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)
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
Motion are interdependent.
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
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
Collider, or a callback from
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?