Devlog 4: Network objects

This devlog marks the success of refactoring the object state system.

For context, the previous solution was making use of RPC calls to all clients for object instantiation/destruction (not on the network). This meant that if player 1 places a block locally, in the backend a broadcast message is sent to all clients in the room to do the same locally. An issue then occurs for player 3 who joins after the block has been placed. As it has missed out the broadcast, the block would not be spawned, and so on player 1 and 2's screen, the block is placed, but on player 3's screen, it would be empty. Although there are actually workarounds (rpc allbuffered) for this issue while keeping the idea the same, this system still clearly misses out on something: there is no shared reference to the objects.

A system where every single client is "disconnected" from one another, only relying on broadcasts to update accordingly, will only spiral downhill with time. When all turn out of sync, and all client screens differ from one another, it begs the question: which client is right? 

This gives rise to the idea of object state governance/authority. The idea is, instead of instantiating locally on all clients, it instantiates on the photon network (cloud). Via websocket/UDP, the object state is then synchronized across all clients via a single reliable source (photon network). For state modification, there is an authority/ownership system, that essentially decides which client can modify which object. For example, client spawns their player object, so the player object is owned by them, and can only be modified by them. Other clients will not be able to modify player objects that are not theirs. 

For subsequent network objects i.e. blocks, the master client will most likely be the client owning and modifying it. The master client is essentially the "host", but without a dedicated server. 

Scenario: Player 1 places grass block. This means, player 1 client spawns the grass block on the network, and effectively owns it. This means that if player 2 tries to destroy it from the network, it will not happen as it does not have authority. If I want to make it so that player 2 can destroy the grass block, I will have to request/transfer ownership of the grass block. Hence, to centralize things and make it easier to manage, I made it so that only the master client spawns/destroys network objects. This effectively means only 1 client handles instantiation/destruction, as well as communication with the map database. For now this works well, but I believe for other uses this approach would be bad as the master client becomes a massive bottleneck/liability.

The updated architecture for object state governance under photon network is, 
1) The first client that joins will be the master client
2) It will read from the database and instantiate all the objects accordingly on the network
3) Newcomers will join with it automatically loaded, since they are spawned on the network
4) Newcomers (non-master clients) who instantiate/destroy objects will go through the master client via targeted rpc call to master client
5) Master client handles all object instantiation/destruction, and updates the database accordingly. This centralizes control, but may also act as a bottleneck
6) If master client leaves, an existing client will upgrade to master client, and all previous network objects are given to it.
7) OnRoomLeave callback will handle the destruction of the leaving client. (note this is because room automatic cleanup is disabled.

All in all, the updated system addresses the issues of latecomers and synchronization.

Also when dealing with rpc calls, there is a need for carefulness, especially if there is anything network/database related within the call. This is because of unwanted calls. For example, if I call PhotonNetwork.Instantiate(gameObject); within a rpc call, it will call it as many times as the amount of clients. So the gameObject will be duplicated many times. In most cases, this type of error is not that easy to detect and so debugging tools should be developed to monitor rpc calls.

Below is a real example, where upon taking damage, all clients will update the health accordingly, but only one client needs to manage the destruction of the object. If I do not check for master client in Die(), the following code would repeat an unwanted amount of times.

As  seen above, a simple health system was also developed. This is primarily targeted at blocks, since we want the blocks to slowly get destroyed, instead of instantly. With the blocks having health, there needs a means to damage it, and so a punch system was also developed. 

The punch system is developed via 2 main steps. First is to damage the health and sync it via rpc call, and next is to have a simple animation of the gray square "punching it" and sync it via rpc call as well. I have yet to fully think out the punch system, but for now it works decently.