My Level Design Process
This page documents my process for designing a level. It is worth noting that, while one particular part of this process is listed as the testing step I will show my work to others constantly throughout. I have noted a few areas where testing is particularly important for me but it is safe to assume that after any change I had other people look at my work to make sure I’m going down the right path.
The example level is one for a personal project based off of third-person melee action games.
Step 1: Goals & Pillars
I like to start any design process by listing out my goals and anything that the team really needs to have. This can be something as simple as an emotion, as in a lot of narrative-focused games a level’s goal within the whole experience may simply be to make the player feel a certain way. Other times it can be very technical, for example, teach the player how to use this new mechanic.
Pillars are often more vague. Pillars describe any kind of event, location, moment, etc that the team want to have in the level. For me personally when given a level to design I will often look for inspiration elsewhere to find some kind of moment I want to draw upon.
This is also the point where I will consider what tools the player has access to in this level. This will inform me of the abilities and mechanics I can make use of.
For the example level, I had a small prototype combat and traversal system that I used as the basis for this project.
The above video is a quick run through what the player can do. The controls are a pretty typical 3rd person controller including a jump and dodge option.
Combat is very simple with a lock-on, block/parry, and three hit combo.
One thing I didn’t show in this video is a grapple system that allows the player to quickly zoom toward specific points (as highlighted by a yellow orb).
Step 2: Plan on Paper
Now I know what I need to make I will start with some paper and a pen by sketching out an idea for the level. At this point I will often look for inspiration in the real world or other works again to get an idea for the level flow. Often I will do one or two sketches and combine parts that the team likes into a ‘somewhat final’ design. This is one of those points where testing is really important. I’ll often show other team members sketches of a level and describe how the player will navigate them to see if they agree with my thinking or not.
For the example level, I made only a couple quick drawings and moved on to iterating in-engine. I had a few pieces that I knew I wanted to get in the level. The first being a final fight area where an enormous spear had been thrust into the ground.
I started with that area up on a hill so it would be nice and easy to see at most points of the level. I then wanted the majority of the level to be along a river as it provides an intuitive, natural barrier the player can’t cross. I set the other side of the level against a cliff and set most of the level in a small river-side village.
Finally I knew the two primary tools to be the combat and the grapple. I set up three combat areas and a section of the level toward the end that featured heavy use of the grapple.
The main change from the first drawing to the second was in the ascension to the hill. Originally I had it curl back on itself but I felt like this was unnecessary. To keep the hill always in view I went for a more straight forward approach.
Step 3: Plan In Engine (WhiteBox)
At this point I like to jump into the engine (or another engine if ours isn’t ready) and actually start putting things together.
The level of detail here depends mostly on how confident I am in the engine. In UE4 or Unity I’m familiar enough to make a relatively detailed (i.e. more than just boxes) layout of the level. If I’m less confident in the engine then I may just stick with boxes. My main focus is speed.
The goal here, of course, is to make something that testers and I can play within as quick as possible. The layout should be there and the primary interactables should be usable but everything else is absent.
This step is followed by the first step of really valuable playtesting. Now people can move around the level I can get an idea of how it flows, if it’s successfully conveying the feeling we want it to, and if it could accomplish the goals I set out with.
If the level is designed to teach a mechanic or something more complex than just a level, then I will often have some pretty brute-force versions of this in the level. E.g. If I’m teaching a player how to use a new weapon I’ll probably just have a text-box pop up with tutorial text to indicate how to use it. No dialogue, nothing fancy, just text.
At the end of this phase I should have something I can put in front of players to interact with. They may not be able to complete it properly but a brute force way to get to the end of the level is ideal.
For the example level I was using Unity so I was pretty confident and eager to jump in and start working in the engine rather than on paper.
I started by making two simple assets in Maya. A house, as I knew the setting was a village, and a rock that I could twist and contort into thousands of shapes. The only other model I used from Maya was the spear which I had from an older project. I then used Unity’s terrain tool to sculpt out an area to build the level in. The primary benefit of the terrain tool was it gave me a background with minimal effort, I didn’t intend for the player to interact with the terrain as anything more than a flat surface in some places.
After sculpting the terrain, creating some water, and placing some rocks and houses I had a simple layout of the level to start filling in.
Before moving on to the next step I took a little extra time to fill in the opening area where the player drops down from this walkway. As falling can feel like a failure in some game situations I spent some time trying to make sure it was clear the player would survive, so they’d be willing to descend to the next part of the level.
I also took note and re-positioned some objects to make the opening view of the objective clear. From the first moment the player emerges from the caves they can see the enormous spear in the distance. Even if they don’t recognize what it is yet they’ll be intrigued. This was also one of the only objects I put in color just to make it stand out even more when testing. Planning out this view is somewhere I found testing to be particularly helpful. Simply showing people the screenshots and noting what stands out to them, where they think they’re going, what they expect to find, etc.
Step 4: Fill in some details (Grey Box)
This is the point where I don’t expect any HUGE changes to the level structure so I can start adding more detail. This includes adding significant colors to the level and molding out individual pieces of the level with more precision. This is where the purpose of each level section is the most important to me. I take the combat areas and start to mold them into areas that will work for fighting. I’ll take an area where the player is using a specific tool and craft that out, including the mechanical pieces that are needed (e.g. grapple points, doors & keys, etc).
A rule I was taught for designing levels was to make sure the player has something to look at or interact with every 5 seconds. This step is where that becomes most relevant to me. While filling in areas I will place notable landmarks, even small ones, so that the player has something to see/do every 5 seconds. Often this can be as simple as a peculiar section of plant life, a blood stain, or a pool of water.
This phase can often take quite a while so I like to playtest as I go along, section by section. Often times this step can blend with the next as I might place some temporary enemies or puzzles to help with testing.