Every studio that has shipped a multiplayer game has a war story about the networking. The demo worked perfectly on LAN. Then real players connected from real networks with 150ms latency, packet loss, and the creative determination to break everything. What worked in testing fell apart in production.
Multiplayer game development is fundamentally different from single-player. It's not a feature you bolt on — it's an architectural decision that shapes every system in your game. This guide covers the core architectures, the production-ready middleware options, and the real costs of building and running multiplayer at scale.
Client-Server vs Peer-to-Peer: The Foundational Choice
Client-Server (Authoritative)
One machine (the server) is the source of truth for game state. Clients send inputs, the server processes them, and sends back the authoritative state. This is the standard architecture for competitive multiplayer, MMOs, and any game where cheating prevention matters.
How it works: 1. Client sends input: "Player pressed fire at timestamp T" 2. Server validates: Is the player alive? Do they have ammo? Is the target in line of sight? 3. Server updates state: Apply damage, update positions, resolve physics 4. Server broadcasts: Send updated state to all relevant clients 5. Clients render: Interpolate between received states for smooth visuals
Advantages: Cheat-resistant (server validates everything), consistent state across all players, scales better with dedicated server infrastructure.
Disadvantages: Requires server infrastructure (cost), introduces server latency on top of network latency, more complex to develop.
Peer-to-Peer (P2P)
Each player's machine communicates directly with other players. There's no central authority — each client runs its own simulation and shares state.
Advantages: No server costs, lower latency for small player counts (2-4 players), simpler to prototype.
Disadvantages: Vulnerable to cheating (each client trusts other clients), desync issues, doesn't scale beyond 8-12 players, one player's bad connection affects everyone.
Relay Server (Hybrid)
A server relays packets between clients but doesn't process game logic. This gives you NAT traversal and connection management without the cost of running game simulation on the server. Photon's default mode operates this way.
Best for: Co-op games, casual multiplayer, games where cheating prevention is low priority and player count per session is under 16.
The Practical Rule
If your game is competitive, involves real-money stakes, or needs more than 8 players per session — use authoritative client-server. For everything else, relay or P2P can work and costs significantly less to operate.
Networking Middleware: Production Options
Photon PUN 2
The veteran choice. Photon PUN 2 (Photon Unity Networking) uses an RPC-based model where you call remote methods across the network. It's intuitive for Unity developers because it feels like calling regular functions.
Session size: Up to 16-32 players (relay mode) Pricing: 20 CCU free, 100 CCU at $95/month, 500 CCU at $195/month, custom pricing above Latency model: Relay server (Photon Cloud) — clients send to Photon, Photon relays to other clients Best for: Room-based games (party games, fighting games, small-scale shooters), rapid prototyping
The RPC model is simple but creates problems at scale: bandwidth grows with call frequency, and there's no built-in state reconciliation. If a packet drops, you need custom logic to handle the desync.
Photon Fusion
Photon's modern replacement for PUN. Fusion uses a state synchronization model: you define networked properties, and Fusion handles replication, interpolation, and lag compensation automatically.
Session size: Up to 200 players (Shared Mode) or 200 players (Host Mode with dedicated server) Pricing: Same CCU-based tiers as PUN Latency model: Supports relay (Shared Mode) and authoritative (Host/Server Mode) Best for: Competitive games, action games, anything that needs authoritative validation
Fusion's killer feature is its built-in lag compensation. It provides a "SnapShot" system that lets the server rewind time to validate shots — the same technique used in AAA shooters. This is extremely hard to build from scratch and Fusion gives it to you out of the box.
Netcode for GameObjects (Unity)
Unity's first-party networking solution, integrated into the engine. It provides NetworkObject, NetworkVariable, and RPC abstractions that feel native to Unity's component model.
Session size: Recommended up to 16-32 players Pricing: Free (part of Unity) Latency model: Client-server (supports dedicated server or listen server) Best for: Studios that want to stay within the Unity ecosystem, games with moderate player counts
NGO is improving rapidly but lacks the maturity and battle-testing of Photon. If you're building a session-based game with under 20 players and your team is Unity-native, it's a viable choice. For anything competitive or high-scale, Photon Fusion is the safer bet.
Mirror (Open Source)
Community-maintained open-source networking for Unity. Supports up to 100+ players with authoritative server architecture. No subscription costs — you host your own servers.
Session size: Tested up to 200+ players Pricing: Free Best for: Indie studios with server operations experience, MMO-lite projects, budget-conscious development
The tradeoff is support. Mirror is community-maintained, and debugging networking issues without commercial support can eat weeks of development time.
Custom Solutions (ENet, LiteNetLib)
For studios that need complete control, low-level libraries like ENet or LiteNetLib provide reliable UDP transport without any game-layer opinion. You build the entire networking model — serialization, state sync, interpolation, lag compensation — from scratch.
Best for: Studios with dedicated networking engineers building MMOs, competitive esports titles, or games with novel networking requirements.
Not for: Any team that doesn't have at least one senior network programmer with shipped multiplayer experience.
Backend Services: The Meta-Game Layer
Real-time networking handles what happens in a match. Backend services handle everything else: accounts, matchmaking, progression, economy, analytics, and social features.
PlayFab (Microsoft)
The most feature-complete game backend service. PlayFab provides: - Player accounts and authentication (device ID, platform login, custom) - Matchmaking (rule-based, latency-based, skill-based via Elo/Glicko) - Economy (virtual currencies, catalogs, purchases, trading) - Leaderboards (with automatic reset schedules) - CloudScript (server-side JavaScript/Azure Functions for game logic) - LiveOps (events, segments, experiments, push notifications)
Pricing: Free up to 100K users/month, then pay-as-you-go. A game with 50K DAU typically costs $500-2,000/month.
Unity Game Services (UGS)
Unity's first-party backend. Covers authentication, cloud save, leaderboards, matchmaking, analytics, and remote config. The advantage is native Unity editor integration — everything configures from within the engine.
Pricing: Free tier generous for small games, enterprise pricing for scale.
UGS is still maturing. If you need advanced economy, complex matchmaking rules, or server-side game logic, PlayFab is more capable today.
Build Your Own
Some studios build custom backends with Node.js, Go, or Rust for the real-time layer, and PostgreSQL or Redis for persistence. This gives maximum control but costs 3-6 months of engineering time and ongoing maintenance.
Only worth it if your game has unique backend requirements that commercial services can't handle — or if vendor lock-in is a serious business risk.
Lag Compensation: Making It Feel Fair
The biggest technical challenge in multiplayer is making the game feel responsive when players have 50-200ms of network latency. The core techniques:
Client-Side Prediction
The client doesn't wait for the server to confirm each input. It predicts the outcome locally and shows it immediately. When the server confirms, the client reconciles — if the prediction was right (usually 99% of the time for movement), nothing changes. If it was wrong, the client snaps to the corrected state.
This is why your character moves instantly when you press forward, even with 100ms ping. The client predicted the movement, and the server confirmed it 100ms later.
Server Reconciliation
When the server corrects a client's prediction, the client needs to smoothly resolve the difference. Snapping to the corrected position looks terrible. Instead, the client replays all inputs since the corrected state, creating a smooth correction.
Entity Interpolation
Clients render other players slightly in the past (typically 100-200ms behind real-time) and interpolate between known positions. This creates smooth movement even when network updates arrive irregularly. The tradeoff: what you see is slightly behind reality.
Lag Compensation (Server-Side Rewind)
When a player fires a shot, the server rewinds all entities to where they were at the time the shot was fired (accounting for the shooter's latency) and checks for hits. This is why "I shot first!" arguments exist — both players see themselves shooting at the right time, because the server compensates for each player's latency independently.
Photon Fusion implements this automatically. Building it yourself requires frame-accurate state history and precise timestamp synchronization.
Matchmaking: Getting Players Into Games
Matchmaking is deceptively complex. The goals conflict: match players of similar skill (fairness) while keeping wait times short (engagement) while filling servers efficiently (cost).
Skill-Based Matchmaking (SBMM)
Use Elo, Glicko-2, or TrueSkill rating systems. Elo is simple and well-understood. Glicko-2 adds a confidence interval (new players have wider matching). TrueSkill (Microsoft) handles team-based matchmaking.
Implementation tip: Start with wide skill bands and tighten them as your player base grows. A 5-minute queue in a game with 500 concurrent players means your matchmaking is too strict.
Regional Matchmaking
Always match by latency region first, skill second. A fair match at 200ms ping is worse than a slightly mismatched game at 40ms. Use regional server deployments and route players to the closest available.
Session Backfill
When a player disconnects mid-match, backfill the slot. Don't force remaining players into a 4v5. This requires your matchmaking system to track active sessions and their available slots.
Scaling to Thousands of Concurrent Users
Going from 100 to 10,000 CCU introduces infrastructure challenges that many studios underestimate.
Server Orchestration
You need automated scaling — spinning game server instances up when demand rises and down when it falls. Options: - Multiplay (Unity): Managed game server hosting with auto-scaling - PlayFab Multiplayer Servers: Azure-backed game server hosting - Custom (Kubernetes + Agones): Open-source game server orchestration on any cloud. Powerful but requires DevOps expertise.
Bandwidth Costs
A real-time multiplayer game sends 20-60 KB/s per player per direction. For a 10-player session at 40 KB/s, that's 400 KB/s per session, or about 1 GB per hour. At 1,000 concurrent sessions, you're moving 1 TB per hour. Cloud bandwidth at $0.08/GB adds up fast — budget $5,000-20,000/month for bandwidth alone at this scale.
Database Scaling
Player data, match history, leaderboards — these grow linearly with your player base. Use managed databases (AWS RDS, Azure SQL, PlanetScale) and implement read replicas early. Don't let the database become the bottleneck when your game goes viral.
What Multiplayer Infrastructure Costs
Rough monthly costs by scale:
| CCU | Server Hosting | Networking Middleware | Backend (PlayFab) | Bandwidth | Total |
|---|---|---|---|---|---|
| 100 | $50-100 | $95 (Photon) | Free | $50 | ~$300 |
| 1,000 | $300-800 | $295 (Photon) | $200-500 | $500 | ~$1,500 |
| 10,000 | $2,000-5,000 | Custom pricing | $1,000-3,000 | $5,000 | ~$10,000-15,000 |
| 50,000 | $10,000-25,000 | Custom pricing | $5,000-10,000 | $20,000 | ~$40,000-60,000 |
These are operational costs — on top of the development cost to build the game itself.
WODH's Multiplayer Experience
We built Soul of King, a 5v5 MOBA with real-time multiplayer using Photon. That project taught us the full scope of multiplayer development: authoritative game logic, lag compensation for action combat, matchmaking across skill tiers, and infrastructure scaling for concurrent players across multiple regions.
Our Games Studio multiplayer development services cover architecture design, Photon/NGO integration, PlayFab backend setup, and the infrastructure automation needed to run multiplayer games in production. Whether you're building a co-op mobile game or a competitive PC title, we can help you avoid the networking mistakes that delay launches by months.