[In this comprehensive postmortem, former Volition developer Luke Schneider talks about how he went indie and assaulted the Xbox Live Indie Games market with an array of games built on the same ideal -- and how each worked, as well as the fate of the overall project.]

I had worked at Outrage Games for five and a half years when it closed in July 2003. Because my wife and I had bought a great house two weeks earlier, we had a choice to make: I could start looking for another games industry job out of state, or I could try to turn a Game Boy Advance prototype I'd been playing with into a full-fledged game. Making a game by myself was a challenge I couldn't resist, so I chose the latter.

The game was completed in a few months, but finding a publisher was a more difficult and demoralizing process than I expected, and a half-completed Xbox port fared no better. So I made the move to Volition in 2004. Though my six years at Volition were enjoyable, the desire for control over my destiny eventually overwhelmed my need for stability. In early 2010, I left Volition to form Radiangames.

When considering the development options for Radiangames, I felt a strong urge to do the opposite of what I'd been doing recently. Instead of taking five years to make one game, I thought it'd be cool to make five -- or more -- games in one year.

My plan was simple: I would create a monthly series of arcade-style games for Xbox Live Indie Games. I'd seen Halfbrick and Arkedo, two small independent studios, do their own series on XBLIG, and I admired the Pixeljunk series on PSN. I also knew that the XNA tools and focused development on a single platform would make it easier to achieve my goals.

Eleven months later, I completed the seventh and final game in the series, with the last five being released in consecutive months. The titles in release order: JoyJoy, Crossfire, Inferno, Fluid, Fireball, Crossfire 2, and Ballistic. Even though I've moved on to a more traditional indie route (larger games, more hype, publisher support, and a higher price) it was still an invaluable experience and an accomplishment to be proud of.

Throughout the article are interspersed "what went right"s and "what went wrong"s from each of the games in the series.

What Went Right

1. Scope Control

Large games take more time to make than small ones. Good games usually take longer than bad ones. So the number one priority in deciding which game ideas to work on: scope. It's amazingly hard to keep a game simple and not to turn it into something epic, so the smaller and more focused the original idea, the better.

With the Radiangames series, the struggle between keeping the games small and making them good was never-ending. I always started small with my ideas, then spent the rest of the time trying to make it good. That invariably required adding more to the core concept, or changing the core concept to be something bigger, but in the end it worked out.

To help keep focused, I avoided hard technical problems whenever possible. The games were all 2D and had no online multiplayer. With development on a single platform, I was also able to limit the games to one resolution (1280 x 720) and a fixed-step framerate.

Applying good scope control also meant choosing game concepts that could build off the elements and ideas in previous games. Every time I started a new game, I'd make a copy of the project it most closely resembled and build from there. Though I didn't have a singular engine I was building, keeping a similar game structure (with improvements only where absolutely necessary) meant I could focus more on game design and less on game code.

In the end, sticking to my original plan of creating simpler games was the main reason I was able to release so many quality games in a short timespan.

Right or Wrong: JoyJoy

Right: Safe Design. Being the first game in the series, I went for a safe core design with JoyJoy to reduce risk and focus on getting the game done quickly. The safe design also allowed me to work harder on writing code that was solid and re-usable. Though there were a few major improvements made in subsequent games, the basic code structure was used throughout the series.

2. Playtesting

Playtesting doesn't make a game great by itself, but it essentially guarantees your game will be enjoyed by more people than it would have otherwise.

With the Radiangames series, I employed a simple but effective two-pronged approach to playtesting: I would occasionally get a few new players to play the game while I observed, and I would send builds to other XBLIG developers for feedback. There's nothing unique about this approach, but I found the two methods combined to be effective at catching a wide range of issues.

The other half of playtesting is listening to the feedback and figuring out what to do with it. My experience with retail games made it much easier to deal with any negative or confusing feedback.

As most of the playtesting comments went directly against scope control or were painful to hear, I'd take a little time to contemplate the best way to respond or address the issues rather than reacting defensively. Usually I'd end up agreeing that something had to be done to make the game better, and that's what playtesting is for.