The conclusion first

A solo player faces a ten-person combinatorial optimisation. The system must turn ten strangers into two temporary teams while balancing hidden rating, roles, hero preferences, network latency, wait time and the likelihood that each player will keep playing.

The central difficulty in solo queue is therefore not whether the system can estimate your personal skill. The harder question is what happens when five people who have never played together are put on the same team.

From the player’s side, four responses matter most:

  1. Keep your role and hero pool stable to reduce variation in your own performance.
  2. In solo queue, favour familiar heroes that can clear waves, survive independently and convert resources.
  3. Take fewer risks in a difficult match. Do not try to prove yourself with one high-risk play.
  4. Set a stopping rule before you queue. Do not let wins and losses decide how long you play or how much you spend that day.

None of these measures can crack the matchmaking system. They can reduce the losses produced when estimation error, random teammates and personal emotion compound one another.

This is one sequel to Who Is the System Optimising?. The previous essay set out the general framework: if a game company’s primary goal is long-term profit, fairness still matters, but more as a constraint that preserves trust and retention. This essay asks a narrower question. What does a solo player face under such a mechanism, and what can they do about it?

The solo-queue system must first guess who you are

The system cannot observe ‘true skill.’ It can only maintain a probabilistic estimate from past records:

\[ P(x_i\mid H_i) \]

Here, \(x_i\) is the system’s estimate of player \(i\)’s current state, and \(H_i\) is that player’s history. The state may include skill, role proficiency, frequently used heroes, recent performance, uncertainty and the risk of quitting.

After every match, the system receives new outcome and behavioural data, then performs a Bayesian update:

\[ P(x_i\mid H_i,D_i) \propto P(D_i\mid x_i)P(x_i\mid H_i) \]

TrueSkill estimates an individual’s skill and the system’s confidence in that estimate. Dynamic K controls how much one result changes the rating. PCA can compress a large set of data on gold, team-fight participation, towers, roles and heroes into a smaller number of behavioural features.

A hidden rating may therefore be more than one number. The system is more likely to maintain a multidimensional profile. A player who is an excellent jungler is not necessarily an equally good support. Someone may be stable on a familiar hero and highly variable after switching to an unfamiliar one.

The implication for players is direct. Constantly changing roles or practising a new hero in ranked play increases both the system’s estimation error and your own execution error.

Five similar players do not necessarily form similar teams

The effective strength of a solo-queue team can be simplified as:

\[ R_A= \frac{1}{5}\sum_{i=1}^{5}\mu_i +\chi_{role} +\chi_{hero} -\rho D_A +\varepsilon_A \]

\(\mu_i\) is the hidden rating of each of the five players, \(\chi_{role}\) measures role fit, \(\chi_{hero}\) measures hero and composition fit, \(D_A\) is the skill gap within the team, and \(\varepsilon_A\) is the error introduced by improvised coordination.

The system may give the two teams almost identical average hidden ratings and still be unable to know these things in advance:

A GNN can learn relations from previous parties, friendships and matches, but most temporary relations in solo queue have too little history. Knowing how each player performed in the past is not the same as knowing how these five will cooperate today.

That is why a solo match can look even before the start and become one-sided in play. It does not necessarily mean the system decided the result in advance. The temporary composition and the decisions made in the first few minutes can rapidly rewrite a pre-match 50 per cent.

How a profit-first objective changes solo queue

If fairness were the only objective, the system would need only to find two teams of nearly equal strength.

If profit and retention come first, the score assigned to a candidate match may look more like this:

\[ U(M)= \alpha Retention(M) +\beta Value(M) +\gamma Quality(M) -\lambda Wait(M) \]

EOMM estimates whether a match will keep players in the game. Survival analysis estimates when they may leave. Information entropy measures how uncertain the outcome is. MIQP or another combinatorial optimisation method selects ten players under constraints such as rank, role, latency and wait time.

The Handicap discussed in the video could add a further bias to win probability, but it is not an established standard mechanism. Minimax is better suited to prediction error, composition counters and worst-case outcomes. Neither method by itself proves that the system deliberately makes one player miserable.

One fact is easy to miss: the system need not create a guaranteed loss. Choosing, among several acceptable matches, the one that best serves retention already changes the win probability and emotion a player may experience next.

A reliably active player also faces an uncomfortable implication. If the model predicts that this person will keep playing after a loss, the marginal value of protecting them for one match may be low. The system may reserve a more restorative experience for someone close to leaving.

That is a direction implied by a profit-first model, not a discovered Tencent rule. The opposite direction is possible too. Losing a high-value player may be more costly, so the system may protect that player first. What determines the direction is the future value added by an intervention, not how much the player spent in the past.

The position of a solo player

1. Your teammates are a risk selected for you by the system

A solo player controls only their own role, hero and execution. The system selects the skill, mood and willingness to cooperate of the other four people.

This makes temporary mismatch more likely in solo queue than in a fixed five-stack. Similar individual hidden ratings cannot guarantee complementary hero pools or decision styles.

2. Balance predicted by the system is not balance felt by the player

Information entropy is highest when predicted win probability is near 50 per cent, but only if the probability model is accurate. If it underestimates a signature hero, a role conflict or a player’s condition that day, it may still return 50 per cent while the match quickly loses balance.

A fifty-fifty prediction means only that the pre-match model found the outcome difficult to predict. It does not guarantee an equally comfortable process for both teams or an equal burden on every player.

3. Matches can become harder after a win streak without an extra punishment mechanism

A run of wins lets the hidden rating catch up with your current performance. Opponents naturally become stronger and the win rate falls back. An exceptional streak may also combine good form with luck, followed by regression towards the mean.

The size of the queue, role requirements and latency limits may leave the system with only a locally optimal combination. These factors are enough to make matches feel suddenly harder after a streak. The feeling alone does not prove that Handicap exists.

4. The easiest behaviour for the system to exploit is immediately queueing again

After a solo-queue loss, players often feel a clear impulse: I must win it back at once.

If EOMM and churn models enter the objective function, that response is the easiest signal for the system to learn. A player who keeps queueing no matter how often they lose contributes play time without needing extra protection.

How solo players can respond

Decide when to stop before entering ranked play

Do not wait for a loss to decide whether to continue. Before the first match, set a maximum number for the day. Stop after two consecutive losses. Stop after reaching the day’s goal as well. Do not add a supposed recovery match on the fly.

This is not meant to reset your hidden rating. It breaks the feedback loop from loss, to immediate requeue, to worse form, to another loss.

Keep one role and a small hero pool

Use only heroes you genuinely know in ranked play. Prepare one main role and one fallback. Practise new heroes in training or casual modes.

Bayesian ratings update continuously from new data. Stable roles and heroes reduce the noise in each match. They help the system recognise your actual level more quickly and help you know what you can still do when behind.

Choose heroes that can solve problems independently

In solo queue, you cannot assume that teammates will follow a plan. A hero should ideally be able to clear waves, survive to some degree, defend a tower while behind, and turn a won fight into a tower or another resource.

Heroes that depend entirely on teammates to create a safe damage window are still playable, but they hand a larger part of your win probability to strangers.

Identify early which teammates are worth coordinating with

Solo queue has no appointed shot-caller. In the first few minutes, observe who responds to signals, which lane truly has an advantage, and who has clearly lost the tempo.

Build a numbers advantage around a reliable teammate. Do not pour resources without limit into a lane that keeps making mistakes. This is not abandoning a teammate. It is preventing one local disadvantage from spreading across the map.

Reduce risk deliberately in a difficult match

When the composition is poor or the opening goes badly, the most dangerous response is trying to prove yourself with one risky play. Manage the waves first. Avoid meaningless deaths. After winning a team fight, take a tower or objective immediately. Mute arguments and do not spend attention on what you cannot change.

A low win probability is not a guaranteed loss. Reduce variance and you can bring an unfavourable match back into playable range.

If the queue is unusually long, play at another time

A wait far longer than usual suggests that the system may lack enough suitable candidates. Cancelling and returning when more players are online is more sensible than accepting a combination likely to be mismatched in both role and skill.

Do not try to deceive the system with KDA

If the system uses multidimensional behavioural features, preserving KDA alone is unlikely to change its overall judgement. Refusing team fights to avoid deaths, farming the jungle after a won fight, and ignoring waves and towers all reduce the probability of winning.

You cannot know exactly how the system evaluates you. Destroying the enemy crystal remains a definite win condition.

Separate spending from results

Do not top up, draw loot or buy a skin after a losing streak to compensate for the emotion. Set a budget in advance and buy only what you had already planned to buy.

There is no public answer on whether spending enters matchmaking. Separating purchases from the day’s results prevents the platform from earning extra revenue from frustration, whatever the real algorithm may be.

The most important principle in solo queue

A solo player cannot choose four teammates or know the retention score assigned to each candidate match. What the player can control is their own variance, and whether one result changes the rest of their time and spending.

Keep roles and heroes stable. Take fewer risks in difficult matches. Set the stopping rule before queueing. These measures do not disable the system, but they reduce the behavioural space it can exploit.

This essay uses a technically feasible unified model. It does not disclose Tencent’s backend code. TrueSkill, EOMM, PCA, GNN, survival analysis and combinatorial optimisation are real methods, but there is still no public evidence that Honor of Kings runs them together in this way. That boundary does not weaken the measures above, because they work under both fairness-first and profit-first systems.