Performance budgets

Optimisation is a design input, not a final pass. Every asset and system has a budget before it is built, and the budget is checked by a logged test. Outcomes are identical on every tier. Tiers only change how things look.

◆Frame targets

Within a frame on High: gameplay/sim ≤ 2 ms, animation ≤ 2.5 ms, culling/LOD ≤ 1 ms, render submit ≤ 4 ms, UI ≤ 1 ms, the rest goes to the GPU. Dynamic resolution holds the frame budget before any visual feature is dropped.

Platform limit (checked 2026-10-06): Unity supports dynamic resolution on Metal, Vulkan and DirectX 12 only (Unity manual). The Web build and any OpenGL ES device need a fixed render scale picked by the capability probe and changed only at safe moments. The GPU Resident Drawer has similar limits (Forward+ and compute shaders; not Web or OpenGL ES; Mesh Renderers only). The per-platform table, five named perf scenes and the extra targets (zero garbage in combat, shader prewarm, frame spread) are proposed in the AAA detail catalog.

◆Reference hardware (owner direction, 2026-10-05)

Use entry-level hardware as the floor, as delegated by the owner. These selected configurations require physical validation; their specifications do not establish measured game compatibility. Canonical record: reference-devices.json.

Sources checked 2026-10-05. Record each physical unit's exact SKU, OS build, GPU driver/API, real RAM and storage; RAM expansion is not physical RAM. No devices have been purchased or benchmarked by this documentation task. The capability probe (M0-05) logs one ZOEN_PROBE line per client run against the contract in reference-devices.json → probe; owner-device results are labelled with their probe and never validate a Low reference, whose probes stay pending until units exist. The owner's M3 stays a secondary development reference (Chrome; its native app is paused since 2026-10-11, ADR-032) and the owner's Windows PC (unprobed until WIN-01) is the High test machine; neither can substitute for the Windows Low probe. The Mac's native app and Chrome runs are measured (2026-10-08, M0-05C: ownerTestDevices[].probes, merged table logs/evidence/M0-05C/probe-summary.txt); so is the owner's phone (nubia NX709S) in Chrome (2026-10-08, M0-05D) and as the native APK (2026-10-08, M0-05E: Vulkan 1.1, 18 GB class memory, ASTC/BC/ETC2, Mid from the cached benchmark). Unity's Android player cuts a log entry at 1023 bytes, so on Android the probe is logged as ZOEN_PROBE_PART i/n lines of at most 800 bytes (reference-devices.json → probe.partNote).

The starting gate reuses Low 30 fps / 33.3 ms / process or tab ≤600 MB and the existing 30-minute playtest. Profile native and supported browsers separately: both views, camp/crowd/boss telegraphs, boss music, sustained mana-limited 0.3 s dash reuse, jumps, collisions, chunk streaming and background/resume. Log p50/p95/p99 frame time, draw calls, particles, memory, thermal degradation and input response. Keep warnings visible when reducing decoration. Exact acceptance targets remain proposed until the feasibility gate supplies measurements. A failure requires optimization or an explicit baseline revision; do not silently raise minimum hardware.

◆Platform caps (owner, round 4)

The full High/Ultra experience is in the downloaded apps; the browser stays light and smooth. Data: feel-quality.json → platformCaps. The client's starting-tier rules (low-memory phone, low-end browser, native startup benchmark, the phone Ultra gate) and the per-tier frame caps above are proposed in feel-quality.json → tierSelection (M0-04C); the client reads them from there. Engine review: Engine & platforms. Capability probing selects Low on the entry-level references before heavier content loads; platform defaults do not force Mid/High onto weak hardware.

◆Budgets by tier

◆Asset budgets

Textures compress per platform on import: BC7 (Windows), ASTC (Android/iOS), ASTC/ETC2 for the Web build. Meshes use Unity mesh compression; streamed content ships as Addressables bundles. Skinned meshes use ≤ 4 bone influences and ≤ 80 bones.

◆Download and startup

◆Network and server

Downstream ≤ 12 KB/s typical, ≤ 32 KB/s cap per client. Upstream ≈ 0.3 KB/s. Server tick p99 ≤ 15 ms at 1,000 players. Details in 1,000 players per map.

◆Techniques we rely on

• Instancing everywhere: GPU Resident Drawer / GPU instancing (RenderMeshInstanced) for vegetation, rocks, projectiles, damage numbers and baked-animation crowds.
• SRP Batcher (all targets) and GPU Resident Drawer (native) for static geometry, plus frustum + distance culling per chunk.
• Pools, not allocations: projectiles, emitters, decals, audio voices and damage numbers come from fixed pools. No new in the frame loop.
• Animation LOD: update rate drops with distance (60 → 30 → 15 Hz), and off-screen characters skip bone evaluation.
• Shader variant budget: ≤ 64 material variants, prewarmed in a loading phase (no hitch on the first cast).
• VFX LOD: every effect has Low/High definitions with the same timing and footprint. Optional tails/sparks drop first. The per-tier feel layers (debris, decals, lights, screen effects) are listed in feel-quality.json and VFX.
• UI: the UI Toolkit HUD updates bound values only when they change; no per-frame allocations.
• Dynamic resolution and frame pacing: keep frame time stable instead of chasing peaks.

◆How budgets are tested

• Perf harness scenes (Combat Lab, town crowd, boss fight) run as PlayMode tests with the Unity Performance Testing package (Web build: Playwright drives the page) and write perf.json with p50/p95/p99 frame time, frames over 33 ms, draw calls, triangles, particles, managed heap and GPU memory estimate.
• Each milestone repeats them on the reference devices (manual run, logged with task-log.mjs test).
• An asset validator script rejects assets over budget (tris, bones, texture size, missing LODs) before they enter the build.