1
\$\begingroup\$

This question already has an answer here:

Say I have an entity that has these components:

-Transformation

-Visual

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

-Transformation

-Visual

-VisualTransformation

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?

\$\endgroup\$

marked as duplicate by Sean Middleditch, Gnemlock, Alexandre Vaillancourt, Engineer, Community May 24 '17 at 13:53

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • \$\begingroup\$ What are you actually trying to accomplish? Dynamic transform hierarchies and game object prefabs or flyweights are easy enough in ECS or really any component architecture. Or are you asking about Systems that operate on Entities with a "signature" of Components? If you're associating every Component and System one-to-one, you're not using ECS right. I'm not really sure what you're actually stuck on here. \$\endgroup\$ – Sean Middleditch May 23 '17 at 18:27
  • \$\begingroup\$ Yes, how would I create Systems that operate on Entities with a "signature" of Components while minimizing coupling and keeping high extensibility? \$\endgroup\$ – Danny Yaroslavski May 23 '17 at 18:37
  • \$\begingroup\$ Thank you for the signature terminology, this answer seems to answer my questions: gamedev.stackexchange.com/a/31491/98134 \$\endgroup\$ – Danny Yaroslavski May 23 '17 at 18:46
  • 1
    \$\begingroup\$ glad to help. Sometimes just knowing what words to Google is half the battle. :) \$\endgroup\$ – Sean Middleditch May 23 '17 at 18:51