Axmol Engine: C++-Spieleentwicklung von Mobile bis Xbox (UWP)
Axmol Engine, eine plattformübergreifende Engine für Desktop-, XBOX (UWP), WebAssembly- und Mobilspiele. (ein Fork von Cocos2d-x-4.0).
Auf einen Blick
- Was ist das?
- Ein seit November 2019 gepflegter Fork von Cocos2d-x v4.0 für 2D-Spiele auf iOS, Android, Windows, Linux, macOS, Xbox (UWP) und WebAssembly, mit Vulkan, D3D12 und Metal als Renderer-RHI.
- Für wen ist es gedacht?
- Axmol Engine passt für Teams mit C++-Erfahrung, die 2D-Spiele auf viele Plattformen bringen wollen, inklusive Xbox über UWP und WebAssembly als Vorschau. Wer eine 3D-first Pipeline oder einen visuellen Editor erwartet, sucht vergebens.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Axmol als Fork von Cocos2d-x v4.0 seit November 2019
Axmol Engine startete im November 2019 als Abspaltung von Cocos2d-x v4.0 und positioniert sich als quelloffene C++-Multiplattform-Engine mit Fokus auf 2D-Spielentwicklung. Die README beschreibt, dass das Projekt auf dieser Basis iteriert hat und nun schneller und fähiger sei, bei geringem Gewicht; einen direkten Vergleich liefert die Wiki-Seite Axmol-vs-Cocos2d-x. Wer von einem bestehenden Cocos2d-x-Projekt kommt, findet einen eigenen Migrationsleitfaden im Wiki.
Die Zielplattformen reichen über Mobile (iOS, Android) und Desktop (Windows, Linux, macOS, tvOS) bis zur Konsole: Xbox wird über die Universal Windows Platform angesprochen, was für Indie-Studios der praktischste Weg zu Microsofts Konsolenökosystem ist. Dazu kommt WebAssembly als Vorschau, online testbar über die cpp-tests und fairygui-tests auf axmol.netlify.app. Als Sprachen stehen C++ und Lua bereit. Die Community zählt rund 1443 Stars und 298 Forks, das Projekt ist unter axmol.dev und der MIT-Lizenz zu finden.
Branch-Regeln: dev für axmol-v3, release/2.x für die Produktion
Das Repository trennt seine Linien explizit. Der Zweig dev dient als v3-Entwicklungslinie, gilt als aktiv und kann instabile oder experimentelle Features enthalten; Pull Requests für neue Funktionen und nicht-kritische Fixes gehören primär hierher. Der Zweig release/2.x befindet sich in der stabilen Wartungsphase, wobei 2.11.x als letzte v2-LTS-Release-Linie bezeichnet wird. Kritische Bugfixes und Sicherheitspatches laufen dorthin, sonst nichts.
Bemerkenswert ist die Härte der Regeln: Pull Requests an release/2.x, die vollständige clang-format-Läufe oder großflächige Reformatting-Änderungen enthalten, werden laut README grundsätzlich nicht akzeptiert, weil sie Merge-Konflikte erhöhen und das Code Review belasten. Auch nicht-kritische Feature-PRs an diesen Zweig werden abgelehnt. Wer beitragen will, muss also vorher klären, welche Linie betroffen ist. Die letzten Releases zeigen, wo die LTS-Wartung steht: v2.11.2 am 15. Januar 2026, v2.11.3 am 23. Februar, v2.11.4 am 6. Juli 2026.
Render-RHI von Vulkan bis WebGL 2.0 und Arm64 seit v3
Die Renderer-Abstraktion ist das technische Herzstück der Plattformliste. Mit axmol-v3 kommen Vulkan für Windows, Linux und Android, dazu D3D12 und D3D11 für Windows und UWP. Metal deckt macOS, iOS und tvOS ab, OpenGL 3.3+ dient auf Linux, macOS und Windows, OpenGL ES 2.0+ auf Android, OpenGL ES 3.0+ auf iOS und tvOS. Unter Windows und UWP ist Google ANGLE als Standard-Renderer-Backend eingebunden, für WebAssembly liefert WebGL 2.0 (OpenGL ES 3.0) die Basis.
Die Architekturmatrix umfasst x64 und arm64 für iOS, tvOS, Windows, Linux, macOS und UWP, dazu x86 und armv7 für Android sowie wasm32, mit v3 auch wasm64. Die README merkt an, dass arm64-Builds für Linux und Windows erst seit Axmol v3 verfügbar sind. Für Teams heißt das konkret: Ein älteres v2-Projekt kann auf einem Arm64-Windows-Gerät nicht nativ bauen, der Wechsel auf v3 bringt diese Fähigkeit, kostet aber den Wechsel von der LTS-Linie auf die dev-Linie mit allen Instabilitätsrisiken.
Box2D und JoltPhysics als Physik-Optionen
Bei der Physik trennt die Engine nach Dimensionen: Für 2D wird Box2D unterstützt, für 3D JoltPhysics. Eine Wiki-Seite mit dem Titel 2D-Physics-Engines-Information vertieft die Details. Diese Kombination passt zur Selbstbeschreibung als 2D-fokussierte Engine mit 3D-Fähigkeiten; wer ein reines 2D-Spiel baut, arbeitet mit Box2D, während JoltPhysics für Projekte mit 3D-Komponenten bereitsteht.
Dazu kommen gebündelte Erweiterungen, die sonst als Einzellizenzen und Integrationsaufgabe anfallen würden: FairyGUI für Benutzeroberflächen, ImGUI für Debug-Overlays, Spine für Skelettanimationen, Live2D und Effekseer für Effekte. Eine eigene Wiki-Seite listet weitere Community-Erweiterungen, eine zweite namens Made in Axmol zeigt fertige Projekte. Die Modularisierung ist eine dokumentierte Designentscheidung: Optionale Erweiterungen wurden aus dem Engine-Kern in einen extensions-Ordner verschoben, was die Abhängigkeitsfläche eines minimalen Projekts verkleinert.
yasio-HttpClient, MediaPlayer und -DAX_USE_ALSOFT in der Praxis
Unter den Features stecken einige, die den Alltagsbetrieb betreffen. Der HttpClient wurde auf Basis von yasio neu implementiert und verarbeitet gleichzeitige HTTP-Requests, was im Spielbetrieb etwa bei Asset-Downloads trägt. Der neue MediaPlayer rendert Video als Textur über eine MediaEngine, unter Windows stützt er sich auf Microsoft Media Foundation. Die AudioEngine wurde refactoriert und nutzt OpenAL: Auf Apple-Plattformen wählt das CMake-Skript standardmäßig OpenAL.framework, auf allen anderen Systemen OpenAL Soft, erzwingbar mit dem Flag -DAX_USE_ALSOFT=ON. Alle .wav-Formate von OpenAL Soft, darunter MS-ADPCM, werden unterstützt.
Weitere Punkte der Liste: HiDPI-Unterstützung für Windows, Linux und WebAssembly seit v3, Apple M1- und Android-x64-Support, Windows-x64-Builds sowie ein verbesserter Windows-Workflow, der gegen vorgebaute Engine-Bibliotheken linkt und im Issue 564 beschrieben wird. Für XML nutzt die Engine pugixml, für URL-Transfers curl, für .plist-Dateien einen SAX-Parser, und ASTC-Texturen in 4x4, 6x6 und 8x8 werden dekodiert, notfalls per Software.
MIT-Lizenz und die Lizenzübersichten in 3rdparty und extensions
Die Engine steht unter der MIT-Lizenz, mit Urheberrechtsangaben von 2008 bis heute, darunter die Cocos2d-x-Autoren und die Axmol-Mitwirkenden. Die Lizenz erlaubt Nutzung, Modifikation, Verbreitung und Verkauf unter der Bedingung, dass Urheberrechts- und Genehmigungshinweise erhalten bleiben, und liefert die Software ohne Gewährleistung. Für kommerzielle Spiele ist dieser Rahmen unkompliziert.
Relevant für die Veröffentlichung sind zwei gesonderte Übersichten, die die README verlinkt: eine Third-party-Lizenzübersicht im Verzeichnis 3rdparty und eine Erweiterungsübersicht im Ordner extensions. Beide liegen außerhalb der Root-README und bündeln die Hinweise auf Drittanbieter-Bibliotheken, damit kommerzielle Apps auf Axmol-Basis leichter publiziert werden können. Wer ein Spiel ausliefert, muss also neben dem MIT-Hinweis der Engine selbst die tatsächliche Kombination genutzter Erweiterungen wie Spine oder Live2D gegen diese Übersichten prüfen, da einzelne eingebundene Bibliotheken eigene Bedingungen tragen können.
Setup über docs/DevSetup.md und die Grenzen ohne visuellen Editor
Für den Einstieg verweist die README auf den Setup-und-Building-Guide unter docs/DevSetup.md, Lernmaterial liegt im Manual unter axmol.dev/manual/latest, im Wiki mit Tutorial-Seite und FAQ. Community-Kanäle sind GitHub Discussions, Discord und Reddit, Spenden laufen über axmol.dev/donate. Mitwirkende werden gebeten, ihre verwandten Repositories mit den Themen axmol und axmolengine zu taggen.
Die ehrlichen Grenzen: Axmol bringt keinen visuellen Editor wie Unity oder Godot mit, die Arbeit geschieht in C++ oder Lua mit Build-Werkzeugen, und WebAssembly bleibt als Vorschau markiert. Die Alternative für ein 2D-Spiel wäre Godot mit eigenem Editor und GDScript; der Unterschied liegt in der Kontrolle und der Binärgröße, die Axmol mit seinem C++-Kern zugunsten eingebetteter Szenarien spart, während Godot Werkzeugkomfort liefert. Wer C++-Kontrolle, Xbox-UWP-Ziel und viele Plattformen von einem Code-Pfad aus will, sollte docs/DevSetup.md durcharbeiten und einen Testbuild der cpp-tests für das eigene Zielsystem anstoßen, bevor das Projekt darauf gesetzt wird.
Redaktionelles Fazit
Axmol Engine passt für Teams mit C++-Erfahrung, die 2D-Spiele auf viele Plattformen bringen wollen, inklusive Xbox über UWP und WebAssembly als Vorschau. Wer eine 3D-first Pipeline oder einen visuellen Editor erwartet, sucht vergebens. Vor dem Commit sollte man das eigene Zielplattform-Set gegen die Render-Backend-Liste prüfen und für die Produktion den release/2.x-Zweig mit v2.11.4 einsetzen.
Community-Notizen