Ahh, so so by default, it will have to loop over every GameObject weather or not it has or needs to update the component or not. I guess this is were ECS comes in? Ensuring the entities are processed in an efficient way.
This is not special to ECS. Look at discussions where people argue that the over-powered scene graph is a wrong approach.
The different sub-systems run different algorithms on the data (from components in this case). The algorithms usually work hand in hand with the structure how the data is stored. Hence it is natural that each sub-system manages its own structure(s) of data. Consequently, having all components in a single structure as provided by the GameObjectManager and the entity's component map cannot be suitable for all sub-systems.
That is true, I will probably split it to TransformComponent and PlacementComponent to make that obvious, thanks for that!
Not exactly what I meant. What meaning would the TransformCompnent have?
To explain my question:
Having a PlacementComponent (regardless of its name) means that at any time there is one position and rotation belonging to the object. When the collision sub-system runs it uses this placement; when the rendering sub-system runs it uses this placement. It is like a variable, read by those sub-systems, and hence with static value. Just when other sub-systems come into play, like e.g. AnimationSubsystem or CollisionResolverSubsystem or MovementSubsystem, there are activities to change the placement's value.
With this in mind, having a TransformComponent besides a PlacementComponent brings up the question which sub-system and how the component is used at all.
I do not quite understand what you mean by this? So each loop, i would call PlayerControllerSystem.update() and AiAgentControllerSystem.update(), and they in turn would call the 'lower' MovementSystem.update()?
Not really. Consider that the game loop is a prescription in which order things should happen.E.g. fFirst input is processed. Then player control is run, then AI, then animation and movement, then collision detection and resolution, then perhaps animation and movement again, then rendering. So, letting the player control invoke movement update would disturb this order.
Instead think of the PlayerController (or AI) to set variables, and of the motion sub-system to read these variables and act accordingly. This lets the PlayerController instruct the MotionSubsystem. The PlayerController actually does not need to know that a MotionSubsystem exists, because it deals with a set of variables.
Then later during processing the game loop, the MotionSubsystem's update is invoked from the game loop, and the MotionSubsystem does whatever the variables tell it.