Use a WebSocket server (Node.js, Elixir/Phoenix, or Go) holding authoritative game state per room, broadcasting deltas at a fixed tick rate, with clients rendering via Canvas or WebGL and reconciling with client-side prediction. Language matters less than a clean room/tick architecture.
At a glance
| Fact | Value | Source |
|---|---|---|
| Core transport for real-time web multiplayer | WebSocket API | developer.mozilla.org |
| Elixir Phoenix real-time framework example | Phoenix LiveView | developer.mozilla.org |
| Client rendering APIs for 2D games | Canvas or WebGL | developer.mozilla.org |
The practical stack is: a WebSocket server holding authoritative state per game room, broadcasting state deltas on a fixed tick, and a browser client that renders with Canvas or WebGL and predicts movement locally between updates. The WebSockets API is the transport almost everyone builds on; on top of it, Node.js with a rooms library, Go with a goroutine-per-room model, or Elixir’s Phoenix framework (Phoenix LiveView gives real-time interactive experiences over WebSocket) are all proven choices. Pick based on team familiarity rather than a theoretical ceiling – the architecture (authoritative server, tick rate, room isolation, reconciliation) matters more than the language.
For cross-platform glue code beyond networking – ads, saves, platform detection – the Playgama Bridge SDK documentation shows the same JS-interop pattern applied to multiple engines.
What goes where in the code
- Server: owns the source of truth for positions, hits, scores; runs the simulation loop; validates client input before applying it.
- Client: sends input intents, renders the last known state, interpolates or predicts between server snapshots to hide network jitter.
- Persistence: use Web Storage only for local prefs, not authoritative game state.
If you build in Unity, browser-side calls (matchmaking pings, analytics, ad triggers) go through a .jslib plugin as described in the Unity manual on interacting with browser scripting; Godot 4 exposes the same kind of bridge via the JavaScriptBridge singleton.
Sources
- MDN: WebSockets API
- MDN: Canvas API
- MDN: WebGL API
- Unity manual: interacting with browser scripting
- Playgama Bridge SDK docs
- MDN: Web Storage API
Related questions
Should the server or the client decide who wins a hit?
The server should be authoritative for all gameplay-affecting outcomes; clients only send inputs and render predicted/interpolated results to avoid desync and cheating.
Does the tech language matter more than architecture?
No. Room isolation, tick rate, and reconciliation logic matter more than choosing Node.js, Go or Elixir; any can serve real-time 2D multiplayer well.
Last updated: 24 September 2026