Engine & platforms (review)

Status: accepted by the owner (round 6, 2026-10-04) — ADR-024 supersedes ADR-002. The docs, stack and roadmap now describe the Unity client. No engine work has started (all milestones are NOT_STARTED); M0 begins once the owner has installed Unity Hub and the pinned LTS (see the toolkit).

◆Why the guide said Babylon.js before round 6

Round 1 targeted browser and mobile web first: instant start, a small download, and text-only sources that AI agents can build and test from a CLI. For that goal a web-native engine (TypeScript + Babylon.js) was the simplest fit, and the wiki's Feel Lab is built with it. The earlier Jade Caravan plan had chosen Unity 6.3 LTS + URP + C# + Blender, with Mirror/secure WebSockets as the networking candidate.

◆What the owner's plan changes (decided, round 4)

• Targets: Windows, Android, iOS and the browser.
• Browser: hard cap at Low–Mid quality (a good, light experience).
• Full experience (High and Ultra) is for the downloaded apps on Windows and phones.

This moves the centre of gravity from "web first" to native first, web as a lighter build. Native High/Ultra (dynamic lights, GPU particles, post effects, large crowds) is where a full engine with a native renderer pays off.

◆Options compared

◆Recommendation

1. Client: Unity 6 LTS + URP + C# for Windows, Android, iOS and the Web build, from one project:
   • Quality profiles: Low, Mid, High and Ultra on native. The Web build ships only the Low and Mid profiles (smaller texture and VFX variants via Addressables), which enforces the browser cap.
   • Web graphics: WebGL2 at launch. WebGPU once the 6.x LTS with production WebGPU is pinned, and only after a measured Web gate.
   • Pin the LTS for production and verify the exact patch at M0. 6.3 is current; check whether 6.7 LTS has shipped.
2. Servers: keep Rust (ADR-003): 1,000 players per channel at 20 Hz, no garbage-collection pauses. The server never depended on the client engine.
3. Shared rules:
   • Today zoen-sim was going to be compiled to WASM for client prediction. With Unity, the small prediction subset (movement, collision against the walkability grid, cooldowns, cast phases) is written in C#.
   • Both sides must pass the same golden test vectors, generated as JSON from the Rust crate and stored in packages/sim-golden. Since ADR-029 the client first tries the Rust crate itself as a plugin (spike M0-11); the C# subset is the fallback.
   • The protocol schema generates Rust and C#.
4. Wiki Feel Lab stays Babylon.js: it is previz inside the wiki, not the game client. Its timing rules, reaction rule and feel tiers (feel-quality.json) are engine-neutral data the Unity client reads.
5. Tooling (from the specs5 review, all still gated):
   • No Unity MCP (owner direction, M0-07, 2026-10-08): the CoplayDev/unity-mcp smoke test was skipped; agents use batchmode and tools/unity-run.mjs. Test Framework 1.6.0 and Performance Testing 3.5.0 are pinned (UNITY_TOOLKIT.md).
   • GameCI test-runner and builder for CI: needs a Unity licence secret that the owner provides.
   • Blender MCP stays deferred.
   • Unity Test Framework from the CLI is the default test path for agents.

Why not stay on Babylon? It is the best browser engine, but with native apps as the main experience, every platform would run inside a WebView at browser performance. That contradicts the High/Ultra goal. Godot is a fair alternative, but its web export can't share the Forward+ look, and the Jade Caravan plan, tutorials, tooling review and the owner's expectation all point to Unity.

◆Migration (done in the docs, round 6)

Checked 2026-10-04. Re-verify the Unity versions and plan terms on unity.com before installing.