# Aleph One: the open source continuation of the Marathon 2 engine

> Aleph One plays Marathon, Marathon 2, Marathon Infinity and third-party scenarios on macOS, Windows and Linux, and it is a working continuation of a discontinued engine rather than a re-implementation. Getting it to build means dealing with vcpkg on two platforms and autoconf on the third, and the scenario data has to be supplied separately from the binary.

**Aleph-One-Marathon/alephone** — Aleph One is the open source continuation of Bungie’s Marathon 2 game engine.

- Repository: https://github.com/Aleph-One-Marathon/alephone
- Website: https://alephone.lhowon.org/
- Stars: 816 · Forks: 142
- Language: C++
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/aleph-one-marathon-alephone

## An engine continuation, not a fork of a shipped commercial game

Aleph One is the open source continuation of Bungie's Marathon 2 and Marathon Infinity game engines, and it plays Marathon, Marathon 2, Marathon Infinity and third-party content on a variety of platforms. The wording matters. This is a continuation of the engine, so the artifact you get is a player, not a commercial release with patches applied.

That distinction explains most of what the repository looks like. The source tree is organized like an engine project: Source_Files/ for the code, Resources/ for game assets, data/ for bundled data, tools/ for utilities, tests/ for automated coverage, and separate build systems for each platform, including VisualStudio/, Xcode/, a vcpkg/ subdirectory and a flatpak/ directory. There is a marathon.dtd at the root, which is a document type definition for the scenario markup the engine parses, and a directory of MML Scripts, the engine's scripting layer.

A player that loads arbitrary third-party scenarios needs a stable scripting and scenario format to hold together, and the presence of both a DTD and a scripting directory is the visible sign of that contract. The project is licensed under the GNU General Public License 3, and the COPYING file at the root carries it.

For a user, the practical entry point is not the repository at all. Ready-to-run builds of all three Marathon games for macOS, Windows and Linux Flatpak are distributed from alephone.lhowon.org, and the project also appears on Steam.

## macOS and Windows share one dependency manager, vcpkg, and one warning about paths

Two of the three platforms are built on vcpkg, and both carry the same caveat: put the checkout and vcpkg somewhere without spaces, and on Windows without non-ASCII characters. The macOS section says some users had issues building when the path to vcpkg and to alephone contained spaces, and the Windows section quotes the vcpkg getting-started advice to prefer a short install path such as C:\src\vcpkg or C:\dev\vcpkg, noting that the same rules apply to the Aleph One source location.

The macOS path assumes familiarity with the Xcode tools and the macOS command line. You bootstrap vcpkg yourself:

```bash
git clone https://github.com/microsoft/vcpkg
./vcpkg/bootstrap-vcpkg.sh
./vcpkg/vcpkg integrate install
```

Then you move into the vcpkg subdirectory inside the Aleph One checkout and run the install-arm-osx.sh and install-x64-osx.sh scripts to install the macOS dependencies for arm64 and x64. Both scripts are needed if you want a universal machine, and the project makes you do it per architecture rather than shipping a prebuilt dependency set. After that you open Xcode/AlephOne.xcodeproj and build.

On Windows the same three steps run through a batch file instead, and the build uses the VisualStudio\AlephOne.sln solution file:

```bash
git clone https://github.com/microsoft/vcpkg.git
.\vcpkg\bootstrap-vcpkg.bat
.\vcpkg integrate install
```

Note the paths differ between the two platforms, with the Windows clone including the .git suffix and the integration command pointing at the batch file. That is not a typo in the documentation, and it is the kind of detail that will cost you an afternoon if you assume they are interchangeable.

## Linux and FreeBSD take a different road entirely: autoconf, configure, make

The Unix path shares nothing with the vcpkg paths, which is worth knowing before you plan a build matrix. Linux, FreeBSD and other systems are built using autoconf. If you downloaded a source tarball, the configure system is already set up for you; if you cloned from git, you have to generate it yourself, which means installing autoconf and autoconf-archive from your distribution's package manager and running autoreconf.

The build itself is the familiar three steps, configure, make, then install:

```bash
autoreconf -i
./configure
make
```

Installation asks for administrator rights, and the executable lands in a predictable place:

```bash
sudo make install
```

By default the Aleph One executable is installed into /usr/local/bin/alephone. The project also ships a Dockerfile.hub at the root, a flatpak/ directory and a spec file template, AlephOne.spec.in, which suggests the packaging work for Linux distributions was being carried alongside the engine itself rather than left to packagers.

The autotools route has one real advantage over the vcpkg routes: the dependency list is expressed as library names you can install from your own package manager, so nothing has to be compiled from source on the machine, and nothing is pinned to a particular vcpkg checkout state.

## The dependency list is really a feature list, split by necessity and by preference

Aleph One requires a C++17 compiler and a set of libraries that are drawn from specific domains: ASIO for asynchronous networking, Boost for general utility work, SDL2 with the SDL2_image and SDL2_ttf companions for windowing, textures and text, zlib for compression, libsndfile for audio file handling, and openal-soft for the audio output itself.

Then a second tier is described as recommended for full features and third-party scenario compatibility, and each entry carries its reason in the documentation. curl is for stats upload to lhowon.org. miniupnpc is for opening router ports, which is what lets a player behind a NAT host a game. zziplib is for using zipped plugins. vpx, matroska, ebml and vorbis together cover film export, and libyuv covers film export as well as video playback.

That list is more informative about the engine than any marketing sentence would be. The presence of a video playback and film export stack means the engine handles recorded footage, and the router port library means multiplayer hosting is a first-class path rather than a community add-on.

Distributions are named with the same specificity. The Fedora instructions install boost-devel, curl-devel, gcc-c++, libpng-devel, SDL2-devel, SDL2_ttf-devel, SDL2_image-devel, asio-devel, zziplib-devel, miniupnpc-devel, openal-soft-devel and libsndfile-devel after enabling the RPM Fusion Repository. The Ubuntu instructions cover the equivalent set plus the film export libraries, including libvpx-dev, libmatroska-dev, libebml-dev, libvorbis-dev, libvorbisenc2 and libyuv-dev.

## Scenario data is not in the repository, and the executable alone will not run a game

Here is the detail that catches out anyone who clones the repository and expects a game. If you only want an Aleph One executable, you can simply download and untar a release source tarball. But to build the all-in-one Mac apps, flatpaks or Windows zip files, you need to populate the data/Scenarios directory, and the easiest way is to clone the repository along with its submodules:

```bash
git clone --recurse-submodules https://github.com/Aleph-One-Marathon/alephone.git
```

The alternative is to download the data files from alephone.lhowon.org/scenarios.html and unzip them into the data/Scenarios/ directory.

So there are two distinct content paths. A source tarball gives you the engine. The scenario data is a separate download, and it is what turns the executable into a playable game. For a third-party scenario author this is the important part: your scenario ships as data, and the engine is the thing that loads it.

Running the result is a matter of pointing the executable at an unzipped game directory:

```bash
/usr/local/bin/alephone ~/Games/Marathon
```

Game data for the three games is also downloadable from the Aleph One Scenarios page, and you unzip one of the games and pass that directory as the argument.

## Still moving, with a release cadence that tracks the Marathon calendar

The engine is not a museum piece. The last push to the repository was on 2026-10-18, and the repository is not archived. Releases are named after the date they were cut, and the most recent, release-20260930, shipped Aleph One 1.11.1 on 2026-10-01. Before that came release-20250829 for version 1.11 and release-20250808 for 1.11b, both in August 2025.

A 1.11.1 patch after a 1.11 release is the kind of numbering that suggests a stable branch receiving fixes rather than frequent churn. The repository carries a changelogs/ directory, and the repository also holds Cheats/, Extras/ and a Steam/ directory, so distribution work for the commercial storefront sits in the same tree as the engine.

Two caveats on what the documentation covers. The README is a build and run guide, and it does not walk through the game's controls, its networking setup beyond the dependency mention, or how to author a scenario. The MML Scripts/ directory and the marathon.dtd are the pointers for content authors, and the docs/ directory and tools/ directory sit alongside them for everything else.

A CI badge for the build workflow is present in the README, which tells you compilation is checked on a schedule, though the badge alone says nothing about which platforms are covered.

## Conclusion

Aleph One is worth adopting if you want to play classic Marathon scenarios or third-party content on a modern platform, or if you intend to write scenario content against a GPL licensed engine that is still receiving pushes. It is the wrong choice if you expected a maintained fork of a shipped game, because it is a continuation of the engine, not a patch set for a commercial release. Before you start, decide how you will obtain the data/Scenarios content, check that your platform toolchain matches one of the three documented paths, and read the build instructions with vcpkg in a short path free of spaces and non-ASCII characters.

## FAQ

### How do I build Aleph One on Linux?

Install autoconf and autoconf-archive from your package manager, run autoreconf -i if you cloned from git, then run ./configure and make. Install with sudo make install, which puts the executable at /usr/local/bin/alephone by default.

### Why does my Aleph One build fail with a path containing spaces?

The macOS and Windows instructions both warn about this. The macOS section says some users had trouble building when the path to vcpkg or alephone contained spaces, and the Windows section recommends a short path such as C:\src\vcpkg with no spaces or non-ASCII characters, and notes those rules apply to the Aleph One source location as well.

### Do I need the scenario data files to run Aleph One?

Yes, for the packaged builds. A release source tarball gives you the executable alone, while building all-in-one Mac apps, flatpaks or Windows zip files requires populating the data/Scenarios directory, either with git clone --recurse-submodules or by downloading and unzipping the data files into that directory.

### Which libraries does Aleph One need for optional features?

curl for stats upload to lhowon.org, miniupnpc for opening router ports, zziplib for zipped plugins, and vpx, matroska, ebml, vorbis and libyuv for film export and video playback. These are listed as recommended for full features and third-party scenario compatibility.

## Sources

- [Aleph-One-Marathon/alephone on GitHub](https://github.com/Aleph-One-Marathon/alephone)
- [License: GPL-3.0](https://github.com/Aleph-One-Marathon/alephone/blob/master/LICENSE)
- [Project website](https://alephone.lhowon.org/)
- [README](https://github.com/Aleph-One-Marathon/alephone/blob/master/README.md)
- [Releases](https://github.com/Aleph-One-Marathon/alephone/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aleph-one-marathon-alephone