Skip to content

Matchmaker Allocation

Games that have a matchmaker in their back end will normally want to know to which game server they can send players waiting for a new match.

Your matchmaker can request free game servers with a simple API call. We call this process: allocation of a game server.

When making an allocation request, you can request one or more game servers for a specific application or application build, hosted in a specific region, fleet and / or DC location. You can be as exact as you need to be in case your matchmaker is aware of all the individual locations. This helps sending game clients to the closest and best performing locations [for that client].

Game server allocation

When you allocate a game server, its status will be set to Allocated (5). This indicates to the system that the game server is now in use and it cannot be allocated again until its status has been reset to Online (4).

Bare Metal before VM

Unless you perform an allocation request with an explicit filter to allocate a game server on a VM, our platform will always prioritize allocations on a Bare Metal before allocating game servers on a VM.

Game server de-allocation

When the match of a game server is over, the operational status of said game server needs to be updated to indicate it is free again for other clients to join. It can then be allocated again by your matchmaker for other clients to join and start a match. For this to be possible, the status of the game server needs to be changed from Allocated (5) to Online (4).

This can be achieved in several ways:

  • your game server can make an API call to set its own status back to Online (4)
  • your matchmaker, when aware of game match progression, can make an API call and set the status of a game server back to Online (4)
  • your game server can shut itself down after a match. Our platform will automatically restart it with the result that the game server's status will automatically be set to a correct value again

Matchmaking process flow example

This example illustrates a typical matchmaker allocation process:

Figure 1: Matchmaker allocation process

Metadata

Our platform has a mechanism in place that allows your backend to send custom data (metadata) to game servers in the form of key / value pairs. This mechanism has primarily been created to reconfigure game servers during allocation, based on what kind of map it should run. But you can use metadata in any way you see fit.

Your matchmaker would collect game clients and then allocate (request and reserve) a game server by doing an allocation call towards the i3D.net API. During the allocation call the matchmaker can send metadata along which will be stored for the allocated game server(s). This same metadata can then be forwarded to the same game server(s), which in turn can react to the metadata and e.g. load another map, or change game mode.

Matchmaking with metadata process flow example

This example illustrates a typical matchmaker allocation process whereby metadata is sent to game servers:

Figure 2: Matchmaker allocation process with metadata

Requirements for metadata usage

In order for the platform to send metadata to your game servers, they need to have the Arcus protocol implemented. This is currently the only game server management protocol that has a mechanism for receiving metadata (that we know of).

If your game already supports a way to receive (custom) information similar to the metadata described here, and you would like our platform to be compatible with that, please contact us and we may be able to support your management protocol (or variation of an already supported one).