Game Components, Game Managers and Object Properties

Posted by George Duckett on Game Development See other posts from Game Development or by George Duckett
Published on 2011-11-16T10:33:55Z Indexed on 2011/11/16 18:16 UTC
Read the original article Hit count: 465

I'm trying to get my head around component based entity design.

My first step was to create various components that could be added to an object. For every component type i had a manager, which would call every component's update function, passing in things like keyboard state etc. as required.

The next thing i did was remove the object, and just have each component with an Id. So an object is defined by components having the same Ids.

Now, i'm thinking that i don't need a manager for all my components, for example i have a SizeComponent, which just has a Size property). As a result the SizeComponent doesn't have an update method, and the manager's update method does nothing.

My first thought was to have an ObjectProperty class which components could query, instead of having them as properties of components. So an object would have a number of ObjectProperty and ObjectComponent. Components would have update logic that queries the object for properties. The manager would manage calling the component's update method.

This seems like over-engineering to me, but i don't think i can get rid of the components, because i need a way for the managers to know what objects need what component logic to run (otherwise i'd just remove the component completely and push its update logic into the manager).

  1. Is this (having ObjectProperty, ObjectComponent and ComponentManager classes) over-engineering?
  2. What would be a good alternative?

© Game Development or respective owner

Related posts about architecture

Related posts about design-patterns