Joining room with an inactive player in it? (Turnbased Unity)

jamesar
jamesar
edited August 2015 in DotNet
Hey guys,

I've been having this problem for a while now but I've finally figured out the real cause of it. When one of my players joins a room and waits for other players to join, then either returns to the lobby or puts the phone in background mode, that room becomes unavailable to join for all other players. However, that room still gets saved for the original player who created it, and they are still able to rejoin it.

The room is only joinable for other players when the person who created it is active in the room. Is there any way to ensure that the room is joinable for all other players even when the person who created the room is considered inactive?

I have looked at PlayerTTL and EmptyRoomTTL but they do not seem to solve the problem for me.

Thanks for taking a look!

Comments

  • JohnTube
    JohnTube ✭✭✭✭✭
    Hi @jamesar,

    Please try the LobbyType AsyncRandomLobby when you create the Rooms. It will make the Room visible in the same lobby for an extra hour after EmptyRoomTTL.
  • jamesar
    jamesar
    edited August 2015
    JohnTube said:

    Hi @jamesar,

    Please try the LobbyType AsyncRandomLobby when you create the Rooms. It will make the Room visible in the same lobby for an extra hour after EmptyRoomTTL.

    Thanks John! Do I need to add this new lobby type (AsyncRandom) to the TypedRoom parameter of all of my OpJoinRandomRoom calls?

  • JohnTube
    JohnTube ✭✭✭✭✭
    Yes.
  • I'm having a similar issue. I need the other player to be able to join the room for up to 48 hrs after it is created and when I try to join the room after EmptyRoomTTL has finished it says it doesn't exist instead of loading it from memory and joining it.
  • JohnTube
    JohnTube ✭✭✭✭✭
    edited November 2015
    @Jad
    48 hours exceeds the maximum lifetime of a Room inside AsyncRandomLobby which is:
    65minutes = 5 mintues (300000 milliseconds; EmptyRoomTtl threshold) + 1 hour (property of AsyncRandomLobby)

    The 1 hour value may be changed in Photon servers configuration if you're self hosting OnPermise.

    Otherwise you may need to store a list of unmatched/not joined/not full rooms that are removed from Photon servers before 48 hours on your own (outside Photon's scope) and join a room by name instead. You should use Photon's matchmaking only when that list is empty.

    Do you really need 48 hours for random matchmaking? Maybe you're thinking about invitations where players challenge their friends.
  • @JohnTube I'm sorry if I wasn't clear in my comment I'm not doing random matchmaking. Here's the flow: The host creates the room and sends the room name to the invitee via a DB the host can then leave the room and the invitee must be able to join the room within 48 hours of it's creation. Then the game starts for both players.

    The problem I'm having is that for some reason when the invitee joins the room, it sometimes doesn't load it from saved instance and creates a new room without any of the settings the host created it with.

    Thanks for your response
  • JohnTube
    JohnTube ✭✭✭✭✭
    edited November 2015
    @Jad

    You need to configure and implement webhooks to save and load room states.

    Use PathClose, Type='Save' to save room state in your DB.
    Use PathCreate, Type='Load' to return previously saved state if any or authorize new room creation (CreateIfNotExist flag check).
  • I see could you help me implement webhooks using PHP do you have an example of how to read the requests and handle them?
  • Jad
    Jad
    edited November 2015
    Hi so I managed to implement the webhooks in php everything is working fine except when two users create a room at the same time and then exit the room I get a call to game close twice for the game that was created last and i don't get any for the game that was created first

    Any thoughts?

    Jad
  • JohnTube
    JohnTube ✭✭✭✭✭
    Hi @Jad

    There is no PHP code for webhooks publicly available yet. So I'm glad you made it all by yourself!

    The issue you spotted was fixed. Please try again and do tell us if you see anything strange about webhooks behaviour.