Gamedev Multiplayer

Game multiplayer & netcode

Design and wire the network layer of a game across Godot 4.x, Unity, and Unreal: choose a topology, put authority in the right place, replicate the right state, and hide latency without opening the door to cheaters. This skill owns the networking decisions; the engine skills own the local gameplay those decisions sit on top of.

Route elsewhere when the ask is not netcode:

Version contract — read first

Target the current APIs. Never emit these deprecated / removed APIs:

UNet is removed from modern Unity — do not scaffold it. If a repo genuinely uses Mirror (a community UNet-like fork), say so; this skill targets first-party NGO. In NGO 2.x the unified [Rpc(SendTo.Server)] / [Rpc(SendTo.ClientsAndHost)] attribute is preferred; the older [ServerRpc] / [ClientRpc] still compile (and enforce …ServerRpc / …ClientRpc method-name suffixes) — cover them but prefer the unified form on new code.

Topologies & authority

Pick the topology first; everything else follows from it.

• Client-server, dedicated server — a headless authoritative process no player controls. The gold standard for competitive/persistent games: one source of truth, hardest to cheat, costs money to run.
• Client-server, listen server — one player's machine is also the server (host). Cheap, zero infra, but the host has a latency advantage and can tamper; fine for co-op and casual PvP. Design so the same code runs on both (a listen server is a dedicated server that also has a local client).
• Peer-to-peer — no central authority; peers exchange state directly. Low infra cost and low latency between peers, but NAT traversal is painful, it is the easiest to cheat, and it needs lockstep or a rollback model to stay consistent. Reasonable for small trusted lobbies or deterministic fighting games.

Server-authoritative is the default. The server owns the truth; clients send intent (inputs, requests), never results. Never trust the client: the client cannot set its own health, position, score, currency, or hit results — it asks, the server decides, everyone else observes. A client that says "I moved to X / I did 40 damage / I have 999 gold" is either lagging or cheating; treat both the same. The one thing a client legitimately owns is its own input and, by convention, cosmetic-only state. See references/prediction-and-latency.md for how to keep this responsive.

State replication vs RPCs

Two complementary tools — use the right one:

• State replication = continuous synchronized values (health, position, ammo, team). The framework watches a variable and pushes changes to relevant peers; late-joiners get the current value automatically. Use for anything a client needs the latest of. It is idempotent and self-healing on packet loss.
• RPCs (remote procedure calls) = one-shot events ("fire weapon", "play explosion at P", "open door"). Fire-and-forget; a dropped unreliable RPC is simply lost. Use for events, never for state you need to stay consistent — a missed "you died" RPC leaves a client desynced forever; a replicated isDead bool self-corrects.

Rule of thumb: replicate nouns (state), RPC verbs (events). What to replicate: only what other peers must see, at the coarsest rate that still looks right — position/rotation of visible actors, gameplay stats, animation state flags. Do not replicate values a peer can derive locally, purely cosmetic particles, or high-frequency data no one observes.

Ownership / authority decides who may write. Every networked object has an owner (a peer id) and an authority (usually the server). Writes to replicated state must come from the authority; ownership lets a client drive its own pawn's input while the server still validates the outcome. Getting ownership wrong is the #1 cause of "it works for the host but not the client" bugs.

The hard problems

Latency (round-trip time, RTT) is the enemy; jitter and packet loss make it worse. Four techniques, covered in depth in references/prediction-and-latency.md:

1. Client-side prediction — the owning client applies its own input immediately instead of waiting a full RTT for the server, so local movement feels instant.
2. Server reconciliation — the server is still authoritative; the client tags each input with a sequence number, and when the authoritative state arrives it replays any inputs the server hadn't processed yet. Mismatch → a correction (the visible "rubber-band"); minimize it, don't hide it.
3. Snapshot interpolation — remote entities are rendered ~100 ms in the past, interpolating between the last two received snapshots, so other players move smoothly instead of teleporting between updates.
4. Lag compensation — for hitscan/instant hits, the server rewinds other entities to where the shooter saw them (at the shooter's render time) before testing the hit. Fairer for the shooter; occasionally "shot behind a wall" for the victim. A deliberate tradeoff, not a bug.

Tick rate / netrate: the server simulates at a fixed tick (e.g. 20–64 Hz) and sends state at a send rate that may be lower than its sim rate and decoupled from client render FPS. Never tie gameplay to frame rate on a networked game — simulate on a fixed timestep, interpolate for rendering.

Per-engine mapping

Short form here; full patterns in the references. All snippets are current-API.