I’ve been keeping this blog for a while now, which means it can be tricky to find your way around. Here are some of the posts I’d recommend checking out:
Analysis of multiplayer level design and social space design:
Analysis of other games:
Looking for more level design writing? Check out Robert Yang’s https://book.leveldesignbook.com/
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,
- 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.
- For another example of Design as Constraint Management, check out Liz England’s “The Door Problem”
Let me share my best cooperative gaming experience:
My friend and I had decided to replay Halo: Combat Evolved on the hardest difficulty, as we have many times before. This time we played cooperatively online from New York to Georgia, both of us away from our hometown on the west coast. For the first few missions, the game was an excuse for talking about our lives and catching up, interrupting a topic whenever the combat became difficult. As the session progressed, I started to observe our different play styles and preferences, and how that affected our cooperation. As we began mission seven “The Library”—known for its long fights from all sides against the zombie-like Flood enemies in repetitive corridors—I decided to act on my observations about our preferences. For the length of the mission, I would be my friend’s bodyguard and prioritize keeping him alive. I kept this goal secret so it wouldn’t affect my friend’s behavior. Achieving this goal meant keeping coms clear and relying on shorthand callouts adapted from our time playing against other people. More importantly, this meant holding a model of his status in my mind: his position and direction, his health and shields, his weapons and ammo. When I saw him turn one way, I swept my aim to watch his back. When he took point down a corridor, I backpedaled while covering the rear. When I found health packs or weapons, I checked if he needed them more than I did. At the most frantic moments, we became a swirling dance of monster-killing efficiency.
There is a version of this cooperation that could have been condescending, like a parent in “tryhard mode” with their child. If I had perfected my goal of guarding my friend, he would have had nothing to do. I would have made the game boring for him, or worse, I would been selfish by “kill stealing” from him. Because of the difficulty in “The Library” and the difficulty maintaining the model of my friend’s status, the game remained challenging for both of us.
My goal was also more subtle than playing bodyguard, but it is the most accurate term I can find. When I found a rocket launcher, I asked him if he wanted it (despite the danger that comes with explosives in close combat). Or when we approached a tunnel too narrow for us to walk abreast, I asked if he wanted to take point while I covered behind. In these cases, I was a bad bodyguard for the sake of his fun.
Most cooperative play tends to mean parallel solo-play or turn-taking. These are cases where players affect a shared game state but have limited interaction together. Until “The Library”, most of the Halo playthrough with my friend had been parallel solo-play with some turn-taking. That is, we could have ran two separate singleplayer games while talking to each other and had an equivalent experience. In missions with multiplayer vehicles, we took turns driving. Or when we found power weapons on the map that we both wanted, we would take turns based on who took the last power weapon.
Some games try to solve this parallel solo-play problem through character specialization. The thinking is that if every player has a specific role, and each role must succeed for the team to succeed, then the game requires teamwork; harder challenges require more teamwork, which requires team building. The most common example is the trinity of tank, healer, and damage. Tanks draw the focus of enemies, healers keep their tanks alive, and damage kills the enemies. Through varied design, this calls for some synchronicity between players. For example, if the tank receives a huge burst of damage, the healer must react before the tank dies. Even though players’ actions affect each other’s success, this gameplay is still more of a parallel solo-play than cooperative play because there is limited reciprocity. The most frequent and important actions go one-direction.
This creates real problems in class-specialized player-vs-player games, especially for support players. A good support player keeps their tanks alive while they battle for control of objectives, but it is harder to credit their contribution to the team compared to roles that have metrics like kills or objectives captured. To make things worse, players have incomplete knowledge in realtime, avatar-based action games. A players can’t always know when they are a lower priority for healing than another player, or when they are positioned where the healer would need to take unjustifiable risks. This leads to increasingly bitter cries of “need healing!” To remain balanced, support classes have to deal less damage and have less health than other characters, which leaves them vulnerable to flankers and can mean a negative kill:death ratio. In worst designed cases, healing feels like a chore. With all of these factors combined, support tends to get all the blame and none of the glory.
If we ported the designed healer-tank interaction to a real relationship, we would call it unhealthy for its imbalance. Nobody in a relationship should give all of their attention to a partner who doesn’t reciprocate attention or energy. But in the game-equivalent, players are expected to fill these designed roles to win. This design is especially problematic with how it links to gender expectations. Supports are often female characters with maternal qualities, and tanks are often hyper-masculine men, playing off traditional gender roles and the separation of public and private spheres in sayings like “behind every successful man [tank] there is a woman [healer]”. In male-dominated gaming communities, healer roles are often called the easy-to-play (read: boring) girlfriend role.
Part of what separates the type of cooperative play I described at the start from these problematic forms is the amount of reciprocity between players. The first part of reciprocity requires one player to observe the status of another and act upon that information. For the loop to complete, the other player must realize they were affected and respond. Reciprocity fails when players have limited tools for observing player status, for acting upon that observation, for realizing they were affected, or for responding. We can think of reciprocity as an exchange of some resource, including time or attention. The amount of reciprocity depends on the degree and frequency of the exchanges. On one end, checking my teammate’s status could start a short reciprocal loop so long as my teammate knows that I am checking on them. On the other end, giving an expensive gift could begin a slower reciprocal loop to build trust and friendship.
Returning to Halo, my cooperative experience at “The Library” stands out because its difficulty encouraged small but frequent reciprocal actions. At the most basic, surving “The Library” means coordinating movement and shooting, which requires players checking on each other and acting on that information. Not all of these actions are observed and reciprocated, but they are frequent enough that not all of them need to be. Such a high level of coordination was only possible while maintaining a rough model of my friend’s status because of hidden and imperfect knowledge in Halo. When I look at my friend’s character, I know what direction he is moving, where he is looking, what weapon he has equipped, and whether he is taking damage. I can start a basic model from this information, which lets me look away for several seconds and know that I won’t step into my friend’s field of fire or be shot in the back by enemies. The other status information like shields, health, ammo, and secondary weapon require communication to maintain, or rough approximations. With such a burden of information, it is no wonder that these moments are rare.
How could we redesigned Halo to reduce that burden?
- Add your partner’s status to the UI, either as part of the HUD or pinned to the character model.
- Reduce the amount of information by cutting design. For example:
- Limit players to one weapon and remove ammo limitations.
- Change the health system to recharge instead of requiring a shared, limited resource.
- Improve the UI for indicating the distance to allies so that players can act without having to look.
- Add dynamic “chatter” for the player-characters to call out enemies and status changes on behalf of the players.
Many of these systems exist in games created since Halo. Each come with costs to the core design and to production. Worse, many of them break the reciprocity loops by hiding the interaction! (Or perhaps, once this burden is removed, players are free to engage in higher-level strategy?)
If our goal is to add more reciprocity loops to Halo, or improve the existing loops, what design changes could we make?
- Replace the flashlight with a waypoint marker. That marker could change based on the context, whether it’s an enemy, an item, an objective, or a beautiful view that a friend wants to share.
- Change the weapon and ammo system to a shared inventory so that one player could pick up a item for another.
- Or add the ability to drop weapons or give ammo.
- Remove environmental health packs and give each player a line-of-sight heal ability on a short cooldown.
- Redesign mission objectives from “kill everything” and “get to the end” to “perform two separate actions simultaneously, or in a mutually-dependent sequence”.
- Add enemies that force cooperative responses.
Most of these ideas would make Halo a different game, and a bunch of unpredictable design problems would follow as a result. I have a sense these rough ideas would lead somewhere, but I would need to test them before I can say for sure.
Some notes for future research:
- Skill-checks as a lens for thinking about whether a design encourages cooperative play.
- Hypothesis that building trust between players requires the potential for failure or exploitation. How can we do this safely in online communities?
- In games where player-characters improve, how do we avoid false stratification between players?
- Hypothesis that decreasing stakes and urgency in casual player-vs-player games will reduce toxicity.
- Can we, and should we, design around player skill gaps in cooperative play?
Notes, Further Reading:
 Philippa Warr gives a specific example through Overwatch‘s play-of-the-game system: https://www.rockpapershotgun.com/2016/05/31/overwatch-play-of-the-game/
 A report from Project Horseshoe on game systems for building friendship between players: http://www.lostgarden.com/2017/01/game-design-patterns-for-building.html
 Some large multiplayer games like Battlefield and Rising Storm have scouting mechanics where players can tag enemies. However, with so many players, it is hard to tell who did the scouting, which makes it less valuable as a callout clarification.
 Dropping weapons during the buy-phase is an critical team interaction in the Counter-Strike series.
 Left 4 Dead and Left 4 Dead 2 have team-healing mechanics, but they come at a time expense to discourage healing during combat, and a resource expense that makes it infrequent.
 Left 4 Dead and Left 4 Dead 2 do this through enemy types that pin or stun the player until their teammates help.