Introduction

IVK Match is matchmaking as a service. Your backend tells it who wants to play; it works out who should play together, and tells your backend the answer.

The division of labour

Get this straight first. It determines how much work the integration is.

IVK Match owns the waiting players, the matching decisions, and delivering the result. It holds a pool of everyone currently queued, runs an engine over that pool to assemble matches, and pushes each formed match to you.

You own everything about the players: identity, authentication, skill ratings, party membership, latency measurements, session state, game-server provisioning, and telling players what happened. IVK Match knows nothing about a player except what you put in the ticket, and it never talks to a game client.

So it is not a drop-in matchmaking system. It is the matching decision on its own, offered as a service. You supply the inputs and act on the outputs. That is what keeps it out of the way of your skill system, your anti-cheat, and your hosting.

What an integration involves

Four pieces of work, none of them large:

1. Author a queue. A queue declares what kind of match you want: 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, your 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. Your 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 arrives later, pushed to you. A match is a multi-party event, so no single caller can sit and wait for one.

What you need before starting

• A skill rating per player. IVK Match compares ratings but never computes or stores them. Whatever number your game already uses is fine, 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. Use the same host identifiers your provisioning layer already understands and the result comes back ready to use.
• A backend that can receive a push. Matches are delivered to you 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

Read Core Concepts for the model the rest of the documentation assumes: tickets, pools, ticks, matches, and outcomes. If you would rather see it work first, the Quickstart gets a match formed in five steps. Then Integration Flow walks the whole sequence, including the failure cases that need handling.