Game Engine Architecture

765

prior to fi nal pose generation, and once aft er fi nal pose generation. This can
be accomplished by providing each game object class with three virtual func-
tions that act as “hooks.” In such a system, the game loop ends up looking
something like this:

while (true) // main game loop

{

// ...

for (each gameObject)

{

gameObject. PreAnimUpdate(dt);

}

g_animationEngine. CalculateIntermediatePoses(dt);

for (each gameObject)

{

gameObject. PostAnimUpdate(dt);

}

g_ragdollSystem. ApplySkeletonsToRagDolls();

g_physicsEngine. Simulate(dt); // runs ragdolls too

g_collisionEngine. DetectAndResolveCollisions(dt);

g_ragdollSystem. ApplyRagDollsToSkeletons();

g_animationEngine. FinalizePoseAndMatrixPalette();

for (each gameObject)

{

gameObject. FinalUpdate(dt);

}

// ...

}

We can provide our game objects with as many update phases as we see
fi t. But we must be careful, because iterating over all game objects and calling
a virtual function on each one can be expensive. Also, not all game objects
require all update phases—iterating over objects that don’t require a particu-
lar phase is a pure waste of CPU bandwidth. One way to minimize the cost
of iteration is to maintain multiple linked lists of game objects—one for each
update phase. If a particular object wants to be included in one of the update

14.6. Updating Game Objects in Real Time