Frames, Networking, and Determinism

Generals networking is not best understood as a stream of remote unit positions. The source organization instead points to a frame-based command system. FrameData.cpp, FrameDataManager.cpp, NetCommandList.cpp, NetCommandWrapperList.cpp, NetPacket.cpp, NetMessageStream.cpp, Network.cpp, and Connection.cpp form the vocabulary required to collect, transport, order, and execute commands against a shared simulation.

The shared frame is the unit of agreement

In a deterministic RTS, peers do not need to transmit the full position and animation state of every object on every update. They need to agree on the commands that enter the simulation and on the frame in which those commands become executable. The same simulation rules then advance each peer's local state. Abstractly, the next simulation state is a deterministic function of previous state and the ordered command set for the frame:

$$ S_{f+1}=\operatorname{Simulate}(S_f, C_f). $$

This is why command and frame-data paths must be studied together. A command has no network meaning until it has been associated with the ordering and readiness rules of a frame. The relevant object is not an isolated packet but the complete command set C_f that each participant will execute for frame f.

NetCommandList and its wrapper list represent command-side collection, while FrameData and FrameDataManager provide the frame-oriented coordination layer. Connection, connection management, packet code, and NetMessageStream implement transport and peer-management concerns around that model. Game-logic dispatch is where an ordered command becomes an instruction to the simulation.

local input -> command wrapper -> network transport
                                      │
remote input -> command wrapper ------┤
                                      ▼
                           frame data / command list
                                      ▼
                     readiness and deterministic ordering
                                      ▼
                           GameLogic dispatch for frame f

The diagram is a source-reading model. It does not claim a particular packet layout or a particular topology. It identifies the required handoffs that the named systems make visible.

Arrival order is not execution order

Network arrival time is inherently local. A packet can be delayed, retried, or observed in a different order by different machines. Deterministic execution therefore needs a stable ordering function independent of incidental arrival order. If commands are sorted by an agreed key k, the executable list is:

$$ C_f = \operatorname{Sort}_{k}({c_1,c_2,\ldots,c_n}). $$

The exact key and completion predicate should be verified in the active source before making a more specific claim. The architectural consequence is already clear: the simulation must wait until its frame-level readiness rule is satisfied, then execute the same ordered work at every peer. A late local packet is not permission for one machine to advance with a different prefix of commands.

if frame f is complete:
    ordered = agreed_order(commands for f)
    dispatch each command in ordered
    advance simulation to f + 1
else:
    retain or request the missing frame data

This is intentionally pseudocode. It separates the completion rule from the simulation step, which is the distinction most often lost when networking is described as ordinary message handling.

What determinism demands

The model makes several constraints visible. Simulation-relevant input must use a shared command format. Execution order must not depend on local arrival order. Random behavior must be controlled. Every peer must use compatible content and rules. Visual effects, local mouse state, and UI animation can remain client-local, but any value that changes game state must enter through the synchronized command and frame path.

The initial state is part of the proof. Two peers can agree perfectly on commands and still diverge if they start from different maps, object definitions, seeds, or rule data. More completely, deterministic agreement requires:

$$ S_0^{(1)} = S_0^{(2)},\qquad C_f^{(1)} = C_f^{(2)},\qquad F^{(1)} = F^{(2)}. $$

Under those conditions, induction gives the same state for each subsequent frame. A desynchronization investigation should therefore check initial content, command contents, frame assignment, ordering, and deterministic inputs before treating a visible position mismatch as the cause.

Transport integrity and simulation integrity differ

Packet integrity answers whether data survived transport. Simulation integrity answers whether independently simulated worlds remain equal. These are related but different checks. A packet checksum can validate bytes before a command enters a frame list. A world-state comparison can detect that equal-looking traffic nevertheless led to unequal simulation state, perhaps because of a rule, seed, or content discrepancy.

When diagnosing a multiplayer discrepancy, do not begin with the visible unit position. Begin by asking whether peers agreed on command contents, frame assignment, command ordering, initial content, and determinism inputs. Those are the upstream conditions from which every divergent unit position follows.