Table of Contents

1. Preproduction
   1. Concept Phase
   2. Level Design Documentation Phase
   3. Whitebox Phase
2. Production
   1. Pre-alpha Phase
   2. Alpha Phase
   3. Beta Phase
   4. Gold Phase

Seek Understanding

• Identify the context (goals, requirements, & constraints) for design, narrative, and art.
• Evaluate the available information and identify ambiguities.
• Disambiguate ambiguities until clarity is reached and stakeholder desires are understood.
• Identify conflicts or discrepancies between stakeholders’ desires.
• Get stakeholders together, present conflicts/discrepancies, and get consensus/resolve.

Evaluate and Iterate

• The desire is now known. Is there room for improvement?
• List out perceived issues.
• Brainstorm ideas for how to address said issues.
• Pick out the best ideas and rank them.
• Present the issues and proposed ranked alternatives to stakeholders.
• Get consensus and adjust the concept as necessary.

Document the High-level Brief

• There should now be enough information create a “high-level brief” (or adjust an existing one), which at minimum should establish the narrative objective, setting, start and end locations, required narrative events, time of day and weather (if fixed), required gameplay mechanics and enemies, and target gameplay time.
• This forms the basis for the LDD and gives one an awareness of the requirements/constraints.

Create the Level Design Document

• I favor short-ish gameplay beat sheets (as short as reasonably possible) – as opposed to 30 pages tomes.
• The goal is to document the flow of the level’s locations, gameplay beats, and player-facing objectives (it may or may not be linear depending on the game) such that it provides a rough blueprint of what to build and can be reviewed by peers and leadership.
• Start with the known required beats. Get those on paper and then…
• Brainstorm ideas for additional gameplay beats, scripted events, vignettes, locations, sublocations, encounters, puzzles, etc. Collaborate with art, narrative, and other designers on this if possible.
• Search for and collect reference and inspiration material (games, film/tv, images, etc.).
• Identify/theme the locations for each gameplay type (encounter, narrative, puzzle, exotic gameplay, and buffer/traversal – and possibly more).
• Provide brief high-level descriptions of each beat – going into a bit more detail as necessary.
• Include links to support documents: story summary, director walkthrough, high-level brief, high-level flowchart, environment asset list, environment references, environment concept, etc.
• Make adjustments based on internal feedback.

Create a Flow-map

• The Level Designer and their lead need the detailed version. Not everyone will read that or needs to. It’s good to have a concise version too. This is where the flow-map comes in handy.
• The flow-map is basically a flowchart. There should be a node for each gameplay beat. The node should call out the gameplay type (encounter, cinematic, conversation, etc.) and link to the beats that precede or follow it.
• That’s all this document needs to do. It’s a quick visual reference for those that don’t have the time or inclination to read the details.

Create a 2D Paper Map if Necessary

• Sometimes, I find the LDD/gameplay beats and the flow-map to be plenty on their own and I don’t always create 2D paper maps.
• It depends on the situation. If I feel that showing a rough top-down map or sketch is helpful in communicating the vision for the gameplay/experience, I’ll create one.
  • For example, on Mafia III, when constructing an intimate boxing gym in a historic building based on a treasure trove of excellent reference, I found it useful to do a 2D layout as it helped to communicate the player experience path by grounding a sequence of events in a particular space. It was easier to get the idea across with a little 2D layout.
• That being said, I don’t like to go into too much detail on 2D paper maps when I do make them as I find things change too much and too quickly once you get to working in editor. What I find they’re most useful for is getting a rough sense of where one thing is relative to another and what the player’s path or potential paths through a level are before you get into 3D. But again, it can be hard to capture complex 3D layouts in 2D and it isn’t always worth the effort as being able to experience it in 3D is much more understandable.

Actualize the Plan as Simply as Possible

• The main thing I want to get out of whitebox phase is the ability to put a 3D level in front of someone on the team and have them traverse through the space and a get a sense of what the level will be like, start-to-end, without me having to verbally explain it to them.
• With the move into 3D, it’s time to gather more reference and inspiration materials to help inform the spaces.
• Build rough 1st pass geometry. Sightlines, flow, and scale are the important bits right now.
• Represent the gameplay beats (narrative, combat, puzzles, etc.) to convey the intended experience. There are a few different ways to approach this one:
  • Implement pop-up text that indicates the type of gameplay beat.
  • Implement rough scripting to convey the idea as cheaply as possible.
    • For example, shove enemies into a combat space but don’t waste time on trying to make the encounter good yet. Or simulate a cutscene or a walk-and-talk using Sequencer – the key is to do the bare minimum to convey what the content will be. It’s important not to get fancy or spend a lot of time on this stuff.
  • Do real 1st pass scripting.
    • This is often not possible when working on new IP or a new engine/tech. It’s also not usually desirable in my opinion as things tend to still be pretty loose at this stage and subject to sudden change.
    • If in a position to do so, prototype one-off gameplay or other oddities that need a bit of extra scrutiny.
• Make adjustments based on internal feedback.

Prepare for Production

• With an approved whitebox in place, it’s time to get ready to move onto production.
• If you haven’t already, get your folder structure, outliner, and actors organized. If your lead hasn’t enforced their own conventions and standards, apply your own. This will save you and anyone who works with you a ton of headaches later on. Better to start organizing early (which is to say if you haven’t started yet, don’t wait any longer).
• Implement whatever 1st pass support logic that you can.
  • It’s common at this stage for a lot of tools to not really be ready yet but it’s good to do what you can.
  • Things to try and implement if possible: skip-to logic, savepoints, navmesh, objectives and waypoints, pitfalls (death/reset volumes if you fall into them), etc.
• Write 1st pass asset request documentation for all the various departments (sfx, vfx, animation, characters, modelling, narrative, tools, etc.).

1st Pass Implementation

• Refine the 3D layout.
• Implement 1st pass scripting for encounters, narrative moments, puzzles, scripted events, vignettes, gameplay pickups, and any other game-specific content/objects that are ready to go.
• Implement placeholder content for systems/content that is not yet ready to be implemented (similarly to whitebox, you want placeholder that represents the intention without spending too much time on it).
• Implement/maintain support logic (folder/outliner organization, savepoints, navmesh, traversal markup, objectives, waypoints, pitfalls, etc.).
• Make adjustments based on internal feedback.
• Prototype one-off gameplay or other oddities that need a bit of extra scrutiny.

Refine Content

• Finalize the 3D layout.
• Implement 2nd pass scripting for anything that had 1st pass scripting from the prior phase.
• Implement 1st pass scripting for anything that had placeholder scripting from the prior phase.
• Implement/maintain support logic (folder/outliner organization, savepoints, navmesh, traversal markup, objectives, waypoints, pitfalls, etc.).
• Cut content that isn’t panning out, is out of scope, is a ship-risk, etc.
• Make adjustments based on internal and external feedback.
• Optimize content and fix bugs.

Finalize Content

• Optimize content and fix bugs.
• Make adjustments based on internal and external feedback.
• Final adjustments to the 3D layout (hopefully few and minor changes at this point).
• Implement 3rd pass scripting for anything that had 2nd pass scripting from the prior phase and isn’t shippable yet.
• Implement 2nd pass scripting for anything that had 1st pass scripting from the prior phase and isn’t shippable yet.
• Implement 1st pass scripting for anything that’s coming in hot.
• Maintain support logic (folder/outliner organization, savepoints, navmesh, traversal markup, objectives, waypoints, pitfalls, etc.).
• Cut content that isn’t panning out, is out of scope, is a ship-risk, etc.

Done

• Ship it!
• But also, start up the patch work (further optimizations, bug fixes, etc.).