================== Writing installers ================== Table of contents ================= * `Basics`_ * `Variable substitution`_ * `Game configuration directives`_ * `Runner configuration directives`_ * `System configuration directives`_ * `Fetching required files`_ * `Installer meta data`_ * `Writing the installation script`_ * `Example scripts`_ Basics ====== Games in Lutris are written in the YAML format in a declarative way. The same document provides information on how to acquire game files, setup the game and store a base configuration. Make sure you have some level of understanding of the YAML format before getting into Lutris scripting. The Ansible documentation provides a short guide on the syntax: https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html At the very least, a Lutris installer should have a ``game`` section. If the installer needs to download or ask the user for some files, those can be added in the `files` section. Installer instructions are stored in the ``installer`` section. This is where the installer files are processed and will results in a runnable game when the installer has finished. The configuration for a game is constructed from its installer. The `files` and `installer` sections are removed from the script, some variables such as $GAMEDIR are substituted and the results is saved in: ~/.config/lutris/games/-.yml. Published installers can be accessed from a command line by using the ``lutris:`` URL prefix followed by the installer slug. For example, calling ``lutris lutris:quake-darkplaces`` will launch the Darkplaces installer for Quake. **Important note:** Installer scripts downloaded to the client are embedded in another document. What is editable on the Lutris section is the ``script`` section of a bigger document. In addition to the script it self, Lutris needs to know the following information: * ``name``: Name of the game, should be surrounded in quotes if containing special characters. * ``game_slug``: Game identifier on the Lutris website * ``version``: Name of the installer * ``slug``: Installer identifier * ``runner``: Runner used for the game. If you intend to write installers locally and not use the website, you should have those keys provided at the root level and everything else indented under a ``script`` section. Local installers can be launched from the CLI with ``lutris -i /path/to/file.yaml``. Variable substitution ===================== You can use variables in your script to customize some aspect of it. Those variables get substituted for their actual value during the install process. Available variables are: * ``$GAMEDIR``: Absolute path where the game is installed. * ``$CACHE``: Temporary cache used to manipulate game files and deleted at the end of the installation. * ``$RESOLUTION``: Full resolution of the user's main display (eg. ``1920x1080``) * ``$RESOLUTION_WIDTH``: Resolution width of the user's main display (eg. ``1920``) * ``$RESOLUTION_HEIGHT``: Resolution height of the user's main display (eg. ``1080``) * ``$WINEBIN``: Absolute path to the Lutris provided Wine binary used to install the game. Additional variables are referenced in a `variables` section in the script. Example:: variables: VERSION: 1.3 files: stk: https://github.com/supertuxkart/stk-code/releases/download/$VERSION/SuperTuxKart-$VERSION-linux-64bit.tar.xz You can also reference files from the ``files`` section by their identifier, they will resolve to the absolute path of the downloaded or user provided file. Referencing game files usually doesn't require preceding the variable name with a dollar sign. Installer meta data =================== Installer meta-data is any directive that is at the root level of the installer used for customizing the installer. Referencing the main file ------------------------- Referencing the main file of a game is possible to do at the root level of the installer but this information is later merged in the ``game`` section. It is recommended to put this information directly in the ``game`` section. If you see an existing installer with keys like ``exe`` or ``main_file`` sitting at the root level, please move them to the ``game`` section. Requiring additional binaries ----------------------------- If the game or the installer needs some system binaries to run, you can specify them in the ``require-binaries`` directive. The value is a comma-separated list of required binaries (acting as AND), if one of several binaries are able to run the program, you can add them as a ``|`` separated list (acting as OR). Example:: # This requires cmake to be installed and either ggc or clang require-binaries: cmake, gcc | clang Mods and add-ons ---------------- Mods and add-ons require that a base game is already installed on the system. You can let the installer know that you want to install an add-on by specifying the ``requires`` directive. The value of ``requires`` must be the canonical slug name of the base game, not one of its aliases. For example, to install the add-on "The reckoning" for Quake 2, you should add: ``requires: quake-2`` You can also add complex requirements following the same syntax as the ``require-binaries`` directive described above. Extensions / patches -------------------- You can write installers that will not create a new game entry in Lutris. Instead they will modify the configuration on an exsiting game. You can use this feature with the ``extends`` directive. It works the same way as the ``requires`` directive and will check for a base game to be available. Example:: # Used in a installer that fixes issues with Mesa extends: unreal-gold Customizing the end of install text ----------------------------------- You can display a custom message when the installation is completed. To do so, use the ``install_complete_text`` key. Game configuration directives ============================= A game configuration file can contain up to 3 sections: `game`, `system` and a section named after the runner used for the game. The `game` section can also contain references to other stores such as Steam or GOG. Some IDs are used to launch the game (Steam, ScummVM) while in other cases, the ID is only used to find games files on a 3rd party platform and download the installer (Humble Bundle, GOG). Lutris supports the following game identifiers: `appid`: For Steam games. Numerical ID found in the URL of the store page. Example: The `appid` for https://store.steampowered.com/app/238960/Path_of_Exile/ is `238960`. This ID is used for installing and running the game. `game_id`: Identifier used for ScummVM games. Can be looked up on the game compatibility list: https://www.scummvm.org/compatibility/ `gogid`: GOG identifier. Can be looked up on https://www.gogdb.org/products Be sure to reference the base game and not one of its package or DLC. Example: The `gogid` for Darksiders III is 1246703238 `humbleid`: Humble Bundle ID. There currently isn't a way to lookup game IDs other than using the order details from the HB API. Lutris will soon provide easier ways to find this ID. `main_file`: For MAME games, the `main_file` can refer to a MAME ID instead of a file path. Common game section entries --------------------------- ``exe``: Main game executable. Used for Linux and Wine games. Example: ``exe: exult`` ``main_file``: Used in most emulator runners to reference the ROM or disk file. Example: ``main_file: game.rom``. Can also be used to pass the URL for web based games: ``main_file: http://www...`` ``args``: Pass additional arguments to the command. Can be used with linux, wine, dosbox, scummvm, pico8 and zdoom runners. Example: ``args: -c $GAMEDIR/exult.cfg`` ``working_dir``: Set the working directory for the game executable. This is useful if the game needs to run from a different directory than the one the executable resides in. This directive can be used for Linux, Wine and Dosbox installers. Example: ``$GAMEDIR/path/to/game`` ``launch_configs``: When you have games with multiple executables (example: a game that comes with a map editor, or that need to be launched with different arguments) you can specify them in this section. In this section, you can have a list of configurations containing ``exe``, ``args`` and ``working_dir`` plus a ``name`` to show in the launcher dialog. Example:: game: exe: main.exe launch_configs: - exe: map_editor.exe name: Map Editor - exe: main.exe args: -missionpack name: Mission Pack Wine and other wine based runners ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``arch``: Sets the architecture of a Wine prefix. By default it is set to ``win64``, the value can be set to ``win32`` to setup the game in a 32-bit prefix. ``prefix``: Path to the Wine prefix. For Wine games, it should be set to ``$GAMEDIR``. DRM free Steam ^^^^^^^^^^^^^^ Lutris has the ability to run Steam games without launching the Steam client. This is only possible with certain games lacking the Steam DRM. ``run_without_steam``: Activate the DRM free mode and no not launch Steam when the game runs. ``steamless_binary``: Used in conjonction with ``run_without_steam``. This allows to provide the path of the game executable if it's able to run without the Steam client. The game must not have the Steam DRM to use this feature. Example: ``steamless_binary: $GAMEDIR/System/GMDX.exe`` ScummVM ^^^^^^^ ``path``: Location of the game files. This should be set to ``$GAMEDIR`` in installer scripts. Runner configuration directives =============================== Runners can be customized in a section named after the runner identifier (``slug`` field in the API). A complete list of all runners is available at https://lutris.net/api/runners. Use the runner's slug as the runner identifier. Please keep the amount of runner customization to a minimum, only adding what is needed to make the game run correctly. A lot of runner options do not have their place in Lutris installers and are reserved for the user's preferences. The following sections will describe runner directives commonly used in installers. wine ---- ``version``: Set the Wine version to a specific build. Only set this if the game has known regressions with the current default build. Abusing this feature slows down the development of the Wine project. Example: ``version: staging-2.21-x86_64`` ``dxvk``: Use this to disable DXVK if needed. (``dxvk: false``) ``dxvk_version``: Use this to define a specific DXVK version. (``dxvk_version: 1.10.3``) ``esync``: Use this to disable esync. (``esync: false``) ``overrides``: Overrides for Wine DLLs. List your DLL overrides in a mapping with the following values: ``n,b`` = Try native and fallback to builtin if native doesn't work ``b,n`` = Try builtin and fallback to native if builtin doesn't work ``b`` = Use builtin ``n`` = Use native ``disabled`` = Disable library Example:: overrides: ddraw.dll: n d3d9: disabled winegstreamer: builtin System configuration directives =============================== Those directives are stored in the ``system`` section and allow for customization of system features. As with runner configuration options, system directives should be used carefully, only adding them when absolutely necessary to run a game. ``env``: Sets environment variables before launching a game and during install. Do not **ever** use this directive to enable a framerate counter. Do not use this directive to override Wine DLLs. Variable substitution is available in values. Example:: env: __GL_SHADER_DISK_CACHE: 1 __GL_THREADED_OPTIMIZATIONS: '1' __GL_SHADER_DISK_CACHE_PATH: $GAMEDIR mesa_glthread: 'true' ``single_cpu``: Run the game on a single CPU core. Useful for some old games that handle multicore CPUs poorly. (``single_cpu: true``) ``pulse_latency``: Set PulseAudio latency to 60 msecs. Can reduce audio stuttering. (``pulse_latency: true``) ``use_us_layout``: Change the keyboard layout to a standard US one while the game is running. Useful for games that handle other layouts poorly and don't have key remapping options. (``use_us_layou: true``) Fetching required files ======================= The ``files`` section of the installer references every file needed for installing the game. This section's keys are unique identifier used later in the ``installer`` section. The value can either be a string containing a URI pointing at the required file or a dictionary containing the ``filename`` and ``url`` keys. The ``url`` key is equivalent to passing only a string to the installer and the ``filename`` key will be used to give the local copy another name. If you need to set referer use ``referer`` key. If the game contains copyrighted files that cannot be redistributed, the value should begin with ``N/A``. When the installer encounter this value, it will prompt the user for the location of the file. To indicate to the user what file to select, append a message to ``N/A`` like this: ``N/A:Please select the installer for this game`` Examples:: files: - file1: https://example.com/gamesetup.exe - file2: "N/A:Select the game's setup file" - file3: url: https://example.com/url-that-doesnt-resolve-to-a-proper-filename filename: actual_local_filename.zip referer: www.mywebsite.com If the game makes use of Steam data, the value should be ``$STEAM:appid:path/to/data``. This will check that the data is available or install it otherwise. If the game or file is hosted on moddb.com, it is necessary to understand that the platform rotates the actual download links every few hours, making it impractical to set these links as source url in installers. Lutris has routines to overcome this limitation (with blessing from moddb.com). When specifying a file hosted on moddb.com, please use the url of the files details page (the one with the red "Download now" button). Example URLs for ModDB files:: https://www.moddb.com/games/{game-title}/downloads/{file-title} https://www.moddb.com/mods/{mod-title}/downloads/{file-title} Writing the installation script =============================== After every file needed by the game has been acquired, the actual installation can take place. A series of directives will tell the installer how to set up the game correctly. Start the installer section with ``installer:`` then stack the directives by order of execution (top to bottom). Displaying an 'Insert disc' dialog ---------------------------------- The ``insert-disc`` command will display a message box to the user requesting him to insert the game's disc into the optical drive. Ensure a correct disc detection by specifying a file or folder present on the disc with the ``requires`` parameter. The $DISC variable will contain the drive's path for use in subsequent installer tasks. A link to CDEmu's homepage and PPA will also be displayed if the program isn't detected on the machine, otherwise it will be replaced with a button to open gCDEmu. You can override this default text with the ``message`` parameter. Example:: - insert-disc: requires: diablosetup.exe Moving files and directories ---------------------------- Move files or directories by using the ``move`` command. ``move`` requires two parameters: ``src`` (the source file or folder) and ``dst`` (the destination folder). The ``src`` parameter can either be a ``file ID`` or a path relative to game dir. If the parameter value is not found in the list of file ids, then it must be prefixed by either ``$CACHE`` or ``$GAMEDIR`` to move a file or directory from the download cache or the game's install dir, respectively. The ``dst`` parameter should be prefixed by either ``$GAMEDIR`` or ``$HOME`` to move files to path relative to the game dir or the current user's home. If the source is a ``file ID``, it will be updated with the new destination path. It can then be used in following commands to access the moved file. The ``move`` command cannot overwrite files. If the destination directory doesn't exist, it will be created. Be sure to give the full path of the destination (including filename), not just the destination folder. Example:: - move: src: game_file_id dst: $GAMEDIR/location Copying and merging directories ------------------------------- Both merging and copying actions are done with the ``merge`` or the ``copy`` directive. It is not important which of these directives is used because ``copy`` is just an alias for ``merge``. Whether the action does a merge or copy depends on the existence of the destination directory. When merging into an existing directory, original files with the same name as the ones present in the merged directory will be overwritten. Take this into account when writing your script and order your actions accordingly. If the source is a ``file ID``, it will be updated with the new destination path. It can then be used in following commands to access the copied file. Example:: - merge: src: game_file_id dst: $GAMEDIR/location Extracting archives ------------------- Extracting archives is done with the ``extract`` directive, the ``file`` argument is a ``file id`` or a file path with optional wildcards. If the archive(s) should be extracted in some other location than the ``$GAMEDIR``, you can specify a ``dst`` argument. You can optionally specify the archive's type with the ``format`` option. This is useful if the archive's file extension does not match what it should be. Accepted values for ``format`` are: tgz, tar, zip, 7z, rar, txz, bz2, gzip, deb, exe and gog(innoextract), as well as all other formats supported by 7zip. Example:: - extract: file: game_archive dst: $GAMEDIR/datadir/ Making a file executable ------------------------ Marking the file as executable is done with the ``chmodx`` directive. It is often needed for games that ship in a zip file, which does not retain file permissions. Example: ``- chmodx: $GAMEDIR/game_binary`` Executing a file ---------------- Execute files with the ``execute`` directive. Use the ``file`` parameter to reference a ``file id`` or a path, ``args`` to add command arguments, ``working_dir`` to set the directory to execute the command in (defaults to the install path). The command is executed within the Lutris Runtime (resolving most shared library dependencies). The file is made executable if necessary, no need to run chmodx before. You can also use ``env`` (environment variables), ``exclude_processes`` (space-separated list of processes to exclude from being monitored when determining if the execute phase finished), ``include_processes`` (the opposite of ``exclude_processes``, is used to override Lutris' built-in monitoring exclusion list) and ``disable_runtime`` (run a process without the Lutris Runtime, useful for running system binaries). Example:: - execute: args: --arg file: great_id You can use the ``command`` parameter instead of ``file`` and ``args``. This lets you run bash/shell commands easier. ``bash`` is used and is added to ``include_processes`` internally. Example:: - execute: command: 'echo Hello World! | cat' Writing files ------------- Writing text files ^^^^^^^^^^^^^^^^^^ Create or overwrite a file with the ``write_file`` directive. Use the ``file`` (an absolute path or a ``file id``) and ``content`` parameters. You can also use the optional parameter ``mode`` to specify a file write mode. Valid values for ``mode`` include ``w`` (the default, to write to a new file) or ``a`` to append data to an existing file. Refer to the YAML documentation for reference on how to including multiline documents and quotes. Example:: - write_file: file: $GAMEDIR/myfile.txt content: 'This is the contents of the file.' Writing into an INI type config file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Modify or create a config file with the ``write_config`` directive. A config file is a text file composed of key=value (or key: value) lines grouped under [sections]. Use the ``file`` (an absolute path or a ``file id``), ``section``, ``key`` and ``value`` parameters or the ``data`` parameter. Set ``merge: false`` to first truncate the file. Note that the file is entirely rewritten and comments are left out; Make sure to compare the initial and resulting file to spot any potential parsing issues. Example:: - write_config: file: $GAMEDIR/myfile.ini section: Engine key: Renderer value: OpenGL :: - write_config: file: $GAMEDIR/myfile.ini data: General: iNumHWThreads: 2 bUseThreadedAI: 1 Writing into a JSON type file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Modify or create a JSON file with the ``write_json`` directive. Use the ``file`` (an absolute path or a ``file id``) and ``data`` parameters. Note that the file is entirely rewritten; Make sure to compare the initial and resulting file to spot any potential parsing issues. You can set the optional parameter ``merge`` to ``false`` if you want to overwrite the JSON file instead of updating it. Example:: - write_json: file: $GAMEDIR/myfile.json data: Sound: Enabled: 'false' This writes (or updates) a file with the following content:: { "Sound": { "Enabled": "false" } } Running a task provided by a runner ----------------------------------- Some actions are specific to some runners, you can call them with the ``task`` command. You must at least provide the ``name`` parameter which is the function that will be called. Other parameters depend on the task being called. It is possible to call functions from other runners by prefixing the task name with the runner's name (e.g., from a dosbox installer you can use the wineexec task with ``wine.wineexec`` as the task's ``name``) If the command you will run in the task doesn't exit with a return code of 0, you can specify an accepted return code like ``return_code: 256`` Currently, the following tasks are implemented: * wine: ``create_prefix`` Creates an empty Wine prefix at the specified path. The other wine directives below include the creation of the prefix, so in most cases you won't need to use the create_prefix command. Parameters are: * ``prefix``: the path * ``arch``: optional architecture of the prefix, default: win64 unless a 32bit build is specified in the runner options. * ``overrides``: optional DLL overrides, format described later * ``install_gecko``: optional variable to stop installing gecko * ``install_mono``: optional variable to stop installing mono Example:: - task: name: create_prefix arch: win64 * wine: ``wineexec`` Runs a windows executable. Parameters are ``executable`` (``file ID`` or path), ``args`` (optional arguments passed to the executable), ``prefix`` (optional WINEPREFIX), ``arch`` (optional WINEARCH value, by default inherited from the `game:` section, which itself defaults to win64. The value can be set to ``win32`` to run the task in a 32-bit prefix.), ``blocking`` (if true, do not run the process in a thread), ``description`` (a message be shown to the user during the execution of the task), ``working_dir`` (optional working directory), ``exclude_processes`` (optional space-separated list of processes to exclude from being monitored when determining if the execute phase finished), ``include_processes`` (the opposite of ``exclude_processes``, is used to override Lutris' built-in monitoring exclusion list), ``env`` (optional environment variables), ``overrides`` (optional DLL overrides). Example:: - task: arch: win64 blocking: true description: Doing something... name: wineexec executable: drive_c/Program Files/Game/Game.exe exclude_processes: process_not_to_monitor.exe "Process Not To Monitor.exe" include_processes: process_from_the_excluded_list.exe working_dir: /absolute/path/ args: --windowed * wine: ``winetricks`` Runs winetricks with the ``app`` argument. ``prefix`` is an optional WINEPREFIX path. You can run many tricks at once by adding more to the ``app`` parameter (space-separated). By default Winetricks will run in silent mode but that can cause issues with some components such as XNA. In such cases, you can provide the option ``silent: false`` Example:: - task: name: winetricks app: nt40 silent: true For a full list of available ``winetricks`` see here: https://github.com/Winetricks/winetricks/tree/master/files/verbs * wine: ``eject_disk`` runs eject_disk in your ``prefix`` argument. Parameters are ``prefix`` (optional wineprefix path). Example:: - task: name: eject_disc * wine: ``set_regedit`` Modifies the Windows registry. Parameters are ``path`` (the registry path, use backslashes), ``key``, ``value``, ``type`` (optional value type, default is REG_SZ (string)), ``prefix`` (optional WINEPREFIX), ``arch`` (optional architecture of the prefix). Example:: - task: name: set_regedit path: HKEY_CURRENT_USER\Software\Valve\Steam key: SuppressAutoRun value: '00000000' type: REG_DWORD * wine: ``delete_registry_key`` Deletes registry key in the Windows registry. Parameters are ``key``, ``prefix`` (optional WINEPREFIX), ``arch`` (optional architecture of the prefix). Example:: - task: name: set_regedit path: HKEY_CURRENT_USER\Software\Valve\Steam key: SuppressAutoRun value: '00000000' type: REG_DWORD * wine: ``set_regedit_file`` Apply a regedit file to the registry, Parameters are ``filename`` (regfile name), ``arch`` (optional architecture of the prefix). Example:: - task: name: set_regedit_file filename: myregfile * wine: ``winekill`` Stops processes running in Wine prefix. Parameters are ``prefix`` (optional WINEPREFIX), ``arch`` (optional architecture of the prefix). Example:: - task: name: winekill * dosbox: ``dosexec`` Runs dosbox. Parameters are ``executable`` (optional ``file ID`` or path to executable), ``config_file`` (optional ``file ID`` or path to .conf file), ``args`` (optional command arguments), ``working_dir`` (optional working directory, defaults to the ``executable``'s dir or the ``config_file``'s dir), ``exit`` (set to ``false`` to prevent DOSBox to exit when the ``executable`` is terminated). Example:: - task: name: dosexec executable: file_id config: $GAMEDIR/game_install.conf args: -scaler normal3x -conf more_conf.conf Displaying a drop-down menu with options ---------------------------------------- Request input from the user by displaying a menu filled with options to choose from with the ``input_menu`` directive. The ``description`` parameter holds the message to the user, ``options`` is an indented list of ``value: label`` lines where "value" is the text that will be stored and "label" is the text displayed, and the optional ``preselect`` parameter is the value to preselect for the user. The result of the last input directive is available with the ``$INPUT`` alias. If need be, you can add an ``id`` parameter to the directive which will make the selected value available with ``$INPUT_`` with "" obviously being the id you specified. The id must contain only numbers, letters and underscores. Example:: - input_menu: description: "Choose the game's language:" id: LANG options: - en: English - fr: French - "value and": "label can be anything, surround them with quotes to avoid issues" preselect: en In this example, English would be preselected. If the option eventually selected is French, the "$INPUT_LANG" alias would be available in following directives and would correspond to "fr". "$INPUT" would work as well, up until the next input directive. Example scripts =============== Those example scripts are intended to be used as standalone files. Only the ``script`` section should be added to the script submission form. Example Linux game:: name: My Game game_slug: my-game version: Installer slug: my-game-installer runner: linux script: game: exe: $GAMEDIR/mygame args: --some-arg working_dir: $GAMEDIR files: - myfile: https://example.com/mygame.zip installer: - chmodx: $GAMEDIR/mygame system: env: SOMEENV: true Example wine game:: name: My Game game_slug: my-game version: Installer slug: my-game-installer runner: wine script: game: exe: $GAMEDIR/mygame args: --some-args prefix: $GAMEDIR/prefix arch: win32 working_dir: $GAMEDIR/prefix files: - installer: "N/A:Select the game's setup file" installer: - task: executable: installer name: wineexec prefix: $GAMEDIR/prefix wine: Desktop: true overrides: ddraw.dll: n system: env: SOMEENV: true Example gog wine game, some installer crash with with /SILENT or /VERYSILENT option (Cuphead and Star Wars: Battlefront II for example), (most options can be found here http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline, there is undocumented gog option ``/NOGUI``, you need to use it when you use ``/SILENT`` and ``/SUPPRESSMSGBOXES`` parameters):: name: My Game game_slug: my-game version: Installer slug: my-game-installer runner: wine script: game: exe: $GAMEDIR/drive_c/game/bin/Game.exe args: --some-arg prefix: $GAMEDIR working_dir: $GAMEDIR/drive_c/game files: - installer: "N/A:Select the game's setup file" installer: - task: args: /SILENT /LANG=en /SP- /NOCANCEL /SUPPRESSMSGBOXES /NOGUI /DIR="C:/game" executable: installer name: wineexec Example gog wine game, alternative (requires innoextract):: name: My Game game_slug: my-game version: Installer slug: my-game-installer runner: wine script: game: exe: $GAMEDIR/drive_c/Games/YourGame/game.exe args: --some-arg prefix: $GAMEDIR/prefix files: - installer: "N/A:Select the game's setup file" installer: - execute: args: --gog -d "$CACHE" setup description: Extracting game data file: innoextract - move: description: Extracting game data dst: $GAMEDIR/drive_c/Games/YourGame src: $CACHE/app Example gog linux game (mojosetup options found here https://www.reddit.com/r/linux_gaming/comments/42l258/fully_automated_gog_games_install_howto/):: name: My Game game_slug: my-game version: Installer slug: my-game-installer runner: linux script: game: exe: $GAMEDIR/game.sh args: --some-arg working_dir: $GAMEDIR files: - installer: "N/A:Select the game's setup file" installer: - chmodx: installer - execute: file: installer description: Installing game, it will take a while... args: -- --i-agree-to-all-licenses --noreadme --nooptions --noprompt --destination=$GAMEDIR Example gog linux game, alternative:: name: My Game game_slug: my-game version: Installer slug: my-game-installer runner: linux script: files: - goginstaller: N/A:Please select the GOG.com Linux installer game: args: --some-arg exe: start.sh installer: - extract: dst: $CACHE/GOG file: goginstaller format: zip - merge: dst: $GAMEDIR src: $CACHE/GOG/data/noarch/ Example steam Linux game:: name: My Game game_slug: my-game version: Installer slug: my-game-installer runner: steam script: game: appid: 227300 args: --some-args