Spokes.wiki Search Graph Growth About

game-engines-wiki

log

Synthesis

The evolving thesis. Current best understanding of this wiki’s topic, updated on every ingest.

Current thesis

This wiki covers the game-engine field across 2D and 3D — the major real-time creation platforms (including Godot) plus 2D / framework-based engines (Flame), and how they differ along a few axes the sources stake out. (Scope broadened from “general-purpose 3D” to all engines on 2026-06-07; general-purpose 3D remains the deepest-sourced corner.) The axes:

  • Licensing / business model. A four-position spectrum. Permissive open-source (no royalties, minimal restrictions): o3de (Apache/MIT + Linux Foundation), godot-engine (MIT, community-run), Flame (MIT), torque2d (MIT). Copyleft open-source (GPL — derivatives must stay open): Spring and openage (both GPL) — a distinct, stronger open position added 2026-06-15. Source-available, royalty-based: unreal-engine (5% over $1M). Proprietary, subscription/seat-based: unity-engine. Permissive vs copyleft vs royalty vs subscription is the central tradeoff a studio navigates when picking an engine.

  • Engine architecture — standalone vs framework-based. A new axis opened by Flame: most engines here are standalone (their own editor + runtime — Godot, Unreal, Unity, O3DE), whereas Flame is framework-based, layering a 2D game loop / component system on top of the Flutter UI toolkit and borrowing its cross-platform reach. Trade-off: less to ship/learn and instant Flutter-ecosystem access, but no bespoke editor and bounded by the host framework (2D-only).

  • Overhead & iteration loop. The clearest hard data so far is unity-vs-godot-comparison: building the same game in both, Godot and Unity were comparable on raw performance, but Godot was dramatically leaner in the dev loop (~164 MB vs Unity Hub’s ~21 GB; ~0.31 s vs ~15.4 s script compiles). Openness tends to travel with low overhead and fast iteration; maturity/completeness travels with the heavier commercial engines.

  • Ecosystem / time-to-game. Godot’s sources point at a recurring theme: reducing time-to-game by reusing community assets — Maaack’s godot-game-template (menus, pause, options, scene loading), the godot-best-plugins-2025 Asset Library roundup, and the active XR community shipping 23 games in a week (godot-xr-game-jam-v). This community-scaffolding layer is itself a competitive dimension between engines — and Godot is now first-partying it: Godot 4.7 (RC, 2026-06) ships an official Godot Asset Store, moving ecosystem scaffolding from third-party roundups to an official channel. Knowledge is part of this scaffolding too: Godot’s official tutorials manual (stable 4.6) spans 20+ topic areas — documentation breadth / onboarding is a competitive axis alongside assets, lowering the learning barrier the way leanness lowers the install/compile one.

  • AI tooling as the new front. The unity-engine source is specifically Unity’s AI offering — the clearest signal that the current competitive battleground is AI-assisted content/code generation inside the editor, not just raw rendering. Unreal now answers in kind: unreal-engine-5-8 (June 2026) ships an experimental Unreal MCP Server Plugin exposing engine data to LLMs — and notably it’s a concrete MCP integration, the same open standard the agentic-tooling spoke tracks, now reaching inside a game engine (a live cross-spoke seam). So the AI front is no longer one vendor’s pitch; two of the three big 3D engines now ship editor-resident AI, and at least one bets on the cross-vendor protocol rather than a closed plugin. Same release also nudges the fidelity-range map: Lumen Lite (+ Switch 2) pushes Unreal’s lighting down toward low-end hardware, softening the clean “Unreal = AAA ceiling” pole — and flags the roadmap horizon (5.8 likely the last UE5; UE6 ~late 2027).

  • Programming-required vs no-code — a new axis (2026-06-10). gdevelop (MIT, open-source) adds a third architecture dimension beyond open-vs-proprietary and standalone-vs-framework: how much code the engine demands. Its visual event system (conditions + actions in natural language, pre-built behaviors) targets non-programmers, the opposite pole from the code-first frameworks bevy/phaser/love2d and the scripting of godot-engine/unity-engine. Notably it localizes the AI-tooling front as a way to lower the authoring barrier (NL→logic), not just speed a pro workflow — and skews to education (10k+ students by 2025). The engine map now spans a ceiling-to-floor range: unreal-engine (AAA fidelity) → unity-engine/godot-engine (general scripting) → bevy/phaser/love2d (code-first frameworks) → gdevelop (no-code/visual).

  • General-purpose vs genre-specialized — a new axis (2026-06-15). Every engine here had been general-purpose (3D: godot-engine/unreal-engine/unity-engine/o3de) or a general 2D framework (flame-engine/phaser/love2d/torque2d). Two RTS-specialized engines arriving together — Spring and openage — open a category built for one genre, trading breadth for deep genre fit (massive unit counts, deterministic multiplayer sim). They show two flavors: Spring is a generic RTS platform (any RTS, defined in Lua), openage a faithful clone of a specific game’s engine (the Genie engine of AoE II, BYO original assets). This also adds an origin-story dimension — ground-up engines vs formerly-commercial → open-sourced (torque2d ex-GarageGames, o3de ex-Lumberyard) vs clean-room reimplementation of a proprietary engine (openage). And on the 2D side, torque2d is the first standalone 2D engine here (its own editor + runtime + TorqueScript), vs the framework-based 2D cohort.

  • Real-time collaboration + liveness — new axes (2026-06-15). Superpowers (ISC, HTML5/TypeScript, Three.js) made simultaneous multi-user editing the core design — “Google Docs for game dev,” self-hostable — a dimension no other engine here centers (the rest rely on external VCS). It’s also the spoke’s first archived/defunct engine (unmaintained since 2021), introducing liveness (actively-maintained vs dead-but-instructive) as a tracked attribute — its collaboration idea outlived its codebase.

Two through-lines worth watching: engines are increasingly pitched as “real-time 3D creation” beyond games (Unreal’s tagline) — film/VFX virtual production, arch-viz, simulation; and the open-source engines are gaining serious commercial credibility — mega-crit moved Slay the Spire 2 from Unity to Godot, not just hobbyists.

Open questions

  • How does O3DE’s feature maturity (still stabilising — 26.05 is patch-heavy, deprecating PhysX4) compare to UE5 / Unity / Godot in production?

  • Is AI tooling a genuine differentiator or table-stakes all engines will match?

  • Documentation quality as a differentiator — Godot’s official manual shows broad first-party coverage (20+ topics), but a cross-engine docs-quality comparison (Godot vs Unity vs Unreal vs the lean frameworks) is unsourced — breadth is documented, relative quality is not.

  • Godot vs Unreal — still unaddressed partly addressed (2026-06-10): unreal-engine is now a real page (refreshed from stub) with licensing + market data — 5% royalty over $1M; 2024 share Unity ~50% / Unreal ~28% by units but Unreal 31% / Unity 26% by revenue, i.e. Unreal skews to fewer, higher-grossing AAA titles vs Godot’s leanness/Unity’s volume. A rigorous head-to-head Godot-vs-Unreal project benchmark still doesn’t exist — gap narrowed, not closed.

  • Are Godot’s godot-game-template and the top plugins maintained / production-grade, or hobby-tier? Is the Mega Crit / Slay the Spire 2-on-Godot claim still current?

  • 2D / framework-based engines — Flame is the only one so far now a five-wide cohort (2026-06-15): Flame (Dart/Flutter), Phaser (JS/HTML5), LÖVE (Lua/native), Bevy (Rust/ECS, also 3D), and libGDX (Java, also 3D, Apache-2.0). They share the framework bet — code-against-an-API, no bespoke editor, minimal footprint + fast iteration — and now vary cleanly on language × host runtime × target platform (Dart/JS/Lua/Rust/Java), giving the cross-engine comparison the spoke lacked.

    Web graphics resolve into a library/engine matrix (2026-06-15). A run of browser-native sources — Babylon.js, PlayCanvas, PixiJS — splits the “framework” bucket by dimension × level: 2D library PixiJS / 3D library Three.js (renderers only, no physics/audio/editor) → 3D framework/engine Babylon.js → 3D full engine + collaborative editor PlayCanvas (physics, animation, audio, cloud editor). The libraries are substrates: GDevelop embeds PixiJS (2D) + Three.js (3D), and Superpowers embeds Three.js. So “is it a game engine?” gets a precise answer in the browser — PixiJS/Three.js are rendering substrates, the others are engines built atop them. Beneath the whole matrix sits a shared backend layer: all four render on WebGPU (the WebGL successor) as well as WebGL, so the engines also compete on how well they exploit it — and WebGPU’s compute shaders open a cross-spoke seam to llm-inference (in-browser GPU/AI compute). PlayCanvas also extends the collaboration axis (a maintained, production 3D cloud editor, vs the archived superpowers); Phaser remains the 2D-web framework above this layer. Bevy also adds two new axes: ECS / data-oriented architecture (vs the scene-tree/object model of godot-engine/unity-engine) and a Rust open-source contender on the same leanness/iteration axis the unity-vs-godot-comparison prized. Still open: a rigorous cross-engine 2D benchmark (these are official/encyclopedic descriptions, not head-to-head tests) — and Godot vs Unreal.

Flagged contradictions / tensions

  • Slay the Spire’s original engine (open, 2026-06-15). The mega-crit page frames Slay the Spire 2 as a Unity → Godot migration, but the original Slay the Spire is widely reported to have been built on libGDX (Java). If so, the migration arc was libGDX → Godot (or StS used more than one stack), not Unity → Godot. Neither claim is first-party-sourced here (the libGDX repo lists Pathway, not StS), so both are recorded pending a Mega Crit primary source — flagged, not resolved.
  • Marketing-vs-reality, otherwise. The engine product pages are first-party/announcement framing; the one analytical source (the Godot/Unity comparison) is a single practitioner test — expect marketing-vs-reality and single-vs-multi-project gaps as more analytical sources arrive.

Cross-spoke adjacency

  • ../webperf-wiki — Godot’s “164 MB / 0.31 s vs 21 GB / 15.4 s” leanness rhymes with webperf’s page-weight / byte-budget thesis (heavy toolchains vs lean ones); the same lens, applied to engines instead of front-ends.

Index

Catalog of every wiki page, grouped by schema.org @type. Read this first when answering a query, then drill into the relevant pages. Updated on every ingest.

SoftwareApplication

  • o3de — Open 3D Engine; open-source (Linux Foundation), ex-Amazon Lumberyard · url
  • unreal-engine — Epic Games’ RT3D engine; UE5 (Nanite/Lumen), now 5.8, royalty-based (5% >$1M) · url
  • unity-engine — Unity’s engine + Unity AI tooling; C#, subscription; the Godot comparison point · url + source
  • godot-engine — free/open-source engine; lean dev loop, active XR & plugin community
  • flame-engine — Flame; 2D engine built on Flutter/Dart, MIT (Blue Fire); first 2D / framework-based engine here · url + source
  • bevy — Rust data-driven engine; ECS, 2D+3D, code-first; MIT/Apache-2.0 · url + source
  • phaser — 2D HTML5 framework (JS/TS), MIT; browser-native, framework-based · url + source
  • love2d — LÖVE; 2D framework scripted in Lua (zlib); indie/jam favourite (Balatro) · url + source
  • gdevelop — free/open-source (MIT) no-code/visual engine; event system, 2D(+3D), HTML5/mobile/desktop; the no-code axis · url + source
  • torque2d — MIT 2D engine, GarageGames lineage (TorqueGameEngines); standalone (own editor + TorqueScript), Box2D/OpenGL; 4.0 EA · url
  • spring-rts — GPL RTS-specialized engine (formerly TASpring); C++/Lua, large-scale battles (Beyond All Reason, Zero-K); first genre-specific + first copyleft engine · url
  • openage — GPLv3 open reimplementation of AoE II’s Genie engine (SFTtech); C++20/Python; RTS, in-dev, BYO original assets; the clean-room-reimplementation pattern · url
  • libgdx — Apache-2.0 cross-platform Java game framework (2D+3D); framework-based, OpenGL ES, desktop/Android/iOS/web; 25.2k★ · url
  • superpowers — ISC HTML5 engine+IDE (Sparklin Labs); real-time collaborative game dev (TS/Three.js, 2D+3D, self-hostable); archived 2021 (first defunct engine here) · url
  • babylonjs — Apache-2.0 web-native 3D game/rendering engine (TS, WebGL/WebGPU); full engine (PBR/WebXR/physics/node-material editor) vs a minimal library; ~25.6k★ · url
  • playcanvas — MIT web-native 3D full engine (JS/TS, WebGL2/WebGPU/WebXR/glTF + Gaussian splatting); physics/anim/audio + collaborative cloud editor; Disney/Samsung/King; ~16k★ · url
  • pixijs — MIT fast 2D WebGL/WebGPU rendering library (TS); the 2D counterpart to Three.js; a renderer (no engine bits), embedded by GDevelop; ~47.4k★ · url
  • three-js — MIT 3D WebGL/WebGPU rendering library (mrdoob); the matrix’s 3D-library node — a renderer (no engine bits), embedded by GDevelop/Superpowers, base of Babylon/PlayCanvas-style stacks; ~113k★ · url

DefinedTerm (concepts)

  • webgpu — modern low-level browser graphics+compute API (WebGL successor, WGSL); the rendering-backend node under the web-graphics matrix; compute-shader seam to in-browser AI · standard

Organization

Article (sources)

NewsArticle (sources)

  • godot-gabe-android — first-party: GABE stable; build/export/publish games entirely on Android+XR (Godot 4.6) · url
  • unreal-engine-5-8 — UE 5.8 release (likely final 5.x): MegaLights, Lumen Lite (low-end/Switch 2), Mesh Terrain, Unreal MCP plugin (LLM↔engine); UE6 ~late 2027 · url · T3 · gamefromscratch.com
  • godot-4-7-rc1 — first-party: Godot 4.7 RC1; HDR output, drawable textures, first-party Godot Asset Store · url
  • godot-4-7-rc2 — first-party: Godot 4.7 RC2 (regression-only, 10 fixes); stable imminent; tight RC cadence · url
  • godot-4-7-rc3 — first-party: Godot 4.7 RC3 (17 fixes / 12 contributors); 4 regressions still open (Jolt, Adreno, XR) · url

TechArticle (sources)

  • godot-docs-tutorials — first-party: official Godot tutorials/manual hub (stable 4.6); 20+ topic areas; documentation-as-onboarding axis · url

SoftwareSourceCode (sources)

  • godot-game-template — Maaack’s starter template (menus, scene loader, example scene) · source

BlogPosting (sources)

Synthesis

  • synthesis — the evolving thesis (open questions + flagged contradictions)