Concepts

Shared Authority vs Server Authority

Built-in Unreal Netcode runs a server-authority model. One process — a dedicated server or a listen host — holds ROLE_Authority for every replicated actor in the world, simulates them, and writes their state. Every other peer is a proxy that observes the authoritative state and forwards player input through Server-marked RPCs.

Fusion runs a shared-authority model. There is no authoritative server process and no single ROLE_Authority for the world. Each replicated actor has its own owner — a regular game client — that is the local authority for that actor and drives its state. The room on the Photon Cloud holds the shared state and relays updates to the relevant clients, but it does not simulate gameplay.

This is the framing shift that drives every other difference covered in this manual. Cheat prevention, lag compensation, where game logic lives, and how RPCs are targeted are all approached differently under shared authority. The high-level tradeoffs between Fusion, dedicated, and listen-host topologies are covered in Fusion Unreal Intro.

Owners, Authority, and Roles

Every Fusion-replicated actor has an owner: an int32 player id that identifies the client that is the local authority for that object. The owner reads and writes the actor's replicated state. Remote clients observe the state but cannot write it. "Having authority" in Fusion always means owning that specific object — there is no world-wide authority and no "the server" to defer to.

UFusionOnlineSubsystem exposes two related getters that answer the "who is in charge?" question. GetOwner(Actor) returns the requested owner — the player id the actor's UFusionActorComponent was configured for, before any runtime resolution. GetResolvedOwner(Actor) returns the effective owner — the player id the simulation actually uses, after applying ownership-mode rules such as master-client tracking, dynamic claims, and disconnects.

For gameplay code, the practical predicates are IsOwner(Actor) and CanModify(Actor). Both consult the resolved owner and are the correct gate for any write to replicated state.

C++

if (OnlineSubsystem->IsOwner(this))
{
    Health -= IncomingDamage;
}

Use these instead of AActor::HasAuthority(). The plugin does not override HasAuthority, so its return value reflects only the stock Unreal ENetMode and ROLE_Authority state — it does not consult Fusion's per-object owner. The behavior of HasAuthority on Fusion-replicated actors is covered in Compatibility with Built-in Netcode.

Ownership modes themselves — Transaction, PlayerAttached, Dynamic, MasterClient, GameGlobal — and the runtime API for transferring ownership are covered in Ownership.

The Master Client

One peer in every room is elected as the Master Client. It is the tie-breaker for room-wide decisions: advancing match state, deciding map changes, owning singletons that no specific player should hold. Query it from any peer with UFusionOnlineSubsystem::IsMasterClient() and gate Master-only gameplay on the result.

The Master Client is not a server. It has no extra simulation power, no special trust, and no separate process. It is a regular game client elected to a coordinator role. When the current Master Client leaves the room, Photon promotes another client automatically. Objects configured with EFusionObjectOwnerFlags::MasterClient ownership re-target to the new master without application code — the ownership migration is transparent to gameplay.

Use the Master Client for room-scoped decisions where exactly one peer must act: spawning shared NPCs, advancing the match state, picking the next map. Do not use it as a stand-in for a trusted server. Every client still simulates its own owned objects and writes its own replicated state, regardless of who the master is. The full MasterClient ownership-mode story is in Ownership.

Rooms and Sessions

A room is the unit of multiplayer session in Fusion. Every play session lives in exactly one room. Clients create or join rooms through UFusionOnlineSubsystem, passing an FFusionRoomOptions struct with RoomName, MaxPlayers, bIsOpen, bIsVisible, PlayerTTL, EmptyTTL, and an optional InitialWorld to load on join. The full connect-and-join flow, including async actions and region selection, is covered in Connection.

The session itself moves through a small lifecycle exposed by the EFusionStatus enum. The convenience queries IsConnected(), IsInRoom(), IsJoiningOrInRoom(), and Status() are the gates gameplay code typically uses to decide when replicated systems are safe to read or write.

Once in a room, each client has a stable int32 player id obtained from GetLocalPlayerId(). The id lives for the session and is what the ownership APIs (GetOwner, GetResolvedOwner, IsOwner, CanModify) compare against internally. The same id is exposed in the OnOwnerChanged and OnOwnerWasGiven events on UFusionActorComponent whenever ownership transitions.

Mapping to Built-in Unreal Concepts

For developers coming from built-in Unreal netcode, a small set of concepts does not carry over. AGameModeBase is not a server-only authority under Fusion — every client constructs its own AGameMode locally, and Master-only flow is gated explicitly with IsMasterClient (covered in Game Classes). The ENetRole family — GetLocalRole, GetRemoteRole, GetNetOwningPlayer — does not drive Fusion replication. Authority is per-object and queried through UFusionOnlineSubsystem, not through actor roles.

The single most important shift is the last row of the table: an actor becomes networked by adding a UFusionActorComponent, not by being spawned authority-side or marked bReplicates. The component is the bridge between the actor and UFusionClient. How this plays with APawn, APlayerController, and AGameStateBase is covered in Spawning and Game Classes.