Elo Ratings Break Down in 1v1 Games — What Goes Wrong and How to Fix It

Elo-style ratings feel universal. Chess uses them. Coding contests use them. So when you ship a 1v1 quiz product, copying a contest rating formula seems like the obvious move.

It is not.

Large-field contests and two-player matches are different statistical animals. An algorithm that is well-behaved at n = 1000 can produce absurd rating swings at n = 2.

This post is about that mismatch: how seed-based contest rating works, what goes wrong in a pure 1v1 setting, and the techniques that keep updates bounded and intuitive — without pasting any production calculator code.

What Elo is trying to do

At the core, Elo (and its contest cousins) does one thing:

Move ratings so that outcomes surprise the model less next time.

If a much stronger player wins, almost nothing should change. If a much weaker player wins, ratings should move a lot.

The pairwise win probability is usually a logistic of the rating gap:

P(A beats B) ≈ 1 / (1 + 10^((R_B - R_A) / S))

S is a scale constant. Classic chess Elo often uses S = 400. That choice is not cosmetic — it controls how “far apart” two ratings feel.

A common intuition (paraphrasing contest writeups):

• rating gap ≈ 200 → stronger player wins ~75% of the time
• rating gap ≈ 400 → stronger player wins ~90% of the time

If your product’s ratings live on a wider numeric range (say thousands of points between casual and elite), you may need a larger S, otherwise tiny gaps look like landslides and expected ranks collapse toward extremes.

How large contests typically do it

Coding platforms with big contests often use a seed / expected rank approach (the Codeforces-style family is a well-known reference).

Rough pipeline for a contest of many players:

1. Pairwise probabilities from rating differences
2. For each player, sum “probability of finishing below others”
3. That sum + 1 becomes the player’s seed (expected place)
4. After the contest, compare seed to actual rank
5. Blend them (often a geometric mean) into a mean rank
6. Find a rating whose seed against the field would match that mean rank
7. Move the player partway toward that rating
8. Normalize deltas so the contest does not inflate or deflate the whole pool (e.g. keep top players’ total rating roughly stable)

That last step matters in large fields. You can afford soft global corrections because many players share the mass.

Where 1v1 breaks the story

In a two-player match, the “field” is just A and B. Several contest assumptions quietly fail.

1) Introducing a phantom contestant

Some contest algorithms, when searching for “what rating would produce this mean rank,” evaluate seeds by imagining a third rating placed into the pool.

With hundreds of players, one phantom is noise. With two players, that phantom dominates the search. The rating you “need” for a mean rank can jump to the ceiling or floor of your allowed range — even when intuition says the update should be modest.

Symptom in practice: underdogs who win once can vault thousands of points; favorites who lose once can crater. Tables of edge cases (favorite vs huge underdog, near-equals, both near minimum rating) make this painfully obvious.

2) Seeds collapse to extremes

With only one opponent, expected ranks are basically:

• near 1 if you are much stronger
• near 2 if you are much weaker

There is no soft middle of a large field. Mean ranks therefore sit near the corners unless the players are close. Binary search for “rating that matches mean rank” then amplifies any numerical quirk.

3) Zero-sum normalization is fragile at n=2

Contest systems often adjust deltas so a cohort’s ratings sum to zero change (or nearly zero). At n = 2, “normalize the top 4√n players” and “normalize everyone” are almost the same operation — and a single bad pair of raw deltas becomes a huge equal-and-opposite transfer.

4) Winner / loser sign bugs

If your formula is not carefully constrained, you can get nonsense like:

• winner’s delta negative
• loser’s delta positive

In large contests that is rare enough to miss. In 1v1 it is a product bug users will screenshot.

5) Scale constant mismatch

If you keep chess’s S = 400 but your rating ladder spans thousands of points, near-equals may still look like mismatches, or large gaps may look unwinnable. For 1v1 products that want ~50/50 when ratings are “a band apart,” you often need to widen S.

Techniques that fix 1v1 without throwing Elo away

You do not need a brand-new theory of skill. You need a model whose assumptions match two players.

Technique A — Stop inventing a third player

When searching for the rating that matches a target seed / mean rank for A, evaluate A’s seed only against B’s real rating (and symmetrically for B). Do not inject a hypothetical contestant into a two-person pool.

That alone removes a large class of explosions from the contest-port.

Technique B — Collapse to classic 1v1 Elo

For pure 1v1, the contest pipeline is overkill. The clean form is:

E_A = expected score of A vs B   // from rating gap
S_A = 1 if A wins, 0 if A loses
Δ_A = K * (S_A - E_A)
Δ_B = -Δ_A                     // or compute symmetrically

In seed language, you can think of expected place vs actual place and scale by K. Same idea: surprise × sensitivity.

Why this helps:

• updates are bounded by K
• favorites who win move almost nothing
• underdogs who win move up to roughly K
• no phantom contestant, no giant binary-search surface over the field

K becomes a product knob: early / volatile ladder → larger K; mature ladder → smaller K.

Technique C — Clamp and guardrails

Even with a sane formula, ship explicit guards:

• winner delta must be ≥ a small positive floor (or ≥ 0)
• loser delta must be ≤ a small negative ceiling (or ≤ 0)
• clamp final rating into [minRating, maxRating]
• optionally cap |Δ| harder for brand-new accounts vs veterans

These are not theoretical purity. They are what stop one weird match from breaking leaderboards.

Technique D — Retune the probability scale

If equal-looking players on your ladder still have extreme expected scores, increase S in:

10^(ΔR / S)

You are telling the model: “a 1000-point gap on our ladder is not the same as a 1000-point gap on chess.” Contest platforms that copy S = 400 without checking this often feel “sticky” or “explosive” for the wrong reasons.

Technique E — Version the calculator

Rating systems are product logic. Treat them like APIs:

• v1: contest-port (large-n assumptions)
• v2: 1v1 Elo-style deltas
• v3: even simpler fixed ±change for early experiments / A/B

Ship behind a version flag. Recompute or migrate carefully. Do not silently change history.

A worked intuition (no production code)

Suppose A is rated far above B.

Contest-port with a phantom third player can do the opposite of “tiny” on the first row and the opposite of “meaningful but bounded” on the second.

1v1 Elo with a sensible K and S does the first table by construction.

Near-equals should move medium amounts either way. If your near-equals barely move, K is too small or S is too large. If they yo-yo every match, K is too large.

What I would recommend for a 1v1 product

1. Do not blindly port a multiplayer contest rating formula to head-to-head matches.
2. Prefer classic 1v1 Elo (expected score vs actual score × K) as the default.
3. If you keep seed/mean-rank language for consistency with contest literature, evaluate seeds only against the real opponent.
4. Add sign guards and rating clamps before you ship to users.
5. Retune S and K on your ladder, not chess’s defaults.
6. Version the calculator so you can iterate without rewriting history in place.

Closing

Elo is not broken. The context is.

Large contests need expected place against a crowd, soft global normalization, and careful handling of a wide field. Two-player games need pairwise expectation, bounded surprise updates, and almost no machinery that assumes n >> 2.

The failure mode is subtle: the math still “runs,” ratings still update, dashboards still look green — until one upset mints an accidental grandmaster, or a favorite loses and the loser gains points.

If you are rating a 1v1 product, start from the two-player model. Borrow contest ideas for intuition. Do not borrow their edge-case assumptions.