ios - When should you roll your own game engine?

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?

Answer

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.