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
Download Gamelift SDK
1.
Gamelift Managed Servers SDK
2. Now you'll need to run some commands in the Terminal (Windows/Linux) you decide to end up using. If you are using Windows, you can go ahead and do this now inside of cmd or powershell. If you are using Linux VM, you'll need to have your Fedora Terminal setup before you can run these commands. If you are using WSL, go ahead and run these through the debian application:
$ cd Downloads
$ ls
$ unzip GameLift_12_14_2018.zip
Windows Upload
1. Let's go ahead and begin with the Windows upload as it should a bit more straightforward compared to the linux uploads. The first thing we need to do is setup our maps. We are going to build a server for both the lobby level, as well as the firstpersonexamplemap level. Let's start with first the lobby map.
2. So go to project settings β Maps and make sure that our server default map is set to Lobby Level.
3. Next, let's open up our project launcher, go to Window β Project Launcher.
4. Then in the top right corner, make sure you have the advanced options toggle enabled. Now you should have a device that is your computer, with a name like DESKTOP-XXXXXX.
5. For that device we are going to set the variant to WindowsServer, the config to Development, and the DataBuild to bythebook. Then you can go ahead and press launch. The first time you do this it may take roughly 30-45 minutes, but once you have built one server, it will go much faster in the future.
6. Now go inside of the root folder of where your project is located on your computer. Go to Saved β StagedBuilds and you should see a folder titled WindowsServer. This is going to be the folder that we are going to upload to Gamelift.
7. Next, there are some files that we need to add inside of this server folder so that gamelift can understand what to do with our files once uploaded. When you downloaded the Example Project from github there is a folder titled Required Files, inside of that folder open the Windows folder, and place them inside of the WindowsServer folder.
8. We are now ready to upload our Server build to Amazon Gamelift, you need to open up a command line or power shell and run the following command (Remember you must have aws command line installed for this command to work as was showed earlier in the documentation)
$ 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]
9. Now you have successfully uploaded Windows Server to amazon Gamelift, let's move on to Linux!
Linux Using Virtual Machine Upload
1.
Download Virtual Box
Virtual Box is going to function as our virtualization tool for our operating system.
2.
Download Fedora Workstation
Fedora is going to function as our Linux Operating System. Download the one that is not the media writer.
3.
Download Cross Compilation Tools For Your UE4 Engine Version
Cross-compilation makes it possible for game developers, working in a Windows-centric workflow, to target Linux.
4. Search edit system environment variables in your control panel. Under the advanced tab click on Environment Variables.
5. Under system variables select new. We are going to create a environment variable with name LINUX_MULTIARCH_Root and the path will be inside of the unreal tool chains folder that we just downloaded to cross compile. It should be something like C:\UnrealToolchains\v15_clang-8.0.1-centos7.
6. Go ahead and open up the virtual box application that we downloaded. Once open we are going to need to select the new option. I went ahead and gave mine the name Fedora and then save it to a spot on your computer.
7. For the rest of the settings I set up as so:
- Memory Size: 4096MB
- Hard Disk: Create a Virtual Hard Disk
- Hard Disk File Type: VDI
- Storage: Dynamically Allocated
- Location and Size:16GB
8. Now open up the settings for that virtual machine we just created. Go to storage, and click the blue disk next to optical drive and select that fedora-workstation-live that we downloaded earlier, then click okay.
9. Next, click on tools and choose create. This will give us a host-only ethernet adapter.
10. Now back to the Fedora VM, choose settings and go to Network. Select host-only adapter under Attached to with name VirtualBox host-only Ethernet Adapter. Click okay.
11. Click Start, and you'll need to set up a personal account. Make sure you select the ATA VBOX HARDDISK for your installation destination.
12. Back inside of Fedora VM Settings, we are going to remove disk from virtual drive inside of storage that we set up earlier. And then choose start again.
13. You will get asked if you want to run software intended to autimatically start choose yes, when it asks if you wish to continue type yes.
14. Open up the Fedora terminal and run the command $ ifconfig. Then find the inet value for the enp0s8. Inside of your command line run ssh [Name before @localhost]@[inet value]. Should look something like ssh mylesdobbs@192.168.56.102, then enter your password.
If you have any problems with the setup at this point try running the following commands to solve the problem and retry this step in your command line again after:
- sudo dnf install sshd
- sudo dnf search ssh
- sudo dnf install openssh-server
15. Get the toolchain we uinstalled earlier into our engine. To do this you will go to your engine, run the setup.bat file, the generateprojectfiles.bat file, and then build the ue4.sln file, the same process we followed when installing the plugin to our engine.
16. Now let's add our device inside of our Example Project inside of Unreal. Go to Device Manager, and expand the add an unlisted device tab. Our platform will be Linux server (this will only be available if you rebuild your engine with unreal toolchain), the device identifier will be that inet number, then you can choose any display name, and finally you will use the username and password from your account we just created earlier.
17. Now we can follow many of the same steps as the Windows section, we will build the server only now changing the device we use to that Linux Server we just created.
18. You won't need to supply the WindowsRequiredFiles inside of the Server folder but you will need to modify a install.sh file and place it inside of the Server folder.
Modifying Install.sh File
19. Then we can upload to Gamelift, the command for Linux will be as follows (do this in your cmd line or windows powershell):
$ 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]
Linux Using Windows Subsystem Linux
1. The benefit of using a windows subsystem linux is that it uses less memory and you don't need to override the ip when using gamelift local.
2. Go to the Microsoft Store and download the app Debian. Then go ahead and launch it.

3. Then go ahead and run the following command:
$ sudo apt install openssh
If it is already installed then all you need to do is search for it:
$ sudo apt search openssh
Next, let's just go ahead and do the same thing but for the ssh server. Install and search for it.
$ sudo apt install openssh-server
$ sudo apt search openshh-server
And now we can go ahead and get our ssh running:
$ sudo service ssh start
$ sudo service ssh status
Make sure you get told sshd is running.
4. Next, we can go ahead and set up our device inside of our device manager in our Unreal Project. If you have not set up cross-compilation as was showed in the Linux with Virtual Machine in the previous section, go check that and make sure you follow all steps so that when you add a new device, Linux Server will be an option.
5. Inside of the device manager, we are going to add a new device. The device identifier will be your local computer or value of 127.0.0.1. You can give a display name, and then I used the same username and password for the login of my PC (One other thing that you may want to check before creating a new device is to check if the nat bridge is working. Run the command "ip a" inside of your debian application, and check the inet value under eth0. It should read 10.0.0.6. (If it reads 169.254.0.1/16 then it is not working).
6. Now we can follow many of the same steps as the Windows/VM Linux section, we will build the server only now changing the device we use to that Linux Server we just created.
7. You won't need to supply the WindowsRequiredFiles inside of the Server folder but you will need to modify a install.sh file and place it inside of the Server folder.
Modifying Install.sh File
8. Then we can upload to Gamelift, the command for Linux will be as follows (do this in your cmd line or windows powershell):
$ 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.
Matching Players Using an Elo Value
This section will be completed upon the release of the Team DeathMatch Example Project (very soon) so that we can show the entire process of obtaining an elo value from a Team Deathmatch game mode and then using it to matchmake players.
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.
