Game Engine Architecture

(Ben Green) #1

760 14. Runtime Gameplay Foundation Systems


times per frame. It might seem reasonable and intuitive to simply update all of
these subsystems directly from within the game object’s Update() function.
For example, consider the following hypothetical update function for a Tank
object:
virtual void Tank::Update(float dt)
{
// Update the state of the tank itself.
MoveTank(dt);
DeflectTurret(dt);
FireIfNecessary();
// Now update low-level engine subsystems on behalf
// of this tank. (NOT a good idea... see below!)
m_pAnimationComponent->Update(dt);
m_pCollisionComponent->Update(dt);
m_pPhysicsComponent->Update(dt);
m_pAudioComponent->Update(dt);
m_pRenderingComponent->draw();
}

Given that our Update() functions are structured like this, the game loop
could be driven almost entirely by the updating of the game objects, like this:
while (true)
{
PollJoypad();
float dt = g_gameClock.CalculateDeltaTime();
for (each gameObject)
{
// This hypothetical Update() function updates
// all engine subsystems!
gameObject.Update(dt);
}
g_renderingEngine.SwapBuffers();
}

However att ractive the simple approach to object updating shown above
may seem, it is usually not viable in a commercial-grade game engine. In the
following sections, we’ll explore some of the problems with this simplistic ap-
proach and investigate common ways in which each problem can be solved.
Free download pdf