Introducing PingCore Matchmaking: From Queue to a Warm Game Server

Today, we are launching PingCore Matchmaking: a new way for studios to move players from a queue to live game-server capacity without building a separate allocation layer.

Studios can use PingCore to form matches from player and party tickets, or keep the matchmaker they already operate. In either case, PingCore takes responsibility for the next operational step: finding eligible capacity, reserving it safely, sending the match context to the server and returning the IP and port players need to connect.

That connection between matchmaking and the server fleet is the important part. A roster is not yet a running session.

Why matchmaking became a Gamescom infrastructure story

Matchmaking was not always the headline on the Gamescom 2026 stage, but it sat underneath much of the multiplayer conversation.

The event reflected how broad online play has become. Studios are building competitive modes, drop-in co-op, private parties, ranked queues, cross-platform sessions and experiences that move between public and persistent play. Each format has different ideas about who belongs together, how quickly a match should form and what counts as a good connection.

That creates a more complicated balancing act than simply filling a lobby.

A matchmaker may need to consider skill, party size, roles, playlist, platform, game version and region. It may have to protect an existing group while finding the remaining players, relax its rules when a queue becomes quiet or keep competitive players away from a server location that would create an unfair latency split.

But even a well-formed match can still fail at the handoff. The players may be compatible while the selected server is full, on the wrong build, too far away or no longer ready by the time they connect.

Gamescom’s multiplayer focus made that wider point difficult to ignore: matchmaking quality depends on what happens after the queue as much as what happens inside it.

Forming the match is only half the job

Many matchmaking systems finish by returning a roster and a match identifier. The studio must then connect that result to the live game-server fleet.

The simplest implementation is often a read-select-write flow: fetch a server list, choose an instance that appears to have room and direct the players towards it. That approach becomes fragile under real demand.

Two matchmaking workers can see the same available slot before either reserves it. A server can change state between selection and connection. A request can time out after succeeding, leaving the caller unsure whether it is safe to try again. If the game server receives no information about the incoming session, it may also have to reconstruct the roster and mode after players begin arriving.

PingCore Matchmaking treats allocation as a transaction rather than a server-list lookup.

When an allocation succeeds, PingCore claims capacity atomically on an eligible warm server, delivers the roster and match context, and returns the connection address to the trusted backend. If the same request is retried with the same idempotency key, the original result is returned instead of creating a second reservation.

An allocation that is not confirmed releases automatically after 60 seconds. If there is no suitable capacity, the API returns no_capacity, allowing the caller to back off and retry without double-booking a server.

Use PingCore’s matchmaker—or bring your own

Different games need different matching rules, so PingCore does not force every studio into the same queue model.

Teams that want a straightforward starting point can use the built-in ticket service. Tickets carry the queue, required session size, party size and relevant filters. PingCore’s matching loop groups compatible tickets, allocates the session and returns the connection result.

Party size and session size remain separate. A group can stay together while the queue fills the remaining places, rather than being split simply to satisfy a target player count.

Studios with an existing matchmaker can call the allocation API directly. That includes teams with custom skill calculations, role composition, tournament rules, lobby logic or social systems that should remain part of the game’s own backend.

Both approaches use the same public allocation path. PingCore’s built-in matchmaker does not rely on a private capability that external matchmaking systems cannot access.

The game decides who should play together. PingCore handles where that group should play.

From queue to connection

The end-to-end flow is deliberately small.

First, the game submits tickets to PingCore or forms the roster in its own trusted service. Matching logic can account for the game’s product rules without exposing allocation privileges to the client.

Next, a single allocation request claims room on an eligible server. The request can filter by location, exact game version and server metadata, preventing a match from landing on an incompatible build or in the wrong region.

The allocation can also carry context such as the roster, game mode, map, queue or tournament identifier. That context reaches the game server before players connect, giving it time to prepare the correct session.

Finally, the calling backend receives the server ID, IP and port and passes the connection details to the approved players.

The game server can read its allocation through an Agones-compatible local SDK or PingCore’s lightweight native session endpoints. RCON occupancy polling is available for live player counts when modifying the game server is not practical. Once a session finishes, the server can return to a ready state for another match.

Safe retries and clear ownership

Allocation happens at exactly the point where queueing, fleet state and player connections meet. Small failures at that boundary can create confusing player-facing problems, so the workflow needs clear ownership.

Atomic claims prevent two callers from reserving the same final slot. Idempotency keys make uncertain requests safe to retry. Automatic expiry returns abandoned capacity to the fleet. Delivering match context before connection gives the server an authoritative expectation of who is arriving and why.

These are not visible matchmaking features in the traditional sense, but they protect the experience the player does see: pressing “find match” and reaching a working session without being sent to a full, stale or incompatible server.

Warm capacity that responds to the queue

Reliable allocation still depends on having a server ready when the match forms.

Each PingCore fleet location can maintain a configurable buffer of warm game servers. As sessions consume that buffer, autoscaling restores it. This reduces the chance that a completed match has to wait for a new game-server process to start before its players can connect.

Matchmaking demand can also help the fleet prepare earlier. If a queue is growing or an event is approaching, a trusted service can publish a desired-ready-server hint. PingCore can begin adding capacity while players are still being grouped rather than reacting only after the warm buffer has been exhausted.

Those hints expire automatically. When demand falls, the fleet returns to its normal buffer instead of staying pinned to an old forecast. Scale-down targets idle servers and rechecks their live state before removal so an active match is not interrupted to meet a capacity target.

This is especially useful around launches, network tests, promotions and post-show traffic. Queue pressure becomes an operational signal instead of a problem the infrastructure discovers too late.

Built on the same live state as Discovery

PingCore Matchmaking operates on the same fleet state used by PingCore Discovery.

Fleet deployments connect to Discovery automatically, and the live server list can be used with or without matchmaking. Allocation works against the same view of server identity, lifecycle and availability, avoiding a situation where discovery believes a server is ready while a separate placement system believes something different.

There is a deliberate boundary. Matchmaking allocates fleet servers deployed through PingCore. Externally hosted servers can still publish themselves through Discovery heartbeats and appear in public server listings, but they are not allocation targets.

Keep allocation in the backend

Tickets, allocations and capacity hints are trusted backend operations, not game-client capabilities.

PingCore separates them with scoped tokens. An allocation token belongs in the service responsible for forming or directing matches. Fleet heartbeat credentials can publish and read live server state but cannot reserve capacity. Tokens can be rotated or revoked independently.

That separation is particularly important for competitive games. A client should not be able to reserve infrastructure, select a favourable server or submit an authoritative roster merely because it can observe the game’s network traffic.

Matchmaking with the servers included

The rules for forming a good match will always depend on the game. Some titles prioritise skill. Others care more about party composition, social intent, mission progress or returning players to the same world.

PingCore does not try to replace those product decisions. It provides the infrastructure step that follows them: claim real capacity, prepare the server, return a connection and keep the warm fleet aligned with demand.

PingCore Matchmaking is available now. Studios can begin with built-in ticket queues and move to custom logic later, or connect an existing matchmaking service to the allocation API from day one.

Create a fleet, issue a scoped allocation token and put the next match on a warm server.