About

Big Bad Robots is an indie game developer but we also do contract development. We have developed on all kinds of platforms (PC,Handheld,Consoles) but now primarily focus on iOS,Android and Unity. Contact us if you looking for developers with over 20 years experience in software and game development at biz -at- bigbadrobots.com

Components, Draw Calls and performance….

March 8, 2011terence

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.

2 responses to “Components, Draw Calls and performance….”

  1. danien says:

    If your entity and sprite hierarchies are separate, you can probably still keep the sprites under a SpriteBatchNode.

    Also, why create your own event system when there is NSNotificationCenter?

  2. terence says:

    Actually I do keep sprites under a SpriteBatchNode and having a component add/delete sprites to the SpriteBatchNode. There is nothing stopping you technically from doing this but from architectural point of view it will be pretty messy as you will root the entities spatial coordinates at (0,0) and manipulate the sprites coordinates.

    I created a new event system because I wanted events to ‘go through’ the entities. It is conceivable to still used NSNotificationCenter which can be used to communicate directly between components still, but I wanted the suggested method to be between entities. It makes it easier to understand logically and also eliminates dangling ‘hooks’ (i.e. damn where the hell did that message come from)

Leave a Reply

Your email address will not be published. Required fields are marked *