Choosing Server-Authoritative Movement in Photon Fusion: Decision Guide

The decision: who owns the truth about player position

In a Photon Fusion project the first architectural choice is authority over movement. Server‑authoritative means the server runs the simulation, validates every input, and broadcasts the corrected state; clients only render what they receive. Client‑authoritative lets each client simulate locally and sends its state to the server, which merely relays it. Picking the wrong model leads to either cheating opportunities or noticeable input lag.

Supported options comparison

Factor	Server‑authoritative	Client‑authoritative
Cheating resistance	High – server never trusts client position	Low – clients can teleport or speed‑hack
Hosting requirement	Dedicated server (Photon Cloud paid tier or self‑hosted)	Works on Photon Cloud free tier
Bandwidth	Server broadcasts corrected states; higher tick rate → more bandwidth	Clients broadcast their own states; lower per‑player cost
Player experience	Input delay visible without local prediction	Locally responsive but other players may see jitter
Complexity	Requires NetworkTransform, interpolation, reconciliation	Simple – attach NetworkTransform and go
Tick‑rate sensitivity	High – 30 ms tick is practical minimum for smooth movement	Low – can run at 60 ms and still feel responsive

Trade‑offs explained

Server‑authoritative eliminates position hacking because the server is the sole authority. The cost is a dedicated server, which means leaving the free 20 CCU plan and using a paid Photon plan or self‑hosted servers. Bandwidth grows with tick rate; a 30 ms tick (≈33 updates/sec) is often the lowest that feels smooth for fast movement. Client‑authoritative is cheaper and simpler but opens the door to cheats; it is suitable for cooperative or non‑competitive titles where exact position authority is not critical.

Minimal server‑authoritative implementation

Fusion’s NetworkRunner is started in Server‑Authoritative mode. The player prefab needs a NetworkTransform component (handles interpolation and prediction) and a script that updates the authoritative state on the server.

using Fusion;
using UnityEngine;

public class PlayerController : NetworkBehaviour
{
    // These fields are replicated from server to clients
    [Networked] public Vector3 Position { get; set; }
    [Networked] public Vector3 Velocity { get; set; }

    public override void FixedUpdateNetwork()
    {
        if (IsServer)
        {
            // Server runs the simulation: read input, apply velocity
            float input = GetInputAxis(); // placeholder for actual input retrieval
            Velocity = transform.forward * input * 5f;
            Position += Velocity * Runner.DeltaTime;
        }
    }
}

The [Networked] attribute tells Fusion to synchronize the fields. The server updates Position and Velocity in FixedUpdateNetwork; clients receive the updated values and the attached NetworkTransform interpolates between updates, giving smooth movement even at a 30 ms tick.

Validation: how to check it's working

1. Launch a dedicated server (e.g., using Photon’s Fusion Server binary or a hosted Photon Cloud room with Server‑Authoritative mode enabled).
2. Start two clients and connect them to the same room.
3. On one client, move the player forward. Observe the server console (or Fusion logs) showing the position updates.
4. Attempt to cheat by modifying the client script to set Position directly to a far value. The server will reject the change; the client will see the player snap back to the server‑authoritative position after the next tick.
5. Verify smoothness: enable Fusion’s NetworkDebugStartAuto or view the interpolation buffer; movement should appear fluid despite the server’s tick rate.

Limitations and practical checks

• Dedicated server required – the free 20 CCU plan is only for testing; production needs a paid Photon plan or self‑hosted Fusion server.
• Tick‑rate trade‑off – lower tick rates save bandwidth but increase perceived input lag; measure round‑trip time with Fusion’s Runner.GetPing and adjust the tick rate in NetworkRunnerConfig (e.g., Simulation.TickRate = 30 for 30 ms).
• Network jitter compensation – Fusion’s built‑in interpolation hides small jitter, but large spikes still cause visible correction; monitor Runner.GetFrameDelay to spot issues.
• Version note – the code targets Fusion 2.x (the current stable release as of 2024); API may differ in earlier versions.