Dead State Postmortem

Brian Mitsoda has penned a Gamasutra postmortem article for his first indie RPG, Dead State, developed with the folks at DoubleBear Productions. The article focuses on the workflow, development practices and decisions adopted by the team and goes over what worked and what didn’t work about them.

A snippet on what went right:

4. Core Design Did Not Need Major Revisions

From the beginning of the game, our design revolved around a few key (identified risk) design concepts: Our (Noise) system, which attracted zombies or enemies to your party’s position; the Shelter, which involved the management and job system; and the Crisis Event system, which dealt with systemic Morale and character events.

If the Noise system hadn’t worked, our combat would have been a lot less exciting, and the zombie apocalypse feel of the game would have been lost. If Shelter management had been less appealing or if the GUI was too complex, it would have made a large portion of the game unappealing. If the Crisis Event system hadn’t worked, it would have taken away one of our more interesting story systems and given the sub-leader charaters less presence in the Shelter.

Fortunately, aside from a few tweaks, we did not have to scrap or completely redesign any major systems in the game, and Early Access feedback on the core gameplay was about on par with what we were hoping. If the feedback had been mostly negative for these systems, we would have had to have done major course correction. Not having to gut and rework major systems in the game saved us a lot of time and effort. Being careful about iteration and implementation of risky design elements up-front was a good idea.

And one on what went wrong:

5. Too Many Characters

When we first developed Dead State, we wanted to make sure we had a large enough cast to make anyone expendable in the field. We shot high to make sure that players would have a large number of allies to present overlap in skillsets and to provide a lot of the dramatic conflicts that take place in the Shelter.

This meant that each ally not only had to have their normal Shelter dialogue, but their intro dialogue, dialogue based on their mood, conflict with other allies, (quest) dialogue, reactive event dialogue, random event dialogue, and so on. And even with all of this dialogue, the player may only see a fraction of it, depending on what they did with each ally.

There are over 45 allies in the game, with 6 to 30 branching dialogues for each ally. The amount of dialogue added up quickly and took a lot of time to write, script, and revise, especially when it was done by two designers that also had to oversee other systems.

The biggest problem stemmed from our allies being around the shelter for a period of up to 85+ days of game time. There was definitely a player (and reviewer) expectation that the allies should have had dialogue refreshed nearly every day, or that they should have as much to say as companions in other RPGs. However, most RPGs spread their companion dialogue and reactivity over 8-10 companions or non-playable characters, and update it in stages according to a set of linear plot points (another thing that Dead State, by and large, happened to avoid).

By the end, Dead State was already pushing the 15,000 line count with our massive cast, and that’s not even counting combat/reactive barks. While I think we did a great job making the allies diverse and as interesting as we could for their screen time, I can honestly say I would never recommend anyone attempt to have 45+ companions in your game unless it’s going to be a very short game.