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,

-Andrew