Player

Overview

A 'Player' in Fusion refers to any peer with a NetworkRunner which can provide player inputs to Fusion; i.e. any peer type OTHER than a Dedicated Game Session Server.

In this document, the various way to identify and access player information will be presented.

PlayerRef

Each NetworkRunner which can provide input for a player controlled peer is associated with a unique identifier called PlayerRef. The PlayerRef given to player only serves as an identifier, and does not contain any player specific data.

The PlayerRef is a struct which contains an indexed Fusion Player with a value between 0 and PlayerCount-1. The index is assigned in the order in which players connect to the Game Session.

The Host is essentially Server with the ability to provide input and thus, contrary to a dedicate game session server, is also given a PlayerRef. A Host's PlayerRef will always be PlayerCount-1.

PlayerCount

This value is the maximun number of players which may be connected to a Game Session at any given time.

The default maximum PlayerCount per Game Session is defined globally in the NetworkProjectConfig asset by the Simulation > Default Players field.

When creating a new Game Session, PlayerCount is determined by the nullable StartGameArgs.PlayerCount value which was passed to NetworkRunner.StartGame(). If StartGameArgs.PlayerCount was not assigned a value (or was set to null), the new Game Session will use the Default Player count from the NetworkProjectConfig instead.

Note that a Dedicated Server does NOT have a PlayerRef and does not represent a player, so it does NOT count toward the PlayerCount limit. This means that a Game Session with a PlayerCount of 4 supports:

• 1 Host and 3 Clients
• 1 Dedicated Server and 4 Clients
• 4 Shared Mode clients

Defining a Player Object

The Player Object is an optional convenient way to associate each PlayerRef in a Game Session with a particular NetworkObject 'Avatar'.

Each PlayerRef can be associated with exactly one NetworkObject. This association will be networked and automatically replicated on all clients.

The PlayerRef <-> NetworkObject association is set using the NetworkRunner.SetPlayerObject(PLayerRef, NetworkObject) method.

• In Host & Server Mode: The Player Object can only be set by the Host / Server.
• In Shared Mode: Each Player can only set their own Player Object association, and that Player must also have State Authority over the NetworkObject being associated.

Any peer can retrieve the NetworkObject associated with a particular PlayerRef via the NetworkRunner.TryGetPlayerObject(PlayerRef, out NetworkObject) method.

C#

// On Player Joined, create and define a Player Object.
void OnPlayerJoined(PlayerRef player, NetworkRunner runner){

    if (Object.HasStateAuthority == false) return;

    var plObject = runner.Spawn(PlayerObjectPrefab);
    var plData = plObject.GetComponent<PlayerData>();

    //SetData defines the PlayerRef for that NB and a life amount.
    plData.SetData(player, 3);

    runner.SetPlayerObject(player, plObject)
}


// When desired, get the Player Object.

int GetPlayerLife(PlayerRef player){
    if (Runner.TryGetPlayerObject(player, out var plObject)){
        return plObject.GetComponent<PlayerData>().Lifes;
    }

    Debug.LogError("Player Object Not found")
    return 0;
}

Each Player can only have one Player Object.

State Authority

• ServerMode: the server only, no player has state authority over the game state.
• HostMode: the host player has state authority, as it represents the server.
• SharedMode: the authority is decentralized and shared among players. Any player can have state authority over any objects which does not already have a state authority assigned to it. The state authority can be assigned when the object is spawned and change hands by calling NetworkObject.ReleaseStateAuthority() and NetworkObject.RequestStateAuthority().

Input Authority

• ServerMode & HostMode: a Player can have input authority over multiple NetworkObjects. When a player has input authority over a NetworkObject, it can send inputs and the server will catch them when looking for inputs on that specific object. That is the main way of communication from clients to the server.
• SharedMode: inputs are only available to the local client and not sent to a central authority. Since clients can have state authority over objects, they can apply inputs directly.

Multiple Local Player on One Machine

If the game allows for more than one local physical player on a single NetworkRunner (for example, couch co-op combined with online players), then game specific logic will be needed to differentiate the local players, independent of Fusion’s 'Player' concept. All input from multiple local players must be consolidated into Fusion's input system, using one network input struct to hold data about all the local players inputs.

NOTE: Having local multiple players creates the need for additional custom logic when using functions that depend on PlayerRef, such as SetPlayerObject or OnPlayerJoined.

Back to top