WebRTC multiplayer without a server

the catch

What WebRTC still needs

1. Signaling. Before a connection exists, two browsers must exchange an offer, an answer and ICE candidates through some third party. WebRTC does not define how.
2. STUN. Each browser asks a STUN server for its public address so peers can find each other through home routers.
3. TURN or relay. Behind symmetric NATs and some corporate or mobile networks, a direct path never opens. Without a relay, those players simply cannot play.

On top of that, a real game needs room membership (who should connect to whom), reconnection, and a place for state that must survive a disconnect.

solution

How the Multiplayer API handles it

Signaling rides inside the sync call the client makes anyway (signals in /v1/rt/sync), so there is no separate signaling server. GET /v1/rt/ice returns ICE servers. When a pair of peers cannot connect, only that pair falls back to the server relay; the rest of the room stays direct.

Once peer connections are up the client calls the server only every five seconds. When a player writes shared state, the SDK sends a ~10-byte nudge on the direct channel so peers read it immediately — fast state without fast polling.

const room = await mp.quickmatch({ max_players: 8 });
room.on('transport', (mode) => console.log(mode));   // 'p2p' | 'mixed' | 'relay'
room.send({ x, y });                                  // direct when possible, relayed otherwise

Bringing strict-NAT players back to direct

Declare a TURN server in the game configuration using the coturn shared-secret convention (understood by Cloudflare, Twilio, Xirsys and most managed TURN services). The secret never leaves the server; each client receives an expiring credential.

{ "turn": { "urls": ["turn:turn.example.com:3478"], "secret": "...", "ttl": 3600 } }