Multiplayer & Networking Development Services

Multiplayer and Network Architecture

You've built a single-player game, the build is stable, and now comes the feature request: add multiplayer. This is where most teams severely underestimate the scope. Multiplayer isn't "add synchronization"—it's a complete rethinking of game logic, choosing a network architecture, and building server infrastructure from scratch.

Choosing Architecture: Authoritative Server vs. Relay

This is the first and most critical architectural decision. Everything depends on it: infrastructure costs, cheat prevention, development complexity, and player latency.

Relay Architecture (P2P with Relay)

In a relay scheme, clients don't connect directly. Instead, they exchange data through an intermediary server that simply forwards packets. The server runs no game logic—it's pure traffic routing.

When to use this:

• Cooperative games with low competition (co-op campaigns, small-scale real-time strategy)
• Prototypes and early versions
• Small studios without server expertise

Specific tools:

• Photon Relay — the most common choice for Unity. Fast setup, ready-made SDKs, clear CCU-based pricing.
• Unity Gaming Services Relay — built into the UGS ecosystem, works alongside Lobby and Netcode for GameObjects.

The problem: cheating. If the client is the source of truth, it can send arbitrary data. For competitive genres (shooters, fighting games, sports simulations), relay architecture is unacceptable.

Authoritative Server

All game logic runs on the server. Clients send only input (button presses, movement direction); the server computes physics, collisions, damage—and broadcasts results to clients.

This is the standard for any competitive genre. A cheater can send fake input, but the server validates it and either ignores it or applies validation logic.

Stack for Unity:

• Netcode for GameObjects (NGO) — Unity's official solution for authoritative multiplayer. Built on top of Unity Transport. Includes: NetworkVariable, NetworkObject, RPC calls out of the box. Relatively young but actively developed.
• Mirror — a uNet fork that's mature and well-documented. Huge example base, supports multiple transports (KCP, Telepathy, WebSockets). If your team worked with uNet before, Mirror is easier to adopt.
• Nakama — open-source game backend with server-side authoritative logic. Supports Lua/TypeScript/Go for server modules. Perfect when you need not just matchmaking, but also player profiles, inventory, and leaderboards.

Stack for Unreal:

• Unreal has built-in network architecture based on authoritative servers. Dedicated Server, actor replication, RPC—all part of the engine. Native tools suffice for most genres.

Lag Compensation

This is the most technically interesting aspect of network code in competitive games. Let's break it down in detail, because this is where most teams make critical mistakes that make shooters and fighting games "feel wrong."

The Problem

A player sees an enemy and clicks to shoot. Between the moment of input and when the server receives the packet, RTT/2 (half round-trip latency) passes. During that time, the enemy moved. If the server checks hit detection against the enemy's current position instead of the position the shooter saw—the player experiences "bullets don't register."

Client-Side Prediction

The client doesn't wait for server confirmation. It immediately applies its own actions locally—movement, animations, sounds. When the server response arrives, the client compares its state to the server state. If they match—good. If not, reconciliation occurs: the client reverts to server state and "replays" all unconfirmed inputs.

This requires storing input history on the client and quickly recalculating state. In NGO, this is implemented manually through NetworkBehaviour with custom prediction logic. Mirror offers NetworkTransformReliable with basic built-in prediction.

Server-Side Rewind

When the server receives a "fire" command from client A, it takes the timestamp from the packet and "rewinds" the world state—back to the moment client A saw it. It checks hit detection against that "old" enemy position. If it hit—the hit counts.

Implementation requires:

• Storing state history (positions of all objects) for the last N milliseconds (typically 200-500 ms, based on max acceptable ping)
• Efficiently interpolating states by timestamp
• Limiting rewind depth to prevent giving advantage to players with very high ping

Without this mechanic, players with 100+ ms ping constantly "miss" enemies in shooters. With it—the game feels fair for everyone.

Interpolation vs. Extrapolation on Client

Remote objects (enemies) aren't predicted by the client—they're interpolated between the two most recent known states. This creates slight visual lag (typically 1-3 network ticks), but movement looks smooth.

Extrapolation (predicting enemy movement) gives less visual latency, but creates jerky "snaps" when direction changes. Most shooters use interpolation.

Server Infrastructure

Matchmaking and Lobbies

• Nakama — includes matchmaking out of the box, write custom matching rules in TypeScript/Go.
• PlayFab (Microsoft) — full-featured game backend. Matchmaking, inventory, cloud saves, analytics. Integrates well with Azure.
• Unity Gaming Services Lobby — simple but sufficient for most indie projects.

Dedicated Servers

Authoritative multiplayer requires dedicated servers. Hosting options:

Transport Protocol

• UDP — standard for real-time games. Low latency, packet loss possible. Most game engines and libraries run on top of UDP with custom reliability logic.
• WebSocket — necessary if targeting WebGL. Works over TCP, slightly higher latency, acceptable for casual genres. Photon and Mirror support WebSocket transport.
• KCP — UDP protocol with reliability elements. Used in Mirror and other solutions as a compromise between speed and reliability.

Social Features

Multiplayer isn't just technical sync. Players need tools to interact.

Standard features:

• Friends and invites — through platform APIs (Steam Friends, Game Center, Google Play Games) or custom service in Nakama/PlayFab
• Voice chat — Vivox (standard for PC/console, integrated through Unity Gaming Services), Agora (cross-platform including mobile)
• Text chat — important to moderate content. Ready solutions: PlayFab Chat, custom WebSocket channel with moderation
• Leaderboards — Nakama, PlayFab, GameSparks. Important to separate global and friends-based leaderboards
• Clan system — non-standard feature requiring separate development. For most projects, grouping in Nakama is sufficient

Authentication

Never invent your own authorization system. Use established providers:

• PlayFab — supports anonymous login, Steam, Google, Apple, custom ID
• Nakama — similar, plus email/password out of the box
• Firebase Auth — well-suited for mobile games, deep integration with Firebase Analytics and Remote Config

For competitive games, account protection is critical: two-factor authentication, suspicious login detection, rapid blocking of compromised accounts.

What to Lock In Before Development Starts

1. Genre and competition level — determines relay vs. authoritative server choice
2. Maximum players per session — 2-4 players and 64 players are fundamentally different problems
3. Target platforms — WebGL requires WebSocket, consoles require network code certification
4. Expected peak CCU — affects infrastructure choice and scaling plan
5. Cheat prevention requirements — do you need server authority, EasyAntiCheat or BattlEye integration