Thinking Outside the Box: Challenge 4

in Tips and Tricks

Challenge 4: Wildly Impractical!

So in our last challenge, we created something in a way that while a bit more difficult, actually had practical use. This time, we are going to do something completely and utterly impractical.

Why? Because even though its impractical there are cool things you can learn from it that can be applied to practical pursuits.

So first, let’s talk about what we are creating!

challenge4-1So here we have our hero. He stands at the opening of cavern, to his left is a merchant, to his right is a pool of water that refills his health and mana (I’ve never figured out how drinking random water in caves does this by the way, all I ever got from it was dysentery.)

From there he travels forth:

challenge4-2Traveling through the caves to confront the evil villain. Along the way he will travel through 10 connected rooms filled with monsters he must fight to reach the evil mastermind preparing to destroy the world!

challenge4-3And then in the end, he confronts the villain, fights him, and emerges victorious.

I know what you are thinking. “What, that sounds easy, its standard RPG Making 101, do you think I’m an idiot?” Well hold your horses there! Let’s get on requirements and restrictions.


  1. You must have the player travel through ten 17×13 rooms. They don’t have to be linear, but they have to all exist. They CANNOT be identical.
  2. The first room must have a merchant selling items and a pool to regain health.
  3. The final room must have a boss fight.

Still sounds easy right? Wrong.


  1. You can only use ONE 17×13 map in your project.
  2. You can only use ONE event in your project.
  3. You cannot use scripting.

Think you can figure out a way to get around these restrictions? Tell us your plan in the comments below! Good luck.


Comments on this entry are closed.

  • Before I tackle this, can you define “identical” a little more? Are you talking about the passability of the tiles on the ground, as in the ground tiles and the wall tiles cannot be the same layout per room or just the aesthetics?

    • Aha, yeah, the trick is the passability. The point of that rule is that you have to be able to have different layouts for each room, not just aesthetics.

      • I’ve got a working prototype in rmvxace right now. If there’s a simpler way to do this then I just made this impractical challenge even more impractical.

        step 1: fill map with a non-passable tile.
        step 2: use region ID 1 to draw a small area in the center. use region ID 2 to draw where the water will be.
        step 3: use different region IDs exiting this area, a minimum of 5 separate entrance/exits that will be interchanged. Fill the rest of the map with region ID 63.
        step 4: create parallax maps based on the different combinations of entrances and exits, making sure that the area with ID 1 is always open and only the first map will have water on ID 2. For the 10th parallax, have only one entrance.
        step 5: create your single event somewhere on region ID 1 and change this event to look like a merchant It will be a parallel event.
        step 6: you’ll need 11 variables. First is Room variable which tracks which room you’re in. 2 and 3 track for the player X and Y. 4 through 7 tracks each direction + or – 1 to track the area around the player. 8 to 11 track the region ID of the area around the player.
        step 7: Create four conditionals for the left, up, right, down button being pressed, without ELSE. In here, do another conditional checking if the variable around the player is region ID 63 depending on which way the player is going.Nest another conditional in the else of this, asking if the region ID is that of a closed off path, and continue this if necessary.
        step 8: on the last Else conditional, set a move route for the player to turn THROUGH ON, MOVE in the same direction, and THROUGH OFF afterwards.

        Steps 6 through 8 makes it so that passabilities in the map are based on the region ID the player is surrounded by.

        Step 9: Make a conditional that checks if the players X and Y is adjacent to the event. Nest in here a conditional to check if the player presses the confirm or action button, and nest in that to check if the player is facing the right direction. If everything checks out, open the shop.
        Step 10: check if the player is next to region ID to. Nest in here a conditional to check if he’s facing the water. If everything is fine, let him have a drink.

        Step 11: Make a conditional that checks if the player is at the edge of the map where the exit is. If so, transfer to the “next map” and increment variable 1 by 1. If they go back one, decrement it by 1 and transfer them back. Make sure to use a tint screen to black and change the parallax depending on the value of variable 1. Also change the page. Each page will have a page condition checking if variable 1 is the right number.
        Step 12: for every map, aka every page of the event, make sure to do the same steps minus the water and merchant event.
        Step 13: for the last map, use the same process we used for the merchant to start the boss fight.
        did I miss something? I started hurrying >_>

      • Another possibility instead of using those conditionals is to fill the map with a single passable time, then put a different tile from B C D or E onto every single tile of the map, a total of 221 unique tiles. The easiest way is to copy a large segment of the tileset and place it directly onto the map.
        You would basically make the map on the tilesets including passabilities with a total of 10 different tilesets. When you ‘transfer’ using the conditional just change the tileset of the map.

        • You’ve got the biggest of the tricks I’m using here.

  • Lukaaash

    Yeah, very practical. Every change of map just in one event… oh my… 🙂

    • Yeah, there is nothing about this challenge that is practical! There are some practical things you can do with the same techniques though, this just shows off the most bizarre way to use them.

      • Stephen H.

        You’ve stumped me! Will be watching this with interest!
        (Seems like it would be very useful for Lite users, as I was one not too long ago, LOL! The restrictions on events and maps in Lite are quite hindering, IMO.)

  • Just use 10 different “panorama” and change them using a variable for each room to trigger which one is “active”.

    It’s maybe a little tricky to change the collisions according to each map, but still easy to do >> Put empty events on the floor and trigger for each room if they are “passable” or not. (similar method for the Boss, the Lake and the Shop to make them visible/active or not… but “SelfSwitches” will be enough)

    • Problem here is that you can only use one event in the whole project.

      • With one event you will have to use 10 tilesets to trigger the different “collision map” (with or without graphics on it, depending on what method you use for the map, for example no graphics on the tileset if you use a panorama).

        And, to have a boss, a shop etc, just move the unique event where you want it to appear (really fast at the beginning of the map, you can put a black picture above everything for half a second so nobody sees the trick), and change the graphic of the event accordingly.

        It’s even more longer and boring to do this way, but not especially difficult. Who would do that by the way.^___^.

        (can use common event as well *to lower the amount of work* I guess? It doesn’t count for multi-event haha, it’s not an event on the map after all :p)

  • AChan

    Wat ._. !
    This will be difficult.

  • Christos Pipinikas

    WILDLY impractical, though I really like this type of practice.

    So, parallax mapping and one constantly auto-running event. Yada yada.

    Passability is the tough nut to crack here.

    I would probably have the autorun event check for button input and player coordinates each frame, then emulate passability, movement, menu access, object activation etc. through an endless series of “IF…THEN”s.

    It *should* work, I guess, but it would be a pain.

  • Chang

    I have a feeling that this have something to do with screen scrolling.

  • Sharon

    Okay – can you use common events? Either a parallel process one, or even one that’s called through Call Common Event, just to save having to repeat the same massive block of code on every event page?

  • Richard T. Balsley

    I get the impression that using this trick helps free up map space in epic-length games.

    • Actually the real trick of what I’m doing isn’t very practical for what I’m using it for. There are techniques in it though that are good to learn for other things.

  • Geekman

    Not that I’m even GOING to attempt this, but the one-event this could probably be managed with variables.

    • Geekman

      OR you could use parallax mapping. 😉

  • I saw this this morning, and my thought processes went as follows throughout the day…

    “This is easy, just use region IDs on a single map!”

    “Um, wait a minute, a SINGLE 17 x 13 room!? Might be a little more difficult…”

    “Ah ha! It’s basically Zelda! A procedurally generated Zelda dungeon! Nice!”

    In the first Legend of Zelda game, even though everything was mapped out, all the maps were based on a single template. This is most obvious in the dungeons, where they are all graphically the same, with basic pallete swaps for each dungeon.

    Depending upon how much variety you wanted, you can basically define a template for the room, and then use an array with some randomly generated numbers to define the contents of each room AND keep a record for backtracking.

    The simplest answer would be to break the template down into a 5 x 5 grid with region IDs. The squares in the grid need not be identical in size, as long as the basic 5 x 5 shape is there.

    The 25 region IDs should be given a random number to define their contents. The outer “ring” of IDs, is basically used to determine exits from each room. If you want to keep it simple, you could have these all set to impassible, with the exception of ID 3 (north exit), ID 11 (west exit), ID 15 (east exit), and ID 23 (south exit) as being randomly either passable or impassible to create your “maze”. For more complexity, you could make it so that each of the IDs along the edges could potentially be passible, allowing for more than one exit per wall, with up to 9 total exits per room.

    The inner IDs should all be set to passible to create the actual rooms. They can be randomly determined to be passible or impassible to create various layouts, although the first and last rooms should have some of these automatically passible to create the pre-set conditions for each room.

    A 5×5 grid (for 25 region IDs) is the simplest template, and changing the size of the grid leads to more variability if using a simple boolean approach for whether each ID is passible or not. You can also use a non-boolean approach with such variables to increase variety as well.

    The procedural generation aspect basically breaks down into two parts. The first is the generation of the dungeon as random numbers, and should include error checking facilities as required. For example, you might want to have that the region IDs for the inner “room” match up with the random exits, to keep from closing off the dungeon. For example, if the north exit (region ID 3) is passible, then region ID 8 should also be passible to allow the player to reach the north exit.

    The second part is then taking this random string of numbers and parsing it to the game engine to be actually used. This part basically tells the engine what a specific value for each specific ID means, and more importantly what to do about it. This is ideal for the actual control of play within the game, so you can have a specific value for region ID 13 (middle of room) represent the boss encounter, and specific variables for the Pool and Merchant in the first room. Since these are pre-set, they won’t be randomly generated, but there is no reason why they can’t be included in the procedural generation (imagine a merchant randomly appearing in room 5, for example).

    On the whole, since you are basically encoding the game within the game engine manually, this is only impractical if you intend to use it once or twice. However, the approach can be used to create random dungeons within a game, to help quickly flesh out areas that aren’t story essential, and can provide variability for each game.

    As the saying goes: “There is always a cave…”