I read some interesting literature describing Entity-Component systems:
GREGORY J.: Game Engine Architecture, 2nd Edition.
http://www.randygaul.net/2013/05/20/component-based-engine-design/
http://www.randygaul.net/2014/06/10/sane-usage-of-components-and-entity-systems/
and some GameDev links (which I removed due to the ugly and large widgets replacing the urls).
Though, I am still not 100% sure, the direction I want to go. I like Unity's representation in the editor, unfortunately Unity is close source. Though, Unreal's monolithic class hierarchy is nice as well since you can basically override every class as a user.
The Unity editor has a GameObject tab and a Component tab. The "GameObjects" represent the different kind of nodes in the scene graph. The "components" seem to be add-ons for the "GameObjects". Though, some overlap is possible since you can have a standalone Camera or an add-on Camera. At first this seems like a nice separation. But when looking to the hierarchies in their scripting API, most of these "GameObjects" and "components" are just inheriting their Component class anyway.
If one wants to represent this in code, the GameObject can have:
human readable name (string or hashed string)
guid
some flags, tags and layers
transform (I do not want separate transform component)
collection of component (pointers or ids)
some message/event passing utilities
Each Component has a way to access its associated GameObject. My scripts will be components as well containing some specific message handling methods that can be overriden.
Each System will access the Components it needs.
That said, how are these Components stored at the Engine side? For memory coherence, I would expect to see something like a dynamic array per Component base type instead of per Component type since you can have an infinite number of components. I guess this Component base type must be specialized enough to avoid all types of casts?
↧