Multiplayer in Babylon.js with WebSockets
Multiplayer transforms a single-player game into a shared experience, but it introduces complexity that touches every system in the game. Input must be sent to the server. State must be synchronized across clients. Physics must agree across machines. Visual feedback must be instant even though the server is 50 to 200 milliseconds away. Each of these challenges has established solutions that web games can adopt using standard browser APIs.
Step 1: Design the Network Architecture
An authoritative server architecture is the standard for competitive and commercial multiplayer games. The server runs the game simulation, validates every player action, and broadcasts the authoritative state to all clients. Clients send input (key presses, mouse movements, action triggers) to the server and receive state updates back. This prevents cheating because the server rejects invalid actions, and clients cannot modify their own position, health, or score.
Peer-to-peer (P2P) architecture connects players directly using WebRTC data channels. One player acts as the host, running the game simulation, while others send input and receive state. P2P eliminates server hosting costs and can reduce latency for players near each other. The downsides are NAT traversal complexity, the host having an inherent latency advantage, and vulnerability to cheating since one player runs the simulation.
For turn-based games, a simple relay server works well. The server receives actions from the current player, validates them, applies them to the game state, and sends the updated state to all players. There is no prediction or interpolation needed because the game pauses between turns. This is the simplest multiplayer architecture and is appropriate for card games, board games, and strategy games with sequential turns.
Choose the architecture based on the game's requirements. Real-time action games need an authoritative server with prediction and interpolation. Cooperative puzzle games can use P2P with a host. Turn-based games use a relay server. The choice affects the entire codebase, so make it early and build on it consistently.
Step 2: Set Up a WebSocket Server
Node.js with the ws library is the most common WebSocket server for browser games. Install with npm install ws and create a server: const wss = new WebSocket.Server({ port: 8080 }). The server listens for connections, and each connection represents a player. Track connected players in a Map keyed by a unique player ID assigned at connection time.
Organize players into rooms or lobbies. A room is a group of players in the same game session. When a player connects, they either join an existing room with available slots or create a new one. The room object holds the game state, the list of connected players, and the game loop interval. When a room is empty (all players disconnected), clean it up to free resources.
The server game loop runs at a fixed tick rate, typically 20 to 60 times per second. On each tick, the server processes queued player inputs, updates the game state (positions, physics, game logic), and broadcasts the updated state to all players in the room. Use setInterval with a consistent interval (50ms for 20 ticks/second) rather than requestAnimationFrame, which is not available on the server.
Handle connection lifecycle events carefully. When a player disconnects, decide whether to remove them immediately (short matches) or keep their slot reserved for reconnection (longer sessions). Broadcast the disconnection to other players so they can display a "player disconnected" indicator. If the disconnected player was the last one in the room, destroy the room.
Step 3: Define a Message Protocol
Messages between client and server need a consistent format. JSON is the simplest option: {"type": "input", "data": {"forward": true, "jump": false}}. JSON is human-readable and easy to debug, but it is verbose and slow to parse. For games with high message frequency (20+ messages per second), the parsing overhead becomes measurable.
Binary protocols are more efficient for real-time games. Use ArrayBuffer and DataView to pack values into compact binary formats. A position update that takes 60 bytes in JSON ("type":"pos","x":123.456,"y":78.901,"z":234.567") takes 12 bytes in binary (three 32-bit floats). At 20 updates per second for 10 players, this difference adds up to significant bandwidth savings.
Define message types with numeric IDs rather than strings. Type 1 is player input, type 2 is state update, type 3 is chat message, type 4 is game event. The first byte of every message is the type ID, and the remaining bytes contain the payload specific to that type. This makes parsing fast: read the type byte, then call the handler for that type with the remaining data.
Implement message batching for efficiency. Instead of sending each input event as a separate WebSocket message, batch multiple events into a single message sent at the tick rate. The client accumulates input events between ticks and sends them all at once. This reduces the number of WebSocket frames, which reduces overhead from framing and system call costs.
Step 4: Implement Client-Side Prediction
Without prediction, the player presses a key, the input travels to the server (50ms), the server processes it, and the state update travels back (another 50ms). The player sees their character move 100ms after pressing the key. This feels unresponsive. Client-side prediction solves this by applying the input locally and immediately, then correcting if the server disagrees.
The prediction loop works as follows: when the player presses forward, immediately move the local character forward using the same movement logic the server uses. Simultaneously, send the input to the server with a sequence number. The server processes the input, computes the resulting position, and sends it back with the same sequence number. The client compares its predicted position with the server's authoritative position.
If the positions match (or are close enough), prediction was correct and no correction is needed. If they differ (the server rejected the input, a collision happened differently, or another player interfered), the client snaps to the server position and replays any inputs that were sent after the corrected one. This replay step is critical because inputs are continuously sent, and the correction must account for all inputs between the corrected one and the current frame.
Keep a buffer of recent inputs with their sequence numbers and predicted states. When a server correction arrives, find the input with the matching sequence number, update the state to the server's value, and re-simulate forward through all subsequent inputs in the buffer. This produces a corrected state that accounts for both the server's authority and the player's recent input.
Step 5: Add Entity Interpolation
Remote players' positions arrive in discrete state updates at the server's tick rate (20 to 60 times per second). If you set the remote player's mesh directly to each received position, the movement appears choppy, jumping from one position to the next. Entity interpolation smooths this by rendering the remote player between two received positions.
Buffer received state updates and render with a deliberate delay, typically one to two tick intervals behind real time. This ensures you always have two state snapshots to interpolate between. At tick rate 20 (50ms between updates), a 50ms render delay means the remote player appears 50ms behind their actual position, which is imperceptible in most games.
On each render frame, calculate the interpolation factor: how far between the previous and next buffered state the current time falls. Use this factor to lerp (linearly interpolate) the remote player's position: position = Vector3.Lerp(prevPos, nextPos, factor). Also interpolate rotation using quaternion slerp for smooth turning. The result is fluid movement that masks the discrete nature of network updates.
Extrapolation handles gaps when a state update is late. If the expected update has not arrived, continue moving the remote player in the direction and speed of the last known velocity. This produces brief, approximate movement that looks better than freezing in place. When the late update arrives, smoothly correct to the actual position over a few frames rather than snapping instantly.
Step 6: Handle Disconnection and Recovery
WebSocket connections drop for many reasons: mobile users walk through a dead zone, a laptop closes temporarily, or the network has a momentary outage. Detect disconnections through WebSocket close events on both server and client. The client should display a "connection lost" indicator and attempt to reconnect automatically with exponential backoff (1 second, 2 seconds, 4 seconds, up to a maximum).
On the server, freeze the disconnected player's character. Other players should see it stop moving, and it should not be affected by game events during the disconnection. Set a timeout (30 to 60 seconds) after which the player is fully removed from the game. If they reconnect before the timeout, restore their state and resume normally.
Reconnection requires state synchronization. The reconnecting client needs the full current game state: all player positions, scores, inventory, and world state. Send a "full state" snapshot when a player reconnects, then resume normal incremental updates. This snapshot can be large, so compress it and send it as a single message before resuming the regular update stream.
Heartbeat messages detect silent disconnections. Send a ping from the server every 10 seconds. If the client does not respond with a pong within 5 seconds, consider the connection dead. Without heartbeats, a silently dropped TCP connection can leave a ghost player in the game for minutes until the OS-level TCP timeout fires, which confuses other players and wastes server resources.
Multiplayer in Babylon.js is about synchronizing game state between a server and multiple clients with minimal perceived latency. Client-side prediction makes the local player feel responsive, entity interpolation makes remote players look smooth, and an authoritative server ensures consistency and prevents cheating. The rendering layer (Babylon.js) and the networking layer (WebSockets) are separate concerns that communicate through state updates.