Introduction

IVK Match is matchmaking as a service. A game backend submits a ticket when a player wants to play; IVK Match pools those tickets, forms matches, and delivers each match back to the game backend.

It works alongside the systems a game already has. Skill ratings, parties and latency measurements are passed in on each ticket, and the game backend provisions servers for the matches it receives, so existing skill, anti-cheat and hosting setups keep working unchanged.

What an integration involves

An integration has four parts:

1. Author a queue. A queue declares what kind of match to form: team sizes, how much skill spread is acceptable, latency budgets, which player attributes have to agree. This is configuration, not code.
2. Submit tickets. When a player presses Play, the game backend creates a ticket carrying that player’s or party’s skill ratings, measured latencies, and attributes.
3. Consume outcomes. When a match forms, IVK Match delivers it. The game backend receives the teams and the chosen host.
4. Act on the match. Provision a server, then tell the players where to connect.

Steps 2 and 3 are separate on purpose. Submitting a ticket does not return a match. The call returns as soon as the ticket is durably queued, and the match is pushed to the game backend later. A match is a multi-party event, so no single caller can wait for one.

Prerequisites

• A skill rating per player. IVK Match compares ratings but never computes or stores them. Any rating the game already uses works, as long as the queue’s parameters are on the same scale.
• Latency measurements per player, per host. These drive both the hard latency filter and host selection. When they use the host identifiers the provisioning layer already understands, the result needs no translation.
• A backend that can receive a push. Matches are delivered asynchronously.
• A game in the portal. Sign up on the free tier, create a game, and issue its credentials from the portal.

Where to go next

Core Concepts describes the model the rest of the documentation assumes: tickets, pools, ticks, matches, and outcomes. The Quickstart forms a match in five steps. Integration Flow covers the whole sequence, including the failure cases that need handling.