In this tutorial, I'll explain how to design levels for video games, based on my experience as a designer for the Ratchet & Clank, Resistance, and Skylanders franchises. I'm not going to dive deep into individual concepts, but rather give an outline of the high-level process I use when designing a level.
I'll walk you through an example level I'm creating from scratch, so you can see typical results from each stage of the process.
- In Step 1: Understanding Constraints, I'll walk you through common limitations I always look out for while designing levels.
- In Step 2: Brainstorming and Structure, I'll show you how I decide what goes into a level.
- In Step 3: Bubble Diagrams, I'll introduce you to a visual method for outlining what goes into each area of your level.
- In Step 4: Rough Maps, I'll talk about how I flesh out each bubble from a Bubble Diagram to figure out what goes into each area. I could write an entire series of tutorials about how to do this, so we'll only go over the basic outline here.
- In Step 5: Finishing the Design, I'll talk about moving on from your basic design to create final spaces. This is also a huge topic that could be further explored in a series of tutorials, so for scope I'll keep this very basic.
1. Understanding Constraints
At the beginning of a design, the hardest part is figuring out what is going to be in a level. As a designer, you get to decide a lot, but you don't always get to decide everything—especially if you're working in a large team.
On a large team, most of your constraints are going to come from other people. There will be business constraints, franchise constraints, audience constraints, legal constraints, engine constraints, and so forth. Most of the time, these restrictions come from far away up the chain.
Closer to you will be the constraints applied by the vision of the creative director, art director, and anyone else involved making decisions at that level.
If you're working on your own as an indie, you're the one who will be making these decisions, so you still need to understand your constraints very well.
General Constraints
There are a few general constraints I try keep in mind whenever I design a level; I find that these apply to most games I've ever worked on. I've provided example answers to the questions about these constraints below to show you the level of detail you need to get started, and I'll use these example constraints to construct an example level design in this tutorial.
How Long Should This Level Be?
This is a short level, about 30 minutes long at most.
Are We Trying to Show off Any New Tech, Art, Audio, or Similar?
Our imaginary game engine has cool indoor lighting effects, so I want to have lots of cool indoor spaces.
How Much Time Do I Have to Design It?
This article was written over the course of several months, but the level design aspect itself took about two or three days to complete.
Note: I'd expect this process to take about 5 weeks for a full-sized level on a real game.
If Someone is Paying For This Game, What Are Their Requirements?
For a game not made as a tutorial example, these requirements usually come from the publisher, the investors, the marketing department, and so on.
What Platform is It On?
The platform you make the game for imposes constraints. A game for a phone can't use as much processing power as, say, a game for PS4 or PC. A virtual reality game imposes restraints on camera movement to avoid causing motion sickness. Mobile games have length restrictions because people play in short bursts. Know your limitations.
For the sake of this example, let's say the game is targeted at last-gen consoles (PlayStation 3, Xbox 360) and PC.
Where Does This Level Fit Into the Level Progression?
This is the third level of the game, and, as such, the challenges won't be too hard.
Who is the Audience?
This game is a sci-fi game, fairly violent. It will likely get an M (or 18+) rating. We're aiming this at hardcore gamers over the age of 18.
The Most Critical Constraints
If you find yourself in the fortunate situation that someone is paying you to design a level, remember that they want this level/game for a reason. If the stuff you make doesn't satisfy that reason, they will not (and should not) pay you, or the development studio you work for, for it. Satisfying clients is the best way to make sure they hire you or your studio again, so make sure to ask questions about what that reason is.
Those critical questions vary from project to project, but regardless of whether I'm designing a level for myself or for others, I find that there are four questions that are almost always the most important to ask first:
- What is required by the level's story, theme, and plot?
- What are my set-pieces?
- What metrics am I constrained by?
- What does the game's "Macro design" require from this level?
Let's look at each of these, in turn:
What is Required by the Story, Theme, or Plot?
The goal of the example level is to rescue a VIP who is trapped in a military facility, then leave the area in a helicopter.
What Are My Set-Pieces?
For the sake of this example:
- Dark hallways and stairwells show our lighting off to good effect. Employ surprise to prompt weapon firing, which will cast cool shadows.
- Fight a huge monster in a destroyed barracks near the middle.
- A Control Tower where the VIP is located.
What Metrics Am I Bound By?
Each area that you design needs to take into account things like the player's movement speed, the size of the player, the size of the monsters, jump heights, and so on.
Each of these informs how large your corridors and spaces need to be, and what heights and lengths are available to be used as jumps.
What Does the Game's Macro Design Require From This Level?
Early in the development of a game, a short document is usually developed that decides what goes on in each level in very vague terms. (Watch this D.I.C.E. 2002 speech by Mark Cerny for more information on Macro designs.)
A Macro document specifies which puzzles and enemies go in each level, how many usages of each are expected per-level, what rewards you get, and things of that nature. This puts further constraints on your design.
For the sake of our example, here are our Macro constraints:
First: this is a simple first-person combat game. No puzzles, and simple combat with four enemy types:
- Ranged: An enemy that stands still and shoots at the player.
- Melee: An enemy that runs up close and attacks the player with a weapon.
- Swarmer: A small, close-range enemy with a single hit point. Good in swarms.
- Heavy: A large enemy that stands still, takes lots of hits to kill, does lots of damage, and has both a ranged attack and a melee attack.
Second: once the player has rescued the VIP, there needs to be a shortcut back to the start of the level, so the player doesn't have to re-traverse the whole thing.
Third: the VIP is located in the final combat room. She is being held prisoner by elite soldiers.
2. Brainstorming and Structure
Coming Up With Ideas
Once I'm clear on my restrictions, I start brainstorming. For example:
- We want a lot of interiors, so I decide this will be an underground base.
- Helicopters get into the base via a long vertical shaft, so I'll start the level at the bottom of one of these.
- The bad guys wrecked the place coming in, so the place is torn up. Several of the areas should be wrecked.
- I want to do combats with enemies at differing heights, so I want to have at least one really long stairwell fight sequence.
- This is not a real level design, so I'm going to make it absolutely linear so my examples in the article are as clear as possible.
- And so on...
Narrowing It Down to Areas
When I'm designing a level, I like to think in terms of different "areas" within the level. That makes it easier to break my work down into manageable chunks. "Areas" is a loose term for any chunk of the level, of any arbitrary size, shape, or location. The only real criterion for whether something is an area or not is that it must help you work faster to think of it that way. If thinking that way makes things more difficult, don't worry about it.
For our example, I want players to learn about new enemies in isolation and then combine the enemies together over the course of the level, so everything gets more complex. This is good intensity ramping.
To do that well, I usually like to have at least seven areas to work with. (It's vastly beyond the scope of this article to explain why, but you can read more about the "Rule of Seven" here to see some of the pacing benefits it brings). When I need a final area for something, like a room for a cutscene where you rescue the VIP, I usually add an extra area. For this example, that means 8 areas.
For each area, I then assign some basic ideas or requirements, so that I have a short list that tells me the structure of my level.
For the example level, this is what I came up with for areas:
- Helicopter Landing Pad: Start of level; safe—no enemies.
- Computer Room: One combat encounter with two Ranged enemies; the path behind you closes off somehow (one way).
- Tight Corridors: Four combat encounters; introduce the Melee and Swarmer enemies.
- Destroyed Barracks: One combat encounter; introduce the Heavy Enemy; tight quarters.
- Barracks 2: The path behind you closes off somehow; one encounter with Melee, Ranged, and Heavy enemies.
- Corridors 2: One encounter with Melee and Ranged enemies.
- Large Stairwell: Vertical fight against enemies; three encounters using all four enemy types.
- Damaged Control Tower Room: One encounter with two Heavies and some Swarmers as a final fight; we need a one-way exit back to the start; the VIP itself is located between this room and the shortcut to the start.
3. Bubble Diagrams
Before I commit a bunch of time and effort towards making a final design, building something in-engine, or even starting to think about individual areas, I always want to have a sense of the overall level and how it flows. This keeps me from making mistakes and having to rework my designs as much.
To visualize the whole level and how its areas are connected, I make a Bubble Diagram.
Bubble Diagram
A Bubble Diagram is a very simple map of the whole level, with circles indicating areas in the level and arrows indicating the flow and connections between the areas.
In the brainstorming phase from section 2, we came up with all the pieces of our level. The idea of a Bubble Diagram is to help you visualize where all of these pieces will be, relative to each other. It also helps you think about the paths through your level, and what kind of path structure is best suited for your objectives.
This is the Bubble Diagram I've made for our linear example level, with two types of arrows to show whether the connection is two-way or one-way:
Almost every designer I know makes these a little differently, and that’s okay! The only requirements are that you must be consistent and that the final product must be readable. Part of the point of making bubble diagrams is that they can be used to communicate your ideas to others, so keep that in mind when you create them.
Note: See my article on Views and Vistas for information about setting up set-pieces and deciding on views. This is a good stage in the process to decide where those go.
4. Rough Maps
Flesh out Each Bubble
Once I've got the Bubble Diagram finished, we know what's going into this level, and we know how each area is connected each other area.
The next step is to run down the list and create a rough design for each bubble. I almost always do this on paper or in Illustrator, because that's how I learned, but I know a number of great designers who do this kind of thing in-engine to get a better sense of the space. Whatever makes you work fastest is best here.
Below, see an example of what one of the bubbles (specifically Bubble 3: Tight Corridors) looks like after I've designed it out on paper (top-down):
The player starts at the top of this area and proceeds to the bottom. This area makes use of right angles to introduce enemies as a surprise to the player
I'll break this down:
- Player comes south and fights 3 Swarmers. After player rounds the corner, four more Swarmers run out from an alcove.
- After rounding the second corner, the player is face-to-face with a Melee enemy. This enemy will need to close distance before attacking, so having it around the corner isn't cheap.
- Rounding the third corner, the player fights a horde of Swarmers, along with a single Melee enemy that runs from behind cover to attack. The Swarmers come from inside the alcove close to the player, and from around the next corner.
- The player passes the fourth corner and turns the fifth corner to be confronted by three Ranged enemies, each using the wall as cover, while five Swarmers run at the player.
- Rounding the last corner, the player proceeds to the area in Bubble 4.
Note how this area is designed in isolation from the others, and scale is considered, but not called out. Note how the distances and heights are still not well defined.
In this rough stage, it's really helpful to be able to change things quickly, so I don't finalize those details until I'm ready to finish the design. I do try to keep the scale relatively consistent between all the areas, though, as this will make my job easier in the next step when we connect the areas together.
Don't get too hung up on accuracy or small details. Things about this design will change constantly from now until the game ships (even after we "finalize" the design). Nothing is being set in stone
Connect the Areas Together
After taking each bubble and designing them in rough, on paper, I link them together (roughly). For readability, I've done it here in Adobe Illustrator, but this can be done on paper as well.
Note how the areas are all laid out end to end, so I know how they'll connect, but I haven't finalized anything yet.
Try to ramp the intensity up, area by area. Make sure you're combining your enemy types well, and that in general the difficulty, complexity, and intensity of your enemy encounters or puzzles increases over the course of the level.
Make sure to add plenty of rest spots between combats or challenges to lower intensity from time to time. If you keep the intensity at 10 all the time, 10 will become the new 5.
The end product (as appears in the image above) is what I call a rough map.
5. Finishing the Design
This step is when I finalize how all the areas connect to each other in physical space. All of the transitions are completed, and I've finalized the heights and distances of everything.
Different designers do this step in different ways. A lot of designers like to dive straight into the engine and build this stuff out, which is great. My preference is usually to finish the 2D map, since I tend to be a bit slower than most when constructing levels in-engine and this speeds me up. The best way will be whatever makes you work faster and makes your end product better.
Notes:
See the PDF attached to this tutorial if you'd like to zoom in and see details of the final map. You can also see how it's organized (different parts in different layers) to get an idea of how I construct these.
The orange boxes are triggers. Enemies in a room won't attack players until players cross the trigger.
Each box on the grid is 2x2 game units. By doing this map top-down on a grid like this, and by marking heights with numbers (e.g. +70 in the map above), I can give indications in all three dimensions about where things should go.
Conclusion
Keep in mind that everything we've done so far is only a design. The minute you get it into the engine and start playing with it, you'll find a ton of things you'll want to improve—but having a solid foundation before going into the tools has helped me a lot over the years.
It's my hope that this description of my method has been useful to you. Most people won't want to work exactly this way, and that's good -- just pick out the parts that make you faster, or which make your resulting work more cohesive, and use those.
Review
I begin the process by understanding all the constraints and restrictions that surround the level. Having a solid handle on my requirements prevents the need for re-work to fix the lack later.
Next, I brainstorm ideas and get together a rough structure for what the level will be like: how many areas I'll need, and what will basically be in them. This usually ends up being a simple numbered list, especially for linear levels like the one we've been working on in this article.
Then, I create a Bubble Diagram so that I can understand how all my areas fit together. It gives me a foundation for understanding the basic flow of my new level at a glance.
After that, I create a rough map. I usually design each area separately, on paper, and then later figure out how to string them together. Once I've got them where I want them, I can see if any changes need to be made to anything I've designed to accommodate the areas fitting together.
Once I've got a rough map, I either start working in-engine or finish the map. When I'm working on my own projects, I go in-engine. When I'm working for others, I usually make a map. A map is a very effective communication tool, and if you keep it relatively up to date it can be useful for people to look at during meetings.
