More fun with an ES...
Currently, I have a few systems:
- Renderer (Renderable attribute, Transform attribute)
- Motion (Movable attribute, Transform attribute, Renderable attribute [for bounding boxes, etc])
- Input (InputReceiver attribute)
- etc.
I'm adding collision detection. My first thought was to add a new system that performs collision. It makes sense to me to keep this isolated from the Motion system since not all things that move or are animated necessarily participate in collision detection - cameras, fog, etc. - but it seems that Collision and Motion are interdependent.
When Motion moves an entity, the transformation needs to be validated with Collision, and the movement either cancelled, or adjusted (bouncing, stopping at a wall, etc.).
An alternative would be to create a Collidable attribute that maintains a reference to a collision object - kd-tree, octree, etc. that is shared among entities that can collide with one another. The Motion system would then check for that attribute, and use it to check or adjust movement.
From a code perspective, that's an acceptable solution. However, from an ECS architecture point of view, it seems that it's pushing logic into the Motion system that doesn't apply to all of the entities that have a Movable attribute.
I could also store a motion vector in the Movable attribute, and have the Collider system adjust Transform as needed, but that'll involve duplicating functionality between Motion and Collider, or a callback from Collider to Motion with some data about the collision location and surface data for bounce/reflection, etc.
This may fall under the heading of "special case hack" but I'd like to get some input from those that have handled this before without creating a ton of edge case code.
The Question What's a good way to avoid tight coupling between motion and collision systems when it seems that they require knowledge of each other?
