Architectural enemies and making the player blame themselves: the level design of Dead Man’s Trail

While working, level designers intuitively take steps or base decisions on playtests, but don’t always think of your processes fitting into higher level design “concepts” until someone else talk about them. This happened to me at this past year’s Level Design in a Day tutorial, a day-long session of level design talks, retrospectives, and information sessions.

In one talk, Hyper Light Drifter and Sunset Overdrive level designer Lisa Brown gave a great presentation on how 3D spatial skills translated into 2D environments. She described how, to go from working on 3D games to a 2D game, she had to break her habits of thinking in “z-space” (using the verticality of 3D levels to communicate with players) and find the skills learned from past work that could influence the new work. The transferrable skills she discussed include:

I’ve also just finished reading Jennifer deWinter’s excellent book on the career of Shigeru Miyamoto and a point that really stuck out to me is that many of Miyamoto’s games seem to consider technology first: taking the affordances and limitations of a piece of hardware and making those important to the game’s design. While this is fairly standard practice, I think limitations make for great design opportunities.

These considerations are making me think hard about the level design in a game I’ve been working on for several years, Dead Man’s Trail. Dead Man's Trail is an upcoming PC/Mac/Linux game that I’m publishing through my own Pie For Breakfast Studios that brings a new modern take on the mashup of survival games like Oregon Trail and the zombie-infested worlds of comics like The Walking Dead. It differs from titles like Organ Trail and Death Road to Canada with mechanics like multiple character classes, procedurally-generated 3D environments, lots of weapons, and a darkly comedic plot. It has a 2D “travel mode”, where players keep their truck and party in traveling shape via resource management, and an isometric 3D “looting mode” where players select a member of their party to raid areas for resources and avoid zombies. The different character classes have benefits and weaknesses in each mode, with some finding certain types of resources (food, ammo, gas, auto parts, medicine) more often than others.

In this article, I’ll use Dead Man’s Trail to provide practical examples of Brown and deWinters’s concepts and demonstrate others from architectural design that will hopefully be of use to level designers on their own projects. I’ll also show how we used playtesting to design levels that felt difficult and scary, but not unfair.  

Shameless plug: We’re trying to get the game through Steam Greenlight before the transition to Steam Direct so please consider voting for it there and sharing if you like this article and/or the game.

Gameplay goals of “looting mode”

Like Brown’s design process, let’s start with core mechanics/metrics and how those influenced the design goals for the looting levels in Dead Man’s Trail.

I’m a big, big, huge, absolutely giant fan of classic zombie movies like Night of the Living Dead and Dawn of the Dead or more recent works like Walking Dead or World War Z (the book.) Some common attributes of the zombies in these works, besides being instruments for social commentary, are that they are slow, difficult to kill, not terribly effective alone, and very dangerous in groups or in narrow spaces.

Classic zombies

Several years ago, I wrote an article about zombies in video games called “Building a Better Zombie.” In it, I looked at historical precedents for the modern zombie and outlined these elements that can make them “effective” (scary) in games and avoid making them feel like “dumb cannon fodder”:

For myself and the rest of the development team, Dead Man’s Trail became a playground for experimenting with these ideas. For the isometric looting mode, we felt that the important elements of the list above were “zombie as a natural disaster”, “zombie as a definer of space”, and “zombie as a time limit.” We codified these with the following basic mechanics and metrics:

Goals for this mode’s level design, therefore, are to create spaces that enable players to wander and collect resources comfortably but also enhance the tension when the map fills with zombies. We also wanted the levels to encourage players to take risks, but not throw dead ends in their way without some sort of warning: the levels are not designed to kill the player. If a player gets a character killed or bitten while looting, they should feel that they miscalculated and learn for the next mission.

Screenshot of fighting a horde in looting mode

While I’d love to tell you that these goals helped us design perfectly realized spaces, that’s simply not how level design works. In the next sections, I’ll describe how some of these goals became level design “mandates” that guided practical decisions and how playtesting helped hone the resulting product.

The technology of zombie hordes and learning to love procedural generation

In Shigeru Miyamoto’s 1999 GDC keynote, he talks about technology and its limitations as a first step to game design. DeWinters explores this in her book about Miyamoto by breaking down how he develops hardware to enable specific experiences and designs game mechanics to maximize those experiences. Without being hardware developers, we instead derived aspects of our games around the technology we were developing for and the size of our team. As of this writing, the Dead Man’s Trail team has about 5 long-term members (2 programmers, 2 artists, and a sound designer splitting time between sound and music) with other day jobs, so we’ve to find ways to make more with fewer assets. Our team has experience in everything from AAA development to indie, mobile, and serious games. We wanted to self-publish Dead Man’s Trail on mobile platforms for the sake of flexibility and that influenced many decisions about art and level structure (on some strong advice about where our game would perform best, we eventually switched to PC/Mac/Linux.)

Hordes are the key to our level design goals, but in games where zombies or other 3D characters appear in large groups technology limitations are an issue. To get lots of zombies on the screen, we reduced the amount of geometry in scenes and in the zombies themselves. Each zombie in the game is only about 750 polygons and many of the pieces used to create level geometry are textured planes. While this results in fairly simple graphics it’s also allowed us to create huge hordes on relatively simple hardware.

Zombie topology. We minimized the amount of geometry needed with painted on features, “mitten” hands (the game’s camera is far from the characters so fingers would not be very visible) and other reductions.

Another issue was map size. Even with simple assets for map creation, we had to keep the size of the levels on the screen minimal to keep the game running smoothly. This was a problem for us because we wanted to create scenarios where players were tempted to wander far into a level and have to fight their way back through the horde that built up. Initially, we thought our design was sunk, but we eventually got some inspiration from tabletop games.

A popular mechanism in exploration-based board games like Avalon Hill’s Betrayal at House on the Hill and Twilight Creations’s Zombies!!! is modular boards, sets of square tiles arranged by players as the game progresses. Each time the game is played, the board layout changes and creates a different set of navigation realities (maybe a helpful area is easy to reach in one playthrough and behind a major hazard in another) creating a lot of replayability. Following this model we broke levels into smaller “tiles” and loaded procedurally-selected sets when the player goes looting

Zombies!!! board showing modular tiles and zombies

For someone who works in a “new media” form like game development and on computers, I’m pretty old-school about design processes and used to worry that “procedural generation” was a buzzword for “putting human designers out of a job.” The tiled approach interested me, though, because each tile could be human-designed to create the experiences we were looking for then assembled with into a full level procedurally. To me there were other design possibilities unlocked by this: tension-raising loading screens between tiles (a la Resident Evil - foggy roads instead of doors), blocking off areas of tiles to make players find alternate routes, and so forth.

Our first environment theme in the game was the “small town” seen in many of our screenshots, so streets were the way that players would move from tile to tile. Each tile would have 4 exits in each of the cardinal directions similar to the tile layouts in Zombies!!! We created two basic “structures” for tiles, 4-way intersections and “town squares.” For the most part, these paradigms carry over into the other environment types; forest, mountain, river town, farm, desert, and country town; with theme-specific variations on those structures.

Image of the initial tile templates and some variations. The blue blocks are item spawners and the yellow wireframe boxes are tile exits.

Luckily these measures worked and we had both a game where players could fight large hordes of zombies and wander around large areas searching for loot. Upon making the switch to PC/Mac/Linux we had a choice: redo the art for graphic fidelity or spend the processing power on MORE zombies. We went with more zombies while using some atmospheric effects to dress up the game and avoid a total art overhaul. Likewise, as we’re no longer targeting a mobile application size (current builds are about 674 MB, lean for PC but very big for mobile) we’ve also purchased some environment packs from the Unity Asset Store to enhance existing levels and have more level themes for players to explore (listed previously.) This gives the game more variety and keeps performance up without overburdening the team. We’ve mixed the new assets in with the older self-made ones and the result looks cohesive.

Moving on from purely technical realities, our next challenge was finding a design mandate that allowed us to make the most of the isometric view and the space of each tile.

Scenes and using z-space in an isometric game

One of the obstacles Brown encountered moving from 3D to 2D was the loss of “z-space”, the ability to have objects exist above and below one another and let players use up and down views to find things. We had a similar problem with Dead Man’s Trail’s isometric looting levels. Unlike Hyper Light Drifter, Dead Man’s Trail’s levels are 3D in the sense that they utilize 3D models and run in an engine that supports 3D space (Unity), but do not afford the true benefits of being able to look around in “z-space.”  Isometric view diminishes the total freedom of placing items far above or below players to tease alternate paths.

Beyond sight-line restrictions, the levels of Dead Man’s Trail are also mechanically simple: they don’t feature puzzles, locked gates, destructible objects, or other bells and whistles. Early builds of the game had these features, one example were The Last of Us-like puzzles where players could use boards to cross gaps in the terrain. With the shift to tile-based levels, these proved difficult to plan for unless the boards were always on the same tile. Likewise, puzzles detracted from the core mechanic experience of looting and running from hordes. In the end the levels became simple arenas of collision meant to facilitate the player’s interactions with items and zombies.

A design concept I’ve found useful in other projects for enriching mechanically-simple levels, and likewise applied to Dead Man’s Trail, is Anna Anthropy’s notion of “scenes” from the excellent book Game Design Vocabulary (co-authored with Naomi Clark.) Anthropy explains scenes as the player’s current situation visible on the screen at any time (author’s note: I realize this terminology might be confusing for Unity users thinking of “scenes” as individual files in the game. In this article I will refer to “tiles” or “levels” when I discuss the content of Unity scene files.)

Scenes are useful because making them feels like micro-scaled level design “gestures” and creating a larger area, like our tiles, as a series of scenes makes the resulting level feel very rich. Through playtesting, we determined that a good parti (basic spatial idea) to repeat throughout the game would be a loop (more on this later in the article) that allows players to keep some sort of barrier between zombies, so that found its way into a lot of these micro-designed scenes. Some examples of scenes in the game include grave yards, hedge mazes, parking lots with items between cars, or anything with features that created interesting mini-areas to be chased by zombies in.

I tried these out in the 4-way intersection tile structure, and found that the 4 non-road spaces made excellent scenes because each was just over 1-screen of information. In this way, 1 tile could have at least 4 scenes.

Diagram of scene-worthy areas in a standard 4-way intersection tile.

Likewise, the central intersection of the tile also made good scene material. By adding blockages to this area we could incentivize travel through the outer scenes of the tiles and by leaving them bare, they created a natural place for zombie hordes to converge. The centers of tiles offer good opportunities for players to have a “standoff” with zombies: players fighting their way out of the central group have an equal chance of escaping via the 4 tile exits.

Screenshot of a standoff with a small horde occurring in the center of a tile. 

As such, we kept the street/pathway areas near the exits to tiles free of distinguishing features so players could most easily enter and exit from them. Again, this mindset occurs not just in the “small town” theme, but in others throughout the game. Even in tiles where there are no roads, scenes became an important element for making each tile seem rich. If you consider that in the 4-way intersection example, a “scene” is roughly 1/9 of the entire tile, then scenes can become an actual unit of measurement for how big a feature could be. For example, the farm environment type uses cornfields to obscure player visibility of zombies and items: some measure 1 scene’s worth of space but some are created to be 3 or 4 scene’s worth of space to become a much more prominent feature.

This cornfield is several “scenes” worth of space on a single tile, making the experience of obscured views last longer.

Scenes also provide our answer for the initial question of this section: how to deal with “z-space” in view that isn’t fully 3D. From the beginning, we knew that verticality would be an important tool for teasing players with not-immediately-reachable items. As I said previously, we wanted to create levels that balanced teasing players into taking risks with not outright trying to kill their characters. In terms of teasing, verticality via raised bridges, cliffs, staircases, etc. was useful in doing so.

Illustration from An Architectural Approach to Level Design (2014) showing the concept of showing an item (the treasure chest across the river) but obscuring the path to it.

Showing players items from the main path of a level space but obscuring the pathway to that item by keeping it out of view is a good way to encourage exploration. In our case, we could accomplish this in two ways: teasing paths that existed in a tile itself, and teasing paths that required players to leave the tile entirely and find a new way back.

Our “river town” and “desert” environment types have some examples of this. The driving idea of the river town theme was towns with canals or waterways required bridges to cross. Navigating these areas is rarely straightforward: they are basically mazes. In practice, we accomplished this feeling by making “one way” passages through some tiles in this theme: when entering a tile from one direction you have access to only one other passage out of the tile. A practical example would be a bridge that goes over an entire tile and allows you to see things below, but doesn’t allow you access to them.

A river town tile with raised bridge that separates the tile into 2 separate axes.

In the image above, two of the tile’s exits are on the raised bridge, but the other two are below. If you see an item you need below, you’ll have to leave the tile and navigate your way back from the perpendicular direction. This has been very effective at creating the feeling of urgency for playtesters and adds unexpected depth that’s been well-received.

On tiles where we obscure the path, but keep the path in the level itself, this has an added benefit of warning players of the spatial condition at the location of items. In this way, we can add risk by telegraphing design elements that are normally against our “rules”, like dead-ends, and making players aware of the dangers of entering. If enough vertical distance is achieved, we can even show a great deal of the surrounding tile and create larger views of hordes than the game typically allows.

A dead end visible from a high bridge (with blue first-aid kit on it)

Incentivizing risk has been important for creating a game where players wander around environments and encounter zombies. On one hand, it’s theoretically possible for a player to stay only in one small area of looting levels and loot more often, reducing the risk of wandering deep into the level and provoking a horde. On the other, this isn’t very fun or interesting. Managing player survival chances is the other side of the risk “coin” in our level design mandate, though, and finding ways to threaten this survival but make escape always possible is a big part of creating suspense.

The “shrinking fortress” principle, and survival instincts

If “z-space” and thinking in “scenes” are what allow us to make the player take risks, the way that levels facilitate the player’s relationship with the game’s zombies creates the payoff of those risks. In the goals of “effective” gameplay zombies cited at the beginning of the article, one of the goals is “zombies as definers of space.” In Dead Man’s Trail’s gameplay goals, this turned into zombies spawning from the edges of tiles quicker as the player stays in looting mode and moving in barrier-like herds towards players.

I’ve already talked a lot about the zombies in Dead Man’s Trail, but beyond managing the health and morale of your humans in the game, whether the game creates an exciting experience rests firmly on the zombies’ slumped, rotting shoulders. A major influence on our mindset about zombies was Matthew Weise’s article, “The Rules of Horror: Procedural Adaptation in Clock Tower, Resident Evil, and Dead Rising” from Bernard Perron’s 2009 edited volume, Horror Video Games. In the article, Weise describes the “shrinking fortress” that exists in many zombie films such as Night of the Living Dead and Dawn of the Dead, where survivors hide in a building from hordes of zombies outside. As these movies progress, the tension builds as the zombies take over more of the building, ultimately leaving the survivors with a small room or area in which to hide.

To incorporate the “shrinking fortress” into our levels, we thought that when players first enter a level, they should be lulled into a false sense of security: they don’t see many zombies but the few they do see can be avoided easily or killed since there’s lots of space to do so. As more zombies appear the player finds it harder to do both.

Player character fighting off a horde.

First time players notice that with a few exceptions, the spaces in many of our levels are quite wide and their characters have lots of space to run around. This is because a major part of the level geometry is missing at first: the zombies themselves. The “metrics” (spatial measurements of levels determined by movement capabilities of characters) of the space are made to support large hordes. In our levels, we gave the player characters enough room to move comfortably based on their movement speeds, a concept known as intimate space (I’ve written extensively about this in other works.) Intimate space is one of 3 spatial size types commonly used in games, the others being narrow space, small spaces that limit player movement, and prospect space, large spaces that are uncomfortable because they leave players open to attack and without mastery of their environment.

Over time, zombies pour in and block off space for player avatars to move and players find performing actions such as picking up items, firing, and reloading difficult. In this way, the zombies transform the previously intimate space-sized areas where players are in control and turn them into narrow spaces. This matches another spatial concept called architectural enemies, derived from the notion of “allies that inhabit” from Lyndon and Moore’s Chambers for a Memory Palace (1994.) In the architectural version, human-sized figures, objects, and statues become “allies”, relatable occupants of spaces to the humans inhabiting that space.

In games we can utilize both friendly non-player characters and enemies to fill space, but enemies have the distinction of being harmful to player avatars. In this way, enemies can become elements designed into a level to not only define space, but add tension by doing so. Zombies, when used as slow and difficult-to-kill attackers that fill passages, are particularly talented in this regard. Their slowness means that they will likely not suddenly pass the character and if difficult to kill, can slowly narrow the space as they approach the player, as seen often in early Resident Evil games.

Zombies blocking off narrow spaces in the original Resident Evil.

Returning to the concept of “scenes”, Brown argued in her Hyper Light Drifter talk that level designers can create more interesting levels by designing for player defense rather than offense. In our game that proved very true. While levels did a lot to make zombies more effective, they also help the players herd and avoid zombies in various ways. The “scene” design concept was a great tool for this, as beyond being interesting places to hide items, scenes had to individually allow players to run from zombies. Many scenes in the game are narrower than the roads or other main circulation spaces (spaces for traveling between areas), but offer multiple escape points for players or ways to draw zombies into a bottleneck.

The goal of our scene design, and by extension our greater level designs, was to offer players incentives to take risks so that they would meet the game’s zombies, which transform the levels from manageably-scaled spaces into narrow passages of undulating undead. Then, of course, we have to give players ways to escape the zombies or “almost losing a party member” loses the “almost”, and that’s not fun.

All of this is to say that we were walking a very narrow tightrope with our level designs. They had to accomplish all of these things and one last requirement: not feel unfair. Luckily, we liberally playtested the game, and the final section will tell you what we learned by doing so.

Playtesting to build player culpability

Playtesting is the most important thing you can do when making a game.

If you haven’t done a lot of playtesting on your work, here are some basics:

Start by showing your game to friends or anyone who is not a team member on your project. A fresh set of eyes will always help after you’ve become skilled at your game or used to it to the point where you can’t find bugs anymore (unless you’re also trained in quality assurance and don’t have that problem.) Bring a notebook to take notes on things player say or find. Try not to interfere with their play: if you have to teach them something then it’s an indicator that you need to teach it better in-game. Bring paper questionnaires that ask questions relevant to the part of development you are currently in: you shouldn’t be answering questions about adding new mechanics 2 weeks before launch when you’re looking for bugs. Include questions like “how fun is this game”, “how do you like the pace of the game”, and “how much would you pay for this game” in your questionnaire at every stage of development.

We’ve done all of that and here’s what we learned playtesting the levels in Dead Man’s Trail:

Earlier, I mentioned loops as a useful basic form for many of the games “scene” spaces designed into level tiles. These worked precisely because of the earlier points made about designing for player defense: if players get stuck in an area with zombies, and the zombies are coming into the area the way the player also came in, there should be another exit for the player to use. In some areas we made these loops by instinct, but it didn’t become part of our design mandate until we’d playtested the game many times and noticed the benefits loops had.

Many developers think of playtesting as a time to search for bugs, and it is, but we also wanted to watch players to see if they were killed “by the level” in any way. As I said earlier, the levels in our game have many goals, but one of them is not to kill the player. I’ve seen new designers and young kids with level editors try to outdo one another by making levels that their friends can’t beat and think this is the goal of level design. Game designer Naomi Clark, in Game Design Vocabulary, even tells a story from her childhood where her sister refused to play levels she created after this happened enough times. “Fun” may be a word that many developers and critics reject as being too ambiguous for understanding the quality of a game, but “unfun” is not. Levels made to kill players are unfun.  

What helped us arrive at the idea of loops was the number of rogue dead ends and bottlenecks we had to remove from the game. During playtests I’d seen players get caught in areas we didn’t even think about as reachable or in some nook in an art asset’s collider (a noteworthy example being a player whose character got stuck in the open door of a car model.) Beyond the occasional instance of these being technical bugs, we deleted a lot of obstacles and added a lot of openings in our levels so players would have options for escaping if zombies follow them into an area. We determined that the occasional dead end could be interesting as long as the player can see the dead end beforehand before deciding to go into it.

Loop in a Dead Man’s Trail level

Loops also offered a series of design possibilities that make scenes challenging as well. In several areas we placed a loop inside of another loop (a “nested loop”) so you could have, say, one with two exits for assisting player defense and another inside with one exit to be a partial dead end/risk for players. Given the grid-based structure of the game levels, there are theoretically many nested loops in a level, as running wide loops through a level’s tiles can be an effective way of sweeping for loot and escaping zombies.

A “nested loop” with a near-dead-end loop area inside creates a multi-layered scene with opportunities for defense and risk

Conclusion

Constant playtesting was vital for all of the concepts in this article to be successful. Translating the elements of the undead from classic horror literature into gameplay was certainly a challenge, but beyond enemy design, level design became a primary tool making zombies that “felt” right. We learned through the process of making levels for Dead Man’s Trail just how important level design is for not only maximizing the abilities of player avatars, but also the success of enemies. Even for a simple zombie character, level design can elevate them to a threatening spatial hazard that becomes part of the level itself. Throughout the process of testing our game, we increasingly saw players blame themselves for losing: even powerful characters like the College Athlete (she runs fast and is insanely strong with blunt melee weapons) can be killed if the player is overconfident and sloppy.

Above all, the experience shows how important thoughtful reflection on one’s own level design is. Though we’ve been operating under many of these level design mandates informally, hearing someone like Lisa Brown speak about her work or reading about the design processes of other successful game designers is immensely helpful for designers trying to make their work better. For me, taking this opportunity to reflect on the work done so far will be very helpful for the work to come as we prepare for early access and the eventual release of Dead Man’s Trail.

Thank you for reading! Again, if you liked the article or think the game sounds neat, please head over to our Steam Greenlight page and vote “yes.”! Also, please consider sharing it with your friends!