jules suggested an idea · Apr 13, 2020 at 06:59 PM · Matchmaking
Tickets waiting in queue longer should be prioritized. Obey all difference and team difference rules, as normal. TimeInQueue would not override any rules; it would just be used as a tiebreaker if multiple combinations of tickets can form an acceptable match.
In general, we are happy with PlayFab Matchmaking 2.0, but we keep noticing what we consider to be a poor optimization. When multiple combinations of tickets can form an acceptable match, it does not prioritize the tickets that have been in queue longest. Our expectation and request is that it would prioritize tickets that have been in queue longest. The scenario that best reproduces it is:
Three tickets in queue:
- 2000 rating (4 minutes in queue)
- 1900 rating (3 minutes in queue)
- 1850 rating (2 minutes in queue)
Our primary game mode is 2v2, so the matchmaker waits for another ticket to enter queue.
A duo ticket enters queue:
- 1800 rating and 1800 rating (0 minutes in queue)
A match is formed with the 1900 and 1850 against the 1800 and 1800.
While this is considered an acceptable match, according to our difference rules, the 2000 player was left behind, despite him being in queue longer than the other players. For us, this is problematic for two reasons:
I originally submitted this as a bug report and spoke with Jay Zuo, a Microsoft support engineer. He told me that the Microsoft/PlayFab Matchmaker does not consider TimeInQueue at all. According to him, "it's not a big deal if there are enough players." He's right about that, but our community is smaller (around 10,000 MAU). We are very in touch with our community, and they bring this up as an issue that affects them every day.
There are two main cases where it negatively affects us:
According to Jay, the Microsoft/PlayFab Matchmaker considers tickets, then stops considering them after GiveUpAfterSeconds runs out. Instead of that, I would propose something like:
As a workaround, we're considering adding a new rule that uses TimeInQueue to prevent tickets from being matched within 10-15 seconds of queueing. We're hoping this will decrease the likelihood of the matchmaker skipping players, while also not increasing the matchmaker's average queue time meaningfully. Prioritizing tickets based on TimeInQueue would be highly preferable to this hacky rule-based solution.
To me, regardless of player base size, it seems like a proper optimization to consider TimeInQueue when matching tickets. It would also significantly help titles with small to medium-sized player bases.
Thanks for your time and consideration.
Cheers,
Julian
jules commented · Jul 17, 2020 at 06:25 PM
Just updating that we continue to have problems on a daily basis because of lack of ticket prioritization by TimeInQueue. Players waiting in queue for a long time get skipped by the PlayFab matchmaker.
For example, this case just happened yesterday:
Our game is 2v2, and all players in this example are almost identical rating (they are all within the parameter ranges to match with each other immediately)
- Player A in queue for 9 minutes
- Player B in queue for 8 minutes
- Player C in queue for 2 minutes
- Duo D queues up
- Match is formed with A + C vs D
- Expectation: Match is formed with A + B vs D
This is a clear and concise example of a pretty major flaw in the PlayFab matchmaker. If tickets were prioritized by TimeInQueue, it would improve matchmaking for many or all titles.
Brendan commented · Jul 17, 2020 at 07:01 PM
One correction: Time is considered as a factor, but it's specific to the settings you put on the parameters for the search in your queue. For a game with a rank check, the Expansion and SecondsUntilOptional are the drivers of the time portion of this.
So for example, if your matchmaker rule has a starting delta of 200 for the player rating, with an expansion of 1 every 2 seconds, it would take 6 minutes and 40 seconds for a rating 2200 player's ticket to match with a rating 1800 player.
It's also important to note that all tickets are applying the rule equally. So once the rating 2200 player's ticket can match with the 1800 rating player's, the 1800 rating player's ticket would have had to be in queue long enough for the expansion of the skill their ticket will match with to allow for a skill 2200 player.
Finally, for the first 30 seconds of a ticket's lifetime, it can only match with other tickets that are at least as old as it. That way, you can't have new tickets that came in after it "jumping the queue". After that 30 seconds, the ticket can match with any other ticket. And more to the point, after that first 30 seconds, they can match with other tickets even if those tickets wouldn't normally match with them.
So the best way to solve this in the short term would be to relax the rank check requirements. In general, the more strict the matchmaking rules, the larger a player base you need in order to have decent match times for all players.
Thanks for your reply, Brendan. My most recent example explains the issue much more concisely than my original thread. I wish I could edit my original thread and replace it with my reply above, but it doesn't let me.
Here's the example:
Our game is 2v2, and all players in this example are identical rating (they are all within the parameter ranges to match with each other immediately). There are only 3 players in queue:
- Player A in queue for 2 minutes
- Player B in queue for 2 minutes
- Player C in queue for 1 minute
- Duo D queues up
- Match is formed with A + C vs D
- Expectation: Match is formed with A + B vs D
You can see in this simplified example, the exact rank check rules are not relevant. Relaxing the rank check rules wouldn't solve this. And the 30-second rule you mentioned does not solve this. Player B gets jumped by Player C.
Max Guernsey, III commented · Aug 07, 2020 at 01:34 AM
If I understand correctly, the expansion is linear: Window Radius = Rate * Time. This is really a first-order polynomial: Window Radius = (Rate * Time)^1.
I think a different exponent (or better yet, the ability to specify an exponent) would probably work more effectively for people with non-linear rank-distributions. I think of matchmaking as an increasingly desperate proposition as the wait time increases. Allowing us to change the exponent would let us create an elbow in the expansion's growth and tune that elbow to kick in before players abandon the pursuit.
I didn't know where to put that thought, so I just added it as a comment, here.
Actually, you can use the "Custom" expansion type to specify whatever "step sizes" you'd like to have in your expansion rule for skill.
So you can just precompute the curve and include it as part of the rule?
We would love to know what you need. Submit your ideas and upvote others to help us prioritize.