I'm writing my own game engine for learning purposes and was wondering about common ways to handle collision callbacks/responses. I'm NOT looking for ways to resolve collisions (no math needed here), I just want to know how systems are commonly set up to respond to one another.

For example, what I have designed now is a system where any entity, if they want to interact with the physical world, adds one of a few predefined shapes to the "physical objects list". One entity might want to add two squares to use as various bounding boxes, another entity might just add a circle as a collision area etc. Once every iteration, the collision detection system looks for collisions, and if it finds one, it checks the shape object's "parent" (the entity that added the shape) and notifies it of a collision and passes it a vector that can resolve it.

Even if someone can simply point me to an article that discusses this concept I would be grateful, as I haven't found any with some basic Google searches. (I also wouldn't know what to call this, collision callback is a term I made up, not sure if it makes sense).

  • \$\begingroup\$ "Collision callback" is definitely an understandable and used term. Sometimes "collision listener" is being used also. \$\endgroup\$
    – bummzack
    Jan 30, 2012 at 23:22
  • \$\begingroup\$ Check out the Bullet Physics manual (and documentation/source if you like it), it explains how its callbacks work quite nicely \$\endgroup\$
    – Aralox
    Jan 31, 2012 at 0:04

1 Answer 1


Some engines, like Havok, let you implement your own handling.

Havok has 2 main types of collision bodies. For rigid bodies, Havok sends a callback for each unique collision point that happens. For "phantoms" which are convex shapes (or a list of convex shapes), you can listen for either per-point collision, or register for a broadphase AABB callback, which means you will get a callback any time something enters the smallest AABB that encompasses your other physics body. The system we setup at my last project for the per-point collision was each frame to create a collision map, when a collision occurred between two bodies, if those two bodies were already in the map then we skipped it, and by the end of the collision step we had a map of every object that was colliding with something, and what it had collided with. We kept the map from the previous frame, and by comparing last frame to this frame we know which collisions were new (occurred this frame but not last frame), and which collisions were no longer happening (occurred last frame but not this frame). Based on this we sent messages for new collisions, and collisions that had ended to each object that cared about collision checks.

JigLib and JigLibX have an almost identical system to Havok's in terms of sending collision points every frame (or every physics step).

Other physics engines likely do something similar to this. By doing things this way you have all the information you need for each collision contact, which can be used for other things than collision response events, but because you do have each contact event you have enough information to setup your own response system as well.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .