five-on-it / packages/protocol/src/snapshot-reader
packages/protocol/src/snapshot-reader
The one way a client reads its snapshot frames, whatever their kind: whole snapshots (kind 3, codec.ts), the ordered deltas (kind 5, snapshot-v2.ts) over a reliable socket, and the acked deltas (kind 6, snapshot-acked.ts) over a transport that loses, duplicates and reorders frames.
- A frame whose tick is not newer than the last one shown is stale and dropped: the game never goes back in time, whatever came late.
- The server switches a client between the ordered and the acked deltas when its transport changes; the first frame of the new kind is a keyframe, and a frame of the new kind that is not one is dropped until it comes.
- What a frame tells of its entities (
FrameNews, against the last frame shown) is what the game relies on:changed, the entities whose state differs;posed, those whose pose the frame carried, each with the tick it was measured at (the only samples a client records: a far entity whose pose was not sent is never pushed again where it was);removed, those gone or born again under their id (a whole snapshot's are told from the one before it by their generation);tiers, how often each one's pose comes. - The events come out once: the acked frames repeat them until acknowledged, the reader shows each above the newest serial shown.
- SnapshotReader.ack is the tick the client acknowledges in its input frames.
A lost thread of the ordered deltas still asks for a keyframe (resync); the acked ones never do.