OpenJK: keeping the Jedi Academy engine alive without touching gameplay

A fork whose first commitment is changing nothing

OpenJK describes itself as a community effort to maintain and improve the game and engine powering Jedi Academy and Jedi Outcast, while maintaining full backwards compatibility with the existing games and mods. The sentence does real work, because the next one narrows the ambition: this project does not intend to add major features, rebalance, or otherwise modify core gameplay.

The aims are listed as three items. Improve the stability of the engine by fixing bugs and improving performance. Support more hardware, naming x86_64, Arm and Apple Silicon, and more software platforms, naming Linux and macOS. And provide a clean base from which new code modifications can be made.

Three aims, none of which is a redesign. That is the defining constraint of the project, and it explains most of what you will find in the repository. It is a maintenance project in the strict sense: the game stays as it was, the engine gets ported and debugged, and mods written against the original binaries keep working.

The project is C++ licensed under GPLv2, which the README states as free software with terms in LICENSE.txt. Support questions and feature requests are directed to the JKHub sub-forum or Discord rather than to the issue tracker, and a Coverity scan badge suggests static analysis is part of the build hygiene.

The support matrix says Jedi Outcast multiplayer is not supported

The README publishes a two-row table with single-player and multiplayer columns, and the cells are not flattering. Jedi Academy is marked stable in both columns. Jedi Outcast single player is marked as working but needing attention, and Jedi Outcast multiplayer is marked not supported, with a pointer to JK2MV for that case.

This is the single most useful thing the README tells you, and it is worth reading before anything else. A project claiming full backwards compatibility with two games and mods will nonetheless have a support matrix, and the difference between the two rows here is the difference between an engine you can rely on and one you should test before committing to.

The Java-era style of the table also tells you something about the project's voice. It uses status words rather than prose, which fits a repository whose maintainers are spread across a forum, a Discord server and GitHub. The three listed leads are Ensiform, razor and Xycaleth, followed by a longer contributor list where the parenthetical notes are informative: bibendovsky is credited with save games and platform support, BSzili with JK2 and platform support, exidl with SDL2 and platform support, smcv with Debian packaging, and Tristamus with the icon.

That distribution is itself the project. Porting a game engine to three operating systems and three CPU architectures is not one person's work, and the credits show which parts of it are somebody's long-running specialty.

Installing means putting binaries into GameData

For players the path is short and assumes you already own the game. OpenJK does not ship the base game, so you need Jedi Academy installed and can buy it from Steam, Amazon or GOG if you do not.

Then download the latest build for your operating system, from the repository's `latest` release tag or from the alternate builds site, extract the contents into the Jedi Academy `GameData/` folder, and run the binary matching your platform: `openjk.x86.exe` on Windows, `openjk.i386` on 32-bit Linux, `openjk.x86_64` on 64-bit Linux, or the `OpenJK` app bundle on macOS.

For Steam users the destination folder is spelled out concretely as the GameData directory inside the Jedi Academy install, under the usual `steamapps/common` path. That detail is the kind of thing that saves an hour of confusion, because the engine reads assets relative to that directory and will not find the base game anywhere else.

The Linux instructions cover the case where you have no existing installation. Install SteamCMD, set the download directory with `force_install_dir`, tell SteamCMD to fetch the Windows build with the force-platform-type command, then download with `app_update 6020`. App ID 6020 is Jedi Academy, which is why the Linux instructions read like they do.

The macOS instructions assume the Mac App Store version of the game. Install Homebrew, install SDL2 with brew, extract the OpenJK DMG into the app bundle's Contents directory, then run `OpenJK.app` or `OpenJK SP.app`. Saves, configuration and logs go to a per-user Application Support directory rather than alongside the game, which is the usual convention on that platform.

Building it and using it as a mod base

The developer section of the README is short and points outward for the hard parts. Building and debugging each have their own wiki guide, so the specifics of compiler flags and debugger attachment are not on the repository page.

What the repository does show is the build system's shape. There is a CMakeLists.txt at the root, a `cmake/` directory for toolchain files, and a `Dockerfile` that builds both a 32-bit and a 64-bit binary from a builder image. Five batch scripts generate Visual Studio project files, one each for 2013, 2015, 2017, 2019 and 2022, which is a good summary of the range of toolchains this engine has to keep alive.

The Docker build is the most concrete evidence of how the two architectures are produced. A single Ubuntu 18.04 builder installs the multilib packages and configures twice, once with an i686 toolchain file for the 32-bit target and once without for 64-bit, each with the game and engine build options disabled so you get the dedicated server rather than a client.

FROM ubuntu:18.04
COPY . /usr/src/openjk
COPY --from=builder /opt/JediAcademy/openjkded.* /opt/openjk/
COPY --from=builder /opt/JediAcademy/base/ /opt/openjk/cdpath/base/

The source tree itself is split in a way that reflects the two games. `code/` is the engine, `codemp/` holds the multiplayer code, `codeJK2/` holds the Jedi Outcast parts, and `ui/`, `shared/`, `lib/`, `tools/`, `scripts/`, `tests/` and `docs/` sit alongside them. `rv-readme.txt` is a leftover from the Raven Software original and is still checked in.

Forking for a mod is one define and one pull request

The instructions for using OpenJK as a base for a mod are the most actionable part of the README, and they are four steps long. Fork the project, create a branch, change the `JK_VERSION` define in `codemp/qcommon/game_version.h` from `OpenJK` to your project name, and send a pull request to upstream if you made a change worth sharing.

That third step is the whole integration story, and it is a good sign. A version string in a header means the engine can identify which build produced a save file or a log, so a mod running on OpenJK does not silently collide with a different engine of the same lineage. Everything else about the base is meant to be taken as-is.

The back-porting request at the end of that section is a statement of intent rather than a requirement. The README asks that improvements be sent upstream so other projects do not each solve the same problem, which is the standard argument for keeping a maintenance fork of proprietary-era code alive.

On releases, the pattern is unusual and worth understanding before you plan an upgrade. The most recent release is tagged `latest`, published on 2026-07-11, and its body lists a single commit fixing a spawn item error in Jedi Outcast. The only numbered tag in the history is `v0.0.0` from 2023-09-23, and its changelog page is intentionally blank. So there is no version ladder to reason about: you take the current build, and the tag tells you when it was cut rather than which generation it belongs to.

Editorial conclusion

OpenJK is the right choice for exactly two audiences: players who want Jedi Academy running on a platform it was never released for, and modders who need a maintained, open base rather than a fifteen-year-old binary. Both are served by the same constraint, full backwards compatibility, which is why the project does not add features and why the Jedi Outcast multiplayer cell in its support table says not supported rather than promising a roadmap. The releases are tracked under a rolling `latest` tag rather than numbered versions, with one commit in the most recent, so there is no upgrade ladder to plan. The parts worth knowing before you commit are the supported-game matrix, which is stated plainly and includes one cell that needs attention, and the mod workflow, which is a single define in a header. Start with the latest build for your platform, read the compilation guide if you intend to build, and remember that the base game is still required.

Frequently asked questions

Official sources

1. Issues
2. JACoders/OpenJK on GitHub
3. License: GPL-2.0
4. README
5. Releases