Choose an authority model
Choose ownership per collection. Players can control their cursor or aim while the server controls scores and hit results.
Picking by game
| Your game | Model | Why |
|---|---|---|
| A jam prototype, a shared whiteboard, a party game on one couch | Relay room | Nothing to cheat at, nothing to deploy |
| Cursors, avatars, emotes, camera angles | Ownership, no validator | A lie costs nothing, and input is instant |
| A platformer, a racer, a top-down shooter’s movement | Ownership plus validate | The client keeps the feel, the server refuses the impossible |
| Scores, decks, turn order, loot, hit results | Server-owned state plus RPCs | The outcome is not the client’s to report |
| Physics, projectiles, timers, AI, anything that keeps happening | Tick room | Something has to run with nobody sending input |
| A leaderboard-backed competitive match | Tick room, server-owned everything | The result is worth lying about |
Most games use more than one row. A shooter owns its own aim locally, validates its movement, and keeps damage server-owned.
Client-owned state
Use owned writes for values a player controls directly. Add validation to accept, clamp, or reject those writes on the server.
Server-owned state
Use RPCs for actions such as playing a card or starting a round. The server checks the request and updates state. Use a tick loop for simulation that continues between inputs, including physics, AI, and projectiles.
Relay rooms
Relay rooms provide messaging and optional shared state with built-in ownership policies. Deploy a schema to use shared state, or join a raw relay for your own message format. Use room code when your game needs custom rules.