Multiplayer netcode is a distributed simulation operating across delay, jitter, loss, reordering and untrusted endpoints. Choosing TCP, UDP or WebRTC is only one design decision. A playable and defensible system also needs an authority model, simulation cadence, replication rules, recovery behaviour, bandwidth targets, observability and abuse controls.
Start with the game experience rather than a protocol slogan. A turn-based card game, four-player co-op platformer and 64-player action server have different tolerance for latency, divergence and recovery. Write down the supported player count, regions, target devices, worst acceptable interaction delay and which actions must remain correct under packet loss.
Declare who owns truth
For an internet-facing competitive game, the server normally owns consequential state: legal movement, health, inventory, projectiles, scoring and match progression. Clients send timestamped or sequenced intent; they do not announce an accepted outcome. The server validates the request against its state, advances the simulation and replicates a result.
Authority is not binary. A client may own camera effects, presentation and local input sampling while the server owns match truth. A co-operative title may permit more client authority, but that is a conscious trust decision with cheating and consistency consequences.
Document each replicated field with:
- its authoritative owner;
- who may request a change;
- validation and rate limits;
- replication audience and priority;
- correction behaviour; and
- whether it must be recorded for investigation or replay.
Valve's description of Source networking is a useful historical example of server ticks, client command streams, snapshots, interpolation and lag compensation. It is not a template to copy without measurement, but it shows why transport choice alone does not solve real-time synchronisation (Valve Developer Community — Source Multiplayer Networking).
Separate three clocks
A typical design has at least three cadences:
- input sampling, often linked to client frames;
- authoritative simulation ticks on the server; and
- snapshot or replication delivery, which may be less frequent or adaptive.
Do not assume they are equal. A client can render at 144 frames per second while receiving snapshots at a lower rate. Every message needs a stable sequence, tick or time reference so stale, duplicated and reordered data can be handled deliberately.
Higher tick rates reduce the interval between simulation decisions but consume CPU, bandwidth and operational headroom. A server that misses deadlines under representative load is not improved by a high configured rate. Profile full matches, busy scenes, joins, reconnects and bursts—not an empty development map.
Budget bytes before adding fields
Set per-client and server-egress budgets before replication expands. Include transport, encryption and acknowledgement overhead rather than counting only payload objects. Track at least:
- average and high-percentile bytes per second per client;
- packets per second and packet-size distribution;
- reliable backlog and retransmission volume;
- snapshot age, loss, jitter and out-of-order rate;
- serialisation, compression and send time; and
- relevance culling and dropped-update counts.
At 60 updates per second, a nominal 20 kilobytes-per-second allowance is only about 333 bytes per update before overhead and bursts. That arithmetic is a planning warning, not a recommended budget. Real traffic is uneven, and maximum packet size, path MTU and congestion behaviour matter.
Prioritise state that affects the current decision. Replicate nearby threats more often than distant decoration, quantise values to the precision the game needs, send changes instead of full objects where safe, and stagger non-critical work. Interest management must not leak hidden information that the client should never receive.
Use responsiveness techniques with correction plans
Waiting for a round trip before moving the local character often feels unresponsive. Client-side prediction applies local input immediately using the same movement rules expected on the server. When an authoritative result arrives, the client matches acknowledged inputs, rewinds to the confirmed state and replays unacknowledged input. Visual correction can be smoothed, but material divergence must not be hidden indefinitely.
Prediction is most effective for behaviour the client can reproduce. Physics, floating-point differences and non-deterministic order can create drift, so record the exact state and inputs used for reconciliation tests.
Remote entities are commonly rendered from a short interpolation buffer. The client displays a point in the recent past and interpolates between known snapshots, trading a little extra display delay for smoother motion under jitter. Extrapolation can bridge a short gap but needs strict duration and error limits.
Lag compensation is a server policy, not a promise to erase latency. A server may evaluate a shot against a bounded reconstruction of earlier positions. Bound the rewind, define which actions qualify and test edge cases so one player's delayed view does not create unreasonable outcomes for another. Valve's design article explains the rationale and trade-offs behind this approach (Valve Developer Community — Latency Compensating Methods).
Choose transport per message semantics
TCP provides an ordered reliable byte stream. That is useful for account operations, chat or match setup, but one lost segment can delay later stream data. UDP provides datagrams without built-in delivery, order or congestion guarantees; an application using it must implement or adopt the reliability, security and congestion behaviour it requires. “TCP is slow” and “UDP is fast” are not designs.
WebRTC data channels use SCTP over DTLS over ICE/UDP and can be configured for ordered or partially reliable delivery. They can help browser and peer connectivity, but introduce signalling, NAT traversal and operational dependencies (IETF RFC 8831 — WebRTC Data Channels). Managed engine transports may be appropriate when their platform reach, limits, lifecycle and observability meet the project.
Classify messages instead of choosing one rule for all traffic:
| Message | Typical requirement |
|---|---|
| Purchase or inventory mutation | Authenticated, idempotent and reliably confirmed |
| Player input | Sequenced, time-bounded and often superseded by newer input |
| World snapshot | Recent state matters more than an obsolete snapshot |
| Chat | Reliable delivery with moderation and rate controls |
| Cosmetic effect | Best effort may be acceptable |
Treat every client as hostile
Encrypt and authenticate sessions, but do not confuse encryption with trustworthy game state. Validate identity, session, sequence, rate, range, cooldown, ownership and state transitions on the authoritative side. Protect reconnect and migration tokens, prevent replay, expire credentials and avoid putting secrets in client builds.
Test malformed and oversized packets, sequence wrap, duplicate commands, time manipulation, impossible movement, inventory races, reconnect storms and denial-of-service pressure. Log enough to investigate without collecting unnecessary personal data or creating an unbounded telemetry store. The OWASP Game Security Framework is in public-review draft as of this review date; it can inform a threat-model checklist but should not be presented as a final certification standard (OWASP — Game Security Framework).
Verify in a network lab and a real build
Automated tests should replay deterministic input sequences, introduce loss, delay, jitter, duplication and reordering, and assert bounded divergence and recovery. Run soak tests with realistic player counts and content. Then test physical devices and actual regional paths; a loopback session cannot represent mobile handover, Wi-Fi contention or long-haul latency.
Define release gates such as server tick deadline, snapshot age, correction distance, disconnect recovery, maximum reliable backlog and per-client egress percentile. Publish observed limits, not marketing guarantees.
For help planning a multiplayer prototype, replication model or test harness, see Ozlin Info's game-development services or contact Ozlin Info.
Related reading: Cross-platform input handling for games.
General-information disclaimer
This article provides general technical information, not a security certification, anti-cheat guarantee, platform approval or capacity commitment. Validate transport, hosting, privacy, safety and platform requirements for the actual game and jurisdictions.
AI-assistance disclosure
AI tools assisted with source discovery, outlining and copyediting. A human reviewer must verify the architecture against a running build, representative network traces, threat model and current engine and platform documentation before publication or use.
Primary sources checked
- Valve Developer Community — Source Multiplayer Networking
- Valve Developer Community — Latency Compensating Methods
- Unity Multiplayer — Client Anticipation
- IETF RFC 768 — User Datagram Protocol
- IETF RFC 9293 — Transmission Control Protocol
- IETF RFC 8831 — WebRTC Data Channels
- OWASP — Game Security Framework
Source access date: 29 August 2026.