Now it would be great to broaden the search after enough time has passed, so users on rarer ranks do find matches, even if they are slightly over/underpowered.
So for example after a minute without finding a match the player now also searches for matches on higher and lower ranks than he himself is in.
However for that to work the other players would also need to search for matches in other ranks, which might not be needed if their own rank has enough matches to matchmake.
One approach that occurs to me is removing the initial search if it’s taking too long using removeMatchmakerTicket and then reperforming the search with broader query properties.
It’s possible there may be a better idea that occurs to one of the other staff or community members.
However for the match to occur the other player would also need to search in a higher/lower rank, right? Therefore I would need some kind of notification mechanism so the client is informed that he should perform a broader search even though there are enough matches in the current rank.
Hey @MWFIAE under my approach, I would just use the same ranking mechanism on the second search. So in your case, you search by number of starts initially. That takes too long, so you remove the ticket, modify the query with the “stars” property, and then re-add the ticket.
If you wanted other users to know for some reason that it’s a “broadened” search attempt, you can add some other query property like “numAttempts”.
Okay maybe I’m just misunderstanding it.
So let’s try with an example.
I do have the following initial query. query = "+properties.stars:" + userWallet.rankingStars;
I do have 2 users. Alice and Bob.
Alice has 10 Stars, Bob has 9 Stars.
So the initial query for Alice would look like this: "+properties.stars:10".
The query for Bob looks like this: "+properties.stars:9"
So they don’t find each other.
Bob however does frequently find other players, since there are alot of players with 9 stars.
After 3 minutes in the queue Alice does broaden her search by removing the initial matchmaking and adding a new one with a broader query. So she now has a query like this: "+properties.stars:>=9 +properties.stars:<=11".
However Bob doesn’t know that Alice is searching for lower ranked enemies. So Bob has still a query like this: "+properties.stars:9".
They won’t find each other unless Bob also doesn’t find a match after 3 Minutes and has to broaden his search too, right?
@MWFIAE that’s right that they wouldn’t find one another. But I think that’s only a problem because you’re initial search for each client is very narrow.
Also, an alternative to removing the matchmaker for broadening the search is using a SHOULD clause in Bleve or using “boosting”:
And Bob could have something similar for his amount of stars.
The initial properties clause is a SHOULD rather than a MUST clause, so ten star matches will be preferred, but it will choose the broader range if no equal star results turn up.
I simplified a bit to get to the core of the problem
Of course the initial query will be broader than the exact amount of stars.
In fact I already planned a query similar to yours for the game.
However I’m still concerned about the match making especially since I can’t yet know how it will turn out and which rank distribution we will get. And of course we don’t want the matchmaking to take too long so players don’t lose interest.
Hey @MWFIAE I totally understand the UX concern. How is your concern not alleviated by the following logical query for all users:
(1) A SHOULD clause preferring users close to your rank.
(2) A MUST clause describing some outer bound of ranks you are willing to match with.
(3) Removing the ticket and reentering matchmaking (opaque to the user) some n number of times, after short intervals, gradually increasing (1) and/or (2).
You could also calculate rank distributions via server RPCs by pulling in from your user info and feed that into your queries, but that may be overkill.
If you are still worried, you could write some tests with mock users.
My main concern would be with point #3, because I can’t guarantee a “symmetrical” broadening.
I.e. even though one user has broadened their search and should even have some kind of priority since he waited for a long time, they won’t find somebody else if the other person didn’t also broaden their search.
But I guess for now I will just start with this approach and “fix” it once I know it is really making problems.
On a related note, there are no matchmaking statistics builtin, right?
Like to see how long matchmaking normally takes and stuff like that
