Thunder Engine: a modular C++ game engine you assemble from modules

The engine is designed to be assembled, not adopted whole

Most engines ask you to accept a set of subsystems and then work around them. Thunder Engine inverts that. The project describes its main ideology as creating a modular engine, and the point of that design is exclusion: developers can leave out modules they are not using so their project stays lightweight. The API is designed on the same premise, allowing you to write your own modules and use them in your games or in the game editor.

That is an unusual contract for an open source project to advertise, and it has a direct consequence for anyone evaluating it. You are not picking up a finished product, you are picking up a set of parts plus the tooling to choose between them. A team that wants one rendering path and one input path will find the module system unnecessary overhead. A team shipping to several platforms with different needs, or a team that needs to replace one subsystem without forking the whole engine, gets real value from it.

The scope is wider than the module idea. The README calls Thunder Engine a multi-functional lightweight engine for creating 2D and 3D games, with a cross-platform target list of Windows, Linux, macOS, Android, iOS and tvOS, a rendering system described as based on physical principles, and scripting handled by the AngelScript engine. A complete feature list lives at docs.thunderengine.org/basics/features.html, and the repository homepage is thunderengine.org.

The repository layout is the source of truth on engine composition

The top level of the repository shows how the modularity is organised in practice. There are directories named engine, editor, modules, builder, resourcecompiler, worldeditor and build, alongside thirdparty for vendored dependencies and translations for localisation. Supporting files include CMakeLists.txt, config.h, version.cfg and Thunder.qbs, which is the Qt Creator project file. A .gitmodules file is present, so at least some dependencies arrive as git submodules.

The separate editor and worldeditor directories matter for the module story. The API is intended to be usable both inside a running game and inside the game editor, which means a custom module has to work in two hosts, and the engine and tooling are built and shipped separately.

The remaining structural detail worth noting is the tests directory. Its presence tells you the project has an automated test surface, though the README does not describe how to run those tests, and this repository does not document a test command or a coverage target. If test integration matters to your team, that gap is something to ask about before you commit, since the build instruction page and the contribution guide are the only pointers given.

Install paths are the Releases page or a from-source build guide

There is no package manager entry, no npm style install and no single command in the README. Two paths are offered. The first is the Releases page on GitHub, which is where the release version is downloaded from. The second is a build instruction hosted at docs.thunderengine.org/basics/install.html, under the section for building the engine from the source, which covers the other options.

The release naming is plain and dated by year: the tags are 2026.2, 2026.3 and 2026.4, with 2026.4 published on 2026-09-28, 2026.3 on 2026-06-26 and 2026.2 on 2026-04-02. That gives roughly a quarterly release rhythm across the visible history, with a gap of nearly three months before the 2026.4 tag. Releases are labelled as named releases rather than semantic version numbers, so a version comparison across time reads as a year and quarter.

Windows binaries carry a signing story. The README says Windows binaries use free code signing provided by SignPath.io, with a free code signing certificate from the SignPath Foundation. That is worth knowing if your build pipeline checks artifact signatures, and it is a supply-chain detail that a source build does not inherit automatically.

The README warns that things will break and asks you to clear the cache

The most important paragraph in the README is the one headed Attention. It says the engine is still in development and that things will break. If that happens, the first thing to do is clear the project's cache directory and restart the editor, and only if that does not help should you raise an issue.

This is unusual to see stated so plainly, and it shapes how you should evaluate the project. A cache directory that can hold stale state across an editor restart implies that the editor does not always recover from a bad state on its own, so a crash in the middle of a session can cost you a debugging round trip before the report is even written. Plan for that rather than discovering it.

It also tells you the support model. The route for problems is public issue trackers, and the README asks readers to keep reports and questions in public because doing so helps other people. There is no private support channel and no SLA mentioned. The repository also carries a GOVERNANCE.md file, a CODE_OF_CONDUCT.md file, and a CONTRIBUTING.md file, so governance is written down, but the README itself is where the stability expectation is set.

One more maintenance fact: the last push was on 2026-10-18, and the newest tag, 2026.4, came out on 2026-09-28. The engine is being worked on, and the warning above applies to the current state of the code rather than to an abandoned snapshot.

Cross-platform targets and AngelScript are the two concrete commitments

Two technical commitments are stated in the README's feature list. The first is cross-platform support, spelled out as Windows, Linux, macOS, Android, iOS and tvOS. The second is that scripts are supported by the AngelScript engine, so gameplay logic can live in scripts rather than in C++ and be changed without recompiling the game.

Both have consequences worth checking against your own plan. Six platforms means more build configurations to keep working than a single target, and since the release assets come from a Releases page rather than a package registry, per-platform installation is a manual download for each one. The topic tags on the project include opengl and vulkan, which points at the graphics backends it is built against, and metal as well, matching the Apple platform targets.

On the scripting side, AngelScript is a C++ like scripting language with a static type system, so scripts are not JavaScript and not Python. The README states the engine provides a basic framework and extensible tools so developers can focus on creation, and that the API lets you create your own modules. What it does not state is which AngelScript version the engine targets, how scripts are bound to engine types, or how the editor exposes script debugging. Those specifics are the gaps to probe before you commit a team to writing gameplay in it.

Apache-2.0 licensing and a project that asks for contributions

The project is released under the Apache License 2.0, with a LICENSE file at the repository root. That is a permissive licence with an explicit patent grant, which in practical terms means you can embed the engine in a commercial game without paying a royalty, and you must keep the licence and notice files with your distribution. This is a licensing summary, not legal advice, and the specific obligations should be confirmed by whoever handles licensing in your organisation.

The repository is structured for outside contribution. CONTRIBUTING.md is linked from the README, and there is a Discord badge for the community, plus a Weblate translation status badge showing that the interface is localised by volunteers rather than only by the core team. A sponsors.md file and a legal directory sit alongside the code.

For a reader comparing engines, the useful contrast is with an engine shipped as a closed binary or a hosted tool. Thunder Engine gives you the source, the build files and the module boundaries, which means you can read the renderer and the resource compiler rather than infer their behaviour from documentation. The price is the same one mentioned above: you own the integration, and the README's advice to clear the cache directory after a break is the clearest signal of what that ownership looks like day to day.

Editorial conclusion

Thunder Engine fits a team that wants source-level control over engine composition and can afford to carry its own build, since CMakeLists.txt, Thunder.qbs and the modules directory are all in the repository and the API is meant to be extended. It does not fit a project that needs a stable, supported editor on day one, because the README states that things will break and points you at the cache directory rather than at a stability promise. Before committing, check the modules directory against the features you actually need, read the build instruction at docs.thunderengine.org/basics/install.html for the from-source path, and confirm the most recent release, 2026.4, covers the platforms you target.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. thunder-engine/thunder on GitHub