GLSMAC: an OpenGL rebuild of Alpha Centauri that still needs the original game

A modern engine wrapped around the original game resources

GLSMAC is an unofficial open-source reimplementation of Sid Meier's Alpha Centauri and the Alien Crossfire expansion, written in C++ on top of OpenGL and SDL2. The important constraint is stated in the first line of the README: you still need to own the original game and expansion, because GLSMAC loads its resources, the images and the sounds, from an existing installation. Nothing about the art, the audio or the rules is shipped. What the project provides is a new engine and a new front end that can read those files. The motivation is equally concrete in the README's own terms. Alpha Centauri was a great game in the 4X genre, but it is outdated to the point that it barely runs on modern systems, and the multiplayer in particular was built on ancient DirectPlay, which is the part that aged worst. A second motivation is modding, since the original game cannot be modded as thoroughly as many players would like. The licence is AGPL-3.0, which is a heavier choice for a game engine than a permissive licence and deserves attention before building on it.

Three steps to a running build, then it asks for the game path

The quickstart is deliberately short. You download either the latest stable release or the latest development build for the target operating system, and the README notes that for now only 64-bit Windows and Ubuntu are covered. You unpack the archive anywhere you like, since there is no installer and no system-wide state. If you plan to change game scripts, you also unpack the GLSMAC_data archive into the same directory. On first launch the program asks for the path to your SMAC installation, and that path is how it finds the assets to load. Two practical consequences follow from the packaging. The application is self-contained once unpacked, and the only external dependency is a legitimate copy of the original game. The download choice also matters for stability: the stable release is the one to use, while the development build is where the newest work lands. The repository also points to a screenshots wiki page and a YouTube playlist for the current state and the history of the project, which is the fastest way to judge how much of the game is really working.

The game rules stay, the engine and the network stack do not

The README splits the difference between the original and the rebuild into three groups, and the grouping tells you a lot about the project's priorities. What will be the same includes models, images, movies, texts, lore, factions, the game rules such as tech trees and the types of armour and weapons, and the user interface. What will be completely different is the graphics engine and the network code, both of which are fully rewritten so the game runs as smoothly as possible. What may differ slightly is random map generation, the AI, dynamic music and some parts of the interface, because the author recreates them from scratch and tries to keep them close to the original logic without guaranteeing it. The division of labour is a sane one. Rules and content are data in the original files, so reproducing them is mostly a matter of reading and interpreting the same data. The engine and the socket layer are the parts that the original codebase cannot survive on a current operating system, so they are the parts that had to be written from nothing.

The network is incompatible with the original client, and saves may never match

The compatibility section is the most negative part of the README, and it deserves reading before planning any multiplayer. The network will not be compatible with the original client, which means you cannot play a game with somebody running the unmodified game. That is a direct consequence of rewriting the network code, and the project is candid about the trade-off. Saves and maps might be made compatible at some point, but the README calls that very low priority. Mod compatibility is partial and specific. Asset mods that replace PCX or WAV files in the SMAC directory should work, and later versions will also accept upscaled versions of those assets. Mods that modify or link against terranx.exe will not work at all. Mods that change text files probably will not either, although some settings and rules are read from the original game's text files, just not all of them. The roadmap marks basic multiplayer, meaning hosting and joining games, a lobby, and saving and loading games with the same players, as delivered in version 0.3, and says that multiplayer support will be maintained from that point on.

Modding runs through .gls.js scripts that ship inside the binary

The modding story is the most interesting engineering decision in the project. Under the hood, GLSMAC loads .gls.js scripts, a language similar to JavaScript but simplified and tuned for the needs of the game, and all user interface and game logic is now written in those scripts to maximise what can be tweaked. The engine talks to them through event handlers and specific bindings, so the split between engine and content is a real interface rather than a convention. The core scripts are in the GLSMAC_data/default directory, and the mechanics of the override matter here: they are embedded into the GLSMAC binary so it works on its own, but if the binary sees a GLSMAC_data directory in the working directory it reads and uses those instead. Unpacking GLSMAC_data next to the executable is therefore how a modder changes behaviour, and it is why the quickstart treats the data archive as optional but recommended. A separate demo mod exists to show how scripting can be used, and the README notes it is a bit outdated and does not work with recent GLSMAC, which gives a fair picture of how quickly the scripting layer is moving.

The roadmap shows exactly how much of the game logic exists

The version list is unusually detailed for a hobby project, and it doubles as a status report. Version 0.1 covered the fundamental engine functions: rendering, the user interface, the netcode and the sound system. Version 0.2 added the basic map functions, meaning tiles, map generation, and creating, saving and loading games. Version 0.3, the current one, is basic multiplayer. Version 0.4 is game processing, and the listed scope shows how narrow it is: game turns, only three unit types, scout patrols, formers and colony pods, one building, the recycling tanks, one technology, centauri ecology, land bases only, three terraformings, unit combat and victory by conquest. Version 0.5 adds the remaining units, buildings, terraformings and technologies, 0.6 the remaining victory types, 0.7 the AI and diplomacy, 0.8 alien lifeforms and ecology, 0.9 the remaining in-game interface including settings, 0.10 the incidental items such as movies, interludes and dynamic music, and 0.11 the final polish and bug fixing. Versions 1.x are for fixing bugs and adding small optional features, and 2.x is where larger ideas live, including larger maps, higher player counts, online services such as a game browser and hosting long-turn games where people log in and play one turn a day, and alternative art packs.

Contribution rules, vendored dependencies and an explicit AI policy

The README ends with a pass criteria list for any pull request, and it reads like a code review checklist written in advance. Code should look clean, with no bloat, duplication, excessive comments or chaotic placement of functions. For C++ changes there should be no theoretical possibility of vulnerabilities or crashes. The result has to compile on Linux, Windows and FreeBSD, with MacOS mentioned as a future target, and the author asks that you test it if a change touches the CMake files. The result has to work without obvious problems, and it must not add unnecessary performance overhead, with the note that the scripting language is not fast yet, so splitting work into too many nested functions has a real cost. Code style should match the existing style, and camelCase is explicitly not welcome. The dependency policy is stated just as precisely: version increases after 2025/10/20 happen only after the author reviews them manually, so dependencies change rarely, and prebuilt Windows and Ubuntu releases always use vendored dependencies while manual builds can leave that off. The AI policy is that the author does not use AI-generated code, and that pull requests containing it are reviewed exactly like human code, with neither extra slack nor extra scrutiny. The tree also carries AGENTS.md, CLAUDE.md, a CHANGELOG.md, CMakePresets.json and a .clang-format file, so the tooling expectations are as explicit as the code ones.

Editorial conclusion

GLSMAC fits players and modders who want Alpha Centauri running on a modern machine with a scriptable interface and a networking stack that no longer depends on DirectPlay, since the project states that the network code is fully rewritten. It is not usable yet for a full campaign, because the roadmap places the remaining units, technologies, victory types, AI and ecology in versions 0.4 to 0.8, and it cannot be used without owning the original game, since the resources are loaded from an existing installation. Before investing in it, check which version a release corresponds to, because the tagged builds sit at v0.3 and the prebuilt packages are published for 64-bit Windows and Ubuntu only.

Frequently asked questions

Official sources

1. afwbkbc/glsmac on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases