irt.io vs Photon
Photon is a family of networking products for game engines: a hosted room service, a tick based netcode stack, a deterministic simulation engine, and a voice SDK. It is Unity first. irtio is one product, for games in a browser.
The structural difference is where the code runs. Photon’s cloud moves messages between clients, and your game logic lives in a client or in a dedicated server you arrange. On irtio the room is the server, it holds authority, and irtio runs it.
When Photon is the better choice
- You build in Unity. Photon’s tooling, samples and documentation are written for the Unity workflow, and its object and property model plugs into the engine. irtio has no engine integration and no C# client.
- You need deterministic lockstep. Photon’s deterministic engine is built for fighting games, RTS and anything where every machine must reach the same result from the same inputs. irtio has no equivalent.
- You ship to consoles or native mobile. Photon covers platforms a browser SDK never will.
- You want a long established hosted room service with wide regional coverage. That operating history is real and irtio is younger.
When irt.io is the better choice
- Your game is a web game written in TypeScript. One schema is imported by the browser and by the room, so a field rename is a compile error rather than a desync.
- You want the server to hold authority without hosting one. In the classic Photon room model a client acts as host, which means host migration and a trusted player. On irtio no client is ever the authority, and there is no machine for you to rent.
- You want validation and simulation server side by default. A validator can clamp or reject any client write, and a room can own state no client may touch at all.
- You want physics, prediction, voice and load testing from one package set rather than assembling them across products.
Model comparison
| Photon | irt.io | |
|---|---|---|
| Authority | A client host by default; a dedicated server in the server modes | Always the server |
| Who operates the server | Photon hosts the room service; dedicated servers are yours to arrange | irt.io |
| State model | Networked objects and properties in the engine, replicated by the SDK | Schema of collections, synced as binary deltas |
| Prediction | Built in to the tick based stack, with rollback | Built in, one option on joinRoom |
| Physics | The engine’s physics, networked by the SDK | Rapier or matter2d, stepped in the room |
| Voice | Photon Voice SDK | joinVoice(room) |
| Testing | Your engine’s test tools | In-process rooms with real clients, plus load runs |
| Idle rooms | Rooms close when the last player leaves | Rooms hibernate and wake with state intact |
| Language | C# and Unity first, with SDKs for other platforms | TypeScript on both sides |
What porting looks like
Start from the state, not the messages. Photon replicates engine objects with networked properties, so the port is a translation of those properties into schema collections. A networked player object becomes one entity per player, owned by that player. Anything the host was authoritative over becomes a server-owned collection that clients change through typed RPCs.
Remote procedure calls translate closely in shape. A call that any client could invoke becomes an RPC whose handler checks the caller and decides what happened, which is stricter than the original and usually shorter.
Two things do not translate. Host migration disappears, because no client is ever the authority. Deterministic lockstep has no counterpart: if your game is built on every client running the same simulation from the same inputs, irtio is the wrong shape and you should stay where you are.
Physics is a rewrite rather than a port. Engine physics running on a Unity client becomes a Rapier or matter2d world running in the room, with body positions written into schema fields. Bodies a player steers can be predicted locally so input stays instant.
Voice is one call. joinVoice(room) rides the connection the room already has, so there is no
second service to configure.
Next steps
- The mental model for rooms, owners and the schema.
- Server authority and validation for validators and RPCs.
- Physics rooms and client prediction.
- Voice for the call and what it costs.
- Simulated players for testing a room without sockets.
This page describes each product’s model as it stood at the page’s last review. If something here is wrong or out of date, write to hello@irt.io and it gets fixed.