Set up a game image

Setting up a game image is one element of setting up a project with zeuz server hardware orchestration tools. See the Set up a project guide for instructions on how to set up zeuz orchestration.

Note: For an introduction to zeuz orchestration, you can follow the Get started tutorial. It uses a test project to demonstrate zeuz server hosting orchestration, the zeuz control panel (ZCP), zeuz scaler and zeuz tool CLI, as well as explaining the SDK downloads and zeuz concepts. It takes 60-90 minutes to complete.

Game assembly and game image

Your game image is a containerized version of your uploaded game assembly. It contains all the files needed to run your game server.

When you set up your game to use zeuz orchestration, you use the zeuz tool CLI to upload your game assembly. (You get zeuz tool as part of the SDK download.) You then use zeuz tool to create a containerized version of your game assembly. zeuz uses this containerized game image to create payload instances to run your game.

You can follow the same process to upload an updated game assembly. zeuz tool only uploads the changed files from your game assembly to your containerized game image.

The zeuz scaler, which you set up in the zeuz control panel, deploys the payload to the machines ​in your orchestration setup.

For further information see the Concepts documentation listed below:

  • Payload lifecycle: A summary in diagrams of game executable to a payload definition and the setup and use of a payload definition in an allocation.
  • Scaler: An overview in diagrams of using the zeuz scaler.

Game image best practise

To make sure your game image (which zeuz creates from your uploaded game assembly) meets zeuz requirements, follow the best practise guidelines below for setting up your game assembly.

Run in headless mode

zeuz only supports Linux game images running in headless mode (no GUI or audio). The following Linux packages are included in the container zeuz creates with your game image:

  • gettext
  • ca-certificates
  • curl
  • wget
  • htop
  • lib32z1
  • libatomic1
  • libsdl2-2.0-0
  • libc6:i386
  • libgcc1:i386
  • libstdc++5:i386
  • libstdc++6:i386
  • python
  • python3-pip
  • rsync

Use a single binary file

To make the game assembly upload process as straightforward as possible, compile your game server executable as a single binary file that:

  • Contains all dependencies.
  • Works without a launch script.
  • Doesn’t require defined environment variables.
  • Is set with executable permissions.
  • Uses only relative paths.

Note: If you can’t include all dependencies in a single executable file, make sure that you link to them statically, or dynamically using relative paths. Upload all dependencies together with your binary file.

Use a launch script

You might want to use a launch script when you need to set specific environment variables expected by your game, and/or transform the environment variables provided by zeuz. See the information on optional environment variables in the payload definition settings for more details.

TIP
If your game server is already logging to standard out, you don’t need to redirect your game server’s output.

Take care when using subdirectories

You might want subdirectories available to the payload, for example to store log output by a game running on Unreal Engine.

When it creates a containerized game image, zeuz deletes empty subdirectories created by your game executable. You can avoid this in a few ways:

  • Create a subdirectory inside your game assembly file structure and place a dummy file inside it, to prevent its deletion during the game assembly upload process, or
  • Set up the game executable so that it creates your subdirectory on startup.

Do’s, don’ts, tips

To avoid some common problems during the upload process, note the following.

Do

  • Make sure your game server runs on Linux.
  • Compile your game server so that everything it needs to run is in a single binary file. See the guidance above in the single binary section if you can’t.
  • Use UNIX syntax (LF) line-endings in your shell scripts. Don’t use Windows syntax (CRLF).
  • Make sure your game assembly files don’t include any sensitive information or user credentials.

Don’t

  • Don’t include dependencies on external modules or system-wide libraries.

  • Don’t use hard-coded parameters in a launch script.

    The zeuz payload runner can’t overwrite them which disrupts the upload process.

  • Don’t use hard-coded ports.

    zeuz assigns ports dynamically and makes them accessible as arguments in your allocation configuration. See the payload definition page for information on the variables zeuz uses for ports and other settings.

Tips

  • Make sure all subdirectories in your game assembly have a file in them.
  • Configure your game server to log to standard out, for any logs you want to view in the zeuz control panel.

2021-aug-24 Page updated with editorial review.

2021-may-19 Page updated with editorial review: clarified zeuz terms.

2021-feb-05 Page created with editorial review.


Last edited on: October 18, 2021 (66851b24)