You need something that finds collisions between objects (it could be a physics engine, or a homegrown collision algorithm), call it 'WorldCollider'. WorldCollider has to know the positions and bounds of all objects - this is unavoidable, elsewise every object will need to deal with collisions.

But WorldCollider only finds collisions, it shouldn't know what to do with them (else you would have to hardcode all your collision responses). So, instead it should trigger some sort of callback.

An example (in very awful pseudo-code):

interface PhysicalObject {
  vec3 getPosition();
  box  getBounds();

  void collidedWith(PhysicalObject other);
}

class WorldCollider {
  list<PhysicalObject> objects;

  void findCollisions() {
    for o in objects:
      for p in objects:
        if collides(o, p):
          o.collidedWith(p)
          p.collidedWith(o)
  }
}

This will get the job done, but it's far from ideal. Among other things, you should probably use some sort of spatial hash to implement collides().

The real problem, is how you tell what type of object you have collided with. All you are handed is the PhysicalObject interface, but you need to know whether it is a bullet, an enemy, or something else entirely.

The correct way to solve this is double-dispatch, but unfortunately a lot of mainstream languages don't support that very well. In practice, you either get cute with mutually-recursive virtual function calls, or you fall back to a chain of instanceof() calls in each callback.

At most, you bounce from one object to the other via virtual functions in order to get the subject defined.

Maybe I misunderstood something crucial, but it seems to me that nothing is actually "defined"; There is no need for type inference because every object implements the required interaction methods.

Right?

So, you are in one of the two objects. If the object you are running from is a projectile or whatever, they just call a "take damage" function on the target object (target/dest is well understood from the point of view of the projectile). Static indestructible objects ignore the call, player vehicles take the given data and apply it via some rules system. If on the other hand, the first object was a player vehicle it calls "collide" on the other object using itself as a parameter. A "projectile" implements collide by simply calling "take damage" on the source. It is completely circular logic but the idea is that the "subject" is always correctly dealt with even if it takes 2 virtual function calls to get it done. A vehicle to vehicle collide of course would do whatever is appropriate.

Yes and no.

I understand the yes, but not the no:

Projectile::interact(subject): subject->take_damage(this)

Car::interact(subject): subject->collide(this)

Projectile::collide(subject): this->interact(subject)

This assumes that interact, take_damage and collide are all valid method calls regardless of subject type. So, every object has to implement those, and other relevant methods.

snip

That is pretty much what I meant by "getting cute with mutually recursive virtual functions".

Virtual functions implement single dispatch, so you can simulate double dispatch with a pair of complementary virtual functions.

Another example could be A.I. An AI actor needs to have knowledge of the world around it in order to make decisions and act appropriately, for example, navigating the environment, or targeting the player. Meaning it would need to know at a minimum the players position, and position of other objects(terrain, walls, obstacles, ect.), and likely a whole lot more information for a more involved A.I.

Again, you need something to have fairly global knowledge - I tend to call this the 'Environment'. Each AI has a reference to the Environment, and they can query it for opponents, obstacles, and such.

The environment also acts as a form of access control, by only letting individual AIs have the set of knowledge they should be aware of. For example, the enemy AI probably shouldn't know the location of the player when the player is hiding behind a wall, so the Environment runs cover-checks and keeps that data private as necessary...

I have a class i have named "AbstractCollider".

It represent ANY colliding object in the world, and my primary motivation for having it was to be able to use a broadphase to find potential collisions.

It contains:

{

ColliderType (sphere, terrain, projectile...)

ColliderID (so its like 5th sphere, 1000244th projectile...)

BodyID (so the broadphase knows where it is)

...

}

Now, when i have 2 of those (potential collision), i look up a collision detector class from a 2D grid based on the types of the 2 colliders. This means i have classes like SphereToSphereCD, SphereToProjectileCD, TerrainToProjectileCD... for each type pair (i reuse the objects when its the same 2 types but different order) all implementing virtual void detectCollidions(Collider&, Collider&)

They then dump the detected collisions to a big list which i then iterate through and apply forces and stuff (collision resolution). The collisions contain information like depth of penetration, collision normal, the colliding bodies ids (the 'abstract' ones), collision location...

That allows having multiple types of objects collide with each other without doing it in O(N^2) (which wouldnt require this layer)

Now, to act on those collisions, you need some kind of "collision callback" system which allows you to add in a handler that is called for collisions. This handler could handle all collisions, or it could handle collisions with a single object (the first needs a single reference in the physics system, the second needs every object to store their own "collision handler" reference) depending on what you need. The more specific ones need more memory and the less specific ones need more checks and branching in the handler since it needs to deal with everything. I would use a CollisionHandler class that again implements a virtual method.

Now, that allows you to know when a collision happens, and which 2 physics bodies it happens between. If the bodies are the same objects as the game objects (as in you have "Player" be a shape that can collide) thats all you need, but in a more flexible system the colliding 'shapes' will only be a part of the entities and you cannot identify the entities from them. So, you need the shapes or the abstractcollider objects to tell what entity owns them. This can be a simple entity ID.