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 the 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.
I came to the iPhone a complete and utter noobcake, so I went through a few UIKit tutorials (that’s the Interface Builder and .xib files and all that stuff), before I realised that most games used OpenGLES, cuz’ for apps that need full-screen refresh (like most games) it’s waaaay faster. I didn’t like the sound of starting from scratch in OpenGLES, so I decided to look at some kind of middleware solution, and… tasted a few.
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:
- oolongengine: We were initially looking at 3D as an option for the game, and while very fast, oolongengine is also extremely bare-bones – from what I could tell, at least when we were looking at it, it just handled importing PowerVR’s POD format and cobbled together a few other open source components into one package. This would be a good starting point for one of the hardcore programmers I mentioned earlier, but I didn’t like the prospect on spending a month or two setting up model managers, scene managers, animation managers, camera managers, etc. before being able to start work on the actual gameplay itself.
- SIO2: This option was a lot more along the lines of what we were wanting out of an engine – a lot of the base 3D stuff was there already, not to mention some sound, physics and lighting/shadows. Unfortunately, we discovered that the tool chain is based around Blender – a fine program I’m sure, but my art-monkeys are Maya-based, and this would require them learning a significantly different way of modelling in a new program. [2]
- Torque2D/3D: Do you remember the slow, clunky and intractable engines that I was talking about earlier? As part of a university group project I worked on a game called Cataclysm (video available on my terrible final year folio site) which used the Torque Engine, and while it was the right choice for game development novices such as ourselves, it definitely didn’t bend very easily when we wanted it to be something other than a 3rd person shooter. Having an engine that’s a lot closer to a finished product is great for some people, and the GarageGames community is a fantastic group of developers, but from my experiences I feel that Torque is one of those engines that isn’t intended as a foundation to build a game upon so much as it is a pre-existing game that you can mod and load custom content into. (This, as far as I’ve deduced, is similar to how a lot of big-budget engines – Unreal, Gamebryo, etc – are designed as well.)
- Unity: Lowest on my priority list was Unity – I’ve heard good things about Unity in general, but after looking at their website a lot of the points previously mentioned about Torque came up – I feel much more comfortable knowing and understanding roughly what’s going on behind the scenes, and in engines that are designed for “anyone” to be able to make a game in, it’s often a lot harder to get to the core of what’s actually happening (Flash, anyone?). The fact that it’s the most expensive option on the list didn’t help either.
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!
