You are responsible for a comprehensive **animation, character-presentation, technical-animation, and motion-polish pass**.

Your job is to make the existing game's characters and animated objects feel:

- intentional;
- readable;
- grounded;
- responsive-looking;
- coherent with gameplay state;
- visually connected from action to action;
- professionally finished rather than prototype-like.

The primary question throughout this task is:

> **What movement, transition, pose, timing, equipment, or character-presentation problems make this game look stiff, cheap, disconnected, robotic, unfinished, or visually out of sync with gameplay?**

Then fix those problems.

This is an **implementation task**, not merely an animation critique.

Do not stop after:

- identifying stiff motion;
- listing bad transitions;
- reporting foot sliding;
- recommending better timing;
- pointing out attachment problems;
- creating an animation-polish backlog.

Inspect actual runtime behavior where practical.

Identify concrete presentation defects.

Trace each defect to the underlying animation, state, timing, attachment, or synchronization issue.

Implement worthwhile corrections.

Validate them in context.

Observe again.

Continue while meaningful, safely actionable animation and character-presentation problems remain.

Use continuously:

> **observe → diagnose → implement → validate → observe again**

The goal is:

> **Leave behind the same game, but make its characters and animation substantially more grounded, coherent, responsive-looking, readable, and professionally presented.**

---

# Animation Supports Gameplay

This pass owns **presentation**, not gameplay redesign.

Do not change:

- combat rules;
- movement semantics;
- control behavior;
- targeting rules;
- authoritative timing;
- progression;
- character art direction;
- gameplay state machines;

merely to make animation easier.

Animation should visually support gameplay truth.

Do not force gameplay to conform to an animation when the established gameplay rule is correct.

If an attack mechanically resolves at time X, the animation should communicate that timing convincingly rather than silently moving the gameplay event for aesthetic convenience unless evidence clearly shows the gameplay timing itself is wrong.

---

# Core Scope

Inspect only animation and character-presentation systems that actually exist.

Relevant areas may include:

## Character States

- idle;
- locomotion;
- running;
- walking;
- turning;
- stopping;
- strafing where applicable;
- combat stance;
- gathering;
- crafting;
- interacting;
- casting;
- channeling;
- hit reactions;
- stun;
- death;
- respawn;
- emotes where relevant.

## Action Presentation

- attacks;
- abilities;
- spells;
- projectiles;
- gathering swings;
- tool use;
- crafting;
- object interaction;
- item use;
- NPC interactions.

## Animation Systems

- animation controllers;
- blend trees;
- state machines;
- layers;
- masks;
- transition rules;
- playback speed;
- normalized time;
- root motion where already used;
- procedural animation where already present;
- inverse kinematics where already present.

## Character Presentation

- stance;
- facing;
- pose;
- silhouette;
- equipment;
- held items;
- weapon/tool placement;
- sheathing;
- character orientation;
- idle behavior.

## Animation Events

- damage timing;
- sounds;
- footsteps;
- VFX;
- resource impacts;
- projectiles;
- hit markers;
- equipment visibility;
- gameplay callbacks.

## Other Animated Entities

Where present:

- creatures;
- enemies;
- NPCs;
- mounts;
- animated world objects;
- interactive props.

Only inspect systems that actually exist.

---

# Explicitly Out of Scope

This is **not primarily**:

- a combat redesign;
- a movement-system redesign;
- an input redesign;
- a control rewrite;
- a character-model redesign;
- a rigging overhaul;
- a new animation-system architecture;
- a visual-art overhaul;
- a gameplay-balance pass;
- a broad game-feel pass;
- a networking rewrite;
- a procedural-animation research project.

Small adjacent changes are allowed when directly required to correct a confirmed animation-presentation defect.

Do not allow this pass to become a broader gameplay or art redesign.

---

# Preserve Existing Product Behavior

Except where correcting an actual defect, preserve:

- gameplay timing;
- movement speed;
- attack cadence;
- hit timing;
- cooldowns;
- authoritative state;
- combat responsiveness;
- interaction rules;
- network authority;
- equipment semantics;
- character identity.

Animation polish that changes how the game plays is a regression unless the original presentation was incorrectly controlling gameplay.

---

# Preserve Existing Work

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

Do not:

- overwrite unrelated work;
- revert unfamiliar changes;
- delete ambiguous animation assets;
- replace active animation-controller work without understanding it;
- use destructive cleanup commands merely to simplify the task.

If existing changes overlap animation work:

1. inspect them;
2. determine apparent purpose;
3. preserve that intent;
4. integrate carefully;
5. avoid broad rewrites where a bounded fix is sufficient.

---

# Runtime First

Animation quality is primarily visible in motion.

Where practical, inspect actual gameplay.

Use:

- runtime play;
- editor preview;
- recorded clips;
- screenshots only for pose issues;
- animation debugging;
- state-machine inspection;
- playback-speed inspection;
- event logs;
- network state where relevant.

Do not judge animation solely from:

- source code;
- clip names;
- state names;
- asset lists.

Code alone cannot reliably reveal:

- stiffness;
- foot sliding;
- poor pose quality;
- weak silhouette;
- visual timing;
- bad blending;
- hitching;
- unnatural recovery;
- floating equipment.

If runtime observation is unavailable:

- state that limitation;
- use the strongest available evidence;
- do not claim a visual defect was directly observed when it was inferred.

---

# Investigate Before Asking Questions

Use the project as evidence.

Inspect relevant:

- animation clips;
- controllers;
- blend trees;
- state machines;
- rig configuration;
- transitions;
- playback rates;
- animation events;
- gameplay state;
- equipment attachment code;
- locomotion logic;
- network replication;
- character prefabs/scenes;
- sibling character implementations;
- tests and warnings.

Ask for clarification only when:

- intended motion cannot be established;
- several materially different presentation styles are equally plausible;
- changing timing would affect gameplay;
- equipment attachment intent is ambiguous;
- shared/networked state ownership is unclear;
- major rigging or asset production is required.

Do not ask questions merely because animation investigation takes effort.

---

# Implementation Over Critique

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

Do not spend most of the task:

- cataloguing clips;
- writing subjective animation critiques;
- producing extensive shot lists;
- theorizing about ideal motion.

Once a meaningful defect is sufficiently understood:

> **fix it.**

Then validate:

1. entry;
2. action;
3. exit;
4. repetition;
5. interruption;
6. relevant sibling states.

---

# 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 this pass sequentially.

Good independent work areas may include:

- locomotion;
- combat actions;
- gathering/crafting;
- equipment;
- NPCs;
- creatures;
- transition audit;
- animation events.

Serialize modifications involving shared:

- locomotion controllers;
- global animation state machines;
- character rigs;
- gameplay-to-animation state mapping;
- networked animation state;
- shared equipment attachment systems.

Do not let independent workstreams create incompatible animation conventions.

Use additional fresh-context review for high-risk shared or networked animation infrastructure.

---

# Animation Priority Queue

## P0 — Broken Animation State

Examples:

- frozen character;
- missing required clip;
- invalid attachment preventing play;
- state machine deadlock;
- character stuck permanently in action pose;
- death state never resolves;
- animation system prevents gameplay progression.

Fix immediately.

## P1 — Major Presentation Failure

Examples:

- obvious snapping;
- severe foot sliding;
- wrong animation for gameplay state;
- attack visually disconnected from damage;
- death state contradicts gameplay;
- major locomotion transition failure;
- equipment visibly floats or rotates incorrectly.

Prioritize heavily.

## P2 — Significant Polish Problem

Examples:

- stiff locomotion;
- weak hit reactions;
- mediocre blending;
- poor loops;
- obvious animation restart;
- weapon/tool mismatch;
- awkward facing;
- poor stop transitions.

Spend substantial effort here.

## P3 — Finishing Polish

Examples:

- subtle pose improvement;
- transition timing;
- secondary motion;
- minor loop cleanup;
- small attachment offsets.

Address after high-frequency major issues.

---

# High-Frequency Actions First

Prioritize actions players see constantly.

Usually this means some combination of:

- idle;
- movement;
- turning;
- stopping;
- common attacks;
- gathering;
- basic interactions;
- equipment presentation.

A rare cinematic animation should not receive more attention than locomotion that looks wrong every second.

Prioritize by:

> **frequency × visibility × severity**

---

# Locomotion Pass

Inspect:

> **idle → move → turn → change direction → stop**

Look for:

- foot sliding;
- incorrect playback speed;
- abrupt starts;
- abrupt stops;
- snapping rotation;
- animation lagging movement;
- movement outrunning animation;
- animation restarting constantly;
- poor directional changes;
- unnatural stop pose;
- delayed return to idle.

Preserve actual movement mechanics.

For:

- grid movement;
- click-to-move;
- directional movement;
- analog movement;
- server-authoritative movement;

synchronize presentation to the established movement model.

Do not redesign movement semantics merely to make the animation fit.

---

# Movement Speed Matching

Compare animation cycle speed against actual world movement speed.

If the character travels farther than the animation visually implies:

> **feet slide forward**

If the character moves slower than the animation implies:

> **feet appear to run in place**

Adjust presentation using the project's existing animation model.

Possible solutions may include:

- playback-speed scaling;
- blend parameters;
- clip selection;
- stride adjustment;
- existing procedural systems.

Do not introduce root motion globally without strong evidence.

---

# Start Transition Pass

Inspect:

> **idle → movement**

Look for:

- instant pose snap;
- character visually moving before legs react;
- overly long anticipation;
- delayed gameplay response;
- restart loops caused by small speed fluctuations.

The animation should acknowledge movement quickly without making controls feel sluggish.

---

# Stop Transition Pass

Inspect:

> **movement → idle**

Look for:

- sliding after movement stops;
- instant snap to neutral pose;
- unnatural foot placement;
- delayed stop;
- repeated stop/start flickering around low speeds.

Preserve responsive gameplay.

Do not force long deceleration if movement itself stops immediately.

---

# Turning Pass

Inspect:

- turning while idle;
- turning while moving;
- target-facing turns;
- rapid direction reversal.

Look for:

- snapping;
- full-body rotation without foot response;
- excessive interpolation;
- character attacking sideways;
- character visually facing away from interaction.

Use the established visual style.

Some stylized games may intentionally use fast turns.

Clean cuts can be better than slow blends.

---

# Direction Change Pass

Test:

- forward → reverse;
- left → right;
- diagonal changes;
- click-to-move path corners;
- rapidly changing targets.

Look for:

- animation restart;
- sliding;
- torso twisting unnaturally;
- direction change occurring visually too late.

Do not require complex directional animation systems unless existing assets support them.

---

# Idle Pass

Inspect idle presentation for:

- stiffness;
- unnatural neutral pose;
- constant animation restart;
- visible loop hitch;
- excessive movement;
- inappropriate combat/non-combat stance;
- equipment clipping.

Idle should look alive without becoming distracting.

Do not add constant exaggerated motion merely to make characters "less static."

---

# Action Structure

For attacks, abilities, gathering, crafting, and interactions inspect:

> **anticipation → action → impact/result → recovery**

Not every animation requires dramatic anticipation or recovery.

Use this structure as a diagnostic model.

Ask:

- When does the action visually begin?
- When does gameplay commit?
- When does the visible impact occur?
- When can the character logically transition onward?

Animation and gameplay should tell the same story.

---

# Attack Animation Pass

For each common attack inspect:

- entry;
- anticipation;
- swing/cast;
- impact;
- follow-through;
- recovery;
- transition to next attack;
- transition back to movement/idle.

Look for:

- damage occurring before visible contact;
- damage occurring long after visible contact;
- attack beginning after gameplay already resolved;
- animation continuing long after next action begins;
- repeated attacks resetting to frame zero unnaturally;
- target direction mismatch.

Do not move authoritative damage timing merely to make the animation convenient unless existing timing is demonstrably wrong.

---

# Impact Timing

The strongest visual moment should generally correspond closely with the gameplay result.

Examples:

- sword contact near damage;
- projectile release near projectile spawn;
- pickaxe strike near resource hit;
- spell release near cast resolution.

Exact frame-perfect matching may not always be appropriate.

But obvious visual/gameplay disagreement should be corrected.

---

# Repeated Attack Pass

Inspect consecutive attacks.

Look for:

- restarting too sharply;
- unnatural full reset between hits;
- overlapping recoveries;
- skipped poses;
- timing drift;
- stale events from prior attack;
- attack-speed changes breaking clip timing.

Repeated gameplay should appear intentional rather than like the same animation being force-reset.

---

# Ability / Cast Pass

Where abilities or spells exist inspect:

- windup;
- target facing;
- cast pose;
- release;
- projectile/effect timing;
- recovery;
- interruption.

Look for:

- effect appears before cast;
- projectile leaves wrong location;
- character rotates after release;
- cast loops indefinitely;
- interruption leaves character stuck.

---

# Gathering Animation Pass

For repeated gathering actions inspect:

- approach;
- facing;
- tool visibility;
- swing/use;
- contact;
- reward timing;
- repeated cycle;
- stop.

Examples:

- mining;
- woodcutting;
- fishing;
- harvesting.

Look for:

- tool striking empty space;
- character facing away from resource;
- repeated loop hitch;
- animation continuing after resource disappears;
- tool attachment mismatch.

Do not alter gathering mechanics.

Improve presentation.

---

# Crafting Animation Pass

Where crafting uses animation inspect:

- entry;
- workstation orientation;
- held tools;
- loop;
- completion;
- cancellation;
- exit.

Avoid characters:

- crafting away from station;
- looping after action completes;
- snapping immediately into unrelated pose;
- continuing after movement cancels the action.

---

# Interaction Animation Pass

Inspect:

- doors;
- chests;
- switches;
- NPC interaction;
- item use;
- world objects.

Where character animation exists, ensure:

- orientation makes sense;
- animation begins at correct time;
- world object and character presentation agree;
- completion returns cleanly to normal state.

Do not invent interaction animation where no asset or system exists.

---

# Transition Pass

Hunt high-frequency transitions such as:

- idle → move;
- move → idle;
- move → attack;
- attack → move;
- idle → attack;
- attack → idle;
- idle → interact;
- move → interact;
- gather → stop;
- hit → death;
- equip → attack;
- cast → movement.

For each ask:

- Is the source pose compatible?
- Does the transition briefly flash unrelated state?
- Is blend duration appropriate?
- Does gameplay move on before presentation?
- Is the state entered/exited repeatedly due to noisy conditions?

Use:

- deliberate blend;
- brief transition;
- clean cut;

according to style.

Longer blending is not automatically better.

---

# Transition Condition Audit

Inspect animation-state conditions.

Look for:

- contradictory conditions;
- unreachable transitions;
- transitions firing every frame;
- exit time conflicting with gameplay;
- states with no reliable exit;
- default transition overriding intended action;
- stale bool/trigger values.

Fix state-machine logic, not just visible symptoms.

---

# Flash-Frame Hunt

Search for characters briefly passing through:

- idle;
- bind pose;
- wrong weapon pose;
- unrelated locomotion;
- default state;

between intended states.

Even one or two frames of wrong pose can make transitions look broken.

Correct the state path or blending.

---

# Loop Pass

Repeated animation should not visibly hitch.

Inspect:

- idle;
- walking;
- running;
- gathering;
- crafting;
- channeling;
- ambient NPC animation.

Look for:

- discontinuous pose;
- transform jump;
- root drift;
- visible pause;
- restarting effect;
- event firing twice at loop boundary.

Fix meaningful loop discontinuity.

---

# Root Transform Drift

For looping clips inspect whether repeated cycles accumulate:

- position drift;
- rotation drift;
- vertical offset.

Ensure clip/root-motion configuration matches the project's movement model.

Do not compensate indefinitely with runtime corrections if the clip configuration itself is wrong.

---

# Grounding Pass

Characters should feel physically connected to the environment.

Look for:

- floating;
- sinking;
- foot sliding;
- sudden vertical offset;
- mismatched terrain height;
- root-motion conflict;
- feet drifting during stationary actions.

Use existing:

- terrain alignment;
- IK;
- grounding;
- character controller;
- animation offsets;

where available.

Do not introduce complex full-body IK infrastructure unless the project clearly needs it.

---

# Foot Placement

Where the project already supports foot IK or similar grounding, verify:

- feet contact ground;
- legs do not overextend;
- hips remain plausible;
- stairs/slopes do not produce severe clipping.

Where no foot-placement system exists, do not automatically build one.

Fix major presentation issues with the simplest available approach.

---

# Root Motion Review

Determine whether the project uses:

- root motion;
- code-driven movement;
- hybrid movement.

Do not mix models accidentally.

Look for:

- root motion moving character twice;
- root motion disabled while clips expect it;
- code movement fighting animated translation;
- rotation applied both by animation and gameplay.

Preserve established authoritative movement.

---

# Facing & Orientation

Check whether characters face appropriate:

- movement direction;
- attack target;
- interaction object;
- resource node;
- NPC conversation target.

Look for:

- attacking sideways;
- gathering while facing away;
- rotating after swing begins;
- snapping at final frame;
- slowly rotating when fast turn is appropriate.

Facing should communicate intention.

---

# Target-Facing Timing

When actions target something, inspect when orientation occurs.

Often the character should orient:

- before;
- or during early anticipation;

rather than snapping at impact.

However, preserve gameplay responsiveness and existing timing.

Do not add long forced turning delays unless mechanically intended.

---

# Hit Reaction Pass

Where hit reactions exist inspect:

- timing;
- frequency;
- direction;
- severity;
- interruption;
- stacking;
- transition back to action.

Avoid:

- hit reaction occurring long after damage;
- reaction constantly restarting under rapid damage;
- minor hits producing exaggerated full-body interruption;
- reaction preventing important gameplay readability.

Use reactions to communicate impact without making characters unusably twitchy.

---

# Reaction Variety

If multiple existing hit reactions are available, inspect whether repetition makes combat visibly mechanical.

Variation can help where supported.

Do not introduce large random animation systems merely to avoid repetition.

Preserve readability.

---

# Death Presentation

Death should visually agree with gameplay state.

Inspect:

> **alive → lethal event → death transition → final state → despawn/respawn**

Look for:

- character continuing normal attack after death;
- death animation starting twice;
- hit reaction overriding death;
- immediate pop to death pose;
- corpse returning briefly to idle;
- gameplay targetability disagreeing with visible death;
- despawn occurring before death can be read.

Death should resolve once.

---

# Death Priority

Ensure lethal state has appropriate animation priority.

A character should not be held in:

- gather;
- craft;
- attack;
- hit;

when authoritative gameplay already says it is dead.

Avoid conflicting transitions.

---

# Respawn Transition

If respawn exists inspect:

- old corpse cleanup;
- character reappearance;
- idle state initialization;
- equipment;
- pose;
- movement state.

Avoid respawning into:

- death pose;
- attack state;
- stale locomotion;
- wrong equipment visibility.

---

# Equipment & Held Item Pass

Inspect existing:

- weapons;
- shields;
- tools;
- ranged equipment;
- spellcasting props;
- gathering tools;
- held quest items.

Check:

- attachment point;
- orientation;
- scale;
- hand alignment;
- clipping;
- visibility;
- sheathing;
- switching.

A technically functional equipment system can still look unfinished if items visibly float or intersect the character.

---

# Attachment Point Audit

Compare attachment conventions across similar items.

Look for:

- one weapon using wrong socket/bone;
- inconsistent local orientation;
- incorrect handedness;
- tool attached to wrist instead of hand;
- shield floating away from arm;
- two-handed item using one-handed alignment.

Fix common high-frequency issues first.

---

# Equipment Scale Consistency

Inspect whether equipped item scale matches:

- world representation;
- character proportions;
- sibling equipment.

Avoid accidental:

- tiny weapon;
- oversized tool;
- inconsistent scale after equipping.

Preserve intentionally exaggerated art style.

---

# Equipment Visibility State

Inspect:

- equipped;
- sheathed;
- combat;
- gathering;
- crafting;
- death;
- respawn.

Look for:

- duplicate visible weapon;
- hidden weapon during intended attack;
- old tool remaining after action;
- equipment visible through incompatible state.

Ensure visibility follows established gameplay state.

---

# Equipment Switching

Test rapid:

- equip;
- unequip;
- weapon swap;
- tool swap.

Look for:

- attachment lag;
- old item lingering;
- wrong animation state;
- duplicate equipment;
- brief default pose.

Presentation should converge quickly on authoritative equipment.

---

# Character Presentation Pass

Compare playable characters and important NPCs for:

- stance;
- silhouette;
- pose;
- facing;
- idle quality;
- equipment;
- scale;
- visual consistency.

Do not redesign character models.

Improve how existing assets are presented.

---

# Default Pose Hunt

Look for accidental:

- T-pose;
- A-pose;
- bind pose;
- neutral rig state;
- engine-default pose;

appearing:

- during load;
- during state transition;
- after respawn;
- after equipment swap;
- before remote player initialization.

Treat visible default-pose flashes as meaningful defects.

---

# NPC Animation Pass

For important NPCs inspect:

- idle;
- locomotion;
- facing;
- interaction;
- ambient animation;
- transitions.

Look for:

- statuesque NPCs where existing clips should be active;
- NPCs rotating unnaturally;
- dialogue target mismatch;
- ambient loops restarting.

Do not invent elaborate schedules or simulation.

---

# Creature Animation Pass

Where creatures exist, inspect:

- locomotion speed matching;
- attacks;
- turns;
- hit reactions;
- death;
- orientation;
- scale.

Non-humanoid creatures may need different transition expectations.

Do not force humanoid animation conventions onto them.

---

# Animated World Object Pass

Where world objects animate, inspect:

- doors;
- chests;
- machinery;
- resource nodes;
- traps;
- moving platforms.

Look for:

- gameplay state changes before object animation;
- repeated open animation;
- state snapping;
- loop hitch;
- multiple clients disagreeing where applicable.

Presentation should communicate object state accurately.

---

# Animation Event Audit

Inspect animation events driving:

- damage;
- projectiles;
- footsteps;
- sounds;
- VFX;
- gathering impact;
- tool visibility;
- hit effects.

Determine whether each event is:

- presentation-only;
- gameplay-authoritative;
- synchronization point.

Do not accidentally create two authoritative systems.

---

# Gameplay Authority Versus Animation Event

If gameplay owns action resolution, animation events should usually present that result rather than determine whether the result exists.

Be careful when:

- damage depends entirely on clip event;
- networked combat depends on local animation;
- frame rate affects event delivery;
- animation interruption skips important authoritative mutation.

Preserve intentional animation-driven mechanics where clearly established.

But fix fragile accidental authority.

---

# Missing Animation Event Hunt

Look for clips where expected:

- sound;
- VFX;
- projectile;
- resource impact;
- footstep;

never occurs because the event is missing or incorrectly referenced.

Verify against complete sibling clips.

Do not add events simply because an effect could look nice.

---

# Duplicate Animation Event Hunt

Inspect whether:

- loop boundaries;
- transition blending;
- repeated state entry;
- multiplayer replication;

cause one event to fire multiple times.

This is especially important when animation events trigger consequential gameplay.

---

# Footstep Pass

If footsteps exist inspect:

- timing;
- duplicate playback;
- missing playback;
- movement-speed mismatch;
- footsteps while sliding/stationary.

Do not turn this into a full audio pass.

Fix synchronization problems.

---

# Audio Synchronization

For existing action sounds inspect whether:

- swing sound occurs before swing;
- impact sound occurs far from impact;
- crafting sound loops incorrectly;
- death audio repeats.

Align existing sound to motion where appropriate.

---

# VFX Synchronization

For existing effects inspect:

- cast effect;
- muzzle/projectile origin;
- hit effect;
- gathering impact;
- death effect.

Look for effects that:

- spawn too early;
- spawn too late;
- remain after state changed;
- use wrong attachment.

Do not invent new VFX content.

---

# Projectile Presentation

Where projectiles exist inspect:

- spawn point;
- character pose;
- release timing;
- facing;
- target direction.

Avoid projectiles visually leaving:

- the character's torso;
- wrong hand;
- behind the character;
- long before release pose.

Preserve projectile mechanics.

---

# Animation Layering

If multiple animation layers exist, inspect:

- masks;
- priorities;
- upper-body actions;
- locomotion interaction;
- equipment poses;
- hit reactions.

Look for:

- lower body frozen unexpectedly;
- attack replacing full body unnecessarily;
- additive layer producing distorted pose;
- incompatible layers accumulating.

Do not add layers unless existing architecture benefits clearly.

---

# Blend Tree Pass

Where blend trees exist inspect:

- parameter ranges;
- dead zones;
- thresholds;
- direction mapping;
- playback speed;
- interpolation.

Look for:

- sudden jumps between adjacent clips;
- wrong directional clip;
- unnecessary oscillation around threshold;
- clips never reachable.

Tune based on actual runtime motion.

---

# State-Machine Completeness

For major animation states identify:

- entry;
- valid transitions;
- exit;
- interruption;
- higher-priority state.

Look for:

- states with no exit;
- transitions requiring impossible condition;
- stale trigger preventing re-entry;
- death/action conflict;
- fallback into wrong state.

Fix lifecycle problems.

---

# Trigger / Flag Cleanup

Animation parameters can become stale.

Inspect:

- booleans;
- triggers;
- integer state IDs;
- normalized-time checks;
- speed thresholds.

Look for:

- trigger never reset;
- bool remains true after action;
- stale target state;
- one-shot action treated as permanent state.

Use the controller's intended parameter semantics.

---

# Playback-Speed Review

Inspect clips modified by:

- attack speed;
- movement speed;
- gathering speed;
- buffs;
- equipment.

Look for:

- extreme speed distortion;
- visual impact no longer aligning with gameplay;
- slow-motion-looking actions;
- animation events moving to wrong perceived timing.

Prefer bounded, intentional scaling.

Do not make every action dynamically time-scaled if the system was not designed for it.

---

# Action Timing Changes

Before changing animation duration or playback speed ask:

> **Is gameplay timing authoritative here?**

If yes:

- adapt animation presentation.

If no:

- determine whether animation timing itself controls the established action.

Do not unknowingly rebalance attacks, gathering, casting, or interactions.

---

# Multiplayer Animation Pass

If multiplayer exists, distinguish:

- authoritative gameplay state;
- local animation presentation;
- remote animation presentation;
- replicated equipment;
- replicated state transitions.

Test:

- normal remote movement;
- attacks;
- death;
- reconnect;
- late join;
- rapid state changes;
- equipment swaps;
- despawn.

---

# Network State Versus Clip State

Prefer replicating meaningful gameplay state when existing architecture supports it.

Examples:

- moving;
- attacking;
- gathering;
- dead;
- equipped weapon.

Avoid sending unnecessary clip-level details if remote clients can correctly derive presentation.

Do not redesign networking merely to reduce animation messages.

---

# Remote Locomotion

Inspect remote characters for:

- jitter;
- frozen animation;
- animation speed unrelated to replicated movement;
- walking while stationary;
- sliding while moving;
- abrupt direction changes.

Coordinate presentation with the networking model.

Do not make animation compensate for fundamental network-state corruption that belongs elsewhere.

---

# Remote Action Timing

Inspect whether remote:

- attacks;
- casts;
- gathering actions;
- deaths;

visually align reasonably with replicated gameplay events.

Perfect local-frame matching may be impossible under latency.

The goal is coherent presentation, not pretending latency does not exist.

---

# Late Join Animation State

A late-joining client should not initialize existing players in visibly incorrect states.

Test joining while another entity is:

- moving;
- attacking;
- gathering;
- dead;
- equipped with non-default gear.

Ensure current gameplay state can initialize appropriate presentation.

---

# Disconnect / Despawn

When remote entities disconnect or despawn:

- stop pending animation work;
- remove presentation safely;
- prevent stale callbacks;
- avoid one final state update resurrecting visual state.

---

# Procedural Animation Awareness

If procedural systems already exist, inspect relevant:

- aim offsets;
- look-at;
- IK;
- recoil;
- procedural leaning;
- foot placement.

Fix broken interactions.

Do not build major procedural-animation infrastructure from scratch unless a confirmed high-impact defect cannot be solved otherwise.

---

# Pattern-Based Defect Hunt

When one problem is found, search sibling assets or states.

Examples:

If one tool attachment is wrong:

> inspect other tools.

If one attack's event timing is wrong:

> inspect the attack family.

If one state lacks an exit:

> inspect equivalent states.

If one death clip conflicts with hit reaction:

> inspect other characters sharing the controller.

Fix repeated faulty patterns where justified.

---

# Animation Warning / Error Hunt

Inspect runtime/editor warnings related to:

- missing clips;
- invalid animation names;
- missing bones;
- invalid state;
- attachment failures;
- missing events;
- controller references.

Do not treat every warning as player-facing.

Prioritize warnings that correspond to real presentation or lifecycle defects.

---

# Clip Inventory Review

Where useful, identify:

- used clips;
- unused clips;
- duplicated clips;
- missing states;
- wrong loop settings;
- mismatched naming.

Do not automatically wire unused clips.

Unused may mean:

- obsolete;
- future;
- alternate;
- abandoned.

Require evidence before activation.

---

# Sibling Comparison

Compare complete animation families.

Examples:

- one weapon family versus another;
- mining versus woodcutting;
- one NPC versus similar NPC;
- one creature attack versus another.

Compare:

- entry;
- impact timing;
- recovery;
- transitions;
- events;
- attachment;
- stop behavior.

Use complete siblings as evidence.

Do not homogenize intentional style differences.

---

# Screenshot / Silhouette Review

For important poses inspect static frames where useful.

Ask:

- Is the silhouette readable?
- Does held equipment obscure the pose?
- Does stance communicate the state?
- Does the pose collapse from normal gameplay camera distance?

Animation must read from the game's actual camera, not only close-up editor view.

---

# Gameplay-Camera Review

Always evaluate presentation from the normal gameplay camera.

A beautiful close-up animation may still look:

- unreadable;
- too subtle;
- awkward;
- visually noisy;

from the actual player viewpoint.

Prioritize what players see.

---

# Productive Animation Loop

After each meaningful wave ask:

- Which common action still looks stiffest?
- Where does animation disagree with gameplay?
- What still snaps?
- What still slides?
- What still floats?
- What still hitches?
- Which equipment looks incorrectly attached?
- Which loop visibly restarts?
- Which impact happens at the wrong visual time?
- Which character still looks least finished?

Continue:

> **observe → diagnose → implement → validate → observe again**

while material, safely actionable presentation problems remain.

Do not manufacture animation complexity merely to continue working.

Stop when remaining issues are:

- subjective;
- very low visibility;
- dependent on new animation assets;
- dependent on rig redesign;
- dependent on broader gameplay changes;
- outside scope.

---

# Work in Animation Waves

Do not polish random clips across the whole project.

## Wave A — Broken States

Fix:

- frozen states;
- missing clips;
- deadlocks;
- default-pose flashes;
- invalid attachments;
- broken death/respawn.

Validate.

## Wave B — Locomotion

Polish:

- idle;
- movement;
- turning;
- direction changes;
- stops;
- speed matching;
- grounding.

Validate in continuous play.

## Wave C — Core Actions

Polish high-frequency:

- attacks;
- abilities;
- gathering;
- crafting;
- interactions.

Focus on action/result timing.

Validate.

## Wave D — Transitions and Loops

Fix:

- snapping;
- poor blending;
- flash frames;
- loop hitches;
- stale parameters;
- action exits.

Validate.

## Wave E — Equipment and Character Presentation

Fix:

- attachments;
- scale;
- orientation;
- clipping;
- visibility;
- stances;
- important NPC/creature presentation.

Validate.

## Wave F — Events and Multiplayer

Inspect relevant:

- audio;
- VFX;
- footsteps;
- projectiles;
- remote state;
- late join;
- death;
- equipment replication.

Validate.

## Wave G — Last 10%

Search for:

- subtle snapping;
- minor slide;
- weak pose;
- repeated motion;
- small timing mismatch;
- lower-priority character presentation.

---

# Reassess After Every Wave

Ask:

- What is now the most obvious animation flaw?
- Which high-frequency action still looks unfinished?
- Did a transition fix create latency or sluggishness?
- Did playback changes alter gameplay timing?
- Did equipment changes break another character?
- Did networked presentation diverge?
- Are animation events still correctly synchronized?
- Did additional blending reduce readability?
- Did we add unnecessary motion?

Reprioritize.

---

# Fresh Independent Animation Review

Near completion, review gameplay from fresh context.

Ask:

> **What animation or character behavior still immediately looks amateur, stiff, broken, disconnected, or unfinished?**

Require concrete findings.

For each include:

## Character / Object

Which one?

## Action

What exact state or transition?

## Evidence

What visually looks wrong?

## Impact

How often and how strongly does the player see it?

## Fix

What practical correction is justified?

## Scope

Tiny / Small / Medium / Large.

Implement worthwhile findings.

Reject vague criticism.

---

# High-Risk Review

Use extra scrutiny for changes involving:

- shared locomotion controller;
- gameplay-authoritative animation events;
- networked animation state;
- shared state machines;
- procedural animation foundations.

Challenge:

- gameplay timing;
- network authority;
- state deadlocks;
- interruption;
- stale state;
- regressions across sibling characters.

Do not approve a change merely because one clip looks better.

---

# Anti-Overanimation Review

Before completion inspect whether animation polish made the game worse.

Look for:

- excessive anticipation;
- sluggish controls;
- overlong recovery;
- too much blending;
- constant unnecessary secondary motion;
- exaggerated hit reactions;
- animation overriding responsive movement;
- excessive turn smoothing;
- visual flourish delaying gameplay.

Remove unjustified animation complexity.

Professional animation supports the game.

It does not fight the controls.

---

# Anti-Blend-Everything Review

Do not assume every transition needs a long blend.

Long blends can cause:

- mushy motion;
- strange intermediate poses;
- delayed readability;
- attacks blending through incompatible poses.

Use:

- hard cuts;
- short blends;
- longer blends;

according to the actual motion.

---

# Anti-Root-Motion Review

Do not introduce root motion simply to eliminate visible sliding if the game's movement model is code- or server-driven.

Root-motion changes can affect:

- controls;
- pathfinding;
- networking;
- collision;
- authoritative position.

Use the existing movement model unless redesign is explicitly justified.

---

# Regression Review

After animation changes verify:

- movement still behaves correctly;
- attacks retain intended timing;
- gathering/crafting timing is unchanged unless intentionally corrected;
- equipment state remains correct;
- hit/death logic remains correct;
- network authority remains unchanged;
- save/load does not break character state where relevant;
- no new animation warnings/errors were introduced.

Presentation polish must not break gameplay.

---

# Final Runtime Review

Before finishing, perform representative continuous gameplay rather than testing only isolated clips.

Include relevant:

1. spawn;
2. idle;
3. movement;
4. turning;
5. stopping;
6. common interaction;
7. common combat;
8. hit reaction;
9. death/respawn where applicable;
10. gathering/crafting where applicable;
11. equipment swaps;
12. multiplayer remote characters where applicable.

Watch transitions between actions.

Many animation defects only appear in sequences.

---

# Completion Standard

The animation and character-presentation pass is complete when, to the degree existing assets and technology allow:

1. major animation states function correctly;
2. no known high-frequency animation deadlock remains;
3. locomotion visually matches movement reasonably well;
4. major foot sliding is reduced;
5. obvious snapping is reduced;
6. idle/move/stop transitions are coherent;
7. turning presentation is appropriate;
8. common action animations align with gameplay results;
9. attack/cast impact timing is visually coherent;
10. gathering/crafting actions align with their results where applicable;
11. high-frequency loops do not visibly hitch;
12. major equipment attachments look credible;
13. held items use appropriate orientation and scale;
14. important characters have coherent stance and presentation;
15. hit reactions support readability;
16. death presentation agrees with gameplay state;
17. animation events are not obviously duplicated or missing;
18. remote animation state is coherent where multiplayer exists;
19. late join and equipment changes initialize presentation correctly where applicable;
20. animation polish has not made gameplay sluggish;
21. intentional gameplay timing and authority remain intact;
22. no discovered P0/P1 animation issue remains unresolved without an explicit blocker;
23. no known regression introduced by this pass remains;
24. remaining issues require new animation assets, rig changes, broader gameplay redesign, are highly subjective, or are outside scope.

The objective is not:

> **maximum animation complexity**

The objective is:

> **make existing characters clearly and convincingly express the gameplay state they are already in.**

---

# Final Report

When complete, provide a concise animation and character-presentation report.

## 1. Overall Result

Summarize the largest improvements to animation quality and character presentation.

## 2. Locomotion

Describe meaningful improvements to:

- idle;
- movement;
- turning;
- stops;
- grounding;
- sliding.

## 3. Actions / Combat

Summarize meaningful improvements to:

- attacks;
- abilities;
- gathering;
- crafting;
- interactions;
- impact timing.

Include only systems that exist.

## 4. Transitions / Loops

Describe significant:

- blend;
- state-machine;
- loop;
- flash-frame;
- state-exit;

fixes.

## 5. Equipment / Character Presentation

Summarize meaningful:

- attachment;
- orientation;
- scale;
- clipping;
- stance;
- NPC/creature;

improvements.

## 6. Animation Events / Presentation Integration

Describe important fixes involving:

- sounds;
- VFX;
- projectiles;
- footsteps;
- gameplay-event synchronization.

## 7. Multiplayer Considerations

Where applicable, summarize:

- remote animation;
- replicated state;
- late join;
- equipment swaps;
- death/despawn presentation.

## 8. Validation

State exactly what was actually tested, including relevant:

- runtime actions;
- transition sequences;
- loop tests;
- equipment swaps;
- death/respawn;
- multiplayer observation;
- automated validation;
- editor warnings.

Do not imply visual validation occurred when it did not.

## 9. Deliberately Unchanged

Describe noteworthy animation issues preserved because:

- they require new assets;
- they require rig changes;
- gameplay timing would be harmed;
- behavior is stylistically intentional;
- evidence was insufficient;
- another specialized pass should own them.

## 10. Remaining Issues

List only meaningful unresolved animation problems.

For each include:

- **Character / Object**
- **Action / State**
- **Problem**
- **Severity**
- **Why unresolved**
- **Recommended next action**

Do not pad this section with microscopic subjective polish.

---

# Final Directive

**Think like an animation director watching actual gameplay, not a programmer inspecting clip names.**

Repeatedly ask:

> **Does the character's body clearly express the state the game says it is in?**

> **Does this motion connect cleanly to what came before and what comes next?**

> **Does the visual impact align with the gameplay result?**

> **Does anything snap, slide, float, hitch, restart, or visually happen at the wrong time?**

> **Does the equipment look physically connected to the character?**

> **Does the animation support responsiveness rather than fight it?**

Continue:

> **observe → diagnose → implement → validate → observe again**

while meaningful animation and character-presentation problems remain.

Leave behind the **same game**, but make its characters, equipment, movement, action presentation, transitions, and animation substantially more grounded, coherent, responsive-looking, readable, and professionally finished.