The aim of this discussion is to inform developers about PUN development. This might be useful for those who are considering, which networking solution to use.
I've been developing a game in Unity, using PUN as a networking architecture, for 3 months now. The more different topics I develop and network, the more I see the one main thing that takes most of the time and brainpower when developing networking. By topics I mean things such as synching item movement, synching score and player status, synching deaths, respawns, doors that open and close, match timers etc.
The main problem when developing these features is that all the time you have to consider the case where the master client could change at ANY time. This adds a lot of instability and is a good source of errors that crawl out of the most unexpected places.
For example, what if there is an important RPC that is sent to everyone and once the master client receives this RPC he has to do something that could change the course of the game. Now what if after the RPC is sent, the master client disconnects, all the other clients execute their RPC's, ignoring the master client's code and only then a new master client is chosen. This means that the new master client must do additional checks if everything indeed is synched properly. However this kind of checking go wrong for many reasons, and thus, the game could not be synched correctly.
One of the solutions to this would be to let every player have the same game state, no matter if the player is a master client or not. But before you start developing with PUN, you have to ask yourself if this is what you want.
It would be much easier to have one server that never changes and everything is stored there. If this server goes down then yes, the game is interrupted. But you have to consider that this approach would probably take much less time to develop since the amount of checks you have to do to make sure everything is synched correctly is much smaller than compared to PUN's solution.
Cheers,
Frosty
I've been developing a game in Unity, using PUN as a networking architecture, for 3 months now. The more different topics I develop and network, the more I see the one main thing that takes most of the time and brainpower when developing networking. By topics I mean things such as synching item movement, synching score and player status, synching deaths, respawns, doors that open and close, match timers etc.
The main problem when developing these features is that all the time you have to consider the case where the master client could change at ANY time. This adds a lot of instability and is a good source of errors that crawl out of the most unexpected places.
For example, what if there is an important RPC that is sent to everyone and once the master client receives this RPC he has to do something that could change the course of the game. Now what if after the RPC is sent, the master client disconnects, all the other clients execute their RPC's, ignoring the master client's code and only then a new master client is chosen. This means that the new master client must do additional checks if everything indeed is synched properly. However this kind of checking go wrong for many reasons, and thus, the game could not be synched correctly.
One of the solutions to this would be to let every player have the same game state, no matter if the player is a master client or not. But before you start developing with PUN, you have to ask yourself if this is what you want.
It would be much easier to have one server that never changes and everything is stored there. If this server goes down then yes, the game is interrupted. But you have to consider that this approach would probably take much less time to develop since the amount of checks you have to do to make sure everything is synched correctly is much smaller than compared to PUN's solution.
Cheers,
Frosty