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.

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.

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).

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.

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?

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”