More About Level Design and Constraints

In my previous blog post, I described level design as constraint management. Level designers take the needs of art, design, and tech, and we try to resolve their conflicts through the process of creating our levels.

In that post I also hinted that the way we negotiate these constraints is by building level geometry; we negotiate through the process. The complexity of all these constraints is too great to solve in our heads or solve on paper; we have to build and iterate on our proposed solutions, which are our levels.

On team projects, this also means the purpose of a level blockout is to communicate with teammates across disciplines. The blockout should communicate our solution so others can evaluate if it works for their need.

But, shame on me, my previous post didn’t give examples from an actual level and blockout process! Thus, the need for this followup post.

To keep the example simple, let’s say I’m once again making a Quake 1 singleplayer map.

Imagine I already have a beginning to the map, which slowly sets a mysterious tone and sense of place in overgrown ruins. Imagine I have also introduced the basic weapons and monsters for the level, gradually raising the tension. As the player delves deeper into the ruins, the floor falls out from under them and drops them into an encounter room!

I have a few ideas for how to build this encounter:

  • At first, no enemies. The space should start as a puzzle-exploration room, then turn into a combat room.
  • There should be a clear goal for the player. I want them to see the exit in their first scan of the room but not know how to reach it. Maybe an exit to an ascending staircase that the player can see across a chasm too wide to jump.
  • As the player explores the room, looking for a way to reach the exit, they should discover a few buttons. When the player activates one of these buttons, some level geometry in the middle of the room rises, forming a platform for a few seconds, and then reverts. Individually, it isn’t clear how these buttons and platforms help. But once the player has discovered them all and tested some combinations, they grant the player access up onto a ledge, where an intermediary goal waits!
  • Because the buttons are on timers, the player should have smooth paths around the space, no awkward turns or frustrating collision. The buttons should also ideally have a view on the platforms they trigger.
  • At the intermediary goal on the ledge, there is a use-once switch. When the player activates this switch, a new platform ascends at the chasm. This new platform still isn’t enough for the player to jump all the way across to the exit, but it hints that one more platform should be enough.
  • The ledge with the intermediary goal should also show the position of the other intermediary goal so the player knows where to go next.
  • The player should now *get* what they need to do to escape. The player has solved the puzzle and now just need to complete it. This is good for player-intentionality, but it’s also boring. So now let’s add monsters!
  • I want to gradually shift the tone from puzzle-exploration to combat, so I will open monster closets in waves. This means the same puzzle space from before should also serve for combat: no awkward dead-ends or bad collision for the player or monsters to get stuck on.
  • The ambush should surprise the player. This means the monsters can’t be waiting behind locked doors from the moment the player first falls into the room; that would be obvious! I also want the player to think “ah if only I had paid closer attention, I could have anticipated!” This means no teleporting monsters into the arena. A tricky problem!
  • The monster variety during this combat encounter should escalate over time. Depending on how I’ve built the space, some monsters may not work.
  • Once the player defeats all the waves of monsters, the player should now be able to reach the other ledge and complete the second intermediary goal.
  • When the player presses the use-once switch for the second intermediary goal, a second platform ascends, completing a jumping path across the chasm to the exit.
  • As the player prepares to cross to the exit, one final wave of monsters! A “boss” wave! This may also be a great opportunity to drop in a quad damage powerup to increase the intensity. For this phase of combat, teleporting the monsters in is OK. (The player’s expectations should have shifted after the first combat waves, and they should be expecting more combat at any moment, so teleport spawning no longer feels as cheap.)
  • At last, the player kills all the monsters, reaches the exit, and returns to the rest of the level above! The encounter room is complete!

Those are my initial goals for the encounter room (revised a little for clarity). Already, I noted a few challenges in making this encounter work, but I need to build the space to see. Sketches can help me identify more of these problems before I move into the level editor. Likely, I will change my plan for the space as I build it and struggle with all of the moving parts. Then, once I’ve built the level, my pan will definitely change with playtesting.


A quick sketch of the encounter, and just enough info to block out the space in the editor.

So far, the biggest conflicts in this encounter room are between gameplay types. What works well for a puzzle-exploration phase at the start might get in the way during the combat later on. For example, I want the buttons to be hidden enough that the player needs to explore the space, while for combat I don’t want the space to sprawl or become too fragmented.

The other conflict is handling the surprise. When the player first falls into the room, I need to reassure them that this is a puzzle room, that there aren’t any monsters around, nor any combat-cover, nor suspicious monster-closet locked doors. But the room still needs all of those things for the combat phase!


Untitled document(7)

Turning the encounter into a constraint diagram, there are a lot of conflicts! And this is before we consider art…

I need to solve these conflicts as I built my level. Already, this encounter room is a challenge to build well! But my constraints so far are mostly about the abstract gameplay…

Time for Nightmare mode. “Architectural Realism” adds a whole new set of constraints:

  • What was the purpose of the room originally? Who built it, when, and why?
  • How has the room fallen into this state of ruin? Is it water damage? Erosion undercutting the foundations? Was there a singular event that led to this state, like a flood, earthquake, or explosion?
  • How do the buttons operate? Are there moving chains and counter-weights that connect the buttons to the level geometry they affect? Can the player see these moving parts?
  • What purpose did these buttons and moving geometry have within the original space? Or did someone graft these features onto the ruins later on? Either way, why are they there?
  • Are these moving components used often? Or is this the first time anyone has used the space in years? Decades? Centuries?
  • Why were there monsters waiting in closets? How did they get there? Have they been there a long time? How did they survive without food and water?
  • (Etc.)

Thankfully, when mapping for Quake 1, I don’t care! (Or at least, I don’t care too much.) Quake’s chunky graphics mean that realism is off limits. I have to embrace some degree of abstraction.

Up to a point, Quake 1’s players also don’t care. Players want the level to convey a fantasy, which requires a consistent theme and governing logic. This is very flexible! If the level is a ruined temple, floating platforms are probably bad. But if the level is a floating castle in the sky, then floating platforms are probably better than grounded ones. My rule-of-thumb: if I would believe the space in a dream, then it’s good enough for Quake. (And if the space is the kind of dreamscape that would stick with me once I woke, then it’s great for Quake!)

But outside this specific example of making an encounter room for a Quake 1 map, these “architectural realism” questions often matter a lot! For western AAA games in 2020, players want spaces they can recognize from the real world, things like hospitals, cities, parking garages, offices, airports, suburbs… Even in sci-fi games, players don’t want generic sci-fi corridors; they want sci-fi hospitals, sci-fi cities, sci-fi parking garages… (This is a big generalization, of course. Some games within the Western AAA space care about “architectural realism” more than others.)

If I take my room encounter’s design from earlier and I apply the constraints of architectural realism, this is a hellish challenge. Likely, I need to change my design and loosen the constraints for art. This means stepping back from the specifics and considering my big goals with the encounter—the series of feelings I want the player to experience—rather than the implementation details such as the arrangement of buttons and platforms. From these big goals, it is easier to find a solution for these conflicts.

In practice, most levels don’t solve all of their constraints. Production imposes its own set of constraints: time, budget, team size, and scope. As a level designer / constraint manager, I need to find working solutions. I need to build foundations that solve the most important conflicts and leave room to iterate on the details and smaller conflicts from there as the team has time. Making games is messy.

In the end, the “design” in level design isn’t some magic or some lofty science exclusive to those of us with the job title. Level design as constraint management means building, testing, communicating, and iterating. This is the reality for anyone tasked with implementation, building tangible solutions to abstract goals and needs. Level design is craftwork, and that means building.

Thanks for reading,


What Do We Even Mean by ‘Level Design’?

I think of Design as Constraint Management. With Level Design, there is a common set of constraints each time I build a new level. Even when I’m designing for older games with a clear set of rules and expectations, there is a lot to consider.

To keep this example simple, let’s say I need to design one encounter room for a classic FPS like Doom or Quake.

Untitled document(1)

Even with a basic encounter, there are probably enemies to create combat, and there may be moving pieces, like a door opened by a switch so that players can’t skip around the enemies and escape. This gives us our Encounter Requirements, as well as demands for Combat Spacing and Functional AI! I also have to consider the Readable Layout constraint, so players can see and react to the encounter and enemies.

Untitled document(2)

Some of these constraints, like Functional AI and Readable Layout, support each other. With the example of classic FPS games, the AI use line-of-sight checks instead of path-nodes or nav meshes. This means some layout patterns can “break” the AI and trick them into getting stuck. But this also means that building clear and simple gameplay spaces for our AI to walk around also supports a Readable Layout (clear sightlines, distinct hierarchy of spaces).

In the same way, good Combat Spacing (sizes of enemies on screen, travel times of player and projectiles, distances for audio cues, room for monster closets or teleport spawns) tends to support Functional AI. Together, these constraints inform what distances in a layout feel good, and what distances to avoid because they feel bad (because AI or combat systems badly support them).

Untitled document(3)

Some of these constraints conflict. For classic FPS gameplay, the combat systems are often about pushing the player into close range against the enemies. The layouts encourage this by breaking sightlines on longer positions. Good Combat Spacing for classic FPS games also means preventing players from sitting back and chipping away at enemy health with a shotgun.

But these same layout features that help combat spacing can also hurt the layout’s readability and visual composition. A bunch of sightline-blocking pillars may be great for gameplay, but terrible for art.

Where constraints conflict, there aren’t reliable solutions for me to reuse. In one encounter room, the correct balance between these constraints may be different from the balance in the next encounter room.

The way I determine this balance for a space is by identifying the needs. What takes priority here? This means looking at the larger context, where the encounter sits in the pacing- and teaching-arcs of the level and episode:

  • Pacing-Arcs: Was there a tense combat encounter just moments before? Maybe this one can chill, focus on the art, let players use easier tactics and “cheese” enemies.
  • Teaching-Arcs: Is the encounter teaching a critical new mechanic? Maybe Thematic Consistency can step back, give the player the more abstract teaching environment that gameplay needs.

Untitled document(4)

Most of the constraints fit within a few categories: game design and game system constraints;  tech and tool constraints; and art constraints. These categories tend to be internally consistent; all of their constraints resolve. Conflicts instead tend to be between these categories.  What’s good for game design may be bad for art. What’s good for tech may be bad for game design. What’s good for art may be bad for tech and game design. And so on. There are conflicts that need resolution!

Where is Level Design in all of this?

Untitled document(5)

We’re here, at the junction of all these constraints. Our job is to resolve them. Once we have a have a workable solution, we’re on to the next problem, iterating across a whole level.

In classic FPS level design, this isn’t too bad! When it’s just me working on a level, I get to decide my priorities! Maybe I’ll ignore some of those art constraints in favor of gameplay. Or maybe I’ll ignore some of those game design constraints in favor of art? No hurt feelings if I’m the only one making the call.

However, in team environments, there may be a Game Designer who owns those systems and goals that determine these constraints. There may also be an Environment Artist who has their own interests and goals, which mean more constraints. Same with Tech Designers, Scripters, and Programmers. On large projects, each of these categories may be departments instead of individual people, and there may even be Directors for each of these categories, with varied visions and hopes for the project, expanding our network of constraints further.

Level design sits in the middle. The levels that we build are our way of negotiating between the teams and their constraints. Our levels are the field through which we iterate as a team to find the best balance possible.

So, what do we even mean by ‘Level Design’?

Sometimes Level Design means working with art, even building art ourselves. Sometimes it means working with game systems, even designing them ourselves. Other time it meas working with tools and tech and scripting. Usually it’s some mix of all three, and it varies project to project.

Building a level is the easy part. Iterating on that level and communicating with the team to satisfy all the constraints and needs—that’s what I mean by Level Design.

Thanks for reading,


  1.  I stole the constraint diagram structures from Christopher Alexander’s “Notes on the Synthesis of Forms” where he proposed a mathematical approach to solving design problems. The math part is bunk, and Alexander himself came to reject it, but the diagrams are still a nice shorthand. For more on that history, check out “On Design Thinking” by Maggie Gram.
  2. For another example of Design as Constraint Management, check out Liz England’s “The Door Problem”