Spokes.wiki Search 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), Carbon (MIT — a AAA in-house MMO engine, CCP/Fenris, joining the permissive pole 2026-07). 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. Tier gates reach, not just price (added 2026-07-29). unity-polyspatial is restricted to Unity Pro, Enterprise and Industry — a Personal-tier user cannot ship to Apple’s visionOS through the official package at all. So the subscription pole has a second dimension the open and royalty poles don’t: which platforms your tier is allowed to reach. Neither MIT nor a 5%-over-$1M royalty can withhold a target.

  • 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). A third position: the engine that doesn’t render (added 2026-07-29). unity-polyspatial puts Unity on Apple’s visionOS by simulating the scene in Unity and letting RealityKit draw it — the platform composites many apps into one shared space with the real room, so no app is handed the frame. Framework-based engines like Flame give up the editor and keep the loop; this gives up the renderer and keeps everything else. The cost shows up as a feature gap Unity ships a validation tool to manage, and 2.0.x has been walking it back with a Metal path that takes the pipeline home for immersive apps. The general shape, if other spatial platforms follow Apple: where the OS owns compositing, the engine stops being the last thing before the screen.

  • 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. The knowledge layer has a community pillar beside the first-party one: project-based tutorial series like The GameDev Tavern’s 20-hour Goblins’ Den build one full 3D game end-to-end (MIT code on GitHub), teaching the integration work — asset pipeline, state machines wiring into physics/pathfinding — that topic-by-topic docs skip. Free labour from the community deepens an engine’s onboarding moat the way third-party assets deepen its ecosystem 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). unreal-engine-6 now makes that horizon concrete and ups the AI bet: native Claude/Gemini models baked into the engine, a step past the experimental MCP plugin from a cross-vendor protocol toward bundled models. Unity answers not with a bundled model but with an execution surface (2026-07-21). The Unity CLI + experimental com.unity.pipeline package reframe the AI front from “which model is inside the editor” to “how does an agent actually operate the engine.” Its three layers — a CLI that manages Unity, a Pipeline package that drives a running Editor (or Player) via [CliCommand]-attributed methods, and eval that runs live C# inside a running instance with no recompile — give an agent the loop editor-resident AI needs but usually lacks: observe → act → verify (the post’s demo agent fixes a “player falls through the floor” bug by inspecting the live scene, re-enabling a collider, and re-entering Play mode itself). The design choices are explicitly agent-shaped: structured JSON + a predictable exit-code contract (parseable, not scraped console text) and a self-describing Editor (unity command lists callable operations at runtime), which Unity maps directly onto function-calling / MCP tools. This makes the AI-front convergence sharper: both big commercial engines now bet on the same open protocol (Unreal’s MCP server and Unity routing its own AI “through its MCP server”), a live seam to ../agentic-tooling-wiki’s MCP thread. And it recasts editor AI as a layer cake — Unity’s assistant reasons/decides, the CLI is the token-gated execution surface that carries decisions out, open to any agent, not just Unity’s. The through-line from the “verify, don’t just suggest” framing rhymes with the agentic-coding-harness self-verification loop the sibling spoke tracks — now reaching inside a game engine’s runtime. All three engines now have one, and the pattern is nameable (2026-07-27, godot-mcp-toolkit). Godot’s arrives as a community MIT Asset Library plugin — 112 MCP tools over scenes, nodes, scripts, ClassDB and playtests — not as an engine feature, which is exactly what its vision prescribes (lean core, plugins for everything else) and exactly what the Foundation’s AI stance would predict. So the AI-integration strategy mirrors the governance model in all three cases: Unreal bundles (models in the engine), Unity productizes an execution surface, Godot leaves it to whoever shows up. The convergence underneath is sharper still — collected as engine-agent-surface, the three independently land on the same four properties: runtime self-description, extension in the project’s own language ([CliCommand] ≈ GDScript MCP tools), the agent’s context budget as a design constraint (Godot’s on-demand discover_tools against a 112-tool surface), and token-gated localhost-only access because write access to a live editor is the dangerous part. Two unaffiliated projects reaching identical security posture is the strongest signal here that this is a real pattern rather than one vendor’s framing.

  • 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. Carbon adds a sub-variant of “formerly-commercial → open-sourced” (2026-07): opened while the game it powers is still live and paying — EVE Online is ~20 years old and still subscription-funded — so the motive is stewardship/longevity (carbon-engine-open-source: Pétursson’s Linux-style “open code is more robust over time” argument, “let EVE live forever”), not the post-abandonment salvage of torque2d/o3de. “Open-source as succession planning for a live service.” Carbon is also the spoke’s first MMO-scale genre engine — server-authoritative networking (CarbonIO)

    • massive deterministic battle sim (Destiny drove an 8,825-player battle) — a deep-genre engine like the RTS pair (spring-rts/openage), not a general-purpose one; the persistent-universe MMO is a corner no other engine here occupies.

  • 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.

  • Engine as ecosystem gateway — a new axis (2026-06-18). unreal-engine-6 reframes what an engine is for. The UE5+UEFN merge (marcus-wassmer, Epic EVP) ties the pro/AAA pipeline and the Fortnite-creator pipeline into one engine whose explicit goal is portable content, code, and economies (via glTF/USD + Epic open specs) — so a UE6 game is also a doorway into Fortnite’s economy. That is a different competitive logic from the per-release tech race (Nanite/Lumen, leanness, no-code): the engine as a distribution-and-economy platform, monetized through the ecosystem rather than (or alongside) royalties. It also opens a language-consolidation sub-axis: UE6 makes Verse primary and deprecates Blueprints + sidelines C++, the boldest engine-language bet here — replacing the default rather than adding one — against the stable C#/GDScript/Lua/Dart choices of the other engines. Caveat: announced plan on a 2027 horizon, deprecations likely to draw developer pushback.

  • Two next-gen playbooks: continuity vs. reinvention (2026-07-21). The two commercial incumbents now have their next major versions on the table within months of each other, and they bet opposite ways. Unity 7 (beta Dec 2026, release early 2027) sells continuity: same Unity 6 architecture, zero rebuilding, projects/code/skills carry forward, opt-in AI a studio can decline, and no pricing change. UE6 (EA ~late 2027) sells reinvention: merge UE5+UEFN, make Verse primary while deprecating Blueprints, bake in native Claude/Gemini. So on the same timeline, one incumbent minimizes migration cost and the other maximizes ambition (and disruption). Unity’s messaging is legible as a reaction to its own past: after the 2023 Runtime Fee burned trust, “won’t break your build” and “AI is your choice” are goodwill-repair moves — the mirror image of Epic’s confident language-and-platform overhaul. The other genuinely new Unity 7 piece — an open CLI + public API letting non-Editor tools validate assets and push builds — rhymes with the “engine as ecosystem gateway” axis from a subscription angle: opening the toolchain surface (headless collaboration) rather than the content economy.

  • Stated philosophy as a competitive axis — vision-as-governance (2026-06-26). Until now the wiki inferred each engine’s values from its behavior; Godot’s Vision Statement (first-party, T1) is the first source where an engine states them outright, and the act of writing them down is itself the point: the Foundation formalized a decade-old oral vision because the contributor pool outgrew learning it by working alongside the founders — a governance artifact for legibility at scale, used to steer funding/contractor allocation, not a roadmap. Its content grounds threads the wiki had only measured: the leanness is a principle (“a smaller, solid engine is better than a large, brittle one”), the low-end reach is a commitment (“runs on hardware people own”), and the ecosystem/plugin layer is the deliberate flip side of a “focused and pragmatic” core (“for everything else, plugins … are the answer”). It also sharpens the licensing pole from observed-MIT to a promise (“free and open source … no paid tiers, no premium versions”) and names a beachhead (small-to-medium teams shipping professional games). Most useful for the field map: it reads as the near-inverse of unreal-engine-6‘s “engine as ecosystem gateway” — where UE6 maximizes (one engine as a content-economy platform, consolidating on Verse), Godot’s vision is a self-imposed scope limit (focused, free-forever, runs on owned hardware, not a platform play). So the two open-vs-commercial poles now differ not just on license and overhead but on stated ambition — maximalist platform vs. focused tool. (First-party/aspirational framing; it states intent, and the unity-vs-godot-comparison is the one independent check that the leanness claim holds in practice.) The vision-as-governance axis gains a second, enforceable instance (2026-07-04): the 2026 contribution policy is the same Foundation writing down not its values but its rules for getting code in — the identical “formalize the tacit now that we’re too big to learn it by osmosis” move, one level more operational (and enforced: autonomous agents / “vibe coding” are auto-banned from the GitHub org). Two things make it more than a housekeeping note. First, it is the wiki’s first explicit engine stance on AI-generated contributions — Godot bans substantial AI-authored code, requires human authorship + disclosure, and confines AI to menial help (completion/regex/find-replace). That makes the “AI tooling reshaping engine development” thread two-directional: the wiki had tracked AI being adopted inside the editor (Unity AI, Unreal’s MCP server, native Claude/Gemini, Godot’s own GABE) — this is the same force being resisted at the community/contribution layer, and the two can coexist in one engine (Godot ships editor AI and bans AI-authored PRs). Second, the stated rationale is human development, not throughput: machines can’t learn from review feedback, so low-effort AI PRs drain the mentorship pipeline that grows future maintainers — a FOSS-governance argument the commercial engines’ AI-productivity framing doesn’t have. It is a live counter-current to ../agentic-tooling-wiki’s autonomous-coding thread (a major project drawing a hard line against agent-authored PRs) and an organizational AI-use policy rhyming with ../ai-governance-wiki — a community-project analog of enterprise AI governance, though a contribution policy rather than law/standard.

  • The middleware layer beneath the engines — a new axis (2026-07-03). Every page so far has been a full engine (or a rendering substrate like three-js/pixijs). Box3D (Erin Catto, MIT) is the first physics engine here — a component an engine embeds rather than a thing you ship a game with. It sharpens a distinction the wiki had left implicit: engines are assembled from swappable subsystems, and physics is one of them. The evidence was already scattered across existing pages — Godot ships the Jolt physics backend, Phaser/Torque2D embed Box2D (Box3D’s 2D sibling), and Carbon‘s Destiny component is CCP’s in-house physics+pathfinding layer. Box3D names that layer directly and adds a build-vs-embed sub-axis: a genre engine can license a permissive deterministic physics core (Box3D) or roll its own (Carbon/Destiny). Its two headline properties — cross-platform determinism and MIT licensing — line up with exactly the genres that need them: the massive-battle RTS pair (spring-rts/openage) and MMO-scale sim (Carbon) all depend on deterministic physics for multiplayer and replay. It also extends the origin-story / lineage thread in a new direction — not open-sourced-from-commercial, but a proven 2D engine (Box2D) re-authored in 3D by the same person, design signatures intact.

  • The framework cohort gains C#/.NET, and a new lineage flavor (2026-07-17). MonoGame joins the code-first framework bet (Flame/Phaser/LÖVE/Bevy/ libGDX) as the C#/.NET entry — the sixth language on the language × runtime × platform axis (Dart/JS/Lua/Rust/Java → + C#), and one with unusually broad reach (desktop + mobile + all three major consoles). It sharpens three existing threads. On licensing, it holds the permissive pole on a distinct license (Microsoft Public License) and makes the anti-royalty stance explicit — “no subscription, royalty, licensing, or runtime fees” — the sharp inverse of Unreal‘s 5% and Unity‘s seats. On origin-story / lineage, it adds a flavor the spoke didn’t have: not a formerly-commercial engine whose own source was opened (Carbon/O3DE/Torque2D), nor a clean-room clone of one game’s engine (openage), but a community reimplementation of a discontinued proprietary framework’s API — MonoGame keeps Microsoft’s abandoned XNA alive, stewarded by the MonoGame Foundation (a third foundation steward beside Godot and O3DE’s Linux Foundation). Most useful: it is the strongest evidence yet that a “mere framework” is production-grade, not hobby-tier — Stardew Valley, Celeste, Streets of Rage 4, Barotrauma, and TMNT: Shredder’s Revenge all ship on it — which directly answers the standing “framework engines: maintained / production-grade, or hobby-tier?” question and reinforces the “open, lean tools have real commercial credibility” through-line below.

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. Godot’s “not just for games” tenet is its own first-party framing of that first through-line.

Open questions

  • What does Unity actually lose on visionOS? (added 2026-07-29) unity-polyspatial ships a project-validation tool whose whole job is flagging unsupported features, and neither introduction page enumerates them. The wiki can say the gap exists and not what’s in it, which is the one thing a developer picking an engine for the headset would want. The FAQ and project-validation pages are the fix. Related and also unsourced: how the other engines reach visionOS at all — Godot and Unreal have no page here on it, so there’s no comparison to make yet.

  • 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, + C#/.NET via MonoGame, 2026-07-17), giving the cross-engine comparison the spoke lacked. MonoGame is also the cohort’s production-credibility anchor (Stardew Valley / Celeste / Streets of Rage 4 shipped on it) — the clearest counter to “framework = hobby-tier.”

    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.

  • Representing astronomical scale. space-games-universe-scale (a fetch-blocked stub) raises the frontier none of the engine pages touch yet: how a real-time engine renders and simulates a world spanning light-years when floating-point precision breaks down at large coordinates. The usual answers — floating-origin/coordinate rebasing, aggressive level-of-detail, procedural generation — are the RT3D-technology corner this wiki should eventually cover with a real source. Held open until the article body (or a better source) is recoverable. First concrete step (2026-07-16): procedural-generation is now paged, grounded in oxide-infinite-world-generator — a real Godot asset doing FastNoiseLite + chunk-streamed infinite 2D worlds. That covers the world-building scale of the procedural lever; the astronomical scale (procedural gen + LOD + floating-origin together) is still the open frontier.

  • Did the Bevy Editor ship? Opened by the 2026-08-12 freshness re-verification of bevy. The page had described Bevy as code-first with the “editor still in progress,” and bevy.org no longer mentions an editor at all — so the claim lost its source rather than changing. That parenthetical is gone from the page and the question is live, because it decides which side of this spoke’s library-versus-engine line Bevy sits on. The front page’s own feature list has meanwhile grown to skeletal animation with blend shapes, a flexbox UI framework, scene save/load with hot reloading and audio, which is the engine end of the split the browser stack made precise (pixijs → babylonjs → playcanvas). — needs: the Bevy release notes or migration guides, which are the only first-party place editor status is stated.

  • The Asset Library as a commercial marketplace. oxide-infinite-world-generator is a free MIT asset that funnels to a paid “Pro” edition on Boosty — the freemium/upsell pattern running on top of Godot’s open Asset Store. Alongside the plugin depth in godot-best-plugins-2025, it sharpens the ecosystem / time-to-game axis: a third-party marketplace is how a FOSS engine closes the feature gap with batteries-included commercial engines — and it now carries its own commercial models (free-as-funnel), not only free plugins. Worth watching whether paid Godot assets become a normal revenue path for plugin authors.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

  1. What Unity actually loses on visionOS. unity-polyspatial ships a validator whose whole job is flagging unsupported features, and no page here enumerates them. — needs: Unity’s project-validation and PolySpatial FAQ pages (T1 first-party; a feature list is exactly what first-party docs are good for).
  2. The other engines on visionOS. Godot and Unreal have no headset page here, so there is nothing to compare Unity’s gap against. — needs: T1 first-party XR documentation from either.
  3. Documentation quality as a differentiator. Godot’s breadth is documented; relative quality is not. — needs: a T2 cross-engine documentation comparison.
  4. Is AI tooling a differentiator or table stakes? Asked since spin-out, still unsourced. — needs: a T2 survey across engines rather than one vendor’s feature page.

Coverage edges (added 2026-08-08, at the curator’s request for a wider backlog). These widen what the spoke covers instead of answering an open question above; one ordinary solid source closes any.

  1. Netcode. Multiplayer is the largest architectural commitment an engine forces on a project and no page covers rollback, lockstep, or the engine-supplied networking stacks. — needs: a technical write-up such as the Overwatch or GGPO accounts, plus the engines’ own docs.
  2. The content pipeline into these runtimes. Blender, glTF and USD decide what an engine can ingest; 62 pages treat engines as runtimes with no path in. — needs: format specs plus one studio’s pipeline description.
  3. Distribution economics. Licensing and royalties are covered; storefront cuts and console certification, which take a larger share than any engine fee, are not. — needs: first-party storefront terms (T3, vendor facts) plus a developer’s account of certification.
  4. Audio middleware. FMOD and Wwise sit in nearly every shipped title and appear nowhere. — needs: product documentation plus a developer write-up. Cross-spoke: the DSP side is music-tech-wiki.

Flagged contradictions / tensions

  • Godot bans AI contributors and ships an AI agent surface — not a contradiction, a boundary (2026-07-27). The Foundation auto-bans autonomous agents and “vibe coding” from its GitHub org; three weeks later the official Asset Library lists godot-mcp-toolkit, handing an agent 112 tools to build scenes and run playtests. Both are Godot. The line is contributing to the engine versus using it, and stating it that way makes the policy’s own rationale legible: what’s being protected is the mentorship pipeline that grows maintainers, an argument that never applied to how a user builds a game. Worth watching whether the distinction holds — the plugin’s listing takes care to say it is unaffiliated and unendorsed, which suggests its author expects the question.
  • 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
  • unity-polyspatial — com.unity.polyspatial.visionos: Unity’s Apple visionOS package — apps simulated by Unity, rendered by RealityKit, the one platform where Unity doesn’t own the frame; 2.0.x adds a Metal escape hatch and gates the package behind Pro/Enterprise/Industry. Routed URL is the stale 0.1.2 (Oct 2023, pre-launch); current is 2.0.4 · url · T1 · docs.unity3d.com
  • godot-engine — free/open-source engine; lean dev loop, active XR & plugin community
  • godot-mcp-toolkit — NPGameDev’s MIT Asset Library plugin (v1.0.0, Godot 4.2+): 112 MCP tools letting an AI assistant build scenes, edit scripts, query ClassDB and drive playtests; GDScript extension API, on-demand tool discovery, session-token + localhost-only auth; Godot’s AI surface, arriving as a community plugin rather than an engine feature · url · T3 · godotengine.org/asset-library
  • 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
  • carbon-engine — MIT MMO-scale framework (CCP/Fenris) behind EVE Online/Frontier; components Trinity/Destiny/CarbonIO/CarbonAudio, Python scripting; live-service AAA engine open-sourced 2026-07 · url
  • libgdx — Apache-2.0 cross-platform Java game framework (2D+3D); framework-based, OpenGL ES, desktop/Android/iOS/web; 25.2k★ · url
  • monogame — C#/.NET cross-platform game framework (MS-PL, code-first, no editor); open-source successor to Microsoft’s discontinued XNA; desktop/mobile/PS/Xbox/Switch; ships Stardew Valley/Celeste; v3.8.5 · url · T3 · monogame.net
  • 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
  • box3d — MIT 3D physics engine (Erin Catto, Box2D author); the wiki’s first middleware component (embedded by engines, not a full engine) — C17, SIMD/multithreaded, Soft-Step solver, cross-platform determinism; v0.1.0 (2026-06) · url
  • oxide-infinite-world-generator — free (MIT) Godot 4 2D procedural world generator asset (RedActor): FastNoiseLite + chunk streaming + slider biomes; a Lite→Pro (Boosty) freemium funnel; first single Godot asset paged · source · T3 · godotengine.org/asset-library

DefinedTerm (concepts)

  • engine-agent-surface — how an engine exposes itself to an AI agent; all three big 3D engines now have one, converging on self-description, project-language extension, context-budget management and token-gated localhost access; each engine’s approach mirrors its governance model · pattern
  • 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
  • procedural-generation — generating worlds/terrain/levels from noise + algorithms (FastNoiseLite + chunking) instead of hand-authoring; the content-side lever, at world-building (oxide-infinite-world-generator) and astronomical (space-games-universe-scale) scale · concept

ComputerLanguage

  • verse-language — Epic’s Verse; UEFN’s language, set to become UE6’s primary language (deprecating Blueprints, sidelining C++) · engine language

Organization

  • epic-games — maker of unreal-engine
  • unity-technologies — maker of unity-engine
  • mega-crit — Slay the Spire studio; migrated Unity → Godot for Slay the Spire 2
  • godot-foundation — non-profit stewarding Godot’s source + trademarks; authored the Vision Statement; the FOSS governance counterpart to Epic/Unity
  • ccp-games — Icelandic studio behind EVE Online/Frontier; parent of Fenris Creations; open-sourced Carbon
  • fenris-creations — CCP’s engine studio; develops Carbon and took it fully MIT open-source
  • gamedev-tavern — YouTube creator making long-form project-based Godot tutorial series (MIT code on GitHub); the community-learning pillar
  • monogame-foundation — 501(c)(3) nonprofit owning/developing MonoGame; third foundation steward here (beside Godot / Linux Foundation); sustains the XNA lineage

Person

Article (sources)

  • unity-vs-godot-comparison — same game built in both engines; Godot far leaner · source
  • unity-technologies-wikipedia — Wikipedia: Unity Technologies history; founding, IPO, the 2023 Runtime Fee saga + Riccitiello departure · source · T2 · en.wikipedia.org
  • godot-contribution-policy-2026 — Godot Foundation (30 Jun 2026): restricts AI-generated code (bans autonomous agents / “vibe coding,” requires human authorship + disclosure), gates new contributors; reviewer-burnout + lost-mentorship rationale; first engine AI-contribution stance here · source · T1 · godotengine.org

NewsArticle (sources)

  • carbon-engine-open-source — CCP/Fenris open-source Carbon (MIT) — Pétursson’s “open code is more robust / let EVE live forever” case; open-sourcing a live AAA MMO engine · source · T3 · fenris.com
  • 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
  • unreal-engine-6 — UE6 merges UE5 + UEFN into one engine; Verse-primary (Blueprints deprecated), native Claude/Gemini, glTF/USD portability; EA ~late 2027 · url · T2 · gamedeveloper.com
  • unity-7-roadmap — Unity 7 (beta Dec 2026 / release early 2027): same Unity-6 architecture → zero rebuilding, open CLI + public API, opt-in genAI, no price change; continuity vs UE6’s reinvention · url · T2 · gamedeveloper.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
  • godot-4-7-stable — Godot 4.7 stable (“Director’s Cut”, 2026-06-18): new Asset Store, HDR output, AreaLight3D, GABE stable; closes the RC cycle · source · T2 · godotengine.org + 80.lv
  • space-games-universe-scale — Space.com (Bradley): why space games still fail to convey the universe’s scale; opens the astronomical-scale rendering theme (precision/LOD/procedural gen). Fetch-blocked stub — body unreadable, subject-only · url · T3 · space.com

TechArticle (sources)

  • godot-docs-tutorials — first-party: official Godot tutorials/manual hub (stable 4.6); 20+ topic areas; documentation-as-onboarding axis · url
  • mdn-webgpu — MDN’s WebGPU reference (W3C-spec-tracking): adapter/device model, render+compute pipelines, GPGPU first-class, WGSL, HTTPS-only · url · T1 · developer.mozilla.org
  • unity-cli — first-party: the Unity CLI (unity binary) + experimental com.unity.pipeline; manage/drive/eval a running Editor from the terminal, JSON + exit-code contract, self-describing Editor → agent-drivable engine (MCP-aligned); available now · url · T1 · unity.com

SoftwareSourceCode (sources)

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

BlogPosting (sources)

Course (sources)

  • goblins-den-dungeon-crawler-tutorial — The GameDev Tavern: 20-episode / ~20 hr video series building a full Godot 3D dungeon crawler (“Goblins’ Den”); state machines, ragdoll physics, shaders, pathfinding, full asset pipeline; MIT on GitHub; the community-onboarding pillar · source · T3 · 80.lv

DigitalDocument (sources)

  • godot-vision-statement — Godot Foundation’s first written vision: 12 tenets (free-forever, “smaller solid engine > large brittle one,” focused+plugins, runs on owned hardware, not-just-games); the stated philosophy + near-inverse of UE6’s platform play · url · T1 · godot.foundation

Synthesis

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