State Sync — Snapshots and Deltas
Sixteen screens must show the same kites in the same places, even though every player sits 15 to 35 ms away from the server and packets sometimes vanish on the way. The server's answer is to keep telling every client what the world looks like, as cheaply as it can, and let each client smooth over the gaps.
The rule
Snapshot the truth, send only what changed, draw between two.
Snapshot. After each tick, the server captures the state a client needs to draw the match: each kite's id, position, heading, string tension and flags, plus slower-changing things such as scores, player names and kite colours. The fast-changing kite part packs into 8 bytes per kite, so all 16 kites fit in 128 bytes.
Delta. Much of each snapshot repeats what the client already knows. A kite resting on its rooftop has not moved, and names and colours never change during a match. So the server sends only the difference between the new snapshot and a baseline: a snapshot the client has confirmed it received.
Interpolation. The client does not draw each snapshot the instant it lands. It draws the world slightly in the past, say 100 ms, which is two ticks at 20 Hz, sliding each kite smoothly between the two snapshots on either side of that moment. A single late or lost packet then causes no visible stutter, because the next snapshot is usually already waiting.
Why must the baseline be a confirmed snapshot rather than simply the last one sent? Because the last one sent may have been lost. A delta says "change state A into state B", and it is useless to a client that never received state A.
Your own kite is a special case. Waiting a full round trip to see it respond would feel sluggish, so the client usually moves it straight away from your own inputs, a technique called client-side prediction, and quietly corrects it whenever a snapshot from the server disagrees. The server still decides.
The shortcut
Keep one note per client: "the last snapshot this client confirmed." Every delta for that client is computed against that tick, and nothing else.
The client confirms tick 200
Its latest packet to the server says "I have snapshot 200". The server records 200 as this client's baseline.
One more trap: if a client stops confirming for a long time, its deltas keep growing. Once a delta would be bigger than a full snapshot, send the full snapshot instead.
Drills
Answer fast — trust the rule.
Why does the server build a delta against the last snapshot the client confirmed, rather than the last one it sent?
A client draws the world 100 ms in the past, and snapshots arrive at 20 Hz. How many snapshot intervals behind is that?
Which part of a snapshot is left out of almost every delta during a match?
The kite part of a full snapshot is 128 bytes. Without deltas, how many bytes of kite data per second does the server send at 20 Hz to all 16 players?
Why does the client interpolate between two snapshots instead of snapping each kite to the newest position?
Remember
- Snapshot the truth, send only what changed, draw between two.
- Every delta is computed against the last snapshot that client confirmed.
- Trap: a delta against an unconfirmed snapshot. One lost packet and the client can no longer follow.