Serverless Multiplayer Gaming Platform

I made this project to give an overview of the way I work. From architecture to implementation, I talk about all aspects of the project, its value and improvements.

This project is close to a real professional project, in proportion to the cost budget, and I would be glad to discuss it with you.

Demo

Functional description

Specification

This demo is a fully working online multiplayer gaming platform. Resources are deployed automatically and users can interact with them.
Resources have been configured to get the best cost/performance compromises (ex: minimum Fargate working specs, endpoints instead of NAT).
Alerts on root account have been configured to send notifications if the estimated budget is exceeded for the current month.
Fargate servers started only when needed. In a real-life use case, there would always be servers running and up to meet traffic needs.
0,70 $/working day + 0,01 $/game
Standard users have minimum rights and can’t call admin API (ex : creation of a new game server). Non-logged-in users can’t call APIs.
A WAF is associated with the load balancers to prevent any malicious behaviors. AWS-managed rules are used.
All communications use secure protocols (HTTPS, WSS).
IAM users use only the rights they need.
Custom domain names are used, not Amazon-generated ones.
All credentials and sensitive terraform variables are securely stored in GitHub.
Docker images have been updated to encapsulate dependencies. The docker containers could run in a local offline network.
API Gateway is configured to use HTTP protocol, reducing latency by 60% reduction in latency (Source).
CloudFront is used to distribute static game files, optimizing objects accessibility.
Downsizing of the Docker images and use of ECR cache to reduce containers loading time by 40%.
Code changes detected and managed by GitHub Actions.
React App built and deployed by Amplify at each commit.
New version of Ecs task definitions created when new Docker images are built.
Terraform is used to manage Aws infrastructures on dev and prod accounts.
SES mail sent when a game server has been started in the prod environment.
DynamoDb table to track game servers activities.
Logs saved in Cloudwatch for analysis.

Architecture

Docker images are uploaded into ECR repositories.

At each front-end react commit, the code is deployed into the serverless amplify website.

A user accesses the amplify website using a public custom domain name. He is redirected to a login page, linked to Cognito data.

After a successful login, the user can press button which will call a HTTP API and trigger lambda functions. Some APIs can only be called by users belonging to the Cognito admin group.

Lambda functions create and manage Cloudformation game server stacks. A step function is used to automatically stop game servers after a given period of time.

When a user joins a game, the client retrieves static files from a S3 bucket, and a WSS connection is established with the ECS game server task.

Each game server is contained within an ECS task. The task is composed of two Docker containers : a proxy and a game server.

A dynamodb table stores all game server data (endpoint url, cloudformation stack name, game server status,…)

Aws resources are deployed using Terraform in the Aws Dev and Prod accounts. A cloudwatch event deploys the resources during working hours, in the prod account.

About the game

I decided to use this game for this project, because :
• its license allows me to do so,
• the game components can be separated into several bricks (game server, web server, content server) and are containerizable,
• this game is a pioneer in the history of video games, and one of the first I played.

Git Repos

Game Server

Proxy Server

React app

Terraform