RequestMultiplayerServer to be distributed over multiple builds in a controlled fashion. This can improve the simplicity and reliability of build to build upgrades and several other scenarios listed below. Aliases achieve this by specifying a list of build ids along with the weight of each one. The weight represents the ratio of allocation calls that should be forwarded to the corresponding build.
Safe deployment that is backwards compatible
This is the most common scenario for a build to build upgrade, where you are updating the game server and retail clients are compatible with both servers. Clients will reference Alias 1, which would have the following configuration:- Build 1: Weight = 1
- Build 1: Weight = 8
- Build 2: Weight = 2
Deployment that is not backwards compatible
In this case you want to update the game server at the same time you are updating game clients, as your current game clients are not compatible with the old server build. Transitioning from one build to another would be done as follows: Old clients will reference Alias 1, which would have the following:- Build 1: Weight = 1
- Build 2: Weight = 1
Blast deployment that is backwards compatible
This is similar to the backwards compatible build to build upgrade scenario, but with a more sudden switch in demand behavior. Transitioning from one build to another would be done as follows: Clients will reference Alias 1, which would have the following:- Build 1: Weight = 1
- Build 1: Weight = 0
- Build 2: Weight = 1
Testing a deployment that is backwards compatible
When you want to update the game server, and the client version is compatible with both servers, but you wants to test the second version before deploying it at scale for all players. Testing and transitioning from one build to another could be done as follows: Clients will reference Alias 1, which would have the following:- Build 1: Weight = 1
- Build 2: Weight = 1
- Build 1: Weight = 8
- Build 2: Weight = 2
Fallback to other builds and regions
Aliases can make your multiplayer server deployments more resilient, by allowing for fallback across multiple builds. For example, assume an allocation request targeting a build alias ranks EastUS as region #1, and West US as region #2. This build alias provides similar weights to two builds, Build 1 and Build 2. Assume that for a given allocation Build 1 is selected.- Allocation in East US for Build 1 is tried.
- If #1 fails, allocation in East US for Build 2 is tried.
- If #2 fails, allocation in WestUS for Build 1 is tried.
- If #3 fails, allocation in WestUs for Build 2 is tried.
Manage a build alias with PlayFab REST APIs
You can now manage build aliases in Game Manager. To get started, see Builds overview page
-
Create a build alias by using the API.
API:
Sample body:Sample response:Build Alias Id is provided as part of the response.
-
Update any parameter of the build alias.
API:
Sample body:Sample response:
-
Delete a build alias.
API:
Sample body:
-
List build aliases.
API:
Sample response:
Allocate using a build alias
To allocate using a build alias one must simply specify the build alias Id in theRequestMultiplayerServer call.
API:
