AWS Gamelift Simplified

• Game Backend Service

  In addition to GameLift, you always need to host a backend service for your game. The backend will use GameLift APIs to initiate matchmaking and request game session placement. Popular options for game backend hosting include serverless backends with Amazon API Gateway and AWS Lambda, or container-based backends with Elastic Load Balancing and Amazon ECS. Backend service can also be called as API Service which will call GameLift API’s. This can be integrated with backend server of game.

• GameLift Fleets

  This is the actual fleet of EC2 instances hosted by GameLift, which is running your game server build with your defined configuration and scaling logic. GameLift fleet will be the actual game servers which will relay the data from one user to another. When created the Game Build, the build is deployed on these servers which are scaled and managed by GameLift Service.

Points to be noted

1. Many of us get confused while reading the documentation around the terms Client, Backend Server and Game Server. Let’s clear the confusion, below:
   • Client is the actual game on Mobile device.
   • Backend Server calls the GameLift API’s, and it has nothing to do with the actual gameplay. It just helps to set the game including matchmaking, requesting game sessions, etc.
   • Game Server is actual game server which will relay the actual game data. It has all the gaming logic.
2. It is best practice to not call AWS GameLift API’s directly from Mobile Device since there is no authentication mechanism provided by AWS GameLift. Instead, integrate GameLift API’s in backend server by which the request will only come from authenticated users.
3. Game Server creation and termination are decided by AWS GameLift FleetIQ ViabilityAlgorithm
4. Following are the parameters provided once the game session is created:
   • IP Address and Port (It’s IP of Game server on which the session is placed. The client will be connected to this IP and Port for gameplay.)
5. AWS GameLift Custom game servers supports following languages:
   • C++
   • C++ for Unreal Engines
   • C#
6. Game engines – Amazon Lumberyard, Unreal Engine, Unity, engines that support C++ or C# libraries

• AWS GameLift Realtime servers use TCP and UDP for messaging.
• A Realtime server is set up to communicate with the GameLift service, which triggers the Realtime server to start game sessions, validate players when they connect, and collects player connection status and game health state from the game server. In contrast, this functionality must be implemented in a custom game server.
• A Realtime script provides configuration settings and optional custom game logic for your game. The script may contain minimal configuration settings or have more complex game logic. The Realtime script is deployed along with the Realtime server when starting up new hosting resources. Scripts are written in Node.js-based JavaScript.
• In Realtime Servers, Game server is already built-in inside the fleet , so there is no need to worry about developing the game server as in Custom Game Servers. In most of the cases, Fleet (EC2 Servers) will only act as message relay servers without doing any processing.

In which scenarios one should think of using Realtime Servers?

• Where there is no server processing included.
• Where most of complex processing is happening on Mobile Devices.
• Where servers are only needed to relay data from one device to another device.

Points to be noted:

1. There is no special realtime capability in Realtime servers. There is no latency advantage when used Realtime server compared with GameLift Custom Server.
2. Realtime Server Client SDK is used to communicate with Realtime Server on Client Device
3. Realtime Script can only be written in Node.js language.
4. AWS GameLift Realtime Script can be deployed on Spot Instances as well as On-Demand instances
5. Realtime Server Client SDK is only in C#. So game builds which are developed other than C# cannot user Realtime Server capability and will have to use GameLift Custom Server.
6. Realtime Server works only for Unity and engines that support C# libraries.

When to use:

• Have existing AWS deployments or want to use Amazon EC2 directly rather than through the fully managed GameLift service. GameLift FleetIQ works with Auto Scaling groups that you manage in your AWS account, giving you full access to your Amazon EC2 instances and groups. You can also integrate with other AWS services, including Amazon Elastic Container Service, Amazon Elastic Kubernetes Service, and AWS Shield Advanced.
• Have existing on-premises game hosting and want to extend capacity to the cloud. With GameLift FleetIQ, you can build a hybrid deployment system that uses your on-premises capacity and incrementally adds AWS cloud capacity as needed.

Points to be noted:

1. When using GameLift FleetIQ, you prepare to launch Amazon EC2 instances as usual: make an Amazon Machine Image (AMI) with your game server software, create an Amazon EC2 launch template, and define configuration settings for an Auto Scaling group. However, instead of creating an Auto Scaling group directly, you create a GameLift FleetIQ game server group with your Amazon EC2 and Auto Scaling resources and configuration.
2. By using FleetIQ, we get complete control to our EC2 instances. It can be seen in EC2 console, which is not in the case of Custom Servers and Realtime Servers. Both the above servers are managed by GameLift and are not accessible.
3. When new server is created by auto scaling group, it first needs to register itself to GameLift Service.
4. When the instance spawn up, it calls AWS SDK function RegisterGameServer(), which informs GameLift Service about the new instance. FleetIQ Viability Algorithm then keeps note of it and mark it as available. New game sessions can now be hosted on that Game Server.
5. Same goes while terminating the Instance. In order to gracefully terminate the instance, it needs to inform to GameLift Service that the instance will no longer be available to host new game sessions. For this, it calls DeregisterGameServer() function which deregisters it and make it unavailable to host new game sessions.
6. GameLift FleetIQ works best when it is constantly directing players onto instances that are least likely to have game session interruptions. Maintaining long-lived sessions interferes with the GameLift FleetIQ balancing process, which increases the likelihood that games sessions might be interrupted