2 ms·

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was br

The problem with this approach is that systems will need info from multiple components, so at some point you are forced to make the coupling that the ECS was brought in to avoid. For example, the rendering system needs to know entity position. So to which system does the "position component" belong? Not all entities that have a position needs to be rendered, and neither do all renderable entities require movement, and this same issue permeates all aspects of the architecture.

bitwize 9y ago
Components do not belong to a system. Any system can access any component. Think of RDBMS stored procedures that operate on all rows matching certain criteria; don't think OO style encapsulated "methods". The system only operates on entities that have all the components they need. So there won't be one rendering system but several: one for entities that require movement, one for those which do not, etc.
- dyarosla 9y ago
  Almost right. You wouldn't necessarily have a separate rendering system for entities that require movement and those that do not. Instead you would likely have an additional system that operates on entities that have both position and render components and propagates updates from position to render data. The render system for all entities with just a render component would then remain the same. This can be imagined as systems that work on signatures (a component set or aspect that specifies whether an entity's components match the system's criteria). A render system would have an aspect of say [RenderComp] and a positionRender system would have an aspect of say [RenderComp, PositionComp]. Note that the positionRender system would not actually render anything, only serving as a propagater of data.
lgas 9y ago
Why does a component need to belong to a system? Why can't the component belong to itself and just be used by multiple systems?
- dyarosla 9y ago
  Right, this is the general approach of ECS.
deleted 9y ago
[deleted]
dyarosla 9y ago
I suggest you read more into component signatures and how systems decide which components to operate on. Specifically, systems do not own components. Nor do they operate on full entities. Nor is there any coupling. If you have entities that need to be rendered, you would give them a render component. A render system would render all render components that exist (thus 'rendering the entities' for whom those render components belong to) If you have entities with positions but not render components, the render system would not operate on those entities. Similarly if an entity has a render component but no, say, velocity component, it would not be registered to a movementSystem. Systems that need to propagate data between components would have component signatures that include those components for which they need the data of. So a positionRender system would have an aspect of [PositionComp, RenderComp] and would be the only system to copy over data from one to the other. There will always have to be a place that decides what object has which components. This should be as close as possible to the 'aggregate root' (a term from DI), and generally in ECS at the point of instantiation of the entity. I believe this question is prompted by a fundamental misunderstanding of ECS.

bitwize 9y ago

Components do not belong to a system. Any system can access any component. Think of RDBMS stored procedures that operate on all rows matching certain criteria; don't think OO style encapsulated "methods". The system only operates on entities that have all the components they need. So there won't be one rendering system but several: one for entities that require movement, one for those which do not, etc.

dyarosla 9y ago
Almost right. You wouldn't necessarily have a separate rendering system for entities that require movement and those that do not. Instead you would likely have an additional system that operates on entities that have both position and render components and propagates updates from position to render data. The render system for all entities with just a render component would then remain the same. This can be imagined as systems that work on signatures (a component set or aspect that specifies whether an entity's components match the system's criteria). A render system would have an aspect of say [RenderComp] and a positionRender system would have an aspect of say [RenderComp, PositionComp]. Note that the positionRender system would not actually render anything, only serving as a propagater of data.

lgas 9y ago

Why does a component need to belong to a system? Why can't the component belong to itself and just be used by multiple systems?

dyarosla 9y ago
Right, this is the general approach of ECS.

deleted 9y ago

[deleted]

dyarosla 9y ago

I suggest you read more into component signatures and how systems decide which components to operate on. Specifically, systems do not own components. Nor do they operate on full entities. Nor is there any coupling. If you have entities that need to be rendered, you would give them a render component. A render system would render all render components that exist (thus 'rendering the entities' for whom those render components belong to) If you have entities with positions but not render components, the render system would not operate on those entities. Similarly if an entity has a render component but no, say, velocity component, it would not be registered to a movementSystem. Systems that need to propagate data between components would have component signatures that include those components for which they need the data of. So a positionRender system would have an aspect of [PositionComp, RenderComp] and would be the only system to copy over data from one to the other. There will always have to be a place that decides what object has which components. This should be as close as possible to the 'aggregate root' (a term from DI), and generally in ECS at the point of instantiation of the entity. I believe this question is prompted by a fundamental misunderstanding of ECS.