Game Mode Config Reference

The Game Modes page covers what each field is. This page goes deeper on how each one actually behaves at matchmaking time — useful when a match isn't forming the way you expect. Each algorithm has its own heading below so you can link directly to it (e.g. /docs/game-mode-config#mmr).

Match Shape

See Match Shape for the field itself. Two details worth knowing once you're configuring it:

• The number that counts against your tier's match size limit is the sum of the shape, not the number of teams — [2, 2, 2, 2] and [4, 4] both need 8 players, even though one has four teams and the other has two.
• Team assignment happens once a full-size group of players has already been found — how that group is split into teams depends on the algorithm, since only MMR and Ping have a value to balance on. See each algorithm's section below.

Cycle Duration

MatchmakingCycleDurationSeconds — how often, in seconds, the matchmaking loop attempts to form matches for this game mode. Each enabled game mode runs its own self-rescheduling loop: after a cycle finishes attempting matches against the current search pool, it waits this many seconds before running again.

• A shorter cycle forms matches sooner but does more work when the pool is quiet.
• A longer cycle is cheaper but adds latency between "enough players are available" and "a match is actually made."
• Your tier sets a floor (minCycleDurationSeconds) on how low this can go.

Parties

The Parties settings of a game mode:

• Allow parties — off by default. While off, a party that tries to search gets PARTIES_NOT_ENABLED.
• Max party size (MaxSize) — the largest party that may queue. It can't exceed the team layout: with Keep parties together on, a party must fit on one team, so it is capped by the largest team; with it off, by the whole match size.
• Keep parties together (KeepTogether) — see below.

Both settings are re-checked against the game mode's current Match Shape when a party searches, so shrinking a team layout later can't leave an oversized party stuck in the queue — it is refused with PARTY_TOO_LARGE instead.

How parties are matched

A party is matched as a single unit, and is never split across two matches:

• MMR: the party's value is the average of its members' MMR, and it needs to be within range of the other players in the group as a whole, like any other candidate.
• Ping: the party's value is its slowest member's ping, since a group is only as good as its worst connection. A party searching a ping-based game mode is measured member by member first — see Parties.
• FIFO: the party waits as long as its longest-waiting member, and joins a group in wait order like a solo player would.

A party is only considered once every member's search is in the queue. If one is missing, disconnected, or dropped, the party isn't matched short-handed.

Keep parties together

With Keep parties together on, a party always ends up on one team, so a match is only formed when every team can be filled exactly with whole parties and solo players. A 3v3 can be filled by two duos plus two solos (a duo and a solo on each side), but not by three duos, because no arrangement of three twos adds up to two teams of three. Those duos keep waiting until solos or other party sizes arrive that make an exact fit; the wait is not relaxed over time. Teams are balanced on the parties' average rank, subject to that constraint.

With it off, parties only share a match: the group is dealt out to teams exactly as for solo players, so a party may land on both sides.

Notification Webhook

Covered in full on Match Made — the URL (it must be a public https address), payload shape, retry/timeout behavior when a match is made, and how to verify the signature on each request.

Algorithm

Every game mode uses exactly one matching algorithm: MMR, Ping, or FIFO.

MMR

Four config values:

• Min MMR / Max MMR (minMmr / maxMmr) — the MMR range this game mode matches within. baseTolerance (below) is a percentage of maxMmr - minMmr, so the actual MMR delta a tolerance percentage translates to depends entirely on how wide this range is.

• Base Tolerance (baseTolerance) — a percentage (0-100) of maxMmr - minMmr: how much of the range is allowed as an MMR delta between two players the moment their search begins, before any waiting has happened. Your tier sets a floor on how low this can go.

• Expansion Multiplier (expansionMultiplier) — how much baseTolerance grows, as a multiple of itself, for every 10 seconds of wait time. Your tier sets a floor on how low this can go (it must always be at least 1 — tolerance never shrinks).

  A player's effective tolerance percentage, then effective range, is:

  tolerancePercent = baseTolerance + (expansionMultiplier - 1) * baseTolerance * (waitTimeSeconds / 10)
  effectiveRange = (tolerancePercent / 100) * (maxMmr - minMmr)
  

  waitTimeSeconds is computed continuously — the current time minus when that player's search started — so it keeps growing between cycles too, it isn't reset or stepped once per cycle. At waitTimeSeconds = 0, tolerancePercent is exactly baseTolerance; every 10 seconds of additional wait adds another (expansionMultiplier - 1) * baseTolerance percentage points. The 10-second window itself is a fixed platform constant, not something an individual game mode configures.

  For example, with minMmr = 0, maxMmr = 3000, baseTolerance = 5, expansionMultiplier = 2: at 0s the effective range is 5% * 3000 = 150; at 10s it's 10% * 3000 = 300; at 20s it's 15% * 3000 = 450.

Two players are only considered a match if the MMR delta between them is within both of their individual effective ranges — a player who has waited a long time (and so has a wide range) still can't be matched against a player who just joined and hasn't expanded yet, unless the newer player's own (narrower) range also covers the delta.

For a game mode whose Match Shape needs more than 2 players, groups are built starting from the longest-waiting unmatched player, so no one gets skipped over in favor of players who joined later. Every other player pulled into that group has to be within range of everyone already in it, not just the first player — so no one ever ends up matched outside their own configured tolerance to make up the numbers. If a group can't be completed yet, the players in it simply carry over to the next cycle rather than being placed in a worse match.

Once a full group is found, players are sorted by MMR and dealt out across the configured teams in an alternating (snake-draft) order, so each team ends up with a comparable total/average MMR — this still works for uneven team sizes like [1, 3].

Every player must have an mmr attribute set on their ticket to search an MMR-based game mode — see Generate a Ticket.

Ping

One config value:

• Max Delta (maxDelta) — the maximum ping difference (in milliseconds) allowed between two players for them to be considered a match.

Unlike MMR's tolerance, this is a flat threshold — it does not expand the longer a player waits. Grouping (for a Match Shape needing more than 2 players) and team assignment work exactly like MMR — the same mutual-range, first-fit heuristic and the same snake-drafted team split — just keyed on Ping instead of MMR.

Ping isn't supplied via the ticket. It can't be known in advance, so Pairiquium measures it live, per search attempt, directly against the player's connection — see Start a Search for what your client needs to handle.

FIFO

No config values — FIFO always groups the longest-waiting players first, with no closeness constraint of any kind.

A match forms as soon as enough players have accumulated at the front of the queue to fill the Match Shape's total player count. Because there's no skill or ping value to balance teams on, the group is shuffled and dealt out to teams randomly rather than snake-drafted.

Config changes and propagation delay