Game Components, Game Managers and Object Properties
- by George Duckett
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).
Is this (having ObjectProperty, ObjectComponent and ComponentManager classes) over-engineering?
What would be a good alternative?
