Game Nock
Start with the game, not the technology
The right architecture follows from how the game plays: how many players share a session, how fast they need to react to each other, and how much it matters if someone cheats. A turn-based strategy game, a 4-player co-op shooter and a 60-player battle royale are different engineering problems even though all three are "multiplayer."
Peer-to-peer vs dedicated server
Peer-to-peer connects players directly to each other. It is cheaper to run and simpler to build, and it suits small, casual or turn-based experiences well. It struggles once you need fairness, persistence or protection against cheating, because there is no neutral party holding the true game state.
A dedicated or relay server sits between players and holds that true state. It costs more to host and adds complexity, but it is what most competitive, persistent or monetised games need, because it gives you one place to validate what actually happened.
Client-authoritative vs server-authoritative
Client-authoritative games trust each player's device to report its own state. It is faster to implement and feels responsive, but it is straightforward to cheat, since a modified client can simply report false information.
Server-authoritative games have the server make the final call on movement, hits and results, with clients predicting locally so the game still feels responsive. It takes more engineering effort but is the standard for anything with real competition or an economy attached to it.
Picking a networking layer
- Photon Fusion — modern netcode with strong support for both client-authoritative and server-authoritative patterns, and good scaling for larger player counts. Our default for new competitive or action multiplayer.
- Photon PUN2 — simpler, room-based, well suited to smaller casual or social games where the extra ceremony of Fusion is not worth it.
- Custom Node.js backend — used alongside either, when the game needs its own authoritative logic for things like turn-based rules, matchmaking or an economy that should not live in the netcode layer at all.
What sits outside the netcode
Netcode handles movement and real-time state. Most games also need a separate backend for player accounts, inventories, matchmaking, leaderboards and live events. Treating these as one problem tends to produce a system that is hard to scale or debug. We usually build them as related but separate layers, so the multiplayer session can restart, scale or fail independently of a player's account and progress.
Questions worth answering before development starts
- How many players share a session, and how fast must they react to each other? This decides how much you need to invest in prediction and lag compensation.
- Is there anything worth cheating for? Rankings, real-money purchases or trading push you toward server-authoritative, even if it costs more.
- Does progress need to persist and sync across devices? If so, you need an account and backend layer from day one, not bolted on later.
- What is the realistic peak player count? Architecture that works at 100 concurrent players can fail in ways that are expensive to fix at 10,000.
Red flags
- A plan that names an engine but never mentions authority model or server hosting
- No answer for what happens when two players disagree about what occurred
- Backend and netcode treated as the same system with no separation
- No discussion of what happens to a live match when a server restarts or a player disconnects