Entity component system, Communication between components [duplicate]

Question

I am trying to implement ECS for my simple 2D game. I would like to ask a question about how components should communicate between themselves and with entity.

I tried to implement few components, like SpriteComponent, MoveComponent, CollisionComponent, etc.. What is the appropriate way of communication between these components? E.g. my Sprite & Physics components need to know about current position, which is affected by Move component. I gave every single of my components handle that refers to the entity, which they can send to engine and call different functions, like updatePosition(EntityHandle handle, float x, float y). Is this the right approach?

Answer 1

I supposed if you want maximum decoupling you would use a message system in order to pass events to your entity (can also happen indirectly with the entity being the listener to your components and broadcasting it to all other listeners/components) and other components can listen to those. I think this is your current approach.

Since you already reference your entity in your component you could ask your entity to return another ("neighboring") component (e.g. entity.getComponent( ID )) and typecast to your required component and pull any information you need or even invoke specific methods. you could also temporary store those (typecast) components as member variables but this might require additional thought on how to properly remove a component (since it might be referenced all over the place).

In a similar manner you could go hybrid and create custom entities implementing specific entity interfaces exposing access to certain components that are common or required by each other to properly work. (e.g. a transformation component that is required by collision, physics, etc) the components entity reference can than be the type of your interface (using generics for example). note that this increases coupling again and one could argue that this approach goes against the whole idea of using an entity component system in the first place.

I found the last approach to be useful for core related entity/components though and you can still implement a highly decoupled message system for application specific custom components.

A very different way to think about it would be to treat components as pure data structures not containing any processing methods the user or engine can invoke directly, but rather implement any component related logic into systems handling the relations between components for each given entity. e.g. having a physic component storing forces applied to your entity and another component storing position/rotation but using a physic system updating those 2 components for each entity. using this approach you are also highly decoupled but it increases complexity in how to efficiently manage entity component relations and is somewhat similar to classical relational database management with your components being pure data queried by systems to perform operations.

I guess a pure message system is probably the most straight forward approach and I suspect that the performance impact the indirect communication causes is neglectable.