This article covers the design and development process of a shipping one-button mobile game - EA Air Hockey, which was released in the first half of 2006. This is not so much a post mortem as it is a dissection of the game. I was the designer and lead coder on this game, and I've taken the opportunity here to go into some detail about how the design evolved and how various technical and playability problems were addressed. Hopefully this will prove interesting or perhaps even useful for others who are tackling the same sort of design challenges.
Acknowledgements
Before embarking on a detailed discussion of EA Air Hockey, I want to acknowledge the valuable input and guidance I received from key people at EA Mobile (then Jamdat). First, credit goes to Zack Norman for signing the game in the first place, for his valuable input and suggestions throughout development, and mostly for coming up with the idea of doing an Air Hockey game. Next, credit goes to Travis Boatman, again for his valuable input through development and for his help with project administration (and for giving permission for me to publish this!). And last, but by no means least, credit goes to Adam Schwenk - my long-suffering producer who put up with all the stuff that producers have to put up with.
What is ‘Air Hockey'?
Some people know the game as shuffle puck, table hockey, shuffle board, and no doubt other name variations. Air Hockey is the game where two players each use a disc shaped "mallet" (or "hammer") to hit a "puck" around a table. The table has a perforated surface through which air is blown by a fan - the air provides a cushion for the puck, which literally floats around the table due to the reduced friction. Each player defends a "goal", which is simply a slot which is several puck-widths wide, and basically the first player to score 7 goals wins.
EA Air Hockey
Why one-button?
The primary reason to develop a one-button game for a mobile phone is one of simple practicality: the keypads on most mobile phones are not really very good for playing games on. The trend with phones is always smaller, slimmer, flatter - and of course much of the "size" of a phone device comes from the keypad itself. Keypads are designed to look cool (e.g. RAZR), and so that you can dial a number and (maybe) text a message. Expecting anything much more than that is a luxury for many of the phones out there. Requiring only one button really nullifies this concern - no scrambling to find the right key.
The other compelling reason to create a one-button game is to appeal to the so-called "casual" gamers and the non-gamers (the "to be converted") as it's these folks who makeup the vast majority of "mobile phone users". A game that is playable with one button should contain little to scare away or embarrass such a player. I wanted to make a game that the salesperson in the cellphone store could just hand to any customer and say, "just press the OK button to play".
One-button design
So, I wanted to make a game that would work on any phone on which the following statements are true:
- Program code can detect that a single key is ‘pressed'.
- Program code can detect that a single key is ‘held'.
- Program code can detect that a single key is ‘released'.
Thus, the game design I had in mind had to allow the player to control the entire game using just a single key, and where 100% of player input would resolve to pressing, holding and releasing a single button.
Now at this point, some readers will have no doubt noted that there are already games like this for mobile, and there have been for some time. In fact, some of the most successful mobile games ever already use such a system - Jamdat Bowling for example. So where's the innovation with what I had in mind? Well, the big difference is this: what I wanted to do was a "real time" game - one that is not quantized into "strength, aim, spin, watch" slices. Rather, I wanted to apply a single-button control dynamic to a game that runs in real time, and which at no time pauses to allow the player to set a strength-gauge, or an aim-meter, or anything like that. The goal was to create a fluid, controllable "action" game where the only control available to the player was a single button.
So, here's what I came up with. I am going to cover the design in terms of the primary challenges encountered, by detailing the solution to each challenge.
