Important note: This Dungeon Keeper game was actually cancelled before it was ever announced! Everything described here took place between December 2011 and sometime towards the end of 2012. When the DK project was cancelled, the IP was handed over to Mythic, which built the Dungeon Keeper Mobile game.
Back in late 2011, when KlickNation was being acquired by EA, I was pulled aside by KlickNation’s CEO/founder to spend a few weeks in a conference room with a few other folks coming up with new game pitches. The assignment was simple: Here’s a list of mostly inactive EA IPs that we could make games out of. Which ones could we make into games on Facebook?
The choice seemed pretty straightforward: Dungeon Keeper.
At the time, we were marveling at the success of Kixeye’s Backyard Monsters on Facebook, and Dungeon Keeper felt like a natural fit for the free-to-play tower defense/base building genre (not to mention its sense of humor was appealing!).
A Call to Arms
I was assigned the role of Combat System Designer. This would be my first full-time game design role since my time at Toys for Bob, and I was excited to jump in.
Step one was, of course, to play through Dungeon Keeper 2. DK2 is a fascinating game because it’s an RTS from a time when the genre was first getting popular but many of the conventions hadn’t been solidified. One of the unique design choices of the Dungeon Keeper series was that it was not a game about tactically micromanaging individual combat units; Instead, the player had some indirect ways to influence their various goblins, monsters, demons, etc. To control any unit directly, the player would need to cast a Possession spell, which would allow them to inhabit a specific creature (and remove the ability to control anything else), or use the Call to Arms spell to plant a flag that all units would try to reach.
It’s worth mentioning that Backyard Monsters and similar games did not allow direct unit control; Instead, the player would have an inventory of monsters they could summon at the edge of the map when attacking enemies, and each monster had specific behaviors and preferences for which types of buildings or defenses they would attack. This lack of direct unit control in comparable games also contributed to the feeling that Dungeon Keeper was a great match.
That being said, I felt that (in the tradition of KlickNation’s two flagship games) adding a bit of a genre twist would help our game stand apart and not feel like a shameless clone. My proposed solution: Turn the Call to Arms spell into the central control mechanic alongside the genre standards. This would not only add agency to the player in a general sense, it would also support navigating more complex dungeon layouts in a way that felt more true to the IP.
Prototyping Combat
At the recommendation of the game’s lead designer, I set about building a paper prototype of this RTS-lite combat system. This was a quick and relatively straightforward task: I drafted out a short list of units with different movement speeds and attack strengths, drew a dungeon into some graph paper, and moved the pieces a number of units per turn towards a Call to Arms flag location until they reached their destinations. With two players, one could move pieces as the player and another as the AI (since we were building for asynchronous multiplayer), and after a few hours of testing it was clear that:
- The Call to Arms system was feasible as a method of macro strategic control
- Doing this on paper was extremely tedious
The project would also need a prototype/demo to get a greenlight, so the next logical step was to assign a programmer and some artists to help build a decent-looking combat demo that could conceivably help the game get a greenlight.
I put together a list of assets and systems that would be needed for the prototype, and everyone got to work. In just a few weeks, we had the basics working: Summoning minions into a pre-made dungeon, setting their pathfinding target with the Call to Arms spell, and battling enemy minions.
Over the next month or so, we continued to refine the combat prototype. We added spells with a limited number of uses, so players could choose to blast down dungeon walls instead of navigating around them, and four different dungeon designs of increasing complexity.
Thanks to the sole programmer on the prototype (hi Dan!), everything about the units was configurable and the maps were easily editable. Because of this, most of my time was spent tweaking values, playing and replaying the prototype, and then recruiting coworkers to play it and provide feedback. I also eventually took over some of the programming on the prototype as the original programmer got pulled away to work on the main game, so I finished up bits of polish like popup damage numbers and other UI elements.
Eventually, the prototype was presented to some outside play-testers elsewhere within EA, and tested extraordinarily well for something with a lot of unfinished art and gameplay. The team got its greenlight!
Design During Full Production
Once the game had a greenlight, we moved onto full production.
I was able to complete a lot of design work that I am very happy about. With the rest of the team, we planned out:
- Four on-brand currencies and how they related to different buildings
- A complete build tree with 1 + 4 + 8 + 16 buildings, each with related themed unit unlocks
- Various traps and defensive towers
- All available units
Unfortunately, for reasons that I won’t get into publicly, the game was eventually canceled.
Fortunately, the studio’s next game, Heroes of Dragon Age, fared much better.