ARAM (or All Random All Mid) is a game mode in League of Legends in a 5v5 format on the Howling Abyss map. Two teams of five players each play against each other. In the game each player controls a single champion, which is chosen in the game lobby before the game starts. In this game mode players are given random champions from the available champion pool and are able to trade or reroll their picks.

When ARAM game lobby starts each player rolls a single champion. This champion is picked randomly from their own available champions. Players' rolls processed sequentially. Teams are blind to the picks of the opponents. Each champion in the game can only be rolled or rerolled into the game lobby at most once (across both teams).

Each player can store up to two reroll credits. A player can consume reroll credit to reroll his champion. Upon doing this he gets the new champion and the previous champion is placed into the team's Available Champion Pool (a.k.a. the Bench). Each team has their own bench. Any player can swap their champion with one from the bench if they own it or it is in Free champion rotation.

Each reroll credit is worth 250 reroll points (max 500 reroll points). Reroll points are awarded to each player after each game. Exact value is based on amount of owned champions (formula: 65 + 1.5 x available champions). Unused reroll points (reroll credits) are saved and carried to the next ARAM lobby.

Some assumptions of the model ordered by importance:

1. First of all, this model assumes that all available champions have equal probability to be rolled whenever roll or reroll happens.
2. All players have the same fixed set (or subset) of champions available. This allows to make all champions fungible and dismisses any aspects of champions popularity, champions availability, roll/reroll order. Amount of available champions is one of the model parameters.
3. In the real game players will prefer to pick favorite or strong champions. This is hard to formalize. In this model players will try to maximize the condition: all players will try to pick the most played champion or most played in a row champion (at the moment). Arguably, this is not how players behave in general, but this is definitely a valid formal strategy. Also most played champions are generally the most strong and the most popular. So we can say that players prefer to pick the same strong and the same favorite champions. For the first game in simulation players will have no preferences.
4. Players will not save rerolls for future games. All available rerolls will be used each game. All players have equal amount of reroll points generated per game (because they have the same amount of available champions). Amount of rerolls per game is one of the model parameters.
5. Rerolls per game can have a fractional value. In this case players will use whole number of rerolls and leftover reroll points will be carried to the next game. If there is more than one player in computation (team of 5 players), then amount of rerolls is computed as the sum of rerolls of involved players. You can think about it as the team's draft pool or bench size. This reroll sum gets truncated to nearest whole number and leftover part is carried to the next games. For example, with 1.5 rerolls per game total amount of rerolls for the team of 5 players will alternate between 7 and 8 every two games.
6. Players will not dodge games (prevent games from starting by leaving game lobby). Theoretically game dodges can be used as limitless source of pick improvement. Real players can use this to cancel some unlucky drafts.
7. Players will not grief each other and will always freely swap champions.

This model computes probability to "upgrade" champions through sequence of games, where each game provides draft pool of random champions and subset of these champions is taken into upgrade pool. Upgrading champion can have different means, most straightforward example is playing game with this champion. Size of draft pool and size of upgrade pool can vary. Upgrades can persist through whole computation (playing X times in total) or can be reset after single non-upgraded game (playing X times in a row).

List of model parameters:

1. total_games — total length of the game sequence to compute;
2. total_champions — total amount of champions that can be drafted;
3. target_streak — maximum number of upgrades that must be applied to a single champions to be counted as success;
4. draft_pool — size of the draft pool — number of randomly chosen champions that can be upgraded;
5. upgrade_pool — size of the upgrade pool — subset of drafted champions that will actually get an upgrade;
6. reset_on_failure — if true, amount of upgrades on a champion is reset to zero on non-upgraded game, otherwise number of upgrades persists.

We have to calculate probabilities over sequences of events, where current decisions are based on previous choices. Dynamic programming is the most straightforward way to do this. Model will process games in the sequence one by one, while keeping track of all possible situations (states) that can be reached after current game.

States will be grouped into layers by amount of games played. Number of games played can be referenced as implicit state argument. Model will keep only two layers: layer of the current game and layer of the next game.

Of course keeping information about each champion is too wasteful. Instead champions are grouped together by number of applied upgrades and size of each group is stored as a vector. This vector is the dynamic programming state argument. Dynamic programming state value is the probability to enter this state.

Dynamic programming transition is adding another game from current state. This is done recursively. At each recursion step single group of champions is considered, starting from the most upgraded ones. All possible ways to draft champions from this group are considered (all possible amounts). For all further steps this group is champions is discarded (both drafted and not drafted champions). When all groups of champions are considered transition state is finally complete. Transition is complete and probability is added to state on the next layer.

Number of states and transitions is still exponential, but the growth is capped by multiple parameters and optimizations. When a state gets targeted amount of upgrades on at least one champion, this probability is added to the result value and this state is not expanded further. When a state or a transition branch has probability close to zero it immediately stops and is not expanded further.

Transitions are calculated independently for each state.

Hypergeometric distribution is used to calculate probability split at each step of transition. At this stage all champions are split into champions of current group and all other champions. Given total amount of champions and size of current group, we want to compute probability that in equiprobably chosen subset of draft_pool champions there will be exactly X champions from current group. Hypergeometric distribution is used on each recursion step and coefficients are multiplied for each group in the state.

This model is consistent in ARAM champion select mechanics with LoL patch 12.17.1.

This document was last updated at 19 September 2022.