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.

FullSizeRender(4)

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,

-Andrew

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,
-Andrew

Notes:

  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”

The Door Problem of Combat Design

Let’s say I’m making a level for a classic first person shooter. To start, I build an arena and add some monsters. I don’t want the player to be attacked as soon as they start the game, so I add a hallway to one side of the arena and start the player there.

doorProblem_arena.png

Here the “E”s mark enemy monsters in the arena and the “P” is the player start in the hall.

My level is simple, but I’m happy with what I’ve built, so I invite a friend to playtest. My friend walks along the hallway, enters the arena, and alerts the monsters, all according to plan. Then things go wrong. Instead of fighting in the arena, my friend steps back into the hall and fights from the doorway as the enemies funnel in. Instead of a dynamic gun ballet of dodged projectiles and swirling destruction, my friend has turned my level into a shooting gallery: dull, safe, and slow. Continue reading “The Door Problem of Combat Design”

Announcement: Quake Sewer Map Jam!

Everyone hates sewer levels.

Too often they are cramped, repetitive, and disorienting. They limit the range of gameplay systems and require one right way to play. They are the antithesis of playgrounds and sandboxes. At their worst, a sewer level drags with no end in sight and stretches a game thin.

Yet, there is an appeal to sewer levels that is so hard to achieve:

  • A good sewer level is a moment to breathe. In its tunnels, there is quiet and refuge which invites introspection.
  • A good sewer level is raw design. This isn’t the place for the one-off scripted sequence or the expensive art setpiece. Instead, a good sewer level is subtle in its mastery of the craft: geometry, lighting, and textures working in unison.
  • A good sewer level is also environmental storytelling at the scale of systems. As we navigate the space, we glimpse something larger than us. We see the flows in, the flows out, and the processes they undergo. There is history and logic at play in the sewers.
  • And sewer levels, both good and bad, are a space for dreams. Unlike the tombs and dungeons of tabletop RPGs, sewers exist alongside our daily urban life but unseen, like the city’s subconscious. They are an id to the ego of the streets. They are also a home for nightmares.
20190721184901_1

Wolfenstein: The New Order, Chapter 7

How do we solve these conflicts of design? How do we take a sewer level—which everyone hates—and make it good? This is the goal of the Quake Sewer Map Jam. This design problem is the theme.

If you are up for this challenge, here’s what you need to know:

When does the event start? When is the deadline?

The jam begins July 28th and ends August 31st at 1 PM Eastern Standard Time.

My hope with the longer deadline is that more people can participate as they have time. I don’t expect anyone to use the whole month+ on a sewer map. Please pace yourself and reduce scope if you run short on time!

Also, if your map only took you a few hours, you are still welcome to submit it! There is no barrier for quality so long as your map is playable start to finish.

Are new mappers welcome?

Yes! Newcomers are encouraged to participate! Sewers have a lot in common with traditional tabletop dungeon design, so this should be a great opportunity to pick up the tools.

If you aren’t sure where to get started, most of the talk about Sewer Jam is taking place in the Quake Mapping Discord, so stop by and we’ll be happy to get you started. Or, if this is your first time mapping for Quake, here is a Quickstart Tutorial.

Are there any special modifications?

We will be using a new version of the underwater jam’s mod.  This allows for dynamic water! You can read more about these features Here. I will update these links once the new version is available.

If you want to stick to vanilla id1 features, that works too! The progs add features, which you can ignore, but they don’t alter any of the standard features.

Are there any special textures?

We’ve gathered some textures from id1, Daikatana, and a few community packages into the sewerjam_wad.zip. I hope these textures provide a starting point for some ideas, but you are welcome to use different textures.

What is the naming convention?

Please name your map “swjam_[username]”. For example, my map would be “swjam_yoder”. If you build the map collaboratively, please include both names.

Where do I send my map?

Once you have completed your map, you can send it to me at AndrewYoder@live.com or on the Quake Mapping Discord. If I don’t reply within a day, feel free to nudge me again.

Please also include a readme file, and consider including the “.map” file so other people can open your level in the editor and learn from your design.

How strict is the theme?

Your map should draw on the ideas of sewer levels, but there is flexibility. You can make a canal, a cistern, or water treatment plant. It may also help to think of a secondary theme. What does a blood sewer look like? Or a sewer in space? What kind of sewer would you find under a dark mage’s tower? All of these ideas are welcome!

Anything else I need to know?

Your level exit should go to the “start” map.


20190721152204_1

Dishonored, Dunwall Sewers

Despite a mess of design problems, sewer levels are rich with theme. They are also a place to practice the subtleties of our craft. Over the next few weeks, I will be writing about some of my favorite sewer levels, like the two pictured above, and why they work.  I may also write about the sewer levels that failed and why.

I know sewers make for a bizarre theme for an event, but I hope you all will join me in showing what a good level a sewer can be!