I carefully read an old post regarding relationship inside ECS especially parenting.
I tried to stick to your explanation:
¤ Parent + PlacementComponent * Position * Orientation ¤ Child + PlacementComponent * Position * Orientation + ParentingComponent * IEntity (parent) * local_placement (Position x Orientation) => PlacingSystem | Entity.Placement.Position = f(Entity.ParentingComponent.Parent.PlacementComponent.Position, Entity.ParentingComponent.local_placement.Position) | Entity.Placement.Orientation = f(Entity.ParentingComponent.Parent.PlacementComponent.Orientation, Entity.ParentingComponent.local_placement.Orientation)
It is a good fit for a single parent|child relationship but I am wondering how to deal with parent|child|grand-child one. Position have to be updated in the right order ie from root to leaves.
Do we need a plain old scene graph or can we handle this sticking to ECS philosophy?
Yes, you need to consider a processing order. But a scene graph is a multi purpose structure. As such it is not suitable to solve a single particular problem. What you essentially mean is a dependency graph.
However, in case of ECS the sub-systems are responsible to store the component data in a reasonable fashion. In the given case there may occur dependencies on each other, so the sub-system has to partially sort the stored data. This will fail on a mutual direct or indirect dependency (which should be disallowed), but will work in all allowed cases. Then the data can simply be processed in order.
See You on GDnet
Thanks for your input. I misspelled it but I was in fact talking about some kind of dependency graph and not scene graph.
If I follow you: putting data inside component, attach them to entity and leverage this dynamic bag to identify which entities a system should work on does not imply that entities must be managed as a flat list inside systems: we need to think the smartest data structure regarding context.
If we stick to SRP, system's single responsibility is to dynamically gather entities. It should - must have to - then leverage an underlying engine (subsystem/kernel/service) to effectively process those entities. If we introduce an abstraction here we can then have the flexibility to switch between different engine which store and work on entities in their own efficient way.
It makes sense for me this way. I will continue to dive into.
Not only for its inherent qualities ECS forces you to approach situation differently.
It deserves a better exhibition as it is clearly IMHO a major software paradigm.