irt.io vs Rune
Rune is an SDK and an app for social multiplayer games. You write one deterministic logic file, and it runs on every player’s device with actions applied in the same order everywhere. irtio runs one copy of your room on a server, and clients hold a synced view of it.
When Rune is the better choice
- Distribution is part of what you want. A Rune game is played inside their app, next to other games and the players already there. irtio hosts your rooms and sends you nobody. You bring your own audience.
- The game fits a deterministic action model. Turn-based games, puzzle races and small fast-casual games express well as a setup function, a set of actions and an update.
- You want no netcode at all. When the logic is deterministic and every device runs it, the SDK can hide latency and rejoin a player without you writing anything.
- Mobile and JavaScript, small builds. That is what the model is tuned for.
When irt.io is the better choice
- You ship on your own site. irtio is a library you add to a game that keeps its own loop, renderer and build, and it runs wherever your page runs.
- Only the server should know something. irtio filters state per collection, by role or by position, so a hidden hand, a spawn table or the far side of the map never reaches a client. Server-owned collections are written by the server alone. See Visibility.
- The simulation does not have to be deterministic. Only the server steps the world, so it can run a physics engine, hold far more state than a phone should, and correct clients that disagree.
- You want rooms with a life of their own. An irtio room keeps state when nobody is connected, hibernates at no cost, wakes on the next join, and can hold ladders, saves and timers.
Model comparison
| Rune | irt.io | |
|---|---|---|
| Authority | The shared deterministic logic, run on every device | The server, per instance, with validators |
| Who operates the server | Rune | irtio |
| State model | One game state, produced by actions applied in order | Typed schema, per-instance ownership, binary deltas |
| Prediction | Comes with the deterministic model | Built in for physics rooms, interpolation for everything else |
| Physics | Whatever runs deterministically inside your logic | Rapier 3D or matter.js 2D, stepped on the server |
| Voice | Outside your game code | joinVoice(room) |
| Testing | A local view of several players at once | 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 | TypeScript, browser clients |
What porting looks like
The pieces line up more neatly than the two models suggest, because a Rune logic file and an irtio room file both describe one authoritative game state.
Your state shape becomes a schema, which is a declaration rather than a
plain object: named collections, sized fields, and one owner per instance. Your setup function
becomes onCreate and the defaults in that schema. Each action becomes an RPC over a server-owned collection, and the body of the handler usually
survives unchanged, because it already reads and writes one state object and already throws to
refuse an illegal move. An update loop becomes the room’s tick.
Two constraints relax on the way over. The logic no longer has to be deterministic across devices, since only the server runs it, and it no longer has to be small enough for every phone to hold. Both of those free you to keep state clients never see, which is the change most games use first.
One constraint arrives. Room code is server-only and synchronous, and your rendering code is now on
the other side of a network boundary, reading room.state and drawing room.render.
You also take on the parts the app was doing: where the game is hosted, how players find each other, and what the first screen is. Quick match covers the queue, and room codes cover playing with friends.
Next steps
- Introduction for what irtio is in one page.
- The mental model for ownership and the ladder.
- RPCs for server-decided actions.
- Quick match for putting strangers in a room.
This page describes each product’s model as it stood at the page’s last review. Send corrections to hello@irt.io.