Gamesmithing: Follow Your Prototype

This gamesmithing article will differ in format a little bit. Instead of talking about a specific area of game development, I'll be presenting a case study on the entire game development process. This will be looking at the game Dwarven Depths, which was developed and released for the Xbox Live Indie Games platform in 2011. I recently ported the whole thing from XNA to MonoGame and put it up on itch.io as a Pay What You Want game. Go ahead and grab it for free - I see the PWYW as more of a way to enable donations rather than an expected thing.

When I was back in college, I was interested in making video games. Senior year I started a game development club, which was in reality just me and my friend Andy. We set a twenty-hour limit for ourselves and got to hacking away on a prototype. The inspiration for the game came from two places. First, I was heavily obsessed with Spelunky at the time. Second, I recently played a game called Miner Dig Deep. It was one of the best-selling games on the Xbox Live Indie Games platform, but I wasn't the biggest fan of it. I saw lots of potential but disagreed with some of the design decisions. It was more of a meditative experience, and I wanted more action. (For a more direct take on the Miner Dig Deep, the game Steamworld Dig successfully expanded on its formula.)

Dwarven Depths was first imagined as a competitive multiplayer game. Instead of slowly and carefully digging deeper for increasingly valuable gems, you'd be forced to rush headfirst into danger. If you are too cautious, you risk that your opponents will reach the best loot first. To add to the risk-vs-reward factor, we decided that the players would need to get back to the surface in order to 'bank' the gold that they've already found. Our thinking was that a player low on health would have to weigh their options. If they were down deep in the mines and wanted to stash their gold, they would have to spend quite a bit of time making their way back up to the surface. If they continued into the depths and fought dangerous monsters, they risked losing everything that they collected.

When a dwarf would die, they would drop all of the gold they collected on the ground. This was originally implemented as a way to dull the pain of dying. You might have messed up, but you'd have a chance to recover your gold. Of course, it didn't take long for us to realize the multiplayer implications. Other players can come and steal the gold that you've dropped. They could even encourage you to meet an untimely demise. This really changed the dynamic of the game. Before, it was more a competitive race for gold. We had PvP combat already implemented, but that was more for slowing down the opponent's progress. Afterward, it was about going for blood and filthy lucre.

At this point, Andy and I had a fun prototype on our hands. Andy wanted to focus on other things in his life, but I wanted to keep working on it. Even just making a prototype fun isn't guaranteed, and I wanted to see where I could go with it. Playtesting was invaluable, as it showed a couple of patterns. First, players would still go off at the start of the match and dig for gold as much as they could. Combat just wasn't worth it at the beginning of the match - everyone starts off broke and there's nothing to steal. Players would generally start mining their own tunnels and taking their own paths, since there was less competition when you aren't sharing a tunnel. This had the effect of creating a natural network of tunnels and multiple routes going downwards. Second, combat was much more valuable when players were coming back up from the depths. Their bags would be full of treasure, and they would hopefully be weakened already by fighting the monsters in the depths. Finally, there was only a brief window for attacking the player coming back to the surface. All dwarves move at the same speed. If a player got above you, it was hard to catch up and take them out. When you consider how wide some of the generated levels can be, this made it hard to successfully ambush someone on the way back up. If you were the murdered party, it made it even harder to take back what was rightfully yours. Dwarves had enough health to take several hits, and a player at full health could just rush past a waiting foe.

I had a fun and tense situation that I was aiming for - one player racing to get their money to safety while the others were trying to hunt them down. I saw a problem that was preventing that situation from happening. Other players would be too dispersed over the map to mount an effective defense against the surface-bound dwarf. What’s more, the fleeing dwarf had too much of an advantage. One or two mistakes by the ambushing dwarf would mean a clean getaway.

I tried out several solutions. One, for instance, was the ability to instantly die and respawn on the surface. If a treasure-laden dwarf got "ahead" of you on the way to the surface, you were given another chance to fight and steal treasure. This would cost you whatever gold you were carrying, but it meant an opportunity for even more riches. It kinda worked, but it didn't solve the underlying problem. The surface-bound dwarf could still just rush past you again. I needed a way to increase the 'surface area' or the 'contact time' of the combat.

What I eventually came up with was to allow players to place traps. These traps were varied in effect, from simple spike traps and arrows to caged monsters and beer tables. (Fact: dwarves can't resist beer.) Once placed, these traps would be initially invisible to the other players and would only reveal themselves once activated. These allowed a player to place traps all over chokepoints on the way back to the surface. Returning players would have to worry about unknown traps even when other players were offscreen and out of sight. This increased the tension factor on their way to the surface. If they knew about or suspected traps up ahead, they could dig out a side channel to get around the dangerous area, but this was trading time for safety. Ambushing players had more tools at their disposal and more time to try to murder each other. Even better, the meta game gets more complicated as players remember where traps are and figure out where they are likely to be.

It was a formula that worked. I sold roughly ten thousand copies of the Dwarven Depths, and reviews noted the great multiplayer action. Some reviewers compared it to Bomberman, others to a drunken Dig Dug brawl. The reviews were solid enough that I started working on an update.  I never released it until now, and it improved the game quite a bit. It included some obvious features (increasing the number of traps and enemies), but I want to talk a bit about my favorite inclusion: booby-trapped tunnels.

When the game is generating itself, it creates 8x8 blocks of tiles. The tiles are either empty or dirt. When these blocks are placed next to each other, the empty tiles create a network of tunnels and caverns for the player to explore. Since I had already done some explosion spritework for the new bomb and mine items, I thought I'd try making some of the of the dirt tiles explosive. After the tile blocks are generated, I would select random empty tiles all over the map. I'd make those empty tiles into explosive tiles. Then, I'd select an adjacent empty tile and repeat a set number of times (or until there is no more empty tiles nearby). This would usually fill up a tunnel or a good part of a cavern. If a player strikes an explosive tile with a pickaxe or another explosion, a brief warning flashes and then that tile and all the connected explosive tiles blow up.

Digging is a very fundamental part of the game - that and 'jump' are the movement verbs. Adding in this twist really increased the fun of digging. You had to pay more attention, as quick reflexes could save you from a fiery death. It added some needed-variety to a previously neglected part of the game. After the dust settled from the explosion, it often opened up a new tunnel. The new tunnel might lead to a room full of treasure, or it might be a shortcut to the player's destination... or it might not. The player has to reevaluate the playing field - a good way to keep them on their toes.

Looking over the whole development cycle, I could draw out some lessons. First, prototypes are for finding the fun. If your prototype is interesting but not fun (I've made plenty of those), it's failed as a prototype. Once you have a fun situation, you should work your game design and thinking around that. What can you do to make the fun happen more often? What creates variety around that bit of fun? What mechanics would offer depth? Don't be afraid to try things, especially at the prototype phase. But make sure you playtest, early and often. Playtesting reveals patterns and currents in your game that you would otherwise be unaware of. Finally, focus on the fundamentals of the game. If there is a verb that players are using a lot, look at what you can do to 'spice up' that action and make that verb more interesting.