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:
- Designing around game mechanics and player character “metrics” (the spatial measurements of player abilities) first.
- Player defense shaping the level’s design (a concept she learned from designer Drew Murray)
- Appealing to player’s survival instincts through prospect and refuge space (which I’ve written about before)
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.
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”:
- The zombie as a personal antagonist – dealing with a character, especially one the player is attached to, transforming into a zombie.
- The zombie as a natural disaster – Zombies are a dominant environmental condition of the world, rather than enemies to be fought.
- The zombie as a definer of space – Zombies, especially in large groups, form barriers that block humans from passing through.
- The zombie as a time limit – The horde is coming!
- The zombie’s effect on mental health – Environmental stress wearing on characters.
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:
- The player enters a looting zone to gather resources and must return to the truck for them to be usable during travel mode.
- Zombies are continuously spawning onto the map from its exits, the longer the player stays in looting mode the faster zombies spawn.
- Zombies are difficult to kill with most weapons. Killshots require lots of bullets or luck.
- The player is much faster than the zombies and can run around individuals or small groups easily.
- Zombies can travel in large herds and spread out to avoid colliding with one another, resulting in large barriers of zombies.
- Damage, bites, or death sustained by party members in looting mode carry over to travel mode. Any resources a killed character is carrying, including those included in the character’s loadout for a mission, are lost. So using a character and loading them with items is like “wagering” them for the chance to win more resources.
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-lik