0

This question is about how to design my ECS system.

I have the following components:

  • Position
  • Gravity

Gravity needs to access Position.

Is there a better design that does not introduce this dependancy?

Position doesn't have any behaviour, it's just accessed by a bunch of things. Should it even be a component? What about other data only components?

Lucien
  • 1,176
  • 2
  • 10
  • 36
  • 2
    In an ECS, typically, components do not access other components. Systems access components.

    You say that Position does not have any behaviour, but so does Gravity: it's just a value. Behaviours should be stored in the Systems.

    Do your entity each need a different value for the gravity? If it's the same for all entities, then it should be set as a parameter to your Physics system.

    I'm not sure we have enough details about the issue you're facing, and about your architecture to give you a definitive answer.

     – Vaillancourt Jan 28 '23 at 11:44
  • 1
    You should help us help you be editing your answer and telling us more about how you've designed your ECS. (Because there are so many ways to build it.) – Vaillancourt Jan 28 '23 at 11:49

1 Answers1

4

Position doesn't have any behaviour, it's just accessed by a bunch of things. Should it even be a component?

Just data without behavior is pretty much the definition of a component in ECS.

I have the components Position and Gravity. Gravity needs to access Position.

No, it doesn't. In an idiomatic ECS architecture, components don't have dependencies because they don't contain any logic. Components are just dumb data. All the logic is in the systems.

The Gravity System, however, is a different story. It needs access to the Gravity component and the Position component of all entities which have both these components. Systems which implement interactions between two components are pretty common in ECS architectures. Such systems of course depend on both of those components. The ECS architecture is responsible for providing such systems with access to all the component-tuples that are relevant for them.

Philipp
  • 119,250
  • 27
  • 256
  • 336
  • I think you'd also need either a velocity or momentum component, or have the position component remember current and previous positions to drive Verlet-style integration. Basically something needs to be remembering motion state to be able to implement the gradual acceleration of gravity. I'm at the same position under the same gravity at both the start and end of my jump, but in one snapshot I'm moving up and in the other I'm moving down, leading to different system outcomes in the next step. – DMGregory Jan 28 '23 at 18:44
  • I suppose it's ok for components to have helper methods- like Velocity#applyForce? I can't see a reason not to have it, so jump could be an applied force that Acceleration slows down? – Lucien Jan 29 '23 at 10:40
  • @Lucien There is no law that forbids to add helper-methods to components. Just be careful to not take away too much power from the systems or introduce dependencies between components. Otherwise you will end up turning your Entity-Component-System architecture into an Entity-Behavior architecture. See also "What is a pure ECS?". – Philipp Jan 30 '23 at 10:15