How It Works
The Basics of Server Management
For each multiplayer game that you wish to host using Armada, you will need a fleet of bare metal servers as well as access to some virtual cloud instances. This will ensure that you have the capacity needed to service your players.
As Armada is completely provider agnostic, you can source hardware from different providers depending on your needs, as well as utilize any and all cloud providers. What's more, if you are unsure what providers to use or do not have the ability to organize your own hardware, the Armada team can source and deploy this for you using our recommended providers.
Each bare metal server and virtual cloud instance will have your multiplayer game server deployed to it so that when players make a matchmaking request, Armada will be able to start an instance based on the required location and instance priority.
Armada has a powerful priority system that allows you to specify what hardware or instance types should be used first to service your players. You may have a large fleet of bare metal servers, and also a bunch of credits provided to you from one of the many cloud providers. With Armada, you can choose if you want to burn through your credits first, or place your players on the bare metal capacity until the point where they are completely full and then burst into the cloud. The choice is entirely yours!
Armada works by connecting dedicated servers from different providers. The diagram below shows the flow and different services involved in connecting these servers. Any dedicated servers required are hosted directly on bare metal or cloud infrastructure that is specific to your game.
How Our Matchmaking Service Uses Armada
Below is a diagram of how Armada can work with our Cloud Matchmaking service.
The player connects to the Lobby service through a websocket connection.
The player sends a matchmaking request to the Lobby service.
The Lobby service will act as a proxy and forward the incoming message to the Matchmaking service.
When a match is found, the Matchmaking service will notify the Lobby service.
The Lobby service will send a request to the DSM to create a new game session with the match details.
The DSM will check whether a DS pod is available.
If there's an idle pod available, the DSM will assign the available DS pod.
If there are no idle pods available, the DSM will spawn a new DS pod.
The DSM claims the pod and assigns the game to it.
After the process is complete, the DSM notifies the Lobby service that the session has been created, and sends the DS details.
The Lobby service forwards the DS details to the game client.
Then the game client can connect to the server using those DS details.
Deployment Override
Deployment override is a feature that enables you to override an existing deployment's configurations if part of that deployment turns out to be unstable, so you can re-enable the previous working version. You can also use deployment override if you want to test a certain feature that has a different game version from your current deployment.
For example, to run the game you need to have a matching Game Client and Game Server. When you override a deployment, if you have 3 different game versions on 3 different development stages, you don't have to create 3 different deployments for each Game Version. You only need to create one Deployment Server that you can override based on the Game Version.
The diagram below outlines how this feature works:
As seen in the diagram above, the override will be activated depending on the version requested by the game client.
- Default Deployment refers to the deployment that will be used if no errors occur.
- Override with Default Deployment allows you to override a non-default deployment version with the default deployment, so if the default version is 1.0.0 and you have deployed 1.0.1, the deployment will be overridden with 1.0.0 should the server have any issues with 1.0.1.
- Override with Specified Deployment enables you to define a deployment version to revert to should the server have any issues with the default deployment. For example, if only a certain version of your game includes support for matchmaking servers in Asia, this version will need to be deployed when players in Asia access your game.