Fairness: what decides who you play against

This page exists because the alternative is asking players to take our word for it. It is published rather than kept internal, and it is written in the same place as the code it describes so that the two cannot drift apart: services/server/src/game/seeding.ts and services/server/src/meta/rating.ts are the whole implementation.

The promise

Matchmaking in Inktide is never optimised for engagement, and there is no losers' queue. Not now, not later.

That sentence is the point of the page, so it is worth being exact about what it rules out. We do not arrange a win to keep somebody playing. We do not arrange a loss to make a later win feel better. Nothing about who you are matched with is chosen from a model of whether you are about to stop playing.

What actually decides a lobby

Three things, in this order, and the order matters more than any of them:

1. Latency. One region today, so in practice this is free.
2. Time to match. A target of thirty to forty-five seconds. If skill matching and this target ever conflict, skill loses — the band is dropped rather than the wait extended.
3. Skill. A hidden rating, used to seed the lobbies that were going to be scheduled anyway.

This is Activision's published priority order, and we use it for the reason they published: a queue that puts skill first produces beautifully fair matches that nobody waited around for.

The rating

• OpenSkill, Plackett–Luce model, MIT licensed. It reads the whole finish order of a match at once rather than breaking it into pairs, because finishing third of twenty is evidence about nineteen relationships and a pairwise model throws that away.
• It is never shown to you. There is no screen in this game with your rating on it and there is no plan to add one. A visible rating turns every lost match into a number going down, and this game does not have punishments.
• Bots are not rated. Beating a bot is not evidence about a person.
• Private rooms are not ranked. Rooms are for friends; a room that moved ratings would let two people trade wins into a band neither could hold.

What you are shown, once you have played ten ranked matches, is a tier — a band of the population, like "top 10%". A percentile means the same thing at two hundred players and at twenty thousand, so it stays honest as the game grows without anybody retuning a threshold.

Your first three matches

A brand-new account is seeded into gentler lobbies for its first three matches: more bots, and slower ones, ramping back towards normal across the three. One win or two top-five finishes ends it early.

Nothing about this is hidden. The entry screen already says bots take the free seats. Results already label which rows were bots. We have never claimed a lobby was all-human and we are not going to start. That is the ordinary standard in this genre and it is the one worth keeping: Marvel Snap disguised its bots, players found out, and what it cost was not the bots — it was being lied to.

The reason the protected window exists at all is one measured number: the best placement somebody reaches in their first session is the strongest predictor available of whether they come back the next day. Activision measured the same effect from the other side — harder early matches cost fourteen-day return.

The bot mix

Bots are the fairness dial that costs no population. Splitting a small pool into two lobbies makes two half-empty lobbies; making bots gentler makes one lobby gentler and splits nobody. So the mix moves with the room — more and slower bots in a gentler lobby, fewer and faster in a stronger one — and humans displace bots exactly as they always have.

After three losses in a row

We know what the research says about this, and we deliberately do only half of what it suggests.

The EOMM paper found the effect: roughly three consecutive losses about doubles the chance a player does not come back. We accept that finding. Its proposed remedy is to arrange easier opponents, and we refuse that outright.

What happens instead is entirely outside the match:

• a one-off XP bonus, paid on your next match rather than the one that went badly, and
• a personal goal that does not depend on beating anybody — hold five per cent of the map — because a goal a bad night cannot take away is the only kind worth offering after one.

Your next lobby is chosen exactly as it would have been. That is the difference between helping somebody through a rough session and managing them through one.

This page binds our experiments too

We do run A/B tests. We test when to offer you an account, how big a daily quest should be, how long the newcomer protection above should last — questions where we genuinely do not know the answer and would rather measure than guess.

Matchmaking is not one of them, and it cannot become one. There is no bucket anywhere that changes who you play against, and there will not be one, because a promise that holds until an experiment is proposed is not a promise.

That is enforced rather than asserted. The scaffold refuses at startup to load any experiment whose name mentions matchmaking, fairness, seeding, rating or EOMM; and the two files named at the top of this page — the whole implementation — are prevented by a test from reading an experiment assignment at all. If somebody ever tries to make this page false, the build stops before the deploy does.

What we do vary is on the honest side of the same line. Protection depth changes how many bots a beginner meets in their first matches. It never changes which people are in the lobby, and a gentler bot mix takes nothing from anybody.

Why we are confident this is also the better business

It happens that the honest answer is the effective one. Activision's own experiment in loosening skill matching measurably hurt the return rate of the bottom ninety per cent of players — the fairness most people are asking for is the fairness that keeps most people playing. And the trust cost of being caught is not recoverable: it is the one asset in a multiplayer game that cannot be patched.

If you think this page is wrong

The code is in the open and the two files named at the top are the whole of it. If the behaviour you see does not match what is written here, that is a bug in one of the two and we would like to know which.