Overview
Lifecycle methods control the state transitions of your game server within the Agones system. These methods are part of the stable SDK service (agones.dev.sdk.SDK).
State Diagram
Ready
Signals that the game server is ready to accept player connections and can be allocated.When to Call
CallReady() when your game server has:
- Loaded all required assets and configurations
- Initialized networking and listening on game ports
- Completed any warm-up or pre-caching operations
- Is ready to accept player connections immediately after allocation
Behavior
Transitions the game server fromRequestReady state to Ready state, making it available for allocation via the Allocation API or Fleet autoscaling.
Request
No parameters required.
Response
Returns empty on success.
Example Usage
Allocate
Performs self-allocation, moving the game server to theAllocated state without going through the Allocation API.
When to Call
Use self-allocation when:- Implementing custom matchmaking within the game server
- Testing allocation behavior
- Creating lobby servers that self-allocate when players join
Behavior
Transitions the game server fromReady state to Allocated state. The server will not be allocated by the Allocation API after this call.
Request
No parameters required.
Response
Returns empty on success.
Example Usage
Shutdown
Signals that the game server is shutting down and should be terminated. This releases the game server resources back to the cluster.When to Call
CallShutdown() when:
- A game match has completed
- All players have disconnected
- A fatal error occurs that prevents normal operation
- The server has been idle for too long (custom logic)
Behavior
Transitions the game server toShutdown state. Kubernetes will then terminate the Pod, typically within 30 seconds (grace period).
Request
No parameters required.
Response
Returns empty on success.
Example Usage
Reserve
Marks the game server as reserved for a specific duration, preventing it from being allocated by the Allocation API.When to Call
Use reservations for:- Holding a server during matchmaking while finalizing player selection
- Implementing custom allocation logic with time-bounded holds
- Creating lobbies that need temporary protection from allocation
Behavior
Transitions the game server toReserved state for the specified duration. After the duration expires, the server returns to Ready state automatically.
Reservations can be extended by calling
Reserve() again before expiration. Each call resets the timer.Request
Duration in seconds to reserve the game server. Must be a positive integer.
Response
Returns empty on success.
Example Usage
GetGameServer
Retrieves the current state of the game server.When to Call
Retrieve game server state to:- Check current metadata (labels, annotations)
- Read configuration from spec
- Inspect current status (state, ports, addresses)
- Access player tracking or counter/list data
Request
No parameters required.
Response
Kubernetes object metadata.
Game server specification.
Current game server status.
Example Usage
WatchGameServer
Streams game server updates whenever the game server resource changes.When to Call
Use watch to:- React to state changes (e.g., allocation)
- Monitor metadata updates from external sources
- Track counter and list changes made via the Allocation API
- Implement event-driven game server logic
Behavior
Opens a server-streaming connection that sends aGameServer message whenever the game server resource is updated in Kubernetes.
Request
No parameters required.
Response
Stream of game server updates. Each message contains the full game server state (same structure as
GetGameServer).