Dead Reckoning

1
Dead Reckoning

• References
• Gamasutra (1), Gamedev (1)
• Forum articles (1)

2
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
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
Dead Reckoning
If the motion is still within the DR threshold
(on Owner), no updates required.
point-to-point
linear
quadratic
5
DR Algorithm (point-to-point)

• No path
• Noticeably jerky unless one packet is received
  per frame

6
DR Algorithm (linear)
moves along this v, until

• Path does not consider change of velocity

7
DR Algorithm (quadratic)
moves along this v and a, until
NewPosition OldPosition Velocitytime
0.5Acceleration(time)2

• Path does not consider change of acceleration
  jerk

8
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
Smoothing

• Jerkiness due to sudden update of position
• Use smoothing algorithm to lessen the apparent
  jerkiness more later

10
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
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
DR Smoothing with Cubic Splines (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 R3
  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 Draftsmans Spline
14
Math of Hermite Curves

• h1(s) 2s3?3s2 1
• h2(s) ?2s3 3s2
• h3(s) s3 ? 2s2 s
• h4(s) s3 ? s2
• P(s) P1h1(s) P2h2(s) T1h3(s) T2h4(s)
• P(s)P1h1(s) P2h2(s) T1h3(s) T2h4(s)
• h1 6s2 ? 6s h2 ?6s26s h3 3s2 ? 4s1
  h4 3s2 2s
• Note end tangent vectors are dP/ds

15
Reparameterization
16
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
Details
The position gradually changes from P1 (s0) to
P2 (s1, tT)
Start a new spline by 1. Current p,v 2. New
p,v computed by p,v,a after time T