Permafrost Engine: an OpenGL 3.3 RTS engine in C with Python 2.7 scripting

What Permafrost Engine solves, and for whom

Most open source engines are general purpose. Permafrost Engine is not. The README describes it as an OpenGL 3.3 Real Time Strategy game engine written in C, made in the image of old classics with some modern ideas folded in. The feature list is the giveaway: RTS minimap, RTS-style unit selection, RTS unit combat, RTS fog-of-war, RTS base-building, resource gathering and transporting, garrison and transport mechanics, ranged combat with a projectile physics simulation. Those are not primitives you assemble into a game. They are the game.

The intended user is a C programmer who wants to build an RTS and does not want to write hierarchical flow field pathfinding, formation shuffling, or a fog-of-war system from scratch. The second intended user is a gameplay programmer, because engine internals are exposed to Python 2.7 and the engine embeds an interactive Python console. That split matters: simulation and rendering run as C in a two-stage multithreaded pipeline, while game rules can live in script.

It is not for someone who wants to ship a 2D platformer, a first-person shooter, or a mobile title. Nothing in the summary points at those targets, and the RTS-specific systems would be dead weight.

The mechanism: C simulation, Python 2.7 rules, and a saved interpreter

The architecture visible in the README is a two-stage pipeline. Simulation and rendering are separate stages, and movement and pathfinding computations are accelerated with parallelism. On top of that sits a fiber system: work is placed in lightweight tasks scheduled in userspace, and Python tasks are fiber-backed so that cooperative multitasking logic can be written in Python rather than in C callbacks.

The pathfinding stack is the most distinctive part. It combines hierarchical flow field pathfinding, handling of dynamic obstacles, and navigation layers so that different kinds and sizes of units path differently. Land, water and air units each path. Groups of entities avoid each other using Hybrid Reciprocal Velocity Obstacles and the ClearPath algorithm, and formations are re-shuffled with the Hungarian Algorithm. Spatial membership queries use a SIMD-accelerated bitmap grid, and large crowds can be simulated on the GPU with compute shaders.

Rendering is a conventional OpenGL 3.3 programmable pipeline with modern extensions used where available. Animated entities are handled by batching animation pose data into a texture, which is what makes large numbers of animated units practical. Meshes are batched dynamically, data streams to the GPU through a ringbuffer, and terrain uses texture splatting with distance-based mesh LOD. The engine also synthesizes textures programmatically using the Image Quilting algorithm and tiles the map plane aperiodically with Wang Tiling.

The part I would flag as unusual is state handling. The README states that the engine supports serialization and deserialization of the entire Python interpreter state, saving and restoring any engine session including all Python-defined state, and zero-copy forking of state using page-level Copy-on-Write semantics. That is an ambitious design. It means a save file is not just entity positions; it is the interpreter. It also means the interpreter is a load-bearing part of your save format, which constrains how you can change gameplay scripts later.

Building Permafrost Engine on Linux and Windows

There are no retrieved releases, so treat the repository as the distribution. The README's Linux path clones the repository, builds the shared library dependencies into ./lib, then builds the engine. The dependency list is SDL2 2.30.0, GLEW 2.3.1, python 2.7.17, openal-soft 1.21.1, mi-malloc 2.2.3, plus stb_image.h, stb_image_resize.h, khash.h and nuklear.h. The Makefile confirms this by pointing at ./deps/GLEW, ./deps/SDL2, ./deps/Python, ./deps/openal-soft and ./deps/mimalloc, and the README notes all dependencies can be built from source and distributed with the game binary.

git clone https://github.com/eduard-permyakov/permafrost-engine.git
cd permafrost-engine
make deps
make pf

After that, the README says you can invoke make run to launch the demo or make run_editor to launch the map editor. If you want standalone binaries that take no arguments, make launchers produces ./demo and ./editor.

make run
make run_editor
make launchers

For Windows, the README says the same steps work under the mingw-w64 cross-compilation toolchain with one change: pass PLAT=WINDOWS to the make environment. That build can run on a Linux host or natively on Windows via MSYS2. A Visual Studio 2022 solution file, permafrost-engine.sln, sits in the repository root as an alternative.

make deps PLAT=WINDOWS
make pf PLAT=WINDOWS
make launchers PLAT=WINDOWS

The Makefile exposes a few switches worth knowing before your first build: PLAT defaults to LINUX, TYPE defaults to DEBUG, and ASAN, TSAN and LTO default to 0. The debug and release mimalloc libraries are selected from TYPE, so a release build is a TYPE change rather than a separate target. The README does not document what make deps does when a dependency is already present, and it does not document an uninstall or clean-dependency path.

Where Permafrost Engine is the wrong tool

The Python version is the first real constraint. The README lists python 2.7.17 and states that Python is built with a subset of the default modules and packaged with a trimmed-down stdlib. Python 2.7 has been end of life for years, and the engine's scripting surface is built on it. If your project has any dependency policy that forbids an unsupported interpreter, this engine fails that policy before you write a line of gameplay code. The README does not describe a Python 3 port or a migration path.

The second constraint is the save system. Saving the entire Python interpreter state is powerful, but it couples your save format to script internals. The README does not document a versioning scheme for saved sessions, nor a rollback or migration mechanism for saves produced by older scripts. If you plan to patch gameplay scripts after release, that is the thing to investigate before you build content on top of it.

The third is distribution. There are no retrieved releases and no package manager path in the README. Users get source and a make invocation. For a hobby project or an internal tool that is fine. For a team expecting a versioned SDK with changelogs, it is a mismatch.

Finally, the platform list is Linux and Windows. The README does not mention macOS, consoles, or mobile. If any of those are on your roadmap, this is not the engine for that roadmap.

How it compares to Spring and to general purpose engines

The obvious open source comparison is Spring, the long-running RTS engine that also targets Linux and Windows and also ships a scripting layer for game rules. The difference is where the boundary sits. Spring is designed around a separation between engine and game, with games distributed as separate content that the engine loads, and its scripting has historically been Lua. Permafrost Engine inverts that: the flagship game, EVERGLORY, is developed by the same author, and the README frames the relationship that way, with a free Steam demo that also gives access to the scripts powering the gameplay to learn from and modify. The engine and its reference game are one project, and the scripting language is Python 2.7 rather than Lua.

Against a general purpose engine, the trade is the other direction. A general engine gives you a renderer and a scene graph and leaves pathfinding, formations, fog of war and combat to you or to the asset store. Permafrost Engine gives you those systems, already integrated, and asks you to accept its RTS assumptions and its C plus Python 2.7 split. If your game is an RTS, that is a large amount of work removed. If your game is close to an RTS but not one, you will spend your time removing assumptions rather than adding features.

Licence and the cost of keeping up

The repository is licensed GPL-3.0, per the LICENSE.txt file in the root. That is a copyleft licence, and it is the single most consequential fact for anyone considering a commercial release. The README points at a Steam page for EVERGLORY, which shows the author ships a commercial game on this engine, but that tells you about the author's arrangement, not yours. If you intend to distribute a closed-source game, the licence question is one for your own counsel, and neither the README nor the Makefile answers it.

The dependency set has its own licence surface. SDL2, GLEW, openal-soft, mi-malloc, khash.h, nuklear.h and the stb headers are bundled or fetched under ./deps, and the README notes they can be distributed alongside the game binary. Each carries its own terms. Nothing in the README summarizes them.

On maintenance cost: the last push to the default branch was on 2026-08-28, and the repository is not archived. There are no retrieved releases, so there is no version number to pin and no changelog to read between updates. Upgrading means pulling master and rebuilding, and because the engine saves the Python interpreter state, an upgrade that changes script internals can interact with existing saves. The README does not document a compatibility policy for that.

Editorial conclusion

Adopt Permafrost Engine if you are a C programmer building an RTS and you want pathfinding, fog of war, formations and save/restore already implemented, and if you can live with Python 2.7 and a source-only distribution. Do not adopt it if you need a stable tagged release, a scripting language with current security support, or an engine you can evaluate without compiling its dependencies from source. Before committing, verify three things in your own checkout: that make deps completes on your toolchain, that make run opens the demo after make pf, and that the Python 2.7 build the Makefile produces is one you are willing to ship.

Frequently asked questions

Official sources

1. eduard-permyakov/permafrost-engine on GitHub
2. Issues
3. License: GPL-3.0
4. README