With some matchmakers and game matching strategies, it can be important for game servers to mark themselves as Allocated. For those scenarios, this SDK functionality exists.

There is a chance that GameServer does not actually become Allocated after this call. Please refer to the general note in Function Reference above.

This returns most of the backing GameServer configuration and Status. This can be useful for instances where you may want to know Health check configuration, or the IP and Port the GameServer is currently allocated to.

The easiest way to see what is exposed, is to check the sdk.proto , specifically at the message GameServer.

This tells Agones that the Game Server is ready to take player connections. Once a Game Server has specified that it is Ready, then the Kubernetes GameServer record will be moved to the Ready state, and the details for its public address and connection port will be populated.

While Agones prefers that shutdown() is run once a game has completed to delete the GameServer instance, if you want or need to move an Allocated GameServer back to Ready to be reused, you can call this SDK method again to do this.

With some matchmaking scenarios and systems it is important to be able to ensure that a GameServer is unable to be deleted, but doesn’t trigger a FleetAutoscaler scale up. This is where reserve(seconds) is useful.

reserve(seconds) will move the GameServer into the Reserved state for the specified number of seconds, and then it will be moved back to Ready state. While in Reserved state, the GameServer will not be deleted on scale down or Fleet update, and also it could not be Allocated using GameServerAllocation.

This is often used when a game server process must register itself with an external system, such as a matchmaker, that requires it to designate itself as available for a game session for a certain period. Once a game session has started, it should call allocate() to designate that players are currently active on it.

Calling other state changing SDK commands such as ready or allocate will turn off the timer to reset the GameServer back to the Ready state or to promote it to an Allocated state accordingly.

This will set a Annotation value on the backing Gameserver record that is stored in Kubernetes. To maintain isolation, the key value is automatically prefixed with “agones.dev/sdk-”.

This can be useful if you want information from your running game server process to be observable through the Kubernetes API.

This will set a Label value on the backing GameServer record that is stored in Kubernetes. To maintain isolation, the key value is automatically prefixed with “agones.dev/sdk-”.

This can be useful if you want information from your running game server process to be observable or searchable through the Kubernetes API.

This tells Agones to shut down the currently running game server. The GameServer state will be set Shutdown and the backing Pod will be deleted, if they have not shut themselves down already.

This executes the passed in callback with the current GameServer details whenever the underlying GameServer configuration is updated. This can be useful to track GameServer > Status > State changes, metadata changes, such as labels and annotations, and more.

In combination with this SDK, manipulating Annotations and Labels can also be a useful way to communicate information through to running game server processes from outside those processes. This is especially useful when combined with GameServerAllocation applied metadata.

The easiest way to see what is exposed, is to check the sdk.proto , specifically at the message GameServer.