Fleet IQ - Working

FleetIQ was named after the Spot viability logic from GameLift Queues and Fleets. This feature is for customers looking for a less managed version of GameLift where customers have more control of the AutoScalingGroup and what happens on the instances. A GameServerGroup creates an AutoScalingGroup in your account. At that point, you can directly update the launch template on the ASG, add scaling policies, SSH onto your EC2 instances, whatever you need to run your game.

The main benefits a GameServerGroup provides:

• Spot viability management. GameLift will continuously monitor the instance types / availability zones for Spot viability and modify your AutoScalingGroup so players are less likely to see Spot interruptions, but still utilizing Spot for cost savings.
• Game server management. When server processes are ready to host a game session, they should register with GameLift via RegisterGameServer. When your matchmaker is ready to place a match, it can call ClaimGameServer in order to get an available game server (including any ConnectionInfo or GameSessionData you want to provide) and connect players to that process.
• ClaimGameServer also performs AutoScaling instance protection (if enabled) and game session packing to make sure your instances are full rather than spreading game sessions across all instances. This provides more cost savings since AutoScaling can scale in faster as player traffic comes down.

What happens on each instance is up to you. As you mentioned, with more control comes more responsibility with this feature. You can use Kubernetes/Agones (https://aws.amazon.com/blogs/gametech/introducing-the-gamelift-fleetiq-adapter-for-agones/), other 3rd party process management, or create your own process manager to run on each instance. If you want GameLift to manage processes on each instance, that's more in-line with what a GameLift Fleet provides.

I would recommend reading EC2 metadata to get the IP address/port your process is using and provide that info in RegisterGameServer as the ConnectionInfo. When your matchmaker calls ClaimGameServer, it will then have the IP/port needed for players to connect to the process.

GameServerData can be used either as a way for your server process to send data to your backend service when it calls ClaimGameServer, or your backend service can pass GameServerData in the ClaimGameServer request to the server process on the instance.

Hopefully that clears up this feature for you, let me know if you have any more questions.

Hey Joe, Thanks for your response but I am still not able to understand how the concurrency of my game session will be managed? For example, Let's assume I have baked my AMI and on Boot, I start 3 Game Servers (Let's assume there is only one EC2 Instance ), I call RegisterGameServer from all the 3 and all of them are healthy state after this Match Maker wants to start a game session on a gameGame session activation server it will call ClaimGameServer API, Now the question is :

• Who and How it will be decided that on which game server the session needs to be placed.

• If a new game session is requested assuming my first session is full with all the players, how that will be started and on which game server, who takes this decision? like on which game server it should be started etc

• How and Who manages the concurrent game sessions on a single-game server? Example in the GameLift Hosting Solution , I have the option to provide Concurrent Process and Game session activation , How can I achieve this in Fleet IQ in my custom game. For Concurrent Process this will fall under my bucket to call RegisterGameServer and control concurrent process, but how and who will take care or control of the concurrent game session in a single process.

I'll start with this before answering your questions. One of the benefits to GameLift not having any code on the instance is the flexibility of how you use GameServers.

• GameServer == Instance. Customers can register/claim/health check treating a GameServer like an EC2 Instance in order to get instance protection and metrics based on instance utilization. Customers are then responsible for process and game session management with their backend matchmaker. You can think of ClaimGameServer as ClaimInstance if implemented this way.
• GameServer == Process. Customers can register/claim/health check each process on each instance. This is great if you run 1 game session per process or if your matchmaker already handles sending multiple game sessions to a single process. You can think of ClaimGameServer as ClaimProcess with this implementation.
• GameServer == GameSession. Customers can register/claim/health check each game session they want to run. If you have a single process that runs 100 game sessions on an instance, that process can call RegisterGameServer 100x and ClaimGameServer becomes equivalent to ClaimGameSession.

Who and How it will be decided that on which game server the session needs to be placed?

• GameLift decides within ClaimGameServer which game server is chosen. GameLift prioritizes game servers by age, state, and packing onto instances. If you've registered 3 game servers on 1 instance, ClaimGameServer will return gameServer-1 the first time you call that API, gameServer-2 the second time, etc.

If a new game session is requested assuming my first session is full with all the players, how that will be started and on which game server, who takes this decision? like on which game server it should be started etc?

• In your example, you've registered 3 game servers with GameLift, with unique GameServerIds, let's say gameServer-1, gameServer-2, gameServer-3. The first time your matchmaker calls ClaimGameServer, GameLift will return gameServer-1. gameServer-1 will now have ClaimStatus CLAIMED and will not be chosen by ClaimGameServer again until ClaimStatus is reset 60 seconds later. This means your matchmaker has 60 seconds to connect players to the host using the ConnectionInfo on the GameServer object and either the matchmaker or the process itself must call UpdateGameServer and set the UtilizationStatus to UTILIZED. This tells GameLift that the GameServer is busy and the GameServer will not be chosen by ClaimGameServer again. ClaimGameServer only returns GameServers with UtilizationStatus AVAILABLE and without a ClaimStatus.
• There's a nice visualization of calling ClaimGameServer / UpdateGameServer here: https://docs.aws.amazon.com/gamelift/latest/fleetiqguide/gsg-lifecycle.html#gsg-howitworks-lifecycle-gameserver

How and Who manages the concurrent game sessions on a single-game server? Example in the GameLift Hosting Solution , I have the option to provide Concurrent Process and Game session activation , How can I achieve this in Fleet IQ in my custom game. For Concurrent Process this will fall under my bucket to call RegisterGameServer and control concurrent process, but how and who will take care or control of the concurrent game session in a single process.

• Concurrent process activations and all the general process management is up to you. GameLift doesn't do anything on the instance, so that's all your responsibility.
• I think you're referring to a single process running multiple game sessions. You can manage that or you can have GameLift manage that based on your implementation. Sticking with the example, you have 1 instance with 3 processes and each of your processes should run 5 game sessions each for a total of 15 game sessions on the instance.
• • If you want to manage game sessions, when your matchmaker picks a GameServer, your matchmaker should send the next 5 matches to that GameServer until your matchmaker needs a new process to place on, then it can call ClaimGameServer again.
• • If you want GameLift to manage game sessions, your process can call RegisterGameServer 5 times. I would recommend setting ConnectionInfo to "ip:1.2.3.4,port:5555,gameSession:1". Now every time your matchmaker wants to place a match, it can call ClaimGameServer to retrieve a GameServer object and the ConnectionInfo will have the ip, port, and game session number.