In my engine, systems work on single components. When a system traverse a pool of its component type, after each component update it sends an event to the object owner of the component, interested components (attached to the same object) will receive the event and update its data accordingly.
For example, my Transform system traverse all transform components, updates its final matrix and send a transform event to its object.
Right now I have 2 components that register to transform components, the collider and the sprite component.
The collider will update its pos by getting the trafo received and adding its own offset.
The sprite will update its "renderWorld" matrix. (its more complicate than that, I actually need to see if the render and current differ, and than interpolate, since its a fixed time step loop. This happens on the sprite system loop, not on the event receiving.)
As you can see, I need to update systems in order, this order is decided when I add the system to the game.
With this event technique I dont need to care if the object have or not components that need to be informed, I could have pointers on components pointing to interested components, but that would be a pain in the ass to manage. The object can change in real time and it keeps working, no need to change anything.
The bad thing is that when I create a new component class, I need to be aware of all components and make the appropriate eve registration on the VOnAttach method.
Say I want to create a rigidBody compo, I will probably want the transform component to register for rigidbody update events, and make sure the rigidybody sys updates before the transform sys. The good thing is that if I want to create a component that need to receive transform events, I just need to register, no fancy interaction.
When it comes to entity talks around 'google', theres always a mention about hacking the gameobject by putting pointers to most used components, to speed up things. For a specific games where you know your objects will always have components x, y, z, you could just create a special case game object that speed up interaction between x, y and z.. (You can see that in Unity, you cant take out the transform component.)
I dont believe much in the "no game object actualy needed", making it just an abstract concept. It just introduces lots of complications, and Ive never seem anything like it other than chit chat (by ppl who actually never implemented it).
Each component have a factory, the factories are the ones holding the pools. The systems grab a reference to the pools on construction.
A factory need a createCompo method that can create an un-initialized compo and one that receives a "gfig" by param. gfigs is something like a parsed xml file that I invented.
Theres a object factory that have access to all compo factories and it can build entire game objects from a single gfig file.
Edited by Icebone1000, 17 April 2014 - 02:02 PM.