This Guidance demonstrates how developers can build a Friends list system for their game using Amazon GameSparks and Amazon DynamoDB. Friends lists are key to driving social engagement in games, enabling players to keep track of their in-game friends and engage with them in gameplay activities. This Guidance provides support for setting a display name, sending friend requests, accepting or rejecting requests, and retrieving a list of friends for a player. Developers can use the provided tooling to deploy the sample code and resources into their AWS accounts.
Architecture Diagram
Step 1
Game clients A and B set up a (default) Friend Code and Display Name for the logged in users (A and B) by sending a request to Amazon GameSparks.
Step 2
GameSparks invokes an AWS Lambda function to store the data in Amazon DynamoDB.
Step 3
The Lambda function stores the Friend Code and Display Name in DynamoDB.
Step 4
Game client A sends a request to become a friend with player B to GameSparks.
Step 5
GameSparks invokes a Lambda function to process the friend request.
Step 6
The Lambda function processes the request and stores it in DynamoDB.
Step 7
Game client B retrieves a list of friend requests by sending a request to GameSparks.
Step 8
GameSparks invokes a Lambda function to retrieve the list of friend requests.
Step 9
The Lambda function retrieves the friend requests from DynamoDB and returns it to GameSparks, which returns it to the game client.
Step 10
When player B accepts the request, the game client sends an acceptRequest message to GameSparks
Step 11
GameSparks invokes a Lambda function to process the request and store the accepted request in DynamoDB.
Step 12
Game client A can now send a request to GameSparks to retrieve the friends list through Lambda from DynamoDB.
Step 1
Game clients A and B set up a (default) Friend Code and Display Name for the logged in users (A and B) by sending a request to Amazon GameSparks.
Step 2
GameSparks invokes an AWS Lambda function to store the data in Amazon DynamoDB.
Step 3
The Lambda function stores the Friend Code and Display Name in DynamoDB.
Step 4
Game client A sends a request to become a friend with player B to GameSparks.
Step 5
GameSparks invokes a Lambda function to process the friend request.
Step 6
The Lambda function processes the request and stores it in DynamoDB.
Step 7
Game client B retrieves a list of friend requests by sending a request to GameSparks.
Step 8
GameSparks invokes a Lambda function to retrieve the list of friend requests.
Step 9
The Lambda function retrieves the friend requests from DynamoDB and returns it to GameSparks, which returns it to the game client.
Step 10
When player B accepts the request, the game client sends an acceptRequest message to GameSparks
Step 11
GameSparks invokes a Lambda function to process the request and store the accepted request in DynamoDB.
Step 12
Game client A can now send a request to GameSparks to retrieve the friends list through Lambda from DynamoDB.
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
GitHub is used to host the source code repository of the Guidance, where you can post issues and request additional functionality to continuously improve the supporting processes.
-
SecurityRead the Security whitepaper
To protect resources in this Guidance, you must set up an AWS Identity and Access Management (IAM) user or role with the appropriate permissions to the services before you deploy.
All stored data is stored in DynamoDB and is encrypted through AWS Key Management Service (AWS KMS).
The resources deployed by this Guidance are not exposed to the internet and can only be accessed by the public through the GameSparks game backend.
-
ReliabilityRead the Reliability whitepaper
All of the computing within the Guidance is stateless, allowing for a reliable, application-level architecture. When there are changes in demand, GameSparks, Lambda, and DynamoDB will automatically scale to meet the new demand.
DynamoDB has a point-in-time recovery feature that is enabled by default within the Guidance. This feature allows you to restore to any given second in the preceding 35 days.
Lambda functions in one AWS account in one Region share the concurrency limit. If one function exceeds the concurrent limit, other functions are prevented from invoking the Lambda service. Check and adjust the reserved concurrency for the Lambda functions deployed in your AWS account prior to your game receiving production traffic.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
Latency from the game client to the game backend is not usually a concern for the Friends functionality. However, GameSparks game backends can be deployed to several AWS Regions, and you should determine where to deploy your game backend depending on where most of your players reside.
-
Cost OptimizationRead the Cost Optimization whitepaper
Within this Guidance, data transfer out only occurs through GameSparks, which does not include a cost for data transfer. Data transfer across AWS Regions is avoided completely by centralizing all resources in a single AWS Region.
GameSparks, used extensively within this Guidance, includes pricing based on Client API calls, Cloud Code API calls, and player data storage, all of which are kept to a minimum. Additionally, this architecture uses serverless services so that you only pay for the resources you consume.
DynamoDB is used as the primary data storage for the Guidance. The DynamoDB on-demand capacity mode is used to ensure that customers only pay for what they use.
-
SustainabilityRead the Sustainability whitepaper
All of the services used within the Guidance are managed services, thus minimizing the amount of hardware that is needed to provision for deployment.
Implementation Resources
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
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.