3 ms·

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on the components that they have. Moreover, neither entities nor components on their own actually own any behaviour. Behaviour occurs by systems that operate on entities with the associated component "signature". For example, an entity with a position and a velocity component (position could hold x,y,z values and velocity vx,vy,vz values) could be operated on by a movementSystem (which adds behaviour to any entities that have both a position and velocity component, and updates position values based on velocity values.) The nice thing about such a system is that the taxonomy as you call it gets defined when you instantiate the systems of your program. If you have entities with position and velocity components but dont want to use a movementsystem to operate on them, you simply dont instantiate the movementsystem. Pretty flexible, but not used excessively outside of video games.

jwdunne 9y ago
Thank you - I think this was probably the inspiration or seed for what I was thinking :) I was amazed when I saw the ECS architecture when I filled my toe into game development. I remember wanting to apply it to other areas outside of game development. It's interesting though that a paradigm that intends to help simulate the real world has been eschewed for speed and maintainability in favour of something like ECS in game development, which is all about simulation.
- dyarosla 9y ago
  Yeah it's an interesting pattern and even when implemented in an OOP language ignores most OOP ideas in favour of what is really more akin to data-driven design. There's some great insight into how the pattern evolves in non-game projects here: https://softwareengineering.stackexchange.com/a/306983/271434 https://softwareengineering.stackexchange.com/a/306983/27143...
  - magnusjonsson 9y ago
    That's an awesome article! Thanks for sharing.
MikkoFinell 9y ago
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?
  - 9y ago
adrianratnapala 9y ago
ECS as you describe it sounds like a good idea, but notice how it is a step away from OO which was supposed to keep code and data in a single encapuslated thing called an "object". Now our componenents are nearly just plain-old-data and entities are slightly more sophisticated data-structures for tying them together. All the code is now kept is "systems", which are starting to look very much like plain-old modules. No doubt the OO language will give you some useful tidbits, so that you can have slightly non-trivial getter setters and whatnot. But the design ends up fundamentally procedural -- which I say is good thing.
- dyarosla 9y ago
  Yes, ECS is very much not OOP.

jwdunne 9y ago

Thank you - I think this was probably the inspiration or seed for what I was thinking :) I was amazed when I saw the ECS architecture when I filled my toe into game development. I remember wanting to apply it to other areas outside of game development. It's interesting though that a paradigm that intends to help simulate the real world has been eschewed for speed and maintainability in favour of something like ECS in game development, which is all about simulation.

dyarosla 9y ago
Yeah it's an interesting pattern and even when implemented in an OOP language ignores most OOP ideas in favour of what is really more akin to data-driven design. There's some great insight into how the pattern evolves in non-game projects here: https://softwareengineering.stackexchange.com/a/306983/271434 https://softwareengineering.stackexchange.com/a/306983/27143...
- magnusjonsson 9y ago
  That's an awesome article! Thanks for sharing.

MikkoFinell 9y ago

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?
- 9y ago

adrianratnapala 9y ago

ECS as you describe it sounds like a good idea, but notice how it is a step away from OO which was supposed to keep code and data in a single encapuslated thing called an "object". Now our componenents are nearly just plain-old-data and entities are slightly more sophisticated data-structures for tying them together. All the code is now kept is "systems", which are starting to look very much like plain-old modules. No doubt the OO language will give you some useful tidbits, so that you can have slightly non-trivial getter setters and whatnot. But the design ends up fundamentally procedural -- which I say is good thing.

dyarosla 9y ago
Yes, ECS is very much not OOP.