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.

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!

 

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,

-Andrew