Multiplayer Networking

General Overview
The majority of networking is done - it's just a case of refining the code, optimisation, and any changes required. Here's a brief overview of how the system works.

1) Currently, you can either create your own game (lobby) or join a lobby in progress. This is because, in the future, we want to add the ability to customise the gameplay (max players, game mechanics, etc). 

2) All players must be "Ready" (achieved by clicking a button). When all players are ready, the countdown timer will start. This allows the map to be asynchronously loaded in the background, and gives players a few seconds to get ready.

3) Player prefabs are spawned on the network at random NetworkStartPositions. Animations and movements are synchronised on the server and subsequently sent to all connected clients.

4) Currently, if the "Host" quits then everyone will be kicked to the main menu (we plan on adding host migration in the future).

5) The majority of actions inherit from the NetworkBehaviour class, with appropriate variables being changed on the server, and sent to connected clients (and subsequently, clients sending back information to the server).

Advanced Networking
There is still a lot to do in terms of creating a stable network that is scalable. Some of the more difficult stuff includes:

1) Network Visibility - Essentially, this is used to determine when information about a particular game object is sent to the client based on their distance. However, to achieve this for hundreds of objects can be difficult. This is because, in order to get this working, scenery can not be static saved in the scene. Everything has to be a prefab that is spawned in at runtime  at it's unique position and rotation on the map. This can dramatically reduce server bandwidth and increase performance - so will be something we are always tweaking in order to get the best performance.

2) Packet Loss & DeSync - Dealing with players that have a negative impact on a game can be difficult. For example, if you wanted to check for an event 60 times in a second. There are two possibilities;

- Players with 60fps will receive 60 checks in a second.
- Players with less than 60fps will receive less checks. 40 fps = 40 checks in a second.

Another issue is when a player with a poor connection becomes de-synchronised. Should packet loss contain movement commands (walking to running) then the subsequent command will never be sent from the server to sync on the connected clients (as it never received the command to resync). This can result in rubber-banding where the server attempts to sync the next cycle of commands, and, not having the previous movement command, sets the player back to "where they should be" according to the most recent server sync vars, events, animations and positions.

This can be an issue.

Player 1 is sending 80%, Player 2 is sending 100%, Player 3 is sending 100%

When Player 1 moves (or does anything) the server needs to sync these actions on all connected clients. When data is missing, it can not be passed on to the other clients.

3) Host Migration
The default behaviour of the network is to kick all players when a host leaves. This is obviously not ideal and we are working on a host migration system. This can be somewhat complex due to the list of things to do. 

- need to check for host leaving to pause game on a global scale
- need to look for another host from the available players and switch over
- need to inform players a host migration is in process
- need to account for the "new" host leaving before the migration is complete
- need to account for "what if everyone just leaves before migration is done"
- other things that are related to optimisation, performance, etc.

4) Scalability
The ability for the network to scale is a crucial aspect and something that will be constantly worked on. (netcode optimisation and performance, matchmaking improvements and additional lobby features).