Multiplayer limitations
Before adding multiplayer, decide whether players need a temporary match or progress they can return to later. Ask Ziva: “Add multiplayer for a small co-op game. Explain what happens if the host leaves and whether we need saved progress.”
Ziva’s relay requires Pro or Ultra. Basic accounts that have already used multiplayer keep access. Bandwidth is charged to the game owner’s account; reaching its monthly cap prevents new connections until the next cycle. Saved room data also uses persisted storage.
The two models
Session multiplayer
One player’s running game acts as the host and coordinates the others. Use this for a lobby, a short co-op demo or a casual match. The Multiplayer guide includes the setup.
- Progress: not a saved game. If the host leaves, a remaining player can become host and rebuild the player roster, but this does not preserve the whole running world. Scores, inventories and other state not synchronized to the remaining players can be lost.
- Cost: bandwidth only, with no per-room storage charge.
Saved and shared progress
The relay stores the room’s game data instead of relying on a player’s machine. Players can leave and return to the saved data, even after everyone disconnects. Use Persistent and shared state for card, board, turn-based games or small saved worlds.
- Progress: saved room data survives disconnects and empty rooms. Your game must save the data it needs; the relay does not save the scene automatically.
- Cost: bandwidth plus persisted storage, within the storage cap below.
- Important: this mode does not replicate Godot scenes and is not meant to be combined with session multiplayer. Any connected player can write room data; if two write the same value, the last write accepted by the relay wins.
When to use which
| Your room needs | Use |
|---|---|
| A temporary lobby, casual match or co-op demo | Session multiplayer |
| Position and animation sharing with a clear host | Session multiplayer |
| Saved data that survives the host leaving | Saved and shared progress |
| Progress that survives everyone disconnecting and returning | Saved and shared progress |
| Room data stored on the relay rather than one player’s machine | Saved and shared progress |
If losing the host would lose progress you care about, plan how to save it before building the game.
Hard limits
32 peers per room
A room accepts at most 32 simultaneous connections. The 33rd connection to the same room is rejected. For more players overall, use separate rooms, such as one per match, rather than one larger room.
~1MB saved-data limit
Persisted room data is capped at roughly 1 MB per room. Store small values such as item IDs, scores and counters, not artwork or long chat logs. This is a storage ceiling, not a per-message limit. An oversized write fails rather than being silently cut down.
Latency
Both modes send messages through Ziva’s hosted relay, even when players are on the same local network. Players far from the room’s server can notice more delay. Try the game from the places your players will connect from.
| Game type | Fit |
|---|---|
| Turn-based, card or board game | A good fit; small network delays usually do not affect taking turns. |
| Casual co-op, lobbies or slow movement | Try it with players near each other; delay grows across regions. |
| Competitive shooters or other fast, global action games | Use networking designed for low, geographically fair delay instead. |
Ask Ziva for ENet, a dedicated server, Steam or Epic Online Services if the relay does not fit. Building with your own networking is available on any plan; it does not set up Ziva’s relay.
Privacy
Room data passes through the hosted relay, and saved/shared progress is stored there. Connected players receive the room’s shared data. Do not put secrets or private account information in it. The relay’s account and game IDs are public identifiers, not passwords.
Optional reference: relay measurements and routing
Every message takes an application round-trip through the relay: from a player through Cloudflare’s edge to the room’s Durable Object (its server-side room), onward to the other player, and back. There is no peer-to-peer path or LAN shortcut. Session multiplayer avoids the saved-state write, not the relay route.
A deployed-relay measurement used two WebSocket clients in US-West, near Cloudflare’s SJC serving location, with 40-50 samples per run:
| Metric | Relay round-trip |
|---|---|
| p50 (half the samples were at or below this) | ~40 ms |
| p90 (90% were at or below this) | ~135 ms |
| Best observed | ~25 ms |
These are nearby-client measurements, not a promise for every player. A room is pinned to a single Cloudflare location, nearest whoever opens it first, with no regional sharding or migration. Distant players add their internet round-trip to that location.
As a rough guide, inter-region round-trips commonly add about 150 ms US to EU or 250 ms US to Asia. A transatlantic player may see a relay round-trip around 150-250+ ms, and players on opposite sides of the world may see more. A single-location relay cannot give every player the sub-50 ms, geographically fair round-trip expected for competitive action.
These figures describe round-trip delay, not throughput or a guarantee about capacity. The 32-connection and roughly 1 MB storage limits still apply.