Great topic. The core architectural decision for competitive replay systems comes down to command recording vs. full-state snapshotting, and most AAA competitive titles converge on a hybrid. Pure input recording (like fighting games do) gives you tiny replay files and frame-accurate determinism, but it’s brutal to implement cleanly because you’re essentially serializing the entire input+logic stream and must guarantee bit-exact reproduction across hardware. The determinism trap is real—floating-point non-determinism, thread scheduling, and unordered hash iteration will silently corrupt your replay 30 minutes in. Titles like Rocket League and fighting games sidestep this by running deterministic fixed-point math and a single-threaded simulation loop, so replay is just “replay the input frames.” For larger team-based shooters where full state is too heavy, I’d recommend snapshotting at a fixed tick rate (e.g., every 4th frame) plus delta-compressed input deltas between snapshots. Serialize the state as a compact binary blob using a schema like FlatBuffers or a hand-rolled structure packing—never reflection-based JSON for hot paths.
On the serialization side, one thing people underestimate is memory layout and pointer stability. If you naively dump a pointer-based scene graph, your replay breaks the moment allocations shift. You want to serialize canonical IDs (entity indices, not pointers) and rebuild references during deserialization through a lookup table. Also implement versioned schema headers with
