Player Management

Player Management

Todo:

: Player Management is WIP for Multiplayer

: Write player management

consists of the LocalPlayer and RemotePlayer lists, the player::PlayerManager and the player::NetData structure, which wraps all player information synced across clients.

The PlayerManager listens to many events of the NetManager for syncing player information. Most importantly each player's NetData is stored as a property of the current room, which invokes events whenever that shared data changes.

The PlayerManager in turn raises an event informing on the addition, deletion or change of a player. This is typically bound by the menu UI to update player display and validity of the current player set for launching a match.

References to the player instances are used in many places, e.g. for getting their specific settings. An instance can be queried using a static Get() function on the Player class, handing the player and client IDs.
The player management interface to all the other classes is in need of a clean-up, as this is a bit complicated overall.

The player management shall wrap all tasks related to tracking which players (local and remote) are connected to the game and provide services to them.

Requirements

1. The player management state shall be persistent over the application runtime.
2. It shall keep track of all connected players, local and remote
3. It shall provide the logic behind adding/removing new players (local or remote) and limitation thereof by a configured maximum amount of players permitted.
4. It shall interact with the UI to allow for customization of local players.
5. It shall be able to save/restore the host player settings upon application start.

Architecture

The architecture describes the SW components and allocation of responsibilities between them. A player is a physical user's representation in the game, where that user may be part of the host's players or a connected client's players.

PlayerManager

• The PlayerManager class follows the Singleton pattern and is thus accessible statically. The script's gameObject shall be persistent across scenes (Req. 1).
• It contains lists of both player types (Req. 2).
• It shall check for whether more local and total players are allowed and provide an "Add Player" button if so. The button shall be disabled once the maximum amount of players has been reached (Req. 3).
• The PlayerManager provides a way of checking whether a client is able to join with all his local players (Req. 3).
• It shall react to networked PlayerAddedEvents:
  • Provide a local UIPlayerSlot for displaying
• It interacts with the PlayerPrefs utility to save/restore the host's player (Req. 5).

Player

The Player class wraps all information on a participating player.

• From Req. 2: A Player instance is marked local or remote.
• A Player has a reference to it's slot and triggers an update of the slot's representation when its data has changed.

Should allocated functionality differ regarding the above roles, a split into two subclassed to a common 'Player' base class should be considered.

UIPlayerSlot

Based on Req. 4:

• The UIPlayerSlot represents a UI component able to adequately represent the player's current settings, such as name, color and InputScheme.
• A click on the slot's UI shall open up a customization dialog for local players.

UIPlayerCustDialog

This class shall be a subclass of a so-called 'UIDialog', which manages a blocking pop-up in-game or in menus. For this Prefabs are used, not references to existing instances. Also after the dialog has ended, the instance is destroyed, not only disabled. The script is therefore a component of the dialog.

A specific dialog subclass handles the special content of the pop-up.