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
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
This can be achieved in several ways:
- your game server can make an API call to set its own status back to
- your matchmaker, when aware of game match progression, can make an API call and set the status of a game server back to
- 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:
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:
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).