Your game must meet specific requirements to ensure that you can use the Multiplay Hosting service to host and scale your game. The following guidelines describe how to prepare your game for Multiplay Hosting.

Most of the requirements are about your build or, more specifically, your build executable file. Your build encapsulates all the files necessary to run your game. Your build executable file is the executable file within your build. You must specify the build executable file when you create a build.

General requirements

This section covers the general requirements your build must meet to use Multiplay Hosting. Refer to the following requirements to learn more:

• Operating system

• Parameterized values

• Start-up conditions

• Network adapter binding

• Dynamic Port number

• Log directory

• Query protocol

• Post-allocation cleanup

Operating system

Your build executable file must support running on Ubuntu Linux 24.04. If you want to run your build executable file on older versions, contact your Multiplay representative or refer to Multiplay Support.

Note: Multiplay Hosting only supports 64-bit Linux applications.

Parameterized values

Your build must support using information from parameterized values. Multiplay Hosting manages parameterized values through configuration variables, the server.json file, and launch parameters.

server.json file

You can manage the information a build tracks through its build configuration.

Multiplay Hosting uses a server.json file to keep track of session-specific information, such as the allocation ID, port number, and any other variables you want to keep track of as configuration variables. Your build process must support keeping track of the information in the server.json file, so it can know when a server becomes allocated and deallocated. If you’re using Unity or the Unreal Engine, you can do so with the Game Server SDK.

server.json

server.json

Builds can also read information from launch parameters. Launch parameters are a good way to set values the build executable file needs, such as the game port, when it starts up.

Note: Although recommended, you don’t have to support launch parameters and build configuration variables. You can choose to support either option or a combination of both options.

Start-up conditions

Builds must support both starting with and without an allocation UUID populated in the server.json file. This is because Multiplay Hosting can create new servers to satisfy the scaling settings you provided. These servers are started in preparation for receiving allocations, which means the allocatedUUID field is an empty string ("") until it is allocated.

server.json

allocatedUUID

""

Network adapter binding

Builds must bind to 0.0.0.0 for both game server port and query protocol server port, if the build supports a query protocol.

0.0.0.0

Note: Trying to bind to any other address, including the externally visible IP address, might cause the server to be inaccessible or application bind failures.

Dynamic port number

Builds must support using a dynamic port number for game data transmission. Multiplay Hosting generates port numbers per server instance, with an offset to ensure there is no port conflict on server startup.

Note: You can use any ports in the range of 8100 to 65355.

Your build executable file must use the variable to leverage this functionality. For example, you can pass the variable to your build at start-up by using the following launch parameter:

-port 

Warning: Multiplay Hosting doesn't support using static or hard-coded port numbers. Static port numbers might work initially but can lead to problems with collisions later.

Logs directory

The logs directory requirement is optional. If you don't set up a log directory, you won't have any way of accessing logs and crash dumps through the Multiplay Dashboard. Multiplay Hosting displays server logs through the Multiplay Dashboard, where you can view, search, and download logs.

You can control where your build saves log files through a launch parameter and configuration variable. For example, you can use -logFile as the launch parameter and pass the configuration variable.

-logFile

-logFile /engine.log

The logs directory requirement is optional. If you don’t set up a log directory, you won’t have any way of accessing logs and crash dumps through the Multiplay Dashboard.

Tip: The recommended best practice is to set up a log rotation within the server code to ensure you have historical log data without continuously overwriting a single file. You use the variable to set up automatic log rotation.

Note: If you’re using Unreal Engine, the log directory must be relative to the Saved directory. Games using the Unreal Engine also support -userdir as a launch parameter to re-route crashes and pattern files to a similar directory.

Saved

-userdir

Query protocol

While it’s not a requirement, it’s best practice for builds to support responding to queries from a server query protocol, such as SQP.

A server query protocol is a protocol that facilitates querying information from a server instance, such as the server state and the number of allocated players. Typically, the response has static variables with dynamic (continuously updated) values.

Multiplay Hosting relies on query protocol responses to decide server instances' health. If your build doesn’t support a query protocol or if you set up your query protocol incorrectly, Multiplay Hosting might decide your server instances are unresponsive.

Additionally, the query protocol lets Multiplay Hosting report and watch real-time data about each server, such as concurrently connected users (CCU), active allocations, failed allocations, connected players per platform, and server events.

Tip: You can use the Game Server SDK to implement a server query protocol.

Post-allocation cleanup

Builds must support some form of post-allocation (post-session) cleanup to prepare the game server for the next allocation.

You have a couple of options:

• You can return to a lobby or a ready state after a game session concludes.

• You can exit the process gracefully (for example, exit code 0).

Returning to the lobby (or a ready state) is preferable to restarting the game server process. Ending the game server process at the end of a match is a less optimal use of resources because it’s typically more costly to restart than clean up a process.

Tip: Refer to the Game Server SDK to learn how to manage game server readiness.