A full hour-long pro game fits in a few hundred kilobytes. No video, no positions, no graphics — just a seed and the players' clicks. Replays are lockstep determinism handed back to you for free.
The core bargain again: positions never go on the wire, only commands, because each machine recomputes the game. A replay applies that to time. Save the starting conditions + every command, feed them back into the same deterministic engine, and it rebuilds every unit, shot, and fog reveal — by literally re-running the game.
Hence: tiny files, and they only play correctly in a faithful engine. Change one rounding bit and the replay desyncs from reality — exactly like a live game.
// replay.h — what a replay actually stores
struct replay_state {
a_vector<uint8_t> actions_data_buffer; // the whole command stream, compressed
int end_frame; // when the game ended
a_string map_name;
std::array<a_string, 12> player_name;
int game_type; // melee, UMS, ...
};The replay header carries the same random_seed the live game agreed on. On load, it's poured straight back into the RNG so every dice roll matches the original match exactly:
// replay.h — restore the RNG from the file, then replay commands
uint32_t random_seed = gir.get<uint32_t>();
// ...load map, init state...
st.lcg_rand_state = random_seed; // same seed → same sequence (see ch.04)Drag the game length and compare a Brood War replay against recording the same match as video. The replay grows with how much players did; the video grows with every pixel of every frame.
a busy pro game is a few hundred KB · the same minutes as 1080p video are gigabytes
A replay opens with an identifier (0x53526572) and a fixed 633-byte game-info block: frame count, the all-important random_seed, map dimensions, game type/speed, and 12 player records (controller, race, name, color). Then come length-prefixed, compressed blocks for the action stream and the map data (replay.h:105).
The command stream is repetitive — the same select/move/attack patterns over and over — so it compresses well. OpenBW's replay_saver.h implements a Huffman + back-reference scheme (variable-length length/distance codes, max ~8 KB segments, each CRC32-checked). The CRC matters: a corrupted command byte would silently desync the playback, so integrity is verified per segment.
As the game runs, add_action (replay_saver.h:544) appends each command under a frame header: a uint32 frame number, a size byte, then (owner, action_bytes) records. Consecutive actions in the same frame share one header until the size would overflow a byte, keeping overhead to roughly one frame-header per active frame. On playback, execute_actions only applies a frame's batch when current_frame matches — the same gating live play uses.
Every chapter of this site is a consequence of a single 1998 decision made under the weight of a 56k modem: don't send the game, send the inputs.
So the engine sends only player commands — a few bytes, regardless of army size.
No one advances a frame until everyone's commands arrive; latency buffering hides the round-trip.
Fixed-point math, a seeded LCG, and fixed iteration order make it bit-for-bit reproducible.
A rolling FNV-1a hash of the whole state catches any divergence within ~1.3 seconds and drops the offender.
Units as state machines, animation as iscript bytecode, memory as fixed pools — all reproducible.
A seed plus a command stream reconstructs everything — the architecture, folded into a file.
A small team built a game lean enough for the worst connections of its era, and in doing so built something so deterministic it could be preserved, replayed, re-implemented, and studied decades later. The constraints didn't limit Brood War. They made it timeless.