iPhone Lessons

For the past few months, a few of our team members have been working on adapting Outpost Kaloki to the iPhone/iPod touch. This was our first attempt at developing for the iPhone, and we definitely learned a few things along the way. Since developing games for the iPhone has become so popular, we thought we’d share the lessons we’ve learned to make things easier for those thinking of converting an existing game or starting from scratch on iPhone development. We asked each team member a series of questions relating to their role in the project. We’ll start with programming, then move to art/animation, then design, and finish off with testing. If you have any questions you want the team to answer, leave them in the comments and we’ll write up a separate post to answer those questions.


Kevin--Programmer

1. Describe the level of difficulty in converting an XBLA game to the iPhone.

Converting the game proved to be much more difficult than I had anticipated so I'm going to have to classify it as "hard."

2. What things really tripped you up in the development process? What was surprisingly easy?

We ended up converting pretty much our entire Wraith game engine over to the iPhone which proved to be quite troublesome. This was problematic for a couple of key reasons. First of all, the iPhone SDK is written in a different language than Wraith. Fortunately we were able to "glue" the two together but it made things a bit messy. Secondly, our engine is used to owning complete control over inputs and external systems. The iPhone likes to own all those things and to update them on its own and tell you about events that happen. Eventually we ended up letting the iPhone do its thing on one thread while the game ran on a separate thread and the threads communicated together about input and events, etc.

Another thing that tripped us up during development was the difference in power between the Xbox and the iPhone hardware. I don't think we really had a good feel for what the iPhone could handle graphically and we were simply trying to give it too much to do and it was choking. Once we had a better feel for the hardware capabilities we were able to tone down a few systems from the Xbox and give the user a decent playable experience.

I'm not sure that anything really turned out to be surprisingly easy - the whole experience felt like it would be easier than it actually turned out to be.

3. How long did you originally estimate development would take? How long did it actually take start to finish (not counting submission to apple)? Why the disparity in time?

I thought it would take 1-2 months originally and it's turned out to be closer to 3-4 months. The disparity in time was due to the unanticipated engine conversion difficulty.

4. What are the biggest differences between developing for XBLA vs. PC vs. iPhone?

Our game engine is written to be platform independent, which makes it so we can pretty much make the game in one platform and the low level functionality is hidden. This way, once the engine is converted to whatever platform (the iPhone in this case), everything just works. Of course, this is what happens in a perfect world. The conversion of the engine to the iPhone turned out to be quite challenging, but it didn't change the gameplay much at all. You're really getting pretty much the same game you played on XBLA now on the iPhone.

5. What advice can you give anyone developing for the iphone?

If you've never developed for the iPhone, spend some time getting familiar with the capabilities of the hardware and plan plenty of time to get used to the unfamiliar API.


Taylor--Artist

1. What was it like converting the art from an XBLA game to an iPhone game? Was it harder or easier than you expected?

Converting art assets from an XBLA game to the iPod/iPhone was an exercise in amputation, a stress test of the "reduce, reuse, recycle" mantra that ultimately prompted the class that I gave regarding the texturing and UV pipeline (see blog post here).

Game design in general is very different from the Pixar-style art generation that I trained for in college, and we're always trying to shoehorn as much as we can into every byte we have. Specifically when taking game assets from the Xbox to the iPod/iPhone, we had to reduce poly count and texture footprint by as much as 98%.

There wasn't anything terribly hard about converting the assets, but there were many little choices about how to reduce the models and textures, and everything required unique attention. A simple macro script wouldn't be enough to make it work well. This was expected, but it did wind up taking longer than expected because of iterative testing and some extensive model alteration, reconstruction and re-texturing as tech specs changed.

2. What was the biggest challenge in working on the art? The most surprisingly easy thing?

The biggest challenge working with such drastically reduced asset budgets was to maintain a look and feel consistent with the original game. That meant making cuts that really matter, but look like they don't. I think that overall, we've been able to make the game look and play enough like its progenitor that it captures the fun of the original without making too many sacrifices.

Maintaining the look and feel of the environments was surprisingly easy, given the complexity of the originals. It turned out that there were a ton of superfluous polygons in the models, so even a quick optimization pass got us a fair chunk of the way to where we wanted to be. A few texturing tricks later, and we had environments of 120 polygons or so that were less sumptuous than the originals, but still set the mood well. The originals were over 3000 polys in some cases, so we got a lot of value out of those 120 polys. We were also able to reuse those assets a lot easier than ship or station assets, so the environments went very, very quickly compared to the rest of the conversion.

3. What changes did you have to make to get the art to work on the iPhone? Did you create anything new?

We made several new LODs (Level of Detail meshes) for the ships and station expansions. We also wound up making a few new textures to fill in gaps or to optimize visuals that were fairly loose in the original. Everything was "under the hood" though, since there were no new ships, stations or expansions added. Anything new we made was just a tool to make the game look right (like the original) in the iPod/iPhone format.

Paradoxically, considering the vast reductions elsewhere, I actually wound up making larger versions of some HUD (Heads-Up Display) elements. The loss of precision that comes with switching from a mouse cursor to a touch input scheme meant that we had to alter some of the game UI. Even there, though, it was just making "technically new" visuals to approximate the old visuals.

4. Any advice you would give to someone working as an artist/animator for an iPhone game?

Get your game running on the iPod/iPhone as quickly as possible, and make sure the art and engineering teams work together to optimize it. The hardware chokes on things that larger consoles handle easily, and the earlier you can nail down target specs, the sooner you can get productive work done. We lost a lot of time by starting the project without an engineer and without the game actually functioning on the hardware. We did reduce assets, but after we started testing them, we needed to do another reduction pass (sometimes a couple of reduction passes) because the vague guesstimates we did early on weren't stringent enough, and the assets choked the iPod/iPhone, even though they were reduced to 25% of the original size. This reworking took a lot of time that could have been saved with clearer reduction targets early on, and early testing with engineering guidance would have helped define those targets.


Ben--Designer

1. What was it like converting the design elements from an XBLA game to an iPhone game? Was it harder or easier than you expected?

I didn't really know what to expect in converting this game to the iPhone! I have never worked on or owned an iPhone, so, it was all new to me. I didn't imagine it being very difficult but there were many things I just didn't think about until it actually came time to start making tweaks on the iPhone. For one, the screen was very crowded. We had to make numerous revisions to the UI because important parts were being covered or because our clumsy fingers couldn't navigate the game very well.


2. What was the biggest challenge in working on the design? The most surprisingly easy thing?
The biggest challenge that I was faced with had to be figuring out what to keep in the game and what to get rid of. We imposed a very strict limitation on the size that the game could be and this meant we had to be conservative with what made the final cut. Fortunately, no gameplay was lost due to these cuts but we did have to remove some of the really cool ships that only appeared once or twice in the whole game.

I was assigned the task of cutting down the size of audio files in the game to save us some more space. If you were to play the games side-by-side you might notice a little difference in the sound. Fortunately, we were able to save plenty of space by cutting down the sound files, yet, the sound is still awesome in the game.

The easiest thing was probably shouting at Kevin every time the game crashed - even when it wasn't his fault. :)

3. What changes did you have to make to the design to get it to work on the iphone?

When shrinking the screens down to fit on the iPhone screen there were a lot of things initially that just looked terrible. There was plenty of shuffling around of pieces of art on the screen, as well as text. Some of the text which fit perfectly on the XBLA version bled a horrible death all over the screen on the iPhone.

We also had tons of awesome content that we wanted iPhone users to be able to access. Unfortunately, there was just too much content for it all to go in one game. Deciding how to split up the content to make it balanced fell primarily on Jeremy's shoulders, I believe. Jeremy worked on the game originally and was much more familiar with it than I was.

4. Any advice you would give to someone working as a designer for an iPhone game?

If I were to give a designer of an iPhone game any advice it would be a warning: Remember that people have fat fingers (or at least I do anyways)! All actions in the game should easily be performed by someone who has really fat fingers! Even if your game is called "Uber kool game 4 ppl w/thin fingerz" it should still adhere to this rule.


Jason--Tester

1. What was it like testing for an iPhone game? Was it harder or easier than you expected?

Testing on an iPhone is like testing in the future! It’s all shiny, smooth, and full of lights. Testing on it was pretty much what I expected, there’s a quick period of adjustment to adapt to the console and UI in pretty much every project.


2. What was the biggest challenge in testing? The most surprisingly easy thing?

The biggest challenge for me in any testing gig is just testing around bugs. For instance if there’s a lot of lag on a level it makes it very difficult to test the level effectively.

3. What crazy bugs did you come across that happened because of converting from XBLA to iPhone?

In one scenario asteroids are suppose to bombard the station, but something happened to the graphics and sound so they were silent and invisible. So I’d be playing and everything would be going along just fine, and then all of sudden half of the expansions on my station would just explode.

In the War Story scenario, war ships are supposed to come in and attack your expansion. When you destroy them, it helps you earn money and complete the mission. However, at one point in the game, the attackers would come in, hover around an expansion, then fly off without attacking. You could destroy the war ships but it wouldn’t count, which made it so you couldn’t pass the level.

4. Any advice you would give to someone working as a tester for an iPhone game?

Learn a couple of deep breathing techniques to calm down for those unavoidable times you’ll want to throw the thing across the room.