# Set up for iterative development with Amazon GameLift Servers Anywhere
Amazon GameLift Servers provides tools and solutions to help you set up a hosted test environment for use during game development. With these tools, you can create an environment that mirrors the real-world player experience of managed hosting with Amazon GameLift Servers and supports a rapid, iterative development process.
With a separate test environment, you remove the overhead of an Amazon GameLift Servers managed fleet during testing. You no longer have to upload each new game server build iteration, create a new fleet for it, and then wait 15\$1 minutes to it to activate. Instead, you can create a new build, quickly update the test fleet with the new build, start it, and commence testing.
Using an Amazon GameLift Servers Anywhere fleet, you can set up a test environment using a local device, such as your development workstation. You can also set up a test environment using a cloud-based hosting resource.
Set up an Anywhere test environment to develop and test a range of scenarios, including these:
+ Test your game server integration with the Amazon GameLift Servers server SDK. You can test even without a working game client by using AWS CLI calls to start new game sessions and track game session events.
+ Test interactions between your game client, backend service, and the Amazon GameLift Servers service as you develop components for your game. Fine-tune the player experience for joining a game.
+ Experiment with your FlexMatch matchmaker design. Try out rule set variations and other matchmaking feature implementations. Set up and test matchmaking backfill.
+ Try out other Amazon GameLift Servers hosting features, such as runtime configuration settings (with the Amazon GameLift Servers Agent) for game server life cycle management.
+ Quickly build, test, and repeat to validate all aspects of your game's player experience, including multiplayer interactions, in a live, hosted environment.
Later, as you prepare your game for launch, you'll want to add Amazon GameLift Servers managed fleets to fine-tune your hosting configurations and test additional scenarios, including the following:
+ Experiment with and test game session queue designs, including use of multi-location fleets, Spot and On-Demand fleets, and multiple instance types.
+ Try out game session placement options with managed fleets, including the use of optional latency policies and fleet prioritization settings.
+ Configure capacity scaling to meet player demand, using automatic or manual scaling options.
+ Set up AWS CloudFormation with Amazon GameLift Servers managed fleets to manage your hosting resources long term.
**Fast Build Update Tool (for development only)**
With managed EC2 fleets, to deploy a game server build update, you need to upload each new build to Amazon GameLift Servers and create a new fleet for it.
The Fast Build Update Tool lets you can bypass these steps during development, saving you time and allowing for faster development iteration. With this tool, you can quickly update your game build files across all computes in an existing fleet. The tool has several options; you can replace an entire game build or change 6 specific files, and you can manage how to restart game server processes after the updates. You can also use it to update individual computes in a fleet.
To get the Fast Build Update Tool and learn more about how to use it, visit the Amazon GameLift Servers Toolkit repo for [ The Fast Build Update Tool](https://github.com/aws/amazon-gamelift-toolkit/tree/main/fast-build-update-tool) in Github.
**Topics**
+ [Build a cloud-based test environment](integration-dev-iteration-cloud.md)
+ [Set up local testing with Amazon GameLift Servers Anywhere](integration-testing.md)
+ [Test your integration using Amazon GameLift Servers Local](integration-testing-local.md)
# Build a cloud-based test environment
**Note**
This topic covers iterative testing for games that are integrated with the server SDK for Amazon GameLift Servers version 5.x. If your game uses server SDK version 4.x or earlier, see [Test your integration using Amazon GameLift Servers Local](integration-testing-local.md).
Use an Amazon GameLift Servers Anywhere fleet to iteratively build and test your game components in a cloud-based hosted environment. Create an Anywhere fleet with hosting resources and a connection to the Amazon GameLift Servers service, run your game servers on them, and test game functionality as needed.
**Deploy an Anywhere fleet with the Amazon GameLift Servers Agent**
If your game server build is integrated with Amazon GameLift Servers SDK 5.x or later, you can deploy it to a cloud-based Anywhere fleet with the Amazon GameLift Servers Agent. The Agent is a background process that manages game server life cycles and other tasks on each compute in a fleet. These tasks include registering the compute with an Anywhere fleet, acquiring an authentication token, and starting/stopping game server processes based on a set of instructions. The Agent is controlled by a fleet's runtime configuration, which you can update at any time during the life of the fleet. (The Agent is automatically deployed to managed EC2 fleets.) For more information and to download the Agent, see the [Amazon GameLift Servers GitHub repository](https://github.com/aws/amazon-gamelift-agent).
## Set up iterative testing with Amazon EC2
Use the guided workflow in this [Amazon GameLift Servers toolkit solution]( https://github.com/aws/amazon-gamelift-toolkit/tree/main/development-instance-with-amazon-gamelift-anywhere-and-gamelift-agent) to set up a cloud-based hosting environment that mirrors the managed hosting experience with Amazon GameLift Servers.
The GitHub repository provides a set of scripts that automate most of the processes for setting up a test environment with Amazon GameLift Servers Anywhere and the Amazon GameLift Servers Agent. It also provides guidance for updating the environment whenever you have a new game server build to test. You can run a single script that deploys a test environment with a sample game server build, or you can walk through each step to set it up with your own game server build.
In this workflow, you'll work entirely in the AWS Management Console, using AWS CloudShell to run scripts and complete command-line tasks.
**Note**
For the tasks in this tutorial, you need an AWS account user with permissions for the following services: Amazon GameLift Servers, AWS CloudShell, Amazon S3, AWS Systems Manager, Amazon EC2, and AWS Identity and Access Management. Users with admin-level access to the AWS account already have the required permissions.
The workflow covers the following tasks:
+ **Package a game server build for Amazon GameLift Servers. **The workflow provides a script to build a sample C\$1\$1 game server, which has already been integrated with the server SDK for Amazon GameLift Servers version 5.x and is ready for hosting. Alternatively, you can work with your own game project if you've completed integration.
+ **Set up an Amazon Simple Storage Service bucket to store game server builds and dependencies.** As you produce new versions of your game builds, you can store them in S3 and use the scripts to update the Anywhere fleet for game testing.
+ **Get and build the Amazon GameLift Servers Agent.** The Agent manages game server processes on a hosting resource based on your configuration. It uses the same logic and behaves identically to Amazon GameLift Servers managed EC2 hosting.
+ **Set up an Anywhere fleet for your hosting resources.** With an Anywhere fleet you can use the Amazon GameLift Servers service for hosting resources that aren't managed by Amazon GameLift Servers. In this step, you'll also configure the runtime configuration, which instructs Amazon GameLift Servers Agent when and how to start game server processes.
+ **Set up an Amazon EC2 instance.** This is your test environment for iterative testing. It is much faster to use a standard EC2 instance instead of a fully managed Amazon GameLift Servers instance (which is optimized for production-level usage). With a standard EC2 instance, you can quickly and continually update the game server as needed.
+ **Deploy your game server build and Amazon GameLift Servers Agent to the Amazon EC2 instance. **The workflow provides a script that gets the latest version of your game build and all dependencies and installs it on your EC2 instance. In this workflow, dependencies include the Amazon GameLift Servers Agent and the CloudWatch Agent.
+ **Start the Amazon GameLift Servers Agent.** Once installed, the Agent automatically starts and begins executing instructions. These include:
+ Register the EC2 instance as a compute in the Amazon GameLift Servers Anywhere fleet.
+ Establish a WebSocket connection with the Amazon GameLift Servers service and get the latest runtime configuration.
+ Start up game server processes based on the instructions in the runtime configuration. In this workflow, the Agent is instructed to start a single process of the game server executable.
+ **Test your game scenarios.** With the test environment set up and your latest game server build installed, you can commence testing. The workflow walks through several steps for testing including starting a game session. Access CloudWatch game server logs to track progress as the game session starts up and prepares to accept players.
As you develop your game components, including a game client and client-side backend service, you can include these in your test scenarios. Use a game client to request a game session, retrieve connection info from the Amazon GameLift Servers service, and then connect directly to the game session.
+ **Deploy a new game server build and repeat tests.** As you develop your game, you can generate new game server builds, then quickly deploy them to the EC2 test environment for testing. Upload them to the Amazon S3 bucket and then use the workflow scripts to update the test environment.
## Transition your game to Amazon GameLift Servers managed fleets
After you've completed development testing and you're ready to prepare for launch, this is a good time to switch over to Amazon GameLift Servers managed fleets. Use managed fleets to fine-tune and test your game hosting resources. Implement your game session placement solution (queues and matchmakers), select optimum hosting hardware (including Spot fleets) and locations, and choose a strategy for scaling capacity. You might also want to start using AWS CloudFormation to more efficiently manage the life cycles of all your game hosting resources, including fleets, queues, and matchmakers.
It requires minimal effort to transition from a cloud-based Anywhere test fleet to an Amazon GameLift Servers managed fleet. You don't need to change any game code, and you can reuse the same queues and matchmakers. Do the following tasks:
+ **Create an Amazon GameLift Servers build resource.** With an Anywhere test fleet, you have to manually deploy your game server build and dependencies to each fleet compute. With a managed fleet, upload your game build package to Amazon GameLift Servers, which automatically deploys it to all fleet computes. See [Create a game server build for Amazon GameLift Servers](gamelift-build-cli-uploading.md) for details on packaging your game build files and creating a build resource with files in an Amazon S3 bucket.
+ **Create a managed fleet.** Create a fleet using the console or AWS CLI, specifying an EC2 managed fleet. This type of fleet requires additional configuration settings, including specifying the build resource and instance types. You can use the same runtime configuration to manage game server life cycle on each fleet compute. See [Create an Amazon GameLift Servers managed EC2 fleet](fleets-creating.md) for details on creating a managed fleet.
+ **Redirect fleet aliases (optional).** If you set up aliases to use with your Anywhere fleets, you can reuse the same aliases for your managed fleets. See [Create an Amazon GameLift Servers alias](aliases-creating.md) for details on creating or updating an alias.
# Set up local testing with Amazon GameLift Servers Anywhere
**Note**
This topic covers local testing for games that are integrated with the server SDK for Amazon GameLift Servers version 5.x. If your game uses server SDK version 4.x or earlier, see [Test your integration using Amazon GameLift Servers Local](integration-testing-local.md).
Use an Amazon GameLift Servers Anywhere fleet and your own hardware to iteratively build and test your game components in a simulated hosted environment. Set up an Anywhere fleet and register a local device to establish a connection to the Amazon GameLift Servers service. Install your game server build onto the device, start a game server process, and test game functionality as needed. You can update your game server build as often as needed to test each new build iteration.
With an Anywhere fleet, you can test using the AWS CLI or with test scripts. If you've integrated a game client with Amazon GameLift Servers, you can run the client on the same local device or on a different device.
Testing locally with an Anywhere fleet is particularly useful for testing your game server integration with Amazon GameLift Servers. You have full visibility into all hosting activity on the local machine, as well as events and logging data.
**Note**
Are you using the Amazon GameLift Servers plugin for Unreal Engine or Unity? These tools include guided workflows for setting up local testing with an Anywhere fleet. Follow the documentation for [Plugin for Unity: Set up local testing with Amazon GameLift Servers Anywhere](unity-plug-in-anywhere.md) or [Plugin for Unreal: Host your game locally with Amazon GameLift Servers Anywhere](unreal-plugin-anywhere.md).
**Topics**
+ [Set up a local Anywhere fleet](#integration-testing-anywhere-fleet)
+ [Update and install your game server](#integration-testing-dev)
+ [Test game session activity](#integration-testing-test)
+ [Iterate on your game server](#fleet-anywhere-iteration)
+ [Transition your game to Amazon GameLift Servers managed fleets](#fleet-anywhere-transition)
## Set up a local Anywhere fleet
Follow these steps to create an Anywhere fleet for your local workstation. For detailed instructions using either the AWS CLI or the AWS Management Console for Amazon GameLift Servers, see [Create an Amazon GameLift Servers Anywhere fleet](fleets-creating-anywhere.md).
**To create the Anywhere fleet**
1. **Create a custom location for your local workstation. (AWS CLI or console).** A custom location is simply a label for the compute resource you plan to include in your Anywhere fleet. Custom location names must start with `custom-`. For example: `custom-my_laptop`. See [Create a custom location](fleets-creating-anywhere.md#fleet-anywhere-location).
1. **Create an Anywhere fleet (AWS CLI or console).** In this step, create the fleet resource with the custom location for your local workstation. See [Create an Anywhere fleet](fleets-creating-anywhere.md#fleet-anywhere-create).
Make a note of the new fleet's ID or ARN value. You'll need this value for the next step.
1. **Register your local workstation as a fleet compute (AWS CLI only).** An Anywhere fleet must have at least one compute resource to host your game servers. See [Add a compute to the fleet](fleets-creating-anywhere.md#fleet-anywhere-compute). To add a compute to the fleet, you need the following information:
+ A compute name. Each compute in a fleet must have a unique name.
+ The Anywhere fleet identifier. You can use either the `FleetID` or `FleetArn`.
+ The compute's connection info. Specify either an `IpAddress` or `DnsName`. This is how Amazon GameLift Servers and game clients will connect to game servers.
+ A custom location in the Anywhere fleet.
Make a note of the `GameLiftServiceSdkEndpoint` return value. You'll need this value when you update your game server to run on an Anywhere fleet.
## Update and install your game server
This task assumes that you've already integrated a game server build with Amazon GameLift Servers server SDK 5.x. The integration process involves adding code to your game server so that it can interact with the Amazon GameLift Servers service to start and manage game sessions.
For an Anywhere fleet, you need to manually configure certain game server settings. On an Amazon GameLift Servers managed fleet, these settings are configured automatically.
**To prepare your game server for an Anywhere fleet**
1. **Get an authentication token.** Your game server must include an authentication token with every communication with the Amazon GameLift Servers service. Amazon GameLift Servers auth tokens are short-lived and must be regularly refreshed.
As a best practice, create a script to complete the following tasks:
+ Call the AWS CLI action `get-compute-auth-token`.
+ Store the returned token value where game server processes can retrieve it, such as in an environment variable on the local compute.
Install the script with your game server on the compute. Set the script to run before starting the first game server process. While game server processes are active, run the script regularly to maintain a valid auth token. All game server processes on the compute can use the same auth token.
1. **Update your Amazon GameLift Servers game server code.** When you integrated your game server code with the server SDK for Amazon GameLift Servers, you added a call to the action `InitSdk()`. When the game server runs on an Anywhere fleet, this call requires additional server parameters. For more information, see [Initialize the server process](gamelift-sdk-server-api.md#gamelift-sdk-server-initialize) and the [Server SDK 5.x for Amazon GameLift Servers](reference-serversdk.md) for your development language. The server parameters are:
+ `webSocketUrl` – Set this parameter to the `GameLiftServiceSdkEndpoint` value that is returned when you register a compute with the fleet.
+ `hostId` – Set this parameter to the compute name that you specify when you register a compute with the Anywhere fleet.
+ `fleetId` – Set this parameter to the ID of the Anywhere fleet.
+ `authToken` – Set this parameter to the token that is returned in response to a request to retrieve an authenticaiton token for a compute.
+ `processId` – Set this parameter to identify a game server process that's running on the local compute. Each concurrent game server process must have a unique process ID.
The server parameter values that each game server process uses needs to be specific to the Anywhere fleet compute where the process is running. For details on how to get the appropriate values for a compute, see [Add a compute to the fleet](fleets-creating-anywhere.md#fleet-anywhere-compute). As a best practice, set `webSocketUrl`, `hostId`, `fleetId`, and `authToken` as environment variables on the local compute. All server processes that run on the compute will use these values.
1. Install the game server build on the local compute. Include all dependencies needed to run the game server.
1. Start one or more game server processes running on the local compute. When the game server process calls the server SDK action `ProcessReady()`, the process is ready to host a game session.
## Test game session activity
Test your game server integration by working with game sessions. If you don't have a game client integrated with Amazon GameLift Servers functionality, you can use the AWS CLI to start game sessions. Try the following scenarios:
+ **Create a game session.** Call [create-game-session ](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/create-game-session.html) command (or the [ CreateGameSession](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateGameSession.html) API operation). Specify your Anywhere fleet's ID and custom location. This call returns a unique identifier for the new game session.
+ **Check game session status. **Call [describe-game-sessions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/describe-game-sessions.html) command (or the [DescribeGameSessions](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_DescribeGameSessions.html) API action). Specify the game session ID. This call returns detailed game session information, including the game session status. Game sessions in Active status are ready for players to connect. To get a list of all game sessions for the fleet, call [list-game-sessions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/list-game-sessions.html) command (or the [ListGameSessions](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_ListGameSessions.html) API action).
+ **Connect to the game session.** If your game client has the ability to join a game session, use the connection information included in the game session information.
## Iterate on your game server
You can use the same Anywhere fleet and compute to test other versions of your game server build.
1. **Clean up your existing `GameSession`.** If the game server process crashes or won't call `ProcessEnding()`, Amazon GameLift Servers cleans up the `GameSession` after the game server stops sending health checks.
1. **Generate a new game server build.** Make changes to your game server and package an revised build.
1. **Update the game server build on your local compute.** Your previous Anywhere fleet is still active and your laptop is still registered as a compute resource in the fleet.
1. **Get an updated authorization token.** Call the [get-compute-auth-token](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/gamelift/get-compute-auth-token.html) CLI command and store the token on the local compute.
1. **Start one or more game server processes running on the local compute.** When the game server process calls `ProcessReady()`, it's ready to be used for testing.
## Transition your game to Amazon GameLift Servers managed fleets
After you've completed development testing and you're ready to prepare for launch, this is a good time to switch over to Amazon GameLift Servers managed fleets. Use managed fleets to fine-tune and test your game hosting resources. Implement your game session placement solution (queues and matchmakers), select optimum hosting hardware (including Spot fleets) and locations, and choose a strategy for scaling capacity. You might also want to start using AWS CloudFormation to more efficiently manage the life cycles of all your game hosting resources, including fleets, queues, and matchmakers.
You need to make a few minor modifications to transition from a local Anywhere test fleet to an Amazon GameLift Servers managed fleet. You can reuse the same queues and matchmakers. Do the following tasks:
+ **Change the game server code call to `InitSdk()`.** Remove the server parameters. For a managed fleet, Amazon GameLift Servers automatically tracks this information.
+ **Create an Amazon GameLift Servers build resource.** With an Anywhere test fleet, you have to manually deploy your game server build and dependencies to each fleet compute. With a managed fleet, you create and upload your game build package to Amazon GameLift Servers, which automatically deploys it to all fleet computes. See [Create a game server build for Amazon GameLift Servers](gamelift-build-cli-uploading.md) for details on packaging your game build files and creating a build resource with files in an Amazon S3 bucket. Don't include scripts that register a compute and get an authentication token, as Amazon GameLift Servers automatically handles these tasks with managed fleets.
+ **Create a managed fleet.** Create a fleet using the console or AWS CLI, specifying an EC2 managed fleet. This type of fleet requires additional configuration settings, including specifying the build resource and instance types. You alls need to set up a runtime configuration to manage game server life cycle on each fleet compute. See [Create an Amazon GameLift Servers managed EC2 fleet](fleets-creating.md) for details on creating a managed fleet.
+ **Redirect fleet aliases (optional).** If you set up aliases to use with your Anywhere fleets, you can reuse the same aliases for your managed fleets. See [Create an Amazon GameLift Servers alias](aliases-creating.md) for details on creating or updating an alias.
# Test your integration using Amazon GameLift Servers Local
**Note**
This topic covers testing for games that are integrated with the server SDK for Amazon GameLift Servers version 3.x and 4.x only. Your server SDK package includes a compatible version of Amazon GameLift Servers Local. If you're using server SDK version 5.x, see [Local testing with GameLift Server SDK 5.x](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/integration-testing-local.html) for local testing with an Amazon GameLift Servers Anywhere fleet. For guidance on migrating from SDK 4.x to 5.x, see [Migrate to GameLift Server SDK 5.x](https://docs.aws.amazon.com/gamelift/latest/developerguide/reference-serversdk5-migration.html).
Use Amazon GameLift Servers Local to run a limited version of the managed Amazon GameLift Servers service on a local device and test your game integration against it. This tool is useful when doing iterative development on your game integration. The alternative—uploading each new build to Amazon GameLift Servers and configuring a fleet to host your game—can take several or more each time.
With Amazon GameLift Servers Local, you can verify the following:
+ Your game server is correctly integrated with the Server SDK and is properly communicating with the Amazon GameLift Servers service to start new game sessions, accept new players, and report health and status.
+ Your game client is correctly integrated with the AWS SDK for Amazon GameLift Servers and is able to retrieve information on existing game sessions, start new game sessions, join players to games and connect to the game session.
Amazon GameLift Servers Local is a command-line tool that starts a self-contained version of the managed Amazon GameLift Servers service. Amazon GameLift Servers Local also provides a running event log of server process initialization, health checks, and API calls and responses. Amazon GameLift Servers Local recognizes a subset of the AWS SDK actions for Amazon GameLift Servers. You can make calls from the AWS CLI or from your game client. All API actions perform locally just as they do in the Amazon GameLift Servers web service.
Each server process should only host a single game session. The game session is the executable you use to connect to Amazon GameLift Servers Local. When the game session is completed, you should call `GameLiftServerSDK::ProcessEnding` and then exit the process. When testing locally with Amazon GameLift Servers Local, you can start multiple server processes. Each process will connect to Amazon GameLift Servers Local. You can then create one game session for each server process. When your game session ends, your game server process should exit. You must then manually start another server process.
Amazon GameLift Servers local supports the following APIs:
+ CreateGameSession
+ CreatePlayerSession
+ CreatePlayerSessions
+ DescribeGameSessions
+ DescribePlayerSessions
## Set up Amazon GameLift Servers local
Amazon GameLift Servers Local is provided as an executable `.jar` file bundled with the [Server SDK](https://aws.amazon.com/gamelift/servers/getting-started/). It can be run on Windows or Linux and used with any Amazon GameLift Servers-supported language. For SDK version 4.0.2, you can download it from the [official GitHub releases](https://github.com/amazon-gamelift/amazon-gamelift-servers-csharp-server-sdk/releases). The GameLiftLocal.jar file is included in the GameLift-CSharp-ServerSDK-4.0.2.zip artifact.
Before running Local, you must also have the following installed.
+ A build of the server SDK for Amazon GameLift Servers version 3.1.5 to 4.x.
+ Java 8
## Test a game server
If you want to test your game server only, you can use the AWS CLI to simulate game client calls to the Amazon GameLift Servers Local service. This verifies that your game server is performing as expected with the following:
+ The game server launches properly and initializes the server SDK for Amazon GameLift Servers.
+ As part of the launch process, the game server notifies Amazon GameLift Servers that the server is ready to host game sessions.
+ The game server sends health status to Amazon GameLift Servers every minute while running.
+ The game server responds to requests to start a new game session.
1. **Start Amazon GameLift Servers Local.**
Open a command prompt window, navigate to the directory containing the file `GameLiftLocal.jar` and run it. By default, Local listens for requests from game clients on port 8080. To specify a different port number, use the `-p` parameter, as shown in the following example:
```
java -jar GameLiftLocal.jar -p 9080
```
Once Local starts, you see logs indicating that two local servers were started, one listening for your game server and one listening for your game client or the AWS CLI. Logs continue to report activity on the two local servers, including communication to and from your game components.
1. **Start your game server.**
Start your Amazon GameLift Servers-integrated game server locally. You don't need to change the endpoint for the game server.
In the Local command prompt window, log messages indicate that your game server has connected to the Amazon GameLift Servers Local service. This means that your game server successfully initialized the server SDK for Amazon GameLift Servers (with `InitSDK()`). It has called `ProcessReady()` with the log paths shown and, if successful, is ready to host a game session. While the game server is running, Amazon GameLift Servers logs each health status report from the game server. The following log messaging example shows a successfully integrated game server:
```
16:50:53,217 INFO || - [SDKListenerImpl] nioEventLoopGroup-3-1 - SDK connected: /127.0.0.1:64247
16:50:53,217 INFO || - [SDKListenerImpl] nioEventLoopGroup-3-1 - SDK pid is 17040, sdkVersion is 3.1.5 and sdkLanguage is CSharp
16:50:53,217 INFO || - [SDKListenerImpl] nioEventLoopGroup-3-1 - NOTE: Only SDK versions 3.1.5 and above are supported in GameLiftLocal!
16:50:53,451 INFO || - [SDKListenerImpl] nioEventLoopGroup-3-1 - onProcessReady received from: /127.0.0.1:64247 and ackRequest requested? true
16:50:53,543 INFO || - [SDKListenerImpl] nioEventLoopGroup-3-1 - onProcessReady data: logPathsToUpload: "C:\\game\\logs"
logPathsToUpload: "C:\\game\\error"
port: 1935
16:50:53,544 INFO || - [HostProcessManager] nioEventLoopGroup-3-1 - Registered new process true, true,
16:50:53,558 INFO || - [SDKListenerImpl] nioEventLoopGroup-3-1 - onReportHealth received from /127.0.0.1:64247 with health status: healthy
```
Potential error and warning messages include the following:
+ Error: "ProcessReady did not find a process with pID: **\$1 Was InitSDK() invoked?"
+ Warning: "Process state already exists for process with pID: **\$1 Is ProcessReady(...) invoked more than once?"
1. **Start the AWS CLI.**
Once your game server successfully calls `ProcessReady()`, you can start making client calls. Open another command prompt window and start the AWS CLI tool. The AWS CLI by default uses the Amazon GameLift Servers web service endpoint. You must override this with the Local endpoint in every request using the `--endpoint-url` parameter, as shown in the following example request.
```
AWS gamelift describe-game-sessions --endpoint-url http://localhost:9080 --fleet-id fleet-123
```
In the AWS CLI command prompt window, `AWS gamelift` commands result in responses as documented in the [AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/gamelift).
1. **Create a game session.**
With the AWS CLI, submit a [CreateGameSession()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateGameSession.html) request. The request should follow the expected syntax. For Local, the `FleetId` parameter can be set to any valid string (`^fleet-\S+`).
```
AWS gamelift create-game-session --endpoint-url http://localhost:9080 --maximum-player-session-count 2 --fleet-id
fleet-1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
```
In the Local command prompt window, log messages indicate that Amazon GameLift Servers Local has sent your game server an `onStartGameSession` callback. If a game session is successfully created, your game server responds by invoking `ActivateGameSession`.
```
13:57:36,129 INFO || - [SDKInvokerImpl]
Thread-2 - Finished sending event to game server to start a game session:
arn:aws:gamelift:local::gamesession/fleet-1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d/gsess-ab423a4b-b827-4765-aea2-54b3fa0818b6.
Waiting for ack response.13:57:36,143 INFO || - [SDKInvokerImpl]
Thread-2 - Received ack response: true13:57:36,144 INFO || -
[CreateGameSessionDispatcher] Thread-2 - GameSession with id:
arn:aws:gamelift:local::gamesession/fleet-1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d/gsess-ab423a4b-b827-4765-aea2-54b3fa0818b6
created13:57:36,227 INFO || - [SDKListenerImpl]
nioEventLoopGroup-3-1 - onGameSessionActivate received from: /127.0.0.1:60020 and ackRequest
requested? true13:57:36,230 INFO || - [SDKListenerImpl]
nioEventLoopGroup-3-1 - onGameSessionActivate data: gameSessionId:
"arn:aws:gamelift:local::gamesession/fleet-1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d/gsess-abcdef12-3456-7890-abcd-ef1234567890"
```
In the AWS CLI window, Amazon GameLift Servers responds with a game session object including a game session ID. Notice that the new game session's status is Activating. The status changes to Active once your game server invokes ActivateGameSession. If you want to see the changed status , use the AWS CLI to call `DescribeGameSessions()`.
```
{
"GameSession": {
"Status": "ACTIVATING",
"MaximumPlayerSessionCount": 2,
"FleetId": "fleet-1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
"GameSessionId": "arn:aws:gamelift:local::gamesession/fleet-1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d/gsess-abcdef12-3456-7890-abcd-ef1234567890",
"IpAddress": "127.0.0.1",
"Port": 1935
}
}
```
## Test a game server and client
To check your full game integration, including connecting players to games, you can run both your game server and client locally. This allows you to test programmatic calls from your game client to the Amazon GameLift Servers Local. You can verify the following actions:
+ The game client is successfully making AWS SDK requests to the Amazon GameLift Servers Local service, including to create game sessions, retrieve information on existing game sessions, and create player sessions.
+ The game server is correctly validating players when they try to join a game session. For validated players, the game server may retrieve player data (if implemented).
+ The game server reports a dropped connection when a player leaves the game.
+ The game server reports ending a game session.
1. **Start Amazon GameLift Servers Local.**
Open a command prompt window, navigate to the directory containing the file `GameLiftLocal.jar` and run it. By default, Local listens for requests from game clients on port 8080. To specify a different port number, use the `-p` parameter, as shown in the following example.
```
./gamelift-local -p 9080
```
Once Local starts, you see logs showing that two local servers were started, one listening for your game server and one listening for your game client or the AWS CLI.
1. **Start your game server.**
Start your Amazon GameLift Servers-integrated game server locally. See [Test a game server](#integration-testing-local-server) for more detail on message logs.
1. **Configure your game client for Local and start it.**
To use your game client with the Amazon GameLift Servers Local service, you must make the following changes to your game client's setup, as described in [Set up the Amazon GameLift Servers API](gamelift-sdk-client-api.md#gamelift-sdk-client-api-initialize):
+ Change the `ClientConfiguration` object to point to your Local endpoint, such as `http://localhost:9080`.
+ Set a target fleet ID value. For Local, you do not need a real fleet ID; set the target fleet to any valid string (`^fleet-\S+`), such as `fleet-1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d`.
+ Set AWS credentials. For Local, you do not need real AWS credentials; you can set the access key and secret key to any string.
In the Local command prompt window, once you start the game client, log messages should indicate that it has initialized the `GameLiftClient` and is successfully communicated with the Amazon GameLift Servers service.
1. **Test game client calls to the Amazon GameLift Servers service.**
Verify that your game client is successfully making any or all of the following API calls:
+ [CreateGameSession()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateGameSession.html)
+ [DescribeGameSessions()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeGameSessions.html)
+ [CreatePlayerSession()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreatePlayerSession.html)
+ [CreatePlayerSessions()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreatePlayerSessions.html)
+ [DescribePlayerSessions()](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribePlayerSessions.html)
In the Local command prompt window, only calls to `CreateGameSession()` result in log messages. Log messages show when Amazon GameLift Servers Local prompts your game server to start a game session (`onStartGameSession` callback) and gets a successful `ActivateGameSession` when your game server invokes it. In the AWS CLI window, all API calls result in responses or error messages as documented.
1. **Verify that your game server is validating new player connections.**
After creating a game session and a player session, establish a direct connection to the game session.
In the Local command prompt window, log messages should show that the game server has sent an `AcceptPlayerSession()` request to validate the new player connection. If you use the AWS CLI to call `DescribePlayerSessions()`, the player session status should change from Reserved to Active.
1. **Verify that your game server is reporting game and player status to the Amazon GameLift Servers service.**
For Amazon GameLift Servers to manage player demand and correctly report metrics, your game server must report various statuses back to Amazon GameLift Servers. Verify that Local is logging events related to following actions. You may also want to use the AWS CLI to track status changes.
+ **Player disconnects from a game session** – Amazon GameLift Servers Local log messages should show that your game server calls `RemovePlayerSession()`. An AWS CLI call to `DescribePlayerSessions()` should reflect a status change from `Active` to `Completed`. You might also call `DescribeGameSessions()` to check that the game session's current player count decreases by one.
+ **Game session ends** – Amazon GameLift Servers Local log messages should show that your game server calls `TerminateGameSession()`.
**Note**
Previous guidance was to call `TerminateGameSession()` when ending a game session. This method is deprecated with Amazon GameLift Servers Server SDK v4.0.1. See [End a game session](gamelift-sdk-server-api.md#gamelift-sdk-server-shutdownsession).
+ **Server process is terminated** – Amazon GameLift Servers Local log messages should show that your game server calls `ProcessEnding()`. An AWS CLI call to `DescribeGameSessions()` should reflect a status change from `Active` to `Terminated` (or `Terminating`).
## Variations with local
When using Amazon GameLift Servers Local, keep in mind the following:
+ Unlike the Amazon GameLift Servers web service, Local does not track a server's health status and initiate the `onProcessTerminate` callback. Local simply stops logging health reports for the game server.
+ For calls to the AWS SDK, fleet IDs are not validated, and can be any string value that meets the parameter requirements (`^fleet-\S+`).
+ Game session IDs created with Local have a different structure. They include the string `local`, as shown here:
```
arn:aws:gamelift:local::gamesession/fleet-123/gsess-56961f8e-db9c-4173-97e7-270b82f0daa6
```