Game Engine Architecture

(Ben Green) #1
771

14.6.3.5. Time-Stamping


One easy and low-cost way to improve the consistency of game object states
is to time-stamp them. It is then a trivial matt er to determine whether a game
object’s state vector corresponds to its confi guration at a previous time or the
current time. Any code that queries the state of another game object during
the update loop can assert or explicitly check the time stamp to ensure that the
proper state information is being obtained.
Time-stamping does not address the inconsistency of states during the
update of a bucket. However, we can set a global or static variable to refl ect
which bucket is currently being updated. Presumably every game object
“knows” in which bucket it resides. So we can check the bucket of a queried
game object against the currently updating bucket and assert that they are not
equal in order to guard against inconsistent state queries.


14.6.4. Designing for Parallelism


In Section 7.6, we introduced a number of approaches that allow a game en-
gine to take advantage of the parallel processing resources that have become
the norm in recent gaming hardware. How, then, does parallelism aff ect the
way in which game object states are updated?


14.6.4.1. Parallelizing the Game Object Model Itself


Game object models are notoriously diffi cult to parallelize, for a few reasons.
Game objects tend to be highly interdependent upon one another and upon
the data used and/or generated by numerous engine subsystems. Game ob-
jects communicate with one another, sometimes multiple times during the up-
date loop, and the patt ern of communication can be unpredictable and highly
sensitive to the inputs of the player and the events that are occurring in the
game world. This makes it diffi cult to process game object updates in mul-
tiple threads , for example, because the amount of thread synchronization that
would be required to support inter-object communication is usually prohibi-
tive from a performance standpoint. And the practice of peeking directly into
a foreign game object’s state vector makes it impossible to DMA a game object
to the isolated memory of a coprocessor, such as the PLAYSTATION 3’s SPU,
for updating.
That said, game object updating can theoretically be done in parallel.
To make it practical, we’d need to carefully design the entire object model
to ensure that game objects never peek directly into the state vectors of oth-
er game objects. All inter-object communication would have to be done via
message-passing, and we’d need an effi cient system for passing messages be-


14.6. Updating Game Objects in Real Time

Free download pdf