Multiplayer and Network Code Development Services

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.