OpenTS: A Source Reconstruction of the Tiberian Sun Engine, and Who Should Build On It

What OpenTS rebuilds, and who the two audiences are

The retail Tiberian Sun executable is a closed binary. The usual community approach is to patch or extend that binary in place, which keeps compatibility but ties every change to the original layout. OpenTS takes the other route: it rebuilds the engine as a standalone program, targeting Tiberian Sun 2.03 Firestorm. The README is explicit that this is not a remaster or remake, not an official Electronic Arts source release, and not a distribution of the original game assets.

The project states two goals of equal weight: keeping a playable engine, and providing a capable platform for modding and engine development. That balance is the interesting part. Engines that prioritize playability tend to freeze their internals; engines that prioritize moddability tend to drift away from the original game. OpenTS says work on one goal should not come at the expense of the other, which is a constraint on how changes get accepted rather than a feature.

The two audiences follow from that. Players get a build that runs the GDI, Nod, and Firestorm campaigns, skirmish, and save/load, all of which the README says have received full play-through testing. Modders and engine developers get a codebase that is being modernized incrementally toward an entity-component architecture, with new work shaped so that migration stays possible. If you are in the second group, docs/DIRECTION.md is where the reasoning is written down.

How the engine is put together and where the data comes from

OpenTS supplies the engine, not the game data. The README states plainly that the installation step provides the original assets, so the binary you download expects to sit next to a real Tiberian Sun installation. There is no installer, and no extra runtime library or launch argument is required: you extract the release zip into the game directory and run Game.exe.

The lineage matters for understanding what the code is. According to the README, OpenTS is based on Electronic Arts' GPL-released source for related Command & Conquer games plus Tiberian Sun-specific reverse engineering, and it continues the community reconstruction preserved in the TibSun archive. That means a large part of the engine is derived from published EA source, with the Tiberian Sun-specific behaviour recovered by working against the original executable.

The renderer is bgfx, and the README says it supports modern resolutions through 4K, including ultrawide. That is a visible break from the original engine's display handling, and it is the kind of change that has to be made carefully if the goal is no user-visible regression. On that point the README claims no user-visible regression from the original game is currently known. Treat that as the project's own assessment of 0.1.0 rather than an independent finding.

The repository layout reflects the same split: code/, thirdparty/, cmake/, tests/, manual/, and docs/ sit alongside Run/, which is where the runtime pieces live. The manual at the project's GitHub Pages site documents setup, runtime behavior, INI configuration, mapping, and source-level internals.

Installing OpenTS and running a first skirmish

The README gives a three-step install and it is worth following in order, because the engine has nothing to load without the retail assets. First, install Tiberian Sun from Command & Conquer The Ultimate Collection on Steam or the EA App. Second, download a release zip and extract it into that Tiberian Sun game directory. Third, run Game.exe from there.

The releases page carries one zip per platform, named OpenTS-<version>-Win32.zip and OpenTS-<version>-x64.zip. Each contains Game.exe, Language.dll, and Game.pdb. The 32-bit build runs on both 32-bit and 64-bit Windows and has the longer runtime history; the 64-bit build runs on 64-bit Windows only.

There is no config file to edit before the first run and no environment variable to set. The README states that no extra runtime library or launch argument is required. If you would rather track merged changes than tagged releases, the Engine nightly workflow produces development snapshots, and nightly.link lets you download the latest one without a GitHub account. The README notes that nightlies contain the latest merged changes without release validation and expire after 90 days.

Pick the 32-bit build unless you have a reason not to. For a first skirmish either will do; the difference bites later, in saves and network games.

The pointer width trap in saves and LAN games

This is the limitation that will actually cost you time. The README warns that the 32-bit and 64-bit builds write saves and network packets at their own pointer widths, and that neither build checks which platform produced what it is reading. A mismatch surfaces as a failed load or a desync. The practical rules the README gives are to keep a saved game with the platform that wrote it, and to play a network game with peers on the same platform.

What makes this worth stating as a design trade-off rather than a bug report is the missing check. A format tag or a version field in the save header would turn a confusing failure into a clear error message. The engine does not do that, so the failure mode is silent until load time or until a game desynchronizes mid-match. If you run a mixed group, agree on one build up front.

The other boundary is the platform itself. OpenTS supports Windows 10 version 1903 (build 18362) and newer. Earlier Windows versions are untested and unsupported. Wine may work, but the README states there is no supported native Linux build. If Linux is a requirement for your group, this is the wrong tool today, and no amount of configuration changes that.

Multiplayer testing is thinner than single-player. The README says LAN multiplayer has had more limited testing than the campaigns, skirmish, and save/load, which it describes as fully play-through tested. CnCNet support is not in 0.1.0 at all; it is the first of the three development milestones the project lists.

How OpenTS differs from patching the retail executable

The obvious alternative is the patching approach, and the README names the relevant pieces directly. Vinifera and ts-patches are the projects OpenTS measures itself against: the second development milestone is feature parity with Vinifera and the rest of ts-patches, and the first milestone includes porting the parts of ts-patches that CnCNet support requires.

The difference in approach is structural. A patcher modifies the retail binary at known offsets, which means it inherits the original engine's behaviour for free and only has to describe its deltas. OpenTS reimplements the engine, so it has to reach the same behaviour from scratch and then prove it, which is why the README leans on play-through testing as evidence. The payoff is that engine internals are ordinary source you can restructure, and the project is doing exactly that by moving incrementally toward an entity-component architecture.

That trade-off has a cost the README does not hide: review capacity is limited, and contributors are asked to discuss non-trivial work with the maintainers before implementing it. A rebuild with a small review team moves differently from a patch set that anyone can extend.

There is also a licensing dimension. OpenTS is under the GNU General Public License, version 3 or later, and material derived from Electronic Arts source remains subject to the additional GPL Section 7 terms recorded in LICENSE.md. THIRD_PARTY_NOTICES.md lists bundled dependencies and their licenses. The repository's licence field reads NOASSERTION, so read LICENSE.md and THIRD_PARTY_NOTICES.md yourself rather than trusting a badge. None of this is legal advice; if you plan to redistribute a build or ship a mod, have someone qualified read those two files.

Maintenance, milestones, and what an upgrade costs you

The last push to the default branch was on 2026-09-17, and the most recent release, v0.1.0, was published on 2026-08-27. The repository is not archived. That is a recent enough cadence to treat the project as one that is being worked on, and the README describes it as the active base for maintenance, documentation, modernization, bug fixes, and new modding capabilities.

Upgrade cost is where the platform split returns. Because saves are not portable across pointer widths, moving a group from the 32-bit build to the 64-bit build means abandoning in-progress saves and making sure every peer switches at the same time. For a modder, the larger cost is the architecture migration the README describes: new development is shaped so that migration toward an entity-component architecture stays possible. That phrasing tells you interfaces are expected to move, and code written against today's internals may need rework.

The milestone list is the honest roadmap. CnCNet and CnCNet client support is the current focus, which includes porting parts of ts-patches. Feature parity with Vinifera and the rest of ts-patches comes second. Extending Tiberian Sun with new features, aiming at parity with Red Alert 2 and Yuri's Revenge, comes third. If your reason for adopting OpenTS is CnCNet play, that work is planned but not shipped in 0.1.0.

For building from source, the README says OpenTS builds for 32-bit and 64-bit Windows with Visual Studio 2022 and CMake, and points to docs/BUILDING.md for the exact requirements, commands, and outputs. The README does not document a rollback procedure for a failed upgrade, so keep the previous release zip before extracting a new one over it.

Editorial conclusion

Adopt OpenTS if you own Tiberian Sun through The Ultimate Collection and want a maintained engine base for modding or engine work, and start with the 32-bit release zip because the README notes it has the longer runtime history. Do not adopt it if you need native Linux support, if you want the original assets bundled, or if you expect LAN multiplayer to be as well tested as the campaigns. Before committing, verify two things for yourself: that your Windows build is 1903 or newer, and that every peer in a network game is on the same pointer width, since neither build checks which platform produced a save or a packet.

Frequently asked questions

Official sources

1. Issues
2. OpenTS-Developers/OpenTS on GitHub
3. README
4. Releases