Demos, Networking, and Determinism

Doom demos and multiplayer share a critical idea: the simulation is driven by ordered tic commands rather than by a stream of recorded screen states. d_net.c, d_ticcmd.h, g_game.c, and the platform net interfaces define the path by which commands are collected, exchanged, and consumed.

A demo records the inputs needed to reproduce play, while network mode attempts to ensure that each participant applies compatible input at compatible tic boundaries. This approach is economical, but it imposes strict conditions on determinism. Random-number consumption, update order, initial map state, and executable behavior must agree, because each machine is deriving the world locally from the same command history.

The practical consequence

When investigating a desynchronization or demo mismatch, rendering is usually downstream evidence rather than the cause. The relevant questions concern tic command bytes, their ordering, game-state transitions, random sequences, and the set of thinkers advanced per tick. G_Ticker and the play tickers are therefore more informative than the display code.

Doom’s approach predates modern rollback terminology, yet it remains a clear example of a deterministic input-driven game loop. Its design makes the simulation small enough to replay, inspect, and synchronize, provided that every participant respects the same tic contract.