Pre-production
How to plan a game level with mechanics, experience goals, and pillars
What is pre-production?
"Plans are of little importance, but planning is essential." -- some guy
Pre-production is the early phase of a project where you generate ideas and try to figure out what the project is about. It's about answering big design questions:
What are you making?
What will the player be able to do? (Mechanics, Experience Goals, Pacing)
Which parts are most important? (Pillars)
How are you going to make this?
How did other people solve similar problems? (Research)
How much time do you need? Is this feasible? (Scope)
Your answers to these questions will change throughout the project, and that's OK.
Planning is useful but it's not magic; you won't know what you're making until you actually make it.
Project planning
Level planning can take many forms. Like for a small solo hobby project, planning is less important, you can write or sketch a simple basic plan and then enjoy the thrill of improvisation and discovery. But for a larger group project, planning helps everyone know what to do / what everyone needs from each other.
Minimal checklist
Very basic questions, enough for a quick solo jam project:
Recommended checklist
But really, you should be able to answer these other basic questions too:
Full checklist
For 3+ people or a 3+ months project, then more planning will help:
In the video below, industry level designer Steve Lee talks about his process -- before drawing any layouts or opening the editor tool, he first opens a text window and writes an outline for what should happen in the level. This is the core of planning: think about the main ideas and talk about it.
Mechanics
A game mechanic is any activity, system, or tactic repeated in your game, basically any action a player routinely performs or uses. Core mechanics are the most basic frequent and fundamental actions / systems of a game, while less frequent activities can be called secondary mechanics.
Some examples of how we talk about game mechanics:
Super Mario 64's core mechanics are running and jumping to reach the exit. Some Mario 64 levels support secondary mechanics like wall kicks for secret shortcuts.
Doom's core mechanics involve running and shooting, with little or no jumping. Sometimes players trick monsters into shooting each other, a secondary mechanic called in-fighting.
Thief: The Dark Project is a stealth game about avoiding enemies, with a core mechanic where loud fast footsteps attract guards. In contrast to Mario and Doom, Thief discourages fast movement, and running is a secondary mechanic.
Mario 64, Doom, and Thief are all similar 3D action games about reaching the exit without dying. However these games require very different approaches to level design. Mario platforming would make for an impossible Doom level, and Doom-style hordes of monsters would make for a brutally unfair Thief level.
Do not design for the genre, do not sleepwalk into familiar patterns. Instead, design for the actual game that exists! If you're modding a game, play it for at least a couple hours, including other modders' work. Watch YouTube gameplay footage, pay attention to how other players use mechanics and systems.
Haven't finalized mechanics yet?
It's hard to build levels without knowing the mechanics. Both mechanics and levels depend on each other, one cannot exist without the other. You can't evaluate a mechanic without testing in a level, but you also can't quite evaluate a level without finalized mechanics.
If you change your mechanics, then you'll end up with a lot of wasted work and obsolete levels that relied on discarded mechanics. But if you don't build enough test levels to measure the mechanics' potential, then you might end up with a dud mechanic that isn't interesting enough beyond the first level.
You might have to throwaway or redo levels, maybe even multiple times! It's OK. Do not think of this as wasted time or work. Instead, think of each discarded version as valuable research. This is why we call it game development -- development is a process that takes time. It will take time to figure out what makes for a good level and a good game.
Build playground test maps
These simple playground-style debug levels are vital for testing game mechanics and general feel for the game. It is especially essential if you are prototyping your own character controller and player physics, to make sure the player can comfortably move around in the game.
Noun-verb diagrams
Modern game developers today rarely use big "GDDs" (game design documents) nor big design bibles; no one's going to read all that, and docs quickly get outdated as you evolve the game. Instead, create a noun-verb diagram to visually track how game systems and mechanics interact.
"[Noun-verb diagrams are] useful for finding holes and questioning assumptions we were making about player motivations, and is super handy for pitching at a glance, people can understand the game so much faster with this than a bunch of bloated copy.
[...] This diagram is not supposed to chart all the things that are possible, but the things you feel are important."
Experience Goals
An experience goal is some kind of idea, feeling, or activity for the player. To conceptualize goals, try starting with the phrase, "In this level, the player should [learn/feel/do]..."
In this level, the player should... ... learn how to use the double jump ability. (Tutorial)
In this level, the player should... ... feel vulnerable, then reach the safehouse and feel relief. (Emotion)
In this level, the player should... ... dodge deadly traps and unlock a shortcut at the end. (Activity)
In this level, the player should... ... feel like they're escaping a medieval prison. (Fantasy)
Advice for setting goals
BE SPECIFIC.
Experience goals don't have to be complicated or profound, but a clear and specific experience goal helps you decide what to build and what is unnecessary.
"The player should have fun" is a vague goal that can't drive design decisions. What type of fun? How much fun? Be more specific.
Or if the goal is to "make the player feel fear," then what type of fear? There's body horror, existential horror, fear of failure, fear of rejection, mid-life crisis, etc.
THINK FROM THE PLAYER'S PERSPECTIVE.
Avoid abstract experience goals. Imagine the player's perspective.
For example, "the player should enjoy non-linearity" focuses on an abstract structure that isn't relevant to the average player, so it isn't a useful experience goal. What do you actually mean by enjoyment or non-linearity?
Imagine talking after a playtest. What do you hope a player says about your level? You would feel insulted if they said, "wow that was really... um... non-linear..."
SECONDARY DESIGN GOALS CAN HELP.
Levels rarely have just one experience design goal. Even a tutorial level benefits from storytelling and mood. These secondary goals can help guide your design decisions.
For example, "fight multiple enemies at once" is an encounter design goal for a level. But so much is still undefined. Where is this level set? What type of enemies?
Try adding a pacing goal: "feel overwhelmed at first" ... So maybe the fight should start in a small space with enemies almost surrounding the player.
Add a fantasy / storytelling goal: "feel like defending a campsite from zombies" ... So maybe we should research types of campsites (military? hiker? winter?) to plan the arena. Campsites have campfires, maybe there's a fire weapon... etc.
Pillars
The most important experience goals across your entire project are pillars -- the most vital ideas that structurally support and justify your entire design. Design pillars help teams maintain a cohesive vision for the project, and resist "feature creep" work tasks that don't actually support your main goals.
Pillars are a design planning tool to help you conceptualize short-term experience goals for each level or area. Each of your level's smaller experience goals and small gameplay beats should contribute to your pillars somehow, and that culminates in the grander arc of your entire game's experience.
To help internalize these big design goals, title each pillar with a pithy phrase or word. For example, the God of War (2018) internal design pillars at Sony Santa Monica were Combat, Father/Son and Exploration (see below).
Because this was a big budget AAA game, their experience goals also involved production value targets like "high optical [motion capture] fidelity."
You might think this character animation goal has little to do with level design, but imagine a level that makes the mocap character animation look bad -- who has to change their work now, the level designer or the animator?
Because the entire team already agreed that mocap animation should have priority as a pillar, perhaps that prior consensus means the level designer should change their level to fit the existing animation.
In this way, pillars help us define what is important about our projects, and thus make more consistent and coherent decisions during development.
Example: Psychonauts 2
Psychonauts 2 is a 3D platformer about exploring peoples' brains. In November 2016, Double Fine Studios made a pre-production with a vertical slice style "art test" prototype -- 5 years before the game's release in August 2021.
By the end of the dev cycle, there's still a lot of uncertainty and unanswered questions. Will this game be good? No one knows. The journey is just beginning.
Example: Dishonored 2, "Clockwork Mansion"
Dishonored is a first person stealth action RPG series about exploring complex places. In Dishonored 2, there is a "Clockwork Mansion" level where the layout dynamically changes.
"I created this proof of concept early in 2013, long before the map was greenlit to be included in the game, basically to say "yes this could be amazing" and "yes I should work on it." It did both, but it would still be over a year before the map was officially OK'd.
But sure, I could make a bunch of blocks animate however I wanted. What is possible using real level geometry? That's why I made this prototype. A bit less wild? Yes. But still clearly do-able.
That prototype introduced the idea of rooms that were moved around like cargo containers and slotted into place, making the map's layout totally dynamic, but without transforming rooms. I am glad we didn't go in that direction.
[...]
After nearly a year of working on other prototypes it was time to revisit the Clockwork Mansion and finally get it validated. I made a new version with fewer twisty rooms, and more emphasis on the "behind the scenes" areas..."
To give you a sense of time scales here: this level spent 7 months in pre-production, then entered final layout / blockout about 18 months later.
To review...
Mechanics are the repeated systems and interactions of a game.
Core mechanics are the most frequent, while secondary mechanics add occasional variety and finesse for more experienced players.
Experience goals are the player-facing design goals for your levels
Pillars are the main design goals for your entire game. What do you want the player to learn, feel, or understand?
How much planning do you need? It depends.
Small casual projects will be OK with small (or nonexistent) plans, big long-term projects may require a huge internal wiki.
Pre-production planning helps developers coordinate and trust each other.
If you're prototyping new mechanics or game design elements, then blockout a test map with a big playground-style space.
Plans help you make things, but plans always change. Even after preproduction, while working in the middle of the project, you will almost always adjust your plans and improvise a redesign. That is OK.
Now what?
Pre-production in more detail:
Further reading and resources
Last updated
