The multiplayer start scene should contain a lot of the core logic, as it is preferred in any AAA game to be able to sync data between scenes, and even have a specific scene load if a player is disconnected.

MP Connection #

The heart of the connection to the cloud. This script manages the initial connection, joining lobbies, joining rooms, room leaving and disconnects. Also includes some logic to prevent any player having the exact same name in a room.

MP Chat Connection #

Voice Chat and or Text Chat (optional). Main connection and router for global chat and game chat, with some under the hood logic you can use for your own backend to setup friend invites and notifications, along with joining a match together. The code is there, for simple pun authentication as an example and it will still require you to setup some other than default auth values. If you know your stuff in this area, I have provided a nice headstart for you, so check this out.

Game Modes #

The game modes should be constructed in a manner that all modes are first level children of a root object that has a DontDestroyOnLoad component attached.
Take the following for example, direct from demo scene.

GameModes (Dont Destroy On Load)
> Coop
> Deathmatch
> TeamDeathmatch
> MultiTeamDeathmatch
> Conquest
> Rush
> CTF

Each of these children objects need to contain the relative components, setup is very modular to contruct a gamemode.

Each and every mode requires MPPlayerSpawner and a PhotonView.
A type of MPMaster is required also. This can be MPMaster, MPDMMaster, or your own extension of MPMaster. With MPDMMaster being an extension of MPMaster you can study this to see how easy it is to create your own custom extension of MPMaster.

The same goes for MPDamageCallbacks. MPDMDamageCallbacks is an extension of MPDamageCallbacks.
With these components you can create two different game modes already. Lets see how you can combine these to create different modes…

Co-op> MPPlayerSpawner, MPMaster, MPDamageCallbacks. The most basic usage.

Deathmatch > MPPlayerSpawner, MPDMMaster, MPDMDamageCallbacks. Handles scoring etc pure death match without any team logic. By adding MPDMTeamManager component, we can then take deathmatch further, and create two more game modes, utilising team logic and scoring.

TeamDeathmatch > As above, a simple copy of Deathmatch with one extra component for team logic. MPDMTeamManager.

MultiTeamDeathmatch > As above, a simple copy of TeamDeathmatch with two extra teams.

More game modes can be created by first setting up your scene with types of MPDMObjective. Again, this is designed to be easily extended. Examples are provided for Conquest, Rush and CTF. Study them to see how you can create your own custom objectives. If you create your own custom objectives, you will need to add them to the GameType enum in MPMaster so you select them, and then add to all relevant code path’s for GameType usage.

TeamDeathMatchConquest > As you may of guessed, this is a copy of TeamDeathMatch, with the Game Type option set to Conquest. You may have already also guessed that you can duplicate TeamDeathMatchConquest, and add some more teams making it MultiTeamDeathmatchConquest.

TeamDeathMatchRush > You guessed it! Just the same as above but with the Game Type set to Rush.

TeamDeathMatchCTF > You guessed it! Just the same as above but with the Game Type set to CTF.

For in game text chat you can also add MPGameChat to any gamemode. To use game chat, you should also have setup the MPChatConnection and the MPChatInput as per Game Scene Setup.

At the time of writing, scoring has only been done for deathmatch types, so it only makes sense to use the score board for modes that incorporate scoring logic which apply score to MPPlayerStats or MPDMPlayerStats.

Score Board #

An example of how to create a simple “smart” deathmatch scoreboard that can dynamically adapt to team count and colors, player counts and a unique color for local player, along with provided stats. You can use this scoreboard as it is, or use it for an example for you own. Check out MPDMMaster to see how the score board is activated. DebugGUI can be used, to save any UI setup work and is nice and neat. Great for prototyping and even on console or PC. For mobile this should be avoided for performance reasons.

MP Menu #

Wires things together as an example. Shows how to trigger which scene (map) to load, along with the game mode and selected character, with some extra examples of player naming (ensuring no two players have exact same name) and some other simple settings. Study this script in order to develop your own game flow.

Teams #

MP Team Manager works to ensure team colours, spawning and score logic is accounted for.

Name

The name of the team.

Grouping

The grouping index used for the spawnpoints.

Objective Grouping

Unused just yet. Ignore. Will possibly be marked obsolete due to core system changes.

Color

The team color.

Character Prefab

The base prefab that will be spawned for the team in question. You could have prefabs with different colored materilas (as per demo for example), or different clothes eg. RU vs US.

Model Index

The ModelIndex should be left to -1 (no override) if players can select model index. If the ModelIndex is 0 or greater the character model will be forced to that model. Aside from that the Character Prefabs defined is what will be spawned. Therefore, you can have a specific prefab per team, and still have the player select the model they will play with, or you can force the model too.

MP Player Spawner #

MP Player Spawner is the soul of getting a players character into the game, spawned with any components in the Components to Add list, which is where you should add the MPPlayerStats or MPDMPlayerStats component, depending on game mode. This is where modularity comes intosome seriously useful effect. We can add components and prefabs at spawntime, and per remote or local player, you can note in the demo only the remote players character requires a nametag prefab, so we add it at runtime when the player is spawned. MPPlayerSpawner will sort out what needs to be assigned to who on what machine relevant to which list the component or prefab is placed in.

Default Character #

This is the character prefab that should be spawned in the case of no MPDMTeamManger or any case wher a team prefab or other is not specified. Consider it a backup even.

Spawn On Join #

This determines WHEN the character prefab should be spawned. If this is true, the character prefab will be spawned upon the scene loading. This may not be desired if using a spawn panel. Examples are provided for use of this option, true or false.

Mode #

This determines PLACEMENT of where the character should be initially spawned. Generally it is by spawnpoints for any game desgin, but the options are available to spawn at a fixed location with an offset applied per player. If a player is “Inactive” eg a non user disconnect or leave, then the player can rejoin, and be placed at the location where they are “lagged” out.

Spawn Location #

Only applies when not using spawnpoints. A reference location to begin spawning characters.

Spawn Offset #

Only applies when not using spawnpoints. How far the character should be spawned from the previously spawned player ID.

Spawn Point Grouping #

This is a default setting, that will only be reverted to when there is no other spawn group management happening ie. when a MPDMTeamManager exists spawn grouping is determined by the MPTeamManger only when the relative input parameter is -1. Any time this is forced, the force group is used. This is how Objective/MiniMap spawning works, hence the local logic in each of them components to update and refresh required components at runtime.

Inactive Timeout #

The duration a player can be considered “Inactive” when a non user disconnect has occured, keeping the room with a slot open for the disconnected player. This allows the disconnected player to rejoin the same room and game they were playing if they are reconnected in time.

Add Prefabs #

With modurality in mind, the Add Prefabs section helps to define which prefabs to add to a local or remote prefab that is spawned.

LOCAL #

Any prefabs that should be attached to the LOCAL character prefab should be defined here. NOTE: If you wish to utilise minimap, you can add the relevant prefab here, it has specific intialization for characters.

REMOTE #

Any prefabs that should be attached to the REMOTE character prefab should be defined here. NOTE: If you wish to utilise minimap or name tag, you can add the relevant prefab/s here, They have specific intialization for characters.

Add Components #

With modurality in mind, the Add Components section helps to define which components to add to a local or remote prefab that is spawned.

LOCAL #

Any prefabs that should be attached to the LOCAL character prefab should be defined here. NOTE: If you wish to utilise minimap, you can add the relevant prefab here, it has specific intialization for characters.

REMOTE #

Any prefabs that should be attached to the REMOTE character prefab should be defined here. NOTE: If you wish to utilise minimap or name tag, you can add the relevant prefab/s here, They have specific intialization for characters.