Editing Dead Reckoning

This page should give information and suggestion on what Dead Reckoning (DR) is, how it is implemented, what it should be.


DR is a method to find the current position by measuring the course and distance from a past known point.  It is used in Distributed Interactive Simulation to conserve bandwidth in the communication between two different network entities, when exchanging position information of a moving object. It starts with a kinematic model of the object.

As a simple example, entity A controls an object which is a "tank". A second entity (B) receives position updates for the tank from A.  A updates the tank's position continuously as it changes, taking into account the environment, the tank's control inputs, and the (virtual) physics laws that the game imposes. A is the master (driver) of the tank.  B recreates the position and orientation of A's Tank locally using data provided by A. B's representation of the tank is a slave.

In a network with no delay and very high bandwidth, A can communicate the tank position and orientation to B any time it updates its own internal tank representation. B would update its internal copy of the tank, using the newest data to have arrived. In the real, inter-networked world, this is impractical because bandwidth is limited.

To conserve bandwidth, A and B could share a Dead Reckoning (DR) model of the tank. Instead of sending position updates any time it changes, A compares the (new) current tank position to a predicted tank position that is calculated using the DR model. If the "real" and predicted object representations are the "close enough" (within a certain tolerance of being the same) it does not send an update message to B. With no update received from A, B uses its own DR model to calculate the position of the tank. This calculated position is intended to be the actual current tank position with no more error than is allowed by the tolerance. However, the true tank position *is* updated periodically at a low rate, to allow for new player's entering in the game to become in sync. To enable all players' DR models to remain synchronized, DR model parameters are sent with the update messages.  This way, position updates are only sent when the present position cannot be accurately derived by the model data, reducing the amount of network bandwidth used.

In a fixed [[lag]] network, B has the "correct" representation of the object and its history, but delayed by the network lag. Lag can be at least partially compensated for by adding a measure of the lag to the DR model.

In a network with significant [[jitter]], the fastest packets arrive with a delay that is near the minimum path route, while others arrive later.  The tank updates from A to B not only arrive delayed, but with a change in that delay, causing effects of time compression and expansion that A is not aware of. DR will alter B's perception of A's tank because simple lag compensation is not able to keep the models in sync. This can result in the remote (to B) tank suddenly "jerking" to a new position when A sends a periodic update.

The examples most disruptive to game-play occur when A's tank is not under the influence of its control inputs, as when jumping or falling. In these cases, the world physics, the DR model and relatively few periodic updates from A determine the tank's trajectory.  With a jump as an example, A might only send updates at the start of the jump, halfway through the rising arc, at the top, halfway through the descent and then upon landing. If the lag varies significantly between these updates, the DR model makes invalid predictions which are "corrected" upon each update received, which force the tank to a new position.  The visual effect at player B's perspective is a tank that rapidly jumps between different positions and trajectories.

As with lag, jitter compensation can be incorporated into the DR model. However, by its nature, jitter is rarely constant and remains a challenge to overcome completely.

[[Category:Development]]