# GBR Hosting game templates

Every game you can host on [GBR Hosting](https://gbrhosting.com) is defined by a template in this repo.
They're public so you can see exactly what your server runs: the Docker image, the startup command,
the install script, and every default setting.

## Layout

```
games/<id>/game.yaml   the template
games/<id>/test.yaml   values CI uses to boot-test it
schema/                JSON Schemas for both files
cmd/gbrgames/          validator and importer
```

## Reading a template

| Field | What it means |
| --- | --- |
| `defaultDockerImage` | The container image your server runs in. |
| `defaultStartupCommand` | The command started inside that container. |
| `installMethod` / `installConfig` | How game files are installed: `STEAMCMD` (anonymous SteamCMD download of `appId`), `BASH_SCRIPT` (the `script` shown in full), or `NONE` (the image already contains the game). |
| `defaultPorts` | Ports opened for players. |
| `defaultConfig` | Starting value for every setting. |
| `configSchema` | Which settings you can edit in the panel, with their types and limits. |
| `configFilePath` / `configFileFormat` | Where settings are written in your server's files, and in what format (`INI`, `JSON` or `ENV`). |
| `backupPaths` | What's included in backups. |

### Your settings vs. the defaults

When you create a server, it starts with `defaultConfig`. Anything you change in the panel overrides
that one setting for your server only; everything else keeps following the template. A few settings
are fixed by your plan. For example, the key named in `maxPlayersConfigKey` always matches your plan's
player count.

### Values filled in for you

Some defaults are placeholders the panel replaces when your server starts:

| Placeholder | Becomes |
| --- | --- |
| `{SERVER_NAME}` | Your server's name. |
| `{PUBLIC_IP}`, `{PUBLIC_HOST}`, `{PUBLIC_PORT_n}` | The address players connect to. |
| `{saved:KEY}` | A value you stored under Saved Values (e.g. a password or token). |

### Generated passwords

Admin and RCON passwords are never shared between servers. A setting marked `x-generate` is left blank
in the template, and if you leave it blank when you deploy, your server gets its own easy password like
`otter-maple-42`. You can see it and change it any time in your server's settings. Values under
`replace` are old shared defaults: a server still using one gets a fresh password the next time it starts.

### Agreements

A setting marked `x-consent` in `configSchema` (a game's EULA, for example) is never accepted for you.
You tick it yourself when you deploy.

## Changes

Templates are maintained by GBR Hosting. Every change is a commit here, so the history shows what
changed for each game and when. Want a game added or something fixed? Open an issue.

## Tooling

```bash
go run ./cmd/gbrgames validate                     # what CI runs on every push
go run ./cmd/gbrgames import admin-games.export.json  # pull templates from GET /api/v1/admin/games
```

`go run ./cmd/gbrgames inspect-image -game <id>` pulls the game's Docker image and reads what it needs
without starting the game: its user, home folder permissions, ports, tools and startup scripts. It then
checks the template against that, e.g. an image built around its own user needs `containerUser`, and a
startup command must read settings under the names the node gives them (`RCONPort` arrives as
`RCONPORT`). Boot tests run it first, so these fail in seconds. `-json` prints the facts for tooling.

Besides the schemas, `validate` checks that each folder name matches its `id`, that referenced config
keys exist, that consents don't default to accepted, and that no credentials or private network
addresses end up in a template.