Networking Specification

Agent Prompt Snippet

Ensure the project has a networking specification covering netcode architecture, protocol selection, latency budgets, and sync strategy.

Purpose

A Networking Specification defines how game clients and servers exchange data in real time: the transport protocol, the network topology, the tick rate, the packet format, the state synchronization model, the bandwidth budget, and the connection lifecycle. It is the single document that determines whether your multiplayer game feels responsive at 30 ms round-trip time and playable at 200 ms.

Every multiplayer game is a distributed system, but unlike web services—where an extra 100 ms is a minor annoyance—games operate under hard real-time constraints. A player pressing “fire” must see a result within a perceptual frame or two, even though the authoritative server might be 80 ms away. The networking spec is where the team commits to how that illusion is maintained: client-side prediction, server reconciliation, entity interpolation, input buffering. Without these decisions written down and agreed upon, each programmer invents their own approach, and the result is a game that feels different depending on which system you’re interacting with.

The spec also draws the boundary between networking and game logic. It defines what data crosses the wire (compressed input commands? full world snapshots? delta-encoded state?), how much bandwidth each player consumes, and how the game degrades gracefully when conditions worsen. These decisions affect everything downstream: the server architecture, the lag compensation model, the anti-cheat integration, and the session management flow. Getting them wrong is expensive—netcode rewrites are among the most costly refactors in game development because they touch every system that reads or writes networked state.

This is a Required document for any multiplayer game project. Without it, the team will discover networking constraints through playtesting failures rather than engineering design.

Who needs this document

Persona	Why they need it	How they use it
Sam (Indie Dev)	Building multiplayer without a networking spec means discovering topology and sync issues mid-development; the spec forces critical decisions (client-server vs. P2P, tick rate, prediction model) before writing netcode	Writes the spec after prototyping the core loop; uses it to evaluate middleware (Photon, Mirror, Steam Networking) against documented requirements
Claude Code (AI Agent)	Cannot generate correct netcode without knowing the sync model, packet format, and authority model; wrong assumptions produce code that desyncs or cheats trivially	Reads the spec before implementing any networked gameplay system; validates that state mutations respect the documented authority boundaries
Priya (Eng Lead)	Coordinates client and server teams around a shared protocol; prevents integration failures where client expects snapshots but server sends deltas	References the spec in architecture reviews; uses bandwidth budgets to evaluate whether proposed features fit within documented limits
DevOps (Infrastructure)	Provisions servers, configures firewalls, and sets up monitoring based on documented port ranges, protocol choices, and expected bandwidth per player	Uses the spec to size server instances, configure UDP hole-punching or relay infrastructure, and set alerting thresholds for packet loss and latency

What separates a good version from a bad one

Criterion 1: Network topology and authority model are explicit

✓ Strong: “Client-authoritative movement with server validation. Dedicated servers run at 60 Hz tick rate in us-east, eu-west, and ap-southeast. Clients send input commands (6 bytes per input: tick number, bitfield for actions, 16-bit aim angle) at the server tick rate. Server simulates authoritatively and broadcasts world snapshots at 20 Hz. Clients interpolate between the two most recent snapshots (100 ms interpolation buffer). P2P fallback: none—all sessions require a dedicated server.”

✗ Weak: “We use client-server architecture.” (Which variant? Who is authoritative for what? What tick rate? What happens if the server is unavailable? Two engineers reading this will implement incompatible authority models.)

Criterion 2: Packet format and serialization are specified with byte budgets

✓ Strong: “Input packet: 4-byte sequence number + 6-byte input payload + 2-byte CRC. Maximum input packet: 12 bytes. Snapshot packet: 4-byte tick + variable-length delta-encoded entity states, maximum 1200 bytes (fits single UDP datagram without fragmentation). Serialization: custom binary format, little-endian, no self-describing fields. Bandwidth target: ≤ 64 kbps upstream per client, ≤ 256 kbps downstream per client at 20 Hz snapshot rate with 32 players.”

✗ Weak: “Game data is serialized and sent over UDP.” (No packet structure, no size constraints, no bandwidth budget. The first time someone adds a 4 KB ability effect to the snapshot, the game fragments across multiple datagrams and packet loss doubles.)

Criterion 3: Latency budget accounts for the full round trip

✓ Strong: “End-to-end latency budget: 150 ms maximum for competitive modes. Breakdown: client input sampling (0–16 ms at 60 fps) + client-to-server transit (target ≤ 40 ms) + server simulation (≤ 16 ms at 60 Hz) + server-to-client transit (≤ 40 ms) + client interpolation buffer (50 ms, configurable per mode). At 150 ms total, hit registration uses server-side rewind up to 200 ms. Connections above 200 ms RTT receive a UI warning; above 350 ms RTT, matchmaking excludes the region.”

✗ Weak: “Latency should be low.” (No numbers, no breakdown, no degradation strategy. Every team member has a different definition of “low.”)

Criterion 4: Connection lifecycle and failure handling are documented

✓ Strong: “Connection states: CONNECTING → AUTHENTICATING → LOADING → SYNCED → PLAYING → DISCONNECTING. Timeout policy: no input received for 5 seconds triggers server-side disconnect; client attempts reconnect with exponential backoff (1s, 2s, 4s, max 30s) carrying a session resume token. Resume window: 60 seconds—if the client reconnects within 60 seconds, game state is preserved. After 60 seconds, the player entity is despawned and the slot is released.”

✗ Weak: “Handle disconnections gracefully.” (No states, no timeouts, no resume logic. Client and server teams will implement conflicting reconnection behavior.)

Common mistakes

Choosing a topology without profiling. Teams pick client-server or peer-to-peer based on familiarity rather than measuring the actual requirements. A 2-player fighting game with 60 Hz input exchange may work beautifully with P2P rollback netcode. A 64-player shooter cannot. Profile the entity count, update frequency, and expected player count before committing to a topology.

Ignoring bandwidth in the design phase. A 20 Hz snapshot rate with 64 players, each requiring 200 bytes of state, is 256 KB/s downstream—before delta encoding. Teams that don’t calculate bandwidth budgets upfront ship games that stutter on residential connections. The networking spec must include per-player upstream and downstream byte budgets and validate them against target connection speeds.

Treating the network as reliable. UDP packets are lost, reordered, and duplicated. Specs that assume ordered delivery or design around TCP for game state produce netcode that stalls on packet loss. The spec must document how each message type handles loss: is it redundantly sent? Does the receiver request retransmission? Is it idempotent?

No anti-cheat integration points. The networking spec must identify where anti-cheat hooks into the data pipeline—input validation on the server, snapshot verification on the client, encrypted channels for sensitive state. If the spec ignores cheating, the anti-cheat system will be bolted on later, likely breaking assumptions about packet format and authority.

Mixing game logic with transport. When gameplay code directly calls socket APIs, every new feature becomes a networking feature. The spec should define a clean abstraction boundary: game logic produces state changes, the networking layer serializes and transmits them. This separation must be documented or it will erode within weeks.

How to use this document

When to create it

Write the networking spec after the game design document establishes the multiplayer model (player count, session type, competitive vs. cooperative) but before implementing any netcode. The spec should be finalized before the first networked playtest. Changing the sync model or authority model after netcode is integrated into gameplay systems is a near-total rewrite.

Who owns it

The networking/engine programmer or tech lead owns the spec. Gameplay programmers, server infrastructure engineers, and the security lead are reviewers. Changes to tick rate, packet format, or authority model require sign-off from all reviewers because they cascade into lag compensation, server scaling, and anti-cheat.

How AI agents should reference it

get_standard_docs(type="video_game", features=["multiplayer"])
→ networking_spec in documents[]
→ agent reads spec before generating any code that sends or receives game state
→ agent validates that new networked entities fit within documented bandwidth budget
→ agent respects authority boundaries: no client-authoritative writes to server-owned state

The prompt_snippet — “Ensure the project has a networking specification covering netcode architecture, protocol selection, latency budgets, and sync strategy” — tells the agent to verify these four dimensions exist and are concrete.

How it connects to other documents

The Networking Specification is upstream of the Lag Compensation Spec (which defines how the sync model handles latency), the Server Architecture (which provisions infrastructure to meet the documented tick rate and player count), the Session Management Spec (which defines the lobby-to-game-server handoff that networking implements), and the Security & Privacy document (which defines what data is encrypted and how anti-cheat integrates with the network layer).