[As has been widely discussed, developing a successful indie title for Xbox Live Arcade is not the simple task it appears at first blush. Here, ex-EA developer Ahmed Usman Khalid candidly discusses the successes and difficulties that arose in the development of the somewhat overlooked Go! Go! Break Steady, a rhythm/puzzle hybrid game with hip-hop flair.]

Go! Go! Break Steady (referred to as GGBS henceforth) is a rhythm/puzzle hybrid game developed as an original IP by indie developer Little Boy Games for XBLA. Little Boy Games was founded by Ivan Tung and myself in August 2006. The two of us were the only engineers for this project. The rest of our in-house team consisted of one artist and two animators. The entire game was developed in Ivan's basement.

Ivan and I are both ex-employees of Electronic Arts. We both brought a fair bit of console development experience to the project but being such a small development team we had to wear multiple hats.

Ivan developed a Flash player for the Xbox 360, which served as our main game engine, and spent most of the development cycle being the principle game designer, art director, and CEO. I worked primarily on all the game-specific technology (gameplay, audio, online, systems and rendering) and was also responsible for tuning the gameplay.

Our initial imagination of GGBS was for it to be a break-dancing game using Flash. We would use a simple button press mechanism to trigger dance moves. We envisaged that we could bring in plenty of production quality to the game by doing custom rendering on the Xbox 360, but the goal was to have a simple gameplay mechanism and to make the game endearing to both gamers and non-gamers.

Initially, it was just the two of us plugging away at the technology. We got the first version of our Flash player running on the PC and then the Xbox 360 in record time.

Simultaneously, we started doing the systems work to get the game up and running on the 360. Over the next few months we brought in the artists/animators and then began our odyssey of iterating over the art and game design while at the same time building all the features to pass certification from Microsoft.

What Went Right

1. Squeezing in the characters.

Back in 2006, Microsoft had a strict size limitation on XBLA titles of 50MB. We, on the other hand, wanted to create a game which is content heavy and would rival today's XBLA titles in content while still meeting that technical requirement.

Figure 1: Early Days vs. Final Product

The two major consumers of our on-disk budget would be the character animations and music. We wanted the game to have six characters that would perform 20 to 30 moves and have at least 10 songs.

Our character animations if stored as vector art would account for under 10MB of disk size, but we discovered that using triangulation of vector art (and consequently anti-aliasing the art) took away from the art style we wanted to achieve. Using bitmaps for the character animation frames would blow our memory budget completely.

We scratched our heads for a day or two trying out different shader-based solutions to improve the look of our characters. Not until our lead animator, in a non-techie way, told us to "do what Flash does" did we started looking at run-time rasterization solutions. Basically, this would involve rasterizing the vector art at runtime into RAM -- of which we had a fair amount to spare.

We found a wonderful free, open-source solution in Anti Grain Geometry, which we ported to the 360. This allowed us to create perfect replicas of our vector geometry that did not need anti-aliasing and free up more of our GPU time to apply post-effects to our art.