Skip to content

Netcode and Multiplayer

Introduction

Section titled “Introduction”

Netcode is the layer that keeps multiple players in sync over an unreliable, latent network while the game still feels responsive. The hard part is physics: light takes time, packets drop, and you must hide that from the player. This page covers topologies, replication, latency hiding, and the security stance — mapped to KBVE’s transport stack.

Topologies

Section titled “Topologies”
  • Client-server (authoritative) — the server owns the truth; clients send input, receive state. The standard for competitive and persistent games because it’s the only practical way to resist cheating.
  • Peer-to-peer — peers talk directly; lower infrastructure cost but trust and NAT problems, and “who is authoritative?” gets messy.
  • Lockstep (deterministic) — peers exchange only inputs and run identical simulations in step. Tiny bandwidth, scales to huge unit counts (RTS), but demands bitwise determinism and stalls on the slowest peer.

Replication

Section titled “Replication”

Replication is keeping client state in sync with server state efficiently:

  • State replication — server sends snapshots of relevant game state; clients render it. Robust to packet loss (next snapshot supersedes the lost one).
  • Delta compression — send only what changed since the client’s last acknowledged snapshot.
  • Relevancy / interest management — only replicate what a client can perceive (area of interest, distance, visibility). Bandwidth is the budget; don’t send the whole world.
  • Reliability tiers — UDP by default; layer your own reliability only where needed (RPCs, events) and leave fast-changing state unreliable.

Latency hiding

Section titled “Latency hiding”

The techniques that make a laggy network feel instant:

Client-side prediction

The client applies the player’s input immediately instead of waiting for the server round-trip, so movement feels instant.

Server reconciliation

When the authoritative state arrives, the client rewinds and re-applies any inputs the server hadn’t processed yet, correcting drift.

Entity interpolation

Render other players slightly in the past, smoothly interpolating between received snapshots to hide the gaps.

Lag compensation

The server rewinds the world to the shooter’s view-time when validating a hit, so well-aimed shots register despite latency.

Tick rate and timing

Section titled “Tick rate and timing”
  • Tick rate — how often the server simulates and snapshots (e.g. 30/60 Hz). Higher = more responsive, more bandwidth/CPU.
  • Fixed timestep — the simulation must advance in fixed steps for determinism and fair prediction; decouple it from render framerate (see the Game Loop pattern).
  • Clock sync — clients estimate server time + RTT to schedule input and interpolation correctly.

Security

Section titled “Security”

The first rule: never trust the client.

  • Validate every input server-side; the client sends intent, the server decides outcome.
  • Movement, hits, economy, and item grants are server-authoritative.
  • Rate-limit and sanity-check inputs; clamp to physically possible actions.
  • Keep authority and transport concerns separated and never mix transports in shared structs.

How KBVE applies these

Section titled “How KBVE applies these”
  • Transport isolation — WS and WT transports are kept strictly isolated; never mixed in shared structs, following the lightyear examples. This is a recorded engineering rule.
  • rareicon (Unity NetCode) — NetCode splits the world; gameplay is client-only and UI/services must scan World.All for KingTag rather than the default injection world.
  • Authoritative auth — OWS/ROWS resolve userguid = sub from the Supabase JWT, gate world-IP on bearer-or-session, and 403 on character-ownership mismatch.
  • Known issue — the isometric game’s WASM WebSocket handshake reports linked = true but the netcode never completes the handshake; native works fine.

Further reading

Section titled “Further reading”