ET: Legacy: keeping a 2010 game engine alive and mod compatible

Two deliverables, not one: the engine and the Legacy mod

ET: Legacy is an open source project based on the code of Wolfenstein: Enemy Territory, which was released in 2010 under the terms of the GPLv3. The project's own framing is a second breath of life for that game.

It has two aspects and the distinction matters. The first is an updated game engine, ET: Legacy, which aims to fix bugs and security exploits, remove old dependencies, add useful features and modernize its graphics, while still remaining compatible with ET 2.60b and as many of its mods as possible. The second is a new mod, Legacy, which aims to add many useful features and improvements while staying close to the original gameplay, and which is designed to be lightweight and extensible through Lua scripts.

So the engine is the infrastructure and the mod is the content. A player can use the engine with an existing mod, which is the compatibility promise, or run the bundled Legacy mod for a more modernised experience. The two are versioned together in practice, but they are separate pieces of work.

The primary language is C, and the topics list the expected technical territory: game engine, 3D game engine, OpenGL, networking, Lua, and the platforms Windows, Linux and macOS. The engine is old enough that its dependencies list reads like an inventory of what a mid-2000s Linux distribution shipped, and modernising that list is a large part of what the project has been doing since it started.

The website is at etlegacy.com, the documentation at etlegacy.readthedocs.io, and there is a separate Lua API documentation site, which is the clearest signal of how the extensibility story is meant to work.

The game data stays under the original EULA, and that is not a detail

The general notes section is where the project's legal shape becomes clear, and it is short enough to state plainly. Wolfenstein: Enemy Territory is a free release and can be downloaded from Splash Damage. The source release contains only the engine and mod code, but not any game data, which is still covered by the original EULA and must be obeyed as usual.

Practically, to run ET: Legacy you need to copy the original pak0.pk3 assets file to the etmain folder. Third party mods might also require the pak1.pk3 and pak2.pk3 assets files.

That is a real constraint on adoption and it is worth understanding before anything else. The code is GPLv3 and open. The assets are not in the repository, they are not covered by the GPL, and the EULA for the original release still applies to them. A team shipping a build of this engine has to treat the pak files as third party content with its own terms, and a team that expects a self-contained open source game will not get one.

The repository tree shows the shape of the deliverable. There is src/ for the engine source, etmain/ for the mod, app/ for the game code, vendor/ for third party code, cmake/ and a CMakeLists.txt for the build, and a Doxyfile for documentation generation. The .gitmodules file and the libs directory are the mechanism for the bundled libraries discussed below, and a dist-manifest.json, VERSION.txt and CHANGELOG.yml handle packaging and versioning.

Compatibility is the feature, with two documented exceptions

ET: Legacy remains compatible with the ET 2.60b version as much as possible. That sentence carries most of the project's value, because a game engine that is not compatible with the mod ecosystem is a museum piece.

There are two documented exceptions and they are both about servers rather than about the client code. ET: Legacy is not compatible with PunkBuster enabled servers. ET: Legacy clients also cannot connect to servers running the ETPro mod.

Both are server-side policies rather than engine defects. PunkBuster was the third party anti-cheat system of that era, and the reasons a modern engine cannot satisfy it are practical: it expects a particular client binary and a particular protocol handshake, and an engine that has been rebuilt from source will not match. The ETPro restriction is the same kind of constraint, since a server running a closed mod may require a specific client build. The practical consequence for a player is that the mod servers you can join are a subset, and the wiki's compatible mods page is the place to check.

For a project maintainer, the same compatibility goal explains a lot of the work. Modernising the graphics, replacing old dependencies and changing the build system are all things that can break compatibility with a mod, so the engine changes are constrained by the requirement to keep the protocol and the expectations of existing mods intact.

64 bit is a separate build and a separate mod list

The Linux 64 bit section is the part of the documentation that catches people out, because it is a compatibility boundary rather than a performance option.

64 bit ET: Legacy clients can only connect to servers running mods providing a 64 bit version. You can play 32 bit only mods if you compile ET: Legacy on a 32 bit system, or cross-compile it for the 32 bit architecture on a 64 bit system.

At the moment only the ETrun, ETJump, N!tmod and Legacy mods are available in 64 bit version, while all other existing mods are 32 bit only. So on a modern 64 bit Linux distribution, the default build connects to a small set of servers and everything else requires a 32 bit build.

The project offers a way around the dependency friction. On a 64 bit system you are pointed at the bundled libraries, which live in a separate etlegacy-libs repository and can be downloaded automatically with the git submodule command. The choice between bundled and system libraries is made in the build configuration, through the BUNDLED_LIBS variable in the CMakeList.txt file, and you can then toggle individual bundled libraries with their respective BUNDLED_XXX variables.

That is a sensible arrangement for a project that has to build on distributions where the original 2000s dependency versions no longer exist, and it is also a clear signal of how much of the build system is about surviving on a modern operating system rather than about the game itself.

Building it: CMake variables, submodules and an easybuild script

The dependency list is long and is presented as required versus optional, enabled by default. Required are CMake at compile time only, OpenGL, GLEW, SDL, ZLib, MiniZip, and libjpeg-turbo or libjpeg. Optional and on by default are libcurl, WolfSSL or OpenSSL, Lua, Ogg Vorbis, Theora, Freetype, libpng, SQLite and OpenAL.

The required list is small enough to install on a modern distribution, and the optional list covers the features the game uses. The Libs Changelog wiki page tracks the current versions of each.

Getting the source is a clone, and the submodules carry the bundled dependencies:

$ git clone [email protected]:etlegacy/etlegacy.git

$ git submodule init
$ git submodule update

The install layout is controlled by CMake variables and the documentation is precise about them. INSTALL_DEFAULT_BASEDIR sets the default fs_basepath, where the etl and etlded executables look for data files, and it is usually CMAKE_INSTALL_PREFIX plus INSTALL_DEFAULT_MODDIR. It defaults to empty on purpose, so that fs_basepath is the current working directory when the game is not installed system-wide. INSTALL_DEFAULT_BINDIR is the executable location and defaults to bin, INSTALL_DEFAULT_SHAREDIR is shared data and defaults to share, INSTALL_DEFAULT_MODDIR is where libraries and paks go and defaults to lib/etlegacy with legacy appended, and DOCDIR defaults to the documentation location under the shared directory.

For Linux there is a build script that handles the 32 bit and 64 bit variants:

$ ./easybuild.sh        # for compiling a 32 bit version or
$ ./easybuild.sh -64    # for compiling a 64 bit version

The tree also carries an easybuild.bat for Windows, release.sh and release.bat, a Brewfile for macOS, and a pixi.toml with a pixi.lock, so the project supports several ways of pinning a development environment.

Lua is the extension point, and the mod ecosystem is the point

The two deliverables meet in the Lua story. The Legacy mod is described as lightweight and extensible through Lua scripts, and the project maintains a separate Lua API documentation site at etlegacy-lua-docs.readthedocs.io, which tells you the scripting surface is a documented public contract rather than an afterthought.

For the mod community, that is the difference between a fork and a platform. A fork that only compiles is a fork you have to keep merging. A fork with a scripting API lets mod authors add behaviour without recompiling the engine, and lets the engine team change internals without breaking every mod at once.

The translation setup points the same way. Translations are managed on Transifex under the etlegacy project, and the tree includes a .tx/ directory, which is the Transifex client configuration. An open source game with a translated interface is a game with contributors who are not C programmers, and the Lua API is how those contributors participate in the code rather than only in the text.

The wiki and FAQ live in the repository itself, the assets are in a shared Google Drive folder, and the community is on a Discord server and an IRC channel on irc.libera.chat. Analysis status is tracked through Coverity, and the CI badges at the top of the readme cover the main build and an ETLBuild workflow.

Signed Windows installers, and the state of the repository

One line in the readme solves a problem that has haunted open source game projects for two decades: the ET: Legacy Windows installers are now signed thanks to the SignPath Foundation. A signed installer is what lets a Windows user run a game without clicking through SmartScreen warnings, and for a project whose audience wants to double-click an installer and play, that is not a nicety.

The repository is not archived, and the last push was on 2026-10-19, so the work is current even though the repository has no GitHub releases, with the versioning handled by VERSION.txt, the CHANGELOG.yml file and the release scripts. The licence is GPL-3.0, and the tree includes a COPYING.txt file. The project also publishes a SECURITY.md, which matters for an engine whose stated purpose includes fixing security exploits, and a CONTRIBUTING.md.

Because the engine is C and the game runs on Linux, Windows and macOS, the platform story is broad. The macOS side is visible in the tree through the Brewfile, the build.gradle and settings.gradle files, and the.vs/ directory, and the Snapcraft badge shows a packaged Linux build as well.

A useful piece of archaeology: the readme lists a Discord server, a wiki, a Lua API site, a Transifex project, a Coverity project and SignPath enrolment. Each of those is a place where a maintainer had to invest to keep a sixteen year old codebase alive, and together they are a better picture of what sustaining a game engine costs than any single feature list would be.

Editorial conclusion

ET: Legacy is worth adopting if you want to keep playing Enemy Territory in 2010-era form with a maintained engine, because the project fixes bugs and security exploits, keeps compatibility with ET 2.60b and as many mods as possible, and ships signed Windows installers, which a sixteen year old game engine cannot do on its own. It is the wrong choice if you want a game data set included, because the source release ships no assets and the pak files remain under the original EULA, and it is the wrong choice on a 64 bit system if you play 32 bit only mods. Before you commit, check the three things the documentation is explicit about: that you have the original pak0.pk3 and, for third party mods, pak1.pk3 and pak2.pk3, since without them the game has nothing to load; that you understand the mod server restrictions, since clients cannot connect to PunkBuster enabled servers or to servers running the ETPro mod; and that you pick the right bitness, because 64 bit clients can only connect to servers whose mod provides a 64 bit build, and only ETrun, ETJump, N!tmod and Legacy are available that way.

Frequently asked questions

Official sources

1. etlegacy/etlegacy on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README