Network Code Development for Player Synchronization
100 ms latency is not a delay player doesn't notice. In first-person shooter over 100 ms opponent moves 30–50 centimeters. Without client-side prediction aiming at moving target becomes physically uncomfortable. This is why for competitive multiplayer there's no option to "just sync positions via RPC"—need full architecture with prediction on client and authoritative server.
This is technically hardest part of game dev. Errors in network architecture aren't fixed with point patches—they require system rework.
Why Naive Synchronization Doesn't Work
Simple approach: server sends positions to all clients. Client receives position update, moves object. At 100 ms RTT object will always lag behind real server position. Movement—visible lag. Jump—"jittering".
NetworkTransform with interpolation (built in Netcode for GameObjects)—next level. Client doesn't teleport object, interpolates between two known positions. Removes visual jittering, but doesn't solve authenticity problem: client controls own character, server trusts client. Opens cheating possibilities and doesn't solve lag compensation.
Client-side prediction + server reconciliation—correct solution for action games. Client applies input immediately locally. Simultaneously sends input to server. Server processes input, returns authoritative state. Client compares own predicted state with server and, if divergent, corrects (rollback + replay). With proper implementation player notices no delay—their character responds instantly.
In Unity NGO (Netcode for GameObjects) implemented via NetworkRigidbody with NetworkTransform in Interpolate mode or via custom ClientNetworkTransform. In Photon Fusion—built-in NetworkMecanimAnimator and KCC (Kinematic Character Controller) with prediction out-of-the-box.
Lag Compensation for Hit Registration
Separate hardcore problem: player shoots and sees hit, but at shot moment on server target already different position. Lag compensation—technique where server "rewinds" game scene state back in time (by amount of client latency) for hit check.
Implemented via History Buffer on server: each tick save snapshot of all player positions. On receiving shoot-request from client—restore snapshot from past, do raycast, return to current state.
In Mirror implemented manually via NetworkTime.time and circular buffer of snapshots. In Photon Fusion—partially via fusion's built-in lag compensation API (LagCompensatedHit).
From practice: mobile tactical shooter, 4 players per match. First implementation—simple NetworkTransform + RPC for shooting. On devices with 80–120 ms latency misses were visually obvious—player aims at opponent, no hits. After implementing client-side prediction for movement + lag compensation 150ms on server—hit "fairness" became acceptable for casual audience.
Game State Synchronization, Not Just Positions
State Synchronization goes far beyond character movement. HP, inventory, game object state (doors, traps, projectiles)—all requires synchronization. Two main approaches:
State sync—server periodically sends complete state (or delta) to all clients. Reliable, but expensive bandwidth with many objects.
Event-driven—clients send events (player opened door), other clients apply event locally. Cheaper bandwidth, but requires event idempotence and packet loss handling.
For most projects—hybrid: rare events via reliable RPC, frequent updates (positions, animations) via unreliable channel with interpolation.
NetworkVariable in NGO—convenient abstraction for value synchronization: NetworkVariable<int> Health. Auto-syncs on change, supports OnValueChanged callback. For HP, score, game state—ideal. For rapidly changing data (position each frame)—overkill.
How We Build Network Code
We start with network diagram—schema of all game systems showing what's authoritative on server, what on client, what data syncs and how often. This is architecture foundation.
Network stack selection per project: NGO for Unity with UGS Relay, Mirror + own dedicated server, Photon Fusion for competitive action, Nakama for casual with game backend.
Development in NetworkSimulator—test with artificial delays 50/100/200 ms and packet loss 1–5%. Sync problems only manifest under real network conditions.
| Task Scale | Estimated Timeline |
|---|---|
| Basic position synchronization (2–8 players) | 2–4 weeks |
| Client-side prediction + lag compensation | 4–8 weeks |
| Full network architecture with game state sync | 6–12 weeks |
| Existing network code optimization | 2–4 weeks |
Cost calculated after analyzing game genre, player count and sync precision requirements.