1. Download Source Code
2. Install Source Code
3. Open up your Epic Games Library and install the Multiplayer With Blueprints Plugin to the same engine version inside of your Epic Games Library that the Source Version you downloaded was for.
4. Find the installed plugin inside of your Epic Games Engine by going to Program Files ➜ Epic Games ➜ UE_4.XX ➜ Engine ➜ Plugin ➜ Marketplace ➜ awsSDK and copy the plugin.
5. Paste the Plugin folder inside of your source Engine build through the same path UE_4.XX ➜ Engine ➜ Plugin ➜ Marketplace ➜ awsSDK.
6. Rebuild Our Source Engine. Run the setup.bat file as administrator, next run the generateprojectfiles.bat, and then open up the UE4.sln and build your visual studio file making sure you have development editor and Win64 selected at the top.
7. Download this free JSON Blueprint Plugin and install it to your engine the same way you did the Multiplayer with Blueprints plugin.
8. Download the Example Project
   
9. When attempting to open the example project, you will be asked to rebuild it, select yes, this is expected so that all the references for the project will be rebuilt to reference your source build of the engine. You may also need to modify your uproject file to ensure you are referencing the correct plugin. The most likely cause of this issue is that your uproject file has the wrong name attached. Please check the "Combining Individual Plugins Into One Package" section of our documentation for more information.
10. Awesome! Now that we have the plugin installed and the example project open, let's get started with AWS!

We need to now Configure our AWS Command Line for our PC in order to upload server builds later on down the line. To do this, you will provide the following information into CMD or Windows PowerShell:

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json
                                        

AWS GameLift is a fully managed service for deploying, operating, and scaling your session-based multiplayer game servers in the cloud. Amazon GameLift replaces the work required to host your own game servers, including buying and setting up hardware, and managing ongoing activity, security, storage, and performance tracking. Auto-scaling capabilities provide additional protection from having to pay for more resources than you need, while making sure you always have games available for new players to join with minimal waiting. Through Amazon GameLift we will be able to deploy and manage dedicated game servers with custom rule sets for skill/latency based matchmaking.

AWS Cognito lets you add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily. Amazon Cognito scales to millions of users and supports sign-in with social identity providers, such as Facebook, Google, Amazon, and enterprise identity providers via SAML 2.0. We will be able to store information about users inside of cognito to use within our matchmaking configurations.

AWS Lambda allows you to run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app. The possibilities are endless on what that block of code will specifically do but a few examples could be allowing invite and accept functions to have friends join your lobby, writing matchmaking configurations, etc...(essentially the idea would be writing any specific block of code that needs to be triggered at a specific time, so if you have any ideas let me know!)

AWS DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. It's a fully managed, multiregion, multimaster, durable database with built-in security, backup and restore, and in-memory caching for internet-scale applications. DynamoDB can handle more than 10 trillion requests per day and can support peaks of more than 20 million requests per second.

AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys. We will be specifically using this service to encrypt the environment variables inside of our Lambda functions.

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources. This service is very important because it allows us to be certain that we are following AWS best security practices.

Firstly, I wanted to explain to everyone why your Credentials (specifically Access Key & Secret Key) can be safe on the client. As long as you make sure to follow the AWS best practices listed on this page.


With that out of the way, we wanted to put together a list of resources and key information so that you can be confident your project will be secure inside of AWS. You will see as we go along in this documentation that we use Groups, Users, Roles, and Policies to ensure we are following AWS best security practices.

Manage IAM users and their access – You can create users in IAM, assign them individual security credentials (in other words, access keys, passwords, and multi-factor authentication devices), or request temporary security credentials to provide users access to AWS services and resources. You can manage permissions in order to control which operations a user can perform.

Manage IAM roles and their permissions – You can create roles in IAM and manage permissions to control which operations can be performed by the entity, or AWS service, that assumes the role. You can also define which entity is allowed to assume the role. In addition, you can use service-linked roles to delegate permissions to AWS services that create and manage AWS resources on your behalf.

Manage federated users and their permissions – You can enable identity federation to allow existing identities (users, groups, and roles) in your enterprise to access the AWS Management Console, call AWS APIs, and access resources, without the need to create an IAM user for each identity. Use any identity management solution that supports SAML 2.0, or use one of our federation samples (AWS Console SSO or API federation).

Introduction To IAM (Identity & Access Management)

AWS Recommended Best Practices

1. Lock away your AWS account root user access keys
2. Create individual IAM users
3. Use groups to assign permissions to IAM users
4. Grant least privilege
5. Get started using permissions with AWS managed policies
6. Use customer managed policies instead of inline policies
7. Use access levels to review IAM permissions
8. Configure a strong password policy for your users
9. Enable MFA
10. Use roles for applications that run on Amazon EC2 instances
11. Use roles to delegate permissions
12. Do not share access keys
13. Rotate credentials regularly
14. Remove unnecessary credentials
15. Use policy conditions for extra security
16. Monitor activity in your AWS account

For More Information On These Practices

Watch this video for an Introduction to using IAM to ensure best security practices:

Introduction To AWS Best Security Practices

Amazon Cognito uses industry standard Authorization and Authentication through OAuth 2.0 and OpenID Connect for User Pools and Identity Pools. User Pools will handle user registration, authentication, and account recovery. By using our Plugin and Example Project, the process for creating User Profiles and retrieving user related information will be extremely straightforward. This is because we have already provided you with a Customized UI as well as all the User Pool SDK exposed to Blueprints so that you have you can have Sign-up and sign-in services, A built-in, customizable web UI to sign in users, User directory management and user profiles, and Security features such as multi-factor authentication (MFA), checks for compromised credentials, account takeover protection, and phone and email verification completely set up for your game in just a few hours!

Learn More About OAuth 2.0 and OpenID Connect     Learn More About User Pools & Identity Pools

Sign In


Sign Up


Forgot Password


Confirm Forgot Password

1. Go to your AWS Console and search for the Service Cognito, once at the Cognito home page select Manage User Pools.

2. Now check the top right corner and make sure that you are inside of the Region that you want to create a User Pool in, we would recommend choosing the region that is closest to your current location.

3. Now select create a New User Pool and give it a name, you can choose to do step through settings or review defaults.

4. Go ahead and Create your pool. I am going to show you the settings we used for the user pool inside of the Example Project, but feel free to set yours up differently where you deem necessary!

5. Starting with Attributes, Under how do you want your users to sign in, I selected Username and all three boxes underneath it. Then under which standard attributes are required, I selected Nickname and Email (which is why when users are signing up inside of the Example Project, they must provide Username, Email, Password, and Nickname). Now under do you want to add Custom Attributes, I added three of them, one of type string with the name custom:steam_id, one of type number with the name custom:game_master, and one of type number with the name custom:level. I recommend adding the Custom Steam ID attribute if you plan on allowing users to use their Steam ID to sign in to your Cognito User Pool inside of your game (Showing you all how to use a players steam id as their username in a cognito user pool is number one on my list of tutorials to create after setting up all this documentation and video tutorials for this new example project). The custom game_master attribute is generally used for public matches but I do not use this attribute inside of the example project. The Custom Level Attribute is what I am going to be using to store a Elo Value (or could be any other value that you want to base matchamking off of, such as kill to death ratio) that I will then use to Matchmake Players into Team Deathmatch Games, I definitely recommend creating this attribute because I believe it is extremely cool how easily we are able to setup Skill Based Matchmaking with the use of this plugin, and this is the variable I am going to use to do it.

6. Next General Setting we are going to look at is Policies. Here you can choose the password strength that you want to require players to have, whether you want to allow Users to sign themselves up (I selected yes), and length of time before temporary passwords expire if not used (I decided 7 days).

7. Moving on to MFA and Verifications. Here you can choose if you want to enable Multi Factor Authentication (MFA) which will increase security for your end players. I selected optional allowing players to decide of my game to decide whether they want MFA enabled and chose SMS text message as the second factor. Then I chose Phone if available, otherwise email, and do allow a user to reset their password via phone if they are also using it for MFA for how a user can recover their account. Finally, for which attributes do you want to verify, I chose email or phone number.

8. Now still inside of MFA and Verification, in order for Amazon Cognito to send SMS messages on your behalf, you're going to need to create an IAM Role to allow Cognito the permission to do this. We've already discussed IAM roles/policies earlier in this documentation, so I am only going to roughly describe how to set up the role you need to set up here. You are going to need to create a role with one attached policy. The service for that policy will be SNS, the access level will be write capabilities, and the resource will be all resources. Then go ahead and add that role name inside of the MFA and verification section of your User Pool.

9. For Advanced Security, message customizations, and tags I left everything default.

10. Next, For Devices, I selected User Opt In for remembering player's devices and selected No to suppressing the second factor during multi-factor authentication (MFA).

11. Then, for App Clients we need to create an App Client. Give the App Client a name, and then I checked the boxes Enable lambda trigger based custom authentication, Enable username password based authentication, Enable SRP, Enable refresh token based authentication, and Enabled Prevent User Existence Errors.

12. For Triggers and Analytics, I left everything default.

In this section I am going to give you an idea of how all the code is going to be functioning for our User Pool. All of the code that we will be looking at will be located inside of the W_mainMenu Widget Blueprint located inside Content ➜ UI_newTemplate ➜ widgets. I am going to break down each explanation by the Comment Bubble that it is inside of. In order for this widget to appear on the users screen, we must add it to viewport. Inside of the LoginPC player controller, you will notice that I have done this.


Event Construct

Inside of the Event Construct Comment Bubble, we are first going to obtain a reference to our Game Instance. We will reference variables in our game instance multiple times so it is just easier to make a variable for it, rather than casting every time. We will also create a Cognito IDP Object and Cognito Identity Object, we do this so that we will be able to use Cognito User Pool and identity Pool client functions inside of our project, which we will do immediately inside of this widget blueprint as the only service this widget will use Cognito related functions. Also you'll notice you need to provide your access key and secret key which you should've seen how to do while creating your AWS account, and you can reference the best security practices of this documentation in order to maintain best security habits regarding access/secret keys.


Hovering

Inside of the Hovering Comment Bubble, all that is taking place is we are playing an animation when you hovering over any button that can be pressed, which really only has an impact on trying to increase the users of your applications experience.


Switching Between Panels

Inside of the Switching Between Panels Comment Bubble, we will handle all of the animations that take place when a user of your application is moving from one screen to another, such as moving from the Login Panel to the SignUp Panel. This functions to improve users of your applications experience.


Pre Login Cognito Functions

Inside of the Pre Login Cognito Comment Bubble, we will handle New Users Signing Up, the Confirmation Code for users to confirm themselves, and dealing with users who have Forgotten Their Password. For starters with all functions inside of this section, anytime you see Set Visibility with target Register Loading, that only deals with the circular throbber that appears next to a button the user presses. Also for many of these functions, we will have animations that are played at the end for switching screens upon successfully executing a Cognito function. Also the Client ID Variable that you should keep in your game instance and will be provided for these functions is the id associated with the App client that we created inside of our Cognito User Pool.

1. Sign Up - When running the Sign Up function, we need to make sure we provide our client id so that our project knows what User Pool that we are referencing. We will also provide all of the values that Users must provide when registering their account, for our case this will be a username, Password, Email, and Nickname. As long as all information was successful a validation code will be sent to the users email for them to confirm their account and the user will be taken to the confirm Sign Up Panel.

2. Confirm Sign Up - When running the Confirm Sign Up function, we will again be sure to set the client id, and be sure to match the Username of the user with the code that they provide, which they will have received inside of their email. As long as the code was provided correctly, we will open up the Login Map to allow the user to Login.

3. Forgot Password - When running the Forgot Password Function, all the user will need to provide is their Username and as long as the username exists inside of our User Pool, the function will run successfully and send a validation code to the email associated with the Username.

4. Confirm Forgot Password - When running the Confirm Forgot Password Function, the user will provide the code they received in their email as well as the new password they would like to use. As long as everything is successful they will be returned to the Login Panel, to login to their account with their new password.

5. Send New Confirmation Code - When runnnig the Send New Confirmation Code function, users will be able to have a new confirmation code sent to their email to either verify their new account, or confirm their password change.


Login Pressed

Inside of the Login Pressed Comment Section, we will handle Authenticating a Users information allowing Cognito to take care of security, so that you do not have to worry about it. We will begin by running the function Initiate Authentication with the users username and password. As long as that functiion runs successfully, we will ensure that their are no challenges in our authentication process. If there are challenges, we will run the function Respond to Auth Challenges in order to attempt to solve the authentication issues we are receiving. Some challenges you could put inside of your application inlude CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) or OTP (One Time Passwords). We will continue to run the respond To Auth Challenges, until the challenge name is not set. Once the challenge name is not set, we have successfully authenticated our User and all the parts of our User Pool have successfully been utilized.

For Building For Android

We are now going to link our Identity Pool to our User Pool. A Identity Pool is a way to Authorize Your Users to use the various AWS services. Say you wanted to allow a user to have access to your S3 bucket so that they could upload a file; you could specify that while creating an Identity Pool. And to create these levels of access, the Identity Pool has its own concept of an identity (or user). The source of these identities (or users) could be a Cognito User Pool or even Facebook or Google. In the case of our Example project we are going to use our Cognito User Pool as the source of our identity. in order to sho how to do this, I am going to break this section down into two parts: what we need to do on the AWS side and what we need to do inside of our blueprints.


Inside of AWS Cognito

1. Inside of the AWS Console, under the Cognito tab, we are going to select Manage Identity Pools and Create a New Identity Pool. Just as I did with the User Pool, I am going to show you how the identity Pool is configured for the Example Project, you can set up your Identity Pool differently where you deem necessary.

2. Go ahead and give your Identity Pool a name. Then under Authenticated Identites, I Enabled Access to Un-Authenticated Identities. Ander under Authentication Flow Settings, I left the Authentication Flow as Enhanced.

3. Next, under Authentication Providers, we are going to link our User Pool to our Identity Pool. You are going to need to go over to the User Pool you created and find the Pool ID, then under the App Client section of your User Pool, you are going to want to find the App client Id, and place both of these values inside of the areas that they are asked for.

4. Now, we can go ahead and select Create Pool. Once doing so, you will be prompted to create 2 new roles, one for Authenticated Identities, and one for Unauthenticated Identities. You can go ahead and allow these two new roles to be created, but we are going to need to modify our authenticated identities role to give it access to the services that we are going to use inside of this example project.

5. Go ahead and head over to the IAM service inside of your console. We are going to need to add the following polocies to our Authenticated Identities Role. We are going to give it Full Access with All Resources to Cognito User Pools, DynamoDB, Gamelift, and Lambda. We have now fully setup our Identity Pool!




Inside of Our Blueprints

1. The first thing we are going to do is set some Game Instance Variables. The first four, our Access Token, Refresh Token, Id Token, and Device Key are all directly taken from our Authentication Result Type.

2. We will then get the Logins Map associated with our User Pool. In order to create the Logins Map, you will need to set the following information...
A)cognito-idp.
B)[your-region]
C).amazonaws.com/
D)[your-user-pool-id]





3. Next, we will go ahead run the GetUser function and make sure it runs successfully. We do this to get the attributes associated with the user.

4. We will then run the GetId function where we provide the Logins as well as our Identity Pool Id. From there we will Get Credentials for Identity and we will have successfully completed the necessary Code to authorize our user with our Identity Pool.

Before you are able to successfully run client functions inside of your project from Gamelift, Lambda, and DynamoDB services, you are going to need to create objects for each of them. The process for doing this is quite simple, you are going to want to be sure that for each Region the specific service you are creating an object for that is being used inside of your AWS console, you store to a variable that object inside of that region. In the example project, inside of the Login Map, we create all of our objects for each of these three services. This is done before using any of the functions available for each individual service.

AWS Lambda allows you to Run Code Without Thinking About Servers. You pay only for the compute time that you consume. We have already pre-written Ruby functions for you to use to set up a Friend System and Party System inside of your game. From there, Lambda could be of great use to you if you feel that you have a much better understanding of Java, Go, powershell, NodeJS, Python, or Ruby rather than using traditional C++. You could theoretically use Lambda to write the entire backend for your Unreal Application. In order to begin using Lambda I am going to show you the process of Uploading The Functions that we have provided for you to your AWS console, and then setting up the first function that we will use inside of the Example Project, to record a players latency.

The following video is a great place to start when working with Lambda, it will show how to add Ruby/NodeJS functions to the lambda console, test the functions to make sure they are working, and add the appropriate environment variables. There will also be a step by step listing of what to do for referencing after the video.

Uploading Functions To Lambda Console

1. Find the lambda functions inside of the Example Project that you downloaded from Github. They should be located inside of the Root of the project inside of a folder called Lambda Functions.

2. We now need to create a deployment package (for Ruby or NodeJS) for our fuctions so that Lambda will be able to recognize our code.

Ruby Deployment Package

Setup AWS Lambda Deployment Package In Ruby

Install ruby (DevelopmentKit) - rubyinstaller
Open the command prompt with ruby:
change to the directory of your downloaded lambda functions
run gem install bundler
Create a zip archive of your ruby file and vendor folder.

NodeJS Deployment Package

Setup AWS Lambda Deployment Package In NodeJS

Install NodeJS (DevelopmentKit) - nodeJSinstaller
Open the command prompt with nodejs:
change to the directory of your downloaded lambda functions
run npm install
Create a zip archive of your nodejs file and node_modules folder.

3. We now have the option to either create an S3 bucket to contain our file or just directly upload inside of lambda. It is recommended to use an S3 bucket if your file is larger than 10mb, but none of ours will be. I will still provide you with the steps for uploading to an S3 bucket if you choose to do so:

• So let's open up the KMS Service inside of our AWS Console and create a key
• Key type is symmetric
• give an alias and description for your key, then I didn't add any tags
• choose your key adminstrators, I only chose myself
• define key usage permissions, this will most likely be anyone working in your AWS Console

4. Okay, now let's go over to the Lambda Service and I will show you the basics of setting up a Lambda Function. Go ahead and start by clicking Create Function.

5. We are going to author from scratch. Go ahead and give your function a Name. For this function I am going to name it get_timestamp, because that is going to be the function we are going to invoke in this section, but as we go through this documentation, there will be many different functions that we will create and use.

6. For Runtime, go ahead and select Ruby 2.7 because that is what our functions are written in and our lambda service is set up for. and then we are going to need to create a role for our lambda service to use, so that it has access to our other services.

7. I went ahead and named my Role AWSLambda and gave it Six Policies. Two of these policies will be AWS Managed Policies and four will be managed ourselves. The 2 AWS policies will be AmazonDynamoDBFullAccess and AmazonSESFullAccess. The Four other policies will be as follows:

  

8. Then, inside of the function code section, click on the actions drop down and select upload a file from amazon S3 or upload your zip file. Since we will be creating the get_timestamp function, we will be using the code inside of the party system folder with the awsLambda.rb file as the name of the ruby file inside of it.

9. If using S3, go back to Amazon S3, inside of your bucket, and click on the zip file you want to use, for the function we are currently creating it will be the function.zip zip file. You are going to copy the Object URL and go back to your Lambda Service. We are going to paste that link URL into the Amazon S3 Link URL and Save. If you did not use S3 just upload the zip archive you created inside of your folder saved onto your computer.

10. Next, go down to Basic Settings of your Lambda function and find the Handler. We need to set this to awsLambda.get_timestamp for this function. When using Lambda, the first part of your handler will be the name of the ruby document and the second part will be the name of the specific function you want to invoke.

11. Encryting Environment Variables
For our awsLambda.rb file there are going to be 7 environment variables that we need to supply for each function using this file. The seven environment variables with the values that I have to go along with each one are going to be:

cognito_region = ap-northeast-1
dynamodb_region = ap-northeast-2
email_sender = (any active email address)
invitation_table = Invitation
ses_region = ap-northeast-2
user_activities_table = UserActivities
user_id_pool = (user id pool value)

$ aws kms encrypt --key-id *place your key id* --plaintext *environment variable value* --region *kms key region*
                                            
$ aws kms encrypt --key-id 11111111-2222-xxxx-yyyy-abcdefghijkl --plaintext ap-northeast-1 --region ap-northeast-2
$ aws kms encrypt --key-id 11111111-2222-xxxx-yyyy-abcdefghijkl --plaintext ap-northeast-2 --region ap-northeast-2
$ aws kms encrypt --key-id 11111111-2222-xxxx-yyyy-abcdefghijkl --plaintext support@multiplayscape.com --region ap-northeast-2
$ aws kms encrypt --key-id 11111111-2222-xxxx-yyyy-abcdefghijkl --plaintext Invitation --region ap-northeast-2
$ aws kms encrypt --key-id 11111111-2222-xxxx-yyyy-abcdefghijkl --plaintext ap-northeast-2 --region ap-northeast-2
$ aws kms encrypt --key-id 11111111-2222-xxxx-yyyy-abcdefghijkl --plaintext UserActivities --region ap-northeast-2
$ aws kms encrypt --key-id 11111111-2222-xxxx-yyyy-abcdefghijkl --plaintext ap-northeast-1_234567abcd --region ap-northeast-2
                                        

12. In the top right corner you will see a test option. Configure a test event as follows:

For some PC's you will need to use the base64 encoder to encrypt the value of your plain text value in order to run the kms encrypt command. Use this website to encrypt plain text values if you are getting an error when testing your function.

Base64 Encoder

Invoking Timestamp Function Inside Blueprints

1. With our get_timestamp function completely setup inside of Lambda, we are going to take a look at some blueprint code inside of our W_Mainmenu widget blueprint. In order for us to find an accurate latency value for our user inside of each of our gamelift regions with open fleets, we are going to use the get_timestamp function.

2. Starting a Function With Lambda: In order to successfully invoke a Lambda function, we are going to need to Supply The Target and Invoke Request. The target will be the lambda objects we created for each of the regions that we have an active lobby fleet inside of. We will make an invoke request in order to supply the information needed so that our lambda function can run. For this function, all we will need to provide is the name, but in the future we will use the body section of the invoke request to supply variables to our function so that it runs successfully. we will go over this more indepth later in the documentation

3. Now when this function runs, we will get the exact world time.

4. In order to access the value returned by the lambda function, we will need to Break The Invoke Result so that we have access to the Payload. The payload will give us the value that is returned by our function.

5. In this section of the blueprints we will run the get_timestamp function twice and obtain access to each of our world time values through our payload. We will then subract the two values in order to obtain a Latency Value that we will store inside of a Game Instance variable so that we can use it to matchmake players later in the project. We will run this function inside of every region that we have a lambda object, which is essentially every region we have an active lobby fleet.

6. We now have successfully set up a Lambda function! Let's move on to the next section to help make more sense of how gamelift is going to work, the most vital service for all of the backend set up that we are doing. We will go more indepth on fleets which should clear up any confusion you have from when I referenced them in this section.

Overview of All Lambda Functions Created

Note: All the functions that are used in this documentation are boxed in. You only need to recreate the functions that are of runtime Ruby (or NodeJS if you would rather use NodeJS, but the functions we included are made in Ruby).

The functions named get_timestamp, get_latence, and invite_friend will come from the awsLambda.rb file. Which means the 7 environment variables for each of these functions will be set up exactly as shown just above.
The remaining functions will all come from the awsLambda_Friend.rb file inside of the friend system folder. You will need to make sure you are uploading the correct S3 bucket or zipfile that contains the function you are trying to create. The handler for these functions will begin awsLambda_Friend.[insertfunctionname]. And the five environment variables for these functions will be:
dynamodb_region = ap-northeast-2
friend_table = Friend
friend_table_byFriendStatus_index = BySubIdStatus
friend_table_byFriendSubId_index = ByFriendSubId
friend_table_bySubId_index = BySubId

Note: Every Environment Variable needs encryting for each function. You can get a better idea of what to do with the video at the top of this section. Also you may need to come back to this section after viewing the DynamoDB introduction section.

We have already in this documenataion given an introduction to Lambda, Gamelift, and Cognito. Now let's do the same thing for Amazon DynamoDB. We are going to use DynamoDB largely in this lobby level as well as the team deathmatch level, so let's go ahead and get started with setting up tables, and how they can be used individually.

Great Introduction For Using DynamoDB Within Our Plugin

Amazon DynamoDB is a fully managed NoSQL database service that allows to create database tables that can store and retrieve any amount of data. It automatically manages the data traffic of tables over multiple servers and maintains performance. It also relieves the customers from the burden of operating and scaling a distributed database. Hence, hardware provisioning, setup, configuration, replication, software patching, cluster scaling, etc. is managed by Amazon.

Differences between No-SQL and SQL Databases

Setting Up A DynamoDB Table

1. Let's first start by taking a look inside of the AWS dynamoDB console interface, then we will move over to look at the blueprints. So go ahead and open up the DynamoDB tab inside of your current region and let's create a new table. For this example we are going to be wroking with the UserActivities table.

2. The first thing you can do is give the table a name. We are going to name the table UserActiuvities since that will be the table that we working with. I will give the table a primary partition key of user_sub and leave the rest of the table as default.
Here is a overview look at how my table will be setup:



3. Now let's go ahead and take a look at some of the more important parts of our dynamodb tables within the AWS console:

Partition Keys
We use primary keys, sort keys, and partition keys within dynamodb to correctly organize our table and manage our items most efficently.

AWS DynamoDB Schema Design

Indexes
Indexes give you access to alternate query patterns, and can speed up queries.



Global Secondary Indexes

Local Secondary Indexes

4. Now let's go ahead and switch over to the blueprints of a UE4 project and go over using the functions available in our plugin.

Update Item
To update an existing item in an Amazon DynamoDB table, you use the UpdateItem operation. You must provide the key of the item that you want to update. You must also provide an update expression, indicating the attributes that you want to modify and the values that you want to assign to them.

Query Item
You must provide the name of the partition key attribute and a single value for that attribute. Query returns all items with that partition key value. Optionally, you can provide a sort key attribute and use a comparison operator to refine the search results.

Using Update & Query Events Inside of blueprints

Getting Started With Gamelift

1. Download Amazon Gamelift Server SDK

2. Throughout the setup of the Example Project & this documentation, there will be Many Things that need to be done Using Gamelift, including uploaing server builds to gamelift, matchmaking players based on skill/latency, getting players into each others party inside of lobby levels, as well as many other things, but for now, just be sure you have an understanding of the Structure of how the Gamelift Service Functions and we will handle each of these events one at a time.

Connecting To Lobby Level

Inside of the W_Mainmenu widget blueprint there are a few things I'd like to explain before moving on to the lobby level. First of all you will see that I run a getUser function in order to obtain the users sub id. I do this and set that value as the Creatorid so that once in the lobby level, where players can join each others party, I always know who is the party leader. You will also see that I set a game instance variable of Lobby Game Session ID, this will also be used so that I can easily provide a player attempting to join another players party with the correct lobby game session id. Okay, now let's move on to the Lobby Level!

Introduction to Advanced Matchmaking

Matchmaking Test

Example of Setting Up Gamelift for Different Game Types

Let's go ahead and get started looking over the Lobby level by going over a couple different blueprints involved in our World Settings for this level. We will take a look at the Event Pre-Constructs/Event Begin Play Functions for our Lobby Player Controller, Lobby Game Mode, Lobby Character and the Main Widget controlling our Lobby Layout, W_Lobby.

Lobby GM

Inside of the LobbyGM, off of the event begin play, you will see that we first Initialize the SDK, this should be done before the server starts, and since our lobby will be hosted on a gamelift server, we need to Init SDK for it. The next thing we do is Construct Our Process Parameters, this is done so that our Unreal Appliction can communicate with our Gamelift Console as I went over earlier in the documentation. Then finally we will run Process Ready to signal to Gamelift that we are ready to accept game sessions. As always we want to print string any errors that we receive so that we can quickly find what is causing our problem.

Lobby PC

Inside of the LobbyPC, you will see that we use event begin play to Create the W_Lobby Widget and add it to the players viewport.

Lobby Character

Inside of the Lobby character, let's go ahead and take a look at the Event Begin Play, which is going to be used to set some more information about the user who has connected, especially making sure that our server and other users have access to necessary information.

1. We are going to make sure we have a variable that we can reference for our game instance, as we always do for any blueprint that is going to need to reference multiple variables in our game instance. 2. Next, we are going to get the Latency Valuesfor the user and make sure to replicate the variable information to the server, and then multicast it to all clients in the lobby, so that when users are matchmaking in a lobby with more than just themselves, they will be able to search for matches with all members of the lobby's specific latency values taken into account.

3. The next function run is Set Player Id. The sub value of our user attributes is the same as finding the username for the user. We will run this function on the server, and then mulitcast it to all as well. We will also check if the player is the creator of the lobby.

4. Right below that function is the Set Player Name function. Which we will also run on the server and then multicast to all other users in the lobby. This will be the name value in the bottom right corner that shows everyones nickname of who is currently inside of the same lobby.

5. We will then Create a Player Session inside of our specific game session id.

6. Finally, we will run the Set Player Session ID function, which will run on the server and essentially function to Accept The Player Session On The Server. This function is run so that we can have an accurate display of current player sessions inside of a specific game session inside of the gamelift console.

W_lobby Widget

Inside of our W_Lobby Widget, let's go ahead and take a look at the Event Pre-Construct, which is going to set the default values that a user upon entry into our lobby is going to be set with.

1. We are going to make sure we have a variable that we can reference for our game instance, as we always do for any blueprint that is going to need to reference multiple variables in our game instance.

2. The next thing we will deal with is the Region Selector. We will allow an option for every region that we have an active lobby fleet created inside of, and set the default region to the current region saved in the game instance. This region selector will be a combo box, and if you look under the comment of region selector, you will see that any time a user changes the value in this combo box, we will set their current region to the new region they selected, and create a new game session inside of that region.

3. After that, back in the pre-construct function, we are going to set Two Variables: one of them a boolean variable of isCreator and the other of type string to store the UserId. The reason for the isCreator variable is so that we can track who is the party leader if other players join his lobby, which we will get to later. The reason for the UserId variable is so that we have a value we can use for our friend system and party system, to send all of the different invites to the correct place.

4. Next, under the comment bubble "set player username value" we will add the player's username to the screen. This will be dealt with more in the future as a way for players inside of the same looby to all see each others usernames of who is all inside of the party.

5. Under the comment bubble "initialize friend list", we will run two functions, you will understand more of what this is doing when we get to the friend system section of this documentation, but these two functions will set the default displays for our friend system.

6. Under the comment bubble "set defaults", the main thing we will do here is go ahead and set the creator of the lobby as marked ready, because they will have the control to select play.

7. Under the comment bubble "query for the creation of invitation widget", we will run a timer by event to check if the user has received an invitation to join another users lobby.

We are going to set up a system so that users can add friends, and keep a list in a dynamodb table of whether another user is a Accepted Request, Pending Acceptance, or Request Sent. In order to set up this friend system we are going to be using Cognito in order to obtain a users ID Value, Lambda to Communicate with our DynamoDB Table to update upon pressing either the accept, decline, or add friend function inside of our Example Project Template, and DynamoDB to Keep Track of all of our User Relationships. Let's go ahead and get started with the process of making this possible.

1. Let's take a look at how this will look inside of the Example Project. We will currently be using two of the three tabs available to us. The third tab in the middle, I plan to show how to add in friends inside of users steam account, and allow you to be able to invite from there as well. For now though, there will be two tabs, one where all the Users Confirmed Friends will be, and one where the user will be able to Accept Friend Requests that are sent to them. There will also be a search bar to search players by their username, and when this is done, the user will be able to add new friends, if there are any with the username that they searched.

2. Now let's take a look at the dynamodb table set up to keep track of all of this information. The table name I used was Friend and it will have primary partition key of id (string) with no secondary index. This is because the id variable will be unique for each user to user relationship, so there is no need for a secondary sort key. There will be 4 Items for this table, one being the id and the other three being friend status, friend sub id, and sub id all of type string.



We are also going to create 3 Indexes for this table, Indexes give you access to alternate query patterns, and can speed up queries. For list friend functions, I can get a player's friend by using "BySubId" index; get friend request by using "BySubIdFriendStatus" index; get a special friend by using "ByFriendSubId" index. This is why we create three indexes as so:



Learn More About Indexing DynamoDB Tables

3. Next, we are going to go through each feature of the friend system individually, to show how we are able to communicate from a button being pressed inside of our example project, to run the blueprints in order to invoke a lambda function, so that we are able to update/scan our dynamodb table for the information that we need.

• In order to start the process of sending a friend request to another user, the user looking to send a request must use the search bar inside of the example project to search users by a username value.
• Once the user has entered in a username, and pressed the find user button, we will run the list users function with a filter to only look for usernames with the username searched, we will then create a friend request widget for each user that fits within that filter.

• Once a user has searched up a username and a friend request widget is created for that user, there will be a add button next to their name, when that add button is pressed we will then invoke the send_friend_request lambda function.
• Inside of our send_friend_request lambda function the first thing to take a look at is the expression_attribute_values, as you can see we have a friend sub id and sub id, which we are going to use the variables to and from to define inside of our blueprints.
  
  
  
  
  
  
• These variables will be used throughout this send friend request function so that we have access to the user who is sending the friend request and the user that they are sending the friend request to.
• Also you can see we are creating an id for this item inside of our dynamodb table that will be the sub id of the sender of the friend request with a # in the middle, followed by the sub id of who the friend request is being sent to.
  
  
  
  
• When one user sends a friend request, we will update the dynamodb table, so that each individual user has a reference of the current relationship between the two users. The sender will have a relationship status of request_sent, and the receiver of the friend request will have a relationship status of request_received.
  
  
  
  
  
  
• Now, let's move on to the receiver of the friend request, being able to accept or reject the friend request!

• Now if you look again at the three tabs that deal with the friend system, when the user selects the pending invitations tab, all of the friend requests sent to that user will be stored there (We will go over how we configure that to happen a little further down in this section, but this section is just showing how we accept or decline pending friend invitations)
• Let's start with when Add is pressed. Inside of our blueprints all we need do is invoke our lambda function and provide the to and from values for each of the users sub id.
• Then inside of our lambda function, everything should be very similar to the setup we made for the send_friend_request function except this time our name will be accept_friend_request and we will be changing the friend status value inside of our dynamodb table to "accepted_request" for both of the users involved.
• The decline button inside of the example project will run the exact same way as the accept button pressed, only changing the lambda function that is invoked to rejected_friend_request, and this function will set the friend status value to "rejected_request" for each user.

• Upon entrance into the Lobby map, the default tab that will be open will be the friends list tab. Under the event pre-construct you will see a comment bubble called initialize friend list which will run two functions: Switch List and List of Friends.
• Our Switch Lists function will be run to update the display of the UI for our tabs. We have indexed each of the three tabs at the top as well as the search user being defined as its own separate tab, and when a user selects a different tab or searches for a user, we want to be sure our UI is updated. This function will be run everytime we change tabs.
• Next, for our list of friends function, since we are going to show the list of friends tab upon entrance into the lobby map, we are going to need to get a list of all the users current friends. To do this we are going to invoke the list_friends_byfriendstatus lambda function by checking our table for all friends with the friend status set as accepted_request.
• Let's take a quick look at this lambda function we are going to be running. Basically all that is happening here is we are inputing the friend_status that we want to get all the username values that are matches for the specific user that is invoking the function.
  
  
  
  
  
  
• This function will also need to be run every time we switch back to the friends list tab after going to a separate tab. For example: if a user checks their pending invites and then goes back to the friend tab, we will run this function in order to display the accurate list.
• The pendinginviteupdate function will function almost the exact same way as the list of friends function for the pending invites tab inside of the friends tab. The only difference is that our list_friends_byfriendstatus lambda function is going to be looking for a friend status of received_request.
• We will also need to update these lists every time a friend request is sent, accepted, or declined. If you look inside of the W_pendinginvitation at the end of both the accept and decline functions, we will be running the update lists function. We will provide an index which will decide which lists need to be updated. For example: if the user accepts a friend, we need to remove that user from the pending invites and add them to the friends list, so we will run both functions to update both of those lists.

Now that we see how to setup our friend system, we need to have a party system in place so that users will be able to Invite Their Friends to games and Play Together. The process for doing this is quite similar to how we did the setup for our Friend System. We are going to use lambda functions to communicate between our blueprints and an invitation dynamodb table. So, let's go ahead and get started with how we are going to set this up!

Let's go ahead and setup our Invitation DynamoDB table. For this table we are going to have two items, to-user-sub and expire-time.

• Once 2 users have successfully completed the process of adding each other as friends, inside of the friends tab, the user will have a widget display of the other user with an invite option next to their username.
• When that invite option is pressed, we will invoke the invite_friend lambda function, where we will provide each of the users userid, the current region for the inviter and their lobby game session id.
• Inside of our invite_friend lambda function, this information will allow us to write to our invitation dynamodb table and use put item, we do this so that when we are querying our dynamodb table to see if an invitation has arrived we will be able to see that one has.
  
  
  
  

• Now back inside of the Example Project, let's look inside of the event construst of our W_lobby widget blueprint. Under the comment bubble 'query for the creation of the invitation widget' you will see that every 5 seconds we are checking to see if any invitation has arrived for the specific user. If an invitation has arrived, the user will have a invitation widget pop up on their screen.
• The invitation widget will give the user the username of who is sending the invite with an option to join game or decline the invite.
  
  
  
  
• When decline is pressed or after waiting 8 seconds without selecting anything, the widget will just be removed from the users screen.
• When accept is selected, we will get the game session id from the sender of the invitation, and place the users together into the same lobby game session.

• Now that more than one player are inside of the same lobby, we need to update the play group box, so that every player in the lobby sees every other players username that is also inside of the same lobby.
• To do this, let's take a look inside of the lobby character. On event begin play, we run a function called set player name which is going to run on the server.
• This event will trigger a multicast player name function, meaning everything done by that function will replicate to all other players in the lobby. This function will trigger the add player function that is run inside of the w_lobby widget blueprint.
• In this function, we will create a group user widget for the user who just joined, and since this is run from a multicasted function, every user in the lobby will have every other user in the lobbys username displayed.

In order to get started with the entire matchmaking system that has been put into place, we are going to begin by going through the blueprints that are setup to make it possible before configuring everything inside of AWS.

Ready State Changed

Users will be able to ready up and un ready up in order to show other users in their lobby that they are ready to play the game. You can choose whether or not this is something you want to include in your own game, also you can design your own rule to allow all players to be matchmade when over 50% of users in a lobby have ready'd up or something like that. Inside of the W_groupUser widget blueprint, in order for other players to see the checkmark next to each users name to know if the ready up, we use the boolean ready value inside of the lobby character.

play button is pressed

Inside of this comment bubble the rest of the blueprints will be taken care of to setup matchmaking, and I am going to go through each step of what is taking place because this can be a quite confusing process to follow.

1. When the readyplaybutton is pressed, the first variable we need to take into account is whether they are the creator of the lobby. If the user is not the creator, all that needs to be done is update their ready staus, if they are currently ready we will change their status to unready, and vice versa. If the user is the creator of the lobby we will move on to the next step of beginning matchmaking.

2. The next step is to get all lobby characters in the lobby, this way we can loop through each individual user in the lobby to obtain the necessary information needed for our matchmaking configurations.

3. The next step is to make an AWSplayer for each user inside of our lobby. This is where we will fill in the latency for each player, their player attributes such as skill level, which we will discuss more later on, if they will be on a specific team, and the playerid for the user. All this information will be extremely crucial for setting up matchmaking configurations which we will dive deeper into in the Configuring with AWS in the next section.

4. You will then see we will enter a gate, this gate will function to close if not all users are ready'd up and will prevent us from starting matchmaking, as long as all users are ready'd up, we will have obtained all necessary information for the AWSplayer, and we will continue through the gate.

5. We will then set a ticketid and start matchmaking. If you take a look under the startmatchmakingrequest, the ticket id will be a unique identifier for the matchmaking ticket, and the matchmaking configuration name will specify how we will specifically matchmake players into games together. Again, we will take a more in-depth look at this in the next section.

6. Next, we will sync the matchmaking ticket with all other users in the lobby and begin looping each 5 seconds for a matchmaking result.

7. Once a match has been found that satisfies the matchmaking configuration rules, we set the matched result which will store the game session arn, ip address, dns name, and port. Then we will sync the ticketid name for the matched result to all users in the lobby.

8. From there, we are going to sync every player session id and game session id so that all players matched into the same game together all have their information synced to the server. Then the new level will appear and the Unreal Gamemode that is setup will take over from there.

Now let's get our project ready to be uploaded to Gamelift. Before we are able to do that though, we need to make sure our list of maps to include in our packaged build is setup. To do this go to your project Settings and search maps. You will provide each the folder location to each map as so:



With this done, we can go ahead and begin the process of uploading each of our 2 servers (lobby and game map) to gamelift. So let's go ahead and get started!

In order to get started we need to go over the different ways that we can upload to Gamelift. We can do a standard Windows upload, a Linux upload through a Virtual Machine, or a Windows subsystem Linux upload. Long term I highly recommend using Linux to upload your builds as it cheaper than windows using either of the 2 options other than the standard windows upload. Windows is most likely the easiest for beginners, as most likely your computer is already setup to handle windows uploads.

We will also have the otion of using Spot vs On Demand resources. We will get in to this more later but you should go ahead and get an idea of the differences between the two. With On-Demand instances, you pay for compute capacity by the hour or the second depending on which instances you run. No longer-term commitments or upfront payments are needed. You can increase or decrease your compute capacity depending on the demands of your application and only pay the specified per hourly rates for the instance you use. Amazon EC2 Spot instances allow you to request spare Amazon EC2 computing capacity for up to 90% off the On-Demand price.

Just to give you an idea on pricing: a m5.large Linux Spot fleet is estimated to cost $9.29 per month with autoscaling, while a Linux On Demand fleet it is estimated to cost $44.53 per month, while as a Windows Spot Fleet it is estimated to cost $49.06 per month, and as a Windows On Demand is estimated at $84.68 per month. So there is definitely a noticable difference in cost.

Learn More About Linux vs Windows & On Demand vs Spot Fleets

$ cd Downloads
$ ls
$ unzip GameLift_12_14_2018.zip         
                                        

$ aws gamelift upload-build --operating-system WINDOWS_2012 --build-root "D:\[Project Name]\Saved\StagedBuilds\WindowsServer" --name "[Any Name You Want]" --build-version "1.0" --region [Your Region] 
                                        

• Memory Size: 4096MB
• Hard Disk: Create a Virtual Hard Disk
• Hard Disk File Type: VDI
• Storage: Dynamically Allocated
• Location and Size:16GB

• sudo dnf install sshd
• sudo dnf search ssh
• sudo dnf install openssh-server

$ aws gamelift upload-build --operating-system AMAZON_LINUX --build-root "C:\Users\myles\[Project Name]\Saved\StagedBuilds\LinuxServer" --name "[Any Name You Want]" --build-version "build 1" --region [Your Region]
                                        

$ sudo apt install openssh                   
                                        

$ sudo apt search openssh                   
                                        

$ sudo apt install openssh-server
                                        
$ sudo apt search openshh-server
                                        

$ sudo service ssh start
                                        
$ sudo service ssh status
                                        

$ aws gamelift upload-build --operating-system AMAZON_LINUX --build-root "C:\Users\myles\[Project Name]\Saved\StagedBuilds\LinuxServer" --name "[Any Name You Want]" --build-version "build 1" --region [Your Region]
                                        

Now in order to setup our Matchmaking Configurations inside of Gamelift to effectively matchmake players into game sessions, we need to obtain a full understanding of the step by step process for how we get to the point of having a matchmaking configuration name that we supply into our blueprints when we run start matchmaking. I would highly recommend you check out this Matchmaking Test Video before reading any further in this section. It will give you a solid base understanding of all the different sub services inside of gamelift.

Setting Up In AWS Console

1. So now you've seen the different ways that you can upload to Gamelift. For this Example Project we are going to upload two servers, one server will have the lobby level as our default server map and one server will have our game map as the default server map.

2. Now inside of the AWS console, choose the gamelift section and take a look at your dashboard. You should see a builds area, fleets area, and aliases area. Under the builds area, you should see the builds you have uploaded.



3. So now we need to create a fleet for that build. In order to do this, select create fleet and give it a name and description. Then you will need to choose between On-Demand and Spot fleets.

On Demand Fleets
With On-Demand instances, you pay for compute capacity by the hour or the second depending on which instances you run. No longer-term commitments or upfront payments are needed. You can increase or decrease your compute capacity depending on the demands of your application and only pay the specified per hourly rates for the instance you use.

Spot Fleets
Amazon EC2 Spot instances allow you to request spare Amazon EC2 computing capacity for up to 90% off the On-Demand price.

Learn More On Demand & Spot Fleets

4. Next, you need to select the build that you uploaded to go with your fleet. From there, you will decide the instance type for your fleet. The instance type you choose to select will be determined by how many players are going to be inside of the same map at one time. You will need to do stress testing to figure out what type works best for you. For most testing, especially in the beginning stages, using the free tier eligible instance type should work.



5. Next up we have the server process allocation. The launch path will be dependent on whether you did a Linux or Windows upload, but for either one you should treat \game\ as your WindowsServer folder. From there we need to get to the executable file:

Windows
[YourProjectName]\Binaries\Win64\[ProjectName]Server.exe

Linux
[YourProjectName]\Binaries\Win64\[ProjectName]Server

6. For the Concurrent processes I set the value to 20. Then in the next section for max concurrent game sessions I set that max value to 20. Basically this means that I can have 20 game sessions going on inside of my fleet, with 20 players inside of each of those game sessions. Again this is something you should stress test in order to maximize the amount of users that can run your project smoothly inside of one fleet.

7. We need to add 2 port settings: one for UDP and one for TCP. The port range for UDP will be 7777-7796 using 0.0.0.0/0 for the ip address range. The port range for TCP will be 3389 using 0.0.0.0/0. We use the TCP protocol in order to be able to remotely access our server. We use the UDP protocol to host each of our instances.

8. Now our fleet is complete. Let's create an alias to go along with it. Just give your alias a name and description and connect to the fleet that we created.

9. Next, we need to create our Queue. This is where we will have our fleet destinations for our Team Deathmatch Game Map. Currently we only have our one alias associated with our game map that we are going to add to our destination, but this is where you can take advantages of cost savings by having spot and on-demand fleets, and your queue will sort through when it is safe to put users into a spot fleet rather than an on-demand fleet. You can also create mandatory player latency policies, but for this example I do not create any.

Learn More About Queues

10. Writing Matchmaking Rule Sets

Now, we get to the part where most of you are most likely most curious to learn about. We will create a Matchmaking Rule Set. Inside of the project that you downloaded from Github you will find that there is a notepad document name MatchmakingRule where we have our example rule set.



Now the way that this is able to interact with the project is the level attribute. When we make AWS players inside of our blueprints, we will make a gamelift attribute value called "level" that is also used inside of the "rules" sector of our rule set. This level attribute can be anything that has to do with your game. For Example: A k/d value or elo value, or any other algorithm that you come up with yourself that you want to use to matchmake users of your game. In order to create a matchmaking rule set, you will just go to the matchmaking rule sets, give your rule set a name, and copy all the information in the notepad document to the rule set.

11. Next we will create a Matchmaking Configuration to tie everything together. You'll have to give your configuration a name, you can add a description, we'll provide the queue that we created, the rule set that we created, I set the request timeout to 60 seconds, backfill mode to automatic, and left everything else as the default that was already provided for it.

Then, since the queue has access to all the fleet/alias destinations and your rule set decides how users will be matchmade together, we have successfully set up our matchmaking. And if you look inside of your blueprints all we need to provide is the matchmaking configuration name and then AWS will take care of the rest.