Collision System

Class Diagram

  • CollisionManager: A member of every scene and responsible for tracking and performing all Collision tests, through a list of CollidableGroups and CollisionTestCommands.
  • Collidable: The class that contains all the functionality for collision. Is what all GameObjects that want to have collision need to extend.
  • CollisionTestCommand: Contains the logic for performing collision tests as well as the CollidableGroups it will be testing and the CollisionDIspatch it will use to callback. Created by the CollisionManager.
  • CollidableGroup: A container for all the registered Collidables.
  • CollisionVolume: An abstract class that all CollisionVolumes extend from. Contains all the information necessary to perform collision tests.
  • CollisionDispatchProxy: A Proxy class used to callback to the users Collision functions. A proxy is used to hide the templates from the CollisionTestCommands and kick the responsibility for casting from the Collidables to the templated class off to the implemented CollisionDispatch.

Tiered Tests

My collision system uses a tiered testing system which avoids performing the more costly collision tests until the cheaper ones have passed.

As you can see above, the CollisionManager updates the group collision volumes every frame before running the collision tests. It does so using the primitive Bsphere volume of each Collidable. Finding the Max/Min of the entire group using the center and radius of each one.

The collision tests themselves are your basic geometric collision tests, however, you’ll notice they are all abstracted away using a Visitor pattern, and a function call to EngineMath. The visitor pattern allows us to abstract away the different volumes in the tests, while the EngineMath class compartmentalizes the math behind the code to make testing and such much easier.

This system allows for scenes like this one from my game TANKS to run smoothly despite the MANY collision tests being run.