Warp Speed

In our game, there’s a lot of on-screen action that we had to be prepared for — we couldn’t have cumbersome, but necessary, calculations and memory allocation processes drop our frame rate to an unplayable level. We’re shooting for a frame rate of 45 FPS; we’ll be happy with anything between 45 FPS and 60 FPS. To help us stick to the 45 FPS end of that spectrum, here are a few things we did to keep the game running smoothly:

1.) The default setting for Xcode is set to “Compile for Thumb”. You get smaller compiled code, but it’s slower in-game. Instead, we turned that off, which makes instruction sets larger, but they get processed faster in-game.

2.) Allocating memory is a slow process and doesn’t need to be done in the game loop; we stashed it away in the loading screen. That’s a big burden off the processor’s back during game play.

3.) All calculations that we needed for our particle system in game, we precalculated. When a meteor gets zapped, or collides with another meteor, the splash for the resulting 200-odd particles is already stored in memory; no slow, ponderous calculations that can effect frame rate need to be done within the game loop.

4.) We had the option of tracking and accounting for off-screen collision detection but chose not to do it. Concentrating only on the objects on-screen requires fewer operations and we decided the benefit to the speed of the game was more valuable than accounting for whether X and Y meteor collided on the opposite side of the planet. In a related maneuver, we also did not draw X and Y meteor on the opposite side of the planet; only the meteors near the spaceship (on-screen) are drawn, thus saving the processor from accounting for meteors not directly affecting gameplay at that moment.

5.) Originally, we stuck with Apple’s convention and wrote the game in Objective-C. We suppose this language makes sense if you need the compatibility Objective-C offers for other iPhone programs (like, say, a photo album) but there really wasn’t anything on the iPhone that the game would benefit from if it were written in Objective-C, so we rewrote the game in C++. This, too, gives us greater flexibility and helps keep our frame rate at the target 45 FPS.

A great resource on optimizing your application’s performance is this page from the Apple iPhone Reference Library: http://developer.apple.com/iphone/library/technotes/tn2008/tn2230.html We used it extensively while figuring out how to keep our game humming along, here’s hoping it will help you too.

Read Full Post »

The Unpaid Version

Free vs. Lite

It’s nice that you want to give prospective users an opportunity to test your game without paying, but don’t shoot yourself in the foot with the words you use to convey that fact. The two words most commonly used to notify a user that they are downloading a version of the game that they can test without paying are “Lite” and “Free.” We say, stick with Free. A user may see “Lite” and not realize that the distinction between the “Lite” and full versions of the game is whether they pay money to play or not. If a user sees “Lite” and that the game doesn’t cost money to play, they may go off in search of the full version. Upon finding the full version, and the fact that it costs $3.99 to download, you’ve probably lost that prospective customer; it’s unlikely the user will then go back to download the Lite version, get hooked, and then go back and buy the full version. By using the term “Free” instead, you note that the user will be able to experience the full range of gameplay possibilities and can notify in the description, and also later in the game, that to play all available levels of the game, they must purchase the full version. People know what “free” means – they don’t have to pay. Leave the coy term – “Lite” – to the soda and beer companies.

Read Full Post »

The First 30 Seconds

First, but not last, Impressions

Your name and icon jive, and people tap through and purchase your app. Good deal. Now you have to make them not regret the decision. Remember that the first impression could be the only impression you get to make, so the first 30 seconds a user spends with your app is critical; one loading screen, or one second of loading, too many, and you’ve lost your user’s attention. To avoid a flame out like this, there are a few things you can do to get them playing as soon as possible and not staring cross-eyed at loading screens.

The big one is loading. If there’s a lot to load, find a way to disguise it; load in the background while the player is progressing through the UI menus. If that’s still not enough, then take the Madden route and show tips, hints, strategy while the game is loading – give your users information they would be interested to read so the loading doesn’t seem so long. You can use the UI menus to your advantage to disguise loading, but don’t create a labyrinth between there and the actual gameplay. Your users want to start playing, so keep the UI menus simple and straight-forward, make the experience crisp and clear, and keep load times to a minimum. Here are a few tips:

1.) To start playing the game just have a button that says “Play” or “Start,” don’t get clever with words like “Engage” or “Lift Off!”
2.) Keep unnecessary options off of the main UI menus; you probably don’t need “Credits” or “About” buttons on the main menu. Has anyone ever clicked on one of those? Also, if the user is starting the game for the first time and your game has multiple levels, don’t force your user to select “Level 1.” Just send them there automatically. They just started playing, of course they have to choose Level 1.
3.) Disable the title bar via Info.plist, not programatically. If you do it programatically, it takes a little longer and it just looks messy when that title bar hangs around a second or two into loading. It’s all in the details.
4.) Don’t disable the user’s music. That’s amateur hour, dudes.
5.) Once the user has played more than once, offer an option to restart the game exactly where they left off so the don’t need to flip through all the UI menus. If you do this, though, also offer an option to disable this feature.

Follow these tips and just keep in mind that you should do everything you can to stay out of your user’s way between the moment they tap to open your app, and begin game play.

Read Full Post »

iPhone Audio Basics

Sounds Nice

It’s all in the details. You’re so focused on getting your app just right – making the splatter effect when missile meets buffalo in your “BuffaloZapper 2: The ReZappening” app, perfect – that you forget the system on which your app will be played was not designed with only your app in mind; your user has his or her own things going on with their phone, too, and they don’t want your app to blot those things out.

The big spot where this comes into play is with sound and music. Your exploding buffalo noise might be great, but your users might not care if they can’t have their favorite Anthrax track playing in the background when it happens.

So you’ve got to have your sounds right. To do this, you need to consider the different situations that could arise for a user and what expectations they would have for your app, their iPhone, and their music. Below is a chart that diagrams all the sonic situations your app should be prepared to accommodate for its users.

Headphones Plugged In	iPod Music Playing	Silent Switch On  (iPhone only)	Music	Sound Effects

Read Full Post »