Ze iPhone Game: Choosing an Engine

On the 8th of June, my two artist friends and I sat around a table slurping down noodle soup and discussing possible ideas for an iPhone game. Six weeks, hundreds of work hours and five thousand lines of code later, we are knee-deep in the production phase, taking our initial prototype and turning it into a fully fledged game.

While I'm not prepared to reveal exactly what our game is yet, I feel comfortable divulging developmental information and thoughts, mostly because I think the notion of absolute secrecy in game development is paranoid and regressive in regards to the evolution of games as a whole. [1]

I'll try to cover a few aspects of our development process in this journal - for starters, the choice of the foundation of the game.

All game engines lie somewhere along a spectrum. On one end of the spectrum (let's say, the left) is flexibility and speed, and on the right end of the spectrum is ease of use and the amount of game that is already made for you. The fastest and most flexible engine, which resides on the left limit of this spectrum, is no engine at all - you are unlimited in what you can create, and it runs infinitely fast.

On the right limit of the spectrum is a complete game, which is so similar to your finished game that all you need to do is change the data that is read in, not the game itself - you are modding the existing game, as opposed to actually creating or modifying any systems code-wise.

Every developer has a preference for a different point along this spectrum. A lot of programmers that I work with at my day job prefer as close to the left limit as possible - they don't mind re-inventing the wheel, because it'll be their wheel, and they'll know exactly how it works. On the flip-side, people in the designer role at big game development companies operate very close to the right limit - programmers make the game (by creating tools for them to use, and the environment that their content resides in, and the rules of that environment), and the designers mod it to fit their vision.

Personally, I live somewhere in the middle - I don't like re-inventing the wheel if I can help it, but I've also worked with a few engines that do too much, which makes them slow, clunky and very intractable when you want to do something that the engine's developer didn't expect.

With that in mind, my thoughts on each of the major "engines" (which as of this writing are cocos2d, oolongengine, Unity, Torque 2D and SIO2) were as follows:

And finally, cocos2d, which is what I decided to go with. As you can probably guess, it lies in that middle ground between complete game and flexible nothingness - there are a lot of core systems that I now don't have to worry about (I don't need to know how to load up a texture, how to apply that to a quad, render that quad, etc.) - but the engine (or API, I guess) is still designed for flexibility and speed over being noob-friendly - which suits someone with a couple of years of game dev experience such as myself perfectly.

That would have been enough for me - fortunately however, it wasn't enough for Ricardo Quesada and his team at Sapus Media, and it also comes built in with a scene state manager, z-sorting with layer support, and a heap of nifty features such as scene transitions, sprite animations, tilemaps, etc. [3]

Furthermore, along with being free (although I'll definitely be donating to the project), cocos2d is open source, so I can go in there and change anything I want, or, more importantly, I can have a closer look and see exactly how a specific feature works. Looking through the cocos2d codebase, it's obvious that the people behind it know how to code concisely and intelligently - pretty much everything that I look at makes sense at first glance, and for the most case the logic works in the way that I'd want it to if I had written it myself.

Cocos2d isn't perfect - the lack of documentation makes the first few steps difficult, although there's a great whitepaper by the folks over at Monocle Studios which walks you through getting set up and putting something on the screen. And, due to the nature of it being a work in progress, you'll occasionally come across components that are not quite yet finished, or might need to change things around a bit when a new update comes through.

Regardless, I highly recommend it - a few measly hours after getting started I had a title screen fading through to a main menu (with clickable buttons!) and a little mans walking around on my iPhone screen, and it's been smooth sailing from there.

There's a lot more that I want to talk about (transitioning from C++ to Objective-C, the design and development process, team structure and work ethic), but I'd better leave it there for now. If you're interested in cocos2d, here are a few other links that I found useful:

http://www.clintharris.net/2009/iphone-app-shared-libraries/ - Setting up cocos2d as a shared library in XCode.

http://www.bit-101.com/blog/ - Blog of a dude getting started with cocos2d, with tutorials.

http://lethain.com/entry/2008/oct/03/notes-on-cocos2d-iphone-development/ - Some notes on the core features/functions of cocos2d.

- Jason 

[1] The games industry just got BURNT!

[2] Before you say it, yes there are ways to export models from Maya to Blender, then probably to SIO2, but in my professional game development experience, the more steps in your tool process, and the more programs involved, the more things are going to go wrong, and I didn't want to have to spend lots of time dealing with the intricacies of exactly what would and wouldn't carry over from Maya to Blender. That said, if you've had good experiences with this, let me know! If I go 3D with my next game, SIO2 might be my best bet.

[3] Another resource that Sapus Media has put out there is cocosLive, a service that you can hook up to your game that hosts a high score table for you - for free!