Is Riot’s “Random” ARAM Algorithm Giving You Worse Champions in League of Legends?
A deep dive into the dependencies that prevent the game mode from being completely fair with suggestions on alleviating the issue.
Recently, Riot Games made a post that briefly describes the champ select process for ARAM, short for “All Random All Mid.” There are two points of interest, the first being the structure behind TeamBuilder, which avoids concurrency issues by routing requests through the server in an ordered fashion, guaranteeing that the same champion is not selected twice. The second piece addresses whether the system is random or not, which arrives at a somewhat ambiguous answer; TeamBuilder randomly draws a champion from a set of available champions that is not random.
We’re going to examine why the constraints preventing duplicate champions, and TeamBuilder’s ordering structure ensures that, for most cases, a uniform random selection does not occur. We will then explore a few ways to approximate or fully achieve a proper uniform random selection under this setting.
What is Random?
On the surface, the idea of random appears simple to understand; a non-deterministic process, such as flipping a coin or rolling a die. Unfortunately, what is meant by random can be complex; there are philosophical and technical arguments as to why true randomness doesn’t exist. It is essential to recognize that random processes on computers are pseudorandom; most output a sequence of numbers, driven by a mathematical method. These sequences have a known period length and will eventually repeat. However, for most algorithms, this sequence is relatively long, meaning that we can assume that pseudorandom is a good enough proxy for the sake of this post.
Instead of deep-diving into the intricacies of random number generation, we’re going to focus on the concept of uniform random selection, which is a method of selecting items from a population where the probability of choosing a particular item is the proportion of those items in the population. In the case of ARAM, the population is the set of champions that a player owns, and uniform random selection only holds if the probability of choosing any champion from that pool is equal. Currently, this is not the case for players entering ARAM; certain players are more likely to end up with certain champions over others.
An Example
To simplify the scenario, let’s assume a two vs. two ARAM match, where we have limited the champion pool to ten and turned off rerolls. Assume that we possess all of the champions, one through ten, while the other three players only own champions one through five. What should our probability of selecting each champion be? Since we own ten champions, there should be a 10% chance to end up with each. However, this is not what happens in ARAM — the constraint that a player can not receive a previously assigned champion and the mismatch in champion pools amongst players prevents this. There is a lot to digest in that sentence, so to alleviate any confusion, we will walk through it step by step.
The first thing to recognize is that order matters; the probability that we receive each champion is dependent on when we get our initial roll relative to everyone else; the outcome for rolling first is quite different from rolling last. Starting with the most straightforward situation, if we were to roll first, the probability is a uniform random selection, equally distributed such as below:
However, if we roll second, then one of the first five champions, those that everyone else owns, has already been taken, and our probabilities become dependent on that action. Each of the five possible scenarios has been listed below, along with normalized probabilities:
We represent a scenario where a champion has already been taken by a zero. We then make a uniform random selection amongst the remaining champions. Since the scenarios above are equally probable, we can aggregate them along the column axis and divide by five to get the overall expectation for each champion when rolling second:
In choosing second, you are 25% more likely to get a champion that the other players do not own. Running through the same process, we can calculate the expectations for rolling third or fourth:
In the most extreme case, rolling last, we are 150% more likely to get a champion that the other players do not own. Of course, the overall expectation will be the average of all possible positions within the queue. If we assume that the queue ordering is uniformly random itself, we can add up the fractions across these four scenarios and divide by four which yields:
Since the fractions are starting to get a little gnarly, it is easier to convert them to decimals — below are the expectations rounded to two decimals:
If we were to simulate this selection process a thousand times, getting a streak of the same champion in different games is possible. When that happens, it can feel like it is not entirely random because, to some extent, it is not.
The Issue
Instead of questioning whether the ARAM selection process is uniformly random, which we’ve seen indications that it is not, we should instead ask — is this a problem? Suppose we own all ten champions, some good and some bad, but everyone else has selectively acquired the same five overpowered champions. In that case, the person with the more extensive champion pool is at a considerable disadvantage. According to our calculations above, they are 50% more likely to receive an underpowered champion.
Shortly after ARAM became a popular game mode, it was evident that players were curating accounts specifically for the mode. Riot focused balance efforts on Summoner’s Rift, and map-specific tuning had yet to come at the time. Due to this, the variance in win rates amongst champions for ARAM was far more significant. It proved heavily beneficial to create a new account to acquire ranged and high win-rate champions. Historically, progressing in ARAM was not only about how good you could play but the steps you took to make the game mode less random and in your favor. In the same way that scrubs always choose meta champions in ranked, behind the scenes, ARAM players could spam strong champions implicitly, all while the initial perception remained: “this is random, this is fair.”
Not long ago, in patch 10.7, Riot updated the free-to-play champions for ARAM, setting 65 champions as “always free to play,” mitigating the problem but not erasing it. A hypothesis for why Riot made this change was to weaken the number of disparate champion pools, so the game mode wasn’t drastically weighted in favor of finicky accounts. Perhaps that wasn’t the case, but if so, was there a way where Riot could have avoided this?
The Solutions
It would be unfair to criticize the ARAM system without proposing a few alternatives. Below are four solutions, from impractical to possible, that I believe could have dampened the issues mentioned previously:
- Set all champions to be free in ARAM
This solution should be self-explanatory, and well, not too exciting. The previous band-aid of setting a large chunk of champions to free in ARAM reduced the problem, as the pools from one player to the next became less diverse, but this would remove the issue entirely. Everyone would be equally likely to receive each champion. However, that may be an issue in itself. If we are forcing players onto champions they don’t want to play, that also feels bad. On one end, we’re trying to make the game fair while remaining fun, and this solution may remove too much of the latter.
- Combine champion pools of all players in the match before selection
A similar but less aggressive solution to setting all champions free would be to union player pools in the match into a superset. In this situation, the order of rolling holds no importance, and we can preserve uniform random selection. Unfortunately, this still has issues mentioned previously around forcing players onto champions.
- Set the order of initial roll by descending champion pool size
A fascinating property comes forward when changing the order of rolling. If a player’s pool is a subset of another, then choosing from that subset first will affect the future superset’s selection. However, selecting from a superset first will not affect the subset’s selection. If we were to reconstruct the two vs. two scenarios from any of the other three perspectives, their chance of receiving each champion would be 20%, regardless of selection order. Since each of these players’ pools is a subset of the rest, the outcome is unaffected. Another interesting thing to point out, albeit slightly more intuitive than the statement above, disjoint sets, those that share no elements, can not impact each other in this process at all.
While ordering the process by pool sizes does not guarantee this subset hierarchy, it should be a decent approximation in most cases. Even if none of the subsets are perfect, ordering from largest champion pool to smallest will significantly diminish the bias against larger champion pools.
- Dynamically set the random selection weights for each match
Suppose we require both an exact solution that does not simply add all of the champions to everyone’s roster. In that case, each match needs to weight selection probabilities dependent on order and champion pools dynamically. Yes, we need to impose bias in each player’s rolls to counterbalance the other dependency issues. The irony here is that we will not perform a uniform random selection at all of the steps, but the overall outcome will be a random selection for every user.
Returning to the example we outlined above, but instead of using a uniform probability of 10% for each champion, we use the two values below, the first for the “strong” group of champions, represented by s, and the second for the “weak” group of champions, represented by w. Our new representation of the probabilities for picking first has this form:
We constrained s and w to be equal under the original setting, but we will loosen that restriction. The only thing that needs to hold is:
We can progress through each roll order and write out similar equations to that above. In the end, we will have an extensive system of equations — as much as we all would love to watch me slog through the algebraic expressions and combinatorial math, I’m just going to state the solution for s and w for our ARAM example. At a later point, I will justify why that level of work is not needed. Here is the solution:
Suppose we, the owner of all ten champions, have been randomly selected to roll first. In that case, we need to put a higher probability on the strong champions to counteract when the system randomly chooses us to roll later. We can now run through the same set of calculations from earlier and output the probability of the draw choosing a specific strong or weak champion in each position. The expectations for each round are as follows:
Now, notice if we take averages across either type of champion, there is an equal probability that the process chooses each. In the strong case:
It is important to note that none of the other players have been affected; their chance of receiving one of their five champions is still uniformly random at 20% each.
The Real World
In the real world, this final solution doesn’t appear to be pragmatic. The process of calculating these weights might seem impractical for ten players with varying roster sizes, and without modification, it is. There were only four players in our toy example, and therefore 4! ways to order them. Once we move to 10 players, the number of orderings would exceed 3 million for each match, and we want to avoid iterating through that. However, there is a trick — as long as we carry out the weight calibration above, we only need to consider a single order; any order will work. As per the suggestion above, it could be pre-determined to order by pool size or completely random. Once we have frozen that order in place for any given match, we can make a single pass through it to calculate the weights and make a draw for the player. Remember how I mentioned earlier that it wasn’t worth it to do all the algebra for all possible states? This is why.
For example, let’s say that we pre-determined that the player with all ten champions was to roll second; how should we weigh their selections? Recall our earlier representation, but now replaced with the s and w variables:
For each column, we want the overall probability to be uniform, and for each row, we know we have to choose something. Putting it all together, we get these two formulas:
These can be simplified rather quickly, but I’ve written them out to help give some insight into the equations’ general form. First, note that (4s + 5w) is a normalizing factor across each row, which must be equal to one. In the first column, we can add up that there are four instances of s over five scenarios, and we need the overall probability for that champion to equal 10%. We can construct the same formula for w, but it is far less exciting. The solution:
Once again, we carry out similar calculations for if we were to draw third or fourth, with s being 1/6th and 1/4th in each of those situations and w remaining the same. These numbers should be reasonably intuitive. Suppose we want our chances of choosing a strong champion to be equivalent to a weak champion after a previous draw has taken one away. In that case, the remaining strong champions effectively need to consume the probability lost by the chosen champion from the first round.
Flipping Weights
A bonus solution would be to take our previous suggestion and flip it on its head. Instead of taking a player-centric focus for the draw, what if we took a champion-centric focus, weighting champions based on the number of times they show up across all players? In this setting, we could choose a champion and assign it to an account that owns the champion. In the next step, we would remove the additional weights that the player had on the selection process and pick the next champion. Overall, this is more intuitive to follow across multiple iterations, but it does have a few drawbacks.
- A similar weighting exercise is needed as the player-centric approach, albeit, on the surface, the math is less complex.
- The system is not currently designed to support this type of selection process. The other solutions accommodate the current setup and, therefore, would require minor modification.
Final Thoughts
Of course, we haven’t addressed additional caveats in this post, such as potential rerolls. These incur additional bias, and it may seem evident that a similar weighting mechanism that determines how quickly different players earn rerolls could alleviate this problem. I’m under the impression that the earn rate for rerolls is proportional to the number of champions one owns, but whether that is sufficient remains unexamined. Another topic for a future post, I suppose!
As for the initial champ select process, we can set up the system in a way that appears to be random, but when a “random” action is dependent on previous ones, a uniform random selection will not occur naturally. If we can figure out how these dependencies bias selections and compensate them accordingly, we can ensure that each player has an equal chance to receive each of their champions. Until then, those players who own Udyr (RIP) will most definitely be seeing him more often than should be expected. Although, perhaps this shortcoming is the lesser of two evils. After all, can you imagine trying to explain to players how a system that dynamically sets biased weights ensures that they aren’t screwed over and receive a “random” selection? Yeah, good luck…
P.S.: Once I stumbled upon the phenomenon of “roster-building” in ARAM, it was an open invitation for some ripe trolling. Poppy only costs 260 RP, and gifting her to budding ARAM-only accounts was a surefire way to lose a friend. At this time, it appears that Poppy is still not included in the list of free ARAM champions, so… you know what to do…
Note: All matrices and equations in this post have been created by the author.
