Adding a game

If a game runs as a dedicated server process on a machine GameDash can reach, it can be run by GameDash. What it needs is a module.

What a module has to answer

Adding a game is mostly a matter of answering four questions in code:

1. How is it installed? Downloading server files, usually through SteamCMD, and whatever first-run setup the game requires.
2. How is it started? The executable, its arguments, and where its settings come from.
3. How is it stopped? Cleanly — most games want a save and a warning before the process goes away.
4. How do you know it is running? So the panel can show status and restart it if it dies.

Everything else — file access, resource limits, console, backups — the platform already does, because it is not game-specific.

Which operating systems

A module declares the platforms it supports. Declare only what you have tested: the panel uses this to decide which nodes may host the game, and a module that claims Linux support it does not have will fail at instance creation rather than at install.

You can name a specific platform or use the linux shorthand to cover every supported distribution.

What you do not have to write

Because the daemon abstracts the host, a module does not deal with the difference between Debian and Windows, or between running a process directly and running it in a container. It asks for a child process with an executable and arguments; the platform works out the rest.

That is the reason a module written once tends to work across the fleet.

Getting started

• SDK overview — what the SDK is and how modules are loaded
• Anatomy of a module — the files and metadata
• Creating your first module — the walkthrough
• Example service module — a complete, working one

Sharing it

Modules are the main way the platform grows, and one that covers a game we do not yet support is worth publishing. Community is the place to start that conversation.