Although an component system is the basis for most modern game engines and considered as the better(if not the best) way to put together a game. One of the biggest drawbacks is that when you create an architecture that is modular and loosely coupled, you introduce performance overheads.
On PC and other higher end devices, the tradeoff is smaller in exchange for elegancy of design and implementation. On the iPhone, especially older ones you have to to be care about how to implement things. The most common discussion on most game dev sites on the iphone is to watch your draw calls. On older 3G devices, 20-30 is a bandied around number…well that obviously and how many polys you are using plus if your code is running native or script…where is all this leading too….Ah yes the component system I was building on top of Cocos2D.
Here are some of potential performance overheads I ran into while implement it:
- One of design limitation you have to work on cocos2d uses a SpriteBatchNode to allow ‘sprites’ using the same texture to be drawn in a single draw. In a component system, everything is based around composition which means there is a lightweight ‘entity’ class with ‘components’ attached to it. So 1 entity = 1 draw call at the very minimum. With the older 3G devices, you are restricted to 25-30 draw calls (as a rule of thumb that is float on the Internet).
- Sharing of properties between components. While I have allowed the position property to be stored on the entity itself, other functionality specific properties aren’t. In order to do so you will have to either incur a dictionary look up (i.e. component foo = entity.lookupComponentByName(Bar)). Or you could directly link it up be assigning it to a pointer. Doing that however breaks a design principle of trying to make components loosely coupled for modularity
- Inter component communications. Besides directly looking up a component, a better way to talk to between components is to use ‘events’. For my component system, I built a addEventListerner,dispatchEventListener system similar to what Flash has. Like all events though everything is unidirectional and has a limited data payload of a single object.
In conclusion, I think for most of the newer games going with component system makes sense because once you get started you will be amazed at how everything clicks into place. If you are writing some more performance intensive, you will find components losing some of its appeal.