Against Best Practices

Several years ago my work tasked me to build a cooperative dungeon themed around a volcanic palace. We wanted the dungeon’s difficulty to rise across a series of rooms and end with a fight against the Fire King. At the half-way point through the level, we wanted to challenge the players with a combat-puzzle encounter.

For my prototype of this encounter, I locked the players in a room with several waves of combat and environmental hazards. Each wave, the players needed to complete an increasing number of objectives in order to survive lava that would rise through the floor.

Outside the specifics of the theme, I designed this encounter to test player coordination across multiple objectives under pressure. The encounter also served as a gear check through the enemies. In the abstract, this encounter is typical of raid design, which was our goal. The problem was the theme and converting my prototype to final art without losing clarity.

In one of several meetings dedicated to solving this problem, another designer asked why the Fire King would have this hazardous room in his palace at all. This led to question about who (within the game’s fiction) built this room, why they built it this way, and what happened since it was built.

When a level is able to answer these questions, it passes a test I think of as “architectural realism”. If a level does not hold up to this scrutiny, and we’re left saying “no one (within the game’s fiction) would have build this place or built it this way”, it fails the test of architectural realism.

This concept overlaps with environmental storytelling, world-building, and immersion, all of which are important for high-fidelity AAA narratives games like Last of Us and God of War (2018). As an industry, we place a lot of value on these concepts.

But my level was not for that kind of game. We used a distant 3rd-person camera, larger-than-life characters with exaggerated proportions, and abilities that worked at massive scales. We built our levels and the environment art to match.

So, when one of these design meetings entered a third hour of argument to solve the problem of architectural realism, I was ready to ship the level as it was, in Mario-like abstraction where primitive meshes clearly conveyed their function. Immersion be damned.

Architectural realism had no place in the problem we were trying to solve, and the efforts to pass its criteria wasted development time and made the encounter’s mechanics opaque. A bad application of best practices made my level worse.

Now, when I see the ideas of architectural realism described as best practice, I remember how it can harm the development process when it does not serve the intended experience.

NotHowBuildingsWork.PNG

Here for example, Mark is correct when referring to most real-world architecture, but most real-world architecture ports badly to video games. This is obvious for those of us who learned level design through modding; our rite-of-passage was to build a replica of our house—or school, or office—in Counter-Strike, Doom (1993), or one of so many other games with mod tools. This was a rite-of-passage because it was a painful realization that we can’t just copy what works in the real-world because the context is different. Even within the same genre, the context of Quake 3: Arena was different from Unreal Tournament 2004. An excellent level in one game will be different, often terrible, in another.

The act of design is to recognize a context, its local needs and constraints, and find a solution that fits best. The practice of greyboxing is a way to prototype a solution, evaluate how well it fits the context, and—in professional game development—communicate the solution to the team. The study of level design is too often concerned with the skills of building and not the skills of design, which persist across genre convention.

NotesOnSynthesisOfForm.png

Christopher Alexander wrote about design this way in his 1964 essay “Notes on the Synthesis of Form”, where he created a visual metaphor of constraints and relationships. The dots each denote a constraint, and the lines denote relationships. The + and – along each line indicates whether the constraints support or conflict with each other. This visual metaphor is powerful because it lets us step aside from convention and any dogma around best practices to instead face the specific needs of the problem.

In real-world manufacturing, material and production—what Alexander labels “economy”—are real constraints. Even in our digital world of level design, material and production are constraints we need to consider. We have our level construction processes, our art asset pipelines, and our production methodologies. We also have our studio cultures and divisions of responsibilities. All of these factor into the local context within which we solve our design problems.

For my lava palace encounter, the values of architectural realism diminished once we recognized the whole context of our production process. Solving the encounter for world-building and immersion conflicted with too many other constraints.

//

Around the assumed best practices of AAA development, there are assumption of roles and responsibilities. In some studios, level designers are also layout artists, world builders, environment artists, content designer, scripters, and quest designers. Each game and studio has its own needs.

otherTweet.PNG(Jeff also clarified in a later tweet that his advice “can be true or false depending on the situation”)

On another project as a professional level design, I spent several months sculpting and painting terrain. I placed foliage and props. Again, I did this work as a level designer. For the experience we intended to provide, we needed rolling hills and grass, and someone had to implement that solution to the design problem. This is level building, but we still call the job level design.

As another example, look at Dear Esther. Where does the level design end and the environment art begin? This division is artificial until we separate design from building. To provide the right experience, the design of Dear Esther called for an island with terrain and foliage; it doesn’t matter whether it was a level designer or an environment artist who did the work of building.

All of that said, when I see talk of “best practices” that don’t specify their context, I get grumpy. And when these “best practices” are directed at students, I get angry. I think about the days of my life wasted solving the wrong problems, and I think about all of the work I shipped that was less than it could have been.

//

What remains if we throw out “best practices” and say the quality of a design depends on its context?

There are fundamentals we can still apply. Gestalt psychology has value. There are also psychological models like Self-Determination Theory to help us better recognize our players’ needs. I personally am skeptical of any application of shape- or color-theory that says “[x] will make the player feel [y]”, but there is still value in studying these areas as well.

What remains is local level design, where our work serves a specific context to the best of its ability. To me, this enriches the many forms our levels can take, frees us from the International Style of AAA best practices, and returns us to our position as experience designers instead of overspecialized level builders. This lets us escape high modernism and enter postmodernism (and maybe we’ll catch up with the rest of the art world eventually).

For students, my suggestion is that you shouldn’t greybox levels in Unity or Unreal by imagining a context that you can’t playtest. Doing this is making fan art levels, replicating solutions that already exist rather than learning how to solve. Instead, take a game with mod tools and an active community and design a level for that context. Seek feedback, not to hear how your level is good or bad, but to better understand who your level is for.  Then build another level with this knowledge. This is the only best practice I know to learn the skills of design.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s