Dynamic Queue Algorithm changes

Hi all,

@RiotSupport on twitter requested I post this here.

The goals of matchmaking are pretty straight-forward.

• To create two teams with an equal probability of winning a match, and;
• For a player’s winrate to stabilize at 50% at their appropriate MMR, and;
• To find a match in an appropriate timeframe.

No algorithm will ever be perfect, but the issue I’m seeing with the last few dynamic queue updates is that the algorithm is unaware of its imperfections. That is to say, each match considers a player based on their state at that instant in time.

However, if the algorithm were to rate its past matchmaking efforts with a positive or negative deviation from ‘perfect’, it would have a concept of the outcomes of its decision-making. With each match viewed in isolation, it is possible for negative snowball to become recursive and self-perpetuating.

Consider the hypothetical match.

Your MMR: 1500 Your Team Avg MMR: 1400, solo queued Other Team Av MMR: 1500, premade 3 MMR discrepancy: -100

Viewed in isolation, the algorithm might think 'yeah that’s alright, not great but within acceptable parameters’. This is a suboptimal match, and blue side should probably expect to lose. It happens, in a perfect world you should never have a match-up the algorithm expects you to lose, instead attempting to find an equal chance of winning or losing, but the reality is some games are unwinnable at minute zero. So blue side gets ravaged and you queue again.

The algorithm can then find you a near identical game, which it will also view as being not great but acceptable.

Your MMR: 1498 Your Team Avg MMR: 1400, solo queued Other Team Av MMR: 1500, 2x duos MMR discrepancy: -100

It gets added to match history, and adjusts your MMR calculation. You queue again, and so on and so forth. Despite an individual player’s performance, because of a lack of pattern awareness outside of the inherent MMR drop through losses, it is possible for the algorithm to provide users a suboptimal experience while being responsible for that experience. The system has no concept of an MMR deficit, because it doesn’t consider that it’s thrown you 10 matches in a row where Red had a notably better MMR, because if it’s acceptable once it’s acceptable 10 times. Moreover, by considering only win/loss and MMR differential you can create a snowball, because the only way out of that loop is for the players MMR to tank so significantly that their opponents and teammates get so bad that the player can solo carry games. You then experience a pendulum effect - long win streaks followed by long loss streaks as it alternates between 'this user is rated too low’ and 'this user is rated too high’. This can be translated into the UX as ‘haha quick game’s a good game’ and ‘kms kms kms kms kms’.

By considering the rate of change of MMR historically, snowball inertia, win:loss and MMR differential of the final match-up, the algorithm could analyze its own performance and adjust accordingly, allowing it to interpolate what would ordinarily be a fluctuating MMR calculation that was swinging back and forth. By adjusting itself for whether it had functioned fairly accurately, it would be able to extrapolate an Effective MatchMaking Rank (EMMR) that would be based on the current condition set.

I theorize that by viewing data as a result set for multiple weighting rather than depending on its own historical performance for a single value result, that matchmaking could effectively tune itself. This dynamic stabilization built into the calculation would create a more accurate and consistent League of Legends experience in low-to-medium MMR players (~800 - 1400) which make up over 50% of the player base.

(Sidenote: If I’m a jungle main and Dynamic Queue auto-fills me to adc, please adjust my EMMR down accordingly, y'all know I’m going to suck at it so no reason to rate me as highly as on my main role.)