Networked RTS State & Simulation Architecture

Key Highlights

• Server-authoritative fixed tick rate that drives both simulation and replication off a single timeline
• Generic replication layer that any entity table plugs into — reused across units, players, and territory without per-system glue
• Strict split between server simulation systems and client presentation systems so the two can evolve independently

Server-Authoritative Tick Simulation

• Runs simulation at a fixed 10 Hz tick that accumulates frame time, decoupling logic timing from per-client frame rate
• Each tick executes systems in a deterministic order — commands, territory, movement, combat, lifecycle, snapshot — so every tick produces one consistent state
• Match context exposes the tick number as a clock that timestamps creates and destroys, giving every system a shared notion of “when”

Replicated Tables for Units, Players, and Territory

• Generic table abstraction provides entity registration, snapshot serialization, snapshot apply, and client-side create/update/destroy event queues out of the box
• Per-entity dirty masks let the server replicate only the fields that actually changed — position, health, team, cooldowns — instead of full payloads every tick
• Two creation modes — server-authoritative for units and players, deterministic-shared for terrain rebuilt from a replicated map seed — keep static world state off the wire entirely

Full-State and Delta Snapshot Replication

• End-of-tick delta broadcasts carry only created, updated, and destroyed entities, keeping steady-state bandwidth bounded by what actually changed
• Late joiners receive an out-of-band full baseline scoped to that one connection, without disturbing the global dirty state used by the next broadcast
• Every entity payload is size-prefixed so a malformed or unrecognized record can be skipped without desynchronizing the rest of the stream
• Host-mode clients bypass network packets and re-emit the same replication events locally, keeping presentation code identical between host and remote

Command Pipeline for Player Orders

• Client requests are encoded as typed, pooled commands sent over a single message channel and dispatched on the server by command type id
• Server validates ownership and parameters before enqueueing, rejecting commands that reference units owned by another team
• Commands drain at the start of each tick with a per-tick cap, giving deterministic order resolution and a hard ceiling on worst-case work
• Multi-unit orders tag every member with a shared cohort id so units can pass through each other and resolve blocked moves without iteration-order glitches

Simulation and Presentation Split

• Server-only systems own simulation state — movement, combat, lifecycle, territory capture — and never touch rendering or audio
• Client systems consume the per-frame dirty queues from each table and translate them into renderers, fog updates, selection visuals, and procedural effects
• Ephemeral signals like attack events ride a separate, non-state message channel so visual feedback fires on the correct tick without polluting the canonical entity state

Why This Matters

• Delivers a complete, working replication model — table abstraction, dirty masks, full and delta snapshots, late-join — built on top of an existing transport rather than offloaded to one
• Predictable tick boundary and system ordering give the simulation behavior that’s straightforward to reason about, debug, and extend with new entity types
• The same architecture scales from a unit table to a territory table to a player table with no special-case code, and the simulation/presentation seam keeps client work testable and swappable