6 mistakes developers make when shipping standalone game servers.

And how to avoid them. A short guide.

Letting your players self-host their own games is a great way to extend the life of your game and build its audience. Minecraft owes a lot of its success to its huge community of independently run game servers where admins are free to set whatever rules they see fit. It also means your game is playable far in the future, Quake III Arena came out in 1999 and you can still play it online today 21 years later. This is possible because the developer isn’t having to bear the financial burden of running the servers, its player base does that itself.

But of course most game developers are not server application developers, it’s not their specialisation and that’s fine — focus on your core competencies. But the reality is that the game developers are usually placed in a situation where they are the ones providing the server application.

My company produces server management software, so we’re very familiar with some of the really common mistakes and pitfalls that developers make when shipping these applications.

Insufficient Manageability Options

A game server application should provide administrators with options to control certain in-game behaviours and check on the server without requiring that they themselves fire up a copy of the game. Admins should be able to kick and ban unruly players, chat with active users, change settings and check the current status (connected users, performance metrics, etc)

There’s a few ways you can offer this — making this accessible via your applications standard input/output and accepting text commands is great because it requires zero additional software. And if you make sure that your log output is in a consistent format it makes it super easy to integrate with other administration software.

Alternatively you can implement a common remote admin protocol such as RCON or WebRCON to let users use standalone clients or again admin tools that speak these protocols.

Insane configuration files

Your configuration files should be human readable and writable, and use a fairly simple syntax. Standard key=value files are great because they’re simple to work with, same goes for JSON formatted files for the same reason and also have the advantage of being trivial to (de)serialize for other applications.

I would tend to avoid using XML however, especially if you’re just storing key/value data. It’s excessively verbose for that kind of usage.

Some games however have a huge number of configurable options to allow users to fine-tune certain aspects of the game. In this situation I would strongly recommend that networking and system-level settings be stored in a separate configuration file from your gameplay settings. System level settings would include things like network configuration and player limits.

No command-line arguments

A good server should be fully configurable using purely command line flags, and any settings specified via said flags should override anything specified in a configuration file. This makes it much easier to automate deployment of game servers and ensure that certain settings are locked in place. A command line flag should also be available to specify the location of any configuration file(s).

Lack of a consistent updating system

Especially if you’re not shipping your server via Steam (and it should be a separate application from the game itself) — a few things need to be possible:

• To know what version of the server is currently running.
• To know what the latest version is (e.g. from a downloadable URL that contains update information)
• To know where to download the latest version, either from a static URL that always returns the latest version or a predictable URL to fetch a given version based on the previously mentioned update data.
• No human interaction required, this means no Cloudflare challenges or Captchas to fetch server data.

Inadequate Logging

It’s better to log too much than too little, or ideally implement different logging levels so that admins can choose how much information they want access to at any given time. You should also allow the log file location to be specified, and tolerate being written to named pipes/fifo streams.

This should also be tied to your remote administration heavily, it should be possible for admins to view your applications log in real-time either via standard output or via whichever remote administration protocol is implemented.

Excessive Dependencies

Especially on Linux, a server must be able to run 100% headless. It should not require that an X session exist, or that the user have too many libraries installed that are not shipped as standard in common distributions. If you require extra libraries consider statically linking them rather than using LD_LIBRARY_PATH (as this is a potential security hazard in some situations)

Under Windows the server should tolerate running as a service with a reduced permissions set, and not read/write to the user profile directory. Any directories used should be configurable.