Gamelift includes a server hosting service, a latency base game session placement service and a matchmaking service. Server hosting service will help us host our game server on virtual private cloud, also known as vpc, and manage each game server on each vpc instance base on game session and player session. Latency base game session placement will help us find the best region to place the game session base on the latency between client and server we provide. Matchmaking service is based on the latency base game session placement service, it can help us match players or teams base on the ruleset we defined.
server side initialize
Gamelift service will start processes in gamelift vpc instances from the game server we built. Then, gamelift service will need to get some infos and controls of our game server processes to help us hosting and managing our server processes.
At the start of each game server process, we need to call init sdk to initiate the communication between gamelift and our game server process.
Then, we need to construct a process parameter with port, log paths to tell gamelift which port this game server process is using, so that we can get the port in the game session details, which log file this game server process is writing, so that gamelift can save the log file for us. We also need to open the ports when we create the fleet.
If we set up log paths for the process parameter properly, we should be able to download the server log from terminated game sessions.
We can also create a subclass from the basic process parameter class to override some of its events or functions.
After that, we need to call process ready with process parameter to tell gamelift service this process is ready to service.
After the process ready is called, gamelift service will keep triggering health check function in the process parameter we provided. We need to return healthy on the server if it's triggered. The base class of Process parameter's health check function already always return true. So, if we don't override this function, we don't need to worry.
If healthy check keep returning false or your server process takes too much time to tick and can't get a chance to report health check, gamelift service will trigger the game server process's process terminate event in the process parameter we provided. We need to make sure the game server process is ready to be ended in a few minutes. The base class of Process parameter's process terminate already call process ending and quit server with false. So, if we don't override this function, we don't need to worry.
create gamelift object
To access gamelift service, we need to create a gamelift object on client side.
Access key id and secret key credentials is required by all gamelift client side nodes. We can get access key id and secret key from pre-created IAM user or get allocated from cognito identity pool.
fleet
Gamelift service will host our game server on vpc instances. We can treat each vpc instance as a personal computer, but it's virtual. A group of these vpc instances is called fleet.
We need to provide a build of our game server to create a fleet. We can use this command to upload the build.
aws gamelift upload-build --name <your build name> --build-version <your build number> --build-root <local build path> --operating-system <WINDOWS_2012 / AMAZON_LINUX / AMAZON_LINUX_2> --region ap-northeast-2
Each vpc instance in the fleet is called fleet instance. We can change how many fleet instances in a fleet after we created the fleet or just let auto scaling to handle it.
In each fleet instance, gamelift service will start a constant number of game server processes from the build we provided. We can set how many game server processes each fleet instance will host when we create the fleet or after we create the fleet.
We also need to make sure all ports which are required by these game server processes are open in all fleet instances when we create the fleet or after we create the fleet.
We can link the fleet to an alias after we create the fleet.
game session
Game session is the session between a game server and gamelift service. It's a programming concept. Gamelift service uses it to store datas related to the game server and its status to determine whether the game server is running or not.
Once the server side initialize process is finished, the game session record will be initialize in gamelift without game session id. Its game session is called available game session. We can call create game session with Aws Resource Name(fleet id or alias id) from client to ask gamelift service to allocate a game session id with an available game session.
If there is no available game server process on the fleet, this node will return "no available process" error. We can use auto scaling to add more fleet instances to add move game server processes to the fleet.
We can also control how many game sessions can be created by a verified user when we create the fleet and after we create the fleet. We need to provide creator id when we call create game session if we want to use this feature. We can use sub id or username as the creator id.
Create game session node will return the allocated game session id and ip address and port in its result.
We can use open level with ip address and port to connect the game server process right after we create the game session. But we'd better wait until its status become active.
We can use describe game sessions or describe game session details with aws resource arn(alias id, fleet id, game session id) to get the game session's status. Describe game sessions or describe game session details have exactly same function. We can call them periodically to keep getting the game session's status until it's activated.
To get game session id on the server side, we can use get game session id node. Start game session event in the process parameter we provided to process ready will also provide the game session id.
Gamelift will trigger the start game session event in the process parameter we provided to process ready. We need to call activate game session on the game server before the game session timeout.
The base class of Process parameter's start game session event contains a call to start game session. So, if we don't override this function, we don't need to call activate game session.
After we call activate game session on the game server process, the game session that the game server process is allocated to will be set to active status. We can create player session on this game session after its status is active.
We can also update the game session's maximum player session count, name, player session creation policy, protection policy by calling update game session with aws resource name(game session id only).
When we want to end a game session, we need to call process ending on the game server to tell gamelift this process is going to end.
The game session status will be set to terminating. Then we need to call destroy to disconnect the game server process to gamelift service.
After that, we can call quit server to end the game server process.
After its resource is released, the game session status will be set to terminated, gamelift will collect the log file we specific in process ready and start a new game server process from the build we uploaded and start a new loop.
auto scaling
Gamelift auto scaling service is used to scale up and down the number of fleet instances in the fleet based on the percentage of available game session in the fleet. We can set the minimal, maximum and exact number of fleet instances in a fleet and the percentage of available game session in the fleet when gamelift will increase or decrease the fleet instances number.
When the fleet instance is going to shut down, gamelift service will trigger all game server processes' process terminate event in their process parameter we provided. We need to make sure the game server processes are ready to be ended in a few minutes. The base class of Process parameter's process terminate already call process ending and quit server with false. So, if we don't override this function, we don't need to worry.
player session
Player session is used to help gamelift service count how many players are there in a game session. It's a session between a game client and gamelift service. We can call create player session with aws resource name(game session id only) to create a player session on an active game session. We can also provide the sub id or username of a verified user as player id, so that we can know how many player sessions a verified user had created.
Or we can use create player sessions node with aws resource arn(game session id only) to create a group of player sessions.
If we want to prevent new player session being created, we can use the Maximum player session count to control how many player sessions can be created in the game session. Or we can call update player session creation policy to accept all or deny all player session creation.
Once the player session is created, the player session will be reserved. We have 60 seconds to call accept player session with player session id on the server. Or the player session will be timeout.
We can use unreal rpc functions to sync the player session id to the game server after the client connects the game server process.
Or we can also describe player sessions on client or server to get all player sessions in the game session with aws resource name(game session id only) or player id or player session id to get the exact player session. They are functionally same, but one is for client and the other one is for server.
After we call accept player session, the player session status will be active.
When the player exits the game server process, we need to call remove player session with player session id to remove the player session from the game session.
The player session status will become completed after we remove it from the game session.
Gamelift service will trigger the game servers process's process terminate event in their process parameter we provided. We need to make sure the game server processes are ready to be ended in a few minutes. The base class of Process parameter's process terminate already call process ending and quit server with false. So, if we don't override this function, we don't need to worry.
queue
Queue is a group of fleets in gamelift service. We can use game session placement after we set up a queue.
To set up a queue, we need to provide one or more fleets with one or more locations with different fleet type settings. Each fleet in the queue is also called as destination. We can also add more fleets into a queue after the queue is created.
game session placement
Game session placement service is a service help us find the best fleet and location base on player latency and cost in a queue and then create the game session and player sessions in the fleet with location.
To start a game session placement request, we need to call start game session placement with placement id(a random UUID which should be unique for the same gamelift queue), game session queue name, maximum player session count, player latencies, desired player sessions.
Game session placement request is a long term request which can exist for 600 seconds at max and 10 seconds at least. We can set how long the game session placement will wait until it timeout when we create the queue and after we create the queue.
During the 600 seconds, the game session placement service will try to find a destination base on the players' latency. We can also set the policy of how to find the destination when we create the queue or after we create the queue. For example, we can set the queue to use the first 5 seconds to find a destination with player latency less than
After we call start game session placement request, we need to wait until the game session placement state become fulfilled. We need to call describe game session placement with the placement id periodically to get the game session placement state.
If the game session placement service can't find a destination in queue that meets our requirement, the game session placement will be timeout.
If there are multiple destinations meet our requirement, game session placement service will choose one based on priority. We can set the priority when we create the queue or after we create the queue.
If we want to stop the game session placement, we can call stop game session placement with the placement id.
The game session placement state will be set to cancelled after we call stop game session placement with the placement id.
Once the game session placement state becomes fulfilled, describe game session placement will return the placed game session's game session detail with game session id, ip address, port and created player sessions. We can connect the clients to the game server process with the ip address and port then notify the game server process to call accept player session to accept the created and connected players' player sessions.
After the game session placement state becomes time out, cancelled. failed or fulfilled, its placement id can be reused in another start game session placement call.
matchmaking
Matchmaking is a service helps us match players and player teams base on the rule set we have defined.
To set up a matchmaking service for our game, we need to define a rule set to tell the matchmaking server how to match players and player teams. We need to read the aws document to learn how to design the rule set for our game and design it ourselves.
Matchmaking will use queue to place the matched game session and player sessions.
To start a matchmaking, we need to call start matchmaking with configuration name, players. Each player should contains his player id, player attributes(will be used to match other players base on matchmaking rule set), team(if we want to specific, or matchmaking will allocate this player to a team randomly), latency in millisecond similar with game session placement.
Start matchmaking will return with a ticket id.
The matchmaking status will be queued after we called start matchmaking. It means the matchmaking request is queued and waiting to process.
Then it will become searching. It means the matchmaking service is currently looking for other matchmaking requests to match with players in this matchmaking request. If we don't provide team in players, matchmaking will try to make all players in the same matchmaking request in the same team.
Similar with game session placement, we need to call describe matchmaking with ticket ids until the matchmaking status becomes completed.
If the matchmaking service successfully match the matchmaking request with other matchmakings, the matchmaking status will become requires acceptance if we enable match acceptance and set its timeout when we create the matchmaking configuration or after we create the matchmaking configuration.
Then, we need to call accept match with ticket id, player ids(accept match can be called for each player id or called one time for all player ids), accept or reject as acceptance type to accept or reject the match result before time out.
If one or more players reject the match result, the matchmaking status will return back to searching. If one or more players doesn't call accept match before time out, the matchmaking status will become cancelled.
If we disable match acceptance or all players accept the match result, the matchmaking status will become placing. It means it's using game session placement to place the game session and player sessions.
After the game session placement finished, the matchmaking status will become completed and similar with game session placement, describe matchmaking will return placed game session's detail with game session id, ip address, port and created player sessions. We can connect the clients to the game server process with the ip address and port then notify the game server process to call accept player session to accept the created and connected players' player sessions.
The above process need to be finished before time out, or the matchmaking status will become time out. we can set how long the matchmaking service will wait until it times out a matchmaking when we create the matchmaking configuration or after we create the matchmaking configuration.
If we want to cancel a matchmaking request, we can call stop matchmaking with the ticket id.
backfill
Matchmaking will make sure there are minimum number players for the match. If we want to make sure player number is maximum, we need to use backfill.
Backfill can be set to automatic or manual mode.
Automatic mode will start backfill automatically after a matchmaking status becomes completed. It will start multiple time automatically until the player number in the match is maximum.
But if a player exit the game or if we don't need the player number reach maximum, automatic mode can't handle it.
To start a backfill request, we need to call start match backfill with matchmaking configuration arn, game session arn, players(matched) on client or server side.
Start match backfill will return a ticket id in its result. We can also get the ticket id of automatic backfill from "autobackfilltickid" in matchmaker data from start game session or update game session event in the process parameter we provided for process ready.
Backfill will use matchmaking service to match with another matchmaking request.
Once the backfill request successfully get another matchmaking request to fill in the empty player session slots in the game session, gamelift service will trigger the update game session event in the process parameter we provided in process ready.
Each backfill request will match a matchmaking request. We can start another backfill request after a backfill request is finished.
If we want to stop a backfill request, we can call stop match backfill with ticket id, matchmaking configuration arn, game session arn on the server side.
