I've been a software developer for 5 years, now, and I am wanting to get into iOS game development. I've played around with the iOS SDK for about 2 years, attending cocoaheads meetings, and I feel I have a good grasp on objective-c, cocoa and even c and c++.

I have a game idea, and know that I will use Box2D, but I'm wondering if I should use cocos2D or not. The main reasons are:

  1. I may want to do things, graphics wise, that aren't available in cocos2d.
  2. If I roll my own game engine, I'll have more control.

Of course, the main reason for using an already-existing game engine is the time it saves, and it makes the hard stuff easier; but for someone who has the technical chops to roll his own, does it make sense?

  • 7
    \$\begingroup\$ If you say "C/C++", it's pretty likely that you don't have a good grasp on at least one of them, and probably both. \$\endgroup\$
    – DeadMG
    Commented May 19, 2011 at 16:21
  • 10
    \$\begingroup\$ I understand that some people confuse the two and I probably should of said C/C++/Objective-C to iterate that I understand the main languages that you can use to program on the iOS platform. I didn't feel like saying C/C++ would automatically mean that I confuse the two as one. \$\endgroup\$
    – Joey Green
    Commented May 19, 2011 at 17:57
  • \$\begingroup\$ I do like this question as it makes a welcome change from the usual "how do I make my own engine?" questions. +1 for you, sir. \$\endgroup\$
    – Ray Dey
    Commented May 19, 2011 at 22:17
  • 1
    \$\begingroup\$ @DeadMG I something say "C/C++" and have an excellent grasp of both. \$\endgroup\$
    – Ciaran
    Commented Oct 13, 2012 at 9:40
  • \$\begingroup\$ I'd say it was the even that did it \$\endgroup\$
    – bobobobo
    Commented Jan 13, 2013 at 14:59

5 Answers 5


Most of the other posts will be "make a game not an engine", but I'm going to assume that you have a particular game in mind you want to make and want to know when it's a good idea to start with somebody else's code base or start from scratch.

You shouldn't roll your own tech unless you know you need to roll your own. That may sound flippant but it's really the only correct answer. As with most decisions, there are tradeoffs. Only you can determine for your particular situation the cost/benefit analysis.

You should have an understanding of the following things (this list is hardly all inclusive).

  • What middleware is already out there that you could use ("engine" or otherwise)
  • What that middleware brings to the table, feature wise.
  • How mature/proven the middleware is, especially if you care about multiplatform support
  • What kind of tools the middleware provides, or doesn't provide, to help speed up development (don't discount tools with your own tech)
  • What limitations that middleware has (as a simple example, Unity 3.x didn't do real time shadows from dynamic lights on iOS)
  • What specific features your particular game has to have.
  • What your deadlines are, and how much time you will have to spend to get up to the point of where the middleware will get you vs. how much the middleware costs.
  • How extensible the middleware is (for example, you can get around the shadow problem on iOS in Unity by using blob shadows. Or maybe projection shadows.)

(Notice that I specifically didn't put "more control" up there. That's a loaded phrase that could range from "I don't like code I don't write" to "I need to be able to see, understand, and tweak all the variables in the physics engine to achieve this particular effect." The first one isn't really a valid consideration, but the second is.)

Personally, I find that rolling your own tech for a low-budget game is hardly ever worth the effort. The amount of power you get the cheap engines these days is ridiculous. You're not at a point where you're deciding on a multimillion dollar triple A engine license or not. You're not going to be able to beat what, say, Unity offers to you for $3k. Or Cocos2d for whatever it costs (isn't it free?).

Now, if your game is mostly focused around some kind of tech that other engines can't provide, or can't provide at a reasonable framerate, then it might be worth investigating what you can do. That doesn't mean you throw out the other middelware entirely, though. Just because you need your own, say, renderer, doesn't mean you can't use some other middleware for physics or sound or UI or what have you.

  • 7
    \$\begingroup\$ Agreed. As tldr: If you have to ask the question, you're much likely better off going with an existing engine. \$\endgroup\$ Commented May 19, 2011 at 18:14
  • \$\begingroup\$ Your note in bold sums up my experience. \$\endgroup\$
    – Engineer
    Commented Aug 3, 2011 at 21:57
  • 1
    \$\begingroup\$ Community is also important. Something with a strong community, like XNA, makes solving particular problems that much easier because someone has done it before or can give you pointers. \$\endgroup\$
    – ashes999
    Commented Jan 4, 2013 at 12:56

Don't roll you own engine. Roll you own game. If you happen to write an engine at the same time then good for you, if not you can always refactor whatever parts you might want to reuse to make it more "engine" like.

People often over estimate what it takes to write the "engine" part of a game. If you only do what you need it won't take that long. The hard part is to not get stuck writing infrastructure and to only write what you absolutely must to solver your problem.

I would use an existing engine when:

  • I have a tight deadline
  • I have a known fixed feature set so that I can chose an engine for that

I think you should just write your game, and perhaps you'll end up with an engine later. Writing the graphics engine (which is all it sounds like you're talking about) from scratch using nothing but OpenGL is likely only going to waste your time. It is a relatively well-solved problem so generally you'd only be changing the shape of the API without adding much in the way of significant new features relative to any other available third-party solution out there.

If Cocos2D or some other graphics layer meets your requirements now, then use it. If your requirements change during development, you can swap out the rendering back end relatively easily -- if you truly believe you have the experience and wherewithal to create an engine yourself, you should certainly have what it takes to structure your game such that swapping out the rendering back end is a relatively trivial operation.

Build your game, allow its specific needs to drive the feature set of the code you write, and write code with reusability and good architecture in mind. You will naturally end up with an "engine" after you finish a few projects like this, and you'll finish those projects faster because you're disallowing yourself from getting bogged down in framework-level feature creep.

  • \$\begingroup\$ If his goal is to learn, then it's not a waste of time. \$\endgroup\$
    – Ciaran
    Commented Oct 13, 2012 at 9:37

It's very simple. Which is your primary goal: learning or time to market?

Avoid using a library if your primary goal is to learn from the experience of implementing the concepts that are solved by the library. Whenever I develop a game (part time), my goal is purely learning. I don't care how long it takes, thats why I'm doing it all from scratch! Now, you decide.


You should roll your own game engine when you know there is a need for it.

So for example, say you don't have the money to spend on Unity. Or, you'd rather spend it on new hardware instead. Or, there are performance issues with the free engines available to you, or you need to have more control at a low level.

If you love writing software for the sake of writing software, then you're going to love writing a game engine. A common trapping of beginning game programmers is to get caught up writing an engine as some kind perpetual project. I honestly believe that's how all these open source game engines came about -- game programmers who actually didn't

Then in that case, write your own engine.


Not the answer you're looking for? Browse other questions tagged .