[In Gamasutra's first postmortem of an iPad game, two members of the team at Magnin & Associates, a veteran developer of portable games such as Prince Of Persia for Game Boy Color, discuss the difficulties and surprising benefits of developing Skittleball for Apple's new platform.]

We based our design of Skittleball loosely on the British game of Skittles, only using a ball instead of a spinning top to make it less random and more interactive. The player tilts the iPhone or iPad to roll a ball through a series of rooms, avoiding the black holes, while trying to knock all the pins down in order, in the fastest possible time.

Our main design goal was to take advantage of the excellent 3D graphics capability of the iPhone along with the built-in accelerometer to make unique game play for players of all ages.

We decided to offer two very different gameplay modes: in the top-down view you keep the device parallel to the floor and lean it slightly to make the ball roll (similar to Labyrinth). In landscape view, you hold the device parallel to the wall, and lean the top edge away from you to go faster and lean it to the left or right to steer (like a racing game).

During development we decided to let the player switch between them at any time by just tilting the device in the new orientation.

This product had been in development since late October for the iPhone. A couple of weeks before its release Apple sent us an email saying that if we submitted by March 27 at 5 PM, it would be considered as a launch title for the grand opening of the new iPad App Store when the iPad went on sale on April 3. Naturally, with the game more than 90 percent complete, we decided to quickly adapt it for the iPad.

Our dev team has a wide range of experience -- from recent college game programming grads to 30-plus years in the industry. Magnin & Associates has specialized in handheld platforms since its inception in 1993, but had just switched over to iPhone development in the past year. At the start of this project we had a couple of previous games in the App Store, with an additional free version.

We decided to write our own game engine this time, although we had reviewed a number of excellent candidates. It was our feeling that we would learn more, have more control over the source code, and hopefully have a competitive edge as we move forward with additional projects. (A second game was started slightly after this one, also using the same engine.)

We used OpenGL ES for our 3D rendering and OpenAL for audio. We relied heavily on Apple's sample code for examples on how to communicate with the hardware. During development we learned some of the nuances of Objective C.

While there are now lots of books on how to develop an app for the iPhone, and even a few on developing games, very few if any mention 3D or OpenGL ES. And the books on OpenGL ES are not necessarily specific to the iPhone.

As a game developer with two previously-developed 3D games on the Nintendo DS, we wanted to do the kind of quality 3D project we thought we were capable of.

What Went Right

Very often in game development, the things you think are going to be easy turn out to be much harder than expected, and the things you thought were going to be hard turn out to be easier than you thought. The following problems turned out to pleasantly surprise us:

1. Sound

We needed to implement sound in a way where we could get the best quality with using as little space as possible. To accomplish this we used wav files for the sound effects and MP3s for the songs.

We decided to mix some of Apple's base sound framework with OpenAL to get the best out of both the effects and music. We were able to have our sound manager up and running in under a week. This included the ability to modify volume and pitch on the fly. We were all surprised with how well it worked and how fast it was to implement.

2. iPad and the simulator

Programming for a new product is hard, but programming on a product you don't have yet -- precluding real-world testing -- can prove to be even more of a challenge. We wrote most of the game with the intent of making it an iPhone/iPod Touch game, but when we got near the end of production and saw that we had a chance to get in on the opening of the iPad store, we made a push to make the changes needed to make it an iPad game.

When it came down to testing the changes, all we could do to see the changes was to use the iPad simulator to try and test as best we could. While we could adjust for the new larger screen size, we could not actually play the game since the simulator does not simulate the accelerometer.

In the end, it turns out the simulator was enough to help us get all the changes we needed in on time. When we went to pick up our first iPad on release day, we literally couldn't wait to get back from the Apple store to see how it played on the iPad. We actually purchased a copy of our own app online at the App Store, to make sure everything came out the way we expected it to.