Snapshot Compression

In the previous article we sent snapshots of the entire simulation state 10 times per-second over the network and interpolated between these snapshots to reconstruct a view of the simulation on the other side.

The problem with such a low snapshot rate is that interpolation between snapshots adds interpolation delay on top of network latency. At 10 snapshots per-second the minimum interpolation delay is 100ms and a more practical minimum considering network jitter is 150ms. If protection against one or two lost packets in a row is desired then this delay blows out to 250ms or 350ms.

This is not an acceptable amount of delay for most games. The only way to reduce this delay is to increase the snapshot send rate. Since many games update at 60fps lets try sending snapshots 60 times per-second instead of 10. Unfortunately this comes at the cost of increased bandwidth, not only because we’re sending the same amount of data more frequently, but also because with each packet sent there is packet header overhead.

This sounds obvious but at 60 packets per-second we send six times the number of UDP/IP packet headers than we do at 10 packets per-second. I use a rule of thumb when calculating bandwidth that packet header overhead is around 32 bytes per-packet. This is not exact but it give you an idea of the typical magnitude. Multiply this by 60 and you’ll see it’s not a trivial amount of bandwidth. This creates a bandwidth floor that you cannot reduce below. The header sizes are even larger for IPv6.

There’s nothing we can do about the packet header overhead, but we can optimize everything else in the packet. So what we’re going to do in this article is work through every possible bandwidth optimization (that I can think of at least) until we get the bandwidth under control. For this application lets set a target bandwidth of 256 kilobits per-second.