Developer Guide (Version 1.11)

Resource Mappings

Resource mappings map the friendly names used in a game's Resource Definitions to the actual names of the resources created for one or more specific Resource Deployments. For example, a DynamoDB table name like DailyGiftTable would get mapped to a name like SamplesProject-DontDieDeployment-78AIXR0N0O4N-DontDieAWS-1I1ZC6YO7KU7F-DailyGiftTable-1G4G33K16D8ZS where SamplesProject is the name of the project, DontDieDeployment is the name of a deployment, and DontDieAWS is the name of a resource group. The 78AIXR0N0O4N, 1I1ZC6YO7KU7F and 1G4G33K16D8ZS parts of the resource name are inserted by AWS CloudFormation to guarantee that the resource name is unique over time. Thus, even if a resource is deleted and a new one with the same logical name is created, the physical resource ID will be different.

Usually different deployments, and consequently different mappings, are used for game development and for the released version of a game. Furthermore, different development, test, and other teams often work with their own deployments so that each team has distinct mappings.

The deployment used by default during development is specified in the project-settings.json file. The file is located in the Amazon S3 configuration bucket at /s3/buckets/<projectname>-configuration-<ID>/project-settings.json. The file can be overridden for each user by the dev\Cache\{game}\pc\user\AWS\user-settings.json file. You can change the default deployment by using the lmbr_aws deployment default command or by using the Cloud Canvas Resource Manager.

The mappings used during development when the game is launched from the Lumberyard IDE by pressing Ctrl+G are stored in the user-settings.json file just mentioned. This file is updated automatically when the default deployment changes, when the default deployment is updated, and when Lumberyard Editor is started. It can be refreshed manually by using the lmbr_aws mappings update command.

When a game launcher application created in Lumberyard launches a release build of a game, the mappings for the game are stored in the {root}\{game}\Config\awsLogicalMappings.json file. These mappings can be updated manually using the lmbr_aws mappings update --release command, which produces the awsLogicalMappings.json file. You can specify the deployment for the release mappings in the ReleaseDeployment property of the project-settings.json file.

For more information, see Running AWS API Jobs Using the Cloud Gem Framework .

Using Mappings in AWS Flow Nodes

AWS flow nodes that define TableName (DynamoDB), FunctionName (Lambda), QueueName (Amazon SQS), TopicARN (Amazon SNS), or BucketName (Amazon S3) ports work with mappings. Set the port to a value like {resource-group}.{resource} where {resource-group} is the name of the resource group that defines the resource, and where {resource} is the name of the resource that appears in the Resources section of the resource group's resource-template.json file. For detailed information on the Cloud Canvas flow graph nodes, see the Cloud Canvas Flow Graph Node Reference.

Using Mappings in Lambda Functions

Lambda function resources defined as part of a resource group often need to access other resources defined by that resource group. To do this, the function code needs a way to map a friendly resource name to the actual resource name used in AWS API calls. The LambdaConfiguration resource provides a way to such mappings, as well as other settings, to the lambda code. For more information, see LambdaConfiguration.