Interleaving systems in ECS (entity component system)?

Question

I'm working on adding physics to an Entity System and am confused about the systems part of ECS.

For example, in a non-ECS project I might have something like this:

function updatePhysics()
    foreach(thisRobot in robots)
        thisRobot.move()
        foreach(otherRobot in robots)
            if(response = thisRobot.isColliding(otherRobot))
                thisRobot.resolveCollision(response)

However in the ECS project, I would have a MovementSystem that operates on a PositionComponent and a VelocityComponent as well as a CollisionSystem that operates on a PositionComponent and a ShapeComponent. The result being something like:

MovementSystem
    function update()
        foreach(entity in entities)
            this.move(entity)

CollisionSystem
    function update()
        foreach(thisEntity in entities)
            foreach(otherEntity in entities)
                if(response = this.isColliding(thisEntity, otherEntity)
                    this.resolve(thisEntity, response)

The difference being that in the non-ECS version the movement and collision are interleaved where as in the ECS version they are seperated. Is there a normal pattern to model this behavior in entity systems? I know the whole point of ECS is to get away from inheritance, but perhaps having both MovementSystem and CollisionSystem be part of a more general PhysicsSystem which calls the other systems update functions on a single entitiy rather than each system maintaining their own loops?

Answer 1

In an ECS structure, your movement system doesn't care about your physics. The physics would have a system of it's own.

The Movement system updates a Position component based on some other component, say, Velocity.
The Physics system updates the Velocity component based on forces.
And the Collision system updates both the Position and Velocity components based on collisions (intersects with other objects).

Pseudocode:

MovementSystem {
    void Process(Entity e){
        e.GetComponent(PositionComponent).position += e.GetComponent(VelocityComponent).velocity;
    }
}

PhysicsSystem {
    void Process(Entity e){
        e.GetComponent(VelocityComponent).velocity += World.gravity;
        //And other physical forces being applied to the entity.
        //I guess you could have a 'Forces' component.
    }
}

CollisionSystem {
    void Process(Entity e){
        var collisions = SomeFunctionThatChecksCollisionsWithTheEntityInTheScene(e);

        foreach(collision in collisions) {
            e.GetComponent(VelocityComponent).velocity +=
                SomeFunctionToApplyForceBasedOnCollision(collision);
            e.GetComponent(PositionComponent).position +=
                SomeFunctionToOffsetAwayFromTheCollisionIntersection(collision);
        }
    }
}

Answer 2

Not every entity that moves is influenced by physics in a simulation...

I would split the MovementSystem into two types

1. Movement for entities which are physics influenced.
2. Movement for entities which are not physics influenced.

In the case of the latter, you can go ahead and take the direction on the MovementComponent in combination with the speed on the VelocityComponent and calculate the movement and position of the entity.

In the case of the former, you will need to allow physics to run its simulation, determine collisions and handle those. In either case, you'd need to then update the position for all entities influenced by physics.

So from a loop perspective, I'd expect to see

1. Input system captures key/mouse input.
2. Player controller system analyzes input and generates intent as appropriate.
3. Run the movement for non-physics influenced entities.
4. Execute the RigidBodyMovementSystem
5. Resolve collisions
6. Update position for all physics influenced entities.

Remember that even based on how you describe your systems, they can be decomposed into smaller system components that specifically handle one smaller task and the output from that step is the input to another system.

Answer 3

A straightforward approach could be to add to the movement component a desired destination along with the actual one. Then update only the former within the movement system.
On the other side, the collision system will try to apply the new position by switching it with the desired one and check for collisions one entity at a time.

Another approach could be to update only velocities within the movement system. Then add a more general physics system that updates position for an entity at a time and check for collisions, adjusting velocity and position if needed.

You can even define a single system that does exactly what you did previously: iterate over all the entities, update position for an entity at a time and check for collisions, then proceed with the next entity.
You don't have necessarily to separate movement system and collision system, do what sounds good for you and your game.