ELEVATION MADE EASY

A lecture on what maps with elevation can add to your RPG, and an in-depth tutorial on how to create the effect.

Elevation Made Easy
an RM2k/3 tutorial by that guy Brickroad

~~~


Concept

This tutorial is about making your RM2k/3 maps cooler.

Not prettier, mind you. That'd be boring. Everyone already knows how to make pretty maps: tons of lighting effects, squirrels and butterflies everywhere, 3-tile rule. That's old news. No, this tutorial is going to teach you a couple easy ways to add life to your maps by utilizing the magic of elevation.

Maps in 2d RPGs have width and height; the hero can walk in any of four directions towards the edges of the screen. The most basic ingredients of an RPG map is one walkable and one non-walkable tile. Maps designed like that look ugly and boring, though, so RM designers usually draw their maps with a variety of tiles in order to add the illusion of a third dimension: depth.

Left: a map. Right: an identical map.



These two maps are functionally identical, but the one on the right is more engaging. It's not just because it's more visually interesting, though it is more visually intresting. It's because there's a Sense of Place there. You can see the walls, and therefore approximate how far away the ceiling is. In the first screenshot it's hard to visualize the hero doing anything but, well, literally walking towards the edges of the screen. In the second shot it's easier to imagine he's walking around inside of an actual space.

Anymore, we expect that much from RPGs, including RPGMaker games. That's the bare minimum that people are accustomed to seeing, playing and designing. Unfortunately it's also where most RM games draw the line; the hero's movement is restricted in four directions, and the illusion of depth only exists only to show us where the boundries are to the hero's field of movement.

To help illustrate this point, I have picked completely at random three very pretty screenshots from various popular RMN games. First up is this shot from Beloved Rapture, by BlindMind:

A gorgeous mountain scene from Beloved Rapture.



This is a beautiful scene. The Sense of Place I mentioned earlier is very much in tact: you are high up in the mountains, practically touching the sky. There is a very high level of detail. The illusion of depth doesn't come from walls, but of the earthy material underneath the character's feet. However, the hero has no way to interact with the map outside of walking towards the edges of the screen. Visually it is astounding. Functionally it is the same as the two-tile monstrosity up above.

Next up is this shot from Beloved Rapture, by BlindMind:

A gorgeous mountain scene from Beloved Rapture.



Again, an extraordinarily pretty map. In addition to the high levels of detail and the Sense of Place, the subtle darkening of the screen gives a Sense of Time. There is less light in the scene, which tells us something about how much sunlight this outdoor scene is receiving. What's more, depth is used in an advanced way: crags and plateaus rise up from out of the ground, rock walls with snow-covered tops that add an uneven-ness to the scene one would expect from a mountain. However, the issue with functionality is still present; the hero can't actually climb the rock walls, he has to walk around them. He's still limited to four directions of movement.

Finally here is a shot from Beloved Rapture, by BlindMind:

This cave is probably located inside of a mountain, which is in turn located inside of Beloved Rapture.



The same praise and criticisms of the previous two shots apply to this one as well. The visuals are very pleasing. The play with light is very convincing. The illusion of depth is held in place by a shallow pit in the floor which looks about as deep as the hero is tall, and the vast cascading waterfall plummeting into the depths of the cavern. The hero can't actually climb down into the pit, though; it might as well be a pile of rocks, or a giant cave mushroom, or, indeed, a jagged blackish-brown unwalkable expanse.

When a map plays with the third dimension in a way outside of simply adding the visual illusion of depth, it can be said to have elevation. In such a map the hero not only can see the depth of the map, but also interact with it. He can climb up to higher levels or jump down to lower ones. Very few RM games make use of this concept in any meaningful way. In fact, my silly brain can only bring two to mind, one of which is Balmung Cycle by Magi:

A library dungeon from Balmung Cycle.



In this first shot we see a simple use of elevation: the hero is standing in a room with two floors. He's currently on the lower floor, but he can see the upper floor from where he's at. And lo! He is also given strong motivation to reach that upper floor: there's a treasure box, right there in plain sight! What luck! Here's another example, also from Balmung Cycle:

A maze-like cave dungeon from Balmung Cycle.



This area not only uses elevation for thematic effect, but incorporates it directly into the puzzle-flavored design of the dungeon. Instead of the walkable/non-walkable paradigm of most RM maps, every tile in this room is both walkable and non-walkable. When the hero is on the bottom level the top level is a barrier, and that's reversed when he's on the top level. The hero not only has to consider the walls as obstacles, but also as pathways. And finally:

A gorgeous mountain scene from Balmung Cycle.



Here we have the holy grail of elevation: the bridge. The hero can interact with this bridge in two ways: he can walk across it, or he can walk underneath it. This means there is a tile on this map which is always walkable, but behaves differently depending on which level the hero is standing on. The bridge is very much alive in the player's mind because he must consider it as a bridge, not just as a tile which happens to be brown instead of green.

~~~


Methodology

So now that you've seen the magic of elevation at work, you're itching to start putting it to work in your very own maps! But... wait, doesn't that mean the maps are going to be more complicated? Isn't it going to involve events and code and other weird stuff? In a word, yes. On the whole, making a map functionally interesting is more difficult than making a map visually interesting. There are lots of ways to bring the illusion of depth to life using RM2k/3, though, and they can be mixed and matched as needed. There are pros and cons to each method, so identify what you want the map to be able to do and then pick the one that will give you the best effect.

~~~


Method #1: Directional Pass

The first, and easiest method of creating maps with elevation is built right into the editor: the Directional Pass mode found under Editing Mode in the Tileset tab of the database.

Attack of the RTP Ice Cave!



On the left is a quick map I knocked together to show this off. On the right is the spot in the editor where the magic happens. Each tile on the tileset has four flags, one for each edge. If an edge shows an arrow, the hero can freely walk across that edge of the tile. If the edge has a dot, he's blocked from walking across it. Thus a fully-walkable tile has four arrows, and an obstacle has four dots.

This map features an icy room with a two-level plateau in the middle of it. The edges of the plateau have their Directional Pass flags set in such a way that the hero can walk on them, but not through them from all directions. For example. the upper edge of the plateau is flagged so that the hero cannot walk over the top edge of the tile directly onto the floor below. This means that even though the hero in the screenshot is able to stand on the tiles directly above him and to his left, he can't actually get there without taking the long way down the stairs.

So the functionality of this map's depth is complete: if the hero wants to stand on either of the two levels of the plateau, he has to walk up the stairs. Note, though, that the illusion of depth is also complete: the back wall of the cave runs from floor to ceiling, and thus is three tiles tall. Climbing each level of stairs puts the hero one tile closer to the ceiling. Not only does this map have depth, it has a certain, finite amount of depth. Take care not to create awkward maps that contain areas taller than the established height of an indoor area.

Aha! This map has a flaw! Did you spot it? It's the treasure box on the top level. In the game world, it's two tiles removed from the ground level... but as far as the editor is concerned it's only one tile away. The hero could walk down the stairs, go around the back of the plateau and take the treasure from "above"! What do we do!?

There's a quick, dirty fix that involves making the treasure box non-functional unless the hero is facing its bottom, but that has nothing to do with elevation. Let's look at a more elegant solution.

~~~


Method #2: Tracking Elevation as a Variable

Working my variable-flavored sorcery, the box is now only takable if the hero is actually standing next to it.



In this pair of shots the treasure box is working properly. It the hero tries to open it from "above" (which is actually two levels below), he's told he can't reach it from down there. If he climbs the stairs, however, he can take his 500 gold(s) and be on his way. How did I accomplish this feat? I taught the game how to tell what level the hero was standing on, and make the box react accordingly. More specifically I created a variable called "Elevation" which gets adjusted every time the hero walks up or down stairs. I defined the ground floor as Elevation = 1, and each level the hero climbs increases the variable by one. The treasure box is only takable if the hero is standing on the top level, Elevation = 3.

This group of map events keeps track of the hero's current elevation level.



The first step is to tell the game what level the hero is standing on at any given time. This is done by placing two events per stair tile on the map. Each event is set to "Below Hero", so it's walkable, and "On Hero Touch", so it executes as soon as the hero steps on it. As you can see there is an event on each stair tile, and an event on each tile just below the stairs. Each event has only one command:

<> Variable Oper: [0001: Elevation] Set, 1


So whenever the hero steps onto one of these events, the game silently sets his Elevation variable to be equal to the level he's walking onto. The events are equal except for the value being set. The bottom row of events sets Elevation equal to 1, since Elevation = 1 is our ground floor. The hero will trigger that if he steps down from the second level. The two middle rows of events set Elevation equal to 2. The hero triggers those if he walks up to the second level from the first, or down to the second level from the third. The top row of events sets Elevation equal to 3, and is triggered only if the hero walks up to the top level from the second.

If there were a fourth level, you'd use another vertical pair of identical events to set Elevation to 4 (if walking upwards), or to 3 (if walking downwards). And of course this can be repeated for however many levels your map requires. But what about that treasure box...?

A closer look at the treasure box event.



The treasure box is, of course, a two-page event. The first page is active whenever the hero's elevation is less than three, meaning he is currently standing on the bottom or second level. The command on this page is a message telling the player the box is unreachable. The second page is active when the hero's elevation is equal to three, meaning he is currently standing on the top level. This page contains a command that awards the player 500 gold.

If there were more levels above the treasure box you could safeguard it from being taken from adjacent tiles on higher levels by simply adding a third page that is identical to the first, except is active if the hero's elevation is greater than three.

Now that we're dealing with variables, though, it's important to be mindful of what level the hero enters a map. Make sure all the teleport events leading to your map set Elevation to the proper variable. The entrance to our Ice Cave is on the bottom level, so we'd want to make sure the door leading into it from another map sets the Elevation variable to 1. It would look something like this:

<> Hide Screen: Use Default

<> Teleport: 0001:Ice Cave Room (010,013), Up
<> Variable Oper: [0001: Elevation] Set, 1
<> Show Screen: Use Default


If you get in the habit of tracking the hero's elevation with a variable, and you're consistent in setting that variable appropriately when the hero moves between maps or between levels within a map, you can use the same variable everywhere in your game. You can even link maps at different elevation levels; a door on the second level of one map might lead to the third level of another.

We're still missing something, though; the sensation of walking on a surface when you're on its level, but under it when you're below it.

~~~


Method #3: Tile Swapping

First, let's make our map a little more interesting. Square, blocky platforms are ugly, so let's round off the edges:

Oooh! Roundy!



The rounded tops of each level look a little better now, but they present a problem. They have the same Directional Pass flags as the previous boxy corners (dots on the closed edges, arrows on the open ones), so they're walkable in the same way. This is fine in the first screenshot, where the hero is standing on the obviously walkable tile. It's jarring, however, in the second; it looks like he should be able to take a step to the left, where he'd be partially obscured by the icy slope on the level above. That tile is walkable, of course, it's just blocked from this direction. What's worse, even if it weren't blocked we want the hero to now appear below the tile, not above it. What to do!?

Don't panic. First let's identify what, exactly we're going to need. Those corner tiles have to serve two functions: the hero has to be able to walk over them when he's on the same level, but under them if he's on a lower level. And we have to make sure he can't walk through them.

On this map, though, the only places the hero can be underneath a corner tile is on the ground floor. There's no spot on, say, the second level where the hero can be standing underneath a corner tile attached to the third. So we can get away with a simple tile swap!

The first step is to duplicate the tiles in question. Since they have to be able to do two different things, we're going to need two copies of the same tile on our tileset:

Our Ice Cave tileset, before and after.



Load the tileset up into your favorite image editing software and duplicate the tiles that need to serve multiple purposes; in this case, our top-corner tiles. This does mean your tileset is going to lose some versatility. In this case, I decided that since I'm building an Ice Cave and not a Fire Cave, I can safely eliminate the Fire Cave versions of these tiles. (Be careful to not overwrite the original resource, though; you're going to be sad if you ever need those Fire Cave tiles and no longer have them!)

Next, we're going to go into the Tileset tab in the Database and assign each of our pairs of corner tiles some unique properties:

The secret inner workings of our two pairs of corner tiles!



On the left is what our corner tiles look like when you have Passability selected under Editing Mode in the Tileset tab. On the right is our old familiar friend, Directional Pass. I've decided that my top set of tiles is going to be walkable from above. Therefore it appears underneath the hero's feet (that's what the O is for), and that it's "open" edges are going to be the ones that match up with the other walkable tiles on their level. The bottom set of tiles is going to be walkable from below, so they appear over the hero's head (indicated by the star) and their "open" edges are the ones that lead away from the rest of their level.

Now all we have to do is make the tiles match the hero's elevation level. We're already tracking elevation with a variable, so let's whip up a parallel process even that uses that variable to swap the tiles for us:

The Tile Substitution command.



You'll find the Tile Substitution button on page three of your event commands. The way it works is, when this command is encountered, it will take every instance of the tile on the left (Original Tile) and replace it with the one on the right (Substitute Tile). Since we want the "above" version when the hero is on the ground level and the "below" version when the hero is on the second or third levels, our Parallel Process event needs two pages. The first will be active when Elevation = 1, and will swap each "below" tile with an "above" tile. The second will be active when Elevation > 1, and will swap each "above" tile with a "below" tile.

Remember, the tiles you're working with only look identical. Make absolutely sure you're picking the right ones when using Tile Substitution, and playtest the result thoroughly.

Ahh, much better!



Since our elevation-tracking events are already in place, a single Parallel Process event anywhere on the map with our Tile Substitution commands in it will take care of this business for us automatically. I used corner tiles as an example of this, but as you can see the same idea would apply to bridges or catwalks that are passable both over and under.

What if you have a lot of tiles affected by your elevation change, though? Like, a lot a lot? Fortunately, I've got you covered there, too.

~~~


Method #4: Tileset Swapping


First, let's build a bridge:

BAM! A bridge.



On this map, we have three unique tiles that will be affected by elevation change: the same two corner tiles from before, and the bridge tile. It wouldn't be much work to just add another Tile Substitution command into our Parallel Process, but let's face it. You aren't building maps this simple. The bridge tile you're using is more than a plank of wood; it's got a rope railing along either side, so it's three tiles tall. And it's got stakes in it at the endpoints, so that's three more tiles at each edge. The bridge you're using has nine tiles, not one, and duplicating it for Tile Substitution is going to eat up too much of your tileset. Besides, you're a busy person and you don't have time to manually create nine Tile Substitution commands and their opposites.

We're going to take care of all those tiles at once; we're going to duplicate the entire tileset!

Duplicate tilesets.



In the Tileset tab, you can copy and paste entire tilesets. Here you can see we'll be working with two versions of the same tileset: a "top" version and a "bottom" version. These two tilesets are identical except for the properties of a few of the tiles. Specifically our corner tiles and our bridge tiles. The corner tiles are going to be set the same way as earlier; the "top" set will be an O with open edges leading inwards, and the "bottom" set will be a star with the open edges leading outwards.

The bridge tiles will be set the same way; the "top" set will be walkable, underneath the hero, with closed edges along the top and bottom. When the hero crosses the bridge he'll be able to walk across it, but not step off of it. The "bottom" set will be above the hero, but won't have any closed edges at all. After all, we don't want the hero to be unable to walk left and right while he's underneath the bridge.

Change the tileset. Change... the world.



A few clicks above the Tile Substitution button is the Change Map Tileset button. Our Parallel Process is going to be set up the same way as before, except this time we only need one command on each page: when Elevation = 1, we want the "Bottom" tileset. When Elevation > 1, we want the "Top" tileset.

Holy grail, man. Holy grail.



As long as the Elevation variable is being kept current in events that teleport the hero to this map and on any tiles where the hero ascends or descends a level the Parallel Process will cleanly and silently keep up. Now we can crawl over and under our bridge to our little heart's content!

There's one last quibble we have to fix, though. Since the hero can walk back and forth under the bridge, he can walk to the left or right directly from the bottom floor to the top. We obviously don't want him to be able to do that, which is when we reach for our most complicated and powerful tool in the elevation arsenal.

~~~


Method #5: Block Events

The main problem with all of the above methods is they only work as long as you're dealing with two effective layers of elevation. It looks like we've got three on our map, but remember, those tricky corner tiles only need to act one way at a time. If the hero's on the bottom level they all need to be above him. If he's on the second or third level they all need to be below him. What happens when your map is designed in such a way that you need to have some corner tiles above you, and some below you, at the same time?

Something like this.



The middle layer in this screenshot causes all kinds of problems. The corner tiles along the middle layer need to be beneath the hero, but the corner tiles along the top layer need to be above him. All of the above methods, as I've presented them, will fail to get this working. So we're going to resort to the elevation-happy mapper's best friend: we're gonna brute force it. We can't get the effect we want with tileset shenanigans this time; we're going to have to make our corner tiles out of events. Since we can't play around with the Directional Pass of the event layer, we need some other way to prevent the hero from walking through our corners.

We're going to create what I'll call a "Block Event". A block events are used to line trouble spots around areas of elevation to prevent the hero from being able to walk where he shouldn't. They're pretty simple to create. They have no graphic and no commands. The only boxes you need to worry about are the Variable box in the Preconditions list, and the Event Layer Box.

First let's create some Block Events that prevent the hero from walking from a higher level to a lower one. We need two pages in each Block Event. The first page is completely empty; an invisible, walkable event that does nothing. The second page is an event set to Same Level as Hero, so it is not walkable. Set this page to activate whenever the hero's elevation is equal to the level above the one the Block Event is sitting on:

See? Starting to get complicated.



The eight events arranged in the diamond shapes near the top of this map are my Block Events. As you can see, the outer four events are sitting on the ground level, and serve to act as barriers when the hero is standing on the second level. The inner four events are sitting on the second level and act as barriers only when the hero is on the third level. The events on the stairs work the same way as ever, keeping track of the Elevation variable and making the whole machine work. It's now impossible for the hero to walk through the Block Events and get to a lower floor from an upper one.

He can, however, still walk from a lower floor to an upper one. We can bar passage up to the third level by adding two more Block Events:

It's like an event layer checkerboard!



Since these innermost Block Events are meant to stop the hero from moving up and not down, you want their second pages to trigger when the Elevation variable is below the one the event is sitting on. These two events are sitting on the third level, and are meant to be unwalkable when the hero is on the second, so they should be obstacles only when Elevation = 2.

We want similar Block Events sitting on the second level to block passage up from the first. However, we've already got Block Events on those tiles. In order to make the map completely functional, we need an additional page to each of the Block Events on the second level which activate when the hero's elevation level is below the one the event is on. These four events are going to therefore be solid if Elevation = 1 or Elevation = 3, but walkable if Elevation = 2.

Now all that's left is putting the corner tiles back in:

So yeah okay by this point we're getting a little nuts.



At the center of each diamond is an event that uses the appropriate corner tile graphic. All of these events are always walkable, since we're using Block Events to control where the hero can and can't walk. In order to make the corner graphics behave properly they each need two pages. The first page should have no precondition and be set to display above the hero. The second page should activate when the hero's elevation is equal to the level the corner tile is attached to, and display below the hero. In our example, the two inner corners are part of the third level, so their second page will trigger when Elevation = 3. The outer corners are part of the second level, so their second page triggers on Elevation = 2.

When using Block Events, keep in mind that events can only use graphics from the Upper Layer of your tileset. If your map has particularly complicated elevation, you may have to pay very close attention to the interactions between various Block Events to make sure they're working properly. Always playtest every single individual Block Event from every single possible angle to make absolutely sure they work. None of these advanced elevation tricks work if the variable keeping track of it gets thrown off, and nothing can throw it off quicker than an improperly placed Block Event.

~~~


I simply could not resist showing off my own MAD ELEVATION SKILLZ.



Okay, so after promising a few simple ways to incorporate elevation into your game's maps, I guess I went a little crazy at the end there. Even so, if you invest the time in wrapping your head around these basics and commit yourself to embracing depth rather than avoiding it, a world of possibilities opens up for your maps. Whether you want to create compact mazes that twist in and around themselves, concoct devilish puzzles involving elevators and water levels or just add an extra bit of pop to your existing beautiful-but-perfectly-flat locations, the z-axis is just what you need.

Go ahead, people. Do me proud and make some bridges. You know you want to.

Posts

Pages: first 12 next last
I laughed at lot at this, but it's actually a very insightful article. Everyone should check it out! =]
Magi
Resident Terrapin
1028
Articles on game design are my personal favorites...
WIP
I'm not comfortable with any idea that can't be expressed in the form of men's jewelry
11363
I am wondering how this is the least useful tutorial ever. I am pretty sure people making poor maps has plagued RM games for years, F-G.
Aesthetically it may be important to add levels, but Brickroad seems to be saying that "everyone knows how to make a pretty map" (which is completely crap by the way) so I don't think that comes into it.

I sound like the world's biggest hypocrite for even bothering to argue this point, but I think what you're saying is pretty much the opposite of Brickroad's statements. The entire article stresses the functionality of map design over aesthetics themselves, and how using varied elevations can add to the depth of the exploration experience. Yes, you may find a lot that's in here embarrassingly simplistic, but I'm willing to bet that there are quite a lot of inexperienced members who'll find it at least a tiny bit helpful.
LouisCyphre
can't make a bad game if you don't finish any games
4523
You forgot your transitionless teleport events between two corresponding maps. If you use that for indoors/outdoors, start mixing that with elevation and tileset swapping, and season with some exploration, you start to enter the oh shit realms.
Sorry you didn't get anything from this one F-G. Maybe you'll like the next one better. =)
Max McGee
with sorrow down past the fence
9159
This is something I'm really interested in but I stopped reading when i realized it literally only applied to techniques for a six year old maker.

I wish there was an article on how to do this in RMVX, which doesn't have directional pass.
Max McGee
with sorrow down past the fence
9159
I mean, obviously, having made games for about ten years now, I can figure something out, I'm just saying it would be a good article.
lol a sprinting tutorial is somehow more useful than this
DE
*click to edit*
1313
I think it's a good article, just not as useful as some others, since not everyone feels a need to put elevation in their games. And it does not automatically make for a better game. For example I wouldn't want to play the game from the last screenshots, it feels extremely gimmicky. But elevation similar to FF6 (a bridge here and there, which you can walk under or over) is good.
You just called Kinetic Cipher gimmicky.

/"\
|\./|
| |
| |
|>~<|
| |
/'\| |/'\..
/~\| | | | \
| =[@]= | | \
| | | | | \
| ~ ~ ~ ~ |` )
| /
\ /
\ /
\ _____ /
|--//''`\--|
| (( +==)) |
|--\_|_//--|


(Actually, that place as kind of annoying)
No one cares if this tutorial is useless to you, F-G. Post a troll comment, and you're gonna get troll responses. You're welcome to present arguments as much as you like, that's what comments and forums are for, but resorting to name-calling when someone responds to your provocations isn't going to get you anywhere but on a bad path.

Be a man (metaphorically speaking) and respond to arguments courteously. It would take a pretty compelling argument for me to believe there is little or no benefit to the information in this tutorial, but I don't believe you were trying to state that, even if that is what was implied.

People in this community hang on to Rm2k/3 long after its prime for various reasons: Because it's easy, or because they like the challenge of creating within limitations, or because of the most obvious reason that we don't need to get into here. Individuals that do should see all tutorials like these as additional creative tools in their arsenal.

That being said, I don't use rm2k/3 anymore, but these ideas resonate for 2D top-down games as a whole. I won't be able to make use of the passability instructions given in the tutorial, but I am aware of the potential issues that arise and address them in ways more appropriate to VX.
I really don't know why everyone is arguing over this tutorial. Yah, I know it is a bit simplictic but the guy obviously put a lot of effort into this tutorial and personally to me, the concept of a multi level on one map maze or puzzle sounds really neat.
Pages: first 12 next last