Introducing the Lumberyard Cloud Canvas Resource Manager

One of the ways Lumberyard is deeply integrated with AWS is through Cloud Canvas, a set of tools designed to help your engineers and technical designers—even with little to no backend experience—build online game features. Last month, we released Lumberyard Beta 1.3, which includes a new tool for Cloud Canvas – the Cloud Canvas Resource Manager. The Resource Manager, which relies on the AWS CloudFormation service, is an in-editor interface that makes it easier for you to manage and configure the cloud resources that implement connected game features such as player statistics, high scores, and real-time events. In this post, we’ll explore why we built the Cloud Canvas Resource Manager and how you can use it to deploy and manage AWS resources for your game.

The main Resource Manager window

Why did we build it?

Game development is an inherently local activity. You have a local copy of game code, assets, etc. You build, you test, and you tweak… over and over on a local computer, or console.

Because it’s an external environment, working in the cloud is different. The resources your game depends on no longer live on your computer. The process of using and modifying these resources in the cloud isn’t the same as for local elements. Cloud Canvas Resource Manager bridges this gap. It lets you have local descriptions of the AWS resources (for example a database table, an S3 file storage bucket, or code that executes in response to an event) your game needs to exist in the cloud and provides ways to create and interact with actual instances of those resources.

For projects where many users are implementing changes frequently, the Resource Manager helps you deal with that additional complexity. In this case, the source code and assets you’re using likely come from a source control system. With the Resource Manager, the changes you make are shared with other people working on the project through that system. Different people on your team can even be working with different branches of the code and assets at the same time, without interfering with each other.

Once the game is launched, you’ll need another copy of the required resources for your players to use while your team works on bug fixes and new content. You want to be sure that players cannot access the development versions of the resources. You want to protect your players’ information—such as account data—from unauthorized access, while also preventing your development team from accidentally making changes that would break the released game.

The Cloud Canvas Resource Manager provides the tools you need to maintain descriptions of the AWS resources that your game depends on; and creates as many copies of those resources as needed for your development teams and releases, while also helping you secure access to those resources.

How did we build it?

Cloud Canvas Resource Manager is built on AWS CloudFormation, which allows you to maintain a description of the AWS resources you need in a text file that can be checked into your source control system. These descriptions can be branched and merged along with the rest of the game code and assets. When actual instances of the resources are needed, the descriptions are passed to AWS CloudFormation and it goes about creating, updating, or deleting AWS resources so that they match the descriptions.

The description files are stored in your game project’s AWS subdirectory. Resource Manager lets you organize the descriptions into any number of “resource groups.” Each group can describe all the resources needed by a game feature, such as a high score tracking system. These groups are known as Resource Definitions.

Resource Manager lets you create as many “deployments” of the resources as you need. You could have a deployment for the dev team, another for the QA team, and another for the released game; or any other arrangement that matches your development and release processes. Each deployment contains a complete and independent instance of all the resources defined by all the project’s resource groups. Deployments are implemented using CloudFormation “stack” resources which contain a nested stack resource for each of the resource groups.

You can choose your active deployment in the Lumberyard Editor. When testing the game, the Editor will use the active deployment you selected to map references to resources in game code and Flow Graphs to the instance of that resource for the deployment you select. You can also specify what deployment is used for release builds of the game. More on that here.

Each deployment comes with an AWS Managed Policy and an AWS Role that can be used to grant access to that deployment to selected AWS Users and Groups. The player is granted access to specific resources within a deployment. Details can be found here.

The Cloud Canvas Resource Manager’s use of AWS CloudFormation is an interesting case study for anyone who needs to add similar functionality to their (game and non-game) applications. Resource Manager makes use of CloudFormation features such as custom resources implemented using AWS Lambda and demonstrates how AWS Identity and Access Management (IAM) can be used with CloudFormation to secure your AWS resources. All the source code for the Resource Manager is included in the Lumberyard download. Most of it is implemented in Python using the Boto3 AWS SDK. It can be used from the command line and from inside the Lumberyard Editor.

See For Yourself

You can see the Resource Manager in action using the “Don’t Die” level of the sample project that comes with Lumberyard. “Don’t Die” uses AWS to store player high scores, and your AWS account must be prepared for that before the example is fully functional. For more info on configuring your AWS account for Cloud Canvas in Lumberyard, check out our tutorial.  Your AWS usage running the “Don’t Die” sample should be well within the free tier.

We’ll be providing a lot more examples, and more ways to leverage AWS, as we continue our work on Lumberyard Cloud Canvas.

About the Author

Mike Deem has been building distributed systems since the early 1990s. He has been at Amazon for over six years, where he built scalable and reliable backend systems for the catalog and Kindle teams. He now applies that experience and his long time passion for online virtual environments to the Lumberyard project where he is the lead engineer on the Cloud Canvas team.