Handling Disconnects and Reconnecting

Teddymac

First off, we are working on a turn based multiplayer card game (using PUN) and things are progressing quite well. We all played on separate laptops the other night and it went perfect, so kudos to the Photon team. Now, we went to a different location and for whatever reason the wifi there was buggy and would drop connection to the internet at random times for a few seconds, which caused our game to stop functioning properly. We knew at some point we would have to prepare the code for such contingencies, so now seems a good time for that.

The question is just what would be the best way to handle this and is there any documentation on what to do about random disconnects and reconnecting to the same game?

OnDisconnected we could save all the current data and room name and have the players reset up their game to the same as it was before they left, and pausing the Master Client, that sounds like a reasonable solution, but what about RCPs that never made it to the client, should they all be buffered, so that they can be resumed on reconnecting? Just what are all the ways to prevent clients from becoming out of sync in such instances?

[Deleted User]

Buffered events is good solution only if count of events during the game is not large.
If events are not buffered, you need to restore game state on client when it joins. Therefore, full game state should be stored somewhere.
One possible solution is to keep track of game state on each client and request master client for that state on connect or reconnect.
For simple games, room properties can be used for game state storage. But avoid frequent updates of huge properties trees for complex games when only one leaf changed (use single property per key).
Turnbased application has another option - store game state on 3rd party servers via webhooks: http://doc.photonengine.com/en/turnbased/current/reference/webhooks

You may also find useful page about analyzing disconnects: https://doc.photonengine.com/ko-kr/realtime/current/reference/analyzing-disconnects

Teddymac

Thanks much for the info, it is a great help and lets us know what direction we need to take.