When two moving objects collide, which one sends the message, and which one recieves it?

Question

I am writing a platform game using an entity-component system. Entity-World collisions are robust and work very well, and I'm now working on collisions between entities.

Just to be clear, in my code an Entity is a collection of Attributes (data) and a collection of pointers to Components (logic).

My Entity class has a sendMessage(messageType type, char* messageData) member function, which adds the messageType and messageData to a queue which is then used by the component interested in that message type. So in this example CollisionMessage is used by CollisionComponent and processed at the end of the tick with other messages (after normal collision checks).

My problem is that with every collision, I have two messages sent per collision, from each Entity to the other. This means that either I need to halve the forces I apply since it applies to each entity twice or I need to set up some Entities to only send collision messages and some to only receive collision messages.

So far things work fine when a player collides with an item, as it just gets picked up and removed from the world, but collisions between players and enemies are proving troublesome.

Is there a better way, or is there anything fundamental I've missed?

Thanks.

Answer 1

I don't think the collision should be handled by the entities at all, or by a component per entity, that need to be called by each entity.

If you only have two generic type of objects, for example actors and walls. Each time you collision detection loop runs, it will check the type of each object (a component provides this information?), for actor-wall one logic is executed, for actor-actor, another logic is executed. Lets assume walls cannot move without being promoted to actors (by changing the value of the relevant component), to maintain the system as simple as possible. No message is sent, anything happens inside the collision detection loop. For actor-actor, for example, each involved actor moves back half the length of the penetration vector. For actor-wall, the actor moves back full the length of the penetration vector, the wall does not move.

That is only an example. Having only two types of objects may not adapt to your game. And having the logic as part of the collision detection loop may not be suitable if you need many types of objects, or if all the types of objects are not known at design time (new types may be provided by loading a library later).

In resume: When two moving objects collide, which one sends the message, and which one receives it?

Answer: Do not use a message system at all. A message system is not suitable for this. The logic that handles the collision for a pair of entities must not by in the entity (or per entity component) and must run only once per pair, not two.

Answer 2

After discussion with @teodron, and some tinkering on my own, I think I've found something satisfactory and hopefully architecturally sound:

So previously any Entity that needed to collide with other objects and the world would have their position checked and modified in CollisionComponent. I've moved the tile/world collision code into a separate WorldCollisionComponent (which does detection and resolution) and I created a new EntityCollisionDetectionComponent, which will only do detection.

Previously, and here's where I think I was getting confused, I would do collision detection and resolution at the same time, and then I would send an additional message. I had the mental model of a Component acting on a particular Entity so each iteration was from the 'perspective' of the entity.

Instead, the EntityCollisionDetectionComponent will detect pairs of entities colliding and send each Entity a message with the details of the entity it collided with. Essentially, I'm marking an entity as collidable if it contains an EntityCollisionComponent.

I will have an EntitiyCollisionResolutionComponent, which will wait on messages and modify the PositonAttribute and VelocityAttribute of the Entity. Entities that don't need to be moved on collision (e.g. coins and other pickups) won't need this component added to it.

In code this would be something like:

class EntityCollisionDetectionComponent : public Component
{
public:
    void init() { /*...*/ }
    void cleanup() { /*...*/ }
    void update()
    {
        for (size_t i = 0; i < entities_.size(); ++i)
        {
            for (size_t j = i; j < entities_.size(); ++j)
            {
                if (collision(entities[i], entities[j])
                {
                     entities[i]->sendMessage(ENTITY_COLLISION, entities[j]->data);
                     entities[j]->sendMessage(ENTITY_COLLISION, entities[i]->data);
                }
            }
        }
    }
private:
    // Actually a part of the base class.
    std::vector<Entity*> entities_;
}

class EntityCollisionResolutionComponent : public Component
{
public:
    void init() { /*...*/ }
    void cleanup() { /*...*/ }
    void update()
    {
        while (!messageQueue_.empty())
        {
            CollisionResponseMessage* msg = reinterpret_cast<CollisionResponseMessage*>(messageQueue_.front());

            Entity* entity = getEntityById(msg->entityId);
            /*

            ... (compute new position, velocity, etc) ...

            */

            messageQueue.pop();
        }
    }
private:
    // Actually a part of the base class.
    std::vector<Entity*> entities_;
    std::queue<char*> messageQueue_;
}

I'm not going to accept this answer, because although it's a starting point for my solution, there's still a couple of holes (e.g. I realized I should send messages to a message handler which then forwards it to components, instead of sending it to entities; I happened to read an article which talks about converting an existing codebase to Entity-Component design where the compatibility makes sense).

Also, I'm sure someone will have something to say about my use of char* and reinterpret_cast!

Perhaps if/when I refine my system I'll come back and update the answer and accept it, if no-one else has any other ideas.

Answer 3

The answer greatly depents on how you store your entities. A very straightforward solution could just check collisions against entities that are stored "after" the one currently being processed e.g. if you store your entities in an array and update in a for-loop do collision checks only on entities with a higher array index than that of the current entitiy. This way each possible collision is only triggered once.