Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've been a software developer for 5 years now and wanting to get into iOS game development. I've played around with the iOS SDK for about 2 years now, attending cocoaheads meetings and feel I have a good grasp on objective-c/cocoa and even c/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 a 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?

share|improve this question
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. –  DeadMG May 19 '11 at 16:21
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. –  Joey Green May 19 '11 at 17:57
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. –  Ray Dey May 19 '11 at 22:17
@DeadMG I something say "C/C++" and have an excellent grasp of both. –  Ciaran Oct 13 '12 at 9:40
I'd say it was the even that did it –  bobobobo Jan 13 '13 at 14:59

5 Answers 5

up vote 36 down vote accepted

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.

share|improve this answer
Agreed. As tldr: If you have to ask the question, you're much likely better off going with an existing engine. –  Chris Subagio May 19 '11 at 18:14
Your note in bold sums up my experience. –  Nick Wiggill Aug 3 '11 at 21:57
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. –  ashes999 Jan 4 '13 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
share|improve this answer

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.

share|improve this answer
If his goal is to learn, then it's not a waste of time. –  Ciaran Oct 13 '12 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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.