Reusable multiplayer infrastructure

Meet on the server.
Play peer to peer.

A deliberately small rendezvous service for browser games. It creates short-lived lobbies, authenticates participants, relays WebRTC setup messages, and then gets out of the gameplay path whenever the network allows it.

2–16 players WebRTC DataChannels TURN recovery Optional verified peer content
Connection path
Browser A Static game
Setup service Short-lived control plane
Browser B Static game
WebRTC gameplay + optional content

Gameplay authority stays in the game. The service never becomes the simulation server.

01

Thin control plane

Rooms, capabilities, signaling, expiry, reconnects, and TURN credentials. No game rules and no authoritative world state.

02

Direct data plane

Once negotiation succeeds, reliable and realtime gameplay channels travel between browsers instead of through the setup service.

03

Optional content plane

Games that need large assets can opt into verified peer seeding with hashes, resumable chunks, bounded upload pacing, and relay-aware policy.

How it works

Three phases, one narrow service.

The server exists to establish safe connectivity. After setup, the interesting traffic belongs to the peers.

Peer Browser A Loads the static game, keeps its own state, and owns its WebRTC connections.
Control plane Setup service Creates membership capabilities and relays only the setup envelopes needed by WebRTC.
Peer Browser B Runs the same client contract and receives gameplay directly after negotiation.
WebRTC DataChannel after setup

2–16 players

Choose the topology in the game.

The lobby only defines who may signal. The browser decides whether those participants form a full mesh or connect through a host.

Current model

Full mesh

Authority boundary

Infrastructure, not game authority.

The useful abstraction is the boundary: connectivity is reusable; game semantics remain specific to each game.

Setup service

Connectivity responsibilities

  • Short-lived rooms and 2–16 player lobbies
  • Participant identities and private capabilities
  • Targeted WebSocket signaling relay
  • Expiry, reconnect replacement, admission and resource limits
  • Short-lived authenticated TURN credentials

Game / peers

Gameplay responsibilities

  • Rules, simulation, rendering, and validation
  • Mesh versus host-spoke policy
  • Reliable versus freshness-first messaging
  • Sequencing, reconciliation, rollback, and anti-cheat policy
  • Which assets may be shared and trusted

Gameplay transport

Send intent, not the whole world.

For deterministic games, peers can apply the same compact sequenced command locally instead of repeatedly shipping large state snapshots.

01 · InputThe player produces a compact command.
02 · TransportWebRTC carries it to the required peers.
03 · SimulationEach device applies the same transition locally.
reliable channelJSON
{
  "type": "step",
  "participantId": "7Q1M8X2K",
  "seq": 42,
  "dx": 1,
  "dy": 0
}

The packet says what happened, not what every resulting coordinate must be. Sequence numbers make stale or duplicate inputs easy to reject.

ChannelSemanticsGood fit
ReliableOrdered and retransmitted until delivered.Moves, joins, scores, resets, inventory changes, turn-based commands.
RealtimeUnordered with zero retransmits; fresh information wins.Frequent movement/input hints where old packets are less valuable than new ones.

Static client modules

Use the same primitives in a real game.

The Pages demos import the production browser modules directly: two-player sessions, larger resilient lobbies, and optional verified peer content.

Live examples

Four games, one setup layer.

These clients are entirely static. Point them at a reachable setup service to create or join a real session.