One common problem shared by most indie game developers is an obsession with game ideas that are bigger than we can execute. Even the most realistic indie has to beat back the little voice in his head that keeps telling him to go bigger and (presumably) better. It’s great to have big ideas, but we need to make sure we bite off only the pieces we can chew. Rather than give up on our grand ideas, we need to break them down into smaller easier to execute pieces in a process I call recursive development.

In the last 14 months, I’ve employed recursive development on one big Urbansquall project, and actively chosen not to use it on another. One of these turned out to be a resounding success that is already set to be Urbansquall’s most successful game series, the other was a financial catastrophe that almost torpedoed the whole company. I spent a fortune confirming the validity of this approach and one of my greatest regrets was ignoring my gut instinct, and not utilizing recursive development to control the scope of the project that failed. I will not make that mistake again.

What is recursive development?

The core premise is that any large game is really just a combination of smaller medium sized games and that any medium game is in turn a combination of several smaller sized games. Recursive development describes the process where we take our grandiose game design and chop it into smaller games that we can develop and release individually, with the goal of working towards our final epic vision.

Why does this work?

Except for some very specific exceptions, the whole is rarely greater than the sum of its parts. In fact, a lot of the time, the majority of these component parts are not only unnecessary, they also damage the quality of the overall product by spreading our limited resources too thin. A development methodology that focuses on each part rigorously proving its worth as a standalone component results in a stronger final product that is cheaper and faster to develop, and is done so at lower risk.

While this doesn’t really apply to small single-concept games, it definitely applies in cases where adding additional features requires massive code changes (like adding multiplayer for example).

How have I applied and failed to apply this methodology?

Zombieland

The original concept was a cooperative multiplayer RPG survival zombie shooter game. I started by making a simple side scrolling zombie shooter. That was released as Zombieland: Bonesnap Boulevard. I never got passed this stage, but theoretically the next step would have added the RPG elements and the large, interactive world. From there would have been the persistent back-end and high scores and that was probably sufficient to release a new game. Then I could have finally added the cooperative multiplayer.

Recursive development worked here because it kept the development costs low. I didn’t have to do any multiplayer, RPG elements or back-end storage for the first pass, which also significantly shortened the time to market (approximately 5 weeks). I collected a check for this first release (it wasn’t a lot, but it allowed me to put some money in my pocket). It really lowered the risk by completely removing the need to find a distribution partner (or try self-distribute, which would have been a failure) – a necessary prerequisite for a multiplayer game. Plus, it let me fail (and fail cheaply) on a few key design choices (which ultimately stifled the game’s popularity).

End result? I screwed up. Made a little money. Built some useful AS3 classes that got reused on several projects following it.

Battalion

The first Battalion was a multiplayer-only game that took about 11 months to build, which, at an hourly minimum wage, meant that the net profit was negative. Very very negative.

I wanted to do a multiplayer sequel to that game (madness, I know). None of the code was reusable because of several features desired in the sequel and because of scale concerns with the original code base. Instead of going for broke, I designed the multiplayer game and then worked backwards until I had just enough elements to make a compelling singleplayer experience. That resulted ultimately in the release of Battalion:Nemesis, which Kongregate really liked and signed on to help fund and distribute two sequels and the multiplayer game.

End result? 2009 looks to be a banner year for Urbansquall with the sequel set to launch on my favorite Flash portal. I’ve made some money and got a game out there in the wild.

Discarded

I could write a book about Discarded. Indeed, several posts in the next few months will go over some of the tragic mistakes that were made that ultimately crippled that project. The biggest mistake I personally made was ignoring my instinct and deciding not to follow the recursive development methodology on the project (I ended up using “Release Early, Release Often”, which is a catastrophic mistake in game development, it turns out). Discarded is a multiplayer side scrolling collectible card game beat em up RPG. If it’s not obvious how many ways Discarded could have instead been a collection of smaller self-contained games, then you probably haven’t been paying attention.

End result? So much time was spent on all the other aspects of the game that the core gameplay was ill conceived and badly implemented. Many design decisions had to be redone several times (expensive) because everyone’s focus was elsewhere. No feature of the game really ever hit 1.0, and the game was a financial failure of epic proportions. If we had instead focused on a smaller game, a side scrolling singleplayer beat ‘em up, not only would it have been cheaper, we would have finished something and at least pulled down some sort of income in the form of a sponsorship. It would have been better for morale. It would have been less effort. It would have been much lower risk. The list really goes on and on.

Conclusion

It’s great to dream big. When you have an awesome concept for an epic game you want to make, consider that just the starting point of your design work. From there, break the game apart. Try to discover each gem of fun gameplay that can be extracted and be built into a separate game by itself. Do this for every aspect of the game. Now build each of the component games. You’ll be releasing smaller games, on a quicker schedule, all the while slowly building towards your ultimate goal. Instead of working towards one epic and overwhelming release target, give yourself the opportunity to have lots of small successes (and failures!) along the way. The components that survive the process will be the ones that are truly worth integrating into your grand vision. You’ll make more money, reduce your overall risk, and create better games in the process.