Postmortem for a Game Dev Course

This spring, George McLay and I taught a two week course on Level Design and Environment Art thanks to an opportunity from the fine folks at Futuregames. Our course’s focus was on the day-to-day collaboration between Level Designers and Environment Artists. Altogether, we are pleased with the results of the course, but there are always opportunities to improve.

In starting the course, we had two big ideas we wanted the students to learn:

  1. Players experience the game environments, which is the result of a collaboration between Level Design and Environment Art. Players don’t experience our separate disciplines in isolation. The work is fundamentally collaborative, and we succeed or fail as a team.
  2. To facilitate collaboration and iteration, we use nondestructive workflows. Specifically, we taught the students about modular mesh workflows from a level design kit (LDK) up through an architecture pass.

However, our assignment also created a few other challenges we took for granted:

  1. How to keep production moving. How to build fast, but also build in a way that informs collaboration.
  2. How to overcome the blank page problem.
  3. How to control production scope.
  4. How to push back against problems in the work while keeping teamwork functional.

For me and George, these challenges are a daily part of the job, and we underestimated the extent these challenges could dominate the focus for some of the students.

The Assignment

On the Level Design side, I had the students create a basic lock-and-key pattern:

  • The player sees a goal they want to reach. This could be a narrative goal (“escape the prison!”) or an enticing landmark.
  • Along the way, the player encounters a lock that prevents them from reaching their goal. This could be a literal lock requiring a literal key, or it could be some other obstacle that must be overcome elsewhere.
  • Looking elsewhere for a way to overcome the lock, the player discovers the key.
  • The player returns to the lock, unlocks it, and continues on to the goal.

Crucially, I stressed that the lock-and-key pattern is a way to structure content, regulate pacing, and get more play out of less space. The lock-and-key itself is seldom the source of “fun” (or—depending on the game’s goals—satisfaction, relief, dread, accomplishment).

To make the pattern more than the lock-and-key, I required the level design students to include at least 1 encounter space. This could be a combat encounter, a boss encounter, a traversal or platforming encounter, or a puzzle. The focus of the course wasn’t on gameplay systems or scripting, so in practice this meant blocking out a larger space and having text markup that said “combat encounter”, for example. Some students took this approach a step further by marking up the design intent in detail “combat encounter starts here. Ranged enemy over there. Ambush after that here” and so on. This helped me when it came time to evaluate the levels, but it also helped the level designers communicate their intent to their artists.

On the environment art side, the assignment had them build a basic level design kit for their level design teammates to use in their blockouts. Then, once the level design student had a functional pass on the blockout and the environment art student had signed off on it, the artist would start work on a modular architecture pass. In each of these production steps, we left some room for students to iterate and push for changes when there were problems. For example, if the environment artist didn’t feel confident they could achieve an architecture pass on the blockout their level designer provided, then they needed to push back for level design iterations.

We also imposed a few constraints. First, we limited the teams to the theme of “fantasy”. I figured most of the learning would come from students talking through problems together, and it was best to keep the students within a similar problem-space. If one team was struggling to build hard-surface abstract sci-fi megatstructures, their struggles wouldn’t overlap enough with a team building a flooded medieval town for them to learn from each other.

For the second restriction, we strongly advised against organic environments (caves, cliffs, hills, islands). We wanted students to go through a modular mesh workflow, which is a much harder problem to solve in organic, irregular environments.

The Problems

If you have taught a course before, you can probably anticipate the problems from the simplified assignment outline above. George and I hadn’t taught a course before, so we stumbled right in:

Problem 1: the possibility space was too big. We allowed students to work in Unreal 4, Unreal 5, or Unity, since we weren’t familiar with their technical backgrounds prior to our course. We also didn’t require them to build with a specific game and set of game mechanics in mind, so long as they made clear in the level what kind of gameplay they intended. This meant we saw first person shooters, stealth games, puzzle adventures, platformers, and a few projects that sat vaguely in some undefined mix. Another consequence of this was a massive blank page problem for students to overcome; not only did they need to design a level, but also the game that the level would belong to.

Solution? Specify the exact game and set of game mechanics. “Make a Skyrim dungeon in Unreal 4! Your level should support stealth, combat, and magic gameplay.”

Problem 2: because we were building for an imagined game instead of one you could truly play, the level designers could only do so much to iterate on playtest feedback. Even with text markup explaining “jumpscare! monster ambush here!” it required playtesters to do a lot of work imagining, and this gave the level design students an excuse that “it’ll work better when there’s a real jumpscare here instead of a placeholder” (a problem that plagues waterfall production also, ahem).

Solution? Have the students build for an actual game. On the level design side this would be easy: have them build Quake 1 maps! Or Half-Life 2 maps! On the environment art side, this is much harder because there aren’t so many moddable games that conform to modern workflows. Even on LD side, modding may not be sufficient for their education, since the brushes->compiler workflows of Quake and Half-Life are very different from the modular mesh workflows of modern tools like Unreal and Unity.

Problem 3: assignment details lacked clarity. To grade the assignment, we needed a playable build in addition to a design pitch doc, a moodboard/refsheet, the LDK .fbx, the arch pass .fbx, and also the project files. Since different students used different tools, this became a headache.

A simple, absurd example: the assignment details for the design pitch doc did not require the students to include their names and roles on the team. As a result, many of the submitted docs did not include names. This left me and George guessing as to who was the level designer and who was the environment artist, or even if we had the right assignment for the right students.

Solution? Split the assignment deliverables into multiple sub-assignments on separate deadlines and specify exact requirements. Make tools a clear part of the assignment constraints. Have students submit their pitch docs and mood boards end of day 1, and grade them right away.

To return to the example of the pitch document, we could have provided the students with a blank form to fill in the blanks, since “how to write good pitch docs” was not one of our course objectives.

Problem 4: in the assignment rubric for the level design, one of my criteria to achieve a pass with distinction was “emotional pacing”. I gave a lecture walking through an example of the lock-and-key pattern in Half-Life 2 Episode 2 and how it provides structure to create an emotional journey of anticipation, fear, and eventually satisfaction in victory. This topic is huge and could have been its own course, rather than a single lecture and a bullet point on the rubric. The specifics of emotional pacing also depend heavily on the game genre and the tools, in the form of game mechanics and systems, that come with it.

Solution? If we have the level designers building for a specific game and constraints, then it would be easier to point to examples and specific techniques.

Problem 5: we graded both students based on their combined work. In cases where one student let their teammate down, this created unfair grades, as happens so often in group assignments. In a professional environment, you succeed or fail as a team, but in a professional environment you also have more recourse than in a classroom if your teammate is preventing you from doing your job.

Solution? Grade the students primarily based on their individual work. Make the combined work a smaller portion of their individual grades.

Thoughts for the Future

Now that George and I have done the work of stumbling through the problems above, I believe there are ways to do the course better. Going into the course, I was worried students would be frustrated by limitations on their creativity if we were too specific in our constraints. My hypothesis now is that we could fix the majority of the problems by tightening the constraints.

Specifically, a few things I would try in the future:

  • Require the students to build for a specific game and game mechanics. (Perhaps build a framework in Unreal for them to build with?)
    • Some students would be disappointed by the lack of creative flexibility, but I think there is a way to frame this limitation as a focus on craftwork fundamentals. In art classes, students study contour lines to add that skill to their repertoire, not because contour lines are the only skill that matters.
  • Integrate play-study into the course. Instead of giving a lecture with still images of Half-Life 2: Episode 2, play it live! Have students interrupt any time they notice something interesting, then pause and talk, or reload a save and play through it again.
    • I hope this structure, which I’ve seen work for film-studies and seminars, would give students ownership in identifying these patterns and what they do. The seminar structure is more student-driven instead of a forced teacher->student knowledge transmission and hierarchical “because I say so” assignments.
  • Require submissions along the way so we can check on their deliverables and help them adjust before its too late.

Maybe we’ll get to teach a course like this in the future and maybe we’ll encounter a whole new set of surprising problems! In the meanwhile, hopefully these notes have been useful for those of you who teach your own game development courses.

Thanks for reading,


Welcome to my design blog!

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:

The Door Problem of Combat Design

Playgrounds and Level Design

Analysis of multiplayer level design and social space design:

Halo and Inflexible PvP

Halo Multiplayer Maps and Public Parks

The Red House of Sainte Marie du Mont

Analysis of other games:

Thief’s Maps and Territories

Looking for more level design writing? Check out Robert Yang’s

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”

Towards Better Cooperative Play

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.[1]

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.[2]

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.[3]

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.[4]
  • 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.[5]
  • Remove environmental health packs and give each player a line-of-sight heal ability on a short cooldown.[6]
  • 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.[7]

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:

[1] Philippa Warr gives a specific example through Overwatch‘s play-of-the-game system:

[2] writes about supports in Overwatch as part of the bigger problem of unrecognized emotional labor:

[3] A report from Project Horseshoe on game systems for building friendship between players:

[4] 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.

[5] Dropping weapons during the buy-phase is an critical team interaction in the Counter-Strike series.

[6] 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.

[7] Left 4 Dead and Left 4 Dead 2 do this through enemy types that pin or stun the player until their teammates help.