How do you architect a web game for single- and multiplayer?

Long Answer

A production web game must deliver smooth input, fair outcomes, and resistance to abuse. The core is a clean separation of simulation, netcode, and rendering, plus a clear stance on authority per mode.

1) Architecture overview
Create three layers. The simulation core is deterministic and platform-agnostic, advancing by ticks with a fixed timestep. The network layer moves player intentions and world states while handling latency, ordering, and loss. The presentation layer renders at display refresh, interpolating between authoritative states and local prediction. This layering allows a single codebase to power single-player and multiplayer with minimal branching.

2) Single-player mode
For solo play, run the same deterministic simulation entirely on the client. Use a fixed tick (for example, 60 Hz or 30 Hz), lock physics to that tick, and record inputs for replays. Implement save states via periodic snapshots and input logs for fast resume and debugging. Determinism requires stable math (consistent random seeds, integer or fixed-point where needed, and explicit order of updates). The single-player loop matches multiplayer for parity, which reduces defects when switching modes.

3) Multiplayer authority decision
For real-time play, choose between server authority and lockstep determinism.

• Server authority: Clients send inputs; the server simulates, then broadcasts snapshots or deltas. Benefits include anti-cheat, late join, and elastic scaling. Costs include bandwidth and simulation load.
  
• Deterministic lockstep: All peers advance with identical inputs per tick. Benefits include low bandwidth and perfect sync for strategy games. Costs include fragility to packet loss and strong cheating risks if peers can forge inputs.
  For action games and shooters, prefer server authority. For RTS or turnlike systems, lockstep is viable with input delay and robust desync detection.
  

4) Transport choices
Use WebSockets for reliable ordered client-server channels. For voice or data that benefits from NAT traversal, add WebRTC with TURN fallbacks; restrict peer data channels to non-authoritative features like cosmetic state or spectators, and route authoritative inputs through the server to preserve integrity. Consider UDP-like semantics via libraries that add reliability layers, but keep validation server-side.

5) Lag compensation toolbox
Latency is inevitable, so design for it.

• Client prediction: The client applies its own inputs immediately to render responsiveness.
  
• Reconciliation: When the server state arrives, the client rewinds to the last acknowledged tick, reapplies unconfirmed inputs, and corrects divergence.
  
• Interpolation and extrapolation: Interpolate remote entities between recent authoritative snapshots; extrapolate cautiously for short gaps.
  
• Server rewind: For hit detection, the server maintains a short history of states. When it receives a shot fired at client time t, it rewinds to that state and resolves the hit fairly.
  
• Input delay caps: Bound perceived latency by adding a small client buffer to smooth jitter, especially in lockstep or fighting games.
  

6) State replication strategy
Publish delta-compressed snapshots keyed by tick. Quantize positions and angles to reduce size. Partition the world into interest management zones; only send entities relevant to each client. Use entity component identifiers that stay stable across ticks for compact diffs. For large lobbies, shard simulation by room, and isolate noisy channels (chat, voice) from gameplay streams.

7) Authoritative simulation and cheat prevention
The server enforces rules. It accepts only inputs (not results), validates movement against physics, rate limits actions, and rejects impossible sequences. Use command sequence numbers and timestamps to prevent replays and ordering attacks. Protect matchmaking with signed tickets. Store authoritative random seeds server-side and reveal only derived outcomes. Monitor anomalies (speed, teleport, fire rates) with heuristic and statistical checks. Never trust client-reported health, ammo, or cooldowns.

8) Persistence and matchmaking
Persist player profiles, progression, and cosmetics out of the hot path through queues. Matchmaking groups players by skill and round-trip time to keep fairness. For regional scale, locate authoritative servers close to players and support migration with state handoff during long sessions.

9) Performance and scalability
Run simulation on a fixed tick and ensure the per-tick budget fits headroom. Profile hotspots in pathfinding and collision; precompute navigation meshes and broad-phase grids. Scale horizontally by room processes or shards. Use a gateway layer to terminate TLS and handle auth; dispatch to room workers. For very large rooms, consider entity ownership across worker partitions with explicit handoff.

10) Testing and observability
Build bot clients that fuzz inputs at scale. Simulate packet loss, jitter, and reorder during development. Track p50 and p95 input-to-photons latency, server tick time, bandwidth per client, reconciliation frequency, and correction magnitude. Log desyncs with repro seeds. Visualize snapshot age and prediction error to tune buffers.

11) Fair UX and ethics
Expose network status, show interpolation artifacts honestly, and provide region selection where possible. Offer aim assist or latency-aware aim cones only when rules allow and disclose it. Allow players to report cheating with automated evidence attachment.

The outcome is a flexible web game architecture: deterministic single-player for reliability, authoritative multiplayer for fairness, and a netcode toolkit that turns latency into a managed variable rather than a source of chaos.

‍

Table

‍

Common Mistakes

Trusting client state for movement, health, or ammo. Shipping multiplayer with a pure peer topology and no validation. Using visual interpolation without authoritative reconciliation, which causes rubber-banding under load. Mixing render rate with simulation tick, introducing non-determinism and desyncs. Broadcasting full snapshots every frame, saturating bandwidth. Ignoring interest management and sending all entities to all clients. Performing hit detection only on the server’s current tick without rewind, which punishes high latency players unfairly. Overusing WebRTC data channels for authoritative gameplay, complicating NAT and cheat prevention. Lacking telemetry for prediction error, reconciliation counts, and server tick time, so tuning becomes guesswork. Applying heavy encryption on every small packet without batching, blowing CPU budgets.

‍

Sample Answers

Junior:
I would keep a fixed-timestep simulation and use WebSockets. For single-player I run the simulation locally. For multiplayer the server is authoritative, clients send inputs, and I apply client prediction with reconciliation. I interpolate remote players between snapshots and keep bandwidth low with deltas.

Mid:
I separate simulation from rendering, add interest management, and quantize state. I implement server rewind for hit validation, and I cap jitter with a small input buffer. I use signed matchmaking tickets and validate all inputs server-side. Persistence is asynchronous so the hot loop stays under budget.

Senior:
I operate room workers behind a gateway, scale by shard, and measure input-to-photons latency. I choose server authority for action modes and deterministic lockstep for RTS. I maintain history rings for rewind, enforce rate limits and anomaly detection, and support region selection. CI includes packet loss and reorder simulations, and dashboards expose prediction error and correction magnitude to guide tuning.

‍

Evaluation Criteria

Look for a layered plan that reuses a deterministic simulation in both modes, with server authority for action games and lockstep only when it fits. Netcode must include client prediction, reconciliation, interpolation, and server rewind. Bandwidth control requires delta snapshots, quantization, and interest management. Security demands input validation, rate limits, signed tickets, and never trusting client state. Scalability should isolate rooms, use gateway routing, and keep persistence off the hot path. Observability must track tick time, prediction error, correction counts, bandwidth, and p95 input-to-photons. Red flags include peer-only authority, trusting client health, no rewind, frame-bound physics, or broadcasting entire state every frame.

‍

Preparation Tips

Build a prototype with a fixed-timestep core. Add a WebSocket server that accepts inputs and broadcasts delta snapshots with interest management. Implement client prediction and reconciliation, snapshot interpolation, and a small input buffer. Add a rewind ring buffer for hit tests. Quantize positions and serialize compactly. Introduce packet loss and jitter in tests, then tune buffers and correction thresholds. Create room workers and a gateway with matchmaking and signed tickets. Log prediction error, reconciliation counts, and p95 input-to-photons. Add a replay system from input logs and seeds. Validate anti-cheat by rejecting impossible moves and rate limiting actions. Finally, document rules for when to use server authority versus lockstep, and prepare charts that show latency distributions before and after tuning.

‍

Real-world Context

A browser shooter moved from client-side hits to server rewind with a 200 ms history; disputed hits fell dramatically and player sentiment improved. A casual RTS adopted deterministic lockstep with input delay and periodic hash checks; it achieved very low bandwidth while catching desyncs early. A sports game added interest management and snapshot deltas; bandwidth per client dropped, enabling larger lobbies. After quantizing state and introducing prediction with reconciliation, visible rubber-banding decreased on mid-latency links. A studio added anomaly detection for speed and fire-rate, reducing cheating reports. Instrumentation of input-to-photons latency revealed a slow path in collision broad-phase; grid partitioning fixed tick spikes. These changes turned netcode from a bottleneck into a competitive advantage while keeping matches fair.

‍

Key Takeaways

• Reuse a deterministic simulation core across modes.
  
• Use server authority for action; lockstep for RTS-like games.
  
• Combine prediction, reconciliation, interpolation, and rewind.
  
• Send compact delta snapshots with interest management.
  
• Validate all inputs and never trust client state.

‍

Practice Exercise

Scenario:
You must ship a top-down arena web game that supports solo training and six-player real-time matches. Average round-trip time is 80–160 ms, and fairness is a hard requirement. The game must run in modern browsers and scale globally.

Tasks:

1. Core: Implement a fixed-timestep simulation with seeded RNG and ordered updates. Expose a pure input → state API for reuse in both modes.
   
2. Transport: Use WebSockets for gameplay. Reserve WebRTC for voice or spectators only. Build a gateway for TLS, auth, and room routing.
   
3. Authority: Server simulates matches. Clients send inputs with sequence numbers and timestamps.
   
4. Lag Compensation: Add client prediction and reconciliation. Maintain a server history ring for rewind hit tests. Use a 100–150 ms interpolation buffer and cautious extrapolation.
   
5. Replication: Quantize positions and angles, send delta snapshots keyed by tick, and filter by interest areas.
   
6. Security: Validate moves against physics, rate limit actions, require signed matchmaking tickets, and flag anomalies for review.
   
7. Scale: Run one worker per room, shard by region, and keep persistence async through a queue.
   
8. Observability: Log p95 input-to-photons, tick time, prediction error, correction count, and bandwidth. Build a bot harness to inject jitter and loss.
   
9. UX: Expose network indicators and region selection. Provide clear correction visuals without hiding them.
   
   

Deliverable:
A short architecture brief, telemetry dashboards, and a demo video showing smooth play under 120 ms RTT, with visible but fair corrections and validated server authority.