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

April 11, 2017
protect

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.

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”:

  • 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

JikGuard.com, a high-tech security service provider focusing on game protection and anti-cheat, is committed to helping game companies solve the problem of cheats and hacks, and providing deeply integrated encryption protection solutions for games.

Read More>>