[ { "productId": "babylonjs", "storyId": "agent-editor-control", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-4", "babylonjs-docs-13", "babylonjs-docs-7", "babylonjs-docs-19", "babylonjs-probe-rt-2" ] }, { "productId": "babylonjs", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-1", "babylonjs-probe-rt-1", "babylonjs-docs-1", "babylonjs-docs-4", "babylonjs-docs-7" ] }, { "productId": "babylonjs", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "agentic-headless", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-2", "babylonjs-docs-3", "babylonjs-docs-24", "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a 3D rendering/game engine library, not an AI agent or agent-orchestration platform; consuming MCP tool servers is not a fair axis for this kind of product. The negative probe confirms no MCP ecosystem exists, reinforcing this is out of category rather than a failed capability.", "evidenceIds": [ "babylonjs-probe-rt-2" ] }, { "productId": "babylonjs", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-rt-2" ] }, { "productId": "babylonjs", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-3", "babylonjs-docs-12", "babylonjs-docs-24", "babylonjs-docs-25", "babylonjs-probe-rt-1", "babylonjs-comm-3", "babylonjs-comm-4" ] }, { "productId": "babylonjs", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a client-side 3D rendering engine/library, not a service issuing API credentials or an agent-facing platform with access control; scoped credential issuance is not a fair axis for this product type.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-1", "babylonjs-docs-12", "babylonjs-docs-24", "babylonjs-docs-25", "babylonjs-comm-3", "babylonjs-comm-4", "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a client-side 3D rendering engine/library, not a service or platform with an event/notification backend; webhook subscriptions are a wrong-axis capability for this kind of product.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-3", "babylonjs-docs-7", "babylonjs-docs-18", "babylonjs-probe-1" ] }, { "productId": "babylonjs", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-2", "babylonjs-probe-1" ] }, { "productId": "babylonjs", "storyId": "api-sandbox", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-3", "babylonjs-docs-2", "babylonjs-docs-7", "babylonjs-docs-14", "babylonjs-docs-18" ] }, { "productId": "babylonjs", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-rt-1", "babylonjs-comm-3", "babylonjs-comm-4" ] }, { "productId": "babylonjs", "storyId": "asset-marketplace", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-24", "babylonjs-docs-25", "babylonjs-docs-8", "babylonjs-docs-6", "babylonjs-comm-17", "babylonjs-comm-10", "babylonjs-probe-rt-1", "babylonjs-probe-rt-2" ] }, { "productId": "babylonjs", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-comm-11" ] }, { "productId": "babylonjs", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a 3D rendering/game engine library, not a workflow/job orchestration platform; scheduling recurring jobs or workflows is outside its product category (wrong axis).", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "browser-deployment", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-10", "babylonjs-docs-22", "babylonjs-docs-24", "babylonjs-docs-25", "babylonjs-comm-4", "babylonjs-comm-19", "babylonjs-comm-20" ] }, { "productId": "babylonjs", "storyId": "builtin-physics", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-11", "babylonjs-docs-21", "babylonjs-comm-1", "babylonjs-comm-5", "babylonjs-comm-11" ] }, { "productId": "babylonjs", "storyId": "codegen-friendly-apis", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-1", "babylonjs-comm-3", "babylonjs-comm-4", "babylonjs-comm-7", "babylonjs-probe-rt-2" ] }, { "productId": "babylonjs", "storyId": "collaboration-versioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "dedicated-server-runtime", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-2", "babylonjs-docs-3", "babylonjs-docs-24" ] }, { "productId": "babylonjs", "storyId": "editor-scripting-extensibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-13", "babylonjs-docs-20", "babylonjs-docs-7", "babylonjs-docs-9" ] }, { "productId": "babylonjs", "storyId": "fast-iteration-loop", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-7", "babylonjs-docs-18", "babylonjs-docs-3", "babylonjs-docs-13" ] }, { "productId": "babylonjs", "storyId": "first-class-2d", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-comm-12", "babylonjs-docs-16", "babylonjs-docs-11" ] }, { "productId": "babylonjs", "storyId": "full-scene-editor", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.\nmissing 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.", "evidenceIds": [ "babylonjs-docs-13", "babylonjs-docs-20", "babylonjs-docs-9", "babylonjs-docs-7", "babylonjs-docs-14", "babylonjs-comm-8", "babylonjs-comm-11" ] }, { "productId": "babylonjs", "storyId": "full-source-access", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-rt-1", "babylonjs-comm-6", "babylonjs-comm-8", "babylonjs-comm-11" ] }, { "productId": "babylonjs", "storyId": "headless-cli-builds", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-2", "babylonjs-docs-3", "babylonjs-docs-4", "babylonjs-docs-24", "babylonjs-docs-25", "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "headless-test-runs", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-2", "babylonjs-docs-3", "babylonjs-docs-24" ] }, { "productId": "babylonjs", "storyId": "modern-3d-rendering", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-6", "babylonjs-docs-9", "babylonjs-docs-10", "babylonjs-docs-22", "babylonjs-comm-16" ] }, { "productId": "babylonjs", "storyId": "multi-platform-export", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-15", "babylonjs-docs-10", "babylonjs-docs-22" ] }, { "productId": "babylonjs", "storyId": "npm-installable-runtime", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-1", "babylonjs-docs-24", "babylonjs-docs-25", "babylonjs-docs-12", "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "official-ai-copilot", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-rt-2", "babylonjs-probe-1" ] }, { "productId": "babylonjs", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-2", "babylonjs-docs-3", "babylonjs-docs-9", "babylonjs-docs-13", "babylonjs-docs-19", "babylonjs-docs-24", "babylonjs-docs-25" ] }, { "productId": "babylonjs", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-8", "babylonjs-docs-6", "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "openness-open-license", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "openness-self-host", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-2", "babylonjs-docs-3", "babylonjs-probe-rt-1", "babylonjs-docs-24" ] }, { "productId": "babylonjs", "storyId": "performance-at-scale", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-13", "babylonjs-docs-20", "babylonjs-comm-10", "babylonjs-comm-13", "babylonjs-comm-14" ] }, { "productId": "babylonjs", "storyId": "permissive-license-no-royalties", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "pricing-terms-stability", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "babylonjs-probe-rt-1" ] }, { "productId": "babylonjs", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a client-side rendering/game engine library, not a data-storage or hosted SaaS service; it has no concept of data residency or region selection since it doesn't store user data itself.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a client-side 3D rendering engine/SDK, not an AI model or service that trains on user data; data-training opt-out is not an applicable axis for this kind of product.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a client-side rendering/game engine library, not a data-processing service or SaaS that stores user data on a vendor's behalf; there is no user account or data-retention model for it to control.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is an open-source client-side rendering/game engine library, not a hosted SaaS or service that collects telemetry from its users; there's no product-level telemetry/usage-tracking feature to opt out of, making this axis a category error for this kind of product.", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "productive-scripting-language", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-12", "babylonjs-docs-13", "babylonjs-docs-20", "babylonjs-comm-10", "babylonjs-comm-17" ] }, { "productId": "babylonjs", "storyId": "runtime-ml-inference", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Babylon.js is a rendering/game engine, not an ML/AI inference platform; on-device ML model execution runtime is outside its product category (wrong axis, not a missing feature).", "evidenceIds": [] }, { "productId": "babylonjs", "storyId": "scripted-asset-import", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-2", "babylonjs-docs-3", "babylonjs-docs-6", "babylonjs-docs-8" ] }, { "productId": "babylonjs", "storyId": "standard-asset-formats", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-6", "babylonjs-docs-8", "babylonjs-docs-14", "babylonjs-comm-9" ] }, { "productId": "babylonjs", "storyId": "visual-scripting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "babylonjs-docs-9", "babylonjs-docs-19", "babylonjs-docs-7" ] }, { "productId": "bevy", "storyId": "agent-editor-control", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Bevy has a first-party Bevy Remote Protocol that could support programmatic scene/entity manipulation, and a community tool (bevy_brp) built on it, but there is no official documentation, no llms.txt, and no official MCP server — the community tooling itself is described as nascent (70 stars). Since Bevy is a code-first Rust crate, most 'scripting' is done by writing/recompiling Rust code rather than through a documented runtime scriptable interface for driving an editor. Missing for 10: first-party documented API/schema for the Remote Protocol, official MCP or agent-facing tooling, evidence of hands-on agent use creating scenes/nodes and triggering builds via that interface.", "evidenceIds": [ "bevy-probe-rt-2", "bevy-probe-1", "bevy-docs-8" ] }, { "productId": "bevy", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Direct probes confirm no llms.txt exists (404) and no agent-oriented docs endpoint is served; docs.rs/crates.io provide standard human docs but nothing tailored for agent consumption per the story.", "evidenceIds": [ "bevy-probe-1", "bevy-probe-2", "bevy-probe-rt-2" ] }, { "productId": "bevy", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of headless mode, CI integration, or automated/scripted execution of Bevy apps; only rendering, ECS, editor-live-reload and general community sentiment are covered. Running headless in CI is a reasonable ask for a game engine, but nothing in the pack demonstrates it.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a game engine/Rust library, not an agent — MCP-server integration is a wrong axis for this product category. No evidence of Bevy itself connecting to or hosting MCP servers as a tool-consuming client would even be applicable here.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Bevy is a game engine/library, not itself an AI agent, so an MCP server axis applies as a fair question, but evidence explicitly shows no official MCP server exists — only nascent third-party tooling (bevy_brp) built on the Bevy Remote Protocol. No official MCP server is documented.", "evidenceIds": [ "bevy-probe-rt-2", "bevy-probe-1" ] }, { "productId": "bevy", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Bevy is a Rust game engine/library with no evidence of any natural-language command interface; probes confirm no llms.txt, no MCP server, and only nascent third-party remote-protocol tooling (bevy_brp), not a natural-language control layer.", "evidenceIds": [ "bevy-probe-1", "bevy-probe-2", "bevy-probe-rt-2" ] }, { "productId": "bevy", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of an official Bevy CLI tool anywhere in the evidence pack; only cargo (Rust's generic build tool) and community projects like bevy_brp are mentioned, not a first-party CLI for AI-native workflows.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "agentic-public-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Bevy ships a documented Rust API (in-depth reference docs, docs.rs) and even a first-party 'Bevy Remote Protocol' that a nascent community tool (bevy_brp) uses to drive the engine externally, but there is no AI-oriented public API surface: no llms.txt, no OpenAPI/swagger spec, and no official MCP server, and the remote-protocol tooling is described as nascent/community-only rather than a robust public API for programmatic driving. Missing for 10: an official machine-readable API spec (OpenAPI/llms.txt), first-party remote-control docs beyond community wrappers, and evidence of stable AI-agent usage against the API.", "evidenceIds": [ "bevy-docs-27", "bevy-probe-1", "bevy-probe-3", "bevy-probe-rt-2" ] }, { "productId": "bevy", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a game engine/library, not a service with API credentials or agent-facing auth systems; scoped credential issuance is a wrong axis for this product category.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Bevy itself ships as an official, versioned Rust SDK (the `bevy` crate on crates.io) with first-party API reference docs, quick-start guides, and migration guides, which is what an AI-native developer would build against (bevy-docs-21, bevy-docs-27, bevy-docs-15, bevy-probe-rt-1). However, pre-1.0 status with breaking changes on nearly every release, community complaints about docs being thin once you leave the intro book, and confirmed absence of llms.txt/AI-consumable doc formats make it harder for AI agents to reliably target the 'official SDK' surface (bevy-probe-rt-1, bevy-comm-12, bevy-comm-14, bevy-probe-1, bevy-probe-rt-2). Missing for 10: llms.txt/AI-friendly doc export, stability guarantees across versions, and independent evidence of AI agents successfully building against the SDK.", "evidenceIds": [ "bevy-docs-21", "bevy-docs-27", "bevy-docs-15", "bevy-probe-rt-1", "bevy-comm-12", "bevy-comm-14", "bevy-probe-1", "bevy-probe-rt-2" ] }, { "productId": "bevy", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a Rust game engine/library, not a service or platform with event streams to subscribe to; webhooks are not a relevant integration concept for this kind of product.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Bevy advertises 'in-depth reference documentation, complete with inline examples' and a separate gallery of wasm-compiled examples that run directly in the browser, giving some interactive/runnable exploration of the API surface. But these are two disconnected resources rather than a unified interactive API reference, docs.rs is static/crawlable with no live-run capability, and there's no llms.txt, MCP, or agent-facing interactive console. Missing for 10: a single integrated interactive reference (e.g. rustdoc playground-style 'run' buttons on API docs), agent-facing tooling (llms.txt/MCP) to programmatically explore it, and independent confirmation the wasm examples are tied to the API reference itself.", "evidenceIds": [ "bevy-docs-27", "bevy-docs-16", "bevy-probe-rt-2", "bevy-probe-1" ] }, { "productId": "bevy", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "api-versioning-policy", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Bevy publishes migration guides for each release (bevy-docs-15) implying some versioning discipline, but there is no documented deprecation policy, and hands-on evidence shows the API is pre-1.0 with frequent breaking changes each release requiring real rework (bevy-comm-12, bevy-comm-13, bevy-probe-rt-1), directly undercutting reliability for an AI agent trained on prior APIs. Missing for 10: an explicit deprecation/versioning policy document, semver guarantees, and evidence that breaking changes are flagged/deprecated before removal rather than silently changed.", "evidenceIds": [ "bevy-docs-15", "bevy-comm-12", "bevy-comm-13", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "asset-marketplace", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Bevy explicitly maintains an official third-party 'Assets' page listing community plugins, tools, and learning resources (bevy-docs-17), and community comments confirm an active ecosystem contributing new features and crates (bevy-comm-19). However, this is a curated links page rather than an integrated in-engine asset store, and the ecosystem is described as young/fragmented with docs gaps and frequent breaking changes affecting third-party plugin compatibility (bevy-comm-12, bevy-comm-15). Missing for 10: evidence of a large volume/maturity of ready-made models or marketplace-scale assets, integrated store UI, and quantified ecosystem size or quality assurance for third-party plugins.", "evidenceIds": [ "bevy-docs-17", "bevy-comm-19", "bevy-comm-12", "bevy-comm-15" ] }, { "productId": "bevy", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack describes Bevy's ECS, rendering, audio, and UI features but never mentions an event/trigger/rule system (e.g., Bevy Events, Observers, or ECS hooks) that would let a user define rules firing automatically on events. While such automation is plausible for a game engine's ECS, no evidence in the pack substantiates it.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a Rust game engine/ECS framework; scheduling recurring jobs or workflows is not a category concept it addresses (its 'schedules' are ECS system execution ordering per frame, not automation/cron-like recurring workflows). This axis is a category error for a game engine.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "browser-deployment", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Bevy documents official Web platform support and showcases live wasm-compiled examples running in-browser, and a community comment shows real interest in adopting Bevy specifically for web/mobile targets. However, the evidence never mentions WebGPU explicitly, payload size/optimization guidance, or any hands-on report of browser performance/bundle size — the WebGPU 'credible story' half of the claim is unevidenced. Missing for 10: explicit WebGPU backend documentation or roadmap, payload-size/optimization guidance, and independent hands-on confirmation of web build performance.", "evidenceIds": [ "bevy-docs-6", "bevy-docs-16", "bevy-comm-20" ] }, { "productId": "bevy", "storyId": "builtin-physics", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers ECS, rendering, audio, UI, and scenes but contains no mention of physics, rigid bodies, collision detection, or raycasting capabilities. Built-in physics is a fair question for a game engine's core-engine axis, but nothing in the docs or community evidence shows Bevy ships this out of the box.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "codegen-friendly-apis", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Bevy has abundant examples and reference docs (bevy-docs-16, bevy-docs-22, bevy-docs-27) which help LLM familiarity, but concrete community evidence shows the API is unstable pre-1.0 with breaking changes almost every release, requiring real migration work each time (bevy-comm-12, bevy-comm-13, bevy-probe-rt-1) — meaning LLMs trained on older versions likely generate code that fails to compile against current APIs. Docs are also reported as thin/outdated relative to the pace of change (bevy-comm-14, bevy-comm-15), and there's no llms.txt or first-party AI-consumption docs (bevy-probe-1, bevy-probe-rt-2). missing for 10: evidence of first-try success rate for LLM-generated Bevy code, stable API surface across versions, and first-party AI-friendly documentation.", "evidenceIds": [ "bevy-comm-12", "bevy-comm-13", "bevy-comm-14", "bevy-comm-15", "bevy-probe-rt-1", "bevy-probe-rt-2", "bevy-docs-22" ] }, { "productId": "bevy", "storyId": "collaboration-versioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence mentions a Scene system for saving/loading ECS worlds (bevy-docs-8) but nothing about its text format being diffable/mergeable, nor any built-in multi-user collaboration tooling. The 'code-first' workflow noted in bevy-probe-rt-2 is framed around agent-driven development, not team version-control workflows, so it doesn't substantiate this story.", "evidenceIds": [ "bevy-docs-8", "bevy-probe-rt-2" ] }, { "productId": "bevy", "storyId": "dedicated-server-runtime", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers Bevy's ECS, rendering, UI, audio, and platform support, but contains no mention of a headless/dedicated-server build mode, disabling rendering plugins, or server-runtime configuration. Since this is a plausible and common need for a game engine, absence of evidence means the axis is unmet rather than inapplicable.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "editor-scripting-extensibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Bevy's evidence shows only a code-first workflow (ECS, scenes, plugins) and mentions no official editor application to extend; the closest hint is a third-party 'bevy_brp' remote-protocol tool with just 70 stars, not first-party editor scripting/plugin support for manipulating scenes and assets. missing for 10: any first-party editor product, documented editor scripting/plugin API, or mature ecosystem tooling for automating scene/asset manipulation via an editor UI.", "evidenceIds": [ "bevy-probe-rt-2", "bevy-docs-8" ] }, { "productId": "bevy", "storyId": "fast-iteration-loop", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Bevy's own docs directly claim 'instant feedback on your changes without app restarts or recompiles' and cite very fast compile times (0.8–3.0s) with a 'fast compiles' config, which matches the story's intent. However, Bevy is a Rust-native engine (not script-based), so this reload speed is achieved via build tooling/dynamic linking rather than a true scripting hot-reload workflow, and there is no independent/hands-on community confirmation of this specific edit-run loop experience — community comments focus on ECS ergonomics, docs quality, and breaking changes instead. Missing for 10: independent/hands-on verification of the hot-reload claim, clarity on scripting vs. Rust recompilation semantics, and community testimony specifically about iteration speed.", "evidenceIds": [ "bevy-docs-10", "bevy-docs-11", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "first-class-2d", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Bevy's official docs explicitly list 2D rendering as a first-class feature alongside 3D (bevy-docs-2, bevy-docs-3), suggesting parity rather than a 3D-only focus, and community feedback confirms active engine use for real projects. However, there is no evidence in the pack of built-in tilemap support or first-party 2D physics (these are known to be third-party crates in the Bevy ecosystem), so the story's specific claims about tilemaps and 2D physics being first-class are unconfirmed. Missing for 10: evidence of native/first-party tilemap support, evidence of native/first-party 2D physics integration, and any community confirmation of 2D-specific workflow maturity.", "evidenceIds": [ "bevy-docs-2", "bevy-docs-3", "bevy-docs-23" ] }, { "productId": "bevy", "storyId": "full-scene-editor", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Bevy's evidence describes a code-first Rust ECS engine (components, systems, scenes-as-data, hot reloading) but nothing about a visual editor with viewport, inspector, or prefab/scene composition UI; comment bevy-comm-8 even suggests users hope NOT to be forced into an in-engine editor, and probes show no official tooling filling this gap. Missing for full/partial credit: any first-party viewport/inspector GUI, prefab authoring workflow, or scene-composition editor.", "evidenceIds": [ "bevy-docs-8", "bevy-docs-10", "bevy-comm-8" ] }, { "productId": "bevy", "storyId": "full-source-access", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Bevy is fully open-source (MIT/Apache 2.0), with source hosted openly, allowing developers to read and modify the engine itself; community confirms code is clean/readable and license is unrestricted ('no strings attached'). Missing for 10: no explicit hands-on account of a developer patching/forking the engine source to unblock themselves, only license and code-quality corroboration.", "evidenceIds": [ "bevy-docs-18", "bevy-docs-25", "bevy-docs-28", "bevy-comm-1", "bevy-comm-2", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "headless-cli-builds", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Bevy is a code-first Rust library built and run via cargo, with no mandatory editor (bevy-docs-21, bevy-comm-8, bevy-probe-rt-2), which inherently supports command-line/CI builds. However, there is no explicit documentation of a headless mode flag, export pipeline, or CI-specific tooling/examples, and no official CI templates or GitHub Actions references are present in the evidence pack. missing for 10: explicit headless-mode/export documentation, CI pipeline examples or templates, and confirmation of asset-building/export automation without a GUI step.", "evidenceIds": [ "bevy-docs-21", "bevy-comm-8", "bevy-probe-rt-2", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "headless-test-runs", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of headless mode, CI test execution, integration testing, or automated test frameworks for Bevy game logic — nothing about running engine/game tests without a display or in continuous integration.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "modern-3d-rendering", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm a 'modern and flexible 3D renderer' with extensible custom shaders/materials/pipelines, and community hands-on feedback confirms shadows exist (though called 'jagged/low-res, reminds me of early Unity shadows'). However, the evidence pack never mentions global illumination, baked lighting, or a post-processing stack explicitly. Missing for 10: explicit documentation of GI/baked lighting support, explicit post-processing feature list, and independent corroboration of PBR material quality beyond the shadow-quality caveat.", "evidenceIds": [ "bevy-docs-3", "bevy-docs-23", "bevy-comm-11" ] }, { "productId": "bevy", "storyId": "multi-platform-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm one Bevy project can target desktop (Windows/macOS/Linux), mobile (iOS/Android) and Web via a single codebase [bevy-docs-6], and community feedback corroborates real-world mobile/web use [bevy-comm-10][bevy-comm-20]. However, there is no evidence—first-party or community—of console export capability, whether direct or via third-party porting partners, which is a key part of the story. Missing for 10: any mention of console targets (Switch/PlayStation/Xbox), official or partner-based console export tooling, or case studies of console shipping.", "evidenceIds": [ "bevy-docs-6", "bevy-comm-10", "bevy-comm-20" ] }, { "productId": "bevy", "storyId": "npm-installable-runtime", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Bevy is distributed exclusively as a Rust crate via crates.io/cargo (bevy-docs-21, bevy-probe-rt-1), not as an npm/JS package; its 'Web' platform support (bevy-docs-6) means compiling to WASM as a game binary, not shipping a tree-shakeable JS library a web developer imports and bundles. No evidence shows npm registry presence, ES-module packaging, or tree-shaking support.", "evidenceIds": [ "bevy-docs-21", "bevy-docs-6", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "official-ai-copilot", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Bevy is a Rust game engine/library with no evidence of an official in-engine AI assistant; probes confirm no llms.txt, no official MCP, and only nascent third-party tooling (bevy_brp).", "evidenceIds": [ "bevy-probe-1", "bevy-probe-rt-2" ] }, { "productId": "bevy", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence documents Bevy's open-source MIT/Apache-2.0 licensing and community activity, but nothing about a governing foundation, published finances, or an official public roadmap a studio could plan against — only migration guides for past releases are mentioned. missing for 10: evidence of a foundation or legal entity, published budget/financials, and a forward-looking public roadmap.", "evidenceIds": [ "bevy-docs-18", "bevy-docs-25", "bevy-docs-15", "bevy-comm-19" ] }, { "productId": "bevy", "storyId": "openness-api-parity", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "bevy", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Bevy is a local, open-source Rust engine (MIT/Apache-2.0) with no cloud data lock-in, and its Scene system lets you save/load ECS worlds in the open RON format, which aligns with the openness theme. However there's no explicit documentation or tooling framed around 'exporting all your data and leaving' (e.g., data migration guides, guaranteed format stability) since Bevy isn't a hosted service holding user data in the first place. Missing for 10: explicit data-export/migration documentation, guarantees around long-term format stability given breaking API changes each release, and any first-party statement on data portability beyond the general OSS license.", "evidenceIds": [ "bevy-docs-8", "bevy-docs-18", "bevy-docs-25", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "openness-open-license", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Bevy's source and docs are explicitly MIT OR Apache-2.0 licensed, confirmed both by first-party docs and independent runtime crates.io metadata, and community commenters corroborate the open, permissive licensing and code readability. Missing for 10: no direct GitHub repo citation in the evidence pack, though license and source availability are otherwise well-documented.", "evidenceIds": [ "bevy-docs-18", "bevy-docs-25", "bevy-comm-2", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "openness-self-host", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Bevy is not a hosted service at all — it's an open-source (MIT/Apache-2.0) Rust library added directly as a dependency to your own project and compiled/run entirely on your own machine, satisfying self-hosting by default with no server or cloud dependency (bevy-docs-18, bevy-docs-21, bevy-docs-25). Community corroboration confirms the open license and local dev workflow (bevy-comm-2). missing for 10: explicit vendor-authored self-hosting/deployment guidance (e.g., docs discussing running Bevy apps as self-hosted servers or headless builds) and independent verification of self-hosted production deployments.", "evidenceIds": [ "bevy-docs-18", "bevy-docs-21", "bevy-docs-25", "bevy-comm-2" ] }, { "productId": "bevy", "storyId": "performance-at-scale", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Bevy's data-oriented ECS is well documented as the foundation for all engine/game logic (bevy-docs-1, bevy-docs-14, bevy-docs-20), and community accounts corroborate its data-driven, ECS-first workflow (bevy-comm-17). However, the evidence pack contains no mention of a built-in profiler/diagnostics tool, explicit job/parallel-system scheduling, or GPU instancing for heavy scenes — core parts of the story. Missing for 10: dedicated profiler tooling (e.g. tracing/diagnostics plugin), explicit job-system/parallelism documentation, and instancing support evidence.", "evidenceIds": [ "bevy-docs-1", "bevy-docs-14", "bevy-docs-20", "bevy-comm-17" ] }, { "productId": "bevy", "storyId": "permissive-license-no-royalties", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Bevy's own site explicitly states it is 100% free forever, MIT OR Apache-2.0 licensed, with no contracts, no license fees, and no sales cuts, directly satisfying the studio-lead's ask of no royalties or per-install fees. This is corroborated independently by crates.io license metadata and by community commentary praising the permissive MIT licensing as 'no strings attached.' Missing for 10: no explicit legal/contract analysis or enterprise-scale case study confirming zero royalty obligations at large studio scale.", "evidenceIds": [ "bevy-docs-25", "bevy-docs-18", "bevy-comm-2", "bevy-probe-rt-1" ] }, { "productId": "bevy", "storyId": "pricing-terms-stability", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Bevy is licensed under MIT/Apache 2.0 with explicit 'no contracts, no license fees, no sales cuts, forever' commitments, and these are irrevocable open-source licenses that cannot retroactively reprice already-shipped games — corroborated by community praise for the license having 'no strings attached.' Missing for 10: a long multi-year track record (Bevy is a young, pre-1.0 project) and any explicit governance statement committing to never relicense future versions restrictively.", "evidenceIds": [ "bevy-docs-25", "bevy-docs-18", "bevy-comm-2" ] }, { "productId": "bevy", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a game engine library/SDK, not a hosted data service; it doesn't store user data on servers, so 'data residency' is a category error for this product type.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a game engine/framework, not a data-processing or AI service that trains models on user data; the axis of preventing personal data from being used for AI training does not apply to this product category.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a game engine/library, not a data-processing service that collects or retains user data; data retention/deletion controls are not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is an open-source, self-hosted game engine library with no SaaS telemetry service; there's no evidence of any usage-tracking/phone-home mechanism to opt out of, and this axis is a category error for a locally-run engine/framework rather than a hosted product with telemetry collection.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "productive-scripting-language", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Bevy uses plain Rust as its 'scripting' layer, and docs plus community comments confirm the ECS API is idiomatic, fully native Rust with no macros/lifetimes needed (bevy-docs-14, bevy-docs-20, bevy-comm-3, bevy-comm-4), which is a strong productivity/API-exposure signal. However, there is no evidence at all of a dedicated debugger or debugging workflow behind this scripting layer, and community feedback flags limited/out-of-date docs and frequent breaking changes as productivity friction (bevy-comm-14, bevy-comm-15, bevy-comm-12). Missing for 10: explicit debugger/debugging-tool evidence, confirmation of full API surface coverage beyond ECS basics, and independent hands-on accounts of debugging Bevy games.", "evidenceIds": [ "bevy-docs-14", "bevy-docs-20", "bevy-comm-3", "bevy-comm-4", "bevy-comm-14", "bevy-comm-15", "bevy-comm-12" ] }, { "productId": "bevy", "storyId": "runtime-ml-inference", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Bevy is a game engine focused on ECS, rendering, audio, UI, and asset management; on-device ML inference runtimes are outside its core product category and no evidence suggests otherwise.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "scripted-asset-import", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Bevy's Asset V2 system does support preprocessing and .meta files, which one community commenter calls 'super useful' for pipeline automation, but no first-party docs describe import hooks, presets, or scripting workflows for batch/automated asset processing. missing for 10: official documentation on asset import hooks/presets, evidence of scripted/batch pipeline tooling, and independent confirmation beyond a single community mention.", "evidenceIds": [ "bevy-comm-18" ] }, { "productId": "bevy", "storyId": "standard-asset-formats", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack mentions glTF, FBX, USD, or any interchange-format import/asset-pipeline support; only glTF is a commonly known Bevy asset format but it's not cited here. Missing for 10: any docs or community mention of glTF/FBX/USD import, format fidelity, or asset-pipeline tooling.", "evidenceIds": [] }, { "productId": "bevy", "storyId": "visual-scripting", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Bevy is explicitly a code-first, Rust-based ECS engine (bevy-docs-1, bevy-docs-14, bevy-docs-20, bevy-docs-21) with no mention of a visual scripting system or node-based logic editor anywhere in the evidence; community feedback even discusses concerns about being forced into a code editor, reinforcing the code-only workflow.", "evidenceIds": [ "bevy-docs-1", "bevy-docs-14", "bevy-docs-20", "bevy-docs-21", "bevy-comm-8" ] }, { "productId": "godot", "storyId": "agent-editor-control", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Godot documents multiple genuine programmatic surfaces — GDScript/C# scripting, EditorScript for in-editor automation, EditorPlugin for extending the editor, and a full command-line interface supporting headless mode and export/build triggering — which together let a script or external process create scenes/nodes, edit properties, and build. However these are general-purpose developer APIs, not an agent-oriented interface, and there is no official MCP server or agent-facing wrapper (GitHub search found zero official MCP results, llms.txt 404s, only community MCP projects of varying activity). Missing for 10: an official/first-party agent-facing API or MCP server, and independent hands-on evidence of an agent actually driving the editor end-to-end via these interfaces.", "evidenceIds": [ "godot-docs-3", "godot-docs-4", "godot-docs-5", "godot-docs-13", "godot-docs-14", "godot-probe-4", "godot-probe-rt-1", "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Explicit probes show no llms.txt (404 at docs.godotengine.org/llms.txt), no .md doc mirrors, and no agent-oriented docs endpoint; the only doc format is standard human-facing HTML documentation.", "evidenceIds": [ "godot-probe-1", "godot-probe-2", "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "godot", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Godot's headless CLI mode and EditorScript/plugin system let scripts run without the GUI (e.g., for CI builds/exports), which can be wired into external schedulers or automation pipelines, but there is no built-in agent/automation-scheduling framework or AI-native background-task system documented. missing for 10: native scheduling/trigger system, evidence of persistent background agents, AI-specific automation hooks, independent confirmation of autonomous unattended runs beyond CI export scripts.", "evidenceIds": [ "godot-probe-rt-1", "godot-docs-3", "godot-docs-5", "godot-docs-4" ] }, { "productId": "godot", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "godot", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Godot documents an official CLI for command-line work and headless operation is explicitly confirmed via runtime probe (`godot --headless` for CI builds, exports, and scripted editor automation), plus EditorScript for scripted automation and one-click exports supporting CI pipelines. Missing for 10: no first-party CI/CD documentation or GitHub Actions template explicitly walking through a CI setup, and no independent hands-on report confirming headless CI use in the wild.", "evidenceIds": [ "godot-docs-3", "godot-docs-12", "godot-docs-5", "godot-docs-14", "godot-gh-1", "godot-probe-4", "godot-probe-rt-1" ] }, { "productId": "godot", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "There is no evidence Godot itself can consume MCP servers as a client to use their tools; the probe shows no official MCP integration exists (0 results searching GitHub org, no llms.txt), only unofficial third-party community projects like godot-mcp and godot-ai, which expose Godot's editor as an MCP *server* for external agents to control, not Godot acting as an MCP client consuming external tools.", "evidenceIds": [ "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence explicitly shows no official Godot MCP server exists (GitHub org search for 'mcp' returns 0 results, no llms.txt, no official endpoint); only third-party community MCP projects exist. The axis applies since Godot could plausibly ship an official MCP integration for editor automation, but no such first-party offering is documented.", "evidenceIds": [ "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows only conventional scripting (GDScript, C#), CLI tooling, and editor plugin APIs — none of which constitute natural-language command operation. No official MCP server or NL interface exists (GitHub search for org:godotengine mcp returns 0 results), and only unofficial third-party community MCP projects (godot-mcp, godot-ai) exist, which are not part of the product itself.", "evidenceIds": [ "godot-docs-3", "godot-probe-4", "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "high", "rationale": "Godot ships an official command-line interface (godot binary with --headless, export, script-run flags) documented extensively and confirmed via runtime probe, enabling scripted/agentic automation such as CI builds and exports. Missing for 10: no AI-specific CLI features (e.g., structured/agent-friendly output modes), no independent hands-on validation of CLI scripting workflows beyond docs, and no llms.txt or machine-readable docs mirror.", "evidenceIds": [ "godot-docs-3", "godot-docs-12", "godot-probe-4", "godot-probe-rt-1" ] }, { "productId": "godot", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Godot exposes a documented, scriptable surface (command-line/headless mode, EditorScript for in-editor automation, full GDScript/C# class API, and a keyless JSON Asset Library API) that an agent could drive programmatically, per godot-docs-3/5/12/14 and godot-probe-rt-1/2. However this is a traditional engine API/CLI, not an AI-native interface: probes confirm no llms.txt, no OpenAPI spec, and no official MCP server (godot-probe-1/2/3, godot-probe-rt-3), leaving only third-party community MCP wrappers of uneven maintenance. Missing for 10: an official machine-readable API spec (OpenAPI/llms.txt) and a first-party MCP or agent-oriented interface layer.", "evidenceIds": [ "godot-docs-3", "godot-docs-5", "godot-docs-12", "godot-docs-14", "godot-probe-rt-1", "godot-probe-rt-2", "godot-probe-1", "godot-probe-2", "godot-probe-3", "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Godot is a game engine/editor with no concept of API credentials or agent authentication scopes; issuing scoped least-privilege API credentials for an agent is a category error for this product type, not a missing feature.", "evidenceIds": [] }, { "productId": "godot", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Godot ships official, well-documented SDKs/language bindings — GDScript, C# via .NET, and GDExtension/C++ — plus a command-line interface and a queryable Asset Library JSON API, all of which an AI-native developer could build against (godot-docs-1, godot-docs-2, godot-docs-8, godot-docs-3, godot-probe-rt-2). However, there is no AI/agent-specific SDK, no official MCP server, and no machine-readable docs (llms.txt/.md mirrors return 404), with only unofficial community MCP projects filling that gap. Missing for 10: an official AI-agent SDK or MCP server, machine-readable/llms.txt documentation, and first-party AI integration tooling.", "evidenceIds": [ "godot-docs-1", "godot-docs-2", "godot-docs-8", "godot-docs-3", "godot-probe-rt-2", "godot-probe-rt-3", "godot-probe-1" ] }, { "productId": "godot", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Godot is a game engine/editor, not a service or platform that emits external events over HTTP; webhook subscription is not a fair capability question for this product category, and no evidence pack item suggests such a feature.", "evidenceIds": [] }, { "productId": "godot", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Godot ships extensive static class/API reference docs (godot-docs-1–17) but none of the evidence shows an interactive reference with runnable/executable code examples (no REPL, playground, or in-browser code execution is mentioned), and probes confirm no llms.txt, no OpenAPI spec, and no .md-mirrored interactive docs.", "evidenceIds": [ "godot-docs-1", "godot-docs-2", "godot-probe-1", "godot-probe-2", "godot-probe-3" ] }, { "productId": "godot", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Godot is a game engine, not a web/service API, but the story is about whether a machine-readable API spec (OpenAPI or equivalent) can be downloaded — probes explicitly show no OpenAPI/swagger endpoints exist (all 404s) and no llms.txt equivalent either, so the applicable axis yields no evidence of delivery.", "evidenceIds": [ "godot-probe-3", "godot-probe-1", "godot-probe-2", "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "godot", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of a versioned API policy or deprecation schedule for Godot's scripting/engine APIs (GDScript, C#, GDExtension); community notes only mention version differences (3.5.2 LTS vs 4.0) informally, not a documented deprecation policy. Since engine APIs could plausibly have such policies, absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [ "godot-comm-11" ] }, { "productId": "godot", "storyId": "asset-marketplace", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Godot ships an official Asset Library with categorized listings (2D/3D Tools, Shaders, Materials, Scripts, Templates, Projects, Demos) and a public JSON API for querying it, directly matching the asset-store/package-ecosystem story. Missing for 10: independent evidence of the store's actual scale/quality (e.g. asset counts, community praise of the marketplace itself) and any third-party commentary comparing it to competitor stores.", "evidenceIds": [ "godot-docs-11", "godot-probe-rt-2" ] }, { "productId": "godot", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Godot supports batch editing of import parameters across multiple assets (godot-docs-15), EditorScript for custom in-editor automation (godot-docs-5/14), and CLI/headless scripting for automated workflows (godot-docs-3/12), which together enable some bulk operations. However there's no dedicated bulk-editing API, no evidence of scripted bulk scene/node manipulation at scale, and no AI-native tooling or examples of large-scale automated bulk operations. Missing for 10: dedicated bulk-edit API/tooling, documented examples of scripted bulk operations across many scenes/nodes, AI-agent-oriented automation examples, independent corroboration of bulk-operation workflows.", "evidenceIds": [ "godot-docs-15", "godot-docs-5", "godot-docs-14", "godot-docs-3", "godot-docs-12" ] }, { "productId": "godot", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers GDScript, C#, plugins, EditorScript, and CLI tooling, but never mentions Godot's signal/event system or any explicit mechanism for defining rules that auto-trigger actions on events; without a citable capability, this is unsupported. missing for 10: any documentation of signals/event-connection APIs, examples of automated rule-triggering, or AI-oriented automation hooks.", "evidenceIds": [] }, { "productId": "godot", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Godot is a game engine/editor, not an automation or workflow-orchestration platform; scheduling recurring jobs or workflows is not a fair axis for this product category (its 'CLI' and editor scripts support build/export tooling, not job scheduling).", "evidenceIds": [] }, { "productId": "godot", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "godot", "storyId": "browser-deployment", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Evidence confirms Godot supports one-click export to Web platforms (godot-gh-1) and community reports web export working well for GDScript-based projects in the 3.x LTS line (godot-comm-11), but a community report specifically flags that C#/.NET export to web does not work (godot-comm-5), and there is no evidence at all in the pack addressing WebGPU support, payload size optimization, or a build pipeline story for it. Missing for 10: WebGPU backend documentation/evidence, payload-size guidance, and clarity on C# web-export limitations vs GDScript.", "evidenceIds": [ "godot-gh-1", "godot-comm-5", "godot-comm-11" ] }, { "productId": "godot", "storyId": "builtin-physics", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of Godot's physics system, rigid bodies, collision detection, or raycasting APIs — only general engine features like 2D rendering, node/scene system, scripting, and export tooling are cited. Absence of evidence for this applicable core-engine capability means it cannot be credited as full/partial.", "evidenceIds": [] }, { "productId": "godot", "storyId": "codegen-friendly-apis", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Godot's GDScript/C# APIs are extensively documented (godot-docs-1/2) and the engine has a large public codebase/asset library that could supply LLM training examples, but there is no direct evidence about LLM-generated code success rates, and community reports note documentation gaps in the past and major GDScript/API syntax breaks between Godot 3 and 4 (godot-comm-11, godot-comm-14, godot-comm-15) that would fragment what models have seen. missing for 10: direct evidence of LLM code-generation success, confirmation that version-specific API drift (3.x vs 4.x GDScript) doesn't cause mismatched generations, independent benchmarks of first-try correctness.", "evidenceIds": [ "godot-docs-1", "godot-docs-2", "godot-comm-11", "godot-comm-14", "godot-comm-15" ] }, { "productId": "godot", "storyId": "collaboration-versioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of Godot's text-based .tscn/.tres scene format, scene diffability, merge-friendly project files, or built-in team-collaboration tooling — only general references to the node/scene system, asset import pipeline, and PR review practices for the engine's own codebase, none of which address version-control friendliness of authored projects.", "evidenceIds": [] }, { "productId": "godot", "storyId": "dedicated-server-runtime", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Runtime evidence confirms Godot ships a `--headless` flag used for CI builds, exports, and scripted automation, and official docs describe extensive command-line/editor-less workflows (godot-probe-rt-1, godot-docs-3/12). However, the evidence pack lacks first-party documentation specifically covering dedicated-server export templates or headless runtime performance/behavior details beyond the CLI tutorial. Missing for 10: dedicated first-party docs on server export templates, detailed headless runtime behavior, and independent hands-on confirmation of headless server deployment at scale.", "evidenceIds": [ "godot-probe-rt-1", "godot-docs-3", "godot-docs-12" ] }, { "productId": "godot", "storyId": "editor-scripting-extensibility", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Godot has first-party, well-documented mechanisms for editor extension: EditorPlugin/plugin system for custom scenes/asset manipulation without reloading the editor, EditorScript for scripted one-off editor automation runnable via Ctrl+Shift+X, and a CLI/headless mode enabling scripted automation of the editor itself. The Asset Library also hosts many community editor tool plugins, corroborating a real ecosystem. missing for 10: no independent hands-on report specifically validating plugin/EditorScript workflows (community evidence is about the engine generally, not editor scripting extensibility).", "evidenceIds": [ "godot-docs-4", "godot-docs-5", "godot-docs-13", "godot-docs-14", "godot-docs-3", "godot-docs-11", "godot-probe-rt-1" ] }, { "productId": "godot", "storyId": "fast-iteration-loop", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence shows editor plugins can be built in GDScript without reloading the editor (godot-docs-4/13) and Godot's scene/node system supports live editing, implying reasonably fast iteration, but there is no direct documentation or community confirmation of hot-reloading running gameplay scripts or near-instant preview after a script change during play mode. missing for 10: explicit docs on script hot-reload during play, independent hands-on confirmation of edit-run loop speed for gameplay code, comparison benchmarks.", "evidenceIds": [ "godot-docs-4", "godot-docs-13", "godot-docs-5", "godot-docs-14" ] }, { "productId": "godot", "storyId": "first-class-2d", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "First-party docs explicitly market Godot's 'dedicated 2D rendering engine with real 2D pixel coordinates and 2D nodes,' distinguishing 2D as first-class rather than a 3D afterthought, and the asset library segments 2D vs 3D tools, reinforcing separate 2D-focused workflows. Community threads corroborate Godot's strength and ease relative to competitors for indie/2D-style projects, though none specifically praise tilemaps or 2D physics. Missing for 10: explicit documentation/evidence on TileMap editor and 2D physics engine (Box2D-like) specifics, and independent hands-on confirmation of 2D-specific workflow quality.", "evidenceIds": [ "godot-docs-7", "godot-docs-11", "godot-docs-6", "godot-comm-16" ] }, { "productId": "godot", "storyId": "full-scene-editor", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Godot's core identity is a visual editor built around a Node/Scene composition system (scenes act as prefabs), inspector for property editing, and viewport for level/scene building, well documented across docs (scene system, import pipeline, plugins extending editor tools) and corroborated by community users praising it as 'a visual editor but still be able to code' compared favorably to more code-heavy alternatives. missing for 10: no dedicated hands-on walkthrough of viewport/inspector UI specifics or prefab-equivalent scene-instancing workflow details, and some community comments note friction for beginners with non-visual-scripting workflows.", "evidenceIds": [ "godot-docs-6", "godot-docs-9", "godot-docs-4", "godot-comm-16", "godot-comm-2" ] }, { "productId": "godot", "storyId": "full-source-access", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Godot is MIT-licensed open source, with full source available on GitHub, permissive rights to use/modify/redistribute per the license page, and an active core team accepting PRs/code reviews from contributors — directly enabling developers to read and modify engine internals when needed. missing for 10: no explicit evidence pack citation of the exact source-code repo browsing/build docs beyond compilation instructions link.", "evidenceIds": [ "godot-gh-2", "godot-docs-16", "godot-gh-3", "godot-comm-1" ] }, { "productId": "godot", "storyId": "headless-cli-builds", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Godot documents a full command-line workflow for editing, building, and exporting projects without opening the GUI editor, and the runtime probe confirms `godot --headless` is usable for CI builds/exports/scripted automation. This is well-documented first-party capability and corroborated by an independent runtime check. Missing for 10: no independent third-party CI pipeline case study or hands-on report confirming headless export works flawlessly in a real CI environment.", "evidenceIds": [ "godot-docs-3", "godot-docs-12", "godot-probe-4", "godot-probe-rt-1" ] }, { "productId": "godot", "storyId": "headless-test-runs", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Godot explicitly supports headless CLI operation (`godot --headless`) for automation and scripted editor tasks, and documents command-line workflows and EditorScript execution, which are prerequisites for CI test runs against the real engine. However, there is no evidence of an official unit/integration testing framework (e.g., GUT) or documented CI test-runner examples/integration in the evidence pack. Missing for 10: official testing framework docs, CI pipeline examples, evidence of test-result reporting from headless runs.", "evidenceIds": [ "godot-probe-rt-1", "godot-docs-3", "godot-docs-12", "godot-docs-5", "godot-docs-14" ] }, { "productId": "godot", "storyId": "modern-3d-rendering", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents Godot's 2D rendering engine explicitly (godot-docs-7) but contains no mention of a 3D renderer, PBR materials, global illumination/baked lighting, shadows, or post-processing pipeline anywhere in the docs, GitHub, or community citations.", "evidenceIds": [ "godot-docs-7", "godot-docs-6" ] }, { "productId": "godot", "storyId": "multi-platform-export", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Godot's official GitHub description explicitly states one-click export to desktop (Linux/macOS/Windows), mobile (Android/iOS), web, and consoles from a single project, matching the studio-lead's cross-platform export need, and the license docs/MIT confirm no barriers to shipping across platforms. No community evidence contradicts console or desktop/mobile export capability. Missing for 10: independent/hands-on confirmation of console export specifically (which in practice goes through third-party console partners), and more detail on the partner/porting process for consoles beyond the single GitHub line.", "evidenceIds": [ "godot-gh-1", "godot-docs-16", "godot-gh-2" ] }, { "productId": "godot", "storyId": "npm-installable-runtime", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "godot", "storyId": "official-ai-copilot", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any official AI assistant built into the Godot editor for generating scripts, answering API questions, or scaffolding scenes; the evidence pack only shows scripting languages, plugins, CLI tools, and asset import pipelines — plus explicit probes confirming no official MCP/AI integration exists and only unofficial community projects (e.g., godot-mcp, godot-ai) fill the gap.", "evidenceIds": [ "godot-probe-rt-3" ] }, { "productId": "godot", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains license info (MIT) and community remarks about core-team PR management, but no evidence of a governing foundation, published financial reports, or a public roadmap that a studio lead could plan against. missing for 10: foundation/legal-entity documentation, published financial statements or funding sources, public roadmap or release-planning documentation.", "evidenceIds": [ "godot-gh-2", "godot-comm-1", "godot-comm-12" ] }, { "productId": "godot", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Godot documents extensive CLI/headless operation, EditorScript for scripting editor actions, and GDScript-based plugins that extend the editor 'without even reloading' it — strong evidence of doing much editor work via API/script rather than UI. However, there is no explicit documentation or claim of full UI/API parity, and no independent confirmation that every UI-only feature has a scripting equivalent. Missing for 10: an explicit full API-UI parity guarantee, independent verification that all editor features are scriptable, and evidence of official OpenAPI/MCP-style programmatic surface (probes show none exists).", "evidenceIds": [ "godot-docs-3", "godot-docs-4", "godot-docs-5", "godot-probe-4", "godot-probe-rt-1" ] }, { "productId": "godot", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Godot's MIT license and 'free for any purpose' policy (godot-gh-2, godot-docs-16) mean there's no vendor lock-in, and the asset pipeline docs show raw source assets live in the project folder while only imported caches sit in a hidden .godot folder (godot-docs-9, godot-docs-17), implying user data stays in accessible files. However, there's no explicit documentation of a dedicated 'export all your data' or project-portability feature, nor confirmation that all internal formats (e.g. binary .tscn/.res variants) are fully open/documented. Missing for 10: explicit docs on project file format openness/portability guarantees, a documented data-export or migration tool, and independent corroboration that users can fully extract and reuse their data outside Godot.", "evidenceIds": [ "godot-gh-2", "godot-docs-16", "godot-docs-9", "godot-docs-17" ] }, { "productId": "godot", "storyId": "openness-open-license", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Godot is MIT-licensed and open source, with the full source hosted publicly on GitHub and license terms explicitly documented ('completely free and open source under the very permissive MIT license', 'You are free to use Godot Engine, for any purpose'); community evidence corroborates active open contribution/review processes. missing for 10: no independent audit or license-scan citation beyond vendor/GitHub statements.", "evidenceIds": [ "godot-gh-2", "godot-docs-16", "godot-comm-1" ] }, { "productId": "godot", "storyId": "openness-self-host", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Godot is MIT-licensed, fully open source, and can be self-hosted/self-compiled on any infrastructure the user controls, with headless CLI operation documented for CI/scripted use and confirmed by runtime probes (keyless Homebrew install, --headless mode). missing for 10: no first-party managed self-hosted server/cloud offering docs beyond generic compile-and-run instructions.", "evidenceIds": [ "godot-gh-2", "godot-docs-16", "godot-gh-3", "godot-docs-3", "godot-probe-4", "godot-probe-rt-1" ] }, { "productId": "godot", "storyId": "performance-at-scale", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of Godot's built-in profiler, ECS, job/threading system, or MultiMesh/instancing APIs for scaling heavy scenes; only a community note that hitting high framerates may require dropping to C++/GDExtension, which doesn't confirm profiling or data-oriented tooling. missing for 10: evidence of a real profiler UI, ECS support, job/threading system, and instancing APIs for scaling.", "evidenceIds": [ "godot-comm-10" ] }, { "productId": "godot", "storyId": "permissive-license-no-royalties", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Godot is MIT-licensed, explicitly described as 'completely free and open source... no royalties, nothing' and 'free to use for any purpose,' with community corroboration noting no forced splash screen requirement unlike Unity. Missing for 10: no explicit discussion of edge cases like trademark/logo usage restrictions or third-party asset licensing nuances.", "evidenceIds": [ "godot-gh-2", "godot-docs-16", "godot-comm-13" ] }, { "productId": "godot", "storyId": "pricing-terms-stability", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Godot ships under the permissive MIT license with no royalties and no required attribution splash, and since it's a community-governed open-source project (not a single commercial vendor), there's no entity that could retroactively reprice shipped games — MIT terms apply perpetually to released versions. Community commentary explicitly contrasts this with Unity's runtime-fee model requiring payment/splash screens.\n\nmissing for 10: no explicit independent commentary tracing Godot's licensing history over multiple years to confirm zero retroactive changes, and no first-party statement addressing this stability guarantee directly.", "evidenceIds": [ "godot-gh-2", "godot-docs-16", "godot-comm-13" ] }, { "productId": "godot", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Godot is a self-hosted, open-source local engine with no cloud service or vendor-managed data storage — all project data lives on the developer's own machine/infrastructure, so 'choosing a storage region' is not a meaningful axis for this product category.", "evidenceIds": [ "godot-gh-2", "godot-docs-16" ] }, { "productId": "godot", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Godot is a local, open-source game engine with no cloud AI service or data-collection feature whose training-data usage would need to be opted out of; this privacy-posture axis about AI training data doesn't apply to this kind of product.", "evidenceIds": [] }, { "productId": "godot", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Godot is a locally-run, open-source game engine, not a hosted service or AI product that collects/retains user data on a vendor's behalf; there is no cloud account, telemetry-driven data store, or user data pipeline for which retention/deletion controls would be a meaningful axis. This privacy-posture story applies to SaaS/AI-data products, not to a local engine binary, so it is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "godot", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry, usage tracking, or any opt-out mechanism for Godot; the pack covers scripting languages, plugins, licensing, and community sentiment but never discusses data collection or privacy settings.", "evidenceIds": [] }, { "productId": "godot", "storyId": "productive-scripting-language", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "GDScript is documented as Godot's native, high-level, object-oriented, gradually-typed language that fully exposes the engine API (nodes/scenes, editor plugins, EditorScript), and community reports back this up as reasonably fast to learn and productive for people with programming experience. However, the evidence pack contains no explicit documentation of a GDScript-specific debugger (only C#'s Visual Studio debugging is called out), and some community feedback calls GDScript's ergonomics and documentation poor (comm-14, comm-15), creating real caveats rather than a clean full delivery. Missing for 10: explicit docs on the built-in GDScript debugger/breakpoints workflow, and stronger independent confirmation that GDScript is unambiguously productive for professional use.", "evidenceIds": [ "godot-docs-1", "godot-docs-8", "godot-docs-4", "godot-docs-5", "godot-comm-16", "godot-comm-14", "godot-comm-15", "godot-comm-6" ] }, { "productId": "godot", "storyId": "runtime-ml-inference", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any official ML inference runtime (e.g., ONNX/TensorFlow Lite integration) built into Godot for on-device model execution; the evidence pack covers scripting, export, plugins, and community sentiment but nothing about ML inference. Missing for 10: official inference API/runtime docs, model-loading tutorials, any first-party ML/AI execution feature.", "evidenceIds": [] }, { "productId": "godot", "storyId": "scripted-asset-import", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm Godot auto-imports assets on drop-in and supports batch-editing import parameters across multiple assets at once, plus a general editor-plugin/EditorScript system and headless CLI usable for scripted automation (godot-docs-9, godot-docs-15, godot-docs-17, godot-docs-4/13, godot-docs-5/14, godot-probe-4, godot-probe-rt-1). However, the evidence never names Godot's specific import-hook API (e.g., EditorImportPlugin/postimport scripts) or shows a documented pipeline-scripting workflow purpose-built for technical artists. Missing for 10: explicit documentation of custom import plugin/hook APIs, real-world pipeline-script examples, and independent corroboration that artists use this for hands-off batch processing.", "evidenceIds": [ "godot-docs-9", "godot-docs-15", "godot-docs-17", "godot-docs-4", "godot-docs-13", "godot-docs-5", "godot-docs-14", "godot-probe-4", "godot-probe-rt-1" ] }, { "productId": "godot", "storyId": "standard-asset-formats", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack only describes Godot's generic asset-import pipeline (auto-import to res://.godot/imported/, bulk import parameter changes) but never mentions glTF, FBX, or USD specifically, nor any hands-on report of clean or problematic imports for these formats — missing for 10: explicit glTF/FBX/USD import documentation, fidelity/compatibility notes, and any community corroboration of import quality for technical artists.", "evidenceIds": [ "godot-docs-9", "godot-docs-15", "godot-docs-17" ] }, { "productId": "godot", "storyId": "visual-scripting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents only code-based scripting options (GDScript, C#, GDExtension/C++) and editor plugins/scripts, with no mention of a node-graph or visual scripting system for building gameplay logic without writing code; Godot's own VisualScript feature is not referenced anywhere in the pack.", "evidenceIds": [ "godot-docs-1", "godot-docs-2", "godot-docs-8", "godot-docs-4", "godot-docs-5" ] }, { "productId": "phaser", "storyId": "agent-editor-control", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Phaser Studio ships an official 'Phaser Game Agent' MCP server with 40+ specialized tools that integrates with Claude Desktop, Cursor, GitHub Copilot and other MCP clients, letting an agent create particle emitters, reorganize scenes into layers, rename objects, tweak physics/animations, and add filters via natural-language commands routed through documented tool calls — directly matching the 'agent drives the editor programmatically' story. Runtime probe confirms the hosted MCP endpoint is live and documented at phaser.io/agent/mcp.\nmissing for 10: independent/hands-on third-party verification that the MCP tools reliably perform builds/edits, and a published open API/tool reference (npm package) beyond the marketing page.", "evidenceIds": [ "phaser-docs-13", "phaser-docs-14", "phaser-docs-15", "phaser-docs-26", "phaser-docs-29", "phaser-probe-4", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "agentic-agent-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "A live llms.txt was found at phaser.io/llms.txt (an examples-API index) and Phaser Studio publishes agent-oriented docs/MCP server pages (phaser.io/agent/mcp) explicitly for connecting coding agents, but the more commonly probed docs.phaser.io/llms.txt returns 404 and the site root 403s non-browser clients, requiring a browser UA and precise deep links to succeed. Missing for 10: a consistently discoverable llms.txt across the main docs domain, no 403/404 friction for automated agent fetches, and independent confirmation that agents can reliably ingest these docs.", "evidenceIds": [ "phaser-probe-1", "phaser-probe-rt-1", "phaser-probe-4", "phaser-docs-14" ] }, { "productId": "phaser", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "phaser", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "phaser", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Phaser's AI-related evidence (phaser-docs-13/14/15) describes an MCP server that lets *external* coding agents (Claude Desktop, Cursor, Copilot) call Phaser Editor tools — the opposite relationship of a built-in assistant living inside the product that a user delegates tasks to. No evidence shows a native, in-product chat/assistant feature.", "evidenceIds": [ "phaser-docs-13", "phaser-docs-14", "phaser-docs-15", "phaser-probe-4" ] }, { "productId": "phaser", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers installation, scenes, physics, animations, editor and MCP agent features, but nothing addresses headless execution or CI-based automation for Phaser games/tests. Since browser-based game engines can in principle support headless rendering or CI test harnesses, this is a fair but unaddressed axis rather than a category error.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a JS/TS game framework, not an AI agent or agent-hosting application; it has no client-side role for consuming external MCP servers. The evidence instead shows Phaser exposes its own MCP server (Game Agent) so other AI coding agents can call ITS tools — the opposite integration direction from this story, which is about the product itself plugging into and using external MCP servers' tools.", "evidenceIds": [ "phaser-docs-13", "phaser-docs-14", "phaser-probe-4" ] }, { "productId": "phaser", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Phaser Studio ships an official 'Phaser Game Agent' MCP server (phaser.io/agent/mcp) documented with 40+ specialized tools and explicit integration with Claude Desktop, Cursor, and GitHub Copilot, letting external agents connect and build games via plain-language commands. Missing for 10: independent/hands-on community validation that the MCP server works as advertised, and clarity on self-hosted/npm distribution (probe found no @phaserjs MCP package on npm, only a hosted endpoint).", "evidenceIds": [ "phaser-docs-13", "phaser-docs-14", "phaser-docs-15", "phaser-docs-26", "phaser-probe-4", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Phaser ships an official hosted 'Game Agent' MCP server that lets users describe changes in plain language (e.g., 'Give the player a double-jump...') and have the agent call over 40 specialised tools inside the Scene Editor, integrating with Claude Desktop, Cursor, and Copilot — directly matching natural-language operation. This is corroborated by a runtime probe confirming the live MCP endpoint at phaser.io/agent/mcp. Missing for 10: independent/community hands-on validation of the MCP agent's reliability and no npm-distributed MCP package (only hosted), so evidence is vendor-only.", "evidenceIds": [ "phaser-docs-13", "phaser-docs-14", "phaser-docs-15", "phaser-docs-26", "phaser-docs-29", "phaser-probe-4", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Phaser docs confirm an official CLI tool for scaffolding projects (interactive selection of templates/demo games), which counts as an official CLI, but it is described as interactive Q&A rather than a scriptable/agent-friendly interface, and there's no documentation of flags or non-interactive mode suited for AI-native automated use. missing for 10: evidence of non-interactive/programmatic CLI flags, AI-agent-oriented CLI documentation, and independent confirmation of CLI usability by agents.", "evidenceIds": [ "phaser-docs-2", "phaser-docs-21" ] }, { "productId": "phaser", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Phaser ships an extensive, versioned public JS/TS API (Scenes, physics, input, loader, animations) documented at docs.phaser.io with full TypeScript definitions, which is exactly the kind of documented public API an AI agent needs to generate/drive game code programmatically; the runtime probe also shows phaser.io/llms.txt now serving a live, programmatic examples-API index tailored for AI consumption. Missing for 10: a formal machine-readable spec (OpenAPI) for the core API surface — probes show OpenAPI/swagger endpoints all 404 — so discovery still relies on human-oriented docs rather than a fully machine-consumable contract.", "evidenceIds": [ "phaser-docs-4", "phaser-docs-8", "phaser-docs-9", "phaser-docs-10", "phaser-docs-11", "phaser-probe-1", "phaser-probe-3", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a JavaScript game framework/library, not a service issuing API credentials or an auth/identity platform; scoped credential issuance for agents is not a fair axis for this product type. Its MCP server (phaser.io/agent/mcp) is a tool-integration feature, not a credential/permissions system.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Phaser itself is the official SDK: it's distributed via npm, an official CLI, a CDN, and ships full TypeScript definitions, all documented in first-party docs and corroborated by community usage (games built in JS/TS, TypeScript experience feedback). Missing for 10: independent/third-party audit of the SDK's completeness and explicit multi-platform SDK packaging (e.g., official native wrappers) beyond docs claims.", "evidenceIds": [ "phaser-docs-1", "phaser-docs-4", "phaser-docs-20", "phaser-docs-21", "phaser-docs-22", "phaser-gh-1", "phaser-comm-4", "phaser-comm-8" ] }, { "productId": "phaser", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a game development framework/library, not a service with event streams or subscriptions that webhooks would apply to. This axis is a category error for this product type — no evidence relates to webhook subscriptions.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Community evidence confirms Phaser has an extensive examples library ('many examples and docs to work from' — phaser-comm-7), and a runtime probe shows docs.phaser.io/llms.txt now serves as a programmatic examples-API index with endpoints to fetch full source code per example (phaser-probe-rt-1), which is useful for AI-native exploration. However, there is no first-party evidence of an interactive, runnable-in-browser API reference (no OpenAPI/API-reference page found, docs-md and llms.txt initially 404'd per probes), so the story is only partially substantiated. Missing for 10: dedicated interactive API reference UI with live code execution, confirmation the examples API is documented/stable, independent hands-on account of using it.", "evidenceIds": [ "phaser-comm-7", "phaser-probe-rt-1", "phaser-probe-1", "phaser-probe-2" ] }, { "productId": "phaser", "storyId": "api-machine-spec", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Phaser ships full TypeScript type definitions (phaser-docs-4) which function as a machine-readable description of its API surface and can be consumed by tooling/agents, but there is no formal OpenAPI/Swagger spec or comprehensive llms.txt for the full API — probes confirm openapi.json/swagger.json 404 and the only live llms.txt is a narrow examples-index API, not a full API spec (phaser-probe-1, phaser-probe-3, phaser-probe-rt-1). missing for 10: a dedicated OpenAPI/JSON-schema style spec covering the full public API, and an official downloadable machine-readable spec beyond TS typings/examples index.", "evidenceIds": [ "phaser-docs-4", "phaser-probe-1", "phaser-probe-3", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "phaser", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of a documented deprecation policy, semver commitments, or API-stability guarantees; the only version-related evidence notes Phaser 2→3 broke compatibility (\"States\"... won't work in Phaser 3) with no stated migration/deprecation process, and probes found no OpenAPI/versioned docs artifacts.", "evidenceIds": [ "phaser-docs-7", "phaser-comm-8", "phaser-probe-3" ] }, { "productId": "phaser", "storyId": "asset-marketplace", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers Phaser's editor, MCP agent tooling, npm install, CDN and framework integrations, but there is no mention of a dedicated asset store, marketplace, or curated plugin ecosystem (à la Unity Asset Store) offering ready-made models/tools/plugins. Missing for 10: evidence of an official or third-party asset marketplace, a plugin registry, or curated ready-made asset packages.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The Editor/MCP agent evidence mentions handling tasks like renaming multiple objects and reorganizing scenes without switching tools, implying some bulk-editing capability, but there's no detailed documentation of a systematic bulk-operations API or workflow for AI agents. Missing for 10: explicit bulk-edit tooling/API docs, examples of batch operations across many assets/scenes, and independent confirmation of this capability working at scale.", "evidenceIds": [ "phaser-docs-29", "phaser-docs-13", "phaser-docs-14" ] }, { "productId": "phaser", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Phaser's docs mention a unified input system and scene lifecycle events, but no evidence describes a rule-engine or declarative trigger system where events automatically fire configured actions (e.g., an event-emitter/automation API is never documented in the pack). Missing for 10: documentation of an event-emitter/listener API, examples of rule-based automation, and any AI-native tooling for defining trigger→action rules.", "evidenceIds": [ "phaser-docs-9", "phaser-docs-5", "phaser-docs-23" ] }, { "productId": "phaser", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a game framework/engine; scheduling recurring jobs or workflows is not a relevant capability for this product category—it's a category error, not a missing feature.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "phaser", "storyId": "browser-deployment", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence confirms browser-based rendering with WebGL (community mention of 'rendering on both Canvas and WebGL') and easy npm/CDN distribution suggesting reasonable payload, but there is no mention anywhere in the pack of WebGPU support, a WebGPU renderer, or a roadmap toward it. missing for 10: explicit WebGPU renderer/roadmap documentation, payload-size benchmarks, and independent corroboration of WebGL performance beyond one anecdotal comment.", "evidenceIds": [ "phaser-comm-11", "phaser-docs-1", "phaser-docs-3" ] }, { "productId": "phaser", "storyId": "builtin-physics", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a built-in Arcade Physics system providing velocity, acceleration, gravity, and collision handling out of the box, and community testimony (phaser-comm-13) lists physics as a core built-in feature, but the pack explicitly notes Arcade physics 'does have its limitations' (phaser-docs-24) and never mentions raycasting or full rigid-body dynamics (e.g., Matter.js integration) with concrete examples. Missing for 10: explicit raycast API evidence, rigid-body/Matter physics documentation, and independent confirmation of collision accuracy beyond Arcade's simplified AABB model.", "evidenceIds": [ "phaser-docs-8", "phaser-docs-24", "phaser-comm-13" ] }, { "productId": "phaser", "storyId": "codegen-friendly-apis", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Phaser has extensive first-party docs, TypeScript definitions, and a long history (widely used since ~2013) that HN commenters confirm produced 'many examples and docs to work from' and 'great documentation,' supporting LLM familiarity. However, other independent reports directly contradict doc quality ('worst documentation... very bad design') and TypeScript support is described as a 'best-effort' bolt-on rather than native, plus the docs explicitly warn that pre-Phaser-3 tutorials/code (States) will not work — all of which undercut first-try reliability for LLM-generated code. Missing for 10: no direct evidence of LLM-generated Phaser code being tested/benchmarked, no resolution of the conflicting doc-quality reports, and no confirmation that the API has stabilized enough to avoid version-mismatch pitfalls.", "evidenceIds": [ "phaser-comm-7", "phaser-comm-10", "phaser-comm-4", "phaser-comm-16", "phaser-comm-1", "phaser-comm-8", "phaser-docs-7", "phaser-docs-4" ] }, { "productId": "phaser", "storyId": "collaboration-versioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers installation, scenes, physics, animation, and a visual Scene Editor, but nothing addresses version-control friendliness, mergeable/diffable scene file formats, or built-in multi-person collaboration tooling. While Phaser's code-first nature implies plain-text source files, there is no explicit documentation of scene file format diffability, conflict resolution, or team collaboration features for the visual editor.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "dedicated-server-runtime", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence anywhere in the pack of a headless/server-runtime build of Phaser that runs game logic without a canvas/WebGL renderer; all documentation focuses on browser/CDN/npm installs, Scenes, physics, and rendering-oriented editor tooling. Headless server support is a fair question for a game framework (many engines offer it), but nothing here confirms Phaser ships one.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "editor-scripting-extensibility", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Phaser's separate Editor product supports visual scene/asset manipulation (drag-and-drop, filters, inspector) and an MCP server exposes 40+ tools letting AI agents call editor-like functions to manipulate scenes/assets programmatically, which partially satisfies 'automate the editor.' However there is no evidence of a scripting/plugin API for the Editor itself (e.g., custom editor panels, extension SDK, editor-scripting language) — the MCP tools are agent-facing, not a documented developer plugin architecture. missing for 10: documented editor plugin/extension SDK, editor scripting API for custom tools, evidence of third-party editor plugins, independent hands-on confirmation of MCP tool automation reliability.", "evidenceIds": [ "phaser-docs-12", "phaser-docs-13", "phaser-docs-14", "phaser-docs-27", "phaser-docs-29", "phaser-probe-4", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "fast-iteration-loop", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack describes hot reload, live-reload dev server, or near-instant preview after script changes; only editor visual tweaks (glow/filters, drag-drop) are documented, which is not the same as a fast JS edit-run loop. The templates/CLI installation docs mention project setup but not dev-server hot reload behavior.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "first-class-2d", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Phaser's docs and community feedback confirm sprites, scenes, arcade physics, animations, tilemaps/atlases, and input are core, well-documented primitives rather than bolted-on features, and community comments reinforce it as a dedicated 2D engine (comparisons to Pixi/Love2D, 'fits 2D, sprites, tilemaps, physics'). missing for 10: independent hands-on benchmarking of tilemap-specific workflows and no explicit dedicated tilemap doc excerpt in the pack (only physics/scenes/animations/input are directly quoted).", "evidenceIds": [ "phaser-docs-5", "phaser-docs-6", "phaser-docs-8", "phaser-docs-9", "phaser-docs-10", "phaser-docs-11", "phaser-comm-13", "phaser-comm-18" ] }, { "productId": "phaser", "storyId": "full-scene-editor", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Phaser Studio ships an official visual Scene Editor with drag-and-drop placement, a real-time Inspector for effects/physics/animations, and scene reorganization into layers (phaser-docs-12, phaser-docs-27, phaser-docs-29), which covers viewport/inspector/scene-composition claims. However, core Phaser itself remains a code-first framework, prefab workflows are never explicitly named, and all evidence is first-party marketing with zero independent/hands-on corroboration of the editor's actual level-building workflow. Missing for 10: explicit prefab/reusable-component system documentation, independent reviews or hands-on reports of the editor, and clarity on how central this paid add-on editor is versus code-based scene building.", "evidenceIds": [ "phaser-docs-12", "phaser-docs-27", "phaser-docs-28", "phaser-docs-29" ] }, { "productId": "phaser", "storyId": "full-source-access", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Phaser's source is hosted on GitHub (phaser-gh-1, phaser-gh-2) and the runtime probe confirms it is MIT-licensed (phaser-probe-rt-1), meaning developers can freely read, fork, and modify the entire engine source when they hit a limitation. Community comments (e.g. phaser-comm-11, phaser-comm-12) even show developers digging into internals/rendering behavior, consistent with open-source access. Missing for 10: explicit documentation/tutorial on how to build from source or contribute patches, and no first-party statement framing this as a workaround path for hitting engine walls.", "evidenceIds": [ "phaser-gh-1", "phaser-gh-2", "phaser-probe-rt-1", "phaser-comm-11", "phaser-comm-12" ] }, { "productId": "phaser", "storyId": "headless-cli-builds", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence only shows an interactive CLI installer for scaffolding new projects (phaser-docs-2/21) and a separate paid Scene Editor with an MCP 'agent' for human-in-the-loop coding assistance (phaser-docs-12/13/14/27/29) — neither documents a headless build/export command or CI pipeline usage. There is no mention of a 'phaser build' CLI, bundler config, or automated export pipeline suitable for CI. Missing for 10: documented headless build/export CLI command, CI integration example, evidence that game export doesn't require the GUI editor.", "evidenceIds": [ "phaser-docs-2", "phaser-docs-21", "phaser-docs-12", "phaser-docs-13", "phaser-docs-14" ] }, { "productId": "phaser", "storyId": "headless-test-runs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions headless testing, CI integration, test runners, or running Phaser against a headless browser/Node environment for automated test execution — all evidence covers installation, scenes, physics, editor, and MCP tooling.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "modern-3d-rendering", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "phaser", "storyId": "multi-platform-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Phaser docs and GitHub state games can be \"compiled to iOS, Android, Steam and native apps using 3rd party tools,\" covering mobile and desktop export paths, and a community report confirms a real Android .apk export at 60fps. However, there is no evidence—vendor or community—of console export capability (directly or via a documented console partner program), which is a core part of this story. Missing for 10: documented console export path or partner program, first-party tooling/guide for desktop/mobile builds beyond \"3rd party tools\", independent confirmation of Steam/iOS builds.", "evidenceIds": [ "phaser-docs-17", "phaser-docs-18", "phaser-gh-2", "phaser-comm-17" ] }, { "productId": "phaser", "storyId": "npm-installable-runtime", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Phaser is published as a standard npm package (`npm install phaser`), confirmed both in docs and via live registry probe (v4.2.1, MIT license, 263k weekly downloads), and includes TypeScript definitions in the package, making it importable/bundleable like any standard JS dependency. Community evidence corroborates typical toolchain use (bundling into games/apps) though tree-shaking specifically isn't explicitly discussed. Missing for 10: explicit documentation or confirmation of tree-shaking/ESM module support behavior.", "evidenceIds": [ "phaser-docs-1", "phaser-docs-4", "phaser-docs-20", "phaser-probe-rt-1", "phaser-gh-1" ] }, { "productId": "phaser", "storyId": "official-ai-copilot", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Phaser Studio ships an official 'Phaser Game Agent' MCP server with 40+ specialized tools that integrates with Claude Desktop, Cursor, and Copilot, letting users describe changes in plain language (e.g. 'give the player a double-jump', 'create a particle emitter, reorganise a scene into layers') and have the agent execute them in the editor — directly matching the scaffolding/scripting parts of the story. However this is a separate hosted MCP server/agent rather than an assistant embedded 'inside the engine' itself, and there's no evidence it specifically answers API/documentation questions, nor any independent hands-on corroboration of its effectiveness. Missing for 10: evidence of API Q&A capability, first-party/independent hands-on validation of code-generation quality, and confirmation it's embedded in-engine rather than an external connected tool.", "evidenceIds": [ "phaser-docs-13", "phaser-docs-14", "phaser-docs-15", "phaser-docs-26", "phaser-docs-29", "phaser-probe-4" ] }, { "productId": "phaser", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items address governance structure, foundation status, published finances, or a public roadmap for Phaser; the evidence covers technical docs, editor/MCP features, pricing/licensing transfer, and community sentiment only. Missing for 10: any mention of a governing foundation, financial transparency/reports, or a published roadmap that a studio lead could plan against.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Phaser is a code-first JS/TS game framework whose entire API is already scriptable (Scenes, physics, input, animations, loader), so most 'UI' interactions like the Scene Editor are optional visual layers over the same API. The official MCP server (phaser.io/agent/mcp) lets an AI agent describe intent in plain language and have it call editor-equivalent tools, supporting API-level parity with editor actions like adding filters, particle emitters, and reorganizing scenes. However, evidence doesn't confirm 100% coverage of every visual editor feature (e.g., visual filter/particle configuration, pixel art/tilemap/SFX generation tools) via the plain code API, and the MCP server itself is a separate hosted tool, not something distributed as an installable npm package with public OpenAPI/spec. missing for 10: explicit confirmation that every Scene Editor visual feature (filters, particle emitters, layers, pixel/tilemap/SFX tools) has a documented equivalent API call, independent hands-on evidence the MCP/API can fully replicate editor UI actions, and a public API spec (OpenAPI 404s) proving completeness.", "evidenceIds": [ "phaser-docs-12", "phaser-docs-13", "phaser-docs-14", "phaser-docs-15", "phaser-docs-26", "phaser-docs-27", "phaser-docs-29", "phaser-docs-28", "phaser-probe-3", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "phaser", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Phaser's source is hosted publicly on GitHub (github.com/phaserjs/phaser, cited in phaser-gh-1/2) and the npm package is confirmed MIT-licensed via runtime probe, satisfying the 'read source under open license' story directly. Missing for 10: an explicit first-party LICENSE file citation and independent community commentary specifically about license terms/openness.", "evidenceIds": [ "phaser-gh-1", "phaser-gh-2", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "openness-self-host", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Phaser is an MIT-licensed, open-source JavaScript library installable via npm or CDN and usable entirely within a self-managed environment (GitHub source, npm package, jsDelivr CDN) — there is no vendor-hosted runtime dependency for the core engine, so self-hosting is inherent to the product. missing for 10: explicit deployment/self-hosting guide (e.g., Docker, server config) and independent confirmation of running fully offline in production.", "evidenceIds": [ "phaser-docs-1", "phaser-docs-3", "phaser-gh-1", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "performance-at-scale", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack shows no mention of a built-in profiler, ECS architecture, job system, or instancing support for scaling heavy scenes; Phaser's docs and community discussion focus on Scenes, Arcade physics, animations, and rendering (Canvas/WebGL) with only a passing complaint about relative rendering FPS. Nothing indicates data-oriented performance tooling exists.", "evidenceIds": [ "phaser-docs-5", "phaser-docs-8", "phaser-comm-11" ] }, { "productId": "phaser", "storyId": "permissive-license-no-royalties", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Runtime probe confirms the core Phaser engine is published under the MIT license (npm registry metadata), which is inherently permissive and imposes no royalties or per-install fees, letting studios keep 100% of game revenue. The evidence pack does not include an explicit vendor statement like 'no royalties' or 'keep what you earn,' so this is inferred from the MIT designation rather than a direct claim; separately, the paid Editor/pricing page (phaser-docs-30) mentions 'full commercial rights' and license transfer for a different, optional commercial tool, not the core engine's licensing terms. Missing for 10: an explicit first-party statement on royalty-free/no-fee terms and independent legal/community confirmation of the license text.", "evidenceIds": [ "phaser-probe-rt-1", "phaser-docs-30" ] }, { "productId": "phaser", "storyId": "pricing-terms-stability", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence shows current pricing/licence terms (full commercial rights, licence transfer) and confirms the core engine is MIT-licensed, but there is no evidence of a documented track record over time — no mention of past pricing changes, grandfathering policies, or community confirmation that shipped games were never repriced retroactively. Missing for 10: historical pricing-change log, explicit no-retroactive-repricing policy statement, and independent/community corroboration of licence stability over multiple releases.", "evidenceIds": [ "phaser-docs-16", "phaser-docs-30", "phaser-probe-rt-1" ] }, { "productId": "phaser", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a client-side JS game framework, not a hosted data service; there is no data storage/residency concept applicable to it since it doesn't manage user data on servers of its own.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a game framework/library with no data collection or AI-training relationship to users' data; privacy-posture around AI training data use is not a relevant axis for this product category.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a client-side game framework/library, not a data-processing service that stores or handles user data on a user's behalf, so data retention/deletion controls are not a meaningful axis for it.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry, usage tracking, or an opt-out mechanism for Phaser's library, CLI, editor, or MCP server offerings, despite these being product surfaces where such a policy could exist.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "productive-scripting-language", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Phaser's primary language is JavaScript/TypeScript with full TypeScript definitions shipped (phaser-docs-4) and GitHub confirming both JS/TS support (phaser-gh-1), and community members report it as easy to learn and productive (phaser-comm-3, phaser-comm-7, phaser-comm-10). However TypeScript support is described as 'best-effort... layered onto Phaser 3 via DefinitelyTyped' rather than native (phaser-comm-8), and docs quality — key to fully exposing the API productively — is criticized as 'the worst I've seen' by one community member (phaser-comm-16) even as others praise it (phaser-comm-10). No dedicated debugger tooling (breakpoints, inspector) is documented anywhere in the evidence pack beyond standard browser JS debugging implied by using JS/TS. Missing for 10: explicit debugger/dev-tools integration documentation, native (non-DefinitelyTyped) TypeScript support, and independent confirmation that the API surface is fully exposed without workarounds.", "evidenceIds": [ "phaser-gh-1", "phaser-docs-4", "phaser-comm-3", "phaser-comm-7", "phaser-comm-8", "phaser-comm-16", "phaser-comm-4" ] }, { "productId": "phaser", "storyId": "runtime-ml-inference", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Phaser is a 2D game framework/rendering engine; on-device ML inference runtime is entirely outside its scope of concerns (rendering, scenes, physics, input, assets). No evidence suggests it ships or plans an ML inference runtime — this is a category error, not a missing feature.", "evidenceIds": [] }, { "productId": "phaser", "storyId": "scripted-asset-import", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Phaser's docs cover its runtime Loader for fetching common asset types (images, atlases, audio) and an editor/MCP agent for interactive scene building, but there is no evidence of asset-import automation tooling (import hooks, preset-based pipelines, or scripts that batch-process incoming source assets before they reach the game) as a build-time pipeline feature. Missing for 10: any documented import-hook API, preset/config-driven asset processing, or pipeline scripting for automating asset ingestion.", "evidenceIds": [ "phaser-docs-10", "phaser-docs-12", "phaser-docs-27" ] }, { "productId": "phaser", "storyId": "standard-asset-formats", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "phaser", "storyId": "visual-scripting", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows Phaser's editor (phaser.io/editor) provides visual scene/asset editing—drag-and-drop placement, animation tweaking, physics-body adjustment, filter effects—and an MCP agent that translates natural-language requests into code changes, but nothing describes a node-based or visual gameplay-logic scripting system that lets a technical artist build game logic without writing JavaScript/TypeScript code. Phaser remains fundamentally a code-first framework (phaser-gh-1, phaser-docs-4), so the 'no-code logic' capability is unevidenced.", "evidenceIds": [ "phaser-docs-12", "phaser-docs-27", "phaser-docs-29", "phaser-docs-13", "phaser-docs-15", "phaser-gh-1" ] }, { "productId": "playcanvas", "storyId": "agent-editor-control", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlayCanvas ships an official, npm-published Editor MCP server that lets AI agents connect to an open Editor session, modify project data, and verify results, plus a separate documented scriptable Editor API (api.playcanvas.com/editor) for programmatic scene/node/property manipulation and automation. This directly satisfies the story of an agent driving the editor programmatically through a documented interface. Missing for 10: no independent/hands-on community report of an agent actually using the MCP server end-to-end, and no explicit documentation of triggering builds via this interface.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-docs-9", "playcanvas-probe-3", "playcanvas-probe-rt-1", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "A working llms.txt confirmed via HTTP 200 probe plus an unusually large llms-full.txt (2MB) of complete docs is directly served at developer.playcanvas.com, satisfying the exact story of pointing an agent at llms.txt/agent-oriented docs. This is corroborated by both docs claims and independent runtime probes, not just vendor assertion. Missing for 10: no independent third-party (non-probe) report of an agent actually consuming the file successfully in a real workflow.", "evidenceIds": [ "playcanvas-probe-1", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "PlayCanvas ships an official Editor MCP server that lets connected AI assistants read and modify project data and verify results in the viewport, which could be used to generate suggestions/insights from a user's scene data, but there is no evidence of a native, built-in AI insights/recommendations feature (e.g., analytics, optimization suggestions) inside the product itself. Missing for 10: dedicated AI-insights UI or documented use-case of the MCP server producing analytical suggestions, independent corroboration of this workflow in practice.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-3", "playcanvas-probe-rt-1" ] }, { "productId": "playcanvas", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "PlayCanvas ships an official Editor MCP server that lets AI assistants programmatically modify project data, but it explicitly requires 'an open PlayCanvas Editor session' rather than running as an independent, scheduled, or background process — this is closer to AI-assisted live editing than autonomous background automation. Missing for 10: evidence of scheduled/triggered jobs, headless/background execution without a live editor session, or any autonomous agent loop running unattended.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-3", "playcanvas-probe-rt-1" ] }, { "productId": "playcanvas", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PlayCanvas does not ship a built-in AI assistant embedded in its UI; instead it exposes an official Editor MCP server that lets external AI assistants (e.g. Claude) connect to an open Editor session and modify/inspect project data via the viewport, effectively allowing task delegation to AI, but the assistant itself lives outside the product rather than inside it. Missing for 10: a first-party, in-product AI assistant UI/chat surface, and any hands-on/community verification that delegation via MCP works well in practice.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-3", "playcanvas-probe-rt-1" ] }, { "productId": "playcanvas", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows the engine is npm-installable and there's an Editor MCP server, but the MCP server explicitly requires 'an open PlayCanvas Editor session' (interactive), and no evidence describes headless rendering, CI pipelines, or server-side/automated execution of the engine or editor without a live browser/editor session.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-gh-2", "playcanvas-comm-8" ] }, { "productId": "playcanvas", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows PlayCanvas exposing its own Editor as an MCP *server* that AI assistants connect to (playcanvas-docs-6, playcanvas-probe-rt-1) — the opposite direction of this story, which asks whether PlayCanvas itself can plug in external MCP servers to consume their tools. No evidence shows PlayCanvas acting as an MCP client or integrating third-party MCP tool servers into its engine, editor, or workflow.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-rt-1", "playcanvas-probe-3" ] }, { "productId": "playcanvas", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlayCanvas documents and ships an official, first-party MCP server (`@playcanvas/editor-mcp-server`, npm-published, official org repo) that connects AI assistants to a live Editor session to modify project data and verify results via the viewport, confirmed both in docs and runtime probes. Missing for 10: independent third-party hands-on validation of the MCP server beyond vendor docs/probe.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-3", "playcanvas-probe-rt-1" ] }, { "productId": "playcanvas", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlayCanvas ships an official, npm-published Editor MCP Server that lets AI assistants modify project data and verify results via the viewport, which is a genuine natural-language/agentic control surface for the Editor. However, this only covers Editor operations, not the runtime Engine or broader workflows, and there's no independent/hands-on evidence of it being used successfully in practice. missing for 10: community/hands-on validation of the MCP server in real workflows, evidence of natural-language control over the Engine/runtime (not just Editor), and broader agentic tool coverage beyond the single MCP server.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-3", "playcanvas-probe-rt-1" ] }, { "productId": "playcanvas", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "PlayCanvas ships an official `create-playcanvas` CLI for scaffolding Vite/TypeScript projects, which an AI agent could invoke, but the docs describe it purely as a project scaffolder with no explicit AI-native/agentic features (non-interactive flags, scripting API, automation hooks) and no independent confirmation of agent usage. Missing for 10: documentation of CLI flags/JSON output for automation, evidence of AI-agent usage, and any tie-in with the MCP server workflow.", "evidenceIds": [ "playcanvas-docs-1" ] }, { "productId": "playcanvas", "storyId": "agentic-public-api", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PlayCanvas exposes a documented scriptable Editor API for automating/customizing the Editor environment (api.playcanvas.com/editor/) plus an official, npm-published Editor MCP Server explicitly built for AI assistants to modify project data and verify results, alongside a standalone Engine API and llms.txt docs for AI consumption. This gives AI-native users multiple documented, programmatic ways to drive the product. Missing for 10: a formal OpenAPI/REST spec (probe found only 404s for openapi/swagger endpoints) and independent third-party confirmation of API-driven automation success.", "evidenceIds": [ "playcanvas-docs-9", "playcanvas-docs-6", "playcanvas-docs-7", "playcanvas-probe-rt-1", "playcanvas-probe-2", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows an official Editor MCP server connecting AI assistants to an open editor session, but nothing about issuing scoped or least-privilege API credentials/tokens for agent access; no auth/permissions model is documented. Missing for 10: any documentation of API key scoping, permission levels, or credential management for agent access.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-3", "playcanvas-probe-rt-1" ] }, { "productId": "playcanvas", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlayCanvas publishes multiple official SDKs — the core Engine (npm `playcanvas`), React and Web Components bindings, a `create-playcanvas` scaffolding CLI, a scriptable Editor API, and an official npm-published Editor MCP server for AI automation — all documented and runtime-verified. Community discussion confirms it integrates with standard JS/React workflows, though it also notes some dev-experience friction unrelated to SDK availability. Missing for 10: independent hands-on developer reports specifically validating SDK usage/quality, and a public OpenAPI/versioned reference (probe found only 404s for openapi.json).", "evidenceIds": [ "playcanvas-docs-1", "playcanvas-docs-7", "playcanvas-docs-9", "playcanvas-docs-11", "playcanvas-gh-2", "playcanvas-probe-rt-1", "playcanvas-probe-rt-2", "playcanvas-comm-7" ] }, { "productId": "playcanvas", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any webhook subscription mechanism in PlayCanvas; the API/MCP server and Editor API references relate to project data/editor automation, not event-driven webhooks. Missing for 10: any documentation of webhook endpoints, event subscription API, or third-party corroboration of webhook usage.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows PlayCanvas has API docs (api.playcanvas.com/editor), llms.txt full docs, and starter templates, but no evidence of an interactive API reference page with embedded runnable code examples akin to a live sandbox integrated into the reference itself.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Explicit probe evidence shows no OpenAPI/Swagger spec exists at any expected path (all candidates 404); while llms.txt and an Editor API doc site exist, there is no machine-readable API spec download offered.", "evidenceIds": [ "playcanvas-probe-2" ] }, { "productId": "playcanvas", "storyId": "api-sandbox", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "PlayCanvas documents Checkpoints for snapshotting/rolling back a project and an MCP server that acts on 'an open PlayCanvas Editor session,' which offers some safety net against irreversible changes, but there is no explicit sandbox/staging environment distinct from production data that an AI agent could test against. missing for 10: dedicated sandbox/staging project mode, explicit production-vs-test data separation, and evidence that MCP or automation actions can't touch the live production project.", "evidenceIds": [ "playcanvas-docs-5", "playcanvas-docs-6", "playcanvas-docs-13" ] }, { "productId": "playcanvas", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item mentions API versioning semantics or a documented deprecation policy; the OpenAPI probe returned 404s and docs only describe scripting formats, editor features, and an MCP server, not stability guarantees for the API surface.", "evidenceIds": [ "playcanvas-probe-2" ] }, { "productId": "playcanvas", "storyId": "asset-marketplace", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows PlayCanvas has an editor, engine, scripting system, MCP server, and npm-published engine, but nowhere mentions an asset store, marketplace, or plugin/package ecosystem for ready-made models or tools. No community or docs citation references anything resembling a store of third-party assets or plugins.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "PlayCanvas exposes a scriptable Editor API (api.playcanvas.com/editor) explicitly for building custom editing tools and integrating external data, and an official MCP server that lets AI assistants modify project data programmatically — both imply automation potential across many assets, but neither doc explicitly describes bulk/batch operations (e.g., multi-entity edits, batch asset import) or gives a hands-on example of many-item automation. Missing for 10: explicit bulk-edit/batch API examples, documented multi-item scripting workflows, and independent confirmation of large-scale automation via the MCP server or Editor API.", "evidenceIds": [ "playcanvas-docs-9", "playcanvas-docs-6", "playcanvas-probe-rt-1" ] }, { "productId": "playcanvas", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers scripting syntax, editor collaboration, physics components, and the MCP server for AI-assisted project editing, but contains no documentation of an explicit event/rule system where users can define triggers that automatically fire actions (e.g., event listeners, condition-action bindings) for automation purposes. Missing for 10: documentation of an event-trigger/rule engine, examples of defining conditional automation, and evidence tying this to AI-native workflows.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PlayCanvas is a 3D engine/editor platform; there is no concept of scheduling recurring jobs or workflows in its product surface, and the story does not map to any fair capability for this kind of tool (asset pipeline, MCP editor automation, scripting are one-off/session-based, not scheduled/recurring).", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PlayCanvas Editor has a Checkpoints feature to snapshot a project and roll back, which covers basic versioning/rollback of editor state (including changes made via the MCP-driven AI automation), but there's no documented diff/review workflow for automations and community feedback explicitly flags the lack of standard source-control integration as a pain point. missing for 10: dedicated review/diff tooling for automation changes, git-style commit history, and any evidence that checkpoints integrate specifically with AI-driven MCP edits.", "evidenceIds": [ "playcanvas-docs-5", "playcanvas-docs-6", "playcanvas-comm-3" ] }, { "productId": "playcanvas", "storyId": "browser-deployment", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlayCanvas is explicitly documented as a WebGL/WebGPU engine (probe-1) with a lightweight open-source runtime (npm playcanvas package, MIT license) and community corroboration that it's well-suited to lean web deployment (comm-1, comm-6, comm-13, comm-16) versus bloated alternatives. Missing for 10: no explicit payload-size benchmarks or bundle-size comparisons, and no independent hands-on confirmation of WebGPU parity/performance versus WebGL in production games.", "evidenceIds": [ "playcanvas-probe-1", "playcanvas-gh-2", "playcanvas-comm-1", "playcanvas-comm-6", "playcanvas-comm-13", "playcanvas-comm-16", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "builtin-physics", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm built-in rigidbody, collision, and joint components enabling physics simulation out of the box (playcanvas-docs-8), and community sources corroborate PlayCanvas as a capable, well-designed engine used in shipped games. However, raycasts are not explicitly mentioned, and there's no hands-on evidence or tutorial demonstrating physics working smoothly without setup friction (e.g., Ammo.js/physics engine integration steps). Missing for 10: explicit raycast documentation, independent hands-on confirmation of zero-config physics setup, and detail on which physics backend is bundled vs. requires separate install.", "evidenceIds": [ "playcanvas-docs-8", "playcanvas-comm-13", "playcanvas-comm-14" ] }, { "productId": "playcanvas", "storyId": "codegen-friendly-apis", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlayCanvas offers strong LLM-friendly infrastructure — a dedicated llms.txt/llms-full.txt (over 2MB of docs), a stable, long-standing npm-published engine (2.22.2, 48k weekly downloads) with abundant public code examples and community history, plus scripting API docs — all of which support an LLM having 'seen' the API. However, community threads note real dev-experience quirks and unusual design choices that could trip up naive LLM-generated code, and there's no direct hands-on evidence of first-try LLM code generation success rates. Missing for 10: independent benchmark or testimonial confirming LLM-generated PlayCanvas code works correctly on first try, and no discussion of API stability/breaking-change history that would affect training-data staleness.", "evidenceIds": [ "playcanvas-probe-rt-2", "playcanvas-probe-1", "playcanvas-gh-2", "playcanvas-comm-2", "playcanvas-comm-3" ] }, { "productId": "playcanvas", "storyId": "collaboration-versioning", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "PlayCanvas markets real-time multi-user editing as solving merge conflicts entirely (docs-4, docs-13) rather than a diffable/VCS-friendly text format, but hands-on community reports concretely contradict the 'plays well with version control' framing: developers note the project lives on PlayCanvas's servers with 'no easy local dev environment' and that basics like 'using your own source control' are missing, with unofficial third-party tools (playcanvas-sync) needed just to sync assets locally, and uploading being a 'deal breaker' for offline/local workflows. Checkpoints (docs-5) offer some rollback safety but are not the same as git-based diff/merge tooling. missing for 10: official git-friendly/text-diffable scene format, first-party local-file sync equivalent to real VCS integration, and evidence the community-reported local-dev gap has been resolved.", "evidenceIds": [ "playcanvas-docs-4", "playcanvas-docs-13", "playcanvas-docs-5", "playcanvas-comm-3", "playcanvas-comm-8", "playcanvas-comm-11", "playcanvas-comm-12", "playcanvas-comm-10" ] }, { "productId": "playcanvas", "storyId": "dedicated-server-runtime", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows PlayCanvas as a browser-focused WebGL/WebGPU engine with npm packages, Editor, and MCP server tooling, but nothing about a dedicated headless/server-runtime build without rendering for running game logic on servers. Missing for 10: any docs or GitHub evidence of a headless Node.js server build, server-side simulation mode, or rendering-free runtime.", "evidenceIds": [ "playcanvas-docs-7", "playcanvas-gh-2", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "editor-scripting-extensibility", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PlayCanvas explicitly documents a scriptable Editor API module (api.playcanvas.com/editor) built 'for developers looking to... create custom editing tools, or integrate external data and systems into the PlayCanvas Editor environment,' plus an official MCP server for AI-driven automation of live Editor sessions, and community-built sync tools for local file mapping — together showing programmatic extension of the editor itself. Missing for 10: concrete example plugins/marketplace or hands-on demonstration of a third-party editor tool built with this API, and no independent review confirming ease of use for this specific API (only general dev-experience complaints exist).", "evidenceIds": [ "playcanvas-docs-9", "playcanvas-docs-6", "playcanvas-probe-rt-1", "playcanvas-comm-10" ] }, { "productId": "playcanvas", "storyId": "fast-iteration-loop", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs claim live editing lets you tweak materials, positions, and even modify scripts while the application is running, and community reports confirm hot-module-replacement style workflows are achievable with the local sync tooling — but multiple community sources note this setup is 'certainly not super obvious' and historically required 'tinkering,' with one report citing no easy local dev environment as a dealbreaker at the time. missing for 10: first-party benchmark or docs describing built-in near-instant reload latency, and confirmation the friction reported in community threads has been resolved.", "evidenceIds": [ "playcanvas-docs-13", "playcanvas-comm-9", "playcanvas-comm-8", "playcanvas-comm-10" ] }, { "productId": "playcanvas", "storyId": "first-class-2d", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence pack covers 3D features (rigidbody/collision physics, Gaussian Splatting, Engine, Editor) but contains no mention of sprites, tilemaps, or a 2D physics system — PlayCanvas is documented here purely as a 3D-first engine. This is a fair question for a game engine, but no evidence supports a first-class 2D workflow, so it's 'none' rather than 'na'.", "evidenceIds": [ "playcanvas-docs-8", "playcanvas-gh-1" ] }, { "productId": "playcanvas", "storyId": "full-scene-editor", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a full drag-and-drop visual Editor with real-time collaborative scene building, live editing of materials/positions, and checkpoint/versioning (playcanvas-docs-3, docs-4, docs-5, docs-13), which matches the viewport+scene-composition part of the story. However, no evidence explicitly documents an 'inspector' panel or a 'prefab' system by name, and community reports flag real dev-experience friction (no easy local dev, assets must be uploaded, offline editing not supported) that complicate treating the editor as the primary, frictionless build workflow. missing for 10: explicit inspector/prefab terminology and documentation, independent hands-on confirmation of prefab workflow, resolution of community-reported offline/local-dev friction.", "evidenceIds": [ "playcanvas-docs-3", "playcanvas-docs-4", "playcanvas-docs-5", "playcanvas-docs-13", "playcanvas-comm-8", "playcanvas-comm-12" ] }, { "productId": "playcanvas", "storyId": "full-source-access", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "The PlayCanvas Engine is confirmed open source (MIT) and published on GitHub/npm, allowing developers to read and modify the core engine code directly, corroborated by community comment that 'the engine is open source' and runtime probes confirming the MIT license and public repo. Missing for 10: explicit contribution/build docs or a first-party statement of the license terms, and no independent hands-on account of someone actually patching engine internals.", "evidenceIds": [ "playcanvas-gh-1", "playcanvas-gh-2", "playcanvas-comm-11", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "headless-cli-builds", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "The standalone Engine is a plain npm package usable with Vite/TypeScript scaffolding, so Engine-only projects can plausibly be built and bundled headlessly via a standard `vite build` in CI (playcanvas-gh-2, playcanvas-docs-1, playcanvas-docs-7). However, PlayCanvas's primary workflow is the cloud Editor, and community reports confirm no easy local dev environment or native CLI export — code/assets live on PlayCanvas's servers, requiring third-party 'playcanvas-sync' tooling and manual tinkering to approximate a local/CI workflow (playcanvas-comm-8, playcanvas-comm-9, playcanvas-comm-10). No first-party CLI/CI build-and-export tool for Editor projects is documented anywhere in the evidence. Missing for 10: an official CLI/CI export command for Editor-based projects, documentation of headless Editor project builds, and independent confirmation that Editor-based CI pipelines work reliably.", "evidenceIds": [ "playcanvas-gh-2", "playcanvas-docs-1", "playcanvas-docs-7", "playcanvas-comm-8", "playcanvas-comm-9", "playcanvas-comm-10" ] }, { "productId": "playcanvas", "storyId": "headless-test-runs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of a testing framework, headless mode, or CI integration for running unit/integration tests against the PlayCanvas engine; docs cover scripting, editor, MCP server, and standalone engine usage but never mention headless test execution or CI workflows.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "modern-3d-rendering", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents scripting, editor collaboration, physics, MCP integration, and Gaussian splatting support, but contains no first-party or community evidence about PBR materials, global illumination/baked lighting, shadow systems, or a post-processing pipeline. Per the rules, absence of evidence for this applicable rendering-feature axis must be scored as 'none' rather than inferred from outside knowledge.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "multi-platform-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows PlayCanvas engine and Editor covering web, desktop-via-browser, and self-hosted app export, but there is no mention anywhere in the pack of console export (PlayStation/Xbox/Switch) or partner porting programs. Community commentary consistently frames PlayCanvas as a web-first/WebGL engine with no console story. missing for 10: any documentation of console export or third-party console porting partnership, evidence of desktop/mobile packaging beyond generic 'download apps', console SDK support.", "evidenceIds": [ "playcanvas-docs-10", "playcanvas-comm-6", "playcanvas-comm-16" ] }, { "productId": "playcanvas", "storyId": "npm-installable-runtime", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlayCanvas engine is published to npm (`npm install playcanvas`, version 2.22.2, ~48k weekly downloads) as a standard ES module library, with docs on using the Engine standalone and scaffolding via create-playcanvas/Vite for standard bundler-based toolchains. Community confirms it integrates with other JS frameworks and modern web-dev workflows (HMR, bundlers), supporting tree-shakable ESM usage. Missing for 10: no explicit documentation or independent confirmation of tree-shaking behavior/bundle-size optimization guidance, and some community reports note setup isn't always straightforward.", "evidenceIds": [ "playcanvas-gh-2", "playcanvas-docs-7", "playcanvas-docs-1", "playcanvas-probe-rt-2", "playcanvas-comm-7", "playcanvas-comm-9" ] }, { "productId": "playcanvas", "storyId": "official-ai-copilot", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlayCanvas ships an official, npm-published Editor MCP Server that lets external AI assistants connect to a live Editor session to modify project data, script entities, and verify changes via the viewport—directly enabling AI-assisted script generation and scene/asset scaffolding (playcanvas-docs-6, playcanvas-probe-rt-1). However, this is an MCP bridge for third-party assistants rather than a built-in chat/assistant panel inside the engine UI, and there's no dedicated in-engine API Q&A assistant beyond the llms.txt docs feed. Missing for 10: a native in-editor chat/assistant UI, and explicit evidence of it answering free-form API questions rather than just executing structured edits.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-probe-3", "playcanvas-probe-rt-1", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of a governing foundation, published financials, or a public roadmap; PlayCanvas is run as a commercial product (subscription plans mentioned) with no transparency artifacts cited. Community comments discuss engine features and dev-experience, not governance or funding.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlayCanvas exposes a scriptable Editor API (api.playcanvas.com/editor) for custom editing tools and integrations, plus an official MCP server that lets AI assistants modify project data and verify results via the viewport — going beyond a typical 'no API' game engine. However there is no discoverable REST/OpenAPI spec (404s across probed endpoints), and no documentation explicitly claims full UI-API parity; some Editor-only features (drag-and-drop scene building, real-time collaboration) are framed as UI-first conveniences without confirmed programmatic equivalents. missing for 10: an explicit parity statement/spec covering all UI actions, a formal REST/OpenAPI contract, and independent confirmation that collaborative/visual editor features are fully scriptable.", "evidenceIds": [ "playcanvas-docs-6", "playcanvas-docs-9", "playcanvas-probe-3", "playcanvas-probe-rt-1", "playcanvas-probe-2", "playcanvas-docs-3" ] }, { "productId": "playcanvas", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "The engine itself is open-source (MIT, npm-published) and PlayCanvas offers 'Download Apps for Self-hosting', plus community tooling (playcanvas-sync) to map project assets to a local filesystem, giving users a path to exit the platform with their code/engine. However, there is no first-party documentation of a comprehensive 'export all project data in open formats' feature, and community reports explicitly flag that code/collaboration data lives on PlayCanvas's servers with no easy local dev environment, undercutting a full data-portability story. Missing for 10: an official bulk data-export tool/format for scenes, assets and editor project state, and independent confirmation that exported data is fully open and complete.", "evidenceIds": [ "playcanvas-docs-10", "playcanvas-comm-8", "playcanvas-comm-9", "playcanvas-comm-10", "playcanvas-comm-11", "playcanvas-gh-2" ] }, { "productId": "playcanvas", "storyId": "openness-open-license", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlayCanvas Engine is confirmed open source (GitHub repo, MIT license, npm-published), and community commentary independently corroborates 'the engine is open source' (playcanvas-comm-11, comm-16). The full engine source is browsable on GitHub and versioned, satisfying an AI-native user's ability to read source under an open license; missing for 10: explicit license file text/OSI confirmation cited directly in evidence.", "evidenceIds": [ "playcanvas-gh-1", "playcanvas-gh-2", "playcanvas-comm-11", "playcanvas-comm-16", "playcanvas-probe-rt-2" ] }, { "productId": "playcanvas", "storyId": "openness-self-host", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "The core Engine is open-source (MIT, npm-published) and documented for standalone/self-hosted use (playcanvas-docs-7, playcanvas-gh-2), but the actual PlayCanvas product most users mean—the Editor/collaboration platform—is proprietary SaaS with no self-hosting option; community reports confirm project code must live on PlayCanvas's servers with no easy local dev environment (playcanvas-comm-8, playcanvas-comm-11, playcanvas-comm-12). The 'Download Apps for Self-hosting' doc refers to exporting built apps, not self-hosting the Editor itself. Missing for 10: an official self-hostable Editor/backend, first-party self-host deployment docs for the full platform, and resolution of the community-confirmed server-lock-in for authoring.", "evidenceIds": [ "playcanvas-docs-7", "playcanvas-gh-2", "playcanvas-docs-10", "playcanvas-comm-8", "playcanvas-comm-11", "playcanvas-comm-12" ] }, { "productId": "playcanvas", "storyId": "performance-at-scale", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of a profiler, ECS architecture, job/worker system, or GPU instancing for scaling heavy scenes — only physics components, Gaussian splatting, and editor/collab features are documented. This is a fair axis for any game engine, but PlayCanvas's pack simply doesn't address it.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "permissive-license-no-royalties", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "The core PlayCanvas Engine is confirmed MIT-licensed and open source ('MIT engine runtime' in playcanvas-probe-rt-2; community confirms 'the engine is open source' in playcanvas-comm-11 and playcanvas-comm-16), meaning a studio can ship and monetize games without royalties or per-install fees on the runtime itself. However, evidence also shows the hosted Editor/collaboration tooling is a paid subscription (e.g., $15/month for private projects, playcanvas-comm-4), which is a studio-tooling cost rather than a revenue royalty, so it doesn't contradict the engine's permissive licensing but adds nuance. Missing for 10: explicit vendor documentation stating 'no royalties/no revenue share' policy and independent legal/community confirmation of unrestricted commercial use terms.", "evidenceIds": [ "playcanvas-probe-rt-2", "playcanvas-comm-11", "playcanvas-comm-16", "playcanvas-comm-4" ] }, { "productId": "playcanvas", "storyId": "pricing-terms-stability", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses pricing/licensing history, terms stability, or retroactive repricing of shipped games; only a $15/month subscription mention and a link to the plans page appear, with no discussion of contract stability or track record.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence discusses data residency, region selection, or storage location controls for PlayCanvas projects/data; one community comment even notes concerns about code living on PlayCanvas's own servers with no mention of region choice. Missing for 10: any documentation of data residency/region options, self-hosting for data control (self-hosted apps mentioned relate to app deployment, not project data storage), or compliance/data-location settings.", "evidenceIds": [ "playcanvas-comm-8", "playcanvas-docs-10" ] }, { "productId": "playcanvas", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI-training data usage, opt-out controls, or a privacy policy statement regarding model training on user content/projects; this is an applicable privacy-posture axis for a cloud-hosted product handling user assets and code, but no documentation or community source confirms such a control exists.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers scripting, editor collaboration, MCP server, and engine features but contains no mention of data retention policies, data deletion controls, or privacy/GDPR settings for projects hosted on PlayCanvas's cloud platform. Given PlayCanvas stores project code/assets on its servers (per community discussion), retention/deletion controls would be a fair and relevant axis, but no evidence confirms such capability exists.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item addresses telemetry, analytics, or opt-out settings for PlayCanvas engine, editor, or CLI tools; the axis applies (any dev tool/platform could ship telemetry controls) but there is simply no documentation or mention of such a setting.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "productive-scripting-language", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlayCanvas scripting uses standard JavaScript/TypeScript (ESM `.mjs` scripts with class syntax) and the full engine can be scripted via `npm install playcanvas`, giving broad API access and a productive, familiar language; community comments (e.g. comm-13) also praise its game-framework layer atop low-level access. However, the evidence pack never explicitly documents a debugger (e.g. browser devtools breakpoints, source maps, or an IDE debug workflow) tied to scripting, and some community feedback flags dev-experience friction (playcanvas-comm-2, playcanvas-comm-3, playcanvas-comm-9) around local/offline workflows that could affect debugging setup. Missing for 10: explicit documentation of a debugger/breakpoint workflow for scripts, and confirmation that the full engine API (not just scripting hooks) is exposed without gaps.", "evidenceIds": [ "playcanvas-docs-2", "playcanvas-docs-12", "playcanvas-docs-7", "playcanvas-gh-2", "playcanvas-comm-13", "playcanvas-comm-9" ] }, { "productId": "playcanvas", "storyId": "runtime-ml-inference", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PlayCanvas is a WebGL/WebGPU game engine; the evidence pack covers editor tooling, scripting, MCP integration, and rendering features but contains no mention of an ML/inference runtime for on-device model execution. This capability is outside the core scope of a game engine's product category as evidenced here, so the axis does not apply rather than simply being unmet.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "scripted-asset-import", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The Editor API is explicitly billed for scripting custom tools and integrating external systems (playcanvas-docs-9), and the community references playcanvas-sync for mapping project assets to a local filesystem (playcanvas-comm-10) and the MCP server for programmatic project data changes (playcanvas-docs-6), all of which imply some automation capability. However, there is no documented import-hook system, asset presets, or a dedicated pipeline-scripting API specifically for processing incoming assets automatically. Missing for 10: explicit asset import hooks, configurable import presets, documented pipeline scripts triggered on asset ingestion, and independent confirmation these tools eliminate manual per-asset clicking.", "evidenceIds": [ "playcanvas-docs-9", "playcanvas-comm-10", "playcanvas-docs-6" ] }, { "productId": "playcanvas", "storyId": "standard-asset-formats", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of glTF, FBX, or USD import support, nor any asset-pipeline/import documentation; it covers editor, scripting, MCP server, and community sentiment unrelated to file format import.", "evidenceIds": [] }, { "productId": "playcanvas", "storyId": "visual-scripting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows PlayCanvas scripting is code-based (ESM/.mjs JavaScript classes) and the Editor supports drag-and-drop scene building and collaboration, but there is no mention of a node-based or visual scripting system for gameplay logic comparable to Blueprints/Bolt that would let a technical artist avoid writing code.", "evidenceIds": [ "playcanvas-docs-2", "playcanvas-docs-3", "playcanvas-docs-12" ] }, { "productId": "threejs", "storyId": "agent-editor-control", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Three.js's core JS API lets an agent create scenes, nodes, meshes, and materials and edit properties programmatically (documented in llms.txt for LLM consumption), but this is just using the library — there's no evidence of a documented scripting/automation interface for the standalone three.js editor app itself, nor any 'trigger build' concept or API. Missing for 10: documented editor automation/scripting API, evidence of programmatic control of the editor UI, and any build/export trigger mechanism.", "evidenceIds": [ "threejs-docs-7", "threejs-probe-rt-2", "threejs-gh-4", "threejs-docs-9" ] }, { "productId": "threejs", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "three.js publishes a llms.txt at its site root (HTTP 200 confirmed by probe) with an explicit 'Instructions for Large Language Models' section and a 363KB llms-full.txt covering complete docs, giving agents a direct machine-readable path. missing for 10: independent/community confirmation that agents actually use this llms.txt successfully in practice, and per-page markdown docs are hash-routed rather than statically addressable.", "evidenceIds": [ "threejs-probe-1", "threejs-probe-rt-2", "threejs-docs-1", "threejs-docs-14" ] }, { "productId": "threejs", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Three.js is fundamentally a browser WebGL/WebGPU library requiring a GPU-backed rendering context; the evidence pack contains no mention of headless rendering, Node.js server-side use, headless-gl/puppeteer integration, or CI automation support. This is a fair question for a rendering engine (other engines in this space document headless CI paths), so absence of evidence means 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a 3D graphics library, not an agent or platform that consumes external tools via MCP; the evidence explicitly confirms no MCP server exists and coding agents just use the library directly through npm. This axis is a category error for a rendering library.", "evidenceIds": [ "threejs-probe-rt-2" ] }, { "productId": "threejs", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "three.js publishes an llms.txt/llms-full.txt specifically to let AI coding agents generate code that drives the library, which is a step toward AI-native operability, but there is no natural-language command interface, chat layer, or MCP server that lets a user directly 'command' the renderer in natural language — an agent still has to write and run JavaScript. Missing for 10: a direct natural-language control layer, an MCP server or agent API, and independent evidence of agents successfully operating three.js purely via NL commands.", "evidenceIds": [ "threejs-probe-rt-2", "threejs-probe-1", "threejs-docs-1" ] }, { "productId": "threejs", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "three.js exposes a well-documented JS API (WebGLRenderer/WebGPURenderer, TSL, GLTFLoader, controls) and even publishes llms.txt/llms-full.txt files explicitly aimed at LLM consumption, which supports AI-native driving of the library via npm. However this is a client-side JS library API, not a service with an OpenAPI/REST spec or an MCP server, and probes confirm no OpenAPI endpoints and no official MCP server exist. missing for 10: OpenAPI/machine-readable API spec, official MCP server, per-page static doc URLs (docs are hash-routed, only llms.txt is the structured machine path).", "evidenceIds": [ "threejs-probe-1", "threejs-probe-rt-2", "threejs-probe-3", "threejs-docs-1", "threejs-docs-4", "threejs-gh-1" ] }, { "productId": "threejs", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a client-side 3D rendering library with no API/service surface requiring credentials; scoped credential issuance is not a relevant axis for this kind of product.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "agentic-sdks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "three.js publishes an llms.txt/llms-full.txt with explicit LLM instructions and is consumable directly via npm, and it is an official, well-documented SDK (WebGL/WebGPU renderers, TSL, GLTFLoader, controls). However, this is a library/API rather than an 'agentic' SDK with tool-calling or agent-specific integration hooks, and there is no official MCP server or agent-oriented tooling beyond docs formatted for LLM consumption. missing for 10: no agent-specific SDK features (e.g., function-calling schemas, MCP server), no independent verification of llms.txt actually improving agent code generation, human docs are hash-routed rather than crawlable per-page.", "evidenceIds": [ "threejs-probe-rt-2", "threejs-probe-1", "threejs-docs-1", "threejs-docs-4", "threejs-probe-rt-1" ] }, { "productId": "threejs", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a client-side rendering library with no service/event backend; webhooks are a wrong-axis capability for this kind of product, not something buyers of a graphics library would expect.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "three.js has a documented interactive examples gallery (threejs.org/examples) and an extensive docs/manual with API references, plus an llms.txt/llms-full.txt tailored for AI agents to consume the API reference programmatically. However, the examples are not runnable/editable inline within the docs reference itself in an AI-native interactive way, there's no API playground or embedded live code editor tied to reference pages, and human doc pages are hash-routed rather than having stable per-page URLs, limiting agentic navigation. missing for 10: inline runnable/editable examples embedded in API reference pages, stable per-page doc URLs for agent navigation, and any dedicated interactive playground/sandbox tool.", "evidenceIds": [ "threejs-docs-16", "threejs-docs-9", "threejs-probe-rt-2", "threejs-probe-1", "threejs-comm-7" ] }, { "productId": "threejs", "storyId": "api-machine-spec", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Three.js has no OpenAPI/Swagger spec (explicit probe of openapi.json/swagger.json paths all 404), but it does publish an 'equivalent' machine-readable artifact for AI consumption: a root-level llms.txt with an explicit 'Instructions for Large Language Models' section and a 363KB llms-full.txt covering the full API surface. This is a documentation-style machine-readable spec rather than a structured, typed API schema (no parameter/type schema, no endpoint-like structure). Missing for 10: a structured schema format (OpenAPI-equivalent with typed signatures), and any indication the llms.txt is treated as a formal versioned spec rather than prose docs.", "evidenceIds": [ "threejs-probe-1", "threejs-probe-3", "threejs-probe-rt-2" ] }, { "productId": "threejs", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "There is a Migration Guide and per-release notes documenting breaking changes between versions (e.g. 185→186), and npm shows a clear version number (0.186.0), but nothing describes a formal deprecation policy (notice periods, stable API guarantees, semver commitments) — three.js is known for frequent breaking changes on its own rolling release cadence. missing for 10: explicit deprecation policy statement, semver/API-stability guarantees, notice period before removals.", "evidenceIds": [ "threejs-docs-10", "threejs-docs-17", "threejs-probe-rt-1" ] }, { "productId": "threejs", "storyId": "asset-marketplace", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows three.js's own built-in addons (GLTFLoader, OrbitControls, editor, devtools) and npm package popularity, not a third-party asset store or plugin marketplace comparable to Unity/Unreal ecosystems; community commentary even notes basic model loading (.obj) was painful. missing for 10: any evidence of a dedicated asset store, marketplace, or curated third-party plugin ecosystem for game assets/tools.", "evidenceIds": [ "threejs-docs-4", "threejs-docs-5", "threejs-docs-7", "threejs-docs-8", "threejs-comm-3", "threejs-probe-rt-1" ] }, { "productId": "threejs", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence describes batch/bulk APIs (e.g., instancing, scene-graph batch edits) or automation tooling for operating on many items at once; the evidence pack only covers renderer setup, TSL, loaders, and controls.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a 3D rendering library, not a workflow/automation platform; scheduling recurring jobs is outside its category and irrelevant to a graphics engine's API surface.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "browser-deployment", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "three.js runs in-browser via WebGLRenderer (widely used, huge npm install base) and has a credible, actively developed WebGPU story through WebGPURenderer plus TSL shaders that target both WebGL and WebGPU backends, with SVG/CSS3D as lighter addons keeping core payload lean. Community confirms it's a solid abstraction over WebGL, though payload/performance specifics for WebGPU maturity aren't independently benchmarked in evidence. missing for 10: independent bundle-size/payload benchmarks, and hands-on confirmation of WebGPU production readiness beyond docs claims.", "evidenceIds": [ "threejs-gh-1", "threejs-gh-3", "threejs-docs-3", "threejs-docs-1", "threejs-comm-1", "threejs-comm-10", "threejs-probe-rt-1" ] }, { "productId": "threejs", "storyId": "builtin-physics", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "three.js is a rendering library — no evidence of any built-in physics engine (rigid bodies, collisions, raycasts as physics) shipped out of the box; evidence only covers rendering (WebGL/WebGPU), loaders, and controls. Raycaster exists in three.js for picking but no physics/collision system is documented, and physics is a well-known gap requiring third-party libraries like Cannon.js or Ammo.js.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "codegen-friendly-apis", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Three.js is hugely popular (12M weekly npm downloads) with abundant public examples and even a dedicated llms.txt/llms-full.txt tailored for LLM consumption, which strongly favors first-try LLM code generation. However, community evidence and the docs themselves point to real friction: frequent breaking API changes requiring per-version migration guides, explicit warnings to use 'CORRECT - modern pattern' import maps (implying old LLM-trained patterns break), and hands-on reports that seemingly simple tasks (loading a model) were unexpectedly hard, undermining 'mostly works on the first try.' Missing for 10: independent benchmark/report of LLM-generated three.js code success rate, and stronger evidence that API stability (not just doc richness) prevents version-mismatch failures.", "evidenceIds": [ "threejs-probe-rt-1", "threejs-probe-rt-2", "threejs-docs-6", "threejs-docs-10", "threejs-comm-2", "threejs-comm-3", "threejs-comm-5" ] }, { "productId": "threejs", "storyId": "collaboration-versioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "three.js is a rendering library/API, not a scene-authoring tool with a project file format; evidence shows only a code-based API, an optional visual editor, and no mention of diffable scene formats, merge tooling, or multi-user collaboration features. This axis applies to engines/authoring tools generally, but nothing in the evidence indicates three.js ships mergeable/diffable project files or built-in collaboration.", "evidenceIds": [ "threejs-docs-7", "threejs-gh-4", "threejs-docs-9" ] }, { "productId": "threejs", "storyId": "dedicated-server-runtime", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "three.js is fundamentally a browser-based WebGL/WebGPU rendering library requiring a canvas/GPU context; the evidence pack shows no headless/server-runtime build, no dedicated-server mode, and no mention of running game logic without rendering on Node.js servers. missing for 10: any headless rendering context (e.g. node-canvas/gl bindings), a documented server-runtime build, or dedicated-server examples.", "evidenceIds": [ "threejs-gh-3", "threejs-probe-rt-2" ] }, { "productId": "threejs", "storyId": "editor-scripting-extensibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence confirms three.js ships an editor (threejs.org/editor) and a devtools browser extension, but nothing in the pack describes any plugin API, scripting console, or extension mechanism for programmatically automating the editor itself — the docs excerpts focus on the library API (TSL, renderers, loaders, controls), not editor extensibility.", "evidenceIds": [ "threejs-docs-7", "threejs-docs-8" ] }, { "productId": "threejs", "storyId": "fast-iteration-loop", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "three.js is a rendering library, not a game engine or dev environment with a build/watch pipeline; no evidence in the pack of any hot-reload, live-reload, or fast edit-run tooling shipped by the project itself (only unrelated docs, editor mentions, and API references).", "evidenceIds": [] }, { "productId": "threejs", "storyId": "first-class-2d", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows three.js is positioned and documented purely as a 3D graphics library (WebGL/WebGPU renderers, TSL shaders, GLTFLoader, OrbitControls) with no mention of sprites, tilemaps, or 2D physics as first-class citizens; 2D is at best an afterthought achievable via workarounds, consistent with community comments about needing workarounds for things it wasn't built for.", "evidenceIds": [ "threejs-probe-1", "threejs-gh-3", "threejs-docs-3", "threejs-comm-1" ] }, { "productId": "threejs", "storyId": "full-scene-editor", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "three.js ships a browser-based editor (threejs.org/editor) and devtools/TransformControls, but evidence only names the editor's existence with no documentation of an inspector, prefab system, or scene-composition workflow, and the library's primary workflow is code-first (constructing scenes via API) rather than a visual editor. Missing for 10: documented inspector UI, prefab/asset composition workflow, evidence the editor is treated as the primary level-building tool rather than a supplementary demo tool.", "evidenceIds": [ "threejs-docs-7", "threejs-docs-5", "threejs-docs-8" ] }, { "productId": "threejs", "storyId": "full-source-access", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "three.js is open-source (MIT license per npm registry) with full source hosted on GitHub, clonable and directly modifiable, and community evidence confirms active engagement with the codebase (e.g., @ts-ignore workarounds, discussion of internals like antialiasing defaults). Missing for 10: no explicit first-party statement encouraging source modification as a supported workflow, and no case study of a game dev forking/patching the engine for a shipped title.", "evidenceIds": [ "threejs-probe-rt-1", "threejs-gh-2", "threejs-comm-5", "threejs-comm-8" ] }, { "productId": "threejs", "storyId": "headless-cli-builds", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows three.js is a code-first WebGL/WebGPU library installed via npm/git and used with standard `WebGLRenderer` setup, but nothing documents a CLI or automated pipeline for building/exporting a 'project' headlessly in CI (no headless rendering support, no export tooling, no CI recipes) — the only editor mentioned (threejs.org/editor) is a browser GUI requiring human interaction. missing for 10: any documented headless rendering approach (e.g. headless-gl/Node canvas), a CLI build/export command, and CI pipeline examples.", "evidenceIds": [ "threejs-gh-1", "threejs-gh-2", "threejs-docs-7", "threejs-gh-4" ] }, { "productId": "threejs", "storyId": "headless-test-runs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack addresses headless testing, CI integration, or running WebGLRenderer/WebGPURenderer without a browser context (e.g. via node-canvas, jsdom, or headless GL). All evidence covers rendering setup, docs, and community sentiment, none of it about automated/headless test execution.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "modern-3d-rendering", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence confirms a modern rendering pipeline (WebGLRenderer/WebGPURenderer, antialiasing, and node-based 'MeshStandardNodeMaterial' implying PBR-style materials) but the pack contains no explicit documentation of shadow mapping, global illumination/baked lighting, or a post-processing pipeline — a community comment even asks uncertainly whether lightmaps are possible. missing for 10: explicit shadow-mapping docs, GI/lightmap baking evidence, post-processing/effects pipeline documentation, independent confirmation of PBR material fidelity.", "evidenceIds": [ "threejs-docs-2", "threejs-docs-13", "threejs-gh-1", "threejs-comm-8", "threejs-comm-9" ] }, { "productId": "threejs", "storyId": "multi-platform-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows three.js is a browser-based WebGL/WebGPU rendering library with no documentation of a build/export pipeline to native desktop, mobile, or console targets — no mention of Electron/Cordova wrapping, console SDK partnerships, or platform-specific packaging tools. While the axis is fair to ask of any 3D technology a studio might adopt, there is no evidence three.js provides or facilitates such multi-platform export beyond running inside a web browser.", "evidenceIds": [ "threejs-gh-1", "threejs-gh-3", "threejs-probe-1" ] }, { "productId": "threejs", "storyId": "npm-installable-runtime", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "three.js is published on npm (12M+ weekly downloads, MIT license per registry probe) and is widely used as an ES module import (importmap pattern shown in docs), consistent with standard bundler/tree-shaking workflows; community feedback confirms TypeScript compatibility and typical dependency usage patterns. Missing for 10: no explicit first-party documentation or evidence specifically confirming tree-shaking behavior/bundle-size optimization guidance.", "evidenceIds": [ "threejs-probe-rt-1", "threejs-docs-6", "threejs-comm-4", "threejs-comm-5", "threejs-comm-10" ] }, { "productId": "threejs", "storyId": "official-ai-copilot", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows only LLM-friendly documentation (llms.txt) and no in-engine AI assistant, chat copilot, or code-generation assistant feature; probe explicitly notes no MCP server or agent integration exists, official or community.", "evidenceIds": [ "threejs-probe-rt-2", "threejs-probe-1" ] }, { "productId": "threejs", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a foundation, published finances, or public roadmap; three.js governance appears to be maintainer-driven (mrdoob) via GitHub releases/migration guides with no financial transparency artifacts in the pack.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "openness-api-parity", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "threejs", "storyId": "openness-open-license", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "three.js source is hosted publicly on GitHub (mrdoob/three.js) and distributed via npm under the MIT license, verified directly from the npm registry; the repo is clonable and openly browsable. missing for 10: no explicit license file text quoted in the evidence pack, only registry-confirmed MIT license metadata.", "evidenceIds": [ "threejs-gh-1", "threejs-gh-2", "threejs-probe-rt-1" ] }, { "productId": "threejs", "storyId": "openness-self-host", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "three.js is an open-source (MIT) client-side library distributed via npm/GitHub that can be cloned, built, and self-hosted entirely without any vendor service, as shown by the git clone instructions and npm registry data. missing for 10: no explicit first-party 'self-hosting guide' doc beyond generic clone/build instructions, and no independent case study of a fully self-hosted deployment.", "evidenceIds": [ "threejs-gh-2", "threejs-probe-rt-1", "threejs-gh-3" ] }, { "productId": "threejs", "storyId": "performance-at-scale", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a built-in profiler, ECS, job system, or GPU/CPU instancing tooling in the pack — only renderer setup, TSL/WebGPU shading, loaders, and controls are documented. Three.js is a rendering library, not a full engine, so profiling and data-oriented scaling primitives fall to external tools (Chrome DevTools extension is mentioned but that's a generic browser profiler, not a real-time engine profiler), and no ECS/jobs/instancing capability is cited.", "evidenceIds": [ "threejs-docs-8" ] }, { "productId": "threejs", "storyId": "permissive-license-no-royalties", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "npm registry confirms three.js is MIT licensed, a permissive license with no royalties or per-install fees, verified directly from the package registry. Missing for 10: no explicit first-party licensing FAQ or legal statement addressing commercial game royalties specifically, relying instead on the generic MIT registry classification.", "evidenceIds": [ "threejs-probe-rt-1" ] }, { "productId": "threejs", "storyId": "pricing-terms-stability", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "three.js is MIT-licensed, verified from the npm registry, which is a free, permissive open-source license with no pricing terms to retroactively change — this structurally supports licensing stability. However, there is no explicit evidence pack documentation of license history, versioning of terms, or any studio commentary confirming a track record of stability over time. Missing for 10: explicit license-history documentation, third-party confirmation of no relicensing/repricing events, and studio-lead testimonials on licensing trust.", "evidenceIds": [ "threejs-probe-rt-1" ] }, { "productId": "threejs", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a client-side rendering library with no data storage/hosting component, so data residency/region choice is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a client-side 3D rendering library, not a data-processing or AI service that trains models on user data; data-training opt-out is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a client-side rendering library, not a data-processing service or platform that stores/retains user data; data retention/deletion controls are not an applicable axis for this kind of product.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a client-side rendering library with no telemetry, network service, or usage-tracking component to opt out of; this privacy-posture axis applies to hosted services/SaaS tools, not a self-contained open-source graphics library.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "productive-scripting-language", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Three.js is a plain JavaScript/TypeScript library, so the 'scripting language' is JS itself, giving full, direct access to the entire engine API with no separate scripting sandbox or restricted binding layer (threejs-gh-1, threejs-gh-4). Debugging is supported via standard browser devtools plus a dedicated official Chrome three.js DevTools extension (threejs-docs-8), and TypeScript works well though community reports note occasional @types/three signature mismatches requiring ts-ignore (threejs-comm-4, threejs-comm-5). Missing for 10: deeper first-party documentation of the debugger extension's capabilities and stronger independent corroboration of TypeScript API completeness.", "evidenceIds": [ "threejs-gh-1", "threejs-gh-4", "threejs-docs-8", "threejs-comm-4", "threejs-comm-5" ] }, { "productId": "threejs", "storyId": "runtime-ml-inference", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "three.js is a WebGL/WebGPU 3D rendering library, not an ML inference runtime; no evidence exists of an on-device model execution engine, and this axis is a category error for a rendering library rather than an applicable-but-unmet capability.", "evidenceIds": [] }, { "productId": "threejs", "storyId": "scripted-asset-import", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "three.js is a rendering library with a GLTFLoader and asset loaders, but there is no evidence of automatable asset-import pipelines, import hooks, presets, or scripted batch-processing of incoming assets — everything in the evidence pack concerns runtime rendering APIs, TSL/WebGPU, and manual loader usage rather than pipeline automation.", "evidenceIds": [ "threejs-docs-4", "threejs-gh-3" ] }, { "productId": "threejs", "storyId": "standard-asset-formats", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Only GLTFLoader is explicitly evidenced as a documented import path; there is no mention of FBX or USD loaders in the evidence pack, and a community report describes friction loading even a simple OBJ model, undercutting the 'imports cleanly' framing. Missing for 10: FBXLoader/USDLoader documentation or examples, first-party guidance on interchange-format fidelity, and independent confirmation that glTF/FBX/USD assets import without manual fixes.", "evidenceIds": [ "threejs-docs-4", "threejs-comm-3" ] }, { "productId": "threejs", "storyId": "visual-scripting", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "unity", "storyId": "agent-editor-control", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-9", "unity-docs-10", "unity-docs-11", "unity-docs-12", "unity-docs-13", "unity-probe-4", "unity-probe-rt-1" ] }, { "productId": "unity", "storyId": "agentic-agent-docs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-15", "unity-docs-16", "unity-probe-rt-2", "unity-probe-1", "unity-probe-2" ] }, { "productId": "unity", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.'", "evidenceIds": [ "unity-docs-14", "unity-probe-rt-1", "unity-probe-4" ] }, { "productId": "unity", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-probe-5", "unity-probe-rt-1", "unity-probe-rt-3" ] }, { "productId": "unity", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-14", "unity-probe-rt-1" ] }, { "productId": "unity", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-probe-rt-3", "unity-comm-13" ] }, { "productId": "unity", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Unity ships an official MCP *server* (com.unity.ai.assistant) so external AI agents can connect to and control Unity — the opposite direction of this story, which asks whether Unity itself can plug in external MCP servers to use their tools. No evidence indicates Unity's AI Assistant or Editor can act as an MCP client/host consuming third-party MCP servers.", "evidenceIds": [ "unity-probe-4", "unity-probe-rt-1" ] }, { "productId": "unity", "storyId": "agentic-mcp-server", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-probe-4", "unity-probe-rt-1", "unity-docs-14" ] }, { "productId": "unity", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-14", "unity-probe-rt-1", "unity-probe-4" ] }, { "productId": "unity", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-docs-9", "unity-probe-5", "unity-probe-rt-2" ] }, { "productId": "unity", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-11", "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-docs-10", "unity-probe-4", "unity-probe-5", "unity-probe-rt-1", "unity-probe-rt-3" ] }, { "productId": "unity", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unity is a game engine/editor product; issuing scoped API credentials for AI agents is not a capability category that applies to this kind of product — it's an authentication/credential-management concern for API/service platforms, not a game development tool. No evidence contradicts this categorization.", "evidenceIds": [] }, { "productId": "unity", "storyId": "agentic-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "unity-docs-11", "unity-docs-13", "unity-docs-10", "unity-docs-6", "unity-docs-7", "unity-docs-9", "unity-probe-4", "unity-probe-5", "unity-probe-rt-1", "unity-probe-rt-2" ] }, { "productId": "unity", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unity is a game engine/development platform, not an event-driven service or SaaS with subscribable resources; webhooks for event subscription are not a fitting axis for this product category, and no evidence suggests otherwise.", "evidenceIds": [] }, { "productId": "unity", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-probe-3", "unity-probe-2", "unity-probe-1", "unity-probe-rt-2", "unity-docs-11" ] }, { "productId": "unity", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-probe-3", "unity-probe-1", "unity-probe-2", "unity-probe-rt-2" ] }, { "productId": "unity", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "unity", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-11", "unity-docs-13", "unity-probe-3", "unity-probe-2" ] }, { "productId": "unity", "storyId": "asset-marketplace", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-12", "unity-docs-13", "unity-comm-6", "unity-probe-rt-1" ] }, { "productId": "unity", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-docs-11", "unity-docs-12" ] }, { "productId": "unity", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-10", "unity-docs-11" ] }, { "productId": "unity", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Unity's evidence shows command-line/headless automation for builds (unity-docs-6/7/8, unity-probe-rt-3) which could be wired into external schedulers, but there is no evidence of any native recurring-job or workflow-scheduling feature inside Unity or its AI tooling. missing for 10: any built-in scheduler/cron equivalent, workflow orchestration UI, or documented recurring automation trigger.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-probe-rt-3" ] }, { "productId": "unity", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "unity", "storyId": "browser-deployment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "unity", "storyId": "builtin-physics", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "unity", "storyId": "codegen-friendly-apis", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "unity", "storyId": "collaboration-versioning", "verdict": "partial", "quality": 2, "confidence": "low", "rationale": "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.", "evidenceIds": [ "unity-docs-2" ] }, { "productId": "unity", "storyId": "dedicated-server-runtime", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-8", "unity-docs-6", "unity-docs-7", "unity-probe-5" ] }, { "productId": "unity", "storyId": "editor-scripting-extensibility", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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).", "evidenceIds": [ "unity-docs-10", "unity-docs-11", "unity-docs-12", "unity-docs-13" ] }, { "productId": "unity", "storyId": "fast-iteration-loop", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "unity", "storyId": "first-class-2d", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "unity-docs-1" ] }, { "productId": "unity", "storyId": "full-scene-editor", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-10", "unity-docs-11", "unity-docs-12", "unity-docs-13" ] }, { "productId": "unity", "storyId": "full-source-access", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-10", "unity-docs-11", "unity-comm-12", "unity-comm-13" ] }, { "productId": "unity", "storyId": "headless-cli-builds", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-docs-9", "unity-probe-5", "unity-probe-rt-3", "unity-comm-13" ] }, { "productId": "unity", "storyId": "headless-test-runs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-comm-13" ] }, { "productId": "unity", "storyId": "modern-3d-rendering", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-5", "unity-docs-18", "unity-docs-16" ] }, { "productId": "unity", "storyId": "multi-platform-export", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-1", "unity-docs-3", "unity-docs-9", "unity-docs-20" ] }, { "productId": "unity", "storyId": "npm-installable-runtime", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "unity", "storyId": "official-ai-copilot", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-14", "unity-probe-rt-1", "unity-probe-4" ] }, { "productId": "unity", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-21", "unity-comm-2", "unity-comm-7", "unity-comm-12", "unity-comm-15" ] }, { "productId": "unity", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-docs-10", "unity-docs-11", "unity-probe-3", "unity-probe-5" ] }, { "productId": "unity", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "unity", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-13", "unity-docs-15", "unity-probe-rt-1" ] }, { "productId": "unity", "storyId": "openness-self-host", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-docs-9", "unity-probe-rt-1", "unity-probe-rt-3", "unity-comm-13" ] }, { "productId": "unity", "storyId": "performance-at-scale", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "unity", "storyId": "permissive-license-no-royalties", "verdict": "disputed", "quality": 3, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-docs-21", "unity-comm-2", "unity-comm-12", "unity-comm-15", "unity-comm-7" ] }, { "productId": "unity", "storyId": "pricing-terms-stability", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "unity-comm-2", "unity-comm-12", "unity-comm-15", "unity-docs-21" ] }, { "productId": "unity", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of data residency, regional storage options, or compliance controls for where Unity Cloud/AI data is stored; only general product, pricing, and AI-credits documentation is present. This is a fair question for a platform with cloud services and AI features, so absence of evidence means 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "unity", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item addresses opting out of AI training data usage, data privacy controls for Unity AI features, or any policy/toggle preventing content from being used to train models; only unrelated docs, pricing/community drama, and MCP/CLI evidence are present.", "evidenceIds": [] }, { "productId": "unity", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unity is a game engine/development platform, not an AI service that collects and retains user data on a subject's behalf; data retention/deletion controls for AI-native usage is a category mismatch for this axis (only Unity Credits/AI Assistant usage is mentioned, with no retention/deletion controls documented).", "evidenceIds": [] }, { "productId": "unity", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item documents a telemetry opt-out setting or privacy control for Unity; the only related evidence is a community complaint about unwanted 'phone home' logging (unity-comm-14), which if anything suggests telemetry behavior was hard to avoid rather than confirming an opt-out mechanism exists.", "evidenceIds": [ "unity-comm-14" ] }, { "productId": "unity", "storyId": "productive-scripting-language", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-11", "unity-comm-4" ] }, { "productId": "unity", "storyId": "runtime-ml-inference", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Unity's editor AI Assistant, MCP integration, and general engine features, but contains no mention of an on-device ML inference runtime (e.g., Unity Sentis/Barracuda) for running models inside a shipped game. Absence of evidence for this applicable capability means it cannot be credited.", "evidenceIds": [] }, { "productId": "unity", "storyId": "scripted-asset-import", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "unity-docs-10", "unity-docs-11", "unity-docs-12", "unity-docs-6", "unity-docs-7", "unity-docs-8", "unity-docs-13" ] }, { "productId": "unity", "storyId": "standard-asset-formats", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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'.", "evidenceIds": [] }, { "productId": "unity", "storyId": "visual-scripting", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "agent-editor-control", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Unreal documents a genuine scriptable interface — the Python Editor Scripting API for asset/property automation (docs-4, docs-12), Blueprints for visual node-based logic (docs-1), and CLI/UAT commands for cooking, packaging and triggering builds (docs-7,14,16,17) — which together let a script or agent create/edit content and trigger builds. However, the probe evidence shows no official Epic MCP server or AI-agent-oriented interface exists (0 results for org:EpicGames MCP repos), the most popular community MCP wrapper is unmaintained since 2025, and the docs themselves are not agent-friendly (SPA HTML, no llms.txt, .md suffix doesn't return markdown), undermining ease of programmatic/agentic access despite the underlying scripting capability being real. Missing for 10: official AI-agent/MCP integration, machine-readable documentation, evidence of an agent actually driving these interfaces end-to-end.", "evidenceIds": [ "unreal-docs-4", "unreal-docs-12", "unreal-docs-1", "unreal-docs-7", "unreal-docs-16", "unreal-docs-17", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "A direct probe found no llms.txt on Epic's domains, and appending .md to docs URLs returns the HTML SPA shell rather than agent-readable markdown, meaning there is no mechanism to point an agent at machine-readable docs.", "evidenceIds": [ "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack of Unreal Engine surfacing AI-generated insights or suggestions from project data; docs cover Blueprints, C++, Python scripting, plugins, and networking but nothing about analytics/AI-driven suggestions, and the probe notes the engine has no official MCP or AI-native tooling exposure.", "evidenceIds": [ "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Unreal exposes Python editor scripting, commandlets, and UAT/command-line automation that can be scripted to run unattended (e.g., asset processing, cooking, packaging) which supports background automation, but nothing in the evidence describes an AI-native agent framework, scheduler, or official API/MCP for autonomous orchestration — and the probe explicitly notes no official Epic MCP and no machine-readable API, undermining AI-native automation setup. missing for 10: official AI-agent/automation orchestration layer, documented scheduling/trigger system for unattended runs, first-party API or MCP for AI agents to invoke automations.", "evidenceIds": [ "unreal-docs-4", "unreal-docs-7", "unreal-docs-14", "unreal-docs-16", "unreal-docs-17", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack of any built-in AI assistant inside Unreal Editor that users can delegate tasks to; all documentation covers Blueprints, C++, Python scripting, plugins, and CLI tools, not an AI agent. The probe evidence even notes the lack of any official Epic AI/MCP integration.", "evidenceIds": [ "unreal-probe-rt-1", "unreal-docs-4", "unreal-docs-5" ] }, { "productId": "unreal", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs show real automation building blocks: command-line launch arguments (unreal-docs-7, unreal-docs-14), UAT commands for cooking/packaging/deploying (unreal-docs-16, unreal-docs-17), and Python editor scripting for automating asset tasks (unreal-docs-4), all of which are commonly used to run Unreal headlessly in CI pipelines. However, there is no explicit first-party 'headless mode' or CI-integration guide, and the probe notes Unreal's docs/repos are largely non-machine-readable (403s, no llms.txt, no official MCP), suggesting automation setup requires manual/expert configuration rather than a turnkey CI story. Missing for 10: dedicated headless-mode documentation, official CI/CD templates (e.g., GitHub Actions), and independent hands-on confirmation of CI pipelines running Unreal successfully.", "evidenceIds": [ "unreal-docs-7", "unreal-docs-14", "unreal-docs-16", "unreal-docs-17", "unreal-docs-4", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Unreal Engine is a platform/tool (not an agent), so the MCP-server axis fairly applies, but evidence shows no official Epic-maintained MCP server exists (GitHub search for `mcp org:EpicGames` returns 0 results) and the most popular community MCP integration is unmaintained since 2025, meaning there's no first-party way to plug MCP servers into Unreal for tool use.", "evidenceIds": [ "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Unreal Engine is a platform/tool (not itself an agent), so an official MCP server axis applies, but evidence shows no official Epic MCP server exists — a GitHub org search returns 0 results, and the most popular community MCP integration is unmaintained since 2025.", "evidenceIds": [ "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only traditional scripting/programming interfaces (Blueprints, C++, Python, CLI args) with no natural-language command layer; the probe explicitly notes no official Epic MCP server, no llms.txt, and only an unmaintained community MCP project, meaning there's no documented way to operate Unreal via natural-language commands.", "evidenceIds": [ "unreal-probe-rt-1", "unreal-docs-4", "unreal-docs-1" ] }, { "productId": "unreal", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Unreal ships an official CLI surface: UnrealEditor.exe/UAT commands for cooking, packaging, deploying and running projects, plus documented command-line arguments for automation and testing, and Python editor scripting for scriptable workflows — all first-party and independently confirmed as keylessly fetchable per the probe. missing for 10: explicit AI-native framing or agent-oriented tooling around the CLI, and independent hands-on validation of using it in agentic workflows.", "evidenceIds": [ "unreal-docs-7", "unreal-docs-14", "unreal-docs-16", "unreal-docs-17", "unreal-docs-4", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Unreal ships genuinely documented public APIs — a Python editor-scripting API for automating asset/editor tasks, a C++ gameplay API, and command-line/UAT automation flags — which a user or script can drive programmatically. However, the probe evidence shows these are not AI-native accessible: no official Epic MCP server, no llms.txt, docs served only as an HTML SPA (no .md fetch), and the GitHub source repo is EULA/account-gated returning 404 to unauthenticated API calls, with the leading community MCP abandoned since April 2025. Missing for 10: AI-agent-discoverable/machine-readable API docs, an official MCP or agent-facing interface, and keyless programmatic access to source/API metadata.", "evidenceIds": [ "unreal-docs-4", "unreal-docs-12", "unreal-docs-7", "unreal-docs-14", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence anywhere in the pack describes an API credential system, scoped tokens, or least-privilege access controls for AI agents interacting with Unreal Engine or its services; the docs cover Blueprints, C++, plugins, and CLI tools but not credential/permission management. Missing for 10: any mention of API keys/tokens, scoped or role-based access, or agent-specific credential issuance.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "agentic-sdks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Unreal ships extensive official build surfaces — C++ APIs, Python editor-scripting API, Blueprint visual scripting, plugin SDK, and CLI/automation tooling — all documented on dev.epicgames.com, which functions as an official SDK for building games/tools. However, the probe evidence shows these are poorly suited for AI-native/agentic consumption: no official MCP server exists, GitHub source access is gated (404 without auth), main sites 403 non-browser clients, no llms.txt, and docs aren't served as fetchable markdown, undercutting AI-native usability of the SDK. Missing for 10: official MCP server or agent-friendly API, machine-readable/llms.txt documentation, keyless programmatic access to source and APIs.", "evidenceIds": [ "unreal-docs-2", "unreal-docs-4", "unreal-docs-13", "unreal-docs-18", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unreal Engine is a game engine/development platform, not a SaaS/service with an event stream; webhook subscriptions for external event notification are not a fit axis for this product category.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows only standard static documentation pages (C++, Blueprints, Python scripting, plugins) with no interactive API reference or runnable/executable code examples; the probe evidence explicitly notes Unreal's docs are not even machine-readable (no llms.txt, .md URLs return HTML shell) and there's no official API sandbox or live-code explorer mentioned anywhere.", "evidenceIds": [ "unreal-probe-rt-1", "unreal-docs-2", "unreal-docs-4" ] }, { "productId": "unreal", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an OpenAPI or similar machine-readable API spec; the probe evidence explicitly finds Unreal's docs and APIs are not machine-readable (no llms.txt, .md docs serve HTML shells, no official MCP/API spec), confirming absence rather than just lack of mention.", "evidenceIds": [ "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "unreal", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item documents API versioning conventions or a deprecation policy for Unreal's C++/Blueprint/Python APIs; the docs cover feature usage (Blueprints, C++, plugins, replication) but never mention deprecation macros, version compatibility guarantees, or a documented sunset policy. The probe evidence further shows Unreal's docs/API surface is poorly machine-readable, with no llms.txt or markdown API references that would expose such a policy.", "evidenceIds": [ "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "asset-marketplace", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs show a genuine plugin and asset-management ecosystem (plugins can add gameplay features, new file types, editor extensions; Asset Manager for content organization) and community comment notes strong third-party program/community support, but there is no direct evidence in the pack describing the actual Marketplace/Fab asset store, its catalog size, or the quality of ready-made models — the probe entry only notes fab.com exists but is API-gated, not its content richness. Missing for 10: concrete marketplace/store catalog evidence, examples of ready-made models/tools available, and independent user reviews of the store experience.", "evidenceIds": [ "unreal-docs-5", "unreal-docs-13", "unreal-docs-6", "unreal-docs-12", "unreal-comm-3", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Unreal's Python editor-scripting API and Asset Manager are documented to automate time-consuming asset tasks (e.g., batch-generating LODs for Static Meshes) and manage large sets of Assets in chunks, which supports bulk operations across many items, and UAT/command-line tooling and cooking commands support batch build/deploy across multiple platforms/targets. However there is no concrete first-party example of an AI-native agent performing bulk edits, no official MCP server, and the probe evidence flags Unreal as the least machine-readable/agent-accessible of comparable products (gated APIs, 403s, no llms.txt), undercutting AI-native automation-depth claims. Missing for 10: worked examples of bulk operations orchestrated end-to-end, official AI/agent tooling or MCP integration, independent hands-on confirmation of scripted bulk workflows.", "evidenceIds": [ "unreal-docs-4", "unreal-docs-6", "unreal-docs-12", "unreal-docs-16", "unreal-docs-17", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "automation-rules-engine", "verdict": "full", "quality": 6, "confidence": "medium", "rationale": "Unreal's Blueprint visual scripting and C++ delegate system explicitly support binding functions to be invoked automatically at a future time/event (dynamic delegates), and Blueprints expose event graphs for designers to wire up event-triggered logic without code. Community commentary confirms Blueprints are used for prototyping event-driven logic though complexity pushes users to C++. Missing for 10: explicit documentation of Event Dispatchers/Event Graph event-binding UI, and independent hands-on validation of rule-trigger reliability at scale.", "evidenceIds": [ "unreal-docs-1", "unreal-docs-3", "unreal-comm-15" ] }, { "productId": "unreal", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Unreal has CLI automation, Python editor scripting, and UAT commands for one-off automation tasks (e.g. asset processing, cooking/packaging), but nothing about built-in scheduling of recurring jobs or workflows — that would require external tooling like Jenkins/cron, which isn't documented here.", "evidenceIds": [ "unreal-docs-4", "unreal-docs-7", "unreal-docs-14", "unreal-docs-16", "unreal-docs-17" ] }, { "productId": "unreal", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers Blueprints, C++, Python scripting, plugins, asset management, and cooking, but contains no mention of version control integration, change review/diffing, or rollback mechanisms for Blueprints, Python scripts, or other automations. This is a plausible axis for a dev engine (e.g., source control on Blueprints), but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "browser-deployment", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The only evidence touching web export is a decade-old community comment noting 'UE4.7 can export to HTML5 too' (unreal-comm-14) — there is no current documentation, no mention of WebGL, no mention of WebGPU, and no discussion of browser payload size or a credible modern web-export pipeline. Given Unreal actually removed HTML5/WebGL export in later versions, this stale anecdote does not establish a current capability.", "evidenceIds": [ "unreal-comm-14" ] }, { "productId": "unreal", "storyId": "builtin-physics", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no documentation, community reports, or probes specifically addressing Unreal's physics system (rigid bodies, collision detection, raycasting, Chaos/PhysX). Coverage is entirely about Blueprints, C++, plugins, asset management, networking, licensing, and community sentiment on cost/usability — none of which substantiates the built-in physics story.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "codegen-friendly-apis", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence directly addresses whether LLM-generated Unreal C++/Blueprint code works reliably on first try; the pack only shows general API docs exist and community comments about C++ complexity and blueprint limitations. The probe evidence even indicates docs are poorly machine-readable (403s, no llms.txt, gated source) which undercuts the 'abundant examples models have seen' premise but isn't a direct test of code-gen success either.", "evidenceIds": [ "unreal-docs-2", "unreal-comm-7", "unreal-comm-15", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "collaboration-versioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of Unreal's scene/level file formats, diffability, source-control integration (e.g., Perforce/Git-LFS workflows), or any built-in multi-user collaboration tooling; it only covers Blueprints, C++, plugins, networking replication, and licensing. Missing for 10: any documentation or community evidence on .uasset/.umap format mergeability, text-based diffable formats, or built-in collaboration features like Multi-User Editing.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "dedicated-server-runtime", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers general networking/replication (client-server sync), command-line arguments, and cooking/packaging, but nowhere mentions Unreal's dedicated-server build target, a headless/no-rendering server runtime, or how to produce a server-only executable. Without explicit documentation of a server-only build path, this axis is unsupported by the given evidence. Missing for 10: any mention of a 'Server' build target, -server or -nullrhi headless launch flags, or dedicated-server packaging instructions.", "evidenceIds": [ "unreal-docs-8", "unreal-docs-15", "unreal-docs-16", "unreal-docs-17", "unreal-docs-14" ] }, { "productId": "unreal", "storyId": "editor-scripting-extensibility", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs confirm multiple official extension paths: Python editor scripting for automating asset/editor tasks, Blueprints for designer-level scripting, C++ for deep gameplay/editor class extension, and a Plugins system explicitly designed to 'extend the capabilities of the Editor.' These are core, well-documented first-party mechanisms for programmatic scene/asset manipulation and editor customization. Missing for 10: independent hands-on corroboration specifically of the Python/editor-scripting API (community evidence mostly discusses C++/Blueprint complexity rather than editor automation), and no mention of newer scripting surfaces like the Editor Utility Widgets or Python API depth in third-party sources.", "evidenceIds": [ "unreal-docs-4", "unreal-docs-5", "unreal-docs-13", "unreal-docs-1", "unreal-docs-2", "unreal-comm-15" ] }, { "productId": "unreal", "storyId": "fast-iteration-loop", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm Blueprints allow instant in-editor scripting changes without recompilation, and C++ changes are 'reflected in the Unreal Editor after compiling' via Visual Studio/XCode, indicating a hot-reload/live-coding workflow exists. However, no evidence quantifies compile/reload speed, mentions the dedicated 'Live Coding' feature explicitly, or provides independent hands-on confirmation that the loop is fast rather than just functional. Missing for 10: benchmark/timing evidence on hot reload speed, explicit mention of Live Coding feature, independent developer testimony on edit-run loop responsiveness.", "evidenceIds": [ "unreal-docs-1", "unreal-docs-2", "unreal-docs-11" ] }, { "productId": "unreal", "storyId": "first-class-2d", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of sprites, tilemaps, Paper2D, or 2D physics support in Unreal Engine—only C++, Blueprints, plugins, networking, and licensing topics. Since a 3D-first engine could plausibly ship a first-class 2D workflow, this axis applies, but no evidence documents it, so the story is unsupported.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "full-scene-editor", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Unreal's editor-centric workflow (Blueprints visual scripting, Editor extensions, Asset Manager, Level building/testing via UE Toolbar) is well documented as the primary way to construct levels and gameplay without programmer-only tools, and community comments (comm-3, comm-11, comm-16) corroborate that it's an actual GUI-driven editor experience artists use. missing for 10: explicit documentation naming 'viewport' and 'inspector' panels, and 'prefab' terminology (Unreal uses Blueprint/Actor classes instead) with independent hands-on confirmation of scene-composition workflow specifically for technical artists.", "evidenceIds": [ "unreal-docs-1", "unreal-docs-5", "unreal-docs-6", "unreal-docs-9", "unreal-comm-3", "unreal-comm-16" ] }, { "productId": "unreal", "storyId": "full-source-access", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Epic's license page explicitly grants 'Access to the source code' and docs describe creating new Gameplay C++ classes that recompile directly into the Editor, and community comments corroborate 'source code included.' Missing for 10: independent hands-on account of actually patching core engine internals (not just gameplay classes), and the probe notes the source repo is EULA/GitHub-account gated rather than freely open, which adds friction to the 'when I hit a wall' scenario.", "evidenceIds": [ "unreal-docs-10", "unreal-docs-18", "unreal-docs-2", "unreal-docs-11", "unreal-comm-12", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "headless-cli-builds", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Official docs give concrete CLI commands for headless building/cooking/packaging/deploying a project (UnrealEditor.exe -run=cook, and the build/cook/package/deploy/run automation command), plus a dedicated command-line-arguments reference for scripted/CI use, all without needing to open the editor UI. Missing for 10: independent third-party CI pipeline case study confirming it works end-to-end, and explicit mention of UAT/BuildCookRun tool name or exit-code/scripting integration details.", "evidenceIds": [ "unreal-docs-16", "unreal-docs-17", "unreal-docs-14", "unreal-docs-7", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "headless-test-runs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack only shows generic command-line argument docs and a UE Toolbar mention for ad-hoc level testing/debugging; there is no evidence of Unreal's Automation System, Gauntlet, or any documented headless unit/integration test execution flow running the real engine in CI. Missing for 10: mention of the Automation Testing framework, -nullrhi/-unattended/-ExecCmds test invocation, CI integration examples, or independent reports of headless test runs against the real engine.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "modern-3d-rendering", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Community evidence confirms Unreal's renderer includes Lumen for real-time global illumination/reflections and general praise for lighting quality, supporting the GI/rendering claim, but the evidence pack lacks first-party documentation or hands-on confirmation of PBR material workflows, shadow systems, or the post-processing pipeline explicitly. missing for 10: explicit docs/evidence on PBR material editor, shadow mapping/ray-traced shadows, and post-process volume/effects stack.", "evidenceIds": [ "unreal-comm-6", "unreal-comm-14" ] }, { "productId": "unreal", "storyId": "multi-platform-export", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs show a single project can be cooked/packaged/deployed to multiple target platforms via the cook/package pipeline (unreal-docs-16, unreal-docs-17) and tested across platforms via the toolbar (unreal-docs-9), and community mentions cross-platform export (e.g., HTML5) confirm this in practice (unreal-comm-14). However, the evidence pack contains no explicit documentation or independent confirmation of console export specifics (partner/licensee console SDK integration), so console support is inferred rather than directly evidenced. Missing for 10: explicit console-platform export/partner-program documentation, independent studio confirmation of a single project shipping to consoles.", "evidenceIds": [ "unreal-docs-16", "unreal-docs-17", "unreal-docs-9", "unreal-comm-14" ] }, { "productId": "unreal", "storyId": "npm-installable-runtime", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "unreal", "storyId": "official-ai-copilot", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official in-engine AI assistant for generating scripts, answering API questions, or scaffolding scenes; the pack only covers Blueprints, C++, Python editor scripting, and plugins as manual tooling. The probe evidence explicitly notes no official Epic MCP/AI integration and that the most popular community MCP project is unmaintained.", "evidenceIds": [ "unreal-probe-rt-1", "unreal-docs-4" ] }, { "productId": "unreal", "storyId": "open-governance-funding", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers licensing costs, royalty terms, and technical documentation, but nothing indicates a governing foundation, published financial statements, or a public roadmap for Unreal Engine — Epic Games remains a private, closed-governance company with only EULA/royalty terms disclosed (unreal-docs-10, unreal-comm-9, unreal-comm-13).", "evidenceIds": [ "unreal-docs-10", "unreal-comm-9", "unreal-comm-13" ] }, { "productId": "unreal", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Unreal exposes substantial programmatic surfaces (Python editor scripting, C++ gameplay/engine API, Blueprints, command-line/UAT automation) that cover many editor and runtime tasks, but there is no documentation or evidence claiming full UI/API parity — some editor UI workflows (e.g. certain asset browser, viewport, or complex tooling operations) are not confirmed as scriptable, and the probe notes the engine is poorly machine-accessible overall (gated source repo, 403s on core domains, no official MCP, docs not served as markdown). missing for 10: an explicit statement/spec of full UI-API parity, evidence that every UI action has an API equivalent, and better machine-readable API discovery for AI agents.", "evidenceIds": [ "unreal-docs-1", "unreal-docs-4", "unreal-docs-12", "unreal-docs-2", "unreal-docs-7", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers Blueprints, C++, plugins, source-code access, and asset management, but nothing addresses exporting a project's proprietary .uasset/.umap data into open interchange formats to allow a clean migration away from Unreal. The probe evidence even highlights poor machine-readable/open access to Epic's own ecosystem, reinforcing the lack of a data-portability story.", "evidenceIds": [ "unreal-docs-6", "unreal-docs-12", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "openness-open-license", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Epic's own licensing page claims 'access to the source code' (unreal-docs-10, unreal-docs-18), but this is EULA/account-gated rather than an open-license grant — the probe confirms the GitHub source repo returns 404 without an authenticated, linked Epic account and all first-party domains block non-browser access, meaning the source is not freely readable under an open license as an AI-native user would need. Missing for 10: no OSI-approved or otherwise open license governing the source, no keyless/anonymous access to the code, no llms.txt or machine-readable confirmation of licensing terms.", "evidenceIds": [ "unreal-docs-10", "unreal-docs-18", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "openness-self-host", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Unreal ships as a locally-installed engine with source-code access (unreal-docs-10/18), so the core product is inherently self-hostable rather than SaaS-only. However, the probe evidence shows source access is EULA/account-gated (must link a GitHub account to Epic), the GitHub repo is not publicly discoverable via API, and there is no simple open self-hosting path comparable to fully open-source engines. Missing for 10: unrestricted/public source access, no account-gating requirement, first-party documentation framing self-hosting as an explicit feature.", "evidenceIds": [ "unreal-docs-10", "unreal-docs-18", "unreal-probe-rt-1" ] }, { "productId": "unreal", "storyId": "performance-at-scale", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation or community evidence about Unreal Insights, stat/profiling commands, GPU profiling, or data-oriented paths like Mass Entity/ECS, job systems, or GPU instancing — only generic command-line-argument docs mentioning 'testing and optimizing' in passing. Profiling and data-oriented scaling are core, expected capabilities for a AAA game engine, so the axis applies, but nothing in the pack demonstrates a real profiler or ECS/jobs/instancing systems.", "evidenceIds": [ "unreal-docs-7", "unreal-docs-14" ] }, { "productId": "unreal", "storyId": "permissive-license-no-royalties", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Community evidence explicitly documents that Unreal charges a 5% royalty on gross revenue after the first $1M (or $3,000/quarter) — this is the opposite of 'no royalties, keep what you earn.' No evidence pack item supports a royalty-free/no-fee licensing model; instead multiple citations (comm-1, comm-9, comm-13, comm-2) confirm a royalty-based commercial license.", "evidenceIds": [ "unreal-comm-1", "unreal-comm-9", "unreal-comm-13", "unreal-comm-2" ] }, { "productId": "unreal", "storyId": "pricing-terms-stability", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The pack shows royalty terms changed over time (5% of gross → 5% after $3,000/quarter) but no evidence addresses whether such changes were ever applied retroactively to already-shipped titles or whether Epic has an explicit no-retroactive-repricing policy/track record. Missing for 10: documented policy or community confirmation that license terms are grandfathered for shipped games, evidence of any past retroactive-change controversy or its resolution.", "evidenceIds": [ "unreal-comm-13", "unreal-comm-9", "unreal-docs-10" ] }, { "productId": "unreal", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unreal Engine is a locally-installed/self-hosted game engine, not a cloud SaaS that stores user data on the vendor's servers; data residency/region selection is not a meaningful axis for this product category. Evidence pack contains no mention of hosted data storage or region choice, consistent with this being a category error rather than a missing feature.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unreal Engine is a game engine/development tool, not an AI model provider or SaaS with a data-training policy; the evidence pack contains nothing about AI training data opt-outs and this axis is a category error for an engine product.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Unreal Engine is a game engine/development tool, not a data-processing SaaS or AI service that collects user data on users' behalf; data retention/deletion controls are a category mismatch — this axis is designed for hosted services handling user data, not a locally-installed engine/SDK.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry, analytics, or usage-tracking opt-out settings for Unreal Engine or the Editor; all docs and community items concern scripting, licensing, and pricing topics unrelated to privacy controls.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "productive-scripting-language", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs show C++ as the primary language with full engine API exposure (new Gameplay classes, delegates binding to arbitrary objects) and it compiles/reflects via Visual Studio/XCode, implying standard IDE debugger support, while Blueprints (the more 'scripting'-like option) explicitly trades off some API depth for accessibility (unreal-docs-1,2,3,11). Community evidence corroborates a productivity/API-completeness tension: Blueprints alone are 'not sufficient' for real scripting tasks and require C++ fallback, and multiple developers cite C++ as their 'main problem' with UE (unreal-comm-4, unreal-comm-7, unreal-comm-15). Missing for 10: no explicit documentation of an integrated scripting debugger workflow (only external Visual Studio/Xcode debugging is implied), and no first-party evidence that any single primary language achieves both full productivity and full API coverage without trade-offs.", "evidenceIds": [ "unreal-docs-1", "unreal-docs-2", "unreal-docs-3", "unreal-docs-11", "unreal-comm-4", "unreal-comm-7", "unreal-comm-15" ] }, { "productId": "unreal", "storyId": "runtime-ml-inference", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of an on-device ML inference runtime (e.g., NNE, ONNX Runtime integration) for Unreal Engine; documentation citations cover Blueprints, C++, Python scripting, plugins, networking, and packaging, but nothing about running ML models in-game. Since game engines can plausibly ship such runtimes, this axis applies, but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "scripted-asset-import", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm Python scripting can automate asset-management tasks like LOD generation, and the Asset Manager gives programmatic control over asset discovery/loading, while Plugins can add new file-type handling — together these support scripted, non-interactive asset pipelines. However, there's no explicit documentation of dedicated 'import hooks' (e.g. post-import delegates/factories) or preset-based automated import workflows, and no independent/community confirmation that artists actually use this for hands-off batch import. missing for 10: explicit import-hook/factory API docs, named import-preset tooling, and third-party/community validation of automated import pipelines.", "evidenceIds": [ "unreal-docs-4", "unreal-docs-6", "unreal-docs-12", "unreal-docs-5", "unreal-docs-13" ] }, { "productId": "unreal", "storyId": "standard-asset-formats", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no documentation, community, or probe citations addressing glTF, FBX, or USD import functionality in Unreal Engine; all provided docs cover Blueprints, C++, plugins, networking, and licensing instead. Since asset-pipeline import is a fair and applicable axis for a game engine, but no supporting evidence exists in this pack, the verdict is none.", "evidenceIds": [] }, { "productId": "unreal", "storyId": "visual-scripting", "verdict": "disputed", "quality": 6, "confidence": "medium", "rationale": "Epic's docs confirm Blueprints let designers use most programmer-level tools without code (unreal-docs-1), and this is Unreal's flagship visual-scripting system for gameplay logic. However, hands-on community reports concretely contradict full no-code sufficiency: one dev states Blueprints were 'not sufficient' for adding content like vehicles and required C++ (unreal-comm-4), and another notes complex Blueprint graphs 'cascade inefficiencies' making C++ necessary at scale (unreal-comm-15), with a third citing C++ as the main pain point when trying to avoid it (unreal-comm-7). Missing for 10: independent case studies of large shipped games built purely in Blueprints without C++ fallback, and clearer scoping of what gameplay complexity Blueprints alone can handle.", "evidenceIds": [ "unreal-docs-1", "unreal-comm-4", "unreal-comm-15", "unreal-comm-7" ] } ]