Dungeon Highway – An Exercise in Validated Fun

This second post about Dungeon Highway, a game I worked on with Mike Judge, was originally published on the Substantial blog here.

Creating a videogame, as with all software, takes time. Polishing a playable experience can take months, if not years, for a complex game. There is often a temptation in software to delay release until the product is “finished” (read: until the game has everything the creators think are necessary for it to be as fun as possible). But how do you know it’s fun enough?

One of the things we do on every project here at Substantial is validate assumptions. Dungeon Highway was no different. In order to most efficiently build a game, we decided to get it in front of players as quickly as possible. If enough people liked it, then we’d know we had something worth building upon. Here are a few things we did to get the game out the door as fast as we could:

Setting Deadlines

The first thing we did on Dungeon Highway was to decide how much time we were giving ourselves before we were “finished” with the project. We arbitrarily picked two weeks as our deadline, and we (somewhat surprisingly) held ourselves to it! We stuck to our self-imposed target, limited scope, and did not add any more features after we were done with our initial timeframe.

Using Existing Tools

Learning new technologies can often slow down a project’s development pace. Mike and I had already been working with Unity3D for the past couple of months, so it was a no-brainer to use tech we were already familiar with. Learning a new stack is good and fun, but is often times not the right decision for a project on a very short deadline.

Another tool we used to help speed us up was NGUI, a UI library for Unity3D. Based on our previous experience, user interfaces that look good in multiple screen resolutions are pretty difficult to build in Unity. Using NGUI easily cut our UI building time in half.

Short Experimentation Cycles

With such a short deadline, we didn’t have the luxury of working through large, complex features. Instead, we settled on a two-day experimentation cycle, in which we would spend two days building a just a few small features, decide which ones were fun (with input from folks in the office), and then decide what to do next, whether that was to cut, refine, or call a feature complete.

Cutting Features

We were ruthless at removing features we felt did not value to the game. With every addition, we evaluated how much it added to the experience. For example, when testing out different kinds of fireballs, we built multiple little prototypes to play with for a bit, deciding how much fun each variant was. Sometimes they made us laugh and we would keep them. Other times they would make the game too easy, and we would move on to the next idea.

Here are some of the features we tested but cut in the end:

Ramps and jumping

Armor

Experience / leveling up

Random shotgun spread

Lances

Hit point bars

Bird’s eye camera power-up

Speed up power-up

Auto-firing fireballs

Enemies that seek out the player

Enemies of various sizes and health

Closing Thoughts

Working on Dungeon Highway has been a lot of fun. Our short development cycle and tight deadline allowed us to experiment with a lot of different things but kept us realistic about what we could finish in our short timeline. It also ensured we could get feedback from players as soon as possible, keeping us on track to build a successful game by maximizing fun at every step. We’ve been floored by the reception Dungeon Highway’s had in the world (#3 in Mongolia’s featured list!), and we think the way we built the game is a large factor in its success. Let the games begin!