Network Manager

Component

The NetworkManagerCustom component is your first stop for methods that involve finding, starting or joining a match. However, it bundles all logic within a single static method: StartMatch(NetworkMode mode). Network Modes are explained in more detail in their own section. The NetworkManager prefab should be placed into your first scene.

Netcode

On the NetworkManagerCustom script inspector, you can define an important network setting, specifically the maximum count of allowed connections = maximum players in a match. Additionality, the player prefabs you are going to use for your game need to be assigned in the Player Prefabs array and the NetworkPrefabs list. Other networked prefabs also have to be put in there, even though some of them are being handled exclusively by our PoolManager during the game.

Further down in the components list is the UnityTransport component, which is used by NetworkManagerCustom and describes the raw transport protocol used for network messages.

Photon

On the NetworkManagerCustom script inspector, you can define the Offline Scene and Online Scene that match with your scenes added in the Build Settings. Only the Offline Scene Index (main scene after e.g. disconnecting or finishing a match) is required, since the Online Scene is determined by the selected game mode automatically. Additionally, an important network setting is Max Players that defines the maximum count of allowed connections in a match. Lastly, a list of player prefabs that are available in the game. In order to instantiate player prefabs over the network, Photon requires placing them in a folder called 'Resources'. Player prefabs are thus located under Tanks Multiplayer > Prefabs > Resources.

In code, the NetworkManagerCustom script defines the amount of teams per game mode for initialization purposes - in a variable named initialArrayLength. If you would like to change team counts, you have to change its value in the OnCreatedRoom() method for this.

case GameMode.CTF: //2 teams in CTF
    initialArrayLength = 2;
    break;
default: //4 teams in TDM
    initialArrayLength = 4;
    break;

Player Data

Since the player can customize quite a few things in the game settings, including the selected player model and user name, the server needs to be aware of these values in order to correctly spawn the player. We call this Player Data. Let's go over both values in more detail:

Player model: In the shop, the IAPProduct component for each model has a unique value assigned to identify which model has been selected by the player at runtime. This value is matched against the Player Prefabs list on the NetworkManager component, so 0 resembles the first model, 1 = the second and so on.

User name: Regarding input and storage, this is not something special and just a regular InputField which is saved locally. The more interesting part, how it is sent to the server, is explained below.

Netcode

Since we do not store user inventories online, when joining a game the client needs to tell the server its player model and user name.

These values are first read from PlayerPrefs, put in a JoinMessage struct and serialized into a byte array. All of this happens in the GetJoinMessage() method. Then, when the client is connected to the server and loaded into a game scene, it calls the RPC AddPlayerServerRpc() for sending its Player Data to the server.

Photon

Since we do not store user inventories online, when joining a game the client needs to tell the server its player model and user name.

Regarding user name, Photon offers the PhotonNetwork.NickName property that is automatically synchronized with other players. So after a connection was established, the client reads from PlayerPrefs and sets its own name using this property. Next, when the client loads into a game scene, it receives the RPC AddPlayer() from the server, which requests the client to instantiate itself with the desired player model in the correct team. Since the team properties are already synchronized at that point, this does not necessarily need to be server authoritative.