Unity vs Babylon.js

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Babylon.js
   Unity~partialprobed5/10

   unity.com serves a root llms.txt file (unity-docs-15, unity-docs-16, unity-probe-rt-2) that an agent could be pointed at, but the actual technical documentation site (docs.unity3d.com) returns 404 for llms.txt and has no markdown mirrors of manual pages (unity-probe-1, unity-probe-2, unity-probe-rt-2), so agent-oriented docs coverage is only marketing-site-deep. missing for 10: llms.txt or agent-readable docs covering the actual API/manual reference (docs.unity3d.com), evidence of agents successfully consuming these docs in practice.

   • [claimed-docs] “Unity’s free plan, Unity Personal, is for individuals and small organizations with less than $100K of revenue and funds raised in the last 1…”
   • [claimed-docs] “Create and optimize high-end games and interactive experiences. Bring your team’s vision to life with Unity’s real-time development platform…”
   • [probe] “PROBE runtime (recorded 2026-09-15): unity.com serves a site-root llms.txt ('# Unity — Develop, deploy, and grow with Unity...'), but docs.u…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.unity3d.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.unity3d.com/Manual/index.html.md”

   proof ↗⚑ flag

   Babylon.js✓fullprobed9/10

   Both doc.babylonjs.com and www.babylonjs.com serve dedicated llms.txt files (confirmed by live probe returning HTTP 200) with structured, categorized documentation summaries covering setup, features, and tooling, directly enabling an agent to be pointed at these files. missing for 10: no independent third-party confirmation of agent usage/consumption of these files in practice, and no .md mirrors of the full docs for deeper agent crawling.

   • [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
   • [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
   • [claimed-docs] “Scene Management: Multiple canvases, offscreen rendering, optimization”
   • [claimed-docs] “Playground: Interactive code editor and sharing”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Unity
   Unity✓fullprobed8/10

   Unity's Editor and Player support extensive command-line arguments (unity-docs-6, unity-docs-7) including an explicit headless mode with no display/input (unity-docs-8), enabling automation and CI pipelines; Unity Hub is also installable headlessly via package managers (unity-probe-rt-3), supporting real-world CI build setups. One community report notes cost barriers to setting up a CI build server (unity-comm-13), but this is a licensing/cost complaint rather than a technical failure of headless capability. Missing for 10: independent hands-on verification of a full CI pipeline example and more detail on batchmode build automation scripts.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity Hub installs keylessly from Homebrew (cask unity-hub 3.21.2, 'Management tool for Unity') — the e…”
   • [community] “The extravagant cost of a Unity seat meant we couldn't afford to give anyone except the Unity devs a license... For the same reason, we coul…”

   proof ↗⚑ flag

   Babylon.js✓fullprobed7/10

   Babylon.js explicitly documents server-side/Node.js usage and provides a NullEngine specifically for headless rendering without a browser/WebGL context, which is the standard mechanism for running Babylon in CI or automated pipelines; NPM packages and ES6 modules further support scripted/headless integration. missing for 10: no independent/hands-on report of a CI pipeline actually using NullEngine, no explicit CI recipe or GitHub Actions example, and no MCP/agent-specific automation tooling.

   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “NPM packages for all modules”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Unity
   Unity~partialprobed6/10

   Unity ships an official MCP server (unity-mcp-get-started docs, unity.com/features/ai 'View MCP Docs') bundled in the com.unity.ai.assistant package, letting agents connect to the Editor. However it's beta, closed-source with no public repo or standalone package (no keyless handshake), and AI usage is metered via Unity Credits, while the much larger community MCP (CoplayDev/unity-mcp, 14k+ stars) suggests the official one is not the primary integration path. Missing for 10: open-source/self-hostable server, GA (non-beta) status, broader independent adoption evidence of the official server itself.

   • [probe] “official MCP server documented at https://docs.unity3d.com/Packages/com.unity.ai.assistant@latest/index.html?subfolder=/manual/integration/u…”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [claimed-docs] “Whenever you generate an image, create a 3D model, produce a sound effect, or send a message to the Assistant, you spend Unity Credits from …”

   proof ↗⚑ flag

   Babylon.js—none0/10

   Babylon.js is a rendering/game engine (not an agent), so the MCP-server axis applies as an ecosystem feature, but evidence explicitly shows no official MCP server exists — only a tiny, inactive community repo with 9 stars.

   • [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Unity
   Unity✓fullprobed7/10

   Unity ships a well-documented official CLI for the Editor and Player, supporting batch/headless mode, custom arguments, and automated build workflows (unity-docs-6/7/8/9, unity-probe-5), which is exactly the kind of scriptable interface an AI agent could drive for CI/automation. Missing for 10: no AI-specific CLI tooling and the docs aren't machine-readable (llms.txt/.md mirrors 404 per unity-probe-rt-2), limiting direct agent ingestion of the CLI reference itself.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “Unity can build your application for different platforms with unique build configurations using build profiles in the Unity Editor.”
   • [probe] “official CLI documented at https://docs.unity3d.com/Manual/EditorCommandLineArguments.html”
   • [probe] “PROBE runtime (recorded 2026-09-15): unity.com serves a site-root llms.txt ('# Unity — Develop, deploy, and grow with Unity...'), but docs.u…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   Babylon.js is a library/engine and the story asks whether it ships an official CLI for AI-native workflows; the evidence pack covers NPM packages, docs, and runtime probes but never mentions a CLI tool of any kind, official or otherwise.

   ⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Unity✓fullprobed8/10

   Unity ships an extensively documented public Scripting API for editor/runtime automation, plus documented command-line/batchmode interfaces for headless CI-driven builds, and an official MCP server (com.unity.ai.assistant) explicitly for AI-driven control of the editor, corroborated by community MCP adoption. This goes beyond a typical closed product and gives AI-native users multiple documented, programmatic entry points. Missing for 10: a formal OpenAPI/REST spec (docs.unity3d.com openapi probes 404) and independent hands-on validation of the MCP server's completeness.

   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [probe] “official MCP server documented at https://docs.unity3d.com/Packages/com.unity.ai.assistant@latest/index.html?subfolder=/manual/integration/u…”
   • [probe] “official CLI documented at https://docs.unity3d.com/Manual/EditorCommandLineArguments.html”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity Hub installs keylessly from Homebrew (cask unity-hub 3.21.2, 'Management tool for Unity') — the e…”

   proof ↗⚑ flag

   Babylon.js✓fullprobed8/10

   Babylon.js exposes its full functionality through a well-documented TypeScript/JavaScript API (TypeDoc class references, NPM packages for all modules, tree-shakable ES6 modules) that is the primary way any AI or human driver would programmatically control the engine, and community feedback independently praises the documentation quality and API discoverability. Missing for 10: no formal API stability/versioning contract or independent third-party audit of API completeness beyond community sentiment.

   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “TypeScript support with full IntelliSense”
   • [claimed-docs] “NPM packages for all modules”
   • [claimed-docs] “Modular design with tree-shakable ES6 modules”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
   • [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
   • [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to Babylon.js
   Unity✓fullprobed7/10

   Unity documents extensive official SDK-style surfaces: the public Scripting API for direct C# integration (unity-docs-11), the Package Manager ecosystem for extending functionality (unity-docs-13), editor extensibility APIs (unity-docs-10), and CLI/automation hooks for headless and CI workflows (unity-docs-6,7,8,9, unity-probe-5). It also ships an official MCP server for AI-assistant integration (unity-probe-4, unity-probe-rt-1), directly relevant to AI-native usage, though distribution is closed (no public repo) and metered via credits rather than a keyless open SDK. Missing for 10: no dedicated multi-language SDK page, no OpenAPI/REST spec (probes show 404s), and no llms.txt/markdown mirror on the actual docs site (only on unity.com marketing pages).

   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”
   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Unity can build your application for different platforms with unique build configurations using build profiles in the Unity Editor.”
   • [probe] “official MCP server documented at https://docs.unity3d.com/Packages/com.unity.ai.assistant@latest/index.html?subfolder=/manual/integration/u…”
   • [probe] “official CLI documented at https://docs.unity3d.com/Manual/EditorCommandLineArguments.html”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [probe] “PROBE runtime (recorded 2026-09-15): unity.com serves a site-root llms.txt ('# Unity — Develop, deploy, and grow with Unity...'), but docs.u…”

   proof ↗⚑ flag

   Babylon.js✓fullprobed8/10

   Babylon.js ships official, versioned NPM packages (@babylonjs/core, etc.), full TypeScript typings/IntelliSense, modular ES6 tree-shakable modules, and extensive first-party API docs plus a Playground/Inspector for iterative development — exactly what an AI-native builder needs to target a stable official SDK, corroborated by the npm registry probe (234k weekly downloads, Apache-2.0) and multiple community accounts of strong documentation and active maintenance. missing for 10: no AI-specific SDK affordances like llms.txt-formatted API references beyond the top-level doc index, and no evidence of official AI-agent tooling (MCP server) wrapping the SDK.

   • [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
   • [claimed-docs] “TypeScript support with full IntelliSense”
   • [claimed-docs] “NPM packages for all modules”
   • [claimed-docs] “Modular design with tree-shakable ES6 modules”
   • [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
   • [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Unity
   Unity~partialprobed5/10

   Unity ships an in-editor AI Assistant (part of com.unity.ai.assistant, metered via Unity Credits) that can chat, generate images/3D models/sound effects, suggesting some AI-driven help inside the editor, and this is corroborated by a live MCP integration for the Assistant. However, evidence never shows the Assistant producing analytical 'insights' from a user's own project data (e.g., analytics, performance suggestions) — it's framed as generative-content assistance rather than data-driven insight generation. Missing for 10: dedicated documentation of data-analysis/insight features, independent hands-on validation of insight quality, and detail beyond generic 'send a message to the Assistant.'

   • [claimed-docs] “Whenever you generate an image, create a 3D model, produce a sound effect, or send a message to the Assistant, you spend Unity Credits from …”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [probe] “official MCP server documented at https://docs.unity3d.com/Packages/com.unity.ai.assistant@latest/index.html?subfolder=/manual/integration/u…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Unity
   Unity~partialprobed5/10

   Unity supports background/unattended automation via documented CLI and headless-mode Editor/Player flags for CI-style builds (unity-docs-6/7/8, unity-probe-5, unity-probe-rt-3), and it also ships an official (beta) MCP server for AI-assistant integration (unity-probe-rt-1) that could drive agentic workflows. However, there's no evidence of built-in scheduling, triggers, or a persistent agent-orchestration layer — automation still requires external CI tooling or scripting rather than a native 'set-and-forget' automation feature. Missing for 10: native scheduling/trigger system, documented autonomous agent workflows beyond beta MCP, independent hands-on confirmation of unattended background runs.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [probe] “official CLI documented at https://docs.unity3d.com/Manual/EditorCommandLineArguments.html”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity Hub installs keylessly from Homebrew (cask unity-hub 3.21.2, 'Management tool for Unity') — the e…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Unity
   Unity~partialprobed6/10

   Unity docs confirm a built-in AI Assistant (com.unity.ai.assistant) that lets users generate images, 3D models, sound effects, and chat with the Assistant directly inside the Editor, metered via Unity Credits — a genuine in-product AI delegate. However, the feature is explicitly beta, evidence is thin on scope/reliability, and no independent/hands-on corroboration of its usefulness exists. Missing for 10: independent hands-on validation of the Assistant's task quality, detail on task scope/limits beyond asset generation, and confirmation it is GA rather than beta.

   • [claimed-docs] “Whenever you generate an image, create a 3D model, produce a sound effect, or send a message to the Assistant, you spend Unity Credits from …”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Unity
   Unity~partialprobed6/10

   Unity ships an official AI Assistant that accepts natural-language messages (consuming Unity Credits per message) and an official MCP server (beta) integrated into the Editor, per unity-docs-14 and unity-probe-rt-1, showing genuine natural-language operation of the tool. However this is explicitly beta, credit-metered, has no public/open repo (closed distribution), and there's no independent hands-on evidence of its reliability compared to the much larger community MCP project. Missing for 10: independent/hands-on validation of the Assistant's command execution, GA (non-beta) status, and documentation of the scope of natural-language commands it can actually perform.

   • [claimed-docs] “Whenever you generate an image, create a 3D model, produce a sound effect, or send a message to the Assistant, you spend Unity Credits from …”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [probe] “official MCP server documented at https://docs.unity3d.com/Packages/com.unity.ai.assistant@latest/index.html?subfolder=/manual/integration/u…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Babylon.js
   Unity—none0/10

   The docs manual and scripting reference exist, but there's no evidence of an interactive API reference with runnable/executable code examples — probes explicitly show no OpenAPI spec, no llms.txt/docs-md mirrors at docs.unity3d.com, and no interactive sandbox is mentioned anywhere in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.unity3d.com/openapi.json, https://docs.unity3d.com/swagger.json, https://docs.unity3d.c…”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.unity3d.com/Manual/index.html.md”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.unity3d.com/llms.txt”
   • [probe] “PROBE runtime (recorded 2026-09-15): unity.com serves a site-root llms.txt ('# Unity — Develop, deploy, and grow with Unity...'), but docs.u…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”

   proof ↗⚑ flag

   Babylon.js~partialprobed6/10

   Babylon.js has a TypeDoc-based API reference (e.g. BABYLON.NullEngine class docs) and a separate interactive Playground for runnable code examples/sharing, which together support exploring the API with live examples. However, the evidence doesn't show these are integrated (e.g. runnable snippets embedded directly inside API reference pages) nor is there independent/hands-on corroboration of this specific workflow. Missing for 10: evidence of direct API-reference-to-playground integration, and community validation of the interactive-reference experience.

   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “Playground: Interactive code editor and sharing”
   • [claimed-docs] “Playground: Interactive code editor at playground.babylonjs.com”
   • [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Unity—none0/10

   Unity is a game engine/editor, not an API-driven service, but the story asks specifically about a machine-readable API spec (OpenAPI or equivalent); probes explicitly confirm none exists — all candidate OpenAPI/Swagger paths return 404 and there is no llms.txt or docs-md mirror on the documentation domain. Since Unity does expose scripting/editor APIs and even MCP tooling, this axis is applicable to its ecosystem but the evidence shows the specific artifact is absent.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.unity3d.com/openapi.json, https://docs.unity3d.com/swagger.json, https://docs.unity3d.c…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.unity3d.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.unity3d.com/Manual/index.html.md”
   • [probe] “PROBE runtime (recorded 2026-09-15): unity.com serves a site-root llms.txt ('# Unity — Develop, deploy, and grow with Unity...'), but docs.u…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   Babylon.js exposes only human-oriented TypeDoc API references and llms.txt files; explicit probes for OpenAPI/swagger endpoints (openapi.json, swagger.json, etc.) all returned 404, showing no machine-readable API spec is published.

   • [probe] “PROBE openapi: all candidate paths 404 (https://doc.babylonjs.com/openapi.json, https://doc.babylonjs.com/swagger.json, https://doc.babylonj…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Babylon.js
   Unity—none0/10

   No evidence describes a sandbox/test environment for Unity's AI/MCP tooling that isolates test data from production; the pack only covers general Unity engine features, pricing controversy, and MCP server existence with no mention of sandbox vs. production data separation.

   ⚑ flag

   Babylon.js~partialclaimed4/10

   Babylon.js offers a NullEngine for headless/server-side testing and dedicated Playground/Sandbox tools (playground.babylonjs.com, sandbox.babylonjs.com) that let developers test scenes and code in isolation, which loosely maps to sandboxed testing without touching a 'production' environment. However, as a client-side rendering engine there is no concept of production data/environments analogous to a SaaS backend, so the story only partially applies. Missing for 10: explicit documentation framing these tools as a prod/test separation mechanism, and independent evidence of AI-native agents actually using NullEngine/Playground as a safe sandbox.

   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “Playground: Interactive code editor and sharing”
   • [claimed-docs] “Sandbox: Model viewer at sandbox.babylonjs.com”
   • [claimed-docs] “Playground: Interactive code editor at playground.babylonjs.com”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Babylon.js
   Unity—none0/10

   Evidence shows Unity exposes scripting/editor APIs and packages (unity-docs-11, unity-docs-13) but nothing documents a versioning scheme or deprecation policy for these APIs, and probes show no OpenAPI spec or machine-readable API docs (unity-probe-3, unity-probe-2). Missing for 10: any documented API versioning scheme, deprecation notices/timelines, or changelog policy for Unity's scripting/runtime APIs.

   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.unity3d.com/openapi.json, https://docs.unity3d.com/swagger.json, https://docs.unity3d.c…”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.unity3d.com/Manual/index.html.md”

   proof ↗⚑ flag

   Babylon.js~partialprobed4/10

   Babylon.js ships versioned npm packages (e.g. @babylonjs/core at 9.26.1) and community reports strong backward compatibility across releases, but there is no evidence of a documented, formal deprecation policy (e.g. deprecation timelines, breaking-change notices, semver commitments in docs). missing for 10: explicit documented deprecation policy, versioning/semver commitment docs, migration guides for breaking changes.

   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
   • [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
   • [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”

   proof ↗⚑ flag

Agent editor

1. ai-native userAn agent can drive the editor and project programmatically — create scenes and nodes, edit properties, trigger builds — through a documented scriptable interface

   weight 3 · round to Unity
   Unity✓fullprobed8/10

   Unity documents a comprehensive scripting/editor extension API (custom inspectors, EditorWindows, AssetDatabase, Package Manager) plus command-line/headless automation for builds (unity-docs-6/7/8/9/10/11/12/13), and ships an official MCP server for AI agents inside the com.unity.ai.assistant package with a dedicated get-started manual page (unity-probe-4, unity-probe-rt-1), reinforced by a large third-party community MCP server (14k+ stars) enabling agent-driven scene/property/build workflows. Missing for 10: no public repo/keyless access to the official MCP server (closed distribution, credit-metered) and no independent hands-on verification of an agent actually creating scenes/nodes end-to-end via the documented interface.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Unity can build your application for different platforms with unique build configurations using build profiles in the Unity Editor.”
   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “The Asset Database stores information about the original source asset files and their imported counterparts to keep the two sets of data in …”
   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”
   • [probe] “official MCP server documented at https://docs.unity3d.com/Packages/com.unity.ai.assistant@latest/index.html?subfolder=/manual/integration/u…”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”

   proof ↗⚑ flag

   Babylon.js~partialprobed4/10

   Babylon.js exposes a fully documented JS/TS API (scenes, meshes, materials, physics, NPM packages, TypeScript IntelliSense) letting code programmatically create scenes/nodes and edit properties, plus browser tools like Inspector, Playground, and Node Material Editor for scene editing. However these are interactive browser UIs, not designed for external programmatic driving by an agent, there's no 'build' trigger concept, and a runtime probe explicitly notes no official MCP server or agent-integration layer exists (largest community MCP repo has 9 stars, inactive since mid-2025). missing for 10: a documented agent-facing interface (e.g. MCP server or CLI) to drive the Playground/Inspector/NME externally, a build-trigger mechanism, and independent evidence of agents successfully automating editor workflows.

   • [claimed-docs] “Scene Management: Multiple canvases, offscreen rendering, optimization”
   • [claimed-docs] “Inspector: Visual debugging and scene editing”
   • [claimed-docs] “Playground: Interactive code editor and sharing”
   • [claimed-docs] “Node Material Editor: Visual shader editor at nme.babylonjs.com”
   • [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”

   proof ↗⚑ flag

Codegen

1. ai-native userLLM-generated code mostly works on the first try — stable, well-documented APIs with abundant public examples the models have seen

   weight 2 · round to Babylon.js
   Unity—none0/10

   The evidence pack contains no data on LLM code-generation success rates, model familiarity with Unity's C# API, or first-try correctness of AI-generated scripts — only general docs, pricing drama, and MCP/CLI tooling notes. Without concrete evidence (docs, benchmarks, or community reports) speaking to this axis, it cannot be credited.

   ⚑ flag

   Babylon.js~partialprobed6/10

   Babylon.js ships dedicated llms.txt files, extensive typed API docs, and community testimony praising documentation quality and strong backwards compatibility (stability helps LLM-generated code stay valid across versions). However, community evidence also notes it has notably less public content/examples than competitors like Three.js ('a lot more written about three than Babylon'), which limits training-data exposure for LLMs, and docs are client-rendered Next.js with no markdown mirrors, hurting scrapability. Missing for 10: direct evidence of LLM code-generation success rates, broader public example corpus comparable to more-documented competitors, and machine-readable doc mirrors beyond llms.txt.

   • [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
   • [community] “Babylon is amazing, the documentation and backwards compatibility is quite something. Just finished a project with it, while the learning cu…”
   • [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
   • [community] “Babylon seemed much more approachable than three for basic stuff (a box and a camera). However there is a lot more written about three than …”
   • [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”

   proof ↗⚑ flag

Copilot

1. ai-native userAn official AI assistant inside the engine helps with engine tasks — generating scripts, answering API questions, scaffolding scenes or assets

   weight 2 · round to Unity
   Unity~partialprobed6/10

   Unity has an official in-editor "Assistant" — docs confirm it exists and consumes Unity Credits for actions like generating images/models/messages (unity-docs-14), and runtime probes confirm Unity's AI tools (beta) including an MCP integration bundled in the com.unity.ai.assistant package (unity-probe-rt-1, unity-probe-4). However, the evidence pack lacks first-party documentation specifically describing script generation, API Q&A, or scene/asset scaffolding workflows for the assistant, and confirms it's still beta with closed distribution. Missing for 10: dedicated docs/examples showing the Assistant generating scripts or scaffolding scenes, independent hands-on reviews of assistant output quality.

   • [claimed-docs] “Whenever you generate an image, create a 3D model, produce a sound effect, or send a message to the Assistant, you spend Unity Credits from …”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [probe] “official MCP server documented at https://docs.unity3d.com/Packages/com.unity.ai.assistant@latest/index.html?subfolder=/manual/integration/u…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   No evidence of an official in-engine AI assistant for generating scripts, answering API questions, or scaffolding scenes; the pack only shows llms.txt documentation files (aimed at external AI tools consuming docs) and explicitly notes an essentially nonexistent MCP ecosystem with no official server.

   • [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://doc.babylonjs.com/llms.txt # Babylon.js Documentation > Babylon.js is a powerful, beautiful, simple, an…”

   proof ↗⚑ flag

Formats

1. technical artistStandard interchange formats — glTF, FBX, USD — import cleanly

   weight 2 · round to Babylon.js
   Unity—none0/10

   The evidence pack never mentions glTF, FBX, or USD import specifically — only generic Asset Database and packaging docs are cited, with no documentation or community proof of clean interchange-format import. Since format import is a fair and expected axis for a game engine's asset pipeline, absence of evidence means 'none' rather than 'na'.

   ⚑ flag

   Babylon.js~partialcommunity5/10

   Babylon.js has strong, well-documented glTF import support (dedicated importer docs, sandbox/model viewer, and general multi-format support including .babylon/glTF/STL/OBJ), and community feedback praises smooth import of 3D model data. However, there is no evidence in the pack of native FBX or USD import support, which are explicitly part of the story's required format set — missing for 10: FBX import documentation/tooling, USD import support, independent confirmation of clean FBX/USD round-tripping.

   • [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
   • [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”
   • [claimed-docs] “Sandbox: Model viewer at sandbox.babylonjs.com”
   • [community] “Babylon.js is an amazing framework. The 3d concepts are ingrained into the API and framework. The ability to read 3d model data from Blender…”

   proof ↗⚑ flag

Import

1. technical artistAsset import is automatable — import hooks, presets, and pipeline scripts process incoming assets without hand-clicking each one

   weight 2 · round to Unity
   Unity~partialclaimed5/10

   Unity's docs confirm scripting APIs, editor extensibility, and an Asset Database that syncs source and imported assets, plus command-line automation for headless/batch operations—together implying pipeline scripting is possible, but no evidence specifically documents AssetPostprocessor import hooks or importer presets, the actual mechanism artists would use to automate imports. missing for 10: explicit documentation of AssetPostprocessor/import-hook API, importer preset system, and a hands-on example of a pipeline script processing incoming assets without manual clicks.

   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “The Asset Database stores information about the original source asset files and their imported counterparts to keep the two sets of data in …”
   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”

   proof ↗⚑ flag

   Babylon.js~partialclaimed4/10

   Babylon.js exposes glTF/OBJ/STL import via a programmatic SceneLoader API and can run headlessly via NullEngine/server-side rendering (babylonjs-docs-2, babylonjs-docs-3, babylonjs-docs-6, babylonjs-docs-8), which implies imports can be scripted rather than hand-clicked, but there is no dedicated documentation of import hooks, batch presets, or a formal asset-pipeline/automation tool for technical artists. Missing for 10: explicit pipeline/preset tooling, CLI or build-step asset processors, documented hook system for custom import automation, and independent evidence of technical artists using it this way.

   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
   • [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”

   proof ↗⚑ flag

Marketplace

1. game developerA large asset store or package ecosystem gives me ready-made models, tools, and plugins

   weight 2 · round to Unity
   Unity✓fullprobed9/10

   Unity's Package Manager and Asset Database provide a structured pipeline for packages/assets (unity-docs-12, unity-docs-13), and Unity operates a large public Asset Store ecosystem for third-party models, tools, and plugins, corroborated by community references to a massive Store with hundreds of assets (unity-comm-6) and thriving community add-ons like the 14k-star community MCP server (unity-probe-rt-1) showing ecosystem breadth. Missing for 10: no first-party evidence pack citation of Asset Store size/catalog numbers or independent reviews specifically praising asset variety.

   • [claimed-docs] “The Asset Database stores information about the original source asset files and their imported counterparts to keep the two sets of data in …”
   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”
   • [community] “Unity basically told us we were not welcome back to their Store, ever, even if we removed all LGPL code. Yet there are currently hundreds of…”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”

   proof ↗⚑ flag

   Babylon.js~partialprobed4/10

   Babylon.js has a real npm package ecosystem (234k weekly downloads, modular tree-shakable modules) and supports many asset import formats (glTF, OBJ, STL, .babylon), plus community-built tools like Spector.js debugger and React-BabylonJS integration mentioned in community threads. However, there is no evidence of a dedicated asset store or marketplace for ready-made models comparable to Unity/Unreal asset stores, and the runtime probe explicitly notes the ecosystem around it (e.g., MCP tooling) is thin. Missing for 10: a curated marketplace/asset store for models, a rich plugin directory analogous to Unity Asset Store, and independent evidence of third-party asset packs beyond a couple of community-mentioned tools.

   • [claimed-docs] “NPM packages for all modules”
   • [claimed-docs] “Modular design with tree-shakable ES6 modules”
   • [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”
   • [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
   • [community] “Babylon is awesome! I just started writing a game with it. The integration with TypeScript works well and there also are very fun things lik…”
   • [community] “The impressive thing about Babylon.js is Spector, a fully functional WebGL debugger extension in Chrome which makes 3D development on the we…”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
   • [probe] “PROBE runtime negative (recorded 2026-09-15): despite Microsoft parentage, Babylon.js has essentially no MCP ecosystem — no official server,…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Unity
   Unity~partialclaimed4/10

   Unity's scripting API, AssetDatabase, and command-line/batch-mode automation (unity-docs-6/7/8/11/12) allow developers to write editor scripts that iterate over many assets or objects programmatically, which supports bulk operations, but there is no dedicated 'bulk operations' feature or AI-native tooling for it documented. Missing for 10: explicit bulk-edit/batch-apply feature, AI-agent-driven bulk workflows, and independent hands-on evidence of performing bulk operations at scale.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “The Asset Database stores information about the original source asset files and their imported counterparts to keep the two sets of data in …”

   proof ↗⚑ flag

   Babylon.js—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Unity
   Unity~partialclaimed4/10

   Unity's scripting API and editor extensibility let developers write custom event-driven code (e.g. callbacks, custom inspectors, command-line automation of build/launch workflows), which can be used to trigger actions on events, but the evidence never documents an actual declarative 'rules that trigger actions on events' system or AI-native automation trigger framework. Missing for 10: a documented rules/trigger engine (e.g. webhook-style or event-condition-action config), AI-specific automation hooks, and independent confirmation that non-scripted users can define such rules.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”

   proof ↗⚑ flag

   Babylon.js~partialcommunity3/10

   Babylon.js does include an ActionManager subsystem for defining triggers (e.g., on-pick, on-intersect) that fire actions automatically, referenced by a community user noting it 'has an action manager,' but this is not documented in the first-party doc excerpts provided and no detail on its rule scope or AI-native usage is given. Missing for 10: official documentation of the ActionManager/trigger system, examples of complex rule chaining, and any AI-agent-specific automation hooks.

   • [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Unity—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Babylon.js—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

2d

1. game developer2D is a first-class workflow — sprites, tilemaps, 2D physics — not a 3D afterthought

   weight 2 · round drawn
   Unity~partialclaimed3/10

   Only unity-docs-1's tagline ('Build 2D and 3D games for any platform') references 2D at all; the rest of the evidence pack is dominated by 3D rendering, multiplayer, and platform-build docs with no mention of sprites, Tilemap, 2D physics, or 2D-specific tooling. Missing for 10: dedicated 2D sprite/animation docs, Tilemap system evidence, 2D physics engine documentation, and any community corroboration that 2D is treated as first-class rather than a side feature.

   • [claimed-docs] “Build 2D and 3D games for any platform”

   proof ↗⚑ flag

   Babylon.js~partialcommunity3/10

   Babylon.js is documented primarily as a 3D/WebGL engine; only a single community comment notes 'sprite support and other 2d-graphics functionality' and the docs mention a 2D/3D GUI system, but there is no evidence of tilemap tooling or a dedicated 2D physics workflow — 2D appears as an add-on rather than a first-class pipeline. missing for 10: tilemap support, dedicated 2D physics engine/workflow, first-party docs treating 2D as a core (not secondary) workflow, independent corroboration of sprite tooling.

   • [community] “Babylon.js is based on the Babylon Toolkit for Silverlight, and includes significantly more features than Three.js, including sprite support…”
   • [claimed-docs] “GUI System: 2D and 3D user interfaces”
   • [claimed-docs] “Physics: Havok, Cannon.js, Ammo.js integration”

   proof ↗⚑ flag

Performance

1. game developerProfile and scale — a real profiler, plus data-oriented paths (ECS, jobs, instancing) when scenes get heavy

   weight 2 · round to Babylon.js
   Unity—none0/10

   The evidence pack contains no mention of Unity's Profiler, ECS/DOTS, Job System, or GPU instancing — only generic claims about rendering/visuals, scripting APIs, and CLI/build tooling. Since this axis clearly applies to a game engine but no evidence in the pack substantiates the specific profiling or data-oriented tech stack, it must be scored as none. missing for 10: any mention of the Unity Profiler, ECS/DOTS, Job System, Burst compiler, or GPU instancing documentation/evidence.

   ⚑ flag

   Babylon.js~partialcommunity4/10

   Babylon.js clearly ships real profiling tools — the Inspector/Scene Inspector for runtime debugging and scene analysis, plus community confirmation of the Spector.js WebGL debugger — but there is no documented ECS, job/worker system, or GPU instancing API in the evidence pack for scaling heavy scenes. Community notes even flag historical GC/allocation pressure concerns around performance-sensitive code. missing for 10: explicit ECS architecture, job/worker-based parallelism, and documented instancing API/guidance for scaling heavy scenes.

   • [claimed-docs] “Inspector: Visual debugging and scene editing”
   • [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
   • [community] “The impressive thing about Babylon.js is Spector, a fully functional WebGL debugger extension in Chrome which makes 3D development on the we…”
   • [community] “It seems to be pretty heavy on object allocation, e.g. BABYLON.Vector3.prototype.add creates a new Vector3 each time, unlike gl-matrix's in-…”
   • [community] “The next version (1.2) will remove the pressure on GC by using in-place operators and by reusing more entities.”

   proof ↗⚑ flag

Physics

1. game developerBuilt-in physics — rigid bodies, collisions, raycasts — works out of the box

   weight 2 · round to Babylon.js
   Unity—none0/10

   The evidence pack contains no documentation, community discussion, or probe results that specifically mention Unity's physics engine, rigid bodies, colliders, or raycasting — only generic references to building 2D/3D games, scripting APIs, and editor extensibility. Absence of evidence for this well-known capability must be scored as 'none' rather than inferred from outside knowledge.

   ⚑ flag

   Babylon.js!disputedcontradicted5/10

   Docs confirm built-in physics engine integration (Havok, Cannon.js, Ammo.js, Oimo.js) and community posts mention 'physics plug-ins and collisions' as part of the engine's game-engine-like feature set, but a detailed hands-on critique explicitly calls the physics implementation 'inexcusably my first game engine level of incompetence,' citing broken velocity/acceleration handling and frame-rate dependent world time, plus another comment noting it 'doesn't care for real-world physics scale.' This is a concrete first-hand contradiction of the 'works out of the box' claim, not mere skepticism. missing for 10: raycast-specific evidence, independent benchmark refuting or confirming the physics bug claims, resolution/fix documentation.

   • [claimed-docs] “Physics: Havok, Cannon.js, Ammo.js integration”
   • [claimed-docs] “Support for multiple physics engines (Cannon.js, Oimo.js, Ammo.js)”
   • [community] “The 'Physics' in Babylon.js is at the inexcusably 'my first game engine' level of incompetence. Velocity and acceleration treated as if they…”
   • [community] “I had high hopes for babylon.js... My gripes: no 'preferred navigation feel', doesn't care for real-world physics scale, setting up a defaul…”
   • [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”

   proof ↗⚑ flag

Rendering

1. game developerThe engine ships a modern production 3D renderer — PBR materials, global illumination or baked lighting, shadows, post-processing

   weight 3 · round to Unity
   Unity~partialclaimed7/10

   Unity's docs confirm a modern rendering pipeline is offered ('scalable, captivating visuals using the latest advances in rendering, lighting, and visual effects') and marketing pages reference real-time 3D rendering/visual fidelity, consistent with Unity's known HDRP/URP pipelines supporting PBR, GI, shadows, and post-processing. However, the evidence pack is thin on specifics — no direct mention of PBR materials, baked/real-time GI systems, shadow techniques, or the post-processing stack by name. missing for 10: explicit documentation of PBR material workflow, GI/lightmapping details, shadow cascade features, post-processing stack/volume framework, and independent hands-on corroboration of rendering quality.

   • [claimed-docs] “Elevate your scenes with scalable, captivating visuals using the latest advances in rendering, lighting, and visual effects.”
   • [claimed-docs] “Build and review 3D projects in real time”
   • [claimed-docs] “Create and optimize high-end games and interactive experiences. Bring your team’s vision to life with Unity’s real-time development platform…”

   proof ↗⚑ flag

   Babylon.js~partialcommunity4/10

   Evidence confirms Babylon.js is a real-time WebGL/WebGPU rendering engine with a Node Material Editor and native glTF PBR material import, implying baseline PBR support, but the pack contains no explicit documentation of shadow mapping, global illumination/baked lighting, or a post-processing pipeline. Community threads praise visual quality and demos but don't confirm these specific pipeline features either. Missing for 10: explicit shadow system docs, GI/lightmapping baked-lighting docs, post-process stack documentation, and independent corroboration of PBR material fidelity.

   • [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
   • [claimed-docs] “Node Material Editor”
   • [claimed-docs] “WebGL and WebGPU rendering support”
   • [claimed-docs] “WebGPU Support: Next-generation graphics API”
   • [community] “This has so many more capabilities than Three.js and the gap seems to be growing.”

   proof ↗⚑ flag

Collaboration

1. studio leadThe project format and tooling play well with version control and multi-person teams — mergeable scenes, diffable text formats, or built-in collaboration

   weight 2 · round to Unity
   Unity~partialclaimed2/10

   Evidence only offers a vague marketing tagline ('Collaborate and iterate quickly with your team') with no detail on scene serialization format, diffability, merge tooling, or a named collaboration/VCS product; nothing describes mergeable scenes or text-based diff-friendly formats. Missing for 10: documentation of YAML/text scene serialization mode, a smart-merge tool for scenes/prefabs, and details of a built-in version-control/collaboration product (e.g. Unity VCS/Plastic) with independent corroboration.

   • [claimed-docs] “Collaborate and iterate quickly with your team”

   proof ↗⚑ flag

   Babylon.js—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Editor

1. technical artistA full visual editor — viewport, inspector, prefabs/scene composition — is the primary way to build levels

   weight 3 · round to Unity
   Unity✓fullclaimed9/10

   Unity's Editor is explicitly documented as extendable with custom inspectors, editor windows, and property drawers, backed by scripting APIs and an Asset Database that underpins scene/prefab composition; this is Unity's well-known primary workflow (viewport, inspector, scene/prefab authoring). missing for 10: no direct hands-on/independent walkthrough of prefab workflows or viewport usage specifically, just docs on inspector/editor extension and asset management.

   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “The Asset Database stores information about the original source asset files and their imported counterparts to keep the two sets of data in …”
   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”

   proof ↗⚑ flag

   Babylon.js~partialcommunity4/10

   Babylon.js ships an Inspector for runtime scene debugging/editing, a Node Material Editor, Playground, and Sandbox model viewer, but these are auxiliary tools layered on a code-first engine rather than a unified viewport+prefab+scene-composition editor that serves as the primary level-building workflow. Community commentary confirms it's approached as a programming API/game engine, not an artist-first editor. missing for 10: a full prefab/scene-composition system, an integrated single viewport combining inspector+asset placement+hierarchy editing as the primary workflow, and evidence of technical artists building levels without code.

   • [claimed-docs] “Inspector: Visual debugging and scene editing”
   • [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
   • [claimed-docs] “Node Material Editor”
   • [claimed-docs] “Playground: Interactive code editor and sharing”
   • [claimed-docs] “Sandbox: Model viewer at sandbox.babylonjs.com”
   • [community] “I switched from Three to Babylon two years ago... Babylon has a compact, active set of devs (I've made bug reports and seen the fix in the n…”
   • [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”

   proof ↗⚑ flag

Extensibility

1. game developerExtend and automate the editor itself — custom tools, editor scripts, plugins that manipulate scenes and assets programmatically

   weight 3 · round to Unity
   Unity✓fullclaimed9/10

   Unity's docs explicitly document extending the editor with custom inspectors, Editor Windows, Property Drawers, and direct scripting access to public Unity APIs, plus AssetDatabase APIs for programmatic asset manipulation and a Package Manager for distributing/consuming editor tooling — directly matching the story's ask for custom tools/editor scripts/plugins that manipulate scenes and assets. This is a first-party, mature, widely-used capability (also evidenced by a large third-party ecosystem like community MCP tooling built on this extensibility). Missing for 10: independent hands-on developer testimonials specifically about editor scripting workflows (community evidence in the pack focuses on pricing/licensing controversies, not editor extensibility).

   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [claimed-docs] “The Asset Database stores information about the original source asset files and their imported counterparts to keep the two sets of data in …”
   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”

   proof ↗⚑ flag

   Babylon.js—none0/10

   Evidence mentions an Inspector for visual scene debugging/editing and a Playground/Node Material Editor, but nothing documents an extensibility API, plugin system, or scripting interface for building custom editor tools or automating the editor itself. Missing for 10: editor plugin/extension API, documented editor scripting hooks, examples of third-party editor tools or automation scripts.

   • [claimed-docs] “Inspector: Visual debugging and scene editing”
   • [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
   • [claimed-docs] “Playground: Interactive code editor and sharing”
   • [claimed-docs] “Node Material Editor”

   proof ↗⚑ flag

Ci

1. game developerBuild and export the project from the command line, headless, in CI — no human clicking an editor

   weight 3 · round to Unity
   Unity✓fullprobed8/10

   Unity officially documents command-line/editor CLI args, headless mode (-batchmode/-nographics), and BuildSettings/build profiles for automated builds, which together enable scripted, non-interactive CI builds; Unity Hub can be installed headlessly via package managers. Missing for 10: no independent hands-on CI pipeline report confirming end-to-end success, and community evidence notes real friction with setting up CI/build servers due to licensing costs.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “Unity can build your application for different platforms with unique build configurations using build profiles in the Unity Editor.”
   • [probe] “official CLI documented at https://docs.unity3d.com/Manual/EditorCommandLineArguments.html”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity Hub installs keylessly from Homebrew (cask unity-hub 3.21.2, 'Management tool for Unity') — the e…”
   • [community] “The extravagant cost of a Unity seat meant we couldn't afford to give anyone except the Unity devs a license... For the same reason, we coul…”

   proof ↗⚑ flag

   Babylon.js~partialprobed5/10

   Babylon.js is a library, not an editor-centric tool, so scenes are inherently built via code/npm (NullEngine for headless rendering, server-side support, NPM/ES6 modules) — this enables CLI/CI usage in principle. However, there is no documented official CLI, build/export pipeline, or CI/headless-testing example specific to game export workflows; the evidence only shows generic headless-engine primitives, not an end-to-end automated build/export toolchain. missing for 10: an official CLI or build tool for scene/asset export, documented CI pipeline examples, evidence of automated packaging/export without any editor interaction, independent confirmation of headless CI usage.

   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “Scene Management: Multiple canvases, offscreen rendering, optimization”
   • [claimed-docs] “NPM packages for all modules”
   • [claimed-docs] “Modular design with tree-shakable ES6 modules”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

Server

1. game developerGame logic runs headless on servers — a dedicated-server or server-runtime build without rendering

   weight 2 · round to Unity
   Unity✓fullprobed8/10

   Unity's Player command-line docs explicitly describe running the application in headless mode with no rendering or input, and this combines with documented command-line/batchmode automation for server builds; Unity is widely used to build dedicated-server binaries via this mechanism. Missing for 10: no first-party 'dedicated server build target' walkthrough or independent case study confirming headless server deployment at scale.

   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [probe] “official CLI documented at https://docs.unity3d.com/Manual/EditorCommandLineArguments.html”

   proof ↗⚑ flag

   Babylon.js~partialclaimed6/10

   Babylon.js documents server-side usage and a NullEngine specifically designed for headless execution (no rendering context) on Node.js, which supports running game logic/physics without a GPU or DOM, per babylonjs-docs-2 and babylonjs-docs-3. However, this is a headless rendering-engine mode rather than a dedicated 'server-runtime build' product, and there's no independent/hands-on corroboration of production server deployments or performance at scale. missing for 10: independent verification of NullEngine in production server use, benchmarks/scale evidence, and any purpose-built 'server build' distinct from just importing core modules headlessly.

   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “NPM packages for all modules”

   proof ↗⚑ flag

Testing

1. game developerTests run headlessly — unit and integration tests of game code execute in CI against the real engine

   weight 2 · round to Babylon.js
   Unity~partialcommunity5/10

   Unity docs confirm the Editor/Player can be run headlessly via command-line arguments (-batchmode, -nographics equivalents) which is the foundation for CI automation (unity-docs-6,7,8), and community evidence confirms a CI build server setup is a real (if costly) practice (unity-comm-13). However, there is no direct evidence of Unity's Test Runner/Test Framework CLI flags (e.g., -runTests) or of CI-based unit/integration test execution against the real engine — the pack only shows generic headless launch capability, not test-specific automation. missing for 10: explicit Unity Test Framework / -runTests CLI documentation, evidence of CI pipelines executing engine unit tests, independent hands-on confirmation of headless test runs succeeding.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [community] “The extravagant cost of a Unity seat meant we couldn't afford to give anyone except the Unity devs a license... For the same reason, we coul…”

   proof ↗⚑ flag

   Babylon.js✓fullclaimed7/10

   Babylon.js ships a documented NullEngine specifically for running the engine headlessly (no WebGL context) plus a dedicated server-side/Node.js support guide, which is the standard mechanism for executing engine logic in CI/unit tests. Missing for 10: independent/community corroboration of real CI pipelines using NullEngine, and no example test harness or CI config shown in the evidence.

   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “NPM packages for all modules”

   proof ↗⚑ flag

Governance

1. studio leadThe project's governance and funding are transparent — a foundation, published finances, or a public roadmap I can plan against

   weight 1 · round drawn
   Unity—none0/10

   Unity is a commercial, for-profit company with no evidence of foundation governance, published financials, or a public roadmap a studio could plan against; the only related material is marketing pages and a blog post reversing a pricing decision. Community evidence instead documents unilateral, retroactive policy changes (comm-2, comm-7, comm-12, comm-15) that undermine any sense of predictable governance.

   • [claimed-docs] “Unity is Canceling the Runtime Fee”
   • [community] “It reminds me of Darth Vader's line: 'I have altered the deal. Pray I don't alter it further.' The per-install fee applies retroactively to …”
   • [community] “Unity's mishandling of the Runtime Fee policy announcement has caused permanent damage to their reputation. I follow a lot of game developer…”
   • [community] “Unity forced my last company into the more expensive license unilaterally and with no discussion. They doubled our costs just because they c…”
   • [community] “This shows once again that Unity is an unreliable option for new projects. The worst part is not the 4% fee, but the bluntness with which Un…”

   proof ↗⚑ flag

   Babylon.js—none0/10

   No evidence pack item addresses governance structure, foundation status, published finances, or a public roadmap for Babylon.js; the pack is entirely feature docs and community sentiment about technical quality.

   ⚑ flag

License

1. studio leadThe license is permissive with no royalties or per-install fees — I keep what my game earns

   weight 3 · round to Babylon.js
   Unity!disputedcontradicted3/10

   Unity's default model is seat/subscription-based (not per-revenue royalties) and the controversial per-install Runtime Fee was announced and then canceled (unity-docs-21), which superficially supports 'no royalties/per-install fees.' However, concrete community evidence directly contradicts the 'permissive, keep what you earn' framing: the per-install fee was retroactively applied to already-shipped games before cancellation (unity-comm-2), studios report being unilaterally forced into pricier license tiers (unity-comm-12), and developers describe Unity's terms as able to 'change at any moment' (unity-comm-15) — the opposite of a stable, low-friction license. missing for 10: vendor documentation of the actual current licensing terms/royalty structure, resolution confirming no future fee reintroduction, and independent legal/financial analysis of the license's permissiveness.

   • [claimed-docs] “Unity is Canceling the Runtime Fee”
   • [community] “It reminds me of Darth Vader's line: 'I have altered the deal. Pray I don't alter it further.' The per-install fee applies retroactively to …”
   • [community] “Unity forced my last company into the more expensive license unilaterally and with no discussion. They doubled our costs just because they c…”
   • [community] “This shows once again that Unity is an unreliable option for new projects. The worst part is not the 4% fee, but the bluntness with which Un…”
   • [community] “Unity's mishandling of the Runtime Fee policy announcement has caused permanent damage to their reputation. I follow a lot of game developer…”

   proof ↗⚑ flag

   Babylon.js✓fullprobed8/10

   The runtime probe confirms Babylon.js core packages are published under Apache-2.0, a permissive license with no royalties or per-install fees, and this is corroborated by wide npm adoption figures. Missing for 10: no explicit first-party licensing page/FAQ evidence in the pack addressing commercial game revenue or royalty terms directly, and no independent legal/community discussion confirming this understanding.

   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

Source

1. game developerRead and modify the full engine source when I hit a wall

   weight 2 · round to Babylon.js
   Unity—none0/10

   Evidence covers scripting APIs, editor extensibility, and packages, but nothing indicates access to or modification of Unity's actual engine source code (Unity is closed-source/proprietary); community evidence instead highlights licensing rigidity and forced fee changes, reinforcing lack of source openness. Missing for 10: any documentation of source code licenses, C++ engine source access program, or ability to recompile/modify the core engine.

   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [community] “Unity forced my last company into the more expensive license unilaterally and with no discussion. They doubled our costs just because they c…”
   • [community] “The extravagant cost of a Unity seat meant we couldn't afford to give anyone except the Unity devs a license... For the same reason, we coul…”

   proof ↗⚑ flag

   Babylon.js✓fullprobed7/10

   Babylon.js is confirmed Apache-2.0 licensed and distributed as open npm packages (@babylonjs/core), and community reports describe developers filing GitHub bug reports and seeing fixes merged within nightly builds, indicating the source is open, forkable, and modifiable in practice. Missing for 10: explicit product docs on the contribution/build-from-source workflow and any direct developer account of forking the engine to patch internals.

   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
   • [community] “three.js seems more well known/established than babylon... I went with babylon and I'm glad I did. Better performance and the object names a…”
   • [community] “I switched from Three to Babylon two years ago... Babylon has a compact, active set of devs (I've made bug reports and seen the fix in the n…”
   • [community] “I would say it is more of a game engine, especially compared to three.js. Babylon.js supports physics plug-ins and collisions, has an action…”

   proof ↗⚑ flag

Trust

1. studio leadThe pricing and license terms have a track record of stability — no retroactive changes that reprice games already shipped

   weight 2 · round to Babylon.js
   Unity—none0/10

   Community evidence directly documents a retroactive pricing change (the 2023 Runtime Fee applied to already-shipped games) and multiple accounts of unilateral license/cost changes forced on existing customers, the opposite of the stability this story asks for; no vendor commitment to non-retroactive pricing is evidenced.

   • [community] “It reminds me of Darth Vader's line: 'I have altered the deal. Pray I don't alter it further.' The per-install fee applies retroactively to …”
   • [community] “Unity forced my last company into the more expensive license unilaterally and with no discussion. They doubled our costs just because they c…”
   • [community] “This shows once again that Unity is an unreliable option for new projects. The worst part is not the 4% fee, but the bluntness with which Un…”
   • [claimed-docs] “Unity is Canceling the Runtime Fee”

   proof ↗⚑ flag

   Babylon.js✓fullprobed7/10

   Babylon.js is confirmed as Apache-2.0 licensed open-source software (babylonjs-probe-rt-1), a permissive license model that structurally cannot retroactively reprice shipped games — there is no paid-tier or revenue-share license to alter. No evidence in the pack shows any history of license or pricing changes, and community discussion focuses on technical quality, not licensing disputes. Missing for 10: an explicit historical narrative confirming multi-year license stability or any statement addressing past licensing changes (or lack thereof).

   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Unity~partialprobed5/10

   Unity exposes extensive scripting APIs, editor extensibility, and CLI/command-line automation for builds and headless runs, letting many UI workflows be scripted, but there is no general REST/GraphQL API mirroring the full Editor UI — automation is Editor/CLI/C#-script based rather than a universal API surface, and no OpenAPI spec exists (404s confirmed). missing for 10: a documented general-purpose API (not just CLI args/C# scripting) covering all UI actions, evidence of parity between UI and programmatic access, and confirmation openapi/swagger specs exist.

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “Unity lets you extend the editor with your own custom inspectors and Editor Windows and you can define how properties are displayed in the i…”
   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.unity3d.com/openapi.json, https://docs.unity3d.com/swagger.json, https://docs.unity3d.c…”
   • [probe] “official CLI documented at https://docs.unity3d.com/Manual/EditorCommandLineArguments.html”

   proof ↗⚑ flag

   Babylon.js~partialclaimed5/10

   Babylon.js is fundamentally a code-first library (NPM/ES6 modules, TypeScript, NullEngine for headless/server-side use) so most scene, mesh, material and physics functionality is exposed programmatically, and NullEngine explicitly supports server-side/headless scenarios without any UI [babylonjs-docs-2, babylonjs-docs-3, babylonjs-docs-24, babylonjs-docs-25]. However, the evidence never explicitly confirms that visual-only tools like the Node Material Editor, Inspector, or Playground have complete 1:1 API equivalents for every feature they expose, so full UI/API parity is inferred rather than documented. Missing for 10: explicit documentation stating NME/Inspector-generated configurations are always fully reproducible via API alone, and independent confirmation of this parity.

   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “Node Material Editor”
   • [claimed-docs] “Inspector: Visual debugging and scene editing”
   • [claimed-docs] “Node Material Editor: Visual shader editor at nme.babylonjs.com”
   • [claimed-docs] “NPM packages for all modules”
   • [claimed-docs] “Modular design with tree-shakable ES6 modules”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Babylon.js
   Unity—none0/10

   The evidence pack contains no documentation of a data-export feature or open-format portability guarantee for Unity projects (assets, scenes, or AI credits data); most content is about platform support, editor extensibility, and pricing controversies, not data portability.

   ⚑ flag

   Babylon.js~partialprobed5/10

   Babylon.js is open-source (Apache-2.0) and supports open, standard 3D file formats like glTF, OBJ, and STL alongside its own .babylon format, so scene/asset data isn't locked into a single proprietary format and can be exported or moved elsewhere. However, there is no first-party or community evidence of a comprehensive 'export all my data and leave' workflow, no discussion of data portability/lock-in avoidance as a stated goal, and no independent confirmation that full round-trip export preserves all engine-specific features (physics, materials, animations). missing for 10: explicit data-export/migration documentation, independent verification of full-fidelity export to open formats, and any framing of this as an intentional anti-lock-in feature.

   • [claimed-docs] “Supports multiple file formats including .babylon, glTF, STL, OBJ, and more”
   • [claimed-docs] “source: https://doc.babylonjs.com/features/featuresDeepDive/importers/glTF”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Babylon.js
   Unity—none0/10

   Unity Engine is proprietary; there is no evidence of an open-source license for its source code, and Unity is a closed commercial product per the evidence (Package Manager, paid plans, closed MCP distribution). This is a fair axis to ask of any dev platform, but no evidence supports open-source availability of Unity's source.

   • [claimed-docs] “Packages deliver a wide range of enhancements to Unity through the Package Manager.”
   • [claimed-docs] “Unity’s free plan, Unity Personal, is for individuals and small organizations with less than $100K of revenue and funds raised in the last 1…”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”

   proof ↗⚑ flag

   Babylon.js✓fullprobed9/10

   Babylon.js core is confirmed Apache-2.0 licensed and published on npm (v9.26.1), and the project is well known to be hosted openly on GitHub with full source visible; runtime probe corroborates the license and package registry data. Missing for 10: no explicit evidence pack citation of the GitHub repository page itself or contribution guidelines to fully corroborate open-source hosting beyond the npm license field.

   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Babylon.js
   Unity~partialprobed6/10

   Unity's core Editor/Player is inherently installed and run on the user's own machines (Unity Hub installs locally, headless -batchmode/-nographics CLI for CI build servers, EditorCommandLineArguments for automation), so the core engine is effectively self-hosted by design rather than a vendor-controlled cloud service. However, Unity's newer AI-native features (Unity AI Assistant, MCP integration) are explicitly cloud-metered via Unity Credits with no public/self-hostable package, so the AI-native layer itself cannot be self-hosted. Missing for 10: a documented self-hosted deployment path for the AI/MCP layer, and any first-party guidance on self-hosting build infrastructure at scale (e.g. license/build-server constraints noted in community reports).

   • [claimed-docs] “You can run the Unity Editor and Players from command-line interfaces to change and customize how they run at launch time.”
   • [claimed-docs] “You can launch the Unity Editor and Player with additional command line arguments to control startup behavior, configure settings, or automa…”
   • [claimed-docs] “Run the application in headless mode. In this mode, the application doesn’t display anything or accept user input.”
   • [claimed-docs] “Unity can build your application for different platforms with unique build configurations using build profiles in the Unity Editor.”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity ships an OFFICIAL MCP server as part of Unity's AI tools (beta) inside the com.unity.ai.assistant…”
   • [probe] “PROBE runtime (recorded 2026-09-15): Unity Hub installs keylessly from Homebrew (cask unity-hub 3.21.2, 'Management tool for Unity') — the e…”
   • [community] “The extravagant cost of a Unity seat meant we couldn't afford to give anyone except the Unity devs a license... For the same reason, we coul…”

   proof ↗⚑ flag

   Babylon.js✓fullprobed7/10

   Babylon.js is an Apache-2.0 licensed npm package/library that runs entirely client-side or server-side (NullEngine, documented server-side support), so a user can self-host the core engine simply by installing it in their own infrastructure with no vendor cloud dependency; runtime probe confirms open license and active npm distribution. Missing for 10: no explicit self-hosting/deployment guide (e.g., Docker image, on-prem playground/inspector hosting instructions) and no independent report of someone self-hosting the full toolchain (playground, inspector, sandbox) rather than just the core engine.

   • [claimed-docs] “source: https://doc.babylonjs.com/setup/support/serverSide”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”
   • [claimed-docs] “NPM packages for all modules”

   proof ↗⚑ flag

Targets

1. studio leadOne project exports to desktop, mobile, and (directly or via partners) consoles

   weight 3 · round to Unity
   Unity✓fullclaimed8/10

   Unity's docs explicitly advertise building for 25+ platforms including desktop, mobile, and consoles via build profiles/Build Settings, and it is well established that console export happens through Unity's console-partner program rather than open SDKs. Missing for 10: no direct evidence pack detail on console-specific partner workflow/certification process or independent studio confirmation of simultaneous multi-platform shipping.

   • [claimed-docs] “Build 2D and 3D games for any platform”
   • [claimed-docs] “Discover 25+ platforms Unity supports”
   • [claimed-docs] “Unity can build your application for different platforms with unique build configurations using build profiles in the Unity Editor.”
   • [claimed-docs] “Ship big games with small teams”

   proof ↗⚑ flag

   Babylon.js~partialclaimed5/10

   Babylon.js supports web (WebGL/WebGPU) export and claims native cross-platform via Babylon Native, which could enable desktop/mobile builds, but the evidence pack contains no documentation of console export (PlayStation, Xbox, Switch) or partner pipelines, and no independent confirmation of Babylon Native's mobile/desktop deployment maturity. missing for 10: console export/partner program details, hands-on evidence of desktop/mobile builds via Babylon Native, independent corroboration of cross-platform deployment success.

   • [claimed-docs] “Cross-Platform: Runs seamlessly on web browsers and natively with Babylon Native”
   • [claimed-docs] “WebGL and WebGPU rendering support”
   • [claimed-docs] “WebGPU Support: Next-generation graphics API”

   proof ↗⚑ flag

Web

1. web developerMy game runs in the browser with a reasonable payload — WebGL today, and a credible WebGPU story

   weight 2 · round to Babylon.js
   Unity—none0/10

   The evidence pack only offers generic cross-platform claims (e.g., '25+ platforms', 'any platform') with no mention of WebGL, WebGPU, browser payload size, or any web-specific export tooling; nothing addresses this story's specific subject.

   ⚑ flag

   Babylon.js~partialcommunity6/10

   Docs confirm both WebGL and WebGPU rendering support plus tree-shakable ES6/NPM modules for payload optimization, but community evidence flags real payload concerns (Babylon is described as 3x the size of Three.js, and long load times/50MB scenes were reported), which Babylon's own reps acknowledge and only partially address via incremental loading. Missing for 10: independent verification of actual bundle sizes after tree-shaking, benchmarked WebGPU performance/adoption data, and confirmation that payload complaints have been resolved in recent versions.

   • [claimed-docs] “WebGL and WebGPU rendering support”
   • [claimed-docs] “WebGPU Support: Next-generation graphics API”
   • [claimed-docs] “NPM packages for all modules”
   • [claimed-docs] “Modular design with tree-shakable ES6 modules”
   • [community] “My wife found that ThreeJS breaks backwards compatibility a lot, while Babylon is exactly the opposite. Babylon also has vastly superior doc…”
   • [community] “demos look quite nice but wow they take a long time to load, took about 5 minutes to download 50mb for a short scene, makes me wonder if dow…”
   • [community] “To avoid having too long loading time, we have support for incremental loading. But we definitely need to work on optimizing the size of our…”

   proof ↗⚑ flag

2. web developerThe engine installs from a package registry into my existing toolchain — a library I import, bundle, and tree-shake like any dependency

   weight 2 · round to Babylon.js
   Unity—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Babylon.js✓fullprobed9/10

   Babylon.js ships as NPM packages (@babylonjs/core, confirmed live on npm registry with real version/downloads), documents ES6 module support, and explicitly advertises a modular, tree-shakable ES6 architecture for bundlers. TypeScript support with full IntelliSense further confirms standard toolchain integration. Missing for 10: independent third-party benchmark/case study of tree-shaking effectiveness in a real bundler beyond vendor docs.

   • [claimed-docs] “Setup & Installation: Framework packages, NPM support, ES6 modules”
   • [claimed-docs] “NPM packages for all modules”
   • [claimed-docs] “Modular design with tree-shakable ES6 modules”
   • [claimed-docs] “TypeScript support with full IntelliSense”
   • [probe] “PROBE runtime (recorded 2026-09-15): `npm view @babylonjs/core version` → 9.26.1 (Apache-2.0, 234,040 weekly downloads via the public npm AP…”

   proof ↗⚑ flag

Iteration

1. game developerThe edit-run loop is fast — hot reload or near-instant preview after a script change

   weight 2 · round to Babylon.js
   Unity—none0/10

   The evidence pack covers scripting APIs, editor extensibility, CLI/build automation, and packages, but contains no documentation or community evidence specifically about hot reload, domain reload speed, or near-instant preview after script changes — a well-known pain point/feature area for Unity that simply isn't addressed here.

   ⚑ flag

   Babylon.js~partialclaimed4/10

   Babylon.js offers a Playground for instant in-browser code iteration and NullEngine/headless testing, which supports fast preview cycles, but there is no evidence of actual hot-reload tooling (e.g., a dev server with HMR for local project scripts) or documentation describing an edit-run loop for typical game-dev workflows outside the Playground sandbox. missing for 10: dedicated hot-reload/watch tooling for local script changes, first-party dev-server integration, independent hands-on confirmation of near-instant reload during real project development.

   • [claimed-docs] “Playground: Interactive code editor and sharing”
   • [claimed-docs] “Playground: Interactive code editor at playground.babylonjs.com”
   • [claimed-docs] “source: https://doc.babylonjs.com/typedoc/classes/BABYLON.NullEngine”
   • [claimed-docs] “Inspector: Visual debugging and scene editing”

   proof ↗⚑ flag

Language

1. game developerThe primary scripting language is productive and fully exposes the engine API, with a debugger behind it

   weight 3 · round to Babylon.js
   Unity~partialcommunity4/10

   Evidence confirms Unity exposes public scripting APIs directly for fine-grained control and customization (unity-docs-11), and community comments corroborate that C# scripting is product993 and lets devs 'ignore the engine features' (unity-comm-4), supporting productivity. However, there is no evidence in the pack about a debugger being available or integrated for the scripting language, nor any detail on API completeness/coverage. Missing for 10: documentation or corroboration of a debugger (breakpoints, step-through, attach-to-process) for the scripting workflow, and evidence of full API surface coverage beyond general scripting docs.

   • [claimed-docs] “Interacting directly with the public Unity APIs allows for finer control and a greater degree of customization.”
   • [community] “I used XNA, then MS killed it... then switched to Unity, been using it since 2012... As a lone indie dev I find Unreal very tedious and slow…”

   proof ↗⚑ flag

   Babylon.js✓fullcommunity7/10

   Babylon.js uses JavaScript/TypeScript as its scripting language, with full TypeScript IntelliSense exposing the entire engine API (babylonjs-docs-12), and ships the Inspector/Scene Inspector for runtime debugging plus community corroboration of the Spector WebGL debugger extension making development easier (babylonjs-docs-13, babylonjs-docs-20, babylonjs-comm-10). Community testimonials also confirm productive TS integration in real projects (babylonjs-comm-17). missing for 10: independent benchmarking of scripting productivity vs other engines, deeper evidence the debugger covers full script-level breakpoints/stepping (vs just WebGL call inspection), and first-party docs explicitly tying TypeScript API completeness to debugger workflow.

   • [claimed-docs] “TypeScript support with full IntelliSense”
   • [claimed-docs] “Inspector: Visual debugging and scene editing”
   • [claimed-docs] “Scene Inspector: Runtime debugging and scene analysis tools”
   • [community] “The impressive thing about Babylon.js is Spector, a fully functional WebGL debugger extension in Chrome which makes 3D development on the we…”
   • [community] “Babylon is awesome! I just started writing a game with it. The integration with TypeScript works well and there also are very fun things lik…”

   proof ↗⚑ flag

Visual

1. technical artistBuild gameplay logic with visual scripting without writing code

   weight 2 · round drawn
   Unity—none0/10

   The evidence pack contains no mention of Unity's Visual Scripting tool (or any no-code/node-based logic system) — it only documents C# scripting, editor extension APIs, and command-line tooling. Missing for 10: any documentation of a visual/node-based scripting system, tutorials or community proof of technical artists building gameplay logic without code.

   ⚑ flag

   Babylon.js—none0/10

   Evidence shows a Node Material Editor (visual shader/material editor) and a code-based Playground, but nothing about a visual scripting system for gameplay logic (e.g., a node-based behavior/flow graph) that would let a technical artist avoid writing code for game logic.

   • [claimed-docs] “Node Material Editor”
   • [claimed-docs] “Node Material Editor: Visual shader editor at nme.babylonjs.com”
   • [claimed-docs] “Playground: Interactive code editor and sharing”

   proof ↗⚑ flag