AccelByte Multiplayer Servers (AMS) is a dynamic dedicated game server manager that enables you to serve dedicated game servers as close to your players as possible. AMS allows you to have multiple fleets of servers, each with their preferences on AccelByte instance type and their own scaling behavior, that can be spread across different regions.
AMS allows you to take advantage of several features designed to ensure your players have the best gaming experience, such as:
- Easy to integrate: AMS has been designed to stay out of the way of your regular server development. By using the AccelByte Server SDK, you will only need to call one API explicitly to make AMS work for you.
- Multi-region: AMS has been designed for global coverage. With AMS, you can maintain a separate server fleet size per region, allowing you to save costs by adjusting the fleet size according to your regional demand.
- Elastic demand-based scaling: AMS scales based on your players' demand per region at any specific time. This ensures your host machine cost in the region is minimized when it has less demand while ensuring that there are always resources available when the region is at peak capacity.
- Warmed dedicated servers: AMS enables you to preload and maintain a healthy amount of warmed (up and running) dedicated servers for each region so that they can be claimed immediately by a game session without the need for its players to wait for a server to load.
- Integrated matchmaking and lobby with AGS: AMS connects directly with AccelByte Gaming Services (AGS) Matchmaking and Lobby services to provide geolocation support, so you can match players in the same region for an optimal player experience.
How does AMS dedicated server management work?
The following is a summary of the process to make dedicated servers available in your service regions:
- Integrate your dedicated server with the AccelByte SDK. See Integrate dedicated servers with the SDK.
- Upload your dedicated server build onto AMS using the AMS CLI. See Upload a dedidcated server build using AMS CLI.
- Create and configure fleets on the AccelByte Gaming Services (AGS) Admin Portal to your desired location. Then, activate your fleet. See Create a fleet to manage dedicated server allocation.
- The Fleet Commander is your representative to the AMS multitenant environment, so it makes virtual machine requests on your behalf.
- The virtual machine requests are handled by the AMS core multiregional orchestrator to find hosting virtual machines for your fleets.
- The entire virtual machine that is assigned to your fleets is dedicated to you; you don't have to worry about resource contention from other AMS customers.
- The watchdog agent manages and monitors the life cycle of all dedicated servers within a virtual machine.
Fleet Commander is deployed in each of your environments. It evaluates all of the namespaces within an environment and makes virtual machine instance requests on behalf of the environment to AMS Core.
AMS Core is the multiregional orchestrator that processes requests from the Fleet Commanders in all the customers' environments to find virtual machine resources for them.
The regional orchestrator will also make sure that every virtual machine is assigned to exactly one owner so that you don't have to worry about noisy neighbors.
The watchdog manages and monitors the life cycle of the dedicated servers on each virtual machine. It also emits observability metrics and analytic events to the respective platforms.
Other key concepts
A dedicated server (DS) is a disposable game server that hosts one game session. The dedicated server is discarded and replaced with a new one by AMS once it has finished serving a game session. Not to be confused with a peer-to-peer (P2P) server.
A fleet is a collection of dedicated game servers, active or idle, to serve game sessions.
Quality of service
Each regional cluster will have its own quality of service (QoS) servers that are used to verify the performance between your players' locations and the regional cluster. This data is used to find out the best region for your players to play in.
In practice, once your game is integrated with the AccelByte Client SDK, the SDK will automatically ping each of the available regions to keep the connection data updated for you.
A virtual machine (VM) is the host to run your dedicated servers, sourced from a cloud provider or from baremetal in the regional resource pool. A typical virtual machine belongs to one of the AccelByte virtual machine instance families.
Dedicated server states
The dedicated server states keep track of the life cycle of a dedicated server. The states are:
- In Session
The change of states of a dedicated server are described in the following diagram.
Timeouts are time limits that are applied to your dedicated servers during some of the states in their life cycles. All these time outs are configurable in the Admin Portal.
The creation timeout starts when the watchdog spins up your dedicated server and marks its state as Creating. It gives a configurable time limit for your dedicated server to initialize so that if your dedicated server fails to initialize, the watchdog will remove the server and start another one again in its place.
The creation timeout is applicable only when the dedicated server is in the Creating state. Once the dedicated server registers itself to the dedicated server manager, it will enter the Ready state.
The session timeout starts when a dedicated server starts serving a game session and enters the In Session state. This timeout gives a time limit for your dedicated server to serve a game session so that the watchdog can remove any stale servers that fail to exit normally after a game session has finished. If this timeout is exceeded, the watchdog sets the state of the server to Drain.
The drain timeout starts when a dedicated server receives the drain signal from the watchdog and enters the Drain state. This timeout gives a time limit for your dedicated server to finish any last minute operations before it exits itself, or waits for the watchdog to forcibly stop it.
The unresponsive timeout refreshes when a server finishes its last health check with the watchdog. This timeout gives a time limit for your dedicated server to recover its connection to the watchdog in case of any service interruption. If this timeout is exceeded, the watchdog removes the server and restarts another one in its place.