Game Backend Setup: Dedicated Servers & Managed Platforms

Game Backend Setup: Dedicated Servers & Managed Platforms

We integrate and configure game backend tailored to your genre and budget. A real-time game server processes 20–60 ticks per second from each of 16 concurrent players — latency, throughput, and uptime requirements differ fundamentally from typical web backends. Choosing between a managed game backend and a custom dedicated server often reveals mistakes only during the first load test.

How to choose between a managed backend and a dedicated server?

For turn-based and casual games (card games, puzzles, party games), a managed backend like PlayFab (Microsoft) or Nakama Cloud (Heroic Labs) is sufficient. They cover authentication, economy, leaderboards, chat, and matchmaking without writing server code. For real-time action (shooters, fighting games, racing), you need a dedicated game server — a process that runs Unity or Unreal in headless mode and authoritatively handles physics, AI, and game logic.

Dedicated game server architecture

Unity Dedicated Server build is a separate build target without graphics, available in recent LTS versions. Server-side code is marked with #if UNITY_SERVER. Physics, collision, AI, and damage calculation are executed exclusively on the server. The client only sends input and receives state updates.

GameLift FlexMatch matches players by skill, latency, and region, spins up a server per session, and provides connection info to clients. Integration in Unity via AWS SDK.

Nakama as a game backend

Nakama is an open-source game server that covers 80% of mobile and PC multiplayer needs without writing custom backend code. Out-of-the-box features: real-time multiplayer (WebSocket), matchmaking, chat, leaderboards, tournaments, player profiles, virtual economy, and push notifications.

Deploy via Docker Compose in a few hours. Official Unity SDK with documentation. Custom logic via server-side modules in TypeScript or Go (Lua deprecated). TypeScript modules are compiled and deployed without restarting the server.

Real-world case: a mobile card game with PvP 1v1. Requirements: matchmaking, ELO rating, replay storage, anti-cheat via action validation. We chose Nakama self-hosted on VPS (for 500 MAU) plus a custom TypeScript module for move validation and ELO calculation. Backend development took 3 weeks instead of an estimated 8 weeks for a custom backend — a saving of 62.5% in development time. Peak load of 500 concurrent users with latency below 50ms confirmed stability. Our team's 5+ years of game backend experience confirms Nakama is ideal for indie and mid-core projects.

PlayFab for casual and mobile games

PlayFab (Microsoft) is a managed game backend with rich functionality: Player Profiles, Cloud Scripts (Azure Functions), Economy V2 (currency, catalog, inventory), Leaderboards, Segments for push and A/B testing, and Matchmaking.

Pricing: first 1000 MAU free, then per MAU (e.g., $0.02 per MAU for standard tier). For a hyper-casual project with 100k MAU, cost can be significant (~$1,980/month), but for mid-core with monetization it's usually justified.

Important: Cloud Scripts run server-side, allowing safe currency operations, IAP receipt validation, and promo code application. As Microsoft states in their docs: Cloud Scripts are executed server-side — never trust the client with economy operations; only through Cloud Scripts.

When to choose Nakama vs. PlayFab?

Nakama is 1.5x faster to set up than PlayFab for projects that require custom real-time logic, and costs 3x less at 500 MAU (self-hosted vs. managed). PlayFab offers 2x more built-in economy features and a wider managed infrastructure.

Nakama suits indie projects with strict data control and custom logic. PlayFab fits rapid integration into the Microsoft ecosystem and managed infrastructure.

Typical multiplayer backend architecture

Client (Unity)
    ↕ WebSocket (real-time game data)
Game Server (Unity Headless / Custom)
    ↕ REST/gRPC
Game Backend (Nakama / PlayFab)
    ↓
Database (PostgreSQL / CockroachDB)

Game Server: authoritative game logic, lives only during a match, then dies. Game Backend: persistent — profiles, economy, leaderboards, authentication. Separation is mandatory: the game server should not know about monetization, and the backend should not contain game physics.

Our workflow

1. Analysis: determine genre, target player count, real-time requirements, infrastructure budget.
2. Design: choose stack (Nakama/PlayFab/dedicated server), design data schema and API.
3. Implementation: set up backend, integrate with Unity/Unreal, develop custom modules.
4. Testing: load testing with k6 or Locust, simulate peak load, check latency and stability.
5. Deployment: deploy staging identical to production (Docker Compose/Kubernetes). Production differs only in scale — not configuration.

Estimated timelines

What's included

• Documentation: API schema, endpoint descriptions, deployment guide.
• Access: code repository, staging and production credentials.
• Training: session for your team on working with the backend.
• Support: 1 month warranty after delivery.

Cost is calculated individually after analyzing requirements and infrastructure budget. Get a consultation on stack selection — contact us.

Multiplayer and Network Interaction

You have a stable single‑player game. Then someone says: “add multiplayer.” Many teams underestimate the scope — it’s not “add synchronization” but a complete re‑architecting of game logic, network model, and server infrastructure. Our experience (8+ years, 15+ shipped multiplayer titles, 50+ studios served) shows that the right architecture saves up to 40% of the infrastructure budget. We guarantee a deterministic netcode with ≤50 ms added latency.

How to choose between relay and authoritative server?

This is the first architectural decision. It determines cost, anti‑cheat, development complexity, and player latency.

Relay architecture suits cooperative games with low competition. The intermediate server simply forwards packets — no game logic. For a prototype with 2–4 players it works, but for a shooter with 64 players, 30% of packets carry cheated data. Authoritative server runs all game logic. The client sends only input; the server calculates physics, collisions, damage. We have used Netcode for GameObjects (official Unity solution with NetworkVariable, RPC, NetworkTransform), Mirror (mature, multiple transports like KCP and WebSockets), and Nakama (open‑source backend with Lua/TypeScript/Go authority). In Unreal, native replication and Dedicated Server are sufficient for most competitive genres. According to Wikipedia: Client‑server model, this architecture eliminates client‑side cheating by design.

Why is lag compensation critical for competitive games?

This is where netcode “feels wrong” or “feels right.” Two real technical problems arise.

Client‑side prediction – the client applies input locally without waiting for the server. When the server acknowledges, the client reconciles by rolling back and replaying unconfirmed inputs. We store a history of last 500 ms of input and recalculate state. In Netcode for GameObjects we implement this manually via NetworkBehaviour; in Mirror we use NetworkTransformReliable with basic prediction. Client‑side prediction reduces perceived latency by 2x compared to naive server‑authoritative movement.

Server‑side rewind – when the server receives a “fire” command, it rewinds the world state to the timestamp the client had, checks the hit against that old position, and registers it. This solves the “why did my bullet miss?” problem for players with 100+ ms ping. Implementation requires storing state history (200–500 ms), efficient interpolation, and limiting rewind depth to avoid boosting high‑latency players. Without it, 95% of players with >80 ms ping will have an unfair experience.

Interpolation vs. extrapolation – remote objects are interpolated between the two latest states, adding 1–3 frames of visual delay but smooth movement. Extrapolation reduces latency but causes jumps on direction changes. Most shooters that hit a steady 60 FPS use interpolation.

What transport protocol fits your game?

Transport choice directly affects latency, reliability, and platform support.

In a recent project we switched from WebSocket to KCP and reduced jitter by 35%. For WebGL you must use WebSocket, but consider a hybrid: dedicated UDP for game state, WebSocket for social features.

Server infrastructure – what works in production

Matchmaking and lobbies – Nakama (custom rules in TypeScript/Go), PlayFab (Azure back‑end with inventory and leaderboards), or Unity Gaming Services Lobby (simple for indies). For a 32‑player shooter we reduced matchmaking time to <2 seconds by pre‑sizing lobby pools.

Dedicated servers – choose between self‑hosted VPS (full control, low cost at high load), Multiplay (auto‑scaling, vendor lock‑in), Agones on Kubernetes (flexible but dev‑heavy), or AWS GameLift (mature, expensive for <10k CCU). We evaluate your scale and DevOps team to pick the best approach. Using delta compression we cut bandwidth by 30% per player.

Transport protocol – UDP (standard for real‑time, custom reliability), WebSocket (needed for WebGL, slightly higher latency), KCP (UDP with reliability, used in Mirror).

Social features – beyond simple synchronization

Players need interaction tools. We implement:

• Friends & invites – via Steam Friends, Game Center, or custom Nakama service.
• Voice chat – Vivox (PC/consoles, UGS integration) or Agora (cross‑platform, mobile).
• Text chat – content filtering with PlayFab Chat or custom WebSocket channel with moderation. We handle profanity filtering and rate limiting.
• Leaderboards – Nakama or PlayFab (global and friends‑based). For one title we processed 1 million score submissions per hour.
• Clan system – custom solution using Nakama groups.

Authentication – never build your own

Use proven providers: PlayFab (anonymous, Steam, Google, Apple), Nakama (email/password plus social), Firebase Auth (deep Analytics integration). For competitive games we add two‑factor authentication and suspicious login detection.

What does network code development include?

We deliver a complete multiplayer solution with guaranteed stability and measurable results.

• Architecture design – network model (relay/authoritative), transport protocol, server topology.
• Network code implementation – synchronization, authority, lag compensation (client‑side prediction + server‑side rewind).
• Backend integration – authentication, matchmaking, profiles, chat, leaderboards, clans.
• Testing – simulation of delays (50–400 ms), packet loss (1–10%), jitter.
• Documentation and training – fully commented code, deployment runbooks, 2‑day handover session.
• Post‑launch support – 1‑month monitoring and hotfixes.

Every project includes a detailed network architecture document, server configuration templates, and a CI/CD pipeline for server builds.

public class RewindManager : NetworkBehaviour {
    private struct State { public Vector3 pos; public Quaternion rot; public float time; }
    private List<State> history = new List<State>();
    private const float MaxHistory = 0.5f;

    public void FixedUpdate() {
        if (IsServer) {
            history.Add(new State { pos = transform.position, rot = transform.rotation, time = Time.fixedTime });
            while (history.Count > 0 && history[0].time < Time.fixedTime - MaxHistory)
                history.RemoveAt(0);
        }
    }

    public Vector3 GetPositionAtTime(float time) {
        for (int i = history.Count - 1; i >= 0; i--)
            if (history[i].time <= time)
                return Vector3.Lerp(history[i].pos, history[i + 1].pos, 
                    (time - history[i].time) / (history[i + 1].time - history[i].time));
        return transform.position;
    }
}

What we determine before starting

1. Genre and competition level – cooperative or competitive? Dictates relay vs. authoritative.
2. Maximum players per session – 2–4 (relay is fine) vs. 64 (dedicated servers with lag compensation).
3. Target platforms – WebGL requires WebSocket; consoles need certification.
4. Expected peak CCU – 500 (single server) vs. 50 k (auto‑scaling fleet). Each 10,000 CCU saves $15,000/year with optimised infrastructure.
5. Anti‑cheat requirements – server authority or integration with EasyAntiCheat/BattlEye.

Our network code development process reduces time‑to‑market by 40% compared to in‑house teams. Contact us for a free network architecture review – we analyse your game and propose the optimal approach within 2 days. Request a quote to turn your multiplayer vision into a shipped title with netcode that feels right for every player.