Editing Dead reckoning (section)

== For networked games ==
Networked games and simulation tools routinely use dead reckoning to predict where an actor should be right now, using its last known kinematic state (position, velocity, acceleration, orientation, and angular velocity).<ref name="Murphy2011">Murphy, Curtiss. ''[https://books.google.com/books?id=ujfOBQAAQBAJ&dq=%22Believable+Dead+Reckoning+for+Networked+Games%22&pg=PA307 Believable Dead Reckoning for Networked Games]''. Published in Game Engine Gems 2, Lengyel, Eric. AK Peters, 2011, p 308-326.</ref> This is primarily needed because it is impractical to send network updates at the rate that most games run, 60&nbsp;Hz. The basic solution starts by projecting into the future using linear physics:<ref>Van Verth, James. ''Essential Mathematics for Games And Interactive Applications''. Second Edition. Morgan Kaufmann, 1971, p. 580.</ref>

<math display="block">
    P_t = P_0 + V_0T + \frac{1}{2}A_0T^2 
</math>

This formula is used to move the object until a new update is received over the network. At that point, the problem is that there are now two kinematic states: the currently estimated position and the just received, actual position. Resolving these two states in a believable way can be quite complex. One approach is to create a curve (e.g. cubic [[Bézier curve|Bézier splines]], [[centripetal Catmull–Rom spline]]s, and [[Cubic Hermite spline|Hermite curves]])<ref>Lengyel, Eric. ''Mathematics for 3D Game Programming And Computer Graphics''. Second Edition. Charles River Media, 2004.</ref> between the two states while still projecting into the future. Another technique is to use projective velocity blending, which is the blending of two projections (last known and current) where the current projection uses a blending between the last known and current velocity over a set time.<ref name="Murphy2011"/>

* <math>    V_b = V_0 + \left (\acute{V}_0 - V_0 \right)\hat{T}  </math>
* <math>    P_t = P_0 + V_bT_t + \frac{1}{2}\acute{A}_0T_t^2 </math>
* <math>    \acute{P}_t = \acute{P}_0 + \acute{V}_0T_t + \frac{1}{2}\acute{A}_0T_t^2 </math>
* <math>    Pos = P_t + \left (\acute{P}_t - P_t \right)\hat{T} </math>

The first equation calculates a blended velocity <math>V_b</math> given the client-side velocity at the time of the last server update <math>V_0</math> and the last known server-side velocity <math>\acute{V}_0</math>. This essentially blends from the client-side velocity towards the server-side velocity for a smooth transition. Note that <math>\hat{T}</math> should go from zero (at the time of the server update) to one (at the time at which the next update should be arriving). A late server update is unproblematic as long as <math>\hat{T}</math> remains at one.

Next, two positions are calculated: firstly, the blended velocity <math>V_b</math> and the last known server-side acceleration <math>\acute{A}_0</math> are used to calculate <math>P_t</math>. This is a position which is projected from the client-side start position <math>P_0</math> based on <math>T_t</math>, the time which has passed since the last server update. Secondly, the same equation is used with the last known server-side parameters to calculate the position projected from the last known server-side position <math>\acute{P}_0</math> and velocity <math>\acute{V}_0</math>, resulting in <math>\acute{P}_t</math>.

Finally, the new position to display on the client <math>Pos</math> is the result of interpolating from the projected position based on client information <math>P_t</math> towards the projected position based on the last known server information <math>\acute{P}_t</math>. The resulting movement smoothly resolves the discrepancy between client-side and server-side information, even if this server-side information arrives infrequently or inconsistently. It is also free of oscillations which spline-based interpolation may suffer from.