Game Development Reference
particularly important with respect to the forces acting on the model. For example, you
could have some objects representing projectiles with others representing aircraft. These
different classes will share some common code (for example, collision detection); how‐
ever, the way forces are computed on each will vary due to the differences in how they
are modeled. With such an approach, each class must have code that implements its
particular model. During integration, the entire list will be traversed, calling the force
aggregation method for each object, and the particular class will handle the details suit‐
able for the type of object.
In some simple cases, you need not use different object classes if the types of objects
you plan to use are not too different. For example, it would be fairly straightforward to
implement a single class capable of handling both particles and rigid bodies. The object
class could include an object type property used to denote whether the object is a particle
or a rigid body, and then the class methods would call the appropriate code. Again, this
will work satisfactorily for simple objects with few differences. If you want to simulate
more than two types of objects or if they are very different, you're probably better off
using different classes specific to each object being simulated.
However you structure your classes or lists, the flow of processing your objects will
generally be the same. Every physics tick —that is, every time step in the physics simu‐
lation—you must check for object collisions, resolve those collisions, aggregate the usual
forces on each object, integrate the equations of motion for each object, and then update
each object's state.
As we said, this is the general flow at every physics tick, or time step, which may not be
the same as your rendering steps. For example, for accuracy in your simulation you may
have to take small steps around a millisecond or so. You wouldn't want to update the
graphics every millisecond when you need only about a third as many graphics updates
per second. Thus, your objects manager will have to be integrated with your overall
game engine, and your game engine must be responsible for making sure the physics
and graphics are updated appropriately.
If collisions are an important part of your game, then a robust collision detection system
Your collision detection system is distinct from the collision response system or module,
though the two go hand in hand. Collision detection is the computational geometry
problem of determining if objects collide and, if so, what points are making contact.
These points are sometimes called the contact manifold . They're just the points that are
touching, which could be a line or surface, though for simplicity usually the point, end
points, or points defining the contact surface boundary are all that are included in the