You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a perfect world, each component would be completely autonomous and not need information on any other component, happily running in it's own little pocket of the simulation. Such a world isn't our world. Having one component per subsystem isn't practical or recommended. Many components can get by in simple cases without having to resort to getting information from another component, but some more sophisticated components cannot.
Some examples:
We have a RenderableProxy and we have plans to extend the graphics system to wrap animations. It is commonplace in other ECSs to have a separate Mesh and Animation components. Simply omit the functionality if the object doesn't need it, the core goal of any ECS. An animation component would still need to have access to the Mesh, hence needs to be aware of another component.
In the past I attempted to implement sticky behavior on RigidProxies. This was bad form due to not everything needing such functionality, but if I were to try this again post ECS refactor it would make sense to have a sticky component that would reference a RigidProxy and create a constraint as appropriate.
Sticking a pointer onto these proxies is straightforward, however may be unsafe to do so if components are removed at runtime during the Entity lifetime (which we currently support). Worse, if they truly depend on the other component(s) then they shouldn't continue to exist after the dependee component is removed. So at a minimum some mechanism will need to be made to allow some components to be notified about the removal of other components.
In a perfect world, each component would be completely autonomous and not need information on any other component, happily running in it's own little pocket of the simulation. Such a world isn't our world. Having one component per subsystem isn't practical or recommended. Many components can get by in simple cases without having to resort to getting information from another component, but some more sophisticated components cannot.
Some examples:
Sticking a pointer onto these proxies is straightforward, however may be unsafe to do so if components are removed at runtime during the Entity lifetime (which we currently support). Worse, if they truly depend on the other component(s) then they shouldn't continue to exist after the dependee component is removed. So at a minimum some mechanism will need to be made to allow some components to be notified about the removal of other components.
This is 11. on #134 .
The text was updated successfully, but these errors were encountered: