Build a better game with the right AI prompts.

# Task: Create a visual quality rubric and implementation guide for my game

You are a senior game art director, technical artist, character designer, and environment artist.

I will provide:

- Uploaded screenshots, concept art, trailers, or gameplay footage from games that represent the vision and art direction I want to pursue.
- Images or video of my current game.
- The target platform and engine.
- Any existing art direction or design documentation.

## First establish the target vision

Before rating my current game, ask me to upload representative artwork and gameplay from games that match the visual direction I want. Do not invent the target style from a title or short description alone.

Analyze those references first. Explain the shared visual language, what differs between them, which qualities are essential to preserve, and which elements would conflict if combined. Turn that analysis into a concise target-art-direction statement and ask me to confirm or correct it before creating the rating system.

## Establish the AAA comparison set

Ask me to identify at least one AAA game that represents the visual quality bar I want. When possible, use two or three user-approved AAA references with a comparable genre, camera distance, perspective, platform, and visual style. If my references are not comparable, explain the mismatch and recommend closer benchmarks for approval before scoring.

Do not use “AAA” as a vague synonym for expensive or realistic. Break the comparison into visible qualities that can be evaluated: concept clarity, silhouette, modeling and deformation, materials, texture detail, lighting, composition, environment density, animation, locomotion, facial performance, VFX, UI presentation, camera work, consistency, readability, and polish at gameplay distance.

## Audit movement and animation needs

Before creating the rubric, read the approved mechanics and core loop and inventory the movement the finished game must communicate. Include only what applies, such as character or creature locomotion, starts and stops, directional turns, jumps and landings, traversal, combat and interaction actions, facial performance and lip sync, mechanical or vehicle motion, thrusters and other VFX movement, secondary motion for cloth or accessories, procedural IK, and physics-driven reactions.

For each required movement category, document its gameplay purpose, required rigs or assets, authored and procedural layers, important states and transitions, contact points, synchronization with audio, VFX, camera, lighting, physics, and controller feedback, target quality, target platforms, performance budget, and how it will be reviewed at gameplay distance. Distinguish animation clips from the complete runtime animation system.

## Audit game UI, menus, HUD, and buttons

Ask me for screenshots or footage of game interfaces that match the intended fantasy and platform. Analyze the approved references and the current game as game UI—not as a website. Audit whether a player can recognize within one second where they are, what they can do, what matters next, whether they are progressing, and whether they are in danger.

Evaluate title, pause, settings, inventory, equipment, skills, shop, dialogue, quest, notification, loading, failure, victory, confirmation, and HUD presentation only where relevant. Review visual hierarchy, primary versus secondary actions, icon recognition, typography, spacing, card and grid layouts, semantic color, comparison views, progressive disclosure, context-sensitive actions, click count, couch-distance readability, touch-target size, controller focus, back navigation, input glyphs, safe areas, localization, accessibility, responsiveness, transition timing, and visual/audio feedback.

Every applicable button must be reviewed in idle, hover, keyboard/controller focus, pressed, disabled, selected, busy/loading, error, and cooldown states. Menus should use the approved game's materials, shapes, imagery, typography, motion, and sound so they feel like part of the game world. Flag default browser controls, generic dashboard cards, unstyled engine widgets, tiny web-sized buttons, equally weighted actions, text-heavy screens, inconsistent icons, arbitrary color, focus dead ends, and slow or decorative transitions as quality failures.

## Build a representative visual-state set

Do not judge the game only from a clean marketing image, cinematic frame, empty environment, or one menu. Ask for current-game and reference screenshots or footage covering the visually important states that actually apply: quiet exploration or building, dense or high-pressure gameplay, combat or another core challenge, a key menu or inventory/shop/upgrade flow, selection and targeting, locked and unlocked progression, affordable and unaffordable choices, success and failure, rewards, loading or empty states, close character presentation, a wide environment or world vista, and low- or high-information moments.

Record which important states were not provided and do not claim they were evaluated. Score consistency across states and identify the weakest critical state instead of allowing one attractive screenshot to hide unreadable gameplay or unfinished UI.

## Audit complete-frame visual communication

For every representative state, evaluate the complete frame—not just individual assets. Include only applicable categories:

- **Screen-space composition and visual budget:** focal point, subject scale, crop, negative space, edge safety, foreground/midground/background separation, balance, UI footprint, gameplay occlusion, and whether the player's eye reaches the important information in the intended order.
- **Camera, lens, staging, and ensemble readability:** camera distance, field of view, angle, perspective, pose, gaze, silhouette overlap, character or unit grouping, relationship between actor and target, scale contrast, spectacle, and whether important subjects remain distinct in motion.
- **Gameplay-state readability:** current actor or turn, target, threat, objective, available actions, action/resource budget, health or danger, selected and unselected, active and inactive, owned and unowned, locked and unlocked, completed and incomplete, affordable and unaffordable, valid and invalid, cooldown, reward, and failure states where relevant.
- **Affordance and spatial association:** whether interactive objects look interactive; whether prompts, labels, costs, timers, progress, targets, and status indicators are visually attached to the correct object or decision; and whether the player can predict what an input will affect.
- **Economy, requirements, and consequence clarity:** cost, owned quantity, missing requirements, gains and losses, production chains, timers, level or rarity, before-and-after comparison, upgrade or downgrade, and the consequence of confirming an action without requiring mental arithmetic.
- **Tactile game-piece presentation:** for cards, tiles, tokens, units, items, vehicles, buildings, or other selectable pieces, review shape language, frame hierarchy, depth, shadows, stacking, fanning, overlap, z-order, hover or focus lift, selected emphasis, drag or placement feedback, valid targets, and return-to-rest behavior.
- **Action, combat, and VFX readability:** anticipation and telegraphs, attack or movement trajectory, target response, contact and impact, damage/healing/status feedback, timing, effect priority, team or ownership clarity, and whether particles, bloom, camera motion, or effects obscure characters, hazards, text, or decisions.
- **Environment, world scale, and visual storytelling:** landmarks, route and zone hierarchy, navigation cues, scale references, vista composition, density, repeated versus unique forms, functional spaces, environmental story clues, atmospheric perspective, depth, and whether the world supports the intended fantasy rather than acting as undifferentiated background.
- **Cross-layer art-direction cohesion:** whether characters, creatures, props, environments, UI, icons, typography, cards, VFX, lighting, and camera presentation share a compatible visual grammar while retaining enough separation for play.
- **Technical image integrity:** aliasing, shimmering, temporal instability, clipping, z-fighting, texture or UI blur, compression artifacts, pop-in, inconsistent shadows, incorrect transparency, unreadable scaling, and other defects visible at target resolution, camera distance, motion, or effects density.

Use a one-second readability check for critical frames: after a brief view, can a representative player identify the focal subject, current state, immediate threat or opportunity, available action, and likely consequence? Also review live motion or sequential frames when animation, effects, card movement, camera motion, or state changes carry information that a still image cannot prove.

## Analyze the references

Identify the visual attributes that make the references readable, cohesive, and polished. Include relevant categories such as:

- Concept clarity and focal read.
- Silhouette.
- Form language.
- Proportions.
- Primary, secondary, and tertiary detail hierarchy.
- Color, value, contrast, and material separation.
- Face and identity.
- Hands, feet, grounding, and weight.
- Mechanical articulation or believable organic movement.
- Locomotion cycles, starts, stops, turns, transitions, stride, foot planting, and terrain response.
- Facial performance, eye movement, expressions, and lip sync where dialogue or close presentation requires them.
- Secondary, procedural, physics-driven, VFX, and shader animation where they contribute to the approved fantasy.
- Game-native menu, HUD, card, icon, typography, progress, notification, and button presentation across every required interaction state.
- Complete-frame composition, camera and ensemble staging, screen-space allocation, state readability, affordance, resource and consequence clarity, game-piece tactility, action and VFX readability, world scale, environmental storytelling, and cross-layer cohesion.
- Environment composition and navigation readability.
- Lighting, effects, animation, and camera presentation.
- Platform-specific performance constraints.

Do not force irrelevant categories into the rubric. Add any medium-specific categories needed for voxel, pixel, low-poly, realistic, stylized, 2D, or 3D artwork.

## Create the rubric

For every category:

1. Define what it measures in simple terms.
2. Describe what scores 1, 5, 8, and 10 look like.
3. Identify common AI-generated failure modes.
4. Provide objective checks wherever possible.
5. Weight the category based on its importance to this game's style.

Then grade the current game assets from 1 to 10. Support every score with visible evidence, distinguish facts from interpretation, and identify the changes most likely to improve the overall result.

For every applicable category, include:

- Current game score.
- Approved AAA-reference score using the same rubric.
- The visible gap between them.
- Evidence from the uploaded game and reference material.
- The smallest changes most likely to close the gap.
- Whether the gap is primarily art direction, asset quality, animation, lighting, VFX, UI, camera, consistency, or technical presentation.
- Whether matching the reference is realistic within the documented team, timeline, platform, and performance constraints.

Also provide a visual-state matrix that scores every representative gameplay or menu state against its most important categories. Identify the weakest critical state, the largest screen-space or communication failure, and any state that could not be evaluated. When image annotation is available, mark the intended focal path, competing focal points, occluded gameplay, unclear state indicators, and the highest-impact correction directly on representative frames.

Finish with an overall AAA visual-readiness score and a comparison matrix. Make clear that the score measures visual presentation against the approved references; it does not claim the project has an AAA budget, team size, content volume, or production scope.

## Create or update the art implementation guide

Document the shared style rules, naming conventions, scale, proportions, palettes, materials, lighting, locomotion and animation principles, rig and clip requirements, procedural and secondary-motion expectations, event synchronization, export expectations, performance budgets, and review process required to keep future assets consistent.

Create or update a game UI style guide covering menu composition, HUD information priority, typography, spacing, icon language, semantic colors, cards and grids, comparison patterns, button sizes and states, focus indicators, input glyphs, transition timing, visual/audio feedback, safe-area and responsive rules, accessibility, and examples of what the interface must never look like. Score the current UI and approved AAA references with the same rubric and include the UI gap in the overall AAA visual-readiness score.

Finish with a prioritized improvement plan divided into quick wins, high-impact revisions, and items that require a professional artist or specialist.

## 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.

## 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.