This question already has an answer here:
Say I have an entity that has these components:
Imagine that these components can nest:
If I have a parent transformation component, a child transformation relies on the parent transformation data.
Similarly, if I have a parent visual component, a child visual component may rely on the parent visual data.
Suppose we have two entities that both have a visual and transformation component. Say we have a concept of composing the entities themselves: which requires us to compose their respective Transformation and Visual components in some way.
Where would that logic go? Using pure ECS, these entities' components would be registered to their respective systems, but not amongst each other- Would I have to create a new system that houses the logic for composing entities that have certain sets of components?
One option would be to create a component along the lines of VisualTransformation which gets added to an entity in addition to the visual and transformation components; This new component would have the transformation and visual components dependency injected into it:
The entity would then have
And then a system that operates on VisualTransformation components would have its own composition logic for entities that have both, and delegate some logic to the respective systems that compose them separately (TransformationSystem and VisualSystem).
This starts to exhibit a code smell reminiscent of extending deep inheritance hierarchies; clearly not an extendible solution.
My other idea is then to create a generic component-bag system that works on entities with certain component sets, and register those entities with the correct bag of components to a system. Is this the right approach? How would this be done?