What We Build
Real-time action. Shooters, arena games, anything where a hundred milliseconds decides the outcome. Astar Strike Online is a multiplayer FPS running on Photon Quantum; in a browser, which is the harder version of an already hard problem.
.io and casual arena. Short-session, high-churn, mass-lobby games where the technical challenge is filling matches rather than shaving latency. We’ve built these on mobile and web.
Turn-based and asynchronous. Card games, strategy, management sims. The netcode is easier and the backend is harder; persistent state, seasons, standings, and an economy that has to stay balanced across thousands of concurrent players.
Social and shared spaces. Voice, avatars, hand presence, and users arriving from different device classes into the same room. See the cross-platform VR and PC environment we built.
Competitive and ranked. Matchmaking, skill rating, leaderboards, and the anti-cheat that has to exist before ranked mode does, not after.
Live-ops backends. Accounts, progression, events, remote configuration, version gating — the layer that lets you run a live game without shipping a build for every change.
Choosing the Netcode
There is no default answer, and picking wrong is expensive to reverse. Here’s how we actually decide:
| Best for | Model | Cheat resistance | |
|---|---|---|---|
| Photon Fusion | Most modern real-time games; action, co-op, shooters | Tick-based, client prediction and lag compensation, host or dedicated server modes | Good in server mode |
| Photon Quantum | Competitive and esports titles, fighting, RTS, anything with prizes | Deterministic ECS with rollback; only inputs travel | Highest – clients can’t diverge |
| Photon PUN 2 | Simple room-based games, and existing PUN codebases | Room-based, client-hosted, mature and simple | Low – client-authoritative by nature |
| Custom Node.js server | Anything where the outcome has value attached | Fully authoritative, we own the logic | Highest – we control every rule |
Fusion is where most new real-time projects should start. It handles prediction and lag compensation properly, and its dedicated-server mode gives you authority without writing a simulation from scratch.
Quantum is what you use when players have a reason to cheat and determinism is worth the constraint. Because only inputs are transmitted and every client runs an identical simulation, there’s no divergence to exploit. That’s why it’s behind Astar Strike, where an on-chain reward layer meant every match outcome had a market value attached to it.
PUN 2 is still the right call for straightforward room-based games and for maintaining an existing codebase. We used it on a real-time .io mobile title with lobbies, live leaderboards and bots but we wouldn’t start a new competitive game on it.
Our own servers come in when the game logic itself has to be authoritative rather than just the transport.
When Photon Isn’t Enough: Our Own Servers
Transport is not authority. Photon moves messages between clients reliably; it doesn’t decide whether a shot hit, whether a hand of cards was legal, or whether a match result was earned.
For anything where an outcome maps to value; ranked position, a token, a squad asset, a payout, that decision belongs on a server we control. So we write authoritative game servers in Node.js, and the client becomes a renderer that submits intentions and displays results.
We’ve done this for a football management sim where the entire match simulation and economy run server-side, and for iGaming formats where every round is resolved and logged before the client is told anything. Around it sits session validation, replay protection, rate limiting, and a per-round audit trail because when assets change hands, disputes are inevitable and “we have the log” is the only useful answer.
The rule is simple and we apply it everywhere: assume the client is hostile and design as though it has already been compromised.
The Problems That Actually Kill Multiplayer Games
Latency gets all the attention. These are what we see go wrong:
Empty lobbies. A match that can’t fill is a match nobody plays, and the effect compounds; the first players leave, so it stays empty, so the next players leave. Bots, region logic and match-fill are launch requirements, not polish. We build them in before release because retrofitting them into a game with declining numbers rarely works.
Disconnects. Players lose signal in lifts, tunnels and on hotel wifi. A design that assumes stable connections produces broken matches and furious reviews. Our .io work fills a disconnected player’s slot with a bot so the match survives the person leaving it.
Reconnection. Coming back into a match in progress with correct state is significantly harder than joining a fresh one, and it’s usually deferred until it’s expensive.
Version fragmentation. Once there are players, you need version gating so out-of-date clients can’t join a live match and corrupt it.
Cheating. It arrives faster than anyone expects, and the architectural decisions that prevent it are made at the start or not at all.
Multiplayer Per Platform
Browser. Our particular specialism. Over 100,000 players across our web titles, with the constraints that come with it: memory ceilings, tabs being backgrounded and throttled, and sessions that have to survive a laptop waking from sleep. See WebGL game development.
Mobile. Unstable connections as the normal case rather than the edge case, plus battery and thermal budgets that shape how often you can afford to send anything.
VR. Head and hand pose to synchronise convincingly, physical object handoffs between players, spatial voice and a frame rate that can’t drop, because in a headset that isn’t a quality problem but a comfort one. See VR and XR development.
Common Questions
Fusion for most new real-time games, Quantum when cheating matters or the game is competitive. It’s a decision worth twenty minutes on a call before anyone commits.
If outcomes have value attached, yes. If it’s casual co-op with friends, usually not. The cost difference is significant, so it’s worth deciding deliberately.
Yes; that’s co-development, and netcode is one of the most common workstreams studios hand us because it’s among the hardest things to hire for directly.
Start a Project
Tell us the game, the target concurrency, and whether anything of value rides on the outcome. That last answer changes the architecture more than anything else.
Scope, team composition and a fixed quote come back within two business days.