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

Fall 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 ms)

Fall 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

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

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

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

Fall 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

Fall 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

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

Fall 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 ”

Fall 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

Fall 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)

A Draftsman’s Spline Fall

Fall Math of Hermite Curves h1(s) = 2s 3  3s 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

Fall s=0 t=0 s=1 t=T Reparameterization

Fall 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

Fall 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)