Vangers: An Open Source Racing RPG Where the Multiplayer Server Moved to Rust

What the game is, and what is not in the repository

Vangers is described as a video game that combines elements of the racing and role-playing genres, and the repository publishes all source code under the GPLv3 licence. The important qualifier is in what follows. The Fostral world data in the data directory is published by Association K-D Lab under a Creative Commons Attribution-ShareAlike 4.0 International licence, and the LICENSES.md file holds the exact licensing scope and attribution. Other resources necessary for the complete game, meaning maps, sounds and textures, cannot be obtained from the repository at all and have to come from copies of the game purchased on Steam or on GOG. So this is a source-available engine with an open world dataset, not a self-contained game you can clone and play.

The dependency list, and the forked library

The required libraries are listed precisely, and one entry is a fork that tells you something about the project. You need SDL 3.2 or newer, SDL_net 3.2 or newer, libvorbis, ffmpeg 6.0 or newer, toml11 4.4.x and zlib, plus SDL3-native clunk from the upstream master branch, which is a fork rather than a released package. The clunk fork is the kind of dependency that decides whether a project can build unattended, since it has to be fetched from a branch rather than from a package registry, and it points to a project that shares the maintainers. The rest of the list is a normal C++ game stack: SDL for windowing and input, ffmpeg for video, libvorbis for audio, a TOML parser for configuration and zlib for compression. The build instructions are on the project wiki pages rather than in the readme.

Settings that moved from binary files to TOML

The user settings migration is a good example of a project modernising its data formats without breaking anyone's setup. Vangers stores user preferences and input bindings in the UTF-8 settings.toml file, and on the first launch after updating, the existing options.dat and controls.dat files are imported automatically. The legacy files are kept byte-for-byte unchanged so an older game build can still use them, but subsequent changes made by the new build are saved only to settings.toml. Save-game files are not affected by the migration. The byte-for-byte promise is the detail that matters, because it means you can run the old and new builds against the same directory without a converter or a backup ritual.

Gamepad support, and the deliberate decision not to call Steam Input

SDL3-compatible gamepads are detected and mapped automatically, including hot-plugging, and the default bindings are documented in detail: the left stick steers, the right and left triggers control forward and reverse throttle, the right stick moves the UI cursor and during gameplay controls side impulses and RIG movement, the face buttons provide actions, the handbrake, the jump spring and fire-all, pressing the left stick activates Vector, and D-pad up opens the inventory while right, down and left fire weapon slots two, three and four. In menus the D-pad navigates focus instead. The design decision worth noting is that the open-source build does not call Steam Input directly and keeps the active SDL_Gamepad, so a Steam build can associate the same SDL-managed device with Steam Input without introducing a second device manager, and strong collisions involving the player's mechos use SDL gamepad rumble when input.controller.rumble is enabled.

The server moved to Rust, and the protocol version matters

The maintained multiplayer server is a separate Rust project, stalkerg/vangers-srv, and the client and server must be matched. Use its master branch with the current Vangers client, since both use network protocol 6, and servers using older protocol versions are not compatible with the current client. The legacy C++ server is no longer built or shipped in this repository, including CI artifacts and Flatpak bundles, while multiplayer client support is unchanged, so hosting a game now means running the Rust server separately.

git clone --branch master https://github.com/stalkerg/vangers-srv.git
cd vangers-srv
cargo run --release --locked -p vangers-srv

The default port is TCP 2197, and the port can be changed with the --port option or the VANGERS_PORT environment variable, for example to run on 2198.

No TLS in the native path, and where the web access sits

Native clients connect over TCP and do not need WSS or TLS certificates, and the old Docker and websockify launcher has also been removed from this repository. WebSocket and WSS access for web clients requires a separate proxy and is not built into the Rust server. That is a meaningful change for anyone who was running the old stack, since a browser client cannot talk to a plain TCP socket and someone now has to put a proxy in front. The server repository is also where the deployment configuration lives, with an environment settings example, a Dockerfile and a Compose configuration referenced from the readme. The audited Rust baseline is a specific commit, 29fb0cb, after merging a dated integration branch into master, and the documentation is careful to say this describes source compatibility rather than the revision deployed on a public host.

The multiplayer plans, and what they say about the state of the work

The repository keeps three Markdown documents that are worth more than the readme to anyone following the project, and their titles describe what kind of work each records. The multiplayer refactor plan covers matching client and Rust server revisions, completed item, snapshot and latency work, and a backlog. The NetID and ownership architecture notes describe the current station and owner model alongside a deferred logical item and generation design. The historical desync investigation, dated 2026-05-17, holds the original evidence and is explicitly superseded as implementation guidance by the network plan. That the project documents its own desync investigation rather than hiding it is a good sign, and the structure of the three documents, separating what is implemented, what is deliberately deferred and what still needs recorded runtime results, tells you the project is honest about where it is.

Build infrastructure and the state of the repository

The repository carries four GitHub Actions workflows, for an OSS Linux build, an OSS Windows 64-bit build, an OSS macOS build and a Clang Format check, so the three platforms are built in continuous integration and the formatting is enforced rather than assumed. The top level shows a CMake project with a cmake directory, a lib directory, a src directory, data, packaging, formulas for the Linux distribution packaging, surmap for the game's world map tooling, tests, and vcpkg.json for dependency resolution through the vcpkg toolchain. There is a Vangers.app directory for the macOS bundle, an INSTALL file, and a LICENSES directory alongside LICENSES.md. The release history is short, with the first public GPL version in 2016 and a Vangers 2.0 release candidate in 2021, while the last push was on 2026-10-06, so the recent activity is in the repository and the multiplayer work rather than in a stream of tagged releases.

Editorial conclusion

Vangers fits a player who wants the open source build of a game that shipped on Steam and GOG, and a developer curious about a project that is moving its networking to Rust while keeping the client in C++. It is the wrong choice if you want a complete game without buying it, since maps, sounds and textures are not in the repository and have to come from a purchased copy, and the wrong choice if you want a single-command build, because the dependency list is long and includes a forked library. Before you start, read the licensing notes, because the world data is under a different licence from the code.

Frequently asked questions

Official sources

1. KranX/Vangers on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases