Matchmaking - Prioritize Tickets by TimeInQueue

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:

1. There is an expectation that a player who is in queue longer should be prioritized
2. A 2000 player is very high-rated in our game (an outlier), so if there is an acceptable match for him, we should be happy about putting him in the match. The fact that it skips him means he's likely to wait much longer and likely have a less fair game.

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:

1. Our skill-based ranked queue: high-rated players complain about getting "skipped by the matchmaker," despite waiting in queue longer, which leads to them getting frustrated. Also, because they are so high-rated, it's difficult to find a fair match for them, so they end up waiting in queue even longer and eventually being matched into a less fair game (rightfully, due to expansion). If the players waiting in queue longest had been prioritized, they would have been matched sooner and into fairer matches.
2. Our fast-queue unranked queue. In this queue, as soon as any 4v4 match can be formed, it will form a match. We even display x/8, where x = the number of players in this queue, so there is a strong expectation of being matched when 8/8 is reached. When players get skipped, they get vocally upset, because of the expectation of short queue time and feeling of unfairness, like getting cut in line.

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:

• Prioritize tickets by TimeInQueue, or give us the ability to prioritize by any variable. TimeInQueue is probably the most common and useful case. For other titles, being able to prioritize tickets by, say, ToxicityScore would be valuable and a way to encourage positive behavior. We'd be more than happy with just TimeInQueue prioritization though.
• 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.

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