[SEO Subhead]
This Guidance helps game developers build persistent world games and host virtual worlds on AWS using Amazon GameLift and serverless backend components. The architecture uses managed and serverless components to reduce operational effort and scale based on player demand. Developers can use this architecture to get started with persistent virtual world game development on MacOS and Windows. This Guidance includes infrastructure as code (IaC) automation, configuration scripts for setting up dependencies, and a sample Unity client/server implementation.
Architecture Diagram
Please note: Steps A-C represent the back end of the system, and Steps 1-9 represent the front end.
Step A
Amazon EventBridge triggers WorldManager AWS Lambda function every one minute. The function checks existing worlds’ status through the Amazon GameLift API.
Step B
WorldManager Lambda function stores the current state of the sessions and worlds to Amazon DynamoDB for faster back end access.
Step C
WorldManager queries configured worlds from DynamoDB and creates any worlds that are not running by calling the Amazon GameLift API CreateGameSession.
Step 1
Game client requests an identity and credentials from Amazon Cognito Identity Pool to sign authorized API requests.
Step 2
Game client requests the world list through Amazon API Gateway. API Gateway triggers ListWorlds Lambda function that checks game session information in the defined Region from DynamoDB.
Step 3
Game client requests to join a specific world in a specific Region by calling JoinWorld Lambda function through API Gateway.
Step 4
Lambda function creates a player session for the player, increases the amount of players for that world in DynamoDB, and sends the connection information to the game client.
Step 5
Client connects to the Amazon GameLift session directly over transmission control protocol (TCP) and sends the player session ID.
Step 6
Amazon GameLift session validates the player session ID with the Amazon GameLift server software development kit (SDK).
Step 7
Amazon GameLift checks for world-specific player data and updates the player data as needed. It will store the latest player location after the player leaves.
Step 8
Amazon GameLift session checks DynamoDB for scheduled termination and terminates if requested.
Step 9
Game server sends logs and metrics to Amazon CloudWatch using the CloudWatch Agent.
Step A
Amazon Eventbridge triggers WorldManager
AWS Lambda function every one minute. The function checks existing worlds’ status through the Amazon GameLift API.
Step B
WorldManager Lambda function stores the current state of the sessions and worlds to Amazon DynamoDB for faster back end access.
Step C
WorldManager queries configured worlds from DynamoDB and creates any worlds that are not running by calling the Amazon GameLift API CreateGameSession.
Step 1
Game client requests an identity and credentials from Amazon Cognito Identity Pool to sign authorized API requests.
Step 2
Game client requests the world list through Amazon API Gateway. API Gateway triggers ListWorlds Lambda function that checks game session information in the defined Region from DynamoDB.
Step 3
Game client requests to join a specific world in a specific Region by calling JoinWorld Lambda function through API Gateway.
Step 4
Lambda function creates a player session for the player, increases the amount of players for that world in DynamoDB, and sends the connection information to the game client.
Step 5
Client connects to the Amazon GameLift session directly over transmission control protocol (TCP) and sends the player session ID.
Step 6
Amazon GameLift session validates the player session ID with the Amazon GameLift server software development kit (SDK).
Step 7
Amazon GameLift checks for world-specific player data and updates the player data as needed. It will store the latest player location after the player leaves.
Step 8
Amazon GameLift session checks DynamoDB for scheduled termination and terminates if requested.
Step 9
Game server sends logs and metrics to Amazon CloudWatch using the CloudWatch Agent.
Get Started
Deploy this Guidance
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
AWS Cloud Development Kit (AWS CDK) handles deployments and updates by using AWS CloudFormation to control resource updates and rollbacks. This reduces errors caused by manual configuration changes.
For Amazon GameLift fleet updates, CloudFormation will create a replacement fleet. It will wait for the replacement to become fully active to accept traffic before terminating the old fleet.
-
SecurityRead the Security whitepaper
The game client uses Amazon Cognito Identity Pool identities to secure access to the back end services. This is achieved by signing the requests with AWS Identity and Access Management (IAM) credentials provided by the Identity Pool. Only authenticated requests are allowed to the provided APIs hosted on API Gateway. Additionally, game clients are allowed to access only the data of their own account.
-
ReliabilityRead the Reliability whitepaper
In case the game server (and consequently the game world) crashes, the architecture will automatically replace the world with a new one, which will have access to the same persisted data of that specific world.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
Amazon GameLift allows direct client to server communication to optimize near real time performance. The architecture allows developers to host game servers across multiple AWS Regions, reducing the latency between the game client and the server.
-
Cost OptimizationRead the Cost Optimization whitepaper
The architecture leverages serverless components including API Gateway, Lambda and DynamoDB, which allow you to reduce costs by paying for the exact amount of resources based on player traffic. Additionally, Amazon GameLift can be configured to scale based on demand so you have a minimal set of unused resources running at any given time.
-
SustainabilityRead the Sustainability whitepaperThis architecture uses managed and serverless services to run only the resources required for the current player load, reducing your individual impact on the environment.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.