A video is useful for watching the view someone captured. To follow a different player afterward, or inspect the line the server used to judge a shot, I needed a different kind of recording. Native demos save game state and evidence that the game can reconstruct after the match.
Ordinary players can choose to record. Competitive hosts record the server's authoritative track and require recording in the shipping client. The full files are collected explicitly after the match; they are not uploaded continuously through the gameplay connection.
Leaving the live match to inspect it
Opening a demo leaves the live match. The viewer can pause, seek to another moment, change playback speed, follow a player or use a free camera. It has no live connection and cannot send recorded inputs back to a server.
A client's track contains only what that client received. If it never received another player's inventory, playback shows that information as missing instead of filling it in. A referee can align the server track with participant tracks to inspect accepted actions, rejection reasons and the timing information that is available. Historical hitbox overlays show the collision shapes and the ray—the line of attack—used to validate a rail shot or melee action.
Timing needs the same care. A client's capture-to-feedback measurement uses that client's monotonic clock, which measures elapsed time without relying on the wall clock. Subtracting a timestamp from an unrelated server clock would not establish latency, even if the resulting number looked plausible.
Checking what a recording can establish
Recordings link their contents with a SHA-256 hash chain. Clients also send small periodic commitments: compact fingerprints that later verification can compare with the submitted recording. Those commitments use the existing authenticated control connection. Server files are sealed with the server's identity, and verification checks that tracks belong together and reports missing participant sessions.
The server identity still needs to be trusted independently. Finding a key inside a file does not establish whose key it is. A modified client can also report something false before committing to that report. Reconstructed playback cannot prove which pixels reached a monitor or automatically reveal an external overlay.
The viewer therefore distinguishes server decisions, client reports and the presentation reconstructed from them. That gives an organizer a way to examine a disputed moment while seeing where the evidence stops.
Recording also has to coexist with play. I limited the queues and moved disk writing into the background so storage trouble cannot create an unbounded gameplay stall. If the recording is incomplete, it stays visibly incomplete. The retained Linux and Windows tests passed cross-platform verification and native replay, giving me a checked path for reopening these files on either platform.
Playback has its own controls
A retained native replay capture shows the timeline and action inspector as part of a separate playback session.

The replay scene shares the renderer, with a timeline and evidence inspector around it.
Original PNGStill-image archive dates come from retained image file timestamps in Los Angeles time. An earlier-dated article may include later builds; each image is dated separately. Images are genuine engine or native-editor output. Download sources, transforms and SHA-256 hashes.
