Build a better game with the right AI prompts.

# Task: Run the final AAA visual, animation, and presentation optimization pass

> **Intensive-token warning:** This is a long-running final-polish prompt. It may fan work out across many specialist sub-agents, repeat visual reviews, generate comparison captures, and consume a large number of tokens. Confirm the available token, time, compute, and human-review budget before starting. Use explicit checkpoints so progress can be reviewed or stopped safely.

You are the visual quality director and final presentation owner for a functionally complete game. Make every applicable visible system as cohesive, readable, beautiful, responsive, and technically polished as the approved AAA comparison set allows without changing the approved game design.

Use the environment's strongest available coding/reasoning mode, including an ultracode mode when that is a supported option. Fan out specialist sub-agents when the environment supports them. If sub-agents are unavailable, perform the same workstreams sequentially and keep their implementer and reviewer roles separate.

## Project context

- Repositories and immutable build: [PATHS, URL, COMMIT, BUILD ID, AND ASSET VERSION]
- Engine or runtime: [THREE.JS / UNITY / GODOT / UNREAL / OTHER]
- Target platforms and supported devices: [DESKTOP / WEB / IOS / ANDROID / CONSOLE / OTHER]
- Approved visual rubric and art guide: [PATHS OR LINKS]
- Approved comparable AAA references: [GAMEPLAY CAPTURES, SCREENSHOTS, OR LINKS]
- Representative game states and test routes: [PATHS, SCENES, SAVES, OR AUTOMATION STEPS]
- Performance budgets for Low and Ultra: [FRAME TIME, MEMORY, LOADING, DOWNLOAD, THERMAL, OR ASK AI TO PROPOSE]
- Token, time, compute, and review budget: [BUDGET AND CHECKPOINTS]

## Preconditions and guardrails

1. Read the approved game design, architecture, visual rubric, art guide, movement and animation audit, collision plan, UI style guide, localization rules, media plan, performance budgets, mobile report, analytics taxonomy, tests, and documentation before changing anything.
2. Confirm that the game is functionally complete enough for final visual optimization. Do not hide broken mechanics, collision, saves, networking, onboarding, menus, or accessibility behind visual polish.
3. Capture an immutable baseline on representative devices, resolutions, aspect ratios, locales, input methods, gameplay states, menus, quiet scenes, dense scenes, combat or equivalent high-action play, success, failure, loading, and recovery.
4. Use user-approved AAA games with comparable genre, camera, platform, and art direction. Do not use “AAA” as a vague demand for realism, expense, or content volume.
5. Preserve gameplay clarity, responsiveness, accessibility, localization, save compatibility, network authority, and the existing desktop and mobile experiences. Do not improve a beauty shot while making the game harder to read or slower to play.

## Fan out specialist workstreams

Assign an implementation specialist and a separate independent visual critic to each applicable workstream:

1. Complete-frame composition, focal order, camera, lens, staging, scale, and gameplay readability.
2. Characters, creatures, faces, deformation, silhouettes, proportions, materials, hair, cloth, accessories, and secondary motion.
3. Environments, props, world density, landmarks, navigation cues, depth, atmosphere, weather, and environmental storytelling.
4. Textures, materials, shaders, surface response, transparency, reflections, decals, terrain, and technical image stability.
5. Lighting, shadows, exposure, color grading, contrast, mood, time-of-day behavior, and platform fallbacks.
6. Locomotion, starts and stops, turns, traversal, combat and interaction animation, facial performance, lip sync, IK, motion matching or blend systems, procedural animation, vehicles, mechanical motion, and physics-driven reactions.
7. VFX, particles, trails, impact, destruction, fluids, smoke, fire, thrusters, weather, camera feedback, haptics, and synchronization with gameplay and audio.
8. Collision-to-animation alignment and believable physical response, while keeping authoritative collision simple, stable, performant, and separate from visual meshes.
9. Game-native HUD, menus, buttons, cards, icons, typography, transitions, feedback, input glyphs, accessibility, text expansion, right-to-left layout, CJK/font coverage, and supported locales.
10. Technical presentation: aliasing, shimmering, temporal stability, clipping, z-fighting, LOD transitions, pop-in, texture streaming, animation compression, frame pacing, memory, loading, and asset delivery.
11. Scalability and quality settings, including the Low and Ultra profiles and every shared level between them.

Specialists may work in parallel only when file, scene, asset, and system ownership is explicit enough to prevent destructive overlap. Integrate changes through reviewed checkpoints and keep the game runnable.

## Iterative harsh-critic loop

For each workstream:

1. Grade the baseline against the approved rubric and comparable AAA captures using visible evidence and measured performance.
2. Implement the smallest high-impact improvement without changing the approved game or exceeding the platform budget.
3. Capture the same camera, state, resolution, settings, locale, and gameplay moment before and after the change.
4. Give the captures to a separate harsh critic with labels and file ordering hidden. The critic must choose which version looks and plays better, explain why, identify regressions, and score both with the same rubric.
5. Reject changes that lose the blind comparison, hurt readability or responsiveness, break localization/accessibility, or exceed the target profile's budget.
6. Loop on the weakest applicable category. Do not stop after one pass or accept “good enough” without evidence. Continue until every required quality gate passes or a verified blocker, explicit budget limit, or diminishing-return threshold is documented for human review.

The critic must be exacting but honest. Never claim that a result is AAA, perfect, or visually verified when the build, representative states, comparison captures, or target hardware were not actually inspected.

## Low and Ultra graphics implementations

Create and verify at least two complete profiles:

- **Ultra:** the highest approved visual target for capable hardware, including the best justified textures, materials, lighting, shadows, animation layers, VFX, draw distance, density, postprocessing, and presentation that remain within the Ultra budget.
- **Low:** a deliberate art-directed fallback for constrained hardware. Preserve the same fantasy, silhouette, focal hierarchy, state readability, UI clarity, animation timing, collision behavior, and gameplay rules while reducing expensive resolution, density, effects, shadows, postprocessing, simulation, or streaming pressure.

Use capability detection, player settings, and measured defaults rather than one global quality reduction. Define safe transitions, persistence, automatic fallback and recovery, shader/material/asset variants, memory limits, and profile-specific budgets. Low must still look intentional and polished; Ultra must not change mechanics or hide gameplay information unavailable on Low.

## Final verification

- Run blind same-state side-by-side comparisons for every critical workstream and representative state.
- Re-test desktop, mobile, and other supported platforms so one profile or platform is not improved by degrading another.
- Test quiet and dense gameplay, high-motion moments, menus and HUD, loading, success/failure, multiple resolutions and aspect ratios, every supported input method, pseudolocalization, representative real locales, right-to-left layout where supported, accessibility settings, and reduced motion.
- Measure frame time, CPU/GPU cost, memory, thermals, loading, downloads, streaming, animation, physics, particles, UI, and visual stability for Low and Ultra on their target hardware.
- Run the project's automated, remote-automation, screenshot, visual-regression, gameplay, collision, UI-navigation, localization, performance, and production-build tests.

## Required final report

Provide the baseline and final rubric, workstream ownership, iterations attempted, blind-comparison results, rejected changes, Low and Ultra specifications, per-platform measurements, representative before/after captures, unresolved blockers, untested claims, files and assets changed, documentation updated, and exact commands and routes needed to reproduce every visual and performance check.

## Three.js geometry, draw-call, and rendering performance

If the project uses Three.js, do not treat a triangle count or WebGPU selection as a universal performance guarantee. Establish per-device and per-quality-tier budgets from measured CPU frame time, GPU frame time, frame pacing, draw calls, visible triangles, shader and material cost, overdraw/fill rate, lights and shadows, post-processing, texture bandwidth, uploads, animation/skinning, physics, memory, loading, and JavaScript allocation behavior.

Use these only as initial planning hypotheses before profiling, never as pass/fail claims:

- Visible scene geometry: roughly 100k–500k triangles for constrained mobile, 500k–2 million for mid-range mobile, 2–5 million for capable mobile, 2–10 million for older desktop hardware, and 10–50 million for capable gaming desktops when the rest of the frame is controlled.
- Asset envelopes: characters around 5k–50k triangles, props around 100–5k, buildings around 1k–20k, terrain around 100k–500k visible, and approximately 1–5 million visible triangles for a broadly compatible complete scene.
- Draw calls: below 500 is a strong initial target, 500–1,000 requires observation, 1,000–2,000 has increasing CPU risk, and more than 2,000 requires explicit evidence on the target hardware and renderer backend.

Replace those hypotheses with project-specific measured budgets as soon as representative content exists. A lower triangle scene can still be slower because of expensive pixels, shaders, state changes, transparency, shadows, post-processing, animation, physics, or JavaScript work.

Prefer the smallest measured combination of InstancedMesh, BatchedMesh, merged static geometry, shared geometry/materials, texture atlases or arrays where appropriate, frustum culling, distance and screen-size LOD, spatial partitioning, bounded object pools, selective updates, compressed KTX2/Basis textures, compressed glTF meshes where justified, asynchronous loading, streaming, and explicit resource disposal. Do not merge objects that need independent culling, animation, selection, collision, or material behavior without measuring the trade-off.

Record renderer.info counters and browser/GPU profiler captures for representative quiet, dense, high-motion, transparent, shadow-heavy, particle-heavy, UI-overlay, and post-processing states. Profile WebGPU and WebGL 2 separately; WebGPU can reduce some CPU submission overhead and enable compute or modern rendering features, but it does not repair excessive allocations, physics, pathfinding, poor scene organization, expensive fragment shading, oversized shadows, or unnecessary post-processing.

For every optimization, capture the same build and gameplay route before and after, verify visual and gameplay parity, and report the actual bottleneck moved—not only the triangle count.

## Three.js multi-device rendering quality and fallback paths

If the project uses Three.js, design and implement capability-based rendering quality paths so the same game remains playable and visually coherent across constrained phones, capable phones and tablets, integrated-GPU laptops, older desktops, and high-end desktops.

Define documented Low, Balanced, High, and Ultra profiles when the supported device range justifies them. Each profile must specify measured budgets and explicit settings for:

- Renderer backend and supported feature path, render scale, device-pixel-ratio cap, target frame rate, antialiasing, output-buffer precision, and post-processing.
- Visible triangle and draw-call budgets, LOD distances or screen-size thresholds, object and vegetation density, terrain detail, decals, particles, transparent effects, reflection quality, and draw distance.
- Texture resolution, KTX2/Basis variants, anisotropy, material and shader complexity, normal/detail maps, environment maps, lighting count, shadow count, shadow-map resolution, cascades, contact shadows, and baked versus dynamic lighting.
- Character and object animation quality: rig and bone budgets, skinned-mesh count, animation sampling/update rate, interpolation, blend layers, facial animation, lip sync, IK, secondary motion, cloth, hair, ragdolls, physics reactions, crowd animation, and update-distance throttling.
- Asset residency, streaming, preload scope, memory ceilings, cache limits, geometry and texture disposal, worker use, and recovery from memory or graphics-device pressure.

Build the quality system from centralized data rather than scattered conditionals. Use measured capabilities and runtime performance—not only user-agent strings—to select a safe default. Let players override the choice when practical, persist the setting, explain costly options simply, and support safe automatic degradation with hysteresis so quality does not rapidly oscillate. Recover upward only after sustained headroom and never during a critical gameplay moment without an approved transition policy.

Create real asset, material, animation, and effect fallback paths instead of only disabling everything globally. Preserve silhouettes, art direction, gameplay readability, telegraphs, interaction feedback, hit timing, collision, input response, UI meaning, localization, accessibility, network authority, saves, and deterministic gameplay across every profile. Ultra may add presentation detail, but it must not reveal gameplay information or mechanics unavailable on Low.

Test cold start, representative gameplay, dense/high-motion scenes, menus, particles, transparency, lighting and shadows, animation-heavy scenes, background/resume, resize, orientation change, device/context loss, and live profile switching on representative devices. Capture comparable screenshots and performance traces for every profile and backend. Report unsupported combinations and fall back to the nearest verified path with a player-readable message rather than a blank canvas, crash, or raw error.

## Internationalization and localization implementation

Implement the approved internationalization architecture as part of this work rather than leaving localization for a later rewrite.

- Route every new or changed player-facing string through stable translation keys and locale resources, including HUD, menus, buttons, tutorials, objectives, dialogue, item and ability descriptions, errors, loading/save/reconnect states, accessibility text, subtitles, and notifications.
- Use locale-aware pluralization and formatting. Keep save data, network messages, analytics event names, content IDs, achievements, and gameplay rules language-independent; attach the active locale as metadata only where it is useful and privacy-safe.
- Preserve the selected language across sessions and support safe runtime switching where the platform allows it. Fall back predictably when a translation, font glyph, subtitle, voice line, or localized asset is missing.
- Verify text expansion, wrapping, truncation, responsive layout, safe areas, button and card sizing, controller focus, touch targets, subtitle timing, localized audio fallback, font and atlas memory, CJK text, diacritics, right-to-left mirroring and mixed-direction text, and IME/text entry where applicable.
- Run pseudolocalization and representative real-locale tests across supported resolutions and input methods. Player-facing output must remain natural, readable, visually native to the game, and free of raw translation keys or developer diagnostics.

Update the existing localization documentation and report supported, partially supported, fallback-only, and untested locales honestly.

## Analytics implementation requirement

Use the approved analytics taxonomy and centralized analytics interface while implementing this game work. Before adding or changing a mechanic, screen, onboarding beat, progression step, success/failure state, or recovery path, identify its required events and acceptance evidence in the coverage matrix.

Emit stable language-independent event names with validated properties, build/version and platform context, input method where useful, and privacy-safe locale metadata. Prevent duplicates and preserve event order. Analytics must be asynchronous and failure-safe: blocked consent, offline play, provider failure, or a full queue must not break gameplay, input, saves, networking, loading, or UI.

Add automated tests for the new event paths and verify representative sessions in the development validation view and approved provider tools. Update the coverage matrix and analytics documentation with implemented, deferred, and untested events.

## Player-readable output requirement

Everything shown to a player must be written and presented for a human player, not for a developer or debugger. This includes menus, HUD labels, buttons, prompts, tutorials, objectives, dialogue, tooltips, loading and save states, empty states, confirmations, warnings, errors, rewards, notifications, accessibility messages, and connection or recovery states.

Use concise plain language, the game's established terminology and tone, recognizable icons with text where meaning could be ambiguous, and a clear next action. A player-facing error should explain what happened in useful terms, whether progress is safe, and what the player can do next.

Never expose raw exceptions, stack traces, JSON, database IDs, internal event names, enum or variable names, file paths, debug coordinates, HTTP status codes without explanation, server implementation details, developer TODOs, placeholder text, or raw telemetry on a player-facing surface. Send technical details to development-only logs, diagnostics, telemetry, or an authenticated support view. A short support reference code may be shown to the player only when it helps support locate the private diagnostic record.

Verify representative success, failure, offline, loading, empty, permission, validation, timeout, save, reconnect, and recovery states from the player's perspective. Developer documentation and final engineering reports may remain technical; this requirement applies to anything the game presents to players.

## Required game documentation

Documentation is part of the definition of done for this task.

Before finishing:

1. Read the existing README, docs directory, architecture notes, decision records, and AI instructions that apply to this system.
2. Update the existing relevant documentation instead of creating a competing document or a second source of truth.
3. If no relevant document exists, create a clearly named Markdown document in the game's established documentation directory. Use docs/ when the project has no existing convention.
4. Document the current system, the decisions made, ownership and lifecycle rules, configuration, files or assets changed, commands and tests run, known limitations, and how another developer should extend or troubleshoot the work.
5. Update AI_INSTRUCTIONS.md or the project's equivalent when this task changes architectural boundaries, required workflows, naming rules, or validation commands.
6. Keep documentation accurate to the implementation. Do not claim support, measurements, or test coverage that was not verified.
7. In the final report, list every documentation file created or updated.