Modes and Topologies

Overview

Fusion Core is a single SDK that runs in two modes and three topologies.
An integration links the same libraries, drives the same frame loop and uses the same object, RPC and interest-area APIs in every case.
A complete integration supports both modes, so its users can ship either kind of game; the mode is selected per session, not baked into the binding.

This page explains how the modes and topologies work and how they differ at the API level.
The game-design trade-offs between them are a decision for the game developer, not the integration.

• A mode is the programming model: who owns and writes state, where state authority lives, and whether input prediction runs.
  The two modes are Shared-Authority and Client-Server, exposed in code as SimulationMode::Shared and SimulationMode::Authority.
• A topology is the network arrangement: where the authoritative simulation runs.
  The three topologies are Shared-Authority, Dedicated Server and Client-Host.
  A fourth arrangement, Determinism, is a separate product (Photon Quantum) and does not use Fusion Core.

In every topology the Photon Cloud Room caches world state and distributes it to clients, and serves snapshots to late joiners.
Authorities write only to the cloud, never directly to other clients, so player IPs are never exposed.

How the Mode Is Selected

The mode is fixed for a session by the "SimulationMode" field of the fusion_config room property ("Shared" or "Authority", defaulting to "Shared").
Client::Start() reads it when the integration joins a room.

An integration queries the active mode at runtime with Client::GetSimulationMode(), or client_get_simulation_mode() through the C ABI, and branches the handful of behaviors that differ between modes.

State Authority and Input Authority

Two authority concepts apply in both modes:

• State authority is the right to write an object's canonical state into the cloud.
• Input authority is the right to feed input that drives an object.

In Shared-Authority mode the two coincide: the owning client both writes state and feeds input.
In Client-Server mode they separate: state authority always belongs to the simulation server, while input authority belongs to a designated predicting player.
Client::HasInputAuthority(obj) abstracts the difference — it returns whether the local client is the owner (Shared) or the predicting player (Client-Server), so input-gathering code can stay mode-agnostic.

Shared-Authority Mode

SimulationMode::Shared.
Every client owns and writes state for the objects it spawns.
The owning client mutates the object's words directly each frame, and the cloud distributes the deltas; there is no central simulation step.

Ownership can move between clients under one of several policies, set per object through ObjectOwnerModes at creation:

• Transaction — ownership is claimed and released explicitly; one owner at a time.
• PlayerAttached — ownership is bound to a player and released when that player leaves.
• Dynamic — ownership transfers on request, gated by a cooldown.
• MasterClient — the master client owns the object.

A client requests ownership with Client::SetWantOwner() and releases it with SetDontWantOwner().
The current owner answers incoming requests through the OnOwnershipRequest callback by calling RespondToOwnershipRequest(), and the requester learns the outcome through OnOwnershipResponse.
Client::IsOwner(), GetOwner() and CanModify() report the local view of authority.
No prediction or reconciliation code runs in this mode.

Client-Server Mode

SimulationMode::Authority.
A single simulation server holds state authority for every object and is the only writer to the cloud.
Clients do not write state directly; they send input and predict locally for responsiveness.

The flow for an object using ObjectOwnerModes::PlayerPredicted:

1. The server assigns a predicting player with Client::SetPredictingPlayer().
2. That player gathers input each frame and submits it with ObjectRoot::QueueInput().
3. The server applies queued input with ObjectRoot::ExecuteInputs() and writes the resulting state; queued input also surfaces on the server through the OnInput callback.
4. Clients predict ahead of confirmation and reconcile when authoritative state arrives, through the OnPredictionOverride and OnPredictionReset callbacks.

Client::IsPredictingPlayer() and GetPredictingPlayer() report input authority, and GetInputSequence() tracks the input stream.
Master-owned objects (ObjectOwnerModes::MasterClient, GameGlobal) carry no prediction; only PlayerPredicted objects run the input path.

Topologies

A topology is where the authoritative simulation runs.
The mode determines the programming model; the topology determines deployment.

Shared-Authority

Uses SimulationMode::Shared.
There is no central authority — every client is the state authority for its own objects, and the cloud caches and distributes them.

Dedicated Server

Uses SimulationMode::Authority.
The authoritative simulation runs in a headless process on dedicated infrastructure.
The server is not a player; it joins the room as the authority and writes state for all objects.

Client-Host

Uses SimulationMode::Authority.
The authoritative simulation runs on the master client — one player's machine takes the host role in addition to playing.

The two Client-Server topologies share identical integration code.
The only difference is where the authority runs and which participant holds it (a headless process versus the master client), which is a deployment concern rather than an API one.

What Differs for the Integration

Most of the SDK surface is identical across modes — connection, spawning and destruction, scene/map management, RPCs, the interest area and the frame loop all behave the same way.
The mode-specific surface is small and concentrated in authority and input handling:

A binding that wires up both the ownership path and the input/prediction path, and branches on Client::GetSimulationMode() where the two diverge, supports all three topologies.