Spokes.wiki Search About

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:

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

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. CLOSED 2026-10-06 (quality cycle, research pass) by Unity's own Supported Unity Features & Components page for PolySpatial 2.0.4 (T1), folded into unity-polyspatial. The loss is rendering, not simulation: ShaderLab shaders, post-processing, VFX Graph, Skybox, Fog, LOD and screen-space UI are out; physics, animation, scripts and NavMesh come across. Residue: the minimum Unity version and Xcode/hardware requirements are still unheld, and edge 2 below (the other engines) is now the sharper question, since Unity's side of the comparison exists.
  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. Sharpened 2026-08-28 by vgpu (T1), not closed. The question assumed one axis. vgpu shows the answer depends on how large the exposed surface is: three of engine-agent-surface's four converging properties hold for a library, and the context budget — the one that forces Godot to expand its tool surface on demand — does not bite at all. So "differentiator or table stakes" is under-specified; for a library the surface is cheap enough to be table stakes, and for an engine it is an architectural bet. Still needs the cross-engine survey, and now also an outcome: every source here describes a surface and none reports whether agents using it built anything. vgpu's agent-evals scripts are the first mechanism in the corpus that could produce that number, and its results are not published.

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. CLOSED 2026-08-25 (research pass). Half-closed on 2026-08-22 with the architecture (ggpo T1, game-networking-fiedler T2); the engines' own stacks are now paged from their own documentation — unreal-replication, unity-netcode-gameobjects, godot-multiplayer-api, all T1 — and netcode carries the comparison table. The finding: all three ship client-server with an authoritative side and neither of the other two families, which is what edge 5a predicted from the determinism argument. Unity alone makes the topology a project choice, and says outright that its cheaper distributed-authority option is easier to cheat against. Successor (edge 5b): three architectures and not one number — nobody compares the three under load, and only Unreal documents what it drops when bandwidth runs out (relevancy, net priority, Replication Graph, Iris), while the other two manuals name no equivalent. — needs: a bandwidth or player-count measurement across two of these stacks, or Unity's and Godot's own documentation on replication culling. 5a. Does any general-purpose engine support rollback? New 2026-08-22, from edge 5's residue. GGPO's three requirements are hostile to how mainstream engines are built (floating-point variance across platforms, physics tied to frame timing, state spread across scene objects), and the fighting games that use rollback mostly ship custom or heavily constrained simulations. — needs: a shipped title's account of getting rollback working on Unity, Unreal or Godot, or an engine's own determinism documentation.
  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. HALF CLOSED 2026-09-14 (research pass) by the gltf-specification (Khronos, 2.0.1, T1) and the content-pipeline page it anchors. The spec supplies the distinction the edge lacked — authoring format vs transmission format, glTF as the deliberate end of the pipeline — and the conventions every importer here inherits (+Y up, metres, metallic-roughness). — needs now: the studio pipeline account, and USD's own documentation for the authoring side.
  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.
  5. What the middleware rung costs. New 2026-08-31. The wiki now holds two graphics-abstraction libraries — vgpu on the web, bgfx natively — and neither publishes a frame time, a draw-call figure, or a comparison against the native API written by hand. Portability is the whole pitch and its price is nowhere stated, in either instance. — needs: a benchmark of bgfx against a direct Vulkan or Metal backend, or a shipped title's account of what the abstraction cost them.

The commitment that has to be made first (quality cycle, 2026-08-22)

Sixty-eight pages here compare engines on rendering, tooling, licensing and download size. Netcode was missing, and it is the one axis where the comparison cannot be made after the fact.

ggpo states the price in three sentences: a fully deterministic simulation, a fully serializable game state, and the ability to save, load and step a frame without rendering it. Those are not features. They are properties the whole codebase either has or does not, and the usual suspects that break them — floating-point differences between platforms, an unsynchronised random source, physics that varies with frame timing, gameplay logic reading renderer state — are exactly the things a general-purpose engine leaves loose in exchange for being general-purpose.

game-networking-fiedler supplies the reason the field split rather than converged. RTS games keep lockstep because their state is too large to ship; action games moved to client-server with prediction and accepted an authoritative server so that input could feel immediate. The two families answer different questions about how much state there is and who is allowed to be wrong about it, which means "which netcode does this engine support" is a worse question than "which of these two worlds is the game in."

For this spoke's own arc it lands next to the leanness thesis. Godot's 164 MB against Unreal's 21 GB is a measurable difference a project can discover late; determinism is a difference a project discovers when the first two players report desyncs, and by then the engine choice is years old.

A rung appears under the web-graphics matrix (2026-08-28)

The spoke's web corner has always been four engines over a bare API: Three.js, Babylon.js, PixiJS and PlayCanvas rendering on WebGPU, with nothing paged in between. vgpu (Vercel Labs, MIT, 716★, four months old) is that middle rung: typed WGSL module imports, one explicit Gpu context, and a stated refusal of implicit scene-graph state. So the stack reads WebGPU → thin typed wrapper → engine, and the question the corpus could not previously ask — how much of an engine you actually need — has one instance behind it.

Three things it adds to standing threads.

Testability as an API decision. vgpu ships three runtimes off one surface: browser, headless Node on Dawn, and a deterministic software mock built for CI. Every engine in this spoke is tested by running its editor. A renderer whose test story is an export rather than an infrastructure problem is a different bet about what a graphics library owes its callers, and it is the first time the corpus can name the alternative.

The leanness thesis gets a mechanism. Godot's 164 MB against Unreal's 21 GB is the spoke's oldest size comparison, and it is always discovered after the fact. vgpu enforces its size in CI: budgets snap to 512-byte steps, client artifacts hard-fail and anything unclassified defaults to client, while tooling artifacts warn at 5% growth. That is leanness as a build-breaking assertion rather than a property you measure afterwards. It also moves: a July commit raised the entrypoint budget to 45 KB gzip. A budget in a young library is a ratchet its maintainers reset on purpose, which is a more useful thing to know than any single number.

Edge 4 gets a data point from outside the engine tier. engine-agent-surface had three shipping retrofits and immens's unreleased claim that the surface should be foundational. vgpu is that construction, shipping — docs, examples, shader validation and MCP all served from the installed package, plus agent-evals scripts that run agents against the library as a test. Three of the four converging properties hold; the context budget does not, because a library's API fits in an agent's attention and an engine's does not. So the foundation-first argument is now demonstrated at library scale and still unproven at engine scale, which is a sharper statement of edge 4 than "is AI tooling a differentiator" — the answer depends on how big the surface being exposed is.

One fact recorded against a policy already in the corpus. vgpu's contributor list on 2026-08-28 reads matiasngf 1,014 commits, claude 21, two others at one apiece; the 21 are authored Claude <noreply@anthropic.com> and do ordinary maintenance. The repository states no policy on this. The Godot Foundation auto-bans autonomous agents from its GitHub org. The corpus now holds both positions from primary evidence, which is worth more than either alone — see the tension below.

The rung under the engines is fourteen years old (2026-08-31)

Three days after vgpu gave this wiki its first page on the layer between a graphics API and an engine, two sources arrived together that put the same layer on the native side — and it turns out to have been occupied since 2012.

bgfx is the native rung: "Cross-platform, graphics API agnostic, 'Bring Your Own Engine/Framework' style rendering library," BSD-2, 17.4k★, nine rendering backends over nine platform families, and roughly fifteen language bindings. OpenTS is a consumer of it — a from-scratch reconstruction of the Tiberian Sun engine whose README says the renderer is built on bgfx and reaches 4K ultrawide because of it. The corpus now holds both ends of one dependency.

Four things move.

The middleware tier becomes a category. box3d entered as "the wiki's first middleware component" and stood alone for two months. bgfx is the second, and the pair defines the tier by what each refuses: Box3D simulates and hands the results back, bgfx draws and does nothing else. Neither owns the game loop. What an engine actually is, in this corpus, is increasingly definable as the thing that composes these — which sharpens the standalone-vs-framework axis from underneath.

"Lean tools are production-grade" gets its strongest evidence, from below the engine tier. MonoGame answered that question at the framework level with Stardew Valley and Celeste. bgfx answers it one rung lower: Minecraft, Guild Wars 2, Football Manager 2018 and 2024, Crypt of the NecroDancer, World of Goo 2, and MAME ship on a rendering library and no engine at all. Three Wadjet Eye titles use it only for their Switch ports — bgfx as a porting layer for a game authored elsewhere, which is a use of the tier the corpus had not seen.

The engine tier borrows from below, including a first-party team. Babylon Native — the native runtime of this wiki's Babylon.js — renders through bgfx, as do Crown, Ethereal Engine, the commercial NeoAxis Engine, and Torque6, a descendant of Torque2D. And Unity's Project Tiny used bgfx before Unity discontinued it. An engine vendor building on the middleware tier rather than its own renderer is the clearest statement available that the rung is real.

Released source beats stars. openage and OpenTS are now a controlled pair: same genre, same copyleft licence, same refusal to ship game data, same requirement that the player own the original. openage reverse-engineers the Genie engine from nothing and has ~14.4k★ with limited playability after years. OpenTS starts from EA's GPL-released C&C source and has 263★ and a complete, tested, playable game two months after its repository opened. The publisher's licensing decision, made once and long ago, is worth more to a reconstruction than a decade of community attention — and it also sets the reconstruction's licence, since the derived files carry GPL §7 terms. That is the licensing axis reaching somewhere it had not touched: not what a studio pays to use an engine, but what a defunct game's engine is allowed to become.

One thing does not move. bgfx publishes no benchmarks — no frame times, no comparison against a hand-written Vulkan backend — so the cost of the abstraction is unstated, exactly as vgpu left it unstated on the web side. Two instances of the same rung, and still no number for what it costs. Its user list is also self-maintained by pull request, so it records who added themselves, not who still ships.

The AI-tooling pitch that concedes the quality argument (2026-09-10)

kovati-automation-forge sells 34 Unreal plugins that generate animation, voice, faces, meshes and materials — and opens by giving away the claim every other AI-tooling source here defends:

"The bet is not that generated assets are good enough to ship. The bet is that a game which has been played for six months before its first real asset is authored is a better game."

What it sells instead is the distance between a decision and a playable version of it — the "playable gap," with the third column of its own table drawn widest: not the clip a model returns, but the target skeleton, prop alignment, montage slot, notify, timing, blend and ability binding that make the clip a thing a player can experience. That column is engine work, and it is the part no generator returns. Whether or not the product delivers it, the framing is the most engine-literate account of AI tooling this spoke holds, because it locates the difficulty where the engine actually is.

It is also the first source here to design for replacement. The four PlayableOps steps end in graduate it deliberately and replace it safely, with a ledger recording what produced each asset. Compare godot-contribution-policy-2026, which answers the same anxiety — nobody remembers what produced the version the project uses — by banning autonomous generation from the codebase. Two positions on provenance, a year apart, neither citing the other: one refuses the input, the other instruments it. The spoke should not pretend those are compatible, and both are unmeasured.

The architectural claim outruns the product claim. Its "Trinity Architecture" — every operation on a typed subsystem, the editor UI and the agent toolset as thin clients over it, "if a function needs a widget to work, the design is wrong" — is a sharper statement of the machine-user constraint than any of the three engine vendors on engine-agent-surface has published, and it arrives from a plugin shop rather than from Epic, Unity or the Godot community. It agrees with immens that the agent surface is architecture and not a bolt-on; unlike Immens, something ships. It also adds a property the engine surfaces do not have: operations are priced before they commit, because these ones spend money.

Held at arm's length. T3 vendor marketing. The throughput and cost figures (~14 s per clip, $0.35 for a 95-line scene, 1:2 face solve on CPU) are first-party with no methodology and no hardware named; parts of the site still say "placeholder"; "open where it counts" never says what is open; and the contact address is one person's. Nothing here is evidence that the playable gap actually closes — only that someone has described it precisely.

The way in gets a document (2026-09-14)

Edge 6 has stood since spin-out as the observation that this spoke holds runtimes and no path into them. The gltf-specification is the first document on that path, and it reframes the edge more than it fills it: glTF is not a neutral middle between tools and engines but, by its own account, the end of authoring — a "distillation target" that drops what the artist needed and keeps what the GPU needs. The engine differences the spoke catalogues therefore start after import, in what each runtime makes of the same metres, +Y-up, metallic-roughness input. That is a small, useful thing to know: an engine comparison that starts at "import a glTF" is comparing renderers and asset systems, not pipelines. The studio account is still owed, and content-pipeline says so.

Flagged contradictions / tensions

Cross-spoke adjacency

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

DefinedTerm (concepts)

ComputerLanguage

Organization

Person

Article (sources)

NewsArticle (sources)

TechArticle (sources)

SoftwareSourceCode (sources)

BlogPosting (sources)

Course (sources)

DigitalDocument (sources)

Synthesis

Related pages

Links to

Linked from