Swept-Polygon Collision Detection

Like most collision systems, Torque Game Builder detects collisions in two phases. First, broad-phase, early-out collision is very common in collision detection schemes. The goal is to very quickly determine objects that will definitely not collide with each other, so that you don't have to check these objects against each other in the next, much more expensive narrow-phase of exact object-object collision detection. Once TGB is done deciding what objects definitely will not collide with each other, it has a much smaller (hopefully) list of objects which might possibly collide with each other. TGB is then capable of performing swept-polygon collision detection, which can detect both overlapping objects, and disjoint objects which collide in forward-time.

Collision Polygons

Collision polygons can be applied to any object as either a regular polygon with any number of sides or a custom convex polygon. This means that you can define tight-fitted custom polygons for your sprites which are sized along with the sprite, making it possible to create nicely accurate collision systems while alleviating the need to constantly adjust the collision polygons.

Individual Collision Causation and Response

Objects can be configured to "send" and/or "receive" collisions. So, you can create objects which can cause collisions in other objects, but are themselves immune to being affected by collisions (maybe bullets would have this profile. Tiles have this profile in TGB by default). Or, you can create objects which don't cause collisions themselves, but can be affected by colliding with other objects (feathers?). Or create objects that do neither and are exempted from the collision system altogether. Note as well that these settings can be dynamically twiddled, so you can switch on or off an object's ability to send or receive collisions at any time.

Restrict Collisions Between Layers or Groups

Objects can also be assigned to layers, and to groups, and these layers and groups can be used in collision detection. For example, you might turn off friendly fire by assigning objects on the same team and their projectile fire to the same group, and turning off their collision with the team's group. Besides offering fine-grained control over the kinds of collisions you want different objects to have, this layer and group system also allows you to speed up collision detection. Collision detection is an expensive operation, and this can especially be true when you're dealing with accurate swept-polygon collision, as TGB does. So, by specifying that an object should only collide with particular layers and groups, you can reduce the collision search space substantially, speeding up the entire process.

Collision Reactions

Objects can be configured with a script collision callback function to generate some sort of reaction upon collision. One obvious use of this system would be to generate explosions at the points of contact between two objects. Or, your collision script might implement its own custom physics processing system... maybe you want some of your objects to actually deform upon collision.

Prototype-Based Configuration

Objects can be very precisely configured for various collision behaviors, and the system itself is very easy to extend or over-ride, even just in script. Also, these settings can be declared in datablocks, so you can create prototype datablocks for collision settings and share them across many objects, making it even quicker and easier to get collision set up.