Filter online players in Matchmaking

Alessio Falsetti

Hi,
Is it possible to make FindPlayers return only online players? It would be very useful for me to have in the "matchesFound" list only the users who are online at that moment, and not those who are offline.

Also, is there a way via CloudCoude to disable matchmaking of one or more users passed as parameters? ie:

var postResult = matchMakingProxy.disableMatchmaking(["profile_id_1", "profile_id_2"]);

Thanks!

Paul Winterhalder

In case folks were following along...

As it turns out, using brainCloud's Lobby System (which implements our Online Matchmaking) was the correct solution for @Alessio-Falsetti .

His team had initially rejected it because they thought it only implemented old-style lobbies - where the user picks a lobby to join. And to be fair - we do support that sort of operation - via the GetLobbyInstances() call.

That said - the much more common way of using Lobbies is via the FindOrCreateLobby() call - which automatically creates a lobby for you if a suitable one isn't already available.

So - to implement their use case, Alessio's team:

Configured a 1v1 lobby that has No Server associated with it.
The lobby is configured to automatically Disband on Start
The owner of the lobby catches the STARTING event - and initiates a AsyncMatch game with the other player in the lobby - presumably via the CreateMatchWithInitialTurn() call <- I'm just guessing there
And because our AsyncMatch service supports RTT events to notify players it is their turn, the two players can participate in a light real-time match without the cost of hosted servers!

I hope that helps to clarify things. @Alessio-Falsetti feel free to add any helpful tips I have missed - or correct me if I got something wrong!

Paul.
(Edit - updated to say it's the STARTING event that is being used to trigger the start of the AsyncMatch - not the ROOM_ASSIGNED event that I had originally mentioned)

Paul Winterhalder

Hi Alessio,

Hmm - interesting question.

Games using use our Lobby service for online matchmaking - but maybe that isn't appropriate for your game? Or is it? Have you looked at it?

"Matchmaking", technically considered our offline matchmaking service, is geared for finding matches for Async and One-way multiplayer games -- which technically support both offline and online play I suppose.

We could tie it into a players online status - though to ensure it's accurate (to the second) the app would need to have RTT enabled. <-- we could use the status of their RTT connection to determine if they are currently online. API sessions aren't sufficient as they take 20 minutes to "expire".

There are games on the system that have implemented their own custom matchmaking with custom entities and cloud code scripts - it may be for this use case.

Request: Can you give us a bit more information regarding your use case?

As for excluding specific profileIds - what's the use case for that? You can use a filter script to eliminate specific matches - but also since a number of candidates get returned you could simply remove them from the list on the client side?

Request: Give us more details on the profileId elimination as well. What's the use case? What would be the max # of profileId's to be excluded?

Paul.

Alessio Falsetti

Hi @Paul-Winterhalder,

Your matchmaking system is fine for our needs, but in our game players need to be online to compete.
For now I solved it by using a web hook (post) on FindPlayers, which takes the list, uses the Presence API (GetPresenceOfUsers) to see if the users are online and returns only those.
It works well, but if FindPlayers had an option to exclude offline users it would probably be even better.
Imagine this use case:

I limit the result to 10 users
I have 12 users in total, of which 10 offline and 2 online
it is possible that in the FindPlayers result there are only the 10 offline (which happened)
my hook cleans the list and returns 0 users, when in reality there would be 2 available.

Regarding arbitrary DisableMatchMaking, I would need to clean the list of offline users who for some reason remain with MatchMacking enabled. Imagine the case:

a player searches for opponents -> EnableMatchMaking is called
the game searches for opponents for 30 seconds, then calls DisableMatchMaking and stops the search
if the player receives a phone call or for some reason closes the app before the 30 seconds are up, the user is left with MatchMacking active in this case, even if formally right that MatchMacking is active, the player should not be chosen because actually not available for our game.
Among the MatchMacking options you have "Automatically disable matchmaking for players after XX days". Even if I set it to 1, it doesn't seem to work (maybe a bug?), in fact the player always remains enabled until it is disabled from the game using DisableMatchMaking.

Thanks,
Alessio

Paul Winterhalder

Thanks for the additional use case information Alessio - I'll bring these use cases back to the devs.

Your post api-hook solution for FindPlayers() - is clever. I was going to suggest using presence in a filter - but doing it in the post-hook likely performs better. Good solve.

The "Disable matchmaking for players after XX days" is a nightly job - so it gets run at a particular time each night. I'll have the test team review it - but that's likely what you're seeing... Agreed that that isn't a solution for your use case.

I still don't think I understand the use case for the matchmaking call where you supply specific profileIds to ignore though?

Paul.

Alessio Falsetti

Ciao @Paul-Winterhalder ,

Regarding your last doubt, I would like to be able to schedule DisableMatchmaking every X hours for all those users who are not online, but still have EnableMatchmaking active. Exactly what the "Disable matchmaking for players after XX days" option should do, but more frequently (4 times a day for example).

Thanks and I hope for some suggestions that will solve it

Alessio

Paul Winterhalder

In case folks were following along...

As it turns out, using brainCloud's Lobby System (which implements our Online Matchmaking) was the correct solution for @Alessio-Falsetti .

His team had initially rejected it because they thought it only implemented old-style lobbies - where the user picks a lobby to join. And to be fair - we do support that sort of operation - via the GetLobbyInstances() call.

That said - the much more common way of using Lobbies is via the FindOrCreateLobby() call - which automatically creates a lobby for you if a suitable one isn't already available.

So - to implement their use case, Alessio's team:

Configured a 1v1 lobby that has No Server associated with it.
The lobby is configured to automatically Disband on Start
The owner of the lobby catches the STARTING event - and initiates a AsyncMatch game with the other player in the lobby - presumably via the CreateMatchWithInitialTurn() call <- I'm just guessing there
And because our AsyncMatch service supports RTT events to notify players it is their turn, the two players can participate in a light real-time match without the cost of hosted servers!

I hope that helps to clarify things. @Alessio-Falsetti feel free to add any helpful tips I have missed - or correct me if I got something wrong!

Paul.
(Edit - updated to say it's the STARTING event that is being used to trigger the start of the AsyncMatch - not the ROOM_ASSIGNED event that I had originally mentioned)

Greg Moulds

Just popping in to clarify @Paul-Winterhalder 's comment about catching the ROOM_ASSIGNED event...

That's actually not the event that should be listened for. That event is only sent if the lobby type has been configured with an associated server type and we've made a request to launch a server instance.

If no server type has been associated with the lobby type, the developer should listen and react to the STARTING event. That will be the event sent out just prior to the lobby being disbanded (assuming "Disband on start" has been selected).

Alessio Falsetti

Ciao @Paul-Winterhalder ,

yes there is not much else to add, except perhaps the fact that the CompleteMatch is sent at the end of the game. Instead, AbandonMatch is sent if one of the players abandons the game prematurely.

Thanks for the support!