irt.io vs Playroom
Playroom is a browser SDK for multiplayer games with no backend of your own. State is shared key-values, and one player’s browser acts as the host for anything that has to be decided. irtio has no host. The server decides.
When Playroom is the better choice
- You want players in a room today. Playroom’s on-ramp is one call. Nothing is deployed, nothing is declared, and the multiplayer part of a jam game is done in an afternoon.
- The game is cooperative or social. When a lie costs nothing, host authority costs nothing either, and you save yourself a server.
- You want the pieces around the game too. Playroom ships things most small games never get to on their own, including a lobby and on-screen controls for phones.
- You never want to write server code. All of your code stays in the browser, in one build, with one language and one deploy.
When irt.io is the better choice
- The outcome matters. Scores, ladders, card decks, hit results and turn order all decide the game. With host authority, one player’s machine decides them, and a modified client is that machine. In irtio those values live in a server-owned collection and only the server writes them.
- Some players must not see some state. irtio filters state per collection, by role or by position, so a hidden card or the far side of the map never reaches a client that should not have it. See Visibility.
- The room should outlive the players. An irtio room is a server-side object. It keeps its state when everyone leaves, hibernates at no cost, and wakes at the tick it stopped on. There is no host to migrate when someone closes a tab.
- You want physics, prediction, voice or automated tests. These are irtio features rather than code you write.
Model comparison
| Playroom | irt.io | |
|---|---|---|
| Authority | The host player’s browser | The server, per instance |
| Who operates the server | Nobody, their service carries the traffic | irtio |
| State model | Shared key-values, global and per player | Typed schema, per-instance ownership, binary deltas |
| Prediction | You write it | Built in for physics rooms, interpolation for everything else |
| Physics | Bring your own, run on the host | Rapier in 3D or 2D (or matter.js), stepped on the server |
| Voice | Not included | joinVoice(room) |
| Testing | Play it with real people | In-process rooms on a fake clock, plus simulated players over real sockets |
| Hibernation and idle cost | No server of yours to idle | Rooms sleep after idleMs and wake with state intact |
| Language | JavaScript in the browser | TypeScript, browser clients |
What porting looks like
Start by sorting your state keys into two piles: values a player owns, and values the game decides.
The first pile is close to free. A per-player key becomes an entity that onJoin adds under the
client id, owned by that client, and the client writes it exactly the way it wrote before. Position,
name, colour, ready flag and held input all land here. See The mental model.
The second pile is where the work is, and it is the work you came for. Every branch guarded by a
check for whether this browser is the host becomes server code. Mark the collection server-owned in
the schema, and no client can write it at all, at compile time as well as
at runtime. The button that used to set a key becomes an RPC, and the handler
decides what actually happened. Anything the host ran on a timer becomes the room’s tick.
The rest is smaller than it looks. Your renderer does not change. Room codes still exist, so the
join flow keeps its shape. Presence becomes onJoin and onLeave. The new pieces are a schema
file, a room file, and irtio deploy.
You can also do this in stages. Rung one of the ladder is client-owned state with no server rules at all, which is roughly where Playroom leaves you, and every rung after it is a local edit to the same two files.
Next steps
- Your first room for the ten-minute version.
- The mental model for ownership and the ladder.
- Server authority and validation for validators and the tick.
- Visibility for hidden state.
This page describes each product’s model as it stood at the page’s last review. Send corrections to hello@irt.io.