Best way of avoiding dead rooms

Heyall

Our game lets user's create rooms where they can invite their friends and such. The way we handle rooms and all that is through webhooks.
I.e.
When a player opens a room our web-server receives a message from the photon servers that a room has been created.
Similarly, when a player closes their room we receive a message from Photon that the room has bee destroyed.
We store this information in a database that we maintain.

However, there are a few cases where this gets tricky.
For instance, if the player opens their room, and they then terminate the game abruptly, we do not get the message from the Photon servers that our room has been destroyed before the room has been timed-out (no players for x amount of time).

This becomes a problem when a player sees his friend has an open room and tries to join it, only to discover that the room is actually destroyed - or should have been.

We've managed to reduce this time before the room is registered as dead by also keeping track of player connections and disconnections. (i.e. using the webhook PathJoin and PathLeave, counting how many players connected, and not showing rooms with 0-players connected) This almost gets us there, because now we can skip the room time-out. But we are still waiting for the player timeout.

I'm unsure if there is something I've missed. A check to see if a room with this room name has at least 1 player would be handy, but I haven't found it. Otherwise, if I could be able to raise an event or RPCs from our web server, we would be able to create a "This player is trying to join"-thingy which we could use to create the "least 1 player"-thingy as well as some other cool stuff (it would actually be really neat).


If nothing else, my emergency solution is to just reduce the PlayerTTL, but I rather have the ability to just query.

Comments

  • JohnTube
    JohnTube ✭✭✭✭✭
    edited June 2018
    Hi @UpstairsDigital,

    There will always be cases where the server (and thus other players/friends) still thinks the player is still joined to a room.
    A typical example is the client timeout:
    The server will give a "not responding" client 10 seconds timeout before disconnecting it.
    This is different from the PlayerTTL.

    So there will be always a "short" (~>=10 seconds) window of "dead rooms" or false positives.

    In any case, there will always be players quitting abruptly (rage quitting, unexpected disconnects, etc.).
    You should allow ReconnectAndRejoin feature though for a fast recovery for those who want to rejoin.

    What you could do however is changing PlayerTTL and EmptyRoomTTL post room creation.
    This feature has been added "lately" after the trick was suggested by customers for matchmaking purposes.
    Before the room is full, it is created for instance with default values of PlayerTTL = 0 or EmptyRoomTTL = 0.
    When the room is full and game logic starts, change PlayerTTL != 0 or EmptyRoomTTL > 0.
    This still does not prevent temporary lingering disconnected "ghost"/"zombie" clients or "dead empty rooms" which are due to the disconnect timeout value.
    You can reduce the "short window" by adding a "heartbeat" WebRPC to detect when a client is really disconnected. You will need to come up with some heuristic though to know when to decide it is really the case.