Author: by Ahmed Usman Khalid

[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.

2. The audio trek.

As mentioned before, initially we had to deal with the size limitation on XBLA titles. Fitting in ten full songs at high quality even with Xbox-specific music encoding was a tall order for our overall memory budget.

To deal with this issue, we decided to create our audio engine based on a MIDI player concept. Since a lot of the hip-hop music is constructed out of loops, we could store the individual loops on disk and create the song at runtime using a metafile that described the playback time for each loop. We could then fit one song in under 2MB of disk space.

The problem with this solution was that it became a creative road block for our audio artist (a local band member we had contracted to create music for us). Consequently, this reduced the rate of production of songs creating a further roadblock for gameplay development.

Luckily, halfway through our production cycle Microsoft removed the limitation on size. We were then able to use licensed music, get it preprocessed and into the game in a decent amount of time.

This allowed us to find the collection of songs that provided the best gameplay experience and at the same time we increased our base count from 10 songs to 20.

3. No art without artists.

Very early on in the development of GGBS, we decided that we wanted a very unique hand-drawn, classical animation look for all our character animations and we wanted that to be very much the visual hook for the game.

Unfortunately, we completely had no notion of how much work such a technique would entail and how difficult a task it really is.

Initially, Craigslist was a great resource for us to find the artistic talent we wanted. We started off with two artists with no animation experience and asked them to work on the character design and the overall art vision of the game.

One of these artists introduced us to our audio artist, but otherwise we were getting nowhere with regards to getting an animated character to work in our game. At the same time we were desperate to get a demo out to Microsoft so we know one way or the other whether this game would be accepted for XBLA.

As luck would have it, we had found our lead animator who did all the character design and helped us recruit a second animator. Together they designed and animated our first character. Their drawings quite literally amounted to hundreds and hundreds of pages.

However, we learned quickly after the first character that the tracing and digitizing of the hand drawn images was a major bottleneck for the animators.

We then looked to outsource this task and found an art company in the Philippines that agreed to perform the tracing and digitizing work at a very decent price. We would scan the hand drawn frames and send it to them over the internet, and a few days later get back Flash files containing all those frames.

It still took over a year to complete all the character animations, but without the talented classical animators on our team and the out-sourcing initiative we would never have made it to the end.

4. Avoiding the game design black hole.

The first version of the game sent to Microsoft was purely a breakdancing game where you had to hit timed button combinations one after the other as you traversed down a move tree.

The game was brutally hard, and as the gameplay engineer I was the only one who could play it properly. The only people to play the game were our development team members and we never realized the flaws in our core gameplay mechanic. It is only when Microsoft's portfolio team and our product manager decided to give us feedback did we realize the state we were in.

While we had complete creative control on the game, we really gave their comments a lot of thought, as at that time it was the only way for us to break out of our tunnel vision. We decided to improve the button combination part of the game to be more like a rhythm game.

Figure 2: A Puzzling Move Tree?

Ivan then one day decided that we needed a more compelling hook for the gameplay and he had an epiphany to introduce a puzzle component to the game mechanic as opposed to the incessant move-after-move mechanic. When we prototyped that out, we realized that this would be the way forward. We sent another demo to Microsoft and they were onboard then to bring our game to XBLA.

The rest of the development cycle was spent trying to strengthen both the music and puzzle genres of the game and figure out a balance to the dificulty. We decided to take the game to Vancouver Film School,where their entire game design class played the game for two days while we looked at what worked and did not work for the game. This was the final breakthrough for the game design, and served as our benchmark for the tuning.

Figure 3: The Puzzle Evolution

5. Going online.

For the first half of our development cycle, we had just one development kit shared between the two engineers. When we started sending demos to Microsoft and they were more engaged with the game, we realized that online gameplay would be a must have component since the multiplayer component of the game was a lot of fun.

At that time, there were no rhythm-based games that provided an online gameplay experience, so it was a big challenge for a small company like ourselves to find a solution that would work.

During the initial months of development, our game-play seemed like in a constant state of flux. It was not until halfway through the development cycle that we decided to get a second development kit and figure out how to build the online game modes.

The key thing then was that our gameplay code was more stable and knowing that we would have to build online game modes later, the code was architected such that we could fill in the online related gaps.

The biggest breakthrough in this task happened when Microsoft released a light-weight library for building online components for XBLA games. Although there were some certification related quirks with this library, it greatly helped us by taking away a lot of the low-level connection, packet ordering, and packet delivery issues. We could then focus on building a compelling online gameplay experience and knock out all the super tricky de-synchronization bugs in the game.

What Went Wrong

1. When will this be done?

Self-funding the game, with no constant income, was a real trial for us in this development cycle. Initially, we thought GGBS would not take us longer than a year to make. But our ship deadline became more of ship "guideline".

The first thing we underestimated was the art effort required. As mentioned above, art alone took us over a year to complete. Next came the certification process. XBLA titles are subject to the same full certification requirements as AAA titles with tens of engineers. As we kept changing our gameplay well past our alpha and code complete milestones it took, us over six months to get the game fully certified.

Although we had a professional testing company put the game through its paces, we still failed certification once, as a critical bug somehow slipped through. This delayed our launch by a month and possibly hurt sales.

2. The hamster development.

It was absolutely necessary for a genre-merging, original title like GGBS to have a lot of gameplay and visual iteration to become compelling. However, as engineers and neophyte game designers it played havoc on our nerves. For one thing, it gave us a deep respect for the game producers out there.

As an engineer I always found it irksome when features I worked on so hard were cut or heavily modified. The burning question would be, "Why wasn't the feature fleshed out completely before it was built?" Having put on the production hat, it became clear why something intangible like fun can never be figured out on paper.

Nonetheless, it was a psychological struggle to continue to discard or re-work game features. It was especially expensive and gut-wrenching when we had to make changes very late in the development cycle.

All in all, developing a new IP with a unique game mechanic is not for the faint of heart.

Figure 4: What Looked Cool Kept Changing

3. Call in the refactorer.

The barrage of reworking of gameplay and the visual look of the game also made managing our codebase quite an ordeal. While the build-as-you-go technique meant the code and coders had to be flexible, at some point it became overwhelming.

Although we built a rendering test-bed to try out various visual elements, like new shaders or particle systems, we still ended up refactoring our main codebase over and over again. Unfortunately, a lot of the core architecture from various prototypes still lingered in the final codebase despite our refactoring efforts.

For instance, the initial move tree code was still intact, but the tree was now a linear list. Similarly, the puzzle evolved from its hastily written initial prototype. In retrospect, we could have reduced bugs, especially the very expensive online de-synchronization bugs, if we had refactored the puzzle code once we had finalized its behavior.

4. XBLA integration is no joke.

Despite having worked on a number of major titles and having experience with online-related certification issues, we underestimated their impact on our game.

We thought that having such a small front-end, and relying on Microsoft libraries for online features, we wouldn't need to build major architecture to handle things as invites, network disconnects, memory card ejections, score reporting to leaderboards and profile changes. This turned out to be a significant mistake, as the majority of our bugs were related to the aforementioned issues.

XBLA integration is a feature unto itself and requires a lot of dedicated development. Having slogged through all those issues for GGBS, it is absolutely clear that one has to carefully architect user interfaces and respond to the Xbox HUD properly in all areas of the game.

The critically painful issues happened during pre/post-game lobbies and when the game is loading up. There are too many edge cases to enumerate here, but to summarize we learned the hard way to give the XBLA integration features their due.

5. Marketing XBLA games as an indie.

What is hype? We completely underestimated the marketing effort required for a successful XBLA title. One of the most attractive reasons for us to develop for XBLA was that we wouldn't need a publisher or major marketing, as the game would always be available online and would be able to garner enough sales for us to make up our investment.

This might have been true when we first started developing for XBLA, as there were then fewer than 10 titles available. We, on the other hand, were the 150th title on XBLA, and we were released alongside a very popular remake of a classic arcade game. Going into our release, we had next to no hype and much to our chagrin very little post-release hype.

Researching this more, we realized that this seems to be the bane of all indie developers. Although we found someone to help us with the PR work close to the release date, in retrospect it would have been prudent to show more of the game earlier so consumers would at least recognize the name when they see it on XBLA.

Conclusion

In the making of GGBS, we encountered a ton of trials and tribulations. Developing a product from scratch and releasing it successfully to the mass market brings an amazing sense of accomplishment with it.

XBLA titles now have production qualities that rival previous-gen titles, and it swells our hearts with pride that with such limited resources, we were able to create a game that is fun and provides a one-of-a-kind gaming experience. Hopefully, it will find its way into the hearts of consumers too and we will have a truly happy ending.