Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
August 27, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Ze iPhone Game: Choosing an Engine
by Jason Bakker on 07/21/09 01:26:00 pm   Expert Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


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 cocos2doolongengineUnityTorque 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 in the engine (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: - Setting up cocos2d as a shared library in XCode. - Blog of a dude getting started with cocos2d, with tutorials. - 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!

Related Jobs

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Software Developer Analytics / Big Data (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Backend Developer Marketing / CRM (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Mobile Developer iOS (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Software Developer Flash (m/f)


Emmanuel Henne
profile image
Good article, indeed ! I personally wouldn't walk away from SIO2 for just the reasons You mentioned (multiple software packages in a chain a common today), but I understand the desire to not clutter the toolchain.

Bryson Whiteman
profile image
Thanks for this! Informative stuff.

I've jumped at Unity because it offers an opportunity to get up and running incredibly quickly, with it handling most of the dirty work. I consider myself toward the right side of your spectrum -- as long as the game is doing what I want it to do and I can do super speedy development, I'm cool. I don't really care what's under the hood as long as it gets me where I need to go.

I actually didn't know that these open libraries existed, I was naively thinking the only alternative was to code an entire engine in Objective-C from scratch -- a nightmare.

I'll take a look at this stuff. I can see the possibility of the best option being somewhere in between.

Christian Arca
profile image
Great read Jason. I went through the same process you explained above. We also decided to go with cocos2d and so far have been obtaining great results. Although, we do have worries in regards to animations and perhaps being limited to 2d animations. However, we're taking it one step at a time. It's funny how sometimes something as simple as drawing a line based on where your touch can be a bit complicated but it is open source and that does make it worth it. It was great to read your experience about this endeavor and I am thoroughly interested to see the final result.

Stephen Northcott
profile image
It's always interesting to see other people's take on engines. Thanks for the article.

We went through the same process as yourselves a while back.

However, we never even considered Torque or Unity. The former for the same reasons as yourselves, and the latter because it's "too far to the right.". The same would go for SIO2 having had a brief look at it a few weeks back, purely out of interest.

On our first iPhone project we actually wrote our own engine and borrowed some stuff from Cocos2d. But to be honest, stripping Cocos apart we were not as happy with the coding as you seem to be. Horses for courses I guess. :) We spent a lot of time optimizing what we felt were some bad practices.

Our far more ambitious second project is well underway now and for that we have adopted Oolong's core code base as an interface to the iPhone, as it is neat, concise, readable and written in a way that makes sense to us.

It's not as far to the left as you suggest, but accessing it's features is a little more convoluted.

But the POD stuff is definitely worth having as a convenience, and Bullet and the community tip the balance IMO.

Over the top of that we have layered our OS X based 3D engine, with some modifications for efficiency on the iPhone. It is amazing how easy it is to port 3.x compliant OpenGL to GLES.

Oolong are well on the way to having their GLES2.0 implementation up and running, and we have run a parallel course with them on our own hybrid engine and GLES2.0.

Of course our aims are for a full 3D simulation, so our needs are different from yours. :)

Stephen Northcott
profile image
I meant to add that Scoreloop is far more fully featured than cocosLive, and will integrate with any engine with about 3 lines of code. :)

James Hofmann
profile image
Game engines suffer the problem of working in a field with no universal goals. When I write a GUI application, the libraries can anticipate various programming needs - painting and positioning controls, setting up events, synchronizing widgets, etc. And to that extent, all the available libraries are similar, though they take different approaches to solving those needs. You can rely on a preset structure that works for most application code. And the same is true for things like math, string processing, databases, etc.

But a game engine can be just about anything. Maybe the game is turn-based, maybe it's real-time synchronized to an external server. Maybe it's 2D and requires only some menu code, or maybe it's 3D with solid-body physics. The low level assumptions are so huge that in the end, to some extent, everyone ends up building a customized system whether they want to or not.

(This problem is shared with pretty much any "creative" use of computing, but with other mediums you can at least settle on standardized output formats - text files, images, audio, video.)

Vincent Morrison
profile image
Personally, I have been loving Torque 2D. Not only because of it's simplicity if you are a designer first and programmer second, but because of it's ease of deployment. Not only can the code be made for the Iphone, but it can be easily recompiled for PC, Mac, Linux and even consoles (if you have the licence). This makes my one game's worth of effort pay off multiple times and immediately widens the audience.

Torque 3d (Game engine advanced) however is very much what you described. I want to see how they do with their full Torque 3D package, but as of now, the code is too difficult to bend if you have a level designer's understanding of programming.

Jason Bakker
profile image
Thanks for all the responses - hearing your takes on and experiences with these engines has been really interesting. I didn't know that oolongengine has a great community, or that Torque2D is a lot simpler to work with than its 3D counterpart, and those are both facts that I'll use when deciding what to work with in future projects.

Also, Scoreloop looks really cool! I'll have to look into it further.

Geoffrey Rowland
profile image
We developed Attack of the Dust Bunnies for the iPhone using iTGB (the 2d Torque solution). It was really nothing at all like you described, all sorts of different type of games have been developed with it. Once we were comfortable with the engine and the process, it became quite easy to work with. I'd probably give it an 8/10 in terms of engines. In order to get it to run at a great framerate, we did need to convert most of the TorqueScript stuff over to C++ however.

Unity seems nice, but you don't get the source code with it, which is a huge problem - if there is a bug in the engine you need to wait for the unity team to fix it, you can't just fix it yourself. for videos and such.

David Turner
profile image
I personally have been spending the past few weeks learning both SIO2 and Blender. For a new developer (or in my case, a college student trying to make a big project outside of class), the price point is fantastic. Blender is free, has a wonderful assortment of tutorials (see Blender 3D: Noob to Pro on wikibooks), and has all the power you need to develop on a limited platform such as the iPhone.

SIO2 is something I have a love-hate relationship with it. Don't get me wrong, it's a very full featured engine. The system is complete with 17 tutorials with source-code and sometimes videos, an active forum monitored by the creator himself, and makes use of every open source technology it can instead of writing everything from scratch. Everything works in the engine, but one thing that bothers me most about it, is how it stores rotations for objects. SIO2 does not use axis-angle rotations, instead it keeps track of an object's rotation via x, y, and z values in a Vec3 format. I haven't come across a gimbal lock for it (yet) and haven't read into the source code well enough to detect if it is a problem, but for people who have a lot of pre-existing animations, you may have to re-write them. SIO2 does work around this by letting you export animations from Blender directly. Either way I'm sticking with it because I believe I can work around the issues I've found with it.

On a final note, I can't wait to see what iPhone OS 3.0 does for the engines. I can't wait to see what OpenGL ES 2.0 does for the look of upcoming games.

Maurício Gomes
profile image
Here on the company that I work we are dumping Cocos2D...

My boss is not happy in paying us to keep figuring stuff o Cocos2D, since its documentation suck (like saying that a Lens3D is a Lens3D...) and lots of thigns we figured from trial and error (mainly things that even the authors don't know too, because it is something that they only ported from PC Cocos2D but have no idea of how it work actually)..

Vishal Lamba
profile image
A good starter / informative article. We're probably going to offer insights into the different iPhone game engines as part of our Advance iPhone Programming Course Online at EDUmobile.ORG , so interested people can pre-sign up there.

Kenneth Barber
profile image
I looked at oolong and SIO2 initially. I also thought about using raw OpenGL or core animation. I have written to the "metal" in the past. My project is a 2d project so I don't need to worry about model loading and z axis collision/response at this time. I ended up using Cocos 2d because:

A. I don't want to reinvent anymore wheels. Starting from scratch is a bummer when you want to get to some actual game mechanics and can't because you have to set up lots of boiler plate common engine stuff first.

B. I wanted to use objective-C and C on this project without C++ (because everything else I write is in C++ and I wanted to at least partially embrace the platform)

C. You get all of the source and can change what you want while leave other parts unchanged.

D. Cocos2d has a healthy community following.

Cocos is pretty good for what it is and is only getting better. I wont look a gift horse in the mouth and talk badly about any of it because I wouldn't be nearly as far along as I am without it.

The missing documentation had me irritated initially but I found my way around and through experimentation came to the realization that there engine paradigm pretty simple and straight forward. directors, scenes, layers, sprites, actions, transitions, etc are pretty common abstractions.

Ondrej Mocny
profile image
I'd love to hear about your transition from C++ to Objective-C. So far it's probably the biggest (mental) obstacle for me to enter the iPhone development, so I'm interested in what was it like :)

Jason Bakker
profile image

It has been a pretty interesting transition! I work mostly in C++ at my day job, so every night when I come home I almost have to retrain my fingers ;) I'll try to look at doing an entry on it soon, I think people such as yourself need to be reassured that ultimately it isn't too big of an obstacle - in general it's more of a syntax change than actual logic.

Matt Mechtley
profile image
My brother Adam and I just released an iPhone boxing game we developed using Unity, Touch KO. We've both worked for Flashbang Studios/ for two years, and have developed using exclusively Unity for that time. If either of us started making another game tomorrow, we'd think about it for about five seconds and almost certainly decide to use Unity. Why?

Anytime that someone presents a simple spectrum from left to right I rant that it's almost certainly a more complex multi-dimensional space. I'm claiming the same here. With due respect, it sounds a bit like you looked at some pictures and marketing text on the Unity site and simply wrote it off, because you've assumed that there's this speed-flexibility/ease-of-use dichotomy. I claim they're independent axes, and that Unity has been unfairly lumped in with Torque, which is certainly slow/inflexible but easy to use.

First, ease of use. I probably don't have to sell anyone on this, as it's how Unity is being marketed. The entire design philosophy of the software can be summed up as, "How can we decrease the developer's iteration time?" Example: File importing -- Unity reads Maya binaries, Blender, FBX, as well as PSD natively. If I have a texture applied to a character, tab over to Photoshop and paint a smiley face on it, it changes instantly in the Unity editor as soon as I tab back. Same for Maya/Blender etc. No weird export pipeline, you configure import settings once per asset and from then on it just works. Another example: Script compilation -- Same story. Go out and edit your enemy behaviour script, save it, tab back. Everything's built on Mono, so the only recompilation that needs to occur is your logic, not the entire engine. Compilation time ranges from instant (a half dozen or so files) to about 2 seconds (for ~100 files). Did I mention there's a remote application for the iPhone version that forwards touch/accel input to the editor, so you don't have to compile and build to the phone just to adjust and test game logic? (though obviously you still must build to test performance)

Ok so how about flexibility/speed? It's true that you don't get engine source, so I'm by no means going to claim it's maximally flexible/fast. There's always a desire to be a meddlesome tinker, trying to tweak systems to your liking but it's important to remember the rules of optimization:

1) Don't

2) Don't yet (for experts only).

If the engine is suitably fast/flexible, it's much more efficient to just make the game instead of trying to remake technology, and resort to cleverness where necessary.

The question remains though, is Unity fast/flexible? I'll use Touch KO as an example. At any given time, we have two quite detailed skinned characters each with a couple dozen animations in a moderately detailed environment. We maintain somewhere between 20-30fps with an occasional spike, such as when using ragdoll physics for knockouts. Generally the scene is pushing around 7k verts and 15k triangles. That's pretty much the limit of the PVR chip's data bus for vertex data, so unless you're using a purpose-built custom engine I think that's about as good as you can expect. The animation skinning it turns out takes almost no time at all, because as of Unity iPhone 1.1 all skinning and animation is handled by custom assembly-written routines on the ARM's vector coprocessor. Do /you/ want to write your own skinning routines in assembly? I do not. So speed is definitely there.

Flexibility is probably its weakest point, but it by no means falls flat. It's definitely a 3D engine so if you want to do sprite-based 2D games it will take some jiggering. Tons of people do that though -- Diabolika or Zombieville USA as examples. There's also some lag in new OS features like custom playlists being exposed to the Unity API. However, you can bind your own external C/Obj-C functions from Mono's C#, so even then it just becomes a rote exercise that will slow you down a bit -- like writing your own engine from scratch might.

In the end it comes down to this for Adam and me: Unity is a wholly capable, fast engine, and its awesome workflow allowed us to finish a pretty damned ambitious game in 6 months of working on it after work and on weekends. Two people and six months means that now that we're reaping the rewards, we're only having to split things two ways (instead of a third for an additional programmer), and the time investment wasn't a great risk to us (we weren't slaving on it full-time for 9 months crossing our fingers that it wouldn't flop).

Yuval Markovich
profile image
We made one game with Unity, Rasta Monkey, a 2d physical platformer that got up to number #13 on the app store and we just started working on a new title and we have no doubts about working with Unity again. Unity is a great engine - fast, reliable and easy to work with. It's true that if you had more control with what's going under the hood you could do more with Objective C based engines but it would take much more time. Right now the reality of the app store is that games don't make enormous amounts of money - also the top 100 apps list is based on number of sales and not on income which gives $1 games a big edge.

This means that a small crew and short production times are key to keep making iPhone games that are economically viable.

Working with Unity lets you concentrate on the important thing which is game design. After learning Unity you get to a point where you can prototype a simple idea in a day or two which gives the ability to make lots of prototypes and experimentations. also the support you get from the team and community are priceless just check out the forums and you'll see what I mean.

for me working with Java Script is also much easier and straight forward than working with Obj-C which also cuts some of the learning time if you are just starting out.


Kevin Runion
profile image
Having published iPhone apps both with Cocoa and Unity, I must say that your assessment of Unity is unfair to say the least. I foresee the approach that Unity has taken with providing a full integrated game development tool kit as being the future of game development. It's just not feasible to be cost effective making games beyond the very simple, using only the native toolset. Asset management alone can bog down a project and tie up so much of your time. In a system like Unity it's an after thought.

A lot depends on your actual motivation for doing this project. I had a lot of fun learning cocoa and tinkering with it. When I decided that writing iPhone apps was going to be an income rather than a hobby, I realized that every hour counted. Being a one man development team, there was only so much I could do. The work is done in a financially tight space, since the average app isn't going to generate much revenue, it needs to be wrapped up as quickly as possible and with the most amount of reliability possible. So when you say that Unity is the most expensive option, in reality it is the cheapest option, unless your time is worth nothing.

In terms of flexibility, I don't see the issue. You can't group it in with torque. There isn't a game already written for you and a style direction that you are lead in. You have the tools to create anything. The Unity team has done an impressive job keeping the engine from getting bloated; including only the basic elements and features that are necessary for all games. Yes, you don't have the source code to the engine, but I have enough to worry about when it comes to making my apps. I'm not about to start messing with engine code. It's been nearly a year since I started writing games using Unity, and never had I wanted the source code for the engine. It's just really not that important.

I'm not saying Unity is right for every project or every development team. I'm just saying that it's worth understand what it's about and how it works. It may really benefit you. Not to be offensive, but it seems you have taken the lazy approach to evaluation of engines. Dev tools really need to be downloaded and tried. Glancing at couple pages on the website is not going show you anything. No amount of forum posts that you read or feature lists that you review will supplement for actually getting you hands dirty.

Jeff Murray
profile image
I have to agree with Kevin, Yuval and Matt on this. We have published two Unity-created iPhone games so far (Vans Sk8 Pool Service and Lifeboat) and the results are incredible. You don't need to know what is going on under the hood to make great games - only programmers use that excuse to justify their wages! ;) This isn't AAA development, it's on a much smaller scale where the amount of engine modification you would need to do would be extremely low unless you are planning on some groundbreaking technical achievement the likes of which have never been seen before? In which case, you probably won't be looking for someone else's engine in the first place. If I were you, Jason, I would actually try out Unity properly first and then write a follow up article once you realize how wrong this evaluation was!

Jason Bakker
profile image
Wow, thanks for your responses guys.


Thanks for the detailed writeup on Unity - you're right, I didn't really give it a fair chance when looking at it. I think the reality lies somewhere between a spectrum and independent axes - there still is definitely a slowdown when going to an engine versus rolling your own (as long as you have the time to do so), but that said, the amount of slowdown can be drastically decreased by smart decisions on the engine programming side. I guess I was hesitant to place my trust in the Unity programming team, feeling that if I was making more of the decisions, at least the only person I could blame was myself.


It's true that the current state of affairs on the App store means that the quicker and cheaper you can knock out your games, the better, however I do want to stress that with cocos2d I was up and running incredibly fast, and the reason that my game isn't out there now is more to do with the scope and style of game we're trying to create as opposed to the engine itself. I think that, at least regarding 2D games, cocos2d would definitely give Unity a run for its money on how quickly you can get your game made.


It's true, I didn't get my hands dirty with every engine, and that is what would have been required for a fair and comprehensive review. In a perfect world I would have done that in this process, but as you mentioned, time is of the essence when developing iPhone games, and based on the information that was available and how I processed it, I narrowed the search down until arriving at my solution.


For my next game, if I'm going 3D, I probably will at least give Unity a trial - as some of the other comments said, for 2D it still requires some jiggering to work, and I'm already too far along in cocos2d to swap engine anyway.

I just want to re-iterate that my opinions and judgments of the engines were from the perspective of someone on the outside looking in - they were not reviews, assessments or evaluations of the products themselves, and were not meant as such - I hope I didn't give the wrong impression to anyone. The only engine I actually loaded up was cocos2d (although I did download and have a peek through oolongengine).