Book 1, Process
Book 2, Culture
Book 4, Learning
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 completely understand what you're making until you start making it.
Project planning
"Planning a level" can take many forms. Some people build small prototypes and test levels before committing to a concept, or you can write out design goals and constraints.
To collaborate as a team, you must make plans and communicate those plans, otherwise you will frustrate each other and the project will likely fail.
But for a small solo hobby project, planning is less important. Make a simple basic plan, and then enjoy the thrill of improvisation and discovery.
Minimal checklist
If you can answer these very basic questions, that's enough to start a quick solo jam project:
- Elevator pitch. In 1-3 sentences, describe the project concept and what makes it interesting.
- Tools. What engine and tools will you use? Will they work for this project? What questions do you have about functionality?
- Scope (basic). How long will it be? How many levels? Are these big or small levels? What does a "big level" mean? These are basic question about scope, the size and workload for a project.
Recommended checklist
But really, you should be able to answer these other basic questions about the design:
- Pillars. What are the 2-3 most important themes / features of this project?
- Experience goals. How should the player react throughout each level? What type of emotion or behavior?
- Mechanics. What are the frequent activities / interactions / skills the player will use?
- Asset list (basic). What kinds of models, textures, and sounds will you need for each level? Have you acquired these assets yet, or is someone going to make them?
Full checklist
If you're 3+ people or if it's a 3+ months project, then more detailed planning will help you a lot:
- Research. What are the inspirations / reference points for these levels? Does the group have a shared understanding and interpretation? How is this project in conversation with the larger culture and industry?
- Worldbuilding. What is the larger world / fictional universe of these levels? Who built these places? What logic / mood guided the construction and use?
- Scope (detailed). Every week, what will you work on, and when? What features / levels are "nice to haves" that can be cut from final release? Planning scope can get so complicated that commercial studios hire one or more producers -- people whose main job is to oversee scope.
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.
People argue over the exact definition of "mechanic." This book adopts a broad inclusive definition because we don't care. But if you care, read more about it.
Some examples of how we talk about game mechanics:
- Super Mario 64's gameplay consists of core mechanics like running and jumping on platforms to reach the exit. Some Mario 64 levels support secondary mechanics like wall kicks with secret shortcuts.
- Doom's core mechanics involve running and shooting, with little or no jumping. Sometimes players can trick monsters into shooting each other, a secondary mechanic called in-fighting.
- Thief: The Dark Project is a stealth game about avoiding direct confrontation, and features 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 -- they are 3D action games about reaching the exit without dying. However, these games also have very different rules and game mechanics, which requires very different approaches to level design. Mario-style platforming would likely 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 and conventions. Instead, design for the actual game that exists. Get a feel for the game. If you're modding a pre-existing game, play that game for at least a couple hours, including other community modders' work. Watch YouTube footage of gameplay, and pay attention to how other players combine various mechanics and game systems.
a page from the Super Mario 64 game manual, detailing various actions and mechanics
What if you 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.
Throughout your game's development, you'll likely have to throwaway or redo your levels. You might even have to remake a level 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 gradual process that takes time. It will take time to figure out what makes for a good level and a good game.
early design document for Donkey Kong (1981) showing mechanics, controls, and flow; by Shigeru Miyamoto (from https://twitter.com/forestillusion/status/1443284433268666368/ )
Build test maps
As part of the planning process, game designers often build simple "playground" blockout-style test maps. These barebones level are intended for internal developer use only, and usually do not ship in the final public release.
For our purposes, these maps basically have zero level design, they are just big boxy courtyards filled with random objects and NPCs.
But that doesn't mean these maps aren't useful. These simple playground-style debug levels are vital for testing game mechanics, physics, and general feel for the game.
Combat prototyping for God of War (2018) in a simple test map, from https://80.lv/articles/evolution-of-god-of-war-from-2014-to-2018/
Experience Goals
An experience goal is some kind of idea, feeling, or activity, that you want the player to understand or undergo while playing. 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. (Experience as tutorial)
- In this level, the player should... ... feel vulnerable, then reach the safehouse and feel relief. (Experience as emotion)
- In this level, the player should... ... dodge deadly traps and unlock a shortcut at the end. (Experience as activity)
- In this level, the player should... ... feel like they're escaping a medieval prison. (Experience as 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.
For example, "the player should have fun", is a vague goal that can't drive design decisions. What type of fun? A light and casual type of fun, a deep engaging type of fun?
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 overly abstract experience goals, and try to think of it from the player's perspective. Ideally, how would a player describe their feelings or understandings while playing the level?
For example, "the player should enjoy non-linearity" focuses on an abstract structural aspect that most would not grasp nor even consider. It is not a useful experience goal. What do you actually mean by enjoyment or non-linearity?
Imagine interviewing the player after a playtest. What do you hope they say about your level? You would feel insulted if they said, "wow, that was really... um... non-linear..."
DEFINE MULTIPLE GOALS.
Levels rarely have just one experience goal. Even something straightforward like a tutorial level benefits from additional experience goals about setting up some storytelling, fantasy, or mood. It might be less important than teaching the player how to play the game, but it still helps to guide design decisions.
For example, "the player should fight five enemies at once" is a combat-oriented mechanical goal for a level. But so much is still undefined here. Is five supposed to feel easy or difficult? Where is this level set, will we need a bigger room to support this higher enemy count?
Let's add additional experience design goals: "the player should feel overwhelmed but then discover a powerup" and "the player should feel like they're defending their campsite from zombies" ... we now bring in themes of resourcefulness, defense, survival, and home. The concept of a campsite suggests a medium-sized outdoor area, and now we can research more specific types of campsites (military? hiker? winter?) to make our plan more specific.
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).
core experience goals / "pillars" for God of War (2018), presented by SIE Santa Monica Studio
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: "Mask of the Rose"
Mask of the Rose is a 2D visual novel / choice-based narrative game by Failbetter Games. While it's not a shooter with 3D levels, it has some similar pre-production needs:
"At Failbetter, when we move from pre- to full production, the game must have a fairly tightly-defined scope, pipelines for producing different types of work must be established, and major questions about the nature of the game answered.What kind of questions? Well on Mask of the Rose, they included things like –
Example: Dishonored 2, "Clockwork Mansion"
Dishonored is a AAA first person stealth action RPG series about exploring complex places. In Dishonored 2, there is a "Clockwork Mansion" level where the layout dynamically changes.
Arkane Studios designer Dana Nightingale built a proof of concept pre-production prototype: (Twitter thread)
"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.
video of internal Arkane prototype "Clockwork Mansion Proof of Concept", recorded 5 Feb 2013 by Dana Nightingale
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 pre-production 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.
- For teams that have never worked together before, pre-production planning helps collaborators coordinate and trust each other.
- Plans help you make things, but don't let plans trap you. Once you're in the middle of the project, feel free to change your plans and redesign it.
Now what?
- Pre-production in more detail:
Further reading and resources
- "A Playful Production Process" (2021) by Richard Lemarchand is an approachable textbook that introduces game production methods, ideal for late high school / university students.
Last modified 4mo ago
Export as PDF
Copy link