I thought it might be useful to post some information regarding developing for the iPhone and iPod Touch… specifically as it relates to our favorite genre: adventure games. Well, it’s my favorite genre. You might hate it with a passion. But given that this is a site dedicated to adventure game development, I suppose it’s either your favorite genre too or you’re some sort masochistic wackjob who loves to spend countless hours and money on something you hate. Well my emotionally twisted friend, let’s dig in to this greasy, crispy, over-seasoned iPhone Bucket O’ Wisdom™!
PreparationLet’s start with the basics. You’re going to need to get a Mac. Calm down, they don’t cost as much as Balmer & Gates would like you to believe! The new iMac (which kicks seven different kinds of butt) goes for only $1,200. You could even go the cheaper route and get a Mac Mini for $599.
You’ll be doing all of the programming in a development environment called Xcode (like Visual Studio, but free and better) in a language called Objective-C. It’s similar to C++ in many ways. Once you have a Mac with Xcode installed, you can start developing right away! Xcode actually comes right on your Mac operating system DVD. Or, if you can download the latest version right from Apple’s website over the Internets.
Apple has a developer program that you’ll want to sign up for right away. Trust me on this one: don’t wait until you’re engine is fully developed or even more extreme... your game is finished. Sure, you can still develop and test your game without the membership, but you’ll only be able to test it on the iPhone simulator on your Mac. And like Kirstie Alley promising to behave herself at an all-you-can eat buffet, the simulator cannot be trusted! It’s $100 per year for individuals and small companies (enterprise membership costs more). Membership is required if you ever want to sell your game on the iTunes App Store. It will also allow you to install and debug your game on an actual iPhone / iPod Touch.
Take Away Item #1: Testing on the iPhone simulator is not the same as testing on the real device. Aside from the obvious interface difference (using a mouse instead of your finger), there are other differences that can crop up. You’ll definitely want to test on the actual iPhone / iPod Touch.
There are several existing game engines out there, but at the time of this writing... none of them appear to be that well suited to adventure game design. So... this guide will assume that you’re going to tackle the daunting task of writing your own engine - or you’ll make that neighbor kid that you’re keeping chained up in the basement do it.
“It types the engine in Xcode or it gets the f’n hose!”Displaying GraphicsThe first thing to decide is if your game is going to be a 2D or 3D adventure. There are basically two approaches to take to developing entertainment titles on this platform:
Core Animation / Quartz 2D- Core Animation and Quartz are built in Apple API frameworks that let you display, animate, and manipulate 2D images. All of the main Apple services have names that start with “core.” Apple... Core... Get it? Good.
OpenGL ES- OpenGL ES is a subset of the same OpenGL 3D graphics API framework that most games use these days (when they don’t use DirectX that is). OpenGL ES can be used to make either 3D games or 2D games. It’s recommended that for anything that is graphically intense (with a lot of animation for example) that you use OpenGL ES.
Accessing DataThe next thing to consider is how your game engine is going to store and retrieve data. When an application is installed onto the device or simulator, all of the files that you’ve added to the project (images, audio, video, etc.) are all stored in the application bundle. The bundle can be accessed in real time while your application is running, but it essentially is in a read-only mode. For that reason, it’s important to copy whatever files could potentially change during gameplay out of the bundle and into the application’s work space (sometimes referred to as the application’s “sand box”).
The cool thing about this bundle / work space relationship is that it allows you to install updates to the code without touching the player’s data. In other words, you can fix bugs and publish the updated version of your game without worrying about the installation of the updated version touching the player’s save game data. At the same time, I suppose it complicates things if the bug exists in the data that *can* be changed. Say, for example... a file or table that contains flags that control the state of something in your game. That clearly would be data that could change, so it would need to be copied from the bundle to the work space when the app is installed and when the app is updated. Integrating your fixed version of that file/table/data could be tricky.
That still leaves the question... what to use to store data? My recommendation would be SQLite. There are existing frameworks (approved by Apple) to fully access SQLite databases. The framework and the database itself are VERY easy to use and the database performance is fantastic!
The InterfaceSo now you’ve got a method to display images and a way of storing and retrieving data. Let’s talk about the interface a bit. Obviously there are no buttons on the device, besides the home button (which, when pressed, closes your application). The touch screen is most likely going to be the primary interface mechanism for your game (we won’t get into the accelerometer, as it doesn’t really fit the genre - although there is the potential for unique puzzle design that uses tilt controls).
When the player touches the screen, the touch goes through different phases. There are several ways to go about this, but in general you can override the event methods for these phases and run your own code during the phases.
- UITouchPhaseBegan (when their finger first hits the screen)
- UITouchPhaseMoved (when the x,y coordinates of the touch in question have changed)
- UITouchPhaseEnded (when their finger has been lifted from the screen)
There is a multitude of data associated with each touch... things like the coordinates, the tap count, etc. You can write code that will react to multiple touches, each one being handled differently and you can even create gesture / swipe recognition.
The possibilities here, as they apply to adventure games, are really endless. How immersive will your game be when the player can literally touch and drag items in the world into their inventory?
There are also, common controls that you can use for things like your menu system and interface. Things like labels for text, buttons, etc. This is pretty straight forward and present in just about any modern “visual” programming language, so I’ll refrain from going into any more detail on these.
Now... onto an important part! There are some guidelines to follow when it comes to sizing “touchable” spots (for lack of a better term) in your game that I’ve run into and would like to share with everyone.
The iPhone and iPod Touch screen resolution is 480 x 320 (when held in landscape orientation). I have found that anything that is smaller than at least 50 pixels in either height or width can be difficult for the player to accurately touch. The icons on the device’s home menu, for example... are all 57 x 57 pixels - and they’re that size for a good reason.
I can’t stress this point enough. I remember reading reviews of people who had jail broken devices (meaning their device was configured in such a way that they could install 3rd party apps outside of the normal iTunes AppStore) who had installed a ported version of ScummVM. Because the classic SCUMM games were designed for use with a mouse, many people found it difficult to accurately position the cross hairs over a desired item / location. The same engine, ported to a Windows Mobile device that uses a stylus doesn’t experience this obstacle, because the stylus controls are much more similar to the mouse.
Audio and VideoAs with images, there are built in API frameworks for playing sound effects, music, and video files. With sound effects, there are a few different approaches that you can take. If your game needs 3D spatial / positional audio, you’ll need to use OpenAL. Otherwise, it should be handled by Core Audio. Under Core Audio, there are even more approaches to take. My recommendation is to look in to using the AudioToolbox framework. The AVAudioPlayer object is very easy to use for playing sound effects and music.
The preferred format (according to Apple) for sound effects is 16-bit, little endian, linear PCM audio data packaged in a CAF file. For music formats, AAC or MP3 would be the way to go.
Video playback is actually easier to deal with from one respect, as there is less choice. The only way to play video files is to use the Media Player framework (MPMoviePlayerController class). The preferred format, I believe... are videos encoded with the H.264 codec. You’ll have control over this player and can hide the normal playback controls.
Publishing and Selling Your GameWhen you submit your finished game to Apple for approval, you get to set a selling price. For each “copy” of your app that gets sold, you get 70% of the money. Apple takes 30%. This covers their hosting, delivery, and payment handling. You might scoff at that at first and think it’s unfair, but try to realize that Apple just connected you with over forty million device owners (combined iPhone and iPod Touch estimates as of Q2 2009) who could potentially see your game and purchase it. That 30% per sale is insignificant compared to the cost of producing a physical product (with packaging) and getting it onto store shelves. Even if you were to attempt to host and distribute a game digitally (like Telltale) your hosting and transaction fees would probably exceed 30% per unit, and the audience that you’d be visible to would be tiny by comparison (as you’d have to generate web traffic to your site - starting with none).
ConclusionAs I just wanted this to provide a very high level introduction to the iPhone and iPod Touch as a platform for adventure games, I’m sure I left out a great amount of detail. That said, hopefully you found this post useful. I’m personally very excited about the potential these devices presents for adventure gaming. So much so, that I’ve spent the past two years of my life working towards releasing an iPhone adventure game.
Just the application distribution model alone should excite indy developers! Forty million device owners and zero publishing / distribution cost? Considering the time, money, and effort that it takes to make a game, I would think this would really appeal to all adventure game developers. But it’s what the multitouch interface can bring to the immersion factor, that really excites me. To be a bit melodramatic, the mouse is a dying interface method. It’s been around since the seventies and just like disco, it’s over stayed it’s welcome. Why point and click when you can just touch?
Recommended Required ReadingiPhone Application Programming Guide
