You are responsible for the final **commercial-quality, presentation-cohesion, and release-polish pass** on an existing game that is already close to shipping.

Your job is to find the remaining details that make the game:

- look unfinished;
- feel prototype-like;
- sound inconsistent;
- behave awkwardly;
- expose development residue;
- lack cohesion;
- visibly fall below the quality of its strongest areas;

and then fix the highest-impact problems.

The primary question throughout this task is:

> **If this appeared in a trailer, storefront screenshot, first 20 minutes of play, livestream, review video, or press capture, what would immediately reveal that it still feels under-polished?**

Then fix those problems.

This is an **implementation task**, not merely a final critique.

Do not stop after:

- identifying weak screens;
- listing inconsistent visuals;
- pointing out stiff animation;
- finding audio gaps;
- documenting empty environments;
- producing a polish backlog;
- recommending what should be improved before launch.

Inspect the actual game.

Rank visible problems by player-facing impact.

Implement the strongest justified fixes.

Validate them in context.

Reinspect the game as a whole.

Continue while meaningful, safely actionable polish remains.

Use continuously:

> **inspect → rank → implement → validate → reinspect**

The goal is:

> **Leave behind the same game, but remove as much visible prototype residue as safely possible so the finished product feels cohesive, intentional, confident, and commercially ready.**

---

# This Is the Final 10%, Not Another Redesign

Assume specialized passes have already addressed deep problems involving:

- gameplay systems;
- balance;
- networking;
- persistence;
- onboarding;
- performance;
- UI;
- animation;
- audio;
- world design;
- release engineering.

This pass targets the visible gap between:

> **works**

and:

> **feels shipped**

Do not restart completed systems from first principles.

Do not invent new features because polish revealed an opportunity.

Do not perform large architecture changes merely because a cleaner solution exists.

Prioritize the details players and reviewers will actually notice.

---

# Commercial Quality Is Not Maximum Complexity

Professional polish does not require:

- more particles everywhere;
- more glow;
- more animation;
- more sound;
- more UI decoration;
- denser environments;
- longer transitions;
- cinematic presentation for routine actions.

Commercial quality usually comes from:

- consistency;
- hierarchy;
- timing;
- restraint;
- clean transitions;
- deliberate composition;
- strong feedback;
- removal of placeholders;
- eliminating visibly weak outliers.

Fix what looks accidental.

Preserve what looks intentional.

---

# Core Scope

Review only systems and presentation that actually exist.

Relevant areas may include:

## Visual Presentation

- lighting;
- materials;
- scene composition;
- effects;
- silhouettes;
- visual hierarchy;
- obvious clipping;
- empty presentation;
- inconsistent quality.

## UI / HUD

- menus;
- HUD;
- inventory;
- character screens;
- settings;
- dialogue;
- tooltips;
- loading screens;
- error states;
- notifications;
- typography;
- spacing;
- alignment;
- icons;
- interaction states.

## Animation / Character Presentation

- locomotion;
- attacks;
- interactions;
- gathering;
- crafting;
- transitions;
- hit/death presentation;
- equipment;
- held items;
- NPCs;
- creatures;
- animation timing.

## Game Feel / Feedback

- input response;
- impact;
- confirmation;
- targeting;
- interactions;
- rewards;
- failure feedback;
- camera response;
- state transitions.

Do not redesign mechanics.

## Audio

- combat;
- movement;
- UI;
- interactions;
- rewards;
- ambience;
- environment;
- music transitions;
- mixing;
- repetition;
- lifecycle.

## Environment / World

- empty spaces;
- landmarks;
- prop placement;
- repetitive layouts;
- transitions;
- authored detail;
- environmental storytelling;
- visual density;
- interiors;
- high-traffic locations.

## Transitions

- scene changes;
- menu transitions;
- gameplay ↔ dialogue;
- movement → action;
- action → movement;
- death/respawn;
- loading → gameplay;
- equipment changes;
- target changes.

## Production Residue

- placeholders;
- debug overlays;
- raw IDs;
- raw enum values;
- development text;
- temporary icons;
- engine defaults;
- test assets;
- broken references;
- stale messages;
- unfinished errors/loading states.

Only fix what actually exists.

---

# Explicitly Out of Scope

This is **not primarily**:

- a feature sprint;
- gameplay redesign;
- progression redesign;
- balance overhaul;
- world expansion;
- new content campaign;
- networking rewrite;
- persistence redesign;
- architecture rewrite;
- dependency modernization;
- broad technical-debt cleanup;
- repository cleanup;
- large asset-production effort.

Small adjacent fixes are allowed when directly necessary to remove a highly visible polish defect.

Do not let final polish create launch risk through unnecessary scope.

---

# Preserve Existing Product Identity

Preserve:

- gameplay;
- controls;
- pacing;
- progression;
- visual identity;
- audio identity;
- world identity;
- humor/tone;
- mechanical asymmetry;
- intended simplicity;
- deliberate stylization.

Do not make the game generic in pursuit of "professionalism."

Professional does not mean:

- photorealistic;
- highly animated;
- cinematic;
- ornate;
- visually dense.

The goal is:

> **the strongest, most coherent version of the game it already is.**

---

# Preserve Existing Work

Before substantive changes, inspect version-control state where available.

Do not:

- overwrite unrelated work;
- revert unfamiliar modifications;
- delete ambiguous assets;
- remove current polish work without understanding it;
- use destructive cleanup operations merely to simplify the pass.

When existing changes overlap:

1. inspect them;
2. determine apparent intent;
3. preserve that intent;
4. integrate carefully;
5. favor bounded corrections over broad rewrites.

---

# Inspect Before Asking Questions

Use the project itself as evidence.

Inspect relevant:

- gameplay runtime;
- representative scenes;
- menus;
- HUD;
- world areas;
- animation;
- audio;
- effects;
- transitions;
- starter state;
- production configuration;
- assets;
- logs/warnings;
- screenshots;
- builds.

Ask for clarification only when:

- intended presentation genuinely cannot be established;
- several incompatible directions are equally plausible;
- new assets require creative direction that does not exist;
- a fix would materially redesign gameplay;
- external production requirements are unavailable.

Do not ask questions merely because identifying "why this still looks cheap" requires judgment.

---

# Runtime First

Where practical, inspect the game in motion.

Final polish problems often do not appear clearly in source code.

Observe:

- actual gameplay;
- actual camera;
- actual UI scaling;
- transitions;
- animation sequences;
- overlapping sound;
- environmental composition;
- loading;
- errors;
- first-run state.

Use screenshots for static composition.

Use video/runtime observation for:

- motion;
- timing;
- transitions;
- game feel;
- sound;
- animation.

If direct runtime observation is unavailable:

- state that limitation;
- use available screenshots/assets/code;
- do not claim a visual or audio issue was directly observed if it was inferred.

---

# Implementation Over Critique

The review exists to create an **implementation queue**.

Do not spend most of the task producing:

- exhaustive critique;
- design documents;
- giant polish spreadsheets;
- subjective taste lists.

Once a high-impact problem is clear:

> **fix it.**

Then inspect the resulting game again.

The strongest remaining weakness often changes after each improvement.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports independent agents, workers, subprocesses, or fresh contexts, use them where they materially improve coverage.

Do not require delegation.

A single capable session must still be able to execute the task sequentially.

Good independent review areas may include:

- UI;
- animation;
- audio;
- environment;
- first 20 minutes;
- placeholder/default hunt;
- screenshot review;
- transition review.

Serialize changes involving shared:

- global UI styles;
- lighting foundations;
- shared animation controllers;
- global mixer/buses;
- gameplay timing;
- common effects;
- world-wide art direction.

Do not let independent workstreams create incompatible polish directions.

Fresh reviewers are particularly useful because familiarity makes prototype residue easy to stop noticing.

---

# Polish Priority Queue

## P0 — Serious Functional Defect

Examples:

- crash;
- corruption;
- broken state;
- missing required resource;
- progression blocker discovered during polish.

Do not ignore it merely because this is a presentation pass.

Fix or document the blocker appropriately.

## P1 — Immediately Visible Unfinished Quality

Examples:

- engine-default presentation;
- obvious placeholder;
- broken UI;
- major clipping;
- severe animation snap;
- conspicuously empty major area;
- common action with weak/missing feedback;
- jarring transition;
- debug residue;
- obviously broken loading/error state.

Fix aggressively.

## P2 — Significant Cohesion Weakness

Examples:

- one screen far weaker than others;
- mediocre animation family;
- inconsistent visual hierarchy;
- weak ambience;
- repetitive environment;
- inconsistent effects;
- poor transition quality;
- inconsistent terminology/presentation.

Spend substantial effort here.

## P3 — Final Detail Polish

Examples:

- small spacing inconsistencies;
- subtle timing;
- minor prop variation;
- small sound variation;
- secondary-motion polish.

Address after P1/P2.

---

# Commercial-Quality Hunt

Search broadly for:

- flat presentation;
- inconsistent presentation;
- weak screens;
- stiff motion;
- placeholders;
- engine defaults;
- empty environments;
- obvious copy/paste;
- UI drift;
- weak feedback;
- jarring transitions;
- audio gaps;
- clipping;
- sliding;
- popping;
- raw debug text;
- weak loading states;
- weak error states;
- inconsistent terminology;
- mismatched art direction;
- pieces that feel like they belong to different games.

Ask:

> **Would this look intentional to someone who knows nothing about the development process?**

---

# Strongest Versus Weakest Comparison

Identify the strongest existing examples of:

- UI;
- environment;
- animation;
- feedback;
- audio;
- effects;
- interaction;
- loading/transition presentation.

Then identify the weakest equivalent examples.

Use the strongest existing work as the quality reference.

Ask:

> **Why does A feel finished while B feels temporary?**

Bring weak outliers toward the established quality bar.

Do not redesign the strongest areas simply for consistency.

---

# Trailer Test

Inspect representative gameplay as though preparing footage for a commercial trailer.

Ask:

- What would I avoid showing?
- Which action looks weakest?
- Which UI screen would I hide?
- Which area looks empty?
- Which animation looks stiff?
- Which transition looks rough?
- Which moment lacks impact?
- Which visual artifact would draw criticism?

Anything you would deliberately avoid recording deserves investigation.

Do not optimize only for trailer spectacle.

Use the trailer test to expose weaknesses.

---

# Screenshot Test

Capture or inspect representative gameplay frames.

Ask:

> **What makes this screenshot look cheaper than it should?**

Inspect:

- composition;
- lighting;
- UI;
- poses;
- environment density;
- repetition;
- placeholders;
- clipping;
- empty space;
- visual noise;
- text hierarchy;
- misaligned elements;
- obvious default assets.

Then ask:

> **Is the problem visible because of a real quality defect, or merely because this frame happens to be quiet?**

Do not fill intentionally calm scenes with clutter.

---

# Normal Gameplay Camera Test

Evaluate from the camera players actually use.

Do not judge polish only through:

- close-up editor view;
- asset preview;
- isolated animation viewer.

Ask:

- Can the player read the action?
- Does the environment compose well?
- Does UI dominate too much?
- Are effects legible?
- Does animation silhouette read at normal distance?

Commercial polish must work from the real camera.

---

# First-20-Minutes Test

Where practical, begin from a fresh account/character/save.

Inspect:

- first launch;
- first menu;
- loading;
- spawn;
- first movement;
- first interaction;
- first combat/gathering;
- first reward;
- first meaningful UI use;
- first transition between major states.

Look for:

- default-looking menus;
- weak spawn composition;
- dead silence;
- rough interaction feedback;
- stiff first action;
- unfinished first reward;
- abrupt scene transition;
- immediate placeholder/default residue.

First impressions receive disproportionate attention.

---

# High-Frequency Action Test

Identify actions players see hundreds or thousands of times.

Examples:

- movement;
- interaction;
- basic attacks;
- gathering;
- inventory use;
- menus;
- target selection.

Ask:

> **Does this still look or feel cheap every time it happens?**

Prioritize frequent imperfections over rare cinematic polish.

---

# Visual Presentation Pass

Look for obvious weaknesses involving:

- lighting;
- contrast;
- material response;
- composition;
- visual hierarchy;
- silhouette;
- effects;
- depth;
- scene grounding.

Do not redo the entire visual direction.

Fix visible outliers.

---

# Flat Presentation Hunt

Look for areas/screens that feel visually flat because of:

- weak foreground/background separation;
- uniform lighting;
- no focal point;
- objects blending together;
- overly even contrast;
- weak state emphasis.

Use existing art direction.

Do not add glow or dramatic lighting everywhere.

---

# Material Consistency

Inspect whether important materials look unintentionally inconsistent.

Examples:

- one metal item appearing matte while equivalents read as metal;
- terrain/material transitions looking unfinished;
- character equipment shading inconsistent with world style.

Do not convert this into a full material-authoring pass.

Fix obvious presentation mismatches.

---

# UI / HUD Commercial-Quality Pass

Inspect:

- layout;
- spacing;
- typography;
- hierarchy;
- alignment;
- controls;
- selected/hover/disabled states;
- icons;
- panels;
- tooltips;
- notifications;
- empty states;
- errors;
- loading.

Ask:

> **Does this look like one deliberate interface system?**

---

# Weakest-Screen Test

Identify the weakest major screen.

Examples:

- inventory;
- character;
- settings;
- crafting;
- dialogue;
- quest log;
- pause menu.

Ask:

> **If a reviewer opens this screen, does it suddenly lower the perceived quality of the whole game?**

Fix high-impact outliers.

---

# UI Consistency Hunt

Compare:

- margins;
- padding;
- button sizes;
- typography;
- colors;
- panel structure;
- corner treatment;
- icon size;
- selection states;
- disabled states;
- tooltips.

Fix accidental drift.

Preserve intentional screen-specific hierarchy.

---

# Raw / Debug UI Hunt

Search for player-visible:

- internal IDs;
- enum names;
- debug coordinates;
- developer labels;
- temporary messages;
- raw exceptions;
- object names;
- unformatted values.

Convert confirmed development residue into appropriate production presentation.

---

# Loading-State Pass

Inspect:

- first load;
- scene load;
- network connection;
- respawn;
- server transitions;
- long async operations.

Look for:

- blank screens;
- frozen-looking UI;
- engine defaults;
- flashing intermediate states;
- abrupt jump into gameplay;
- debug-style loading text.

Do not create elaborate loading screens without need.

Make existing loading feel deliberate.

---

# Error-State Pass

Inspect visible errors such as:

- connection failure;
- save failure;
- invalid action;
- missing service;
- unavailable server.

Avoid:

- raw stack traces;
- generic engine dialogs;
- malformed UI;
- development terminology.

Provide coherent product-appropriate presentation.

---

# Animation / Character Presentation Pass

Inspect:

- locomotion;
- turning;
- common attacks;
- interactions;
- gathering;
- equipment;
- hit/death;
- NPC movement.

Look for:

- snapping;
- sliding;
- floating;
- weak pose;
- incorrect timing;
- visible animation restart;
- bad transitions.

Do not redo animation architecture.

Fix remaining high-visibility flaws.

---

# Game Feel Pass

Inspect common interactions for:

- acknowledgement;
- timing;
- impact;
- responsiveness;
- state clarity.

Ask:

> **Does the action feel deliberate when I perform it?**

Look for:

- input with weak feedback;
- action results with no confirmation;
- selection that feels ambiguous;
- reward with no weight;
- interaction that visually happens before/after actual result.

Do not change core mechanics unnecessarily.

---

# Feedback Hierarchy

Routine events and major events should not feel identical.

Examples:

- normal XP versus level-up;
- normal loot versus rare loot;
- normal hit versus lethal hit;
- ordinary interaction versus quest completion.

Use existing:

- animation;
- audio;
- VFX;
- UI;

to establish appropriate hierarchy.

Avoid making every event dramatic.

---

# VFX Pass

Inspect existing effects for:

- timing;
- scale;
- opacity;
- readability;
- attachment;
- repetition;
- lifecycle.

Look for:

- placeholder particles;
- oversized effects;
- effects obscuring gameplay;
- effect continuing after state ends;
- important action with visibly weak existing effect.

Do not fill the game with particles.

---

# Audio Commercial-Quality Pass

Listen for:

- dead common actions;
- repetitive effects;
- mistimed sounds;
- weak impacts;
- inconsistent loudness;
- ambience gaps;
- abrupt music transitions;
- obvious placeholder audio.

Do not redo the soundtrack or audio engine.

Focus on what visibly/audibly undermines quality.

---

# Silence Versus Missing Audio

Ask:

> **Is this intentionally quiet, or does it simply feel unfinished?**

Preserve silence where it supports:

- calm;
- tension;
- isolation;
- contrast.

Fix conspicuous sonic emptiness around major actions or environments.

---

# Environment Commercial-Quality Pass

Walk through representative:

- starter area;
- towns;
- travel routes;
- gathering areas;
- combat areas;
- interiors;
- major landmarks.

Look for:

- barren spaces;
- copy/pasted prop patterns;
- empty corners;
- weak landmarks;
- abrupt transitions;
- procedural-looking scatter;
- areas with no visual identity.

Do not fill every space.

Fix the most visible under-authored areas.

---

# High-Traffic Area Priority

Prioritize areas players:

- spawn in;
- revisit frequently;
- see in screenshots;
- traverse often;
- use for important gameplay.

A weak starter town matters more than an obscure edge of the map.

---

# Authored Does Not Mean Crowded

Do not solve environment weakness by filling every empty area.

Preserve:

- negative space;
- navigation clarity;
- combat space;
- readability;
- performance;
- visual rest.

Ask:

> **Does this space feel intentionally open or simply unfinished?**

---

# Repetition Hunt

Search for repetition involving:

- props;
- environment layouts;
- textures;
- sounds;
- animation;
- VFX;
- UI assets.

Look for repetition that exposes implementation.

Use restrained variation where existing systems/assets support it.

Do not randomize everything.

Consistency and repetition are not inherently bad.

Mechanical-looking repetition is the target.

---

# Prop Repetition

Look for:

- identical spacing;
- identical rotation;
- repeated clusters;
- mirrored arrangements;
- copied environmental modules.

Break obvious patterns where safe.

Preserve gameplay readability.

---

# Audio Repetition

Listen to high-frequency:

- footsteps;
- attacks;
- gathering;
- UI;
- ambience.

Use existing variations or restrained randomized selection where appropriate.

Do not make informational sounds inconsistent.

---

# Animation Repetition

Look for:

- constant restart;
- identical idle timing;
- repeated attack snapping;
- loop hitch.

Use existing animation systems to reduce mechanical presentation.

Do not add random motion simply for novelty.

---

# Transition Hunt

Inspect transitions such as:

- scene → scene;
- menu → gameplay;
- gameplay → dialogue;
- dialogue → gameplay;
- movement → action;
- action → movement;
- death → respawn;
- loading → gameplay;
- target changes;
- equipment changes;
- music/ambience changes.

Look for:

- snap;
- flash;
- stale state;
- intermediate wrong pose;
- silence;
- timing mismatch;
- old UI lingering;
- abrupt audio change.

Transitions often expose the difference between:

> **functional**

and:

> **finished.**

---

# Scene Transition Pass

Inspect:

- outgoing scene;
- loading;
- incoming scene;
- music;
- ambience;
- camera;
- player state;
- UI.

Avoid:

- one-frame default states;
- sudden exposure of uninitialized scene;
- duplicated ambience;
- player appearing before surrounding world is ready.

Use existing loading/transition architecture.

---

# Dialogue Transition Pass

Inspect:

> **gameplay → dialogue → gameplay**

Look for:

- camera snap;
- character facing wrong direction;
- controls remaining active incorrectly;
- UI flicker;
- audio mismatch;
- dialogue closing into stale state.

Do not redesign dialogue.

Polish entry/exit.

---

# Death / Respawn Transition

Inspect:

- lethal event;
- death presentation;
- UI;
- camera;
- respawn;
- state reset.

Look for:

- abrupt pop;
- corpse flashing alive;
- UI retaining dead-state data;
- music/audio mismatch;
- respawn in incorrect animation.

---

# Equipment Transition

Rapidly:

- equip;
- unequip;
- swap.

Look for:

- floating items;
- old equipment lingering;
- wrong animation pose;
- duplicate visual;
- stale stats/UI.

Fix visible presentation disagreement.

---

# Placeholder / Default Hunt

Search production-facing content for:

- placeholder text;
- `TODO`;
- `TBD`;
- `Lorem ipsum`;
- `Test`;
- engine names;
- default icons;
- temporary art;
- development shaders/materials;
- raw IDs;
- generic error dialogs;
- debug overlays;
- profiler display;
- temporary VFX;
- missing-state visuals.

Confirm each finding before changing it.

Do not invent unknown final content.

---

# Engine-Default Hunt

Look for obvious engine/framework defaults in:

- window titles;
- icons;
- buttons;
- fonts;
- panels;
- loading;
- error states;
- cursors;
- materials;
- lighting;
- controls.

Not every standard-looking element is bad.

Fix defaults that visibly break the game's established identity.

---

# Debug Residue Hunt

Search for player-facing:

- FPS counters;
- coordinates;
- collision display;
- navigation display;
- entity IDs;
- temporary labels;
- debug buttons;
- admin controls exposed to normal players;
- verbose logging overlays.

Remove or appropriately gate confirmed development residue.

---

# Missing-State Presentation

Inspect whether common systems have presentation for:

- disabled;
- unavailable;
- selected;
- targeted;
- loading;
- error;
- empty;
- completed;
- dead;
- disconnected.

A system may function technically but look unfinished when intermediate states use no presentation at all.

Add only states actually required by existing behavior.

---

# “One Team Made This” Test

Review:

- UI;
- world;
- animation;
- audio;
- effects;
- interactions;
- terminology;
- feedback.

Ask:

> **Does this feel like one product created under one coherent direction?**

Look for:

- one screen using different design language;
- one animation family behaving differently;
- one area with unrelated prop density;
- one UI workflow using different terminology;
- one set of sounds dramatically louder.

Fix accidental mismatches.

Preserve intentional differences between systems and areas.

---

# Terminology Consistency

Search player-facing wording for inconsistent names of:

- skills;
- items;
- stats;
- currencies;
- actions;
- systems;
- buttons.

Do not rewrite flavor text broadly.

Fix terminology drift that makes the product feel assembled from different development eras.

---

# Visual Scale Consistency

Look for objects or UI elements that feel accidentally:

- too large;
- too small;
- inconsistent with siblings;
- scaled differently between world and UI.

Correct obvious mismatches.

Preserve intentional exaggeration.

---

# Camera Presentation Pass

Inspect normal gameplay camera for:

- composition;
- framing;
- clipping;
- abrupt correction;
- awkward obstruction;
- zoom limits;
- state changes.

Do not redesign camera controls.

Fix high-visibility presentation defects.

---

# Clipping / Intersection Hunt

Look for:

- weapon through body;
- character through environment;
- UI text clipping;
- VFX through geometry;
- props intersecting badly;
- camera entering geometry.

Prioritize:

> **frequent + obvious + screenshot-visible**

problems.

Do not attempt to eliminate every microscopic geometric intersection.

---

# Pop-In / State Pop Hunt

Look for:

- characters appearing in default pose;
- equipment popping;
- UI appearing before data;
- props popping abruptly;
- effects appearing late;
- state switching visibly.

Fix where the existing system can do so safely.

Do not turn this into a deep streaming overhaul.

---

# Storefront Screenshot Review

Select representative scenes that could plausibly appear on a storefront.

Ask:

- Is the UI presentable?
- Are poses strong?
- Does environment look authored?
- Are visual bugs visible?
- Is important content readable?
- Does this resemble final software?

Do not artificially stage the entire game for screenshots.

Use the test to expose ordinary presentation weaknesses.

---

# Reviewer Capture Review

Assume a reviewer records without developer supervision.

They may:

- open an ugly menu;
- stand in an awkward location;
- trigger a transition repeatedly;
- inspect settings;
- fail an action;
- die;
- revisit the starter area.

The game should not depend on carefully curated footage to look finished.

---

# Common Failure-State Polish

Inspect likely player-facing failures:

- invalid interaction;
- insufficient resources;
- unavailable server;
- full inventory;
- death;
- save/load error where applicable.

Do these look:

- intentional;
- understandable;
- consistent;

or like raw development behavior?

Fix high-visibility failures.

---

# First Impression Versus Long-Term Polish

Prioritize first impressions heavily, but do not ignore high-frequency long-term problems.

A useful rough ordering:

1. first launch;
2. first 20 minutes;
3. major recurring gameplay;
4. major menus;
5. common environments;
6. rare content;
7. obscure edge cases.

Adjust based on actual game structure.

---

# Pattern-Based Polish Hunt

When one visible defect appears, inspect siblings.

Examples:

If one settings screen uses old styling:

> inspect other secondary screens.

If one weapon clips badly:

> inspect its equipment family.

If one ambience zone cuts abruptly:

> inspect adjacent transitions.

If one area uses obvious cloned props:

> inspect nearby authored zones.

Fix repeated patterns rather than isolated symptoms where justified.

---

# Work in Final Polish Waves

Do not change everything simultaneously.

## Wave A — P1 Presentation Failures

Fix:

- placeholders;
- defaults;
- major broken UI;
- obvious clipping;
- severe animation/audio defects;
- visibly unfinished loading/errors.

Validate.

## Wave B — First Impression

Polish:

- first launch;
- starter presentation;
- first 20 minutes;
- high-traffic opening environments;
- early rewards/interactions.

Validate.

## Wave C — High-Frequency Gameplay

Polish:

- movement;
- interaction;
- combat;
- gathering;
- common feedback;
- inventory/equipment.

Validate.

## Wave D — Cohesion

Compare:

- screens;
- environments;
- animations;
- audio;
- terminology;
- effects.

Bring weak outliers toward the established quality bar.

## Wave E — Transitions

Polish:

- scene changes;
- dialogue;
- death/respawn;
- loading;
- action transitions;
- audio transitions.

Validate.

## Wave F — Last 10%

Address worthwhile:

- repetition;
- spacing;
- minor clipping;
- subtle timing;
- secondary environmental detail;
- small hierarchy inconsistencies.

Do not manufacture churn.

---

# Reassess After Every Wave

Ask:

- What is now the most obvious cheap-looking thing?
- What would a reviewer notice first?
- What would look bad in a screenshot?
- What would I avoid showing in a trailer?
- What still feels temporary?
- Which screen is now weakest?
- Which environment is now weakest?
- Which common action still feels unfinished?
- Did one fix expose another weak layer?
- Did we accidentally over-polish something?

Reprioritize.

---

# Productive Final-Polish Loop

Final polish often reveals quality layers.

Examples:

- fixing weak UI makes animation flaws more noticeable;
- animation cleanup makes audio timing more obvious;
- audio polish exposes empty environment;
- environment improvement makes transitions stand out;
- transition cleanup exposes placeholder loading state.

Continue:

> **inspect → rank → implement → validate → reinspect**

while meaningful player-visible polish remains.

Do not keep changing things simply because more changes are possible.

Stop when remaining issues are:

- subjective;
- microscopic;
- low visibility;
- dependent on major new assets;
- dependent on redesign;
- outside scope.

---

# Fresh Independent Commercial-Quality Review

Near completion, review with fresh context where practical.

Use this exact mindset:

> **Assume the game ships tomorrow. Identify the most visible reasons it still feels unfinished, cheap, inconsistent, prototype-like, or insufficiently polished.**

For every meaningful finding require:

## Location / Action

Where exactly?

## Problem

What looks, sounds, or feels unfinished?

## Evidence

What specifically creates that impression?

## Player-Facing Impact

How visible/frequent is it?

## Recommended Fix

What practical correction is justified?

## Scope

Tiny / Small / Medium / Large.

Reject vague taste such as:

> **make it prettier**

or:

> **needs more juice**

Require concrete evidence.

---

# Fresh Screenshot Review

Review representative frames without relying on development context.

Ask:

> **What visible detail would make an outside viewer question whether this is final?**

Look for:

- hierarchy;
- clipping;
- placeholders;
- empty composition;
- UI inconsistency;
- weak pose;
- visual repetition.

Implement supported findings.

---

# Fresh Gameplay Review

Review representative continuous gameplay.

Ask:

> **What motion, sound, transition, interaction, or feedback still feels immediately amateur?**

Focus on repeated real gameplay rather than isolated assets.

---

# “What Still Feels Temporary?” Review

Search for anything that feels like it was intended to be replaced later.

Examples:

- temporary icon;
- bare text message;
- generic loading screen;
- prototype particle effect;
- default font;
- raw data label;
- flat placeholder panel;
- silent interaction.

Require evidence.

Do not replace minimalist intentional design merely because it is simple.

---

# Anti-Overpolish Review

Before completion, inspect whether final-polish changes made the game worse.

Look for:

- too many particles;
- too much glow;
- constant animation;
- excessive camera motion;
- loud audio;
- cluttered environment;
- ornate UI;
- longer interaction timing;
- reduced readability;
- generic visual trends replacing identity.

Remove unjustified embellishment.

Professional polish requires restraint.

---

# Anti-Churn Review

Ask:

- Are we still fixing meaningful visible defects?
- Or merely changing things because we can?

Do not continuously retune:

- colors;
- spacing;
- sounds;
- timing;

without clear evidence of improvement.

Final polish should converge.

---

# Anti-Consistency-At-All-Costs Review

Consistency does not mean sameness.

Preserve intentional differences between:

- areas;
- factions;
- equipment;
- interfaces;
- actions;
- reward tiers;
- soundscapes.

Fix accidental inconsistency.

Do not erase identity.

---

# Anti-Trailer-Only Review

Do not optimize only for staged footage.

Verify polish also survives:

- menus;
- failure states;
- inventory management;
- ordinary traversal;
- repetitive gameplay;
- non-cinematic moments.

The actual game must feel finished, not merely the promotional captures.

---

# Regression Review

After final polish verify relevant:

- gameplay;
- controls;
- progression;
- save/load;
- multiplayer;
- performance;
- UI scaling;
- animation timing;
- audio lifecycle;
- environment navigation.

Final polish must not introduce functional regressions.

---

# Performance Awareness

Do not materially damage performance for presentation polish.

Watch for:

- excessive particles;
- excessive lights;
- too many animated objects;
- excessive UI effects;
- too many simultaneous audio sources;
- environment overpopulation.

This is not a performance pass.

But final polish should not create obvious new performance problems.

---

# Final Commercial-Quality Walkthrough

Before finishing, perform the closest practical equivalent of a final-player review.

Inspect:

1. first launch;
2. first menu;
3. first spawn;
4. movement;
5. first interaction;
6. representative combat;
7. representative gathering/crafting where applicable;
8. inventory/equipment;
9. major UI screens;
10. several important environments;
11. dialogue where applicable;
12. rewards/progression;
13. loading/transitions;
14. death/respawn where applicable;
15. important failure states;
16. multiplayer presentation where applicable.

Observe continuously.

Do not inspect each system only in isolation.

---

# Final Trailer Test

After worthwhile fixes, ask again:

> **What would I still avoid showing?**

If the answer identifies a concrete high-visibility defect:

investigate it.

If the answer is merely:

- stylistic preference;
- content preference;
- low-value edge case;

do not manufacture additional work.

---

# Final Screenshot Test

Inspect representative screenshots again.

Ask:

> **Does anything still immediately read as placeholder, debug, broken, accidental, or visually unfinished?**

Fix remaining supported P1 issues.

---

# Final “One Product” Test

Ask:

> **Do the UI, animation, audio, environments, effects, terminology, feedback, and transitions feel like parts of one coherent product?**

Do not demand identical style everywhere.

Demand coherent intent.

---

# Completion Standard

The final commercial-quality pass is complete when, to the degree available testing can establish:

1. no known obvious P1 polish defect remains without an explicit blocker;
2. major screenshots look intentional;
3. first-launch presentation feels deliberate;
4. the first 20 minutes do not expose obvious prototype residue;
5. high-frequency actions look and feel coherent;
6. major UI screens belong to the same product;
7. player-facing placeholders are substantially reduced;
8. obvious engine defaults are substantially reduced;
9. debug residue is not exposed unintentionally;
10. major loading/error states look intentional;
11. common animation does not conspicuously undermine presentation;
12. common audio does not conspicuously undermine presentation;
13. major environments feel authored rather than obviously empty or copied;
14. major transitions are reasonably clean;
15. frequent equipment/character presentation is credible;
16. reward and action feedback have appropriate hierarchy;
17. repetition does not immediately expose implementation patterns;
18. major terminology/presentation inconsistencies are reduced;
19. polish changes remain restrained;
20. game readability has not been harmed;
21. gameplay responsiveness has not been harmed;
22. obvious new performance problems have not been introduced;
23. no known regression introduced by this pass remains;
24. fresh reviewers primarily identify subjective, low-impact, asset-dependent, or out-of-scope concerns.

The objective is not:

> **make the game indistinguishable from the largest-budget production**

The objective is:

> **remove the visible accidental roughness that makes a finished game still feel unfinished.**

---

# Final Report

When complete, provide a concise commercial-quality report.

## 1. Overall Result

Summarize how the game's perceived level of finish improved.

## 2. Top Visible Problems Fixed

List the highest-impact issues corrected.

For each major item include:

- **Location / System**
- **Problem**
- **Fix**
- **Player-facing impact**

## 3. Visual / UI

Summarize meaningful improvements to:

- visual presentation;
- HUD;
- menus;
- typography;
- hierarchy;
- loading/error presentation.

## 4. Animation / Game Feel

Summarize meaningful:

- animation;
- transition;
- responsiveness;
- interaction;
- feedback;

improvements.

## 5. Audio

Summarize meaningful:

- missing/mistimed audio;
- repetition;
- mix;
- ambience;
- feedback;

improvements.

## 6. Environment

Summarize meaningful improvements to:

- authored detail;
- landmarks;
- density;
- repetition;
- high-traffic locations.

## 7. Transitions / Placeholder Removal

Summarize:

- loading;
- scene/menu transitions;
- state changes;
- debug residue;
- placeholders;
- engine defaults.

## 8. Fresh Review Findings

Summarize the most important findings discovered during fresh commercial-quality review and what was done about them.

Do not describe tool or worker implementation details unless they materially affect the result.

## 9. Validation

State exactly what was actually inspected or tested, including relevant:

- runtime gameplay;
- screenshots;
- first-20-minute run;
- major screens;
- environments;
- animation sequences;
- audio;
- loading;
- error/failure states;
- multiplayer presentation.

Do not imply validation occurred when it did not.

## 10. Deliberately Unchanged

Describe noteworthy issues preserved because:

- they appear intentional;
- the current style supports them;
- correcting them requires major new assets;
- correcting them requires redesign;
- evidence was insufficient;
- they are too low impact to justify churn.

## 11. Remaining Issues

List only meaningful unresolved polish problems.

For each include:

- **Location / System**
- **Issue**
- **Severity**
- **Why unresolved**
- **Recommended next action**

Do not pad this section with microscopic subjective preferences.

---

# Final Directive

**Think like a reviewer seeing the game for the first time, not a developer accustomed to every rough edge.**

Repeatedly ask:

> **What still screams “unfinished”?**

> **What would I hide from a trailer?**

> **What would I avoid putting in a storefront screenshot?**

> **What would a reviewer notice immediately?**

> **What still feels temporary?**

> **Which weak area now stands out against the strongest work?**

> **What breaks the illusion that this is one professionally finished product?**

> **Did our polish make anything noisier, slower, less readable, or more generic?**

Continue:

> **inspect → rank → implement → validate → reinspect**

while meaningful, safely actionable commercial-quality gaps remain.

Leave behind the **same game**, but remove as much visible prototype residue as safely possible so it feels cohesive, intentional, restrained, confident, and professionally shipped.