This is an outline of how I built a CI system to develop Counter Strike 2 plugins, complete with an automated build system and local test server.
Context
Counter Strike 2 is a 5v5 first-person shooter video game played by over a million people a day (at the time of writing). The game’s architecture is client-server, meaning the players connect to a central server hosted somewhere between them, on which the game itself is played. This server binary is provided by Valve, the makers of Counter Strike, free of charge for anyone to download and run their own server.
In addition to being able to run your own local server to host the game, there is a project called Counter Strike Sharp which distributes a C# package exposing a number of useful API’s that can be used to write creative mods for the game (called “plugins”) that run on the server-side.
Server Setup
The first thing we must do before anything else is set up a plain old Counter Strike server on a local machine.
I use set of bash scripts known as LinuxGSM to do this. LGSM is an open-source project by a very talented developer, Dan Gibbs. It greatly simplifies the process of configuring a basic server for over 120 self-hostable games on Steam.
To install LinuxGSM, all you need to do is download and run the install script in a POSIX-compliant terminal. It’s best to just use bash, since this is what LGSM is written in. Granted you have sudo access, the script will also download and install any missing dependencies from the appropriate package registry for your distro.
I had this idea to use something like arecord to programatically retain audio from some terminal-based audio thing, like spotifyd, and pipe it through demucs in the same breath, to get familiar tracks (and their stems) to practice in VirtualDJ with. To my surprise, it was much easier than I anticipated, however I was only able to obtain the desired output audio recordings using local hardware with handwritten sciripts. Trying to automate such a process on a platform like Railway has so far been impossible, for reasons I will get into below.
First attempt - local hardware
I was able to get a semblance of this working on a Raspberry Pi Compute Module 4. arecord records the output of spotifyd, while a python script calls the Spotify API to get the song metadata, which is then stored alongside the resulting .wav file.
Bash scripts are then used to create necessary file structures and run the .wav through the command-line demucs utility, for however many sources I want, renaming the output files appropriately.
Furthermore, since spotifyd shows up as a device on Spotify Connect, I am able to trigger this entire process by playing Spotify from my phone and choosing the Pi as my playback device. Way more luxurious than I anticipated.
Second attempt - cloud pipelines
Using an automation platform called Windmill (which I’ve made a popular template for), I was able to create pipelines that successfully utilized ffmpeg as a means to capture output from spotifyd - the latter of which requires compilation from source. I was able to compile all the required software and supply Railway with a Docker image with the required binaries. However, I found that audio was either missing or, due to access restrictions on machines from VPS providers, inaccessible to the end user. I couldn’t find any audio devices using aplay -l and got permission errors trying to access /proc/asound/ to see any processes associated with ALSA or any kind of audio.
