Choose a Topology
Overview
Fusion supports two network topologies: Shared-Authority and Client-Server. They share the same connection, spawning and RPC systems but differ fundamentally in who owns game state and how authority is managed. This page helps you pick the right one before you start building.
The Quadrant organizes game genres and popular titles by network topology to help guide your decision. It shows four Photon options: Dedicated Server, Client-Host, Shared-Authority and Quantum (a separate Photon product for deterministic simulation games). In Fusion Godot documentation, Dedicated Server and Client-Host both fall under the Client-Server topology.
Master client: the first player to create or join the room, designated by Photon. In Client-Server topologies, the master client will act as the host/server (the player or dedicated process running the simulation), will be refered to as the simulation server. In Shared-Authority, the master client is responsible for large-scene load signaling, and typically spawns and controls NPCs (although these can also use authority switch options).
Shared-Authority
The mental model: "I own my objects and I write their state directly."
Every client owns and writes state for the objects it creates. The Photon server acts as a stateful relay: it caches the world, distributes deltas and serves a full snapshot to late joiners. There is no single simulation bottleneck: if one client lags, only its objects are affected.
The programming model is straightforward because the authority writes values directly with no prediction or rollback involved. Authority can be transferred between clients using one of several ownership modes (Transaction, Player Attached, Dynamic, Master Client).
This topology works well for co-op, casual, party, social and physics sandbox games.
Client-Server
The mental model: "I suggest input, the authority decides what happens, and I predict locally."
A simulation server (the player-host or a dedicated server) runs game logic and validates all state changes. Clients poll input and send it to the simulation server, which executes and writes the results. Clients predict movement locally for responsive feel, and corrections are applied when the authoritative state arrives.
Because the server validates everything, this topology provides stronger anti-cheat guarantees. It fits competitive or extraction shooters, battle royale and other games where fairness matters.
The Photon Cloud still handles state distribution, AOI filtering and late join snapshots, so the simulation server focuses on gameplay without carrying the networking load. The host sends state to a single endpoint (the cloud room), not to each client individually, saving bandwidth and CPU.
Additional benefit: IP addresses of neither player host nor dedicated server are ever exposed to other clients, providing both DDoS and harassment protection.
Choosing Factors
| Shared-Authority | Client-Server | |
|---|---|---|
| Suggested game types | Casual, co-op, party, sandbox, social. Large player counts, frequent join/leave | Competitive, shooter, battle royale, esports. Client-Host for small sessions; Dedicated Server for ranked |
| Cheat protection | Lower at start: clients write their own state. Server plugins can add validation as the game grows | Strong: server validates everything. Only aimbots and wall-hacks remain. Client-Host: host can still cheat |
| Server complexity | None: Photon Cloud handles everything | Client-Host: a player runs the simulation. Dedicated Server: requires third-party hosting |
| Cost efficiency | Most cost-effective: CCU + bandwidth to Photon Cloud | Client-Host: comparable to Shared (host sends to cloud, not N clients). Dedicated Server: adds hosting costs |
| Mobile | Strongly recommended. Cloud connection, no resimulation, lower CPU | Dedicated Server: hosting cost does not fit F2P. Client-Host: apps easily backgrounded or killed, unreliable as host |
| Web | Strongly recommended. Cloud connection, no resimulation, lower CPU | Dedicated Server: hosting cost does not fit F2P. Client-Host: browser tabs slow down when backgrounded, degrading the server for all players |
You can read more about the specifics of Fusion's pricing here.
Technical Comparison
| Shared-Authority | Client-Server | |
|---|---|---|
| Authority | Distributed - each client owns its objects | Centralized - host or dedicated server |
| Who writes state | The owning client, directly | The simulation server, after executing client input |
| Complexity | Simpler - no prediction code | More involved - input packing, prediction, rollback |
| Input prediction | Not needed - clients write state directly | Built-in via input queue and prediction reset |
| Physics prediction | Forecast: flexible correction based extrapolation and smoothing | Forecast |
Which One Should I Use
Start with Shared-Authority if you are unsure. It is simpler, faster to prototype and covers the majority of multiplayer game types. Choose Client-Server when your game requires server-authoritative validation, anti-cheat enforcement or a competitive ranked environment where every player must trust the same simulation.
Changing Later
Switching topologies after the fact is possible but not easy. Replication and RPC patterns are fundamentally different between the two topologies, so a switch involves reworking most of your networking code. It is better to choose wisely at the start.
Start Building
