Posted on May 22, 2009 | 0 comments

I’ve wanted to write a proper postmortem for Audiball for some time now and I’ve been putting it off for far too long. Below, I try to summarize six months of my life into a few pages of text. Audiball was not a commercial success, nor was it groundbreaking in any way, but it was my experience with game development and I’ll always be proud of it. Read on if you’re interested in the game’s original vision, what sacrifices were made, what unexpected events changed development, how the game’s soundtrack was composed, how you can learn from my mistakes, and how an announcement trailer can be the longest fifty seconds of your life.

Background

Before starting development on Audiball, I was hooked on Jonathan Mak’s Everyday Shooter. Of course he’s already credited in the game for inspiration. It did a great job of using non-traditional sound effects in each level to blend with the game’s soundtrack. Each level used a different set of sound effects for shooting, explosions, combos, and just about everything else. It’s really what made the game exceptional as opposed to, well, your everyday shooter.

At the same time, I was playing quite a bit of Rock Band with my roommates. The speakers on our TV blew out while we were in the middle of a difficult song, and while the guitarists and drummer were able to continue without a problem until it came back on, the singer promptly failed out. I guess I had never really considered that Rock Band is just a test of muscle memory. It’s why Guitar Hero is able to take away all the colors of the frets and players still know which buttons to push: the colors are irrelevant once you know where they are, it’s only the positions that matter.

It was then that I got curious about the idea of focusing on the colors of the frets rather than their positions. It would be a completely different way of using the guitar controller. Of course, that also meant that no skills would carry over from any other guitar game. Playing Audiball for the first time would be similar to playing Guitar Hero for the first time; the guitar controller would be a new controller all over again. Then came the challenge of trying to make it “fun” as opposed to “unintuitive.”

Rock Band doesn’t lets you play music much in the way that you play a game, but you don’t produce music or influence it in any way other than “off’ or “on” when you miss or hit notes. I wanted to explore making something that was “the opposite of Guitar Hero” in that multiple aspects of the player’s performance would determine what they heard coming out of the speakers. I didn’t want to try to make a music composition program for a guitar controller because I didn’t see how that could be fun – of course, Guitar Hero World Tour ended up doing it later that year anyways. Instead, I tried to let the player work towards a visible goal (the gameplay) while using the sound intensity to reflect their progress towards that goal (the  reward).

Initial Design (March-April 2008)

The game was initially drafted on a giant whiteboard in our residence hall in spring of 2008 – one of the few resources we actually did use from Georgia Tech. We had just gotten back from the Game Developer’s Conference and were itching to get to work. We dubbed it “SoundOff” as a production name. The idea was to create a game where the player had to get a number of balls from one side of a level to another. Every time the player strummed, a ball would launch from a cannon. It would collide with different colored “enviromods” (environment modifiers) that would do various things to change its trajectory.

Some enviromods would act as a spring, some would act as a cannon, some would teleport the ball from one place to another, etc. It might sound somewhat similar to the final product, but wasn’t envisioned to play anything like it. The player only strummed to launch balls from the starting cannon. Gravity existed on every level, so the trajectories of the balls were never straight. It actually shared a number of similarities with the barrel levels from the Donkey Kong Country series. To activate an enviromod, the player simply had to hold down its fret while the ball passed through it.

Sound was only played when the player successfully activated an enviromod. I thought that I would be able to compose sound clips that could play concurrently and design levels that made sure these clips were played in a particular order. This was a mistake for a number of reasons, the biggest one being that designing the level to sound a certain way completely defeated the point of procedural music.

The HUD changed quite a bit throughout development. The first design for the game called for a Guitar Hero-esque panel that would show the balls as they approached the circles on the screen. Before it was even coded, I realized that although it would make it easier for people to play, they would completely ignore the rest of the game and it would be reduced to a fancy visualization. It was decided that the entire screen would be the game’s main area, and we would try to stay as far away from Guitar Hero references as possible so as to avoid the notion that we were “competing” with it. Suddenly, the game itself was a lot more difficult to grasp because the player no longer had anything familiar to ease them into playing.

Final Design (September-October 2008)

In its most basic form, we realized that the game was nearly impossible to play when the user had to keep track of multiple balls at once. Even when the user only had to press frets to activate them (with no strumming involved) there were balls flying out of control everywhere with no method to the madness other than mashing buttons. It certainly wasn’t fun. So we had to figure out a way of controlling the gameplay without necessarily slowing it down. I came up with the idea of using timers to pause between collisions, and once it was prototyped in a few different ways we settled on each ball having its own timer rather than the enviromods having a limit for all the balls inside them at once.

This ended up being one of the core elements of how the game plays. The timers give the player between three and five seconds to (1) notice that an enviromod needs to be activated, (2) find the corresponding fret on the neck of the guitar, and (3) strum to launch the ball in their desired direction. This sequence is the best representation of what I intended Audiball to do as a rhythm game. No matter how a level was designed, every solution resulted in a rhythm created by the player, and players had to keep that rhythm constant to successfully pass a level within the time limits.

After the Guitar Hero HUD with the sidebar came a design styled after a media player. The pause menu was designed around this time too. Although the pause menu’s look in this stage remained intact in the final version, the rest of the HUD changed dramatically. There were far too many numbers on the screen at any given time, and it was too distracting for a game that plays as frantically as it does.  One thing that did stick from this iteration of the HUD, however, is the word “audiball.”

The word “enviromod,” on the other hand, was never meant to be a final name, and we needed a way of describing it in a way that made sense to players – a task I failed miserably in my final implementation. “Enviromods” were retitled “sounds,” and each color of “sounds” corresponding to the fret buttons were called “sound sets.” Players strummed to “activate sounds” when an audiball was inside them. This could have been described much more clearly as “get all the balls to the goal,” but it wasn’t exciting enough to use in marketing the game to potential players. The look of the enviromods changed at this point too, moving to a minimalist style so that the waveform ripples of each sound would be the focus of the game’s look. The minimalist look of the game ended up being a bad idea in the end too – it didn’t have enough production value to come off as “polished and minimalist” as much as it did “rushed and basic.”

For the Independent Games Festival we had hoped to submit a 10 level demo. We ended up with four, two of which were scrapped from the final game. There was only one audio track finished at that point too, and it was set to all four levels. Obviously we didn’t get anywhere in IGF – our judges summary a few months later revealed that we were praised for innovation and docked for audio, consistent with our opinion of what we submitted.

The other 13 levels in the game came together over the next three weeks. Two levels were completed two days before release. We worked right up until the wire to get it out. When we weren’t working, we were watching people playtest. I loved watching people playing the game because everyone approached it in a different way. Players being confused and not knowing how to play was the game’s biggest problem (one that could have been solved with the inclusion of a tutorial) but at the same time it was refreshing to see experienced gamers pick it up as if it was the first game they had ever played. Everyone was on equal ground. I recall my roommate’s girlfriend passing a set of levels only for him to fail miserably minutes later – my roommate being the hardcore gamer of the two. Feedback showed that the game was fresh and fun to play, and we couldn’t have hoped for more in our first project.

Music Composition (October-November 2008)

Audiball was my first experience with program music. I had written things for fun before, but giving it a purpose turned out to be a compeltely different challenge. More challenging was that it was my first attempt at procedural music. The final soundtrack ended up being more “guided” than procedural due to a combination of technical limitations and lack of compositional skill, but nonetheless I enjoyed writing it.

Each song was made up of a series of sound clips that were played on top of each other. Some songs had as few as 6 different clips, others had as many as 20. Getting it composed and split up was only part of the battle: getting it into Microsoft’s less-than-perfect XACT architecture was agonizingly difficult. I created target renders of what I thought the tracks should sound like, and then we tried to mix and match them in the game to make them sound similar. For example, here’s what the flow sheet looked like for the “Fast Techno” track:

You can download the entire soundtrack on my Audiball page if you care to give it a listen.

The game’s official trailer was made in two days – one day of music composition, and a second day of recording and putting the video together. When I say two days, I actually mean the full 48 hours. It’s a lot of work to make a game look good. The trailer ended its run with a 6 / 10 score on GameTrailers with most people criticizing the graphics, but intrigued by the concept. We were happy about the intrigue, and tolerant of the criticism. The game’s visual style just didn’t come across as well as we had hoped.

Conclusion

Audiball was a fun first project that had a lot of promise in concept but was seriously flawed in execution. Fortunately, the flaws weren’t enough to prevent it from being a fun game. Anyone who played it for more than 10 minutes could figure it out, and most of those who did enjoyed it. We didn’t anticipate players to give up after failing just once and putting it down in two or three minutes. The game’s concept was probably far too unique and challenging for us to tackle as our first project, but I’m still happy with how it turned out.

So many of the problems with the game could have been fixed with just a little more development time. It’s aggravating to see how we spent months working on a game and just fell short of creating a complete package. Better production values would have gone a long way to make it an exceptional game for what it is. It may not have sold significantly better, but it would have felt much more professional as a whole. As an indie company, we had no reason to give ourselves an arbitrary deadline. We’ve learned to never compromise the quality of a product for the sake of getting it released. It’s better to take an extra five months than to have regrets.

I hope this write-up adequately illustrates the game’s design process for all who have interest, and I sincerely hope that other bedroom developers out there can benefit from it. Feel free to shoot me an email if you have any more questions about the game, and check it out on Xbox Live Indie Games if you haven’t already – it’s still available for download, and should be as long as the service is running.