Idea

jules avatar image
jules suggested

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

Matchmaking
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

3 Comments

·
jules avatar image
jules commented

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.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan commented

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.

1 comment
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jules avatar image jules commented ·

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.

0 Likes 0 ·
Max Guernsey, III avatar image
Max Guernsey, III commented
@Brendan

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.

2 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image brendan commented ·

Actually, you can use the "Custom" expansion type to specify whatever "step sizes" you'd like to have in your expansion rule for skill.

0 Likes 0 ·
Max Guernsey, III avatar image Max Guernsey, III brendan commented ·

So you can just precompute the curve and include it as part of the rule?

0 Likes 0 ·

Write a Comment

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Your Opinion Counts

Share your great idea, or help out by voting for other people's ideas.