Lobby creation/deletion events in CloudCode

Alessio Falsetti

Hi,
Is there a way, on the CloudCode side, to intercept when a new Lobby is created/deleted?
If so, is it possible to notify currently connected users (via RTT) that the Lobby has been created/deleted?

Thanx!

Paul Winterhalder

Oh - interesting...

I'm guessing your game has a lobby browser - and you want to update it dynamically if a new lobby becomes available... (instead of continuously polling from the client - which would be the alternative).

We don't have something currently - but it might be interesting to create the concept of a lobbyType channel for such a think. So an RTT user would connect to a channel of the appropriate lobbyType to listen for this sort of event... (and of course, the app could connect to multiple lobbyType channels if necessary as well).

Presumably you'd want to know when new lobbies are added or removed...

What about state changes to the lobbies? (Certainly updating lobby listeners about the state changes of every lobby in the system could be tons of data and get potentionally problematic... polling every <x> seconds might be more efficient for that).

Thoughts?

Paul.

Greg Moulds

Could we get some elaboration on your use-case Alessio? For example, what's your definition of "currently connected users"? Are these users just generally online or actually members of the lobby instance itself? Something else that may or may not be relevant: how are these lobbies being created? Manually via the client/CloudCode ... or via our built-in matchmaking processes? Thanks!

Alessio Falsetti

Yes Paul, exactly. There is a lobby browser and I would like to avoid polling it. I currently poll using lobbyProxy.getLobbyInstances to get the list, but then I have to loop through the list and get the settings/extra json with lobbyProxy.getLobbyData. However, all this is very expensive (1 API call getLobbyInstance and 1 API call for each getLobbyData). Having the created/deleted events would be ideal, alternatively if getLobbyInstances also returned the lobby settings it could also be an acceptable alternative.
There is also another problem: since the update is timed, closed lobbies are still visible to users in the browser, and this also creates a bit of confusion because at that point users have to be told that that lobby no longer exists if they click on it.

Greg, by connected users, I mean the users who are currently playing and are connected via RTT, regardless of whether they are in the lobby or not. It would be useful to have the possibility of sending a broadcast message to all players online at that moment or to a subset of users with some filter (e.g. he is playing a match, exclude him from the list).

Suggestions?

Thanks!

Alessio Falsetti

Greg, I just saw that you introduced SysSendEventToProfiles in version 5.0. Something like that but without needing to specify the list of users

Greg Moulds

Thanks for the additional details Alessio. Paul and I will discuss some options and get back to you.

Greg Moulds

Hey Alessio. I just thought of something that might help you with part of your use-case. We do have the facility for you to attach some arbitrary data to a lobby instance that WILL be returned in the GET_LOBBY_INSTANCES
call. That piece of data is set by specifying a "_public" key in the lobby instance "settings" field. For example, here's a sample call to create a lobby instance that sets it:

CREATE_LOBBY REQUEST:

{
   "service": "lobby",
   "operation": "CREATE_LOBBY",
   "data": {
      "lobbyType": "TestPVP",
      "rating": 76,
      "otherUserCxIds": [],
      "settings": {
         "_public": {
            "hello": "world"
         }
      },
      "isReady": false,
      "extraJson": {},
      "teamCode": "all"
}
}

CREATE_LOBBY RESPONSE:

{
   "status": 200,
   "data": {
      "lobbyId": "23713:TestPVP:41"
   }
}

GET_LOBBY_INSTANCES REQUEST:

{
   "service": "lobby",
   "operation": "GET_LOBBY_INSTANCES",
   "data": {
      "lobbyType": "TestPVP",
      "criteriaJson": {
         "rating": {
            "min": 25,
            "max": 99
         }
      }
   }
}

GET_LOBBY_INSTANCES RESPONSE:

{
   "status": 200,
   "data": {
      "lobbiesByRating": {
         "76.0": [{
            "id": "23713:TestPVP:41",
            "lobbyType": "TestPVP",
            "state": "early",
            "rating": 76,
            "desc": "TestPVP",
            "owner": {
               "profileId": "c14caf2b-6c72-4c8e-9280-54356f7d56c2",
               "name": "",
               "rating": 0,
               "cxId": "23713:c14caf2b-6c72-4c8e-9280-54356f7d56c2:nscnrabmi1ukk1ncr2dqpf9nau"
            },
            "numMembers": 1,
            "maxMembers": 2,
            "publicSettings": {
               "hello": "world"
            }
         }]
      }
   },
}

Greg Moulds

Notice that the "_public" settings key/value is returned as a "publicSettings" key/value in the response to GET_LOBBY_INSTANCES. Is that something that you can take advantage of for your use-case?

Alessio Falsetti

Ciao Greg,

yes this thing would be great, it would be perfect for what I need!

I'm currently trying this solution, please tell me if you think there might be any problems:

when a user enters in the view with the lobby browser I invoke a script on the BC side in which I save the user's profileId in a Global Entity. When the user leave the browser view, I invoke the same service that removes him.
when a user creates a lobby, I develop an API Hook which at the CreateLobby event (post) takes the IDs saved in the list and with SysSendEventToProfiles informs the users to update the lobby list
when a user leaves, with the LeaveLobby Hook API (post), I check if the lobby has been removed, if so, as per point 2, I inform the users to update the list

The change you suggest would be an excellent further optimization and would be fantastic

My doubts now are these:

although the number of users in the list saved in Global Enity is less than 1000 (average 400 users), do you think there could be performance problems?
if the app crash or closed unexpectedly, the user list in the Global Entity may not be updated because the removal event does not arrive at BC, at that point if SysSendEventToProfiles sends to non-connected profileIds, what happens? I have to try and find a way to clean the list.

Suggestions?

Thank you!

Alessio

Alessio Falsetti

Ciao!

With the procedure described above and the modification you made for the publicSettings I think I have solved the problem of having to do polling. All I have to do is figure out how to clean the list of profileIds in the Global Entity in case of an unexpected crash.
Thanks guys for the support! If you have any other suggestions, they are welcome

Greg Moulds

Great to hear Alessio. Let us know if anything else pops up or if you notice any other gaps. Ciao!

Greg Moulds

I'll let Paul speak to the performance issues that you mention as concerns. I think your right to be concerned about that performance so I'll let Paul chime in.

Paul Winterhalder

Hi Alessio,

I have a suggestion.

Why not create a global chat channel called "lobbyListeners".

Then - when a user is viewing the lobbies - have them connect to and listen to the lobbyListeners channel.

Then you don't need to maintain a global entity at all. Whenever you create a lobby or delete it - send an event to lobbyListeners - and it will automatically send it to everyone who has registered for the channel.

Would that work? (or is there a part of your use case that I am missing?)

Paul.