Axmol Engine: a Cocos2d-x 4.0 fork for C++ 2D games on mobile, desktop, Xbox and WebAssembly

What Axmol Engine solves, and who it is for

Axmol Engine is a C++ multi-platform engine aimed at 2D game development. The README describes it as "an open-source, C++ multi-platform engine designed for mobile devices, desktop, and Xbox, well-suited for 2D game development," launched in November 2019 as a fork of Cocos2d-x v4.0.

The audience is narrow and specific. If you have a Cocos2d-x project, the README states that migrating is easy and links a Cocos2d-x migration guide on the wiki. That sentence is the clearest signal of intent: Axmol is not trying to win developers away from visual editors. It is trying to be the maintained continuation for teams that already write 2D games in C++ and want targets Cocos2d-x v4.0 never shipped, notably WebAssembly and Xbox through UWP.

Two languages are supported, C++ and Lua. That matters when you plan a project, because there is no mention of C#, JavaScript or a node-based scripting layer, so the engine assumes you are comfortable in a compiled language or in Lua. Extensions cover FairyGUI, ImGUI, Spine, Live2D and Effekseer, which is the usual 2D middleware set for this kind of engine.

The licence is MIT, which is the permissive end of the spectrum and the reason the README points at third-party and extension licence overviews separately: those components carry their own terms, and the repository keeps 3rdparty/README.md and extensions/README.md for exactly that reason.

How the renderer abstraction and branch model actually work

The architecture detail that stands out is the renderer RHI list. Rather than one graphics API, the README enumerates Vulkan for Windows, Linux and Android; D3D12 and D3D11 for Windows and UWP; Metal for macOS, iOS and tvOS; OpenGL 3.3+ for Linux, macOS and Windows; OpenGL ES 2.0+ for Android; OpenGL ES 3.0+ for iOS and tvOS; ANGLE GLES 3.0+ for Windows and UWP; and WebGL 2.0 for WebAssembly.

That list is not a marketing inventory. It encodes a version split. Vulkan, D3D12 and D3D11 are marked as arriving with axmol-v3, and the README notes that arm64 builds for Linux and Windows are also v3 features. So a team on the stable v2 line is not getting the newer backends, and a team on dev is getting them at the cost of the stability warning attached to that branch.

The branch model is stated bluntly. The dev branch "serves as the v3 development branch" and "may contain unstable or experimental features." The release/2.x branch "has entered the stable maintenance phase," with 2.11.x described as the final v2 LTS release, reserved for critical bug fixes and security patches. The README adds that non-critical feature PRs against release/2.x will not be accepted, and that full-file clang-format or large-scale reformatting PRs against that branch will be rejected because they create merge conflicts. For anyone planning to contribute, that is a real constraint, not a style preference.

On the audio side, the engine moved to OpenAL across all platforms. Passing -DAX_USE_ALSOFT=ON to CMake forces OpenAL Soft; without that option, the CMake script selects OpenAL.framework on OSX, iOS and tvOS. HttpClient was reimplemented on yasio for concurrent request processing, and UserDefault was refactored on mio. Those are the kinds of substitutions a fork of this age accumulates, and they are worth reading before you port code that depended on the original Cocos2d-x behaviour.

Installing Axmol and building a first project from source

There is no package manager step in the README. The project points to docs/DevSetup.md for setup and building, and the repository ships a CMakeLists.txt at the top level plus a cmake/ directory and templates/. A setup.ps1 script sits at the repository root. The README does not document a prebuilt binary download for general use, so expect a source build.

The README names the branches to choose between. For production work it says to use release/2.x; for v3 development, use dev. The README documents one CMake option explicitly: passing -DAX_USE_ALSOFT=ON forces OpenAL Soft as the audio backend, and without that option the CMake script chooses OpenAL.framework on OSX, iOS and tvOS.

-DAX_USE_ALSOFT=ON

That option is a CMake configure flag, so it belongs on the configure command line rather than in a shell by itself. The README gives no full configure command, so docs/DevSetup.md is the place to get the exact invocation for your host platform.

After the build, the templates/ directory is where project scaffolding lives, and docs/DevSetup.md is the document that explains how a generated project is wired to the engine libraries. The README also links a Windows workflow guide covering linking against engine prebuilt libraries, which is the path to take if you do not want to rebuild the engine for every application change.

Two platform notes from the README are worth checking before you write code. Windows defaults to Google ANGLE as the renderer backend, so a Windows build is not exercising the same path as, say, a Metal build on macOS. And the WebAssembly target is labelled a preview, with the README linking Axmol test builds and FairyGUI test builds hosted on Netlify rather than presenting WASM as production-ready.

Where Axmol Engine is the wrong tool

The clearest limitation is the absence of an editor. Nothing in the README describes a scene editor, an asset pipeline UI or a visual scripting environment. Axmol is a code-first engine: you write C++ or Lua, and the templates/ directory plus docs/DevSetup.md are the entry points. A solo developer who expects to drag sprites onto a canvas and press play will find the workflow unfamiliar, and there is no editor download to fall back on.

The second limitation is the version split. If you need Vulkan, D3D12, D3D11, arm64 Linux or arm64 Windows builds, the README attributes those to axmol-v3, which lives on the dev branch described as possibly unstable. If you need stability, you are on release/2.x, which the README calls the final v2 LTS release and restricts to critical fixes and security patches. You cannot have both today, and that is a structural trade-off rather than a temporary gap.

The third is 3D. The README lists supported 2D physics engines (Box2D) and supported 3D physics engines (JoltPhysics), so 3D physics exists, but the engine is described throughout as "well-suited for 2D game development." The feature list is 2D-shaped: FairyGUI, Spine, Live2D, Effekseer, ASTC texture compression. If your project is a 3D game, the README gives you no reason to pick Axmol over a general-purpose 3D engine.

Finally, WebAssembly is a preview. The README labels it as such and links hosted test builds instead of a stable release channel. Treating WASM as a shipping target based on the feature list alone would be reading more into the README than it says.

Axmol against Godot and Cocos2d-x

The honest comparison is with Cocos2d-x itself, because Axmol is a fork of Cocos2d-x v4.0 and the README maintains a wiki page titled Axmol versus Cocos2d-x. The difference in approach is maintenance and reach: Axmol claims to have "iterated and improved over the Cocos2d-x v4.0 base," and it adds targets that the v4.0 base did not cover, namely WebAssembly and Xbox UWP. It also replaces components, for example HttpClient on yasio and UserDefault on mio. If you are on Cocos2d-x v4.0 and your platform list includes a console or the browser, the migration guide is the document to read, and the API surface will feel familiar because it descends from the same code.

Godot is a different kind of answer, and the difference is architectural rather than a feature checklist. Godot is editor-centric: scenes are authored in a visual environment and the engine ships as an application you download and run. Axmol has no editor in the README, builds through CMake from source, and expects C++ or Lua. If your team's skills are in C++ and your codebase already exists, Godot's editor workflow is not a drop-in replacement for a library you link against. If your team wants to author content visually and does not have a C++ codebase to preserve, Godot's model is the one that matches the work.

The related searches people use around this project include "Cocos2dx" and "Godot," which suggests the comparison is already the question developers ask. One concrete distinction holds: Axmol gives you a C++ library with a CMake build and an explicit migration path from Cocos2d-x, while Godot gives you an editor and a download. Which one is right depends on whether your existing code is an asset or a liability.

Maintenance, releases and licence cost

The last push to the repository was on 2026-07-06, which is the same timestamp as the v2.11.4 release. The release cadence visible in the releases is roughly every one to two months: v2.11.2 on 2026-01-15, v2.11.3 on 2026-02-23, v2.11.4 on 2026-07-06. That is a maintained project, and the README reinforces it with the branch policy, since release/2.x is explicitly kept open for critical bug fixes and security patches.

The upgrade cost is where the branch model bites. The README states that 2.11.x is the final v2 LTS release, so the v2 line is a destination rather than a staging area: you get fixes, not features. Moving forward means moving to v3 on the dev branch, and the README warns that branch may contain unstable or experimental features. Plan for that migration as a real project, not a version bump, because the renderer backends and arm64 support differ between the two lines.

On licensing, the engine itself is MIT, which permits commercial use and modification. The README does not stop there: it maintains an upstream version licence overview at 3rdparty/README.md and an extensions licence overview at extensions/README.md, described as existing "for easier publishing of your commercial apps based on Axmol framework." That is a useful piece of engineering hygiene, because FairyGUI, Spine, Live2D, Effekseer and the rest are not covered by the MIT licence of the engine core. Read both files before you ship; this is a description of what the repository provides, not legal advice, and the terms of each third-party component are set by its own authors.

Editorial conclusion

Axmol fits teams with existing C++ or Cocos2d-x code who need Xbox UWP or WebAssembly targets and are willing to build the engine from source. It is the wrong choice if you want a visual editor, a scripting-first workflow, or a stable v3 API today, since the dev branch is described as possibly unstable and v2.11.x is the final v2 LTS line. Before committing, read docs/DevSetup.md, check the Axmol versus Cocos2d-x wiki page against your own codebase, and confirm which branch your target platforms are actually supported on, because the arm64 Linux and Windows builds and the Vulkan, D3D12 and D3D11 backends are v3 features.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes