1. Dead Reckoning References: Gamasutra (1), Gamedev (1)1 Forum articles (1)1

2. Fall 20122 Introduction Fast-paced interaction in twitch games Players expect the level of performance of distributed games to approximate that of single computer/player game Solution: dedicated network (end-to- end latency 150-200 ms)

3. Fall 20123 Dead Reckoning From DIS (distributed interactive simulation) protocol of SIMNET project, DoD, USA Was for networking tank simulators Objectives: latency hiding, bandwidth reduction Basic Ideas: Agree in advance on a set of algorithms that can be used by all players to extrapolate the behavior of entities Update threshold: how far reality should be allowed to get from these extrapolations before a correction is issued

4. Fall 2012 4 Dead Reckoning [point-to-point] [quadratic] [linear] If the motion is still within the DR threshold (on Owner), no updates required.

5. Fall 20125 DR Algorithm (point-to-point) No path Noticeably jerky unless one packet is received per frame New packet [p]

6. Fall 20126 DR Algorithm (linear) moves along this v, until … New packet [p,v] Path does not consider change of velocity

7. Fall 20127 DR Algorithm (quadratic) moves along this v and a, until … NewPosition = OldPosition + Velocity*time + 0.5*Acceleration*(time) 2 New packet [p,v,a] Path does not consider change of acceleration – jerk

8. Fall 20128 PDU (protocol data unit) Data packet representing each entity Kinematic state: position, velocity, acceleration, orientation Other info: damage level, turret … Which dead reckoning algorithm to use Threshold: jerkiness vs. more PDUs to be sent

9. Fall 20129 Smoothing Jerkiness: due to sudden update of position Use smoothing algorithm to lessen the apparent jerkiness [more later]

10. Fall 201210 Extension Predictive Contract State-based, rather than kinematic-based State: “ drive along road to waypoint ”  If the definition of roads, the specific waypoint, the way of driving (right-side), … are known to all players, the vehicle could be computed w/o any network traffic Others: “ turn on/off the sensors ”, “ send out radio report ”

11. Fall 201211 Summary Dead reckoning is not free: every computer runs an algorithm to extrapolate each entity Trade processor cycles to reduced network use and apparent latency If all entities behave unpredictably all the time, DR offers little gain

12. Fall 201212 DR Smoothing with Cubic Splines (ref)ref Jerkiness is due to the sudden update of position The following method ensures smooth positional transition while ensuring accuracy by packet (server) updates Only cubic (parametric) curve can represent R 3 curve [quadratic curves are planar] Hermite curves are most common. Two points and their corresponding tangents need to be specified (by quadratic kinematics laws)

13. A Draftsman’s Spline Fall 201213

14. Fall 201214 Math of Hermite Curves h1(s) = 2s 3  3s 2 + 1 h2(s) =  2s 3 + 3s 2 h3(s) = s 3  2s 2 + s h4(s) = s 3  s 2 P(s) = P1h1(s) + P2h2(s) + T1h3(s) + T2h4(s) P ’ (s)=P1h1 ’ (s) + P2h2 ’ (s) + T1h3 ’ (s) + T2h4 ’ (s) h1 ’ = 6s 2  6s h2 ’ =  6s 2 +6s h3 ’ = 3s 2  4s+1 h4 ’ = 3s 2 – 2s Note: end tangent vectors are dP/ds

15. Fall 201215 s=0 t=0 s=1 t=T Reparameterization

16. Fall 201216 Algorithm When a packet [p,v,a] arrives, begin creating a cubic spline for next position Approximate (extrapolate) the [p,v] after time T A piece of Hermite curve is defined by two end points and two end tangents P1: current position T1: (scaled) current velocity P2: extrapolated position after T T2: (scaled) velocity after T T: estimated interval between packets

17. Fall 201217 Details New packet [p,v,a] Start a new spline by 1. Current [p,v] 2. New [p,v] computed by [p,v,a] after time T Move with current spline P1 T1 P2 T2 The position gradually changes from P1 (s=0) to P2 (s=1, t=T)