Zombie Heist Retrospective

I started working on Zombie Heist nearly two years ago. I had just watched Zack Snyder's Army of the Dead and began thinking of how to bring that vibe to the tabletop. I was alone in my flat whilst my friend was visiting family during the lockdown, and so my brain could do nothing but turn the idea over and over until I had it formed. The first draft was never meant to be big, but I proceded to write 10,000 words over the course of a week. After work I'd switch on my computer and just type, and I spent most of the weekend working on it. This will most likely never happen again: Most of the mechanics where formed already in my manic, cooped-up mind after a week of thinking it over, so they just sort of spilled onto the page. I want to emphasise that this was not how my brain works usually, and it was probably the last time I've ever been able to write so freely. And it's also the cause of some of the game's biggest problems in my eyes.

The game has now been released for a year. I have earned some money off of it, yes, but it was also a part of the Indie Bundle for Abortion Funds, and it warms my heart that most of the downloads seem to come from that. But now is a good time to look at Zombie Heist and figure out how to make the next project better. This post will dive into some of the design and development process, look at what I think it did well, but most importantly look at what could be improved on.

Development and Design

As mentioned above, this game is heavily inspired by the film Army of the Dead, and the idea of telling stories about a group doing heists in the zombie apocalypse. After thinking, this came down to the following tenets:

1. Cinematic feel - The players should feel like they are playing characters in an action-heist movie
2. Group dynamic - Everyone in the group plays a distinct and important role in the story, encouraged to work together but able to have their moment
3. Serious and scary atmosphere - Situations should be tense, and most characters should be critically injured or dead by the end of the story

The first key decision was that this would be a one-shot focused system. Each session was meant to be its own standalone story with a different cast of characters. I wanted the possibility of recurring characters and a shared universe, but at its core the system would be for unique characters in new situations. Using the tenets and this decision, I started thinking about mechanics.

Key Mechanics

Character Archetypes

A key feature of some of my favourite games, like Monster of the Week and Thirst Sword Lesbians is the use of playbooks. These are story-centred character plans that have a selection of abilities and motivations that help define a character's arc within a game. This is used as a guide for both the players on how to play their characters and how they might know each other and the game master on what situations to give the party. Considering the cinematic feel and group dynamic tenets, I decided a similar approach would be a good fit: each player would have a role to play in the story, but feel like being a part of a cohesive team.

I will not lie, I didn't do any research before diving in to create the Archetypes. I looked at the inspiration and thought on what roles are typical of heist plots I had seen in the past and added in aspects of different combat types that came up in action films. However, the problem this presented is that it clashed with the idea of running each session as a one-shot.

Whilst it is possible to improvise a one-shot game, typically they are an opportunity for a game master to plan an adventure carefully. If they have to account for every possible combination of Archetypes, the challenge of planning could be daunting. This is why in the game masters' section about planning the game, it is stated to decide which Archetypes will be allowed at the table. This takes away some of the players' agency, but hopefully ultimately allows the group to tell a more cohesive story. Whilst the beats of the story may be linear, the path to each one can be determined by the players, something that is encouraged as part of character creation.

The decision to give each Archetype a limited set of possible stats and abilities was made to speed up the character creation progress. If you only have an evening to play a game in and never see this character again, you don't necessarily want to spend hours flipping through lists of abilities and equipment. You still want your character to feel like yours though, hence the decision to give each Archetype two or three options for each element. The Businessman you play this game may be completely different to the one you play in a couple of games' time.

Character Creation

Character creation in Zombie Heist is an involved process. It takes place after the start of the game, when the heist has been outlined so that the players have an idea of what challenges they will need to overcome. Whilst the players' agency is reduced by the game master and the story, the number of stats and how they are divided up allows every player to have a different set of strengths and weaknesses, playing into the group dynamic tenet. Also, due to the requirement of a cinematic feel, character interaction is championed, with a large part of character creation being focused on working out how the characters know each other. This helps the players come up with interactions that they can have with each other, despite this most likely being the first and only time that they will play these characters together.

The idea of having a pre-existing relationship between the player characters is not a new one. It is included in Monster of the Week and Thirsty Sword Lesbians, but also in Free League games (ALIEN, Tales from the Loop, Things from the Flood), and is an excellent tool for what I like to term story-first games. These are typically tabletop RPGs where the focus isn't necessarily on who can do more damage and exact possitioning on a map, and more with telling a fun and interesting story as a group. I feel like Zombie Heist falls into this category, having an emphasis on social connection and describing cool scenes, but it fails in a few ways that I will discuss later.

Challenges and Thresholds

Whilst trying to decide how best to handle the random element of a tabletop game, I thought it would be fun to create my own set of dice rules. I considered a d20 system, but have thought that d6s are better for a while now. They are more recognisable, easy to source, and in my mind have a far more interesting probability curve. So I mashed together the threshold system of games like Dungeons & Dragons and the success system of Monster of the Week to create the system in the game today.

The idea of Zombie Heist's system is that it is incredibly easy to succeed at low-level challenge, but exponentially harder, maybe even impossible, to succeed at higher-level challenges. There may even be challenges that a character cannot complete due to not having a high enough stat. This was meant to convey the serious and scary atmosphere whilst also encouraging a cinematic feeling group dynamic that allowed certain characters to take the spotlight and have their moment whilst others took a breather. Needless to say, this didn't work the way I planned it, and I shall discuss this more later.

Share the Spotlight and Combat

The combat system of Zombie Heist has two of my favourite mechanics in it: Pass the Camera and Share the Spotlight.

When creating the combat system, I didn't want to use a generic turn-keeping method. I remember sitting at my desk with a stack of sticky notes and writing the obvious ones down: initiative order, going round the table, deciding order at the top of the round. None of these would do. So I thought, landing on Pass the Camera, a system where the turn order can change round-to-round depending on what the players want to do. From the start, I didn't want enemies to have a space on the turn order outside of special moves (large encounters especially can be slowed down by the game master having to manage the turns of enemies), meaning that if an enemy is attacked, they will most likely attack back on that turn. The result is combat made up of small vignettes where each character can do something and chain it with the next person or act on their own.

This worked excellently with the cinematic feel tenet, but didn't mesh well with the group dynamic tenet, especially with the emphasis on building relationships with other characters. So I developed Share the Spotlight, a move that any character can use that brings another character into their turn for an added affect based on their relationship. Combat encounters in my mind look like amazing sweeping camera shots that swing between characters showing how they work both alone and together in one continuous take. I feel that this translated into the mechanics, and hope others feel the same.

Coup de Gras and After Death

Death is a major part of any zombie movie. Even characters that we have followed for the entire runtime and have grown to like are not safe from the Grim Reaper. I wanted death in Zombie Heist to feel impactful and special. This would be the last time this character would be in play, their last time to take the spotlight, so it felt important to let them go out in style.

But this left a problem: If you die at the start of the game, why should you stay at the table? How could a dead character still influence the story? Enter the Horde. The Horde is a mechanic that allows players of dead characters to control a roaming group of enemies that has a chance to appear and attack the remaining party. The Horde Dice system is designed to encourage them to remain active at the table, ensuring that they have what they need to re-enter the story and cause mayhem (something that every TTRPG player I know loves).

In other tabletop RPGs, a character death either means creating a new character or sending the party after resources to bring that character back, neither of which are possible in a high-action one-shot where the game master needs to focus on the table and that has specific roles that should be filled. Joining the Horde offers the players a chance to keep playing even after their main presence at the table is gone.

Playtesting and Development

During the development of Zombie Heist, I was working full time, and after that went straight into my final year of University, not to mention the ongoing pandemic that made meeting up with people very risky. However, I managed to run a couple of playtest sessions. These were done with friends and strangers after the lockdown lifted, both at home and at a charity gaming event called Nerdvana. All the players involved in my playtesting and proofreading are thanked in the dedication to the finished product.

The playtests were mostly informal, with each player creating their character for a prewritten heist that I or another person had created. The rules were in flux and were actively edited at the table for balance, as I tried to find the rules that would be most fun. I ran two games, and then got to participate as a player when a friend ran a session, meaning I got to see both sides of the screen (these playtests are where the enigmatic Baron Teufel came from in the flavourtext). Getting to see how others read and ran my rules was an amazing experience, and massively helped the process of refining the rules.

One thing that never came up in the playtesting was the Horde mechanics. No characters died during the main story, meaning it never got tested, which is a shame, but means it reflects the majority of players' experiences. Most of the rules remained unchanged from the inital 10,000 word draft, with only minor changes. The biggest changes were the addition of the computer and safe enemies that standardised how hacker characters could get their moment in the spotlight and still be involved in combat. The final word count for Zombie Heist is over 15,000 words.

Once the rules were as polished as I could get them, I added the flavourtext and designed the front cover. The initial release of the book was created in Scribus, a free and open source layout editor, however it was difficult to use and the resulting book was not good to look at. Having completed my final year of University, I had fallen in love with LaTeX, a formatting language that allows you immense control over the layout and design of your documents. I converted the book into LaTeX documents and rereleased it as the version now available.

The Good Bits

Before we dive into the things that could be done better, I want to highlight the parts of this game I'm proud of. I am proud of the Archetypes and how they enable interesting casts of characters. The Pass the Camera mechanic creates interesting flows in combat and allows the players to work with each other how they see fit without slowing them down. The small amounts of worldbuilding within the book such as CORPS are some of my favourite that I have made. Finally, I am proud of it as I finished it.

Lessons Learned

Now that I've patted myself on the back, I want to discuss the parts that could have been done better.

Firstly, character creation. It takes too long. Due to the number of skills, how the dice system works, the relationships with other characters, how armour and equipment work, and the creation of a back up horde it can take hours to actually make a character if you use all the mechanics. I witnessed this three times, twice as a game master and once in the role as player. Even I got confused and missed things, because it got complicated. This stems from my decision to create a brand new system rather than falling back on an open system such as Blades in the Dark. The World of Darkness-like dot system can be difficult to describe quickly and the tier system of Novice, Adept, Professional, and Expert is unintuitive.

If I were to make a Zombie Heist 2, I would switch to something like Blades in the Dark with a much simpler stat system and a larger emphasis on Archetype moves and abilities. This would reduce the complexity of the system as a whole and also speed up character creation.

Secondly, the equipment is bad. The number of columns in each equipment table with all their attributes and bonuses is not worth the time, as they are all very similar. Add that to the health system which relies on stacking armour and tracking their bonuses separately to determine if you get hit or not and you end up with a mess of numbers that slows down character creation and combat as much as the Archetype system and Pass the Camera speed it up. It could work on a smaller, success-based system where each armour piece contributes 1 hit point and the possibility of getting hit is small, but when most of the enemies can easily surpass a player character's armour no matter what, it becomes confusing.

Finally, the biggest issue is with the dice system at the heart of the game. Dice play a huge role in the tabletop gaming experience. They add randomness to the mix and help determine what actions do and do not succeed. How a dice system works is how the game communicates its vibe. Games like Dungeons & Dragons use a threshold system where the probability of success revolves around getting greater than or equal to a given value. The probability for a this looks something like the graph below, where the x-axis is the threshold and the y-axis is the probability of success. The manipulation of success is done through applying modifiers to the roll, effectively moving the graph to the left or right depending on the bonus. For example, it is impossible to get total of 21 without at least a +1 modifier which makes it a 5% chance to get 21 and impossible to roll lower than a 2.

Other games like World of Darkness and Blades in the Dark use a success-based system. Let's take World of Darkness, which uses d10s and where 8, 9, or 10 are considered a success (ignoring critical successes and re-rolling 10s). In this scenario, I roll 5 dice (a small number in WoD, I've seen people roll 10 or more dice at a time). The probability of success decreases exponentially as the number of successes required goes up, until it's highly improbable at 5 successes. A system based on successes places much more tension in it's rolls, especially at higher probabilities.

Zombie Heist, a horror game with serious and scary atmosphere as one of its tenets, is more suited to a success-based system, and this showed in playtesting. The stories told were serious in setup but quickly became light-hearted romps with horror elements. The only truly scary enemies were the God Class zombies that showed up at the end of the session. Returning to the hypothetical Zombie Heist 2, I would make it a success-based system. This isn't to say that the light-hearted atmosphere isn't fun or good, but the aim was to be scary, with the players feeling helpless and that any wrong move could result in Game Over.

Below is a map of the probability of success based on how many dice are being rolled, with 1d6 in red (far left), 2d6 in black (center), and 3d6 in green (far left). The difference between these curves is huge and is incredibly biased in the favour of more skilled characters. This wouldn't be a problem in a game with progression, however, the action one-shot nature of Zombie Heist means that if the game master has created many of a single type of encounter, some players will get left behind, with their only moment of glory being during their specific task. When you're aim is to tell a story together, having players out of action will not end well.

Summary

In short, Zombie Heist was my first large project that I actually completed. It has some ideas that I think are good and create engaging games with fun stories, but has some glaring mechanical issues that can prevent players' enjoyment. Creating Zombie Heist,I made new friends through playtesting and learnt a lot about game design and publishing. Overall, I am glad I manically wrote 10,000 words in a week, but next time I'll hire an editor.