November 2016
Xbox Live Compute is a cloud-based platform that empowers game creators to deliver breakthrough online session-based gaming experiences at epic scale. The primary goals and objectives of the platform are to:
The Xbox Live Compute management portal is now integrated into the Universal Dev Center. This places us alongside our neighboring Xbox Live services and helps centralize Xbox Live config management. Additionally, we have released a new version of our PowerShell commandlets which can be found in the Xbox Live SDK or the Xbox Live Tools Package. Both the UI and the commandlets are no longer coupled to Azure for signing in and management; instead we use Azure Active Directory accounts that are affiliated with a Dev Center publisher.
We are excited to share our new management portal and PowerShell commandlets which bring with them some long-awaited features as part of our new developer experience. Developers can onboard to the new experience and experiment with development without affecting thier current development environment. Work in Dev Center can be confined to a new title id for the server game separate from any exisiting server titles.
Each deployment has configurable scale settings that control the number of standingby and maximum servers on a per-region basis that are now exposed in the portal and the commandlets. Scale settings can be set before a deployment is started as well as while a deployment is running and serving clients. The Xbox Live Compute team still needs to initially provision brand new regions before they can be used.
Developers now have the ability to control the following aspects of cloud game deployments:
VM size can only be changed when the deployment is in a stopped state. For example, you can select an A1 size before starting a deployment, stop the deployment, change the settings to a D1, and restart the deployment. There is no longer a dependency on the Xbox Live Compute team to provide an updated VM package.
Tenant count is also controllable on a per-deployment basis. Multi-tenancy allows multiple instances of your game server to be launched on the same VM. With the appropriate setup, this can lead to an advantageous savings on VM costs. Just like VM size, tenant count can only be set when a deployment is stopped. Refer to the multi-tenancy documentation for more information.
VM endpoint specification is now exposed to users. New titles only need to specify a name and protocol of the desired ports. The Xbox Live Compute service will handle the mapping of port numbers. For more information on port retrieval, refer to the multi-tenancy documentation.
Developers are no longer required to create and manage RDP certificates for Xbox Live Compute. The Xbox Live Compute service now generates unique RDP usernames and passwords for each deployment. Credentials are retrievable in the management portal and in PowerShell. Credentials only become available shortly after a deployment has been started.
There is a new endpoint on the Discovery Service to use for discovering deployments created through the new developer experience. The contract has been streamlined to require less paramters than the original endpoint. Complete documentation on the endpoint will be coming soon.
We’ve prioritized instrumenting our service with more human-readable error strings to provide a more helpful and consistent experience across the portal and the commandlets.
There are a few scenarios that are no longer supported in the new self service model and some that will be coming soon in future feature rollouts.
Coming soon
No longer supported
First, work with your developer account manager (DAM) to onboard to the Universal Dev Center. After registering a publisher, integrate your Dev Center publisher account with Azure Active Directory. This integration provides support for adding individual user accounts to your publisher. Creating an AAD tenant for your organization can be done in the Azure management portal. More information on linking your publisher with an AAD tenant can be found here.
After the appropriate user accounts are provisioned, create an app and enable it for Xbox Live. You will want to select the product type as “Cloud Game.” Cloud games have their own title IDs and can only be used for Xbox Live Compute.
Reach out to the Xbox Live Compute team once you have created the Xbox Live enabled cloud game. The title needs to be granted access to Xbox Live Compute before you can proceed to use the portal and PowerShell commands for development. Additionally, let the Xbox Live Compute team know which Azure regions you are interested starting development in. Typically studios start off in one or two locations. As development progresses, more locations can be enabled over time.
Once your app is enabled for Xbox Live Compute, navigate to the list of Xbox Live services in the services section and click on “Compute.” This brings you to the Xbox Live Compute landing page for the game. Continue reading below for more information on portal functionality.
After selecting the product from the Dev Center dashboard, select “Compute” from the Xbox Live section in the services menu. This is the Xbox Live Compute landing page. From the landing page you can enter four sub-pages: deployments, assets, certificates, and access. Note: proceeding to these pages requires that you have onboarded with Xbox Live Compute. If you have not onboarded with the team then you will be redirected back to the landing page.
A deployment represents an iteration of your game server executable. Different deplyments can be created and initialized with different settings to control server counts, ports, VM size, and tenant count. Once the configuration is set and the game server build is uploaded, starting a deployment will create game servers in the specified regions at the specified levels. Running deployments can be adjusted to add or remove data center locations or change server levels. When a deployment is no longer needed it can be stopped and removed.
Asset packages provide an optional way for multiple cloud game deployments to use the same static data. Once an asset package is uploaded it is available for all deployments to use. Only .zip archives are supported. Multiple asset zips are supported per deployment so best practice is to zip a top level folder to avoid name conflicts between separate asset packages.
There are two steps to creating an asset - the asset object creation and then the upload. To instantiate the asset object, only an asset name and optional description are required. Afterwards, the .zip can be uploaded.
Asset packages can be deleted at any time so long as they linked to any deployments. Error messaging will inform which deployments are using an asset on a failed delete attempt.
Like assets, certificates are be uploaded once and can be used by multiple deployments. Only password-protected .pfx certificates are accepted. When creating a deployment you can reference the certificates you want on your game server in the browser or using the certificateId in PowerShell. Certificates are installed in LocalMachine\My.
Certificates can be deleted at any time so long as they are linked to any deployments. Error messaging will inform which deployments are using a certificate on a failed delete attempt.
The Access page is where you configure which titles and services are allowed to allocate your cloud-based server. Title Ids from XDP can be added as an “External App (Xbox One)”. Web services from XDP can be added as an “External XDP service”. Products created in Dev Center should be listed as “Dev Center apps”.
Detailed documentation for the new PowerShell commandlets can be found here.