Detailed Level Layouts

When asked to make a level layout, the first step is to start with a high-level layout. However, once that has been approved, the next phase might be to develop the chosen layout into a detailed layout. These are made to scale (meaning measurements are correct), taking into account player abilities (such as jump distance, jump height, etc…) and include all important details of the level including combat encounters, narrative sections, puzzles locations, etc…

Detailed layouts are meant to be handed over to the rest of the team (engineers, artists, audio, etc…) and them be able to build it in-engine from that. In order to create one, other than the high level layout, you’ll also need to have a good understanding of what the player abilities, weapons and items will be at that specific point of the game.

In contrast to the high-level layout, exactitude is more important than speed, so take your time. Measurements need to be precise. There are a few ways to make sure you are using the correct scale:

• You can use a precise program such as Illustrator or AutoCad to make sure that every line uses a real world scale (i.e. 1 to 1 with meters or yards). Just remember that in most games, player abilities are not ‘realistic’ (game characters usually jump much higher than humans).
• You can pre-arrange with the rest of the team a series of “lego blocks” you’ll use to make the level. These standardized pieces can have different skins for different environments, but the scale is consistent. It’s easier on production to make them, but you lose the flexibility of the first method.
• You can use Hero Units, as recommended by Mike Birkhead. Basically use your main character as a ruler to measure everything else in the game. You can create an actual ruler that shows the main player abilities and use this to measure the level while building it. This will help creating layouts where you can gauge the difficulty of different sections and will easily translate between teams and game engines (as it’s all self-contained).

A detailed layout should be made in Photoshop, Illustrator or a similar tool, as they have so much information that separating it into layers is crucial. Important layers include:

• Level structure — The basic layout. Each different height should be a different layer, as well as parts of the layout that aren’t constricted by reality (i.e. hidden or magical pathways). The basic layout should be outlined in all the other layers so it’s easy to see how everything relates.
• Objectives — What are the key objectives of the level.
• Enemy Encounters — Where players will find enemies and what type of enemies they will find. If the enemies have a patrol path or a set area they are covering, you should show that as well.
• Lock & Key items — If there’s a lock/gate system in the level, that should go here. Here gates are more conceptual, referring to any barrier that can only be overcome after a player has grabbed a specific item or performed a specific action. Of course they can be a literal gate, but if a player needs to get “super jump boots” to pass on to the “really high ledge” that would also count.
  • Puzzles — Many 3D games have puzzles that serve as gates. Unless the layout is critical for the puzzle, it is generally cleaner to have a separate feature brief for the puzzle, and just mark its location in the map.
• Expected player paths — Many games allow players limited freedom on how to traverse a level. That being said, it is important for us to have an idea of what the main expected path is. This is the path that we think most players will use. During testing and development, this will be where most of our attention should be placed. We should not ignore secondary paths though; and we should also mark them in this layer. If the secondary path is only hidden behind a gate, make sure to include a note about that.

You can add more layers if needed depending on the game. I’ve seen some include concept art, art references, sketches, Voice Over triggers etc… What is important is to have the right information for your team.

You should always include a legend/key (i.e. an information box that describes all the icons, colors, and other info contained in the map). It’s often forgotten and just makes it harder to pass along the layout without a designer there explaining everything.

One very important thing to keep in mind is that your project might not need a detailed layout. If your team is small and communication is good, you might be able to jump straight into grayblox and do a level there. Detailed layouts are a time commitment, if you’re able to give the team everything they needs without creating one, go for it. However, if the team is large, siloed or you’re outsourcing, then this is an indispensable tool.

There are many ways to make layouts. What you see hear is my approach which has taken inspiration from many designers; special shout out to Alex Galuzin & Seb Bouzac.

Depending on the game, genre, and the designer’s preference, the steps for making a level layout will change. There really isn’t one main way to go around it. This is the way I do it:

1. Before we start with the detailed layout, we need to know:
   • The Player metrics (height, speed, jump height, field of view, etc…)
   • What measurements does the team operate with? These can be meters, yards, hero units, engine units (i.e. the default unit in the game engine), etc…
   • A high-level layout
2. Wie should next find the correct scale of the level. This is usually determined by the time we want players to take to traverse it. What “feels right” for a game depends on platform and genre.
   • You can get the distance measurements by multiplying the time with the player speed.
   • Ian Schreiber reminds us to also factor in how much exploration you want. My recommendation is find an ‘exploration factor’ (a percentage of time you want players to explore), translate that to distance and create alternate routes of that length.
3. With the scale, transform the high-level layout into one with measurements. Don’t be afraid to make changes to the layout if it makes for a better level; that is iteration after all.
   • Start with the main expected player path from the high-level layout. Build the level around it making sure to encompass all the main focal points.
   • Use a separate layer for each different height.
4. Add markers for the key objectives and obstacles (enemies, puzzles, etc…). Make sure you do this in separate layers.
5. Once the obstacles are in place think of alternative routes, additional abilities you need to account for, etc… Add these routes to the layout.
   • Don’t forget to add obstacles to the alt routes.
   • A good tip from Ian Schreiber: a quick way to make a level harder is to make easy alt paths and block them at higher difficulty settings.
6. Add any additional information your team requires in its own layer (VO’s, concept art, etc…)
7. Add a legend to the layout so it’s easy to read.

We need to watch out that, on paper, all the obstacles are surmountable by the player. Double check they have the correct items and abilities to progress. If there are jumps or traps to avoid, use a player ability ruler to make sure they are possible (You’ll fine tune difficulty later).

Run the WIP detailed layout by the different disciplines in your team. It is common for art/programing/UX/Audio to have very specific questions about one or two parts of the level. If it’s a common concern, add that info as a new layer. After incorporating all feedback, present the level with everyone in the room so they can all discuss any remaining doubts.

Hot tips: Levels should be shorter at the beginning of the game and get progressively longer to help players feel early progression. You can also do this by using art to create different ‘regions’ in a level, making them feel shorter.

Let’s imagine we’re continuing with our work from the High-level layout. Here we are developing a 3D stealth game in the same vein as Metal Gear Solid.

First things first, we need to know player metrics. There is not much verticality in this level (other than the second floor) and the only movement mechanics are crawling, walking and running. Because of this, the most important player metric is movement speed. We know the team uses ‘engine units’ for the game, but to get the exact player metrics, we need to ask our lead. They tell us the metrics are:

• crawling — 0.5 units / s
• walking — 1 unit / s
• running — 3 units / s

With this data we can go back to the high-level concept and start iterating on it. As a stealth game, we expect players to be mostly walking, especially when in a new area. With this in mind, I want it to take ~15s to get from one end of the space to the next. I don’t expect there to be much exploration in this level, so the exploration factor will be low, say 10% – this means our alternative routes would be ~ 1.5 units long. Remember that this is just a starting point, and not a hard limit.

With the scale defined, we can start diagraming the level. I won’t make all the layers that a game would need; but here’s a few of the important ones 🙂

First off we’d have a base layer with measurements:

Level 1 Level 2

Notes:

• To make these, in photoshop I made an image of 2k by 2k pixels, where each engine unit is equal to 100 pixels. That way I can make sure the image is precise.
• That being said, the diagram is not pixel perfect; just close enough to get a good sense of the space
• You don’t need to show the measurements of generic items that are shared throughout the game (crates, stairs, doorways). Only show those that are relevant to gameplay or custom to the level.
• The tanks’ size is based off of the t-90; though I modified it a bit to better fit the space.

Here’s a layer with important items:

Level 1 Level 2

Notes:

• The position of the items is not pixel perfect, in my experience it ends depending a lot on the art; especially for things like that ration box hidden behind the stairs in level 1.
• Notice that the keycard and final gate are color-coded. This is an easy shorthand to help programmers and designers know which elements are related.

Here’s one with the enemies:

Level 1 Level 2

Notes:

• The cameras have a symbol showing how much they turn, but this is also reinforced by the notes on them.
• This is also a good layer to point out the types of enemies you’ll find (in this case ‘Regular Guard’). Because this is a stealth game, there’s only one enemy per patrol, but this is not always the case. If there were a group I’d note it as: ‘orcs x4, goblins x2, wizardx1‘.

Finally one with some inspiration for artists:

Level 1 Level 2

These are just some examples of information you could find in a detailed level layout. Depending on the project and genre, you might need to include more layers or you might not need it at all! Check with your team and leads to know what the best way forward is.

---