Polish an existing game's movement, combat, interactions, feedback, timing, camera response, animation response, and controls so moment-to-moment play feels responsive, satisfying, deliberate, and professionally tuned.
You are responsible for a comprehensive **game feel and interaction polish pass**.
Your job is to make the existing game **feel substantially better to play**.
The primary question throughout this task is:
> **What makes this game feel sluggish, cheap, stiff, delayed, disconnected, unsatisfying, awkward, unclear, inconsistent, or mechanically under-polished during actual moment-to-moment play?**
Then fix those problems.
This is an **implementation task**, not merely a game-feel audit.
Do not stop after:
- identifying rough interactions;
- listing opportunities for "juice";
- describing ideal responsiveness;
- creating recommendations;
- writing a polish backlog;
- discussing game-feel theory;
- suggesting improvements without implementing them.
Inspect the actual game and project, understand its existing interaction model, identify concrete weaknesses, prioritize them, implement worthwhile improvements, validate them in context, reassess with fresh eyes, and continue while meaningful improvements remain.
The goal is:
> **Make the same game feel more immediate, deliberate, satisfying, predictable, tactile, and professionally tuned without redesigning what the game fundamentally is.**
---
# Game Feel Is the Priority
Prioritize approximately:
1. input acknowledgement;
2. responsiveness;
3. action timing;
4. movement feel;
5. interaction feel;
6. combat feel;
7. interruption and cancellation behavior;
8. targeting and selection;
9. action feedback;
10. repeated-action flow;
11. animation response;
12. camera response;
13. audio response;
14. state transitions;
15. failure feedback;
16. subtle finishing polish.
This is not a rigid ordering.
Prioritize the highest-value problems actually present in the game.
A player-visible interaction problem should normally outrank:
- internal code cleanliness;
- accessibility additions;
- visual beautification unrelated to interaction;
- backend refactoring;
- speculative optimization;
- new feature work.
Those areas belong to separate passes unless they directly block an interaction improvement.
---
# Core Scope
This pass owns **moment-to-moment interaction quality**.
Relevant areas may include:
- input acknowledgement;
- mouse clicks;
- taps;
- button presses;
- controller actions;
- movement requests;
- point-and-click movement;
- direct movement;
- movement start;
- movement stop;
- movement redirection;
- acceleration and deceleration where applicable;
- turning;
- path requests;
- path interruption;
- path failure;
- targeting;
- target switching;
- hover feedback;
- entity selection;
- world-object selection;
- NPC interaction;
- gathering;
- crafting interactions;
- item use;
- inventory actions where they affect feel;
- equipment interaction;
- combat actions;
- attacks;
- abilities;
- spells;
- projectiles;
- cooldown feedback;
- hit confirmation;
- damage response;
- misses;
- blocks;
- dodges;
- death response;
- loot interaction;
- XP and progression feedback;
- contextual actions;
- action queuing;
- repeated actions;
- interruption;
- cancellation;
- unavailable actions;
- failed actions;
- action transitions;
- animation timing where it affects responsiveness;
- sound timing where it affects responsiveness;
- VFX timing where it affects responsiveness;
- camera response where it affects control feel;
- cursor and world feedback;
- directly felt state changes;
- micro-delays;
- awkward pauses;
- unnecessary friction;
- inconsistent interaction timing.
Only improve systems that actually exist.
---
# Explicitly Out of Scope
This is **not primarily**:
- an art-direction pass;
- environment beautification;
- lighting polish;
- material polish;
- a dedicated UI visual-design pass;
- an accessibility audit;
- a technical-debt cleanup;
- repository cleanup;
- a balance redesign;
- progression redesign;
- economy redesign;
- content expansion;
- world expansion;
- persistence hardening;
- multiplayer architecture redesign;
- a broad performance optimization pass;
- dedicated audio production;
- deep animation-system reconstruction;
- a new-feature sprint.
Animation, audio, VFX, camera, and UI may be modified **when they directly improve the feel, timing, acknowledgement, or clarity of an existing player interaction**.
Do not let those supporting disciplines take over the task.
Record worthwhile out-of-scope findings for another specialized pass.
---
# Preserve the Existing Game
Do not mistake:
> **better game feel**
for:
> **different gameplay.**
First understand what the game is trying to be.
A deliberate tactical game should not automatically become twitchy arcade action.
A relaxed gathering game should not become hyperactive.
A click-to-move RPG should not be converted into direct keyboard movement merely because direct movement might feel more immediate.
A slow heavy attack may intentionally be slow.
A long gathering action may intentionally take time.
A server-authoritative action may intentionally wait for authority.
The correct question is:
> **Does the existing intended action feel as good as it reasonably can within its intended pacing, rules, and technical constraints?**
Preserve where intentional:
- movement model;
- combat model;
- interaction model;
- pacing;
- action durations;
- cooldown rules;
- progression;
- authoritative server behavior;
- multiplayer rules;
- intended animation commitments;
- game identity.
Only alter these when evidence shows the current behavior is defective, accidental, inconsistent, or clearly undermining the intended experience.
---
# Responsiveness Does Not Mean Instant Completion
This distinction is critical.
An action may deliberately require:
- several frames;
- hundreds of milliseconds;
- an animation cycle;
- several game ticks;
- a server response;
- a multi-second action duration;
and still feel responsive.
The game should quickly communicate:
> **I received your command.**
Then communicate what is happening.
A well-feeling interaction often contains stages such as:
1. player expresses intent;
2. game acknowledges intent;
3. target or action becomes clear;
4. action begins;
5. progress or commitment is visible where appropriate;
6. action succeeds, fails, or is interrupted;
7. completion is communicated;
8. the player returns to the expected control state.
Do not artificially shorten intended actions merely to improve responsiveness.
Improve the **communication and transition around the action**.
---
# Input-to-Feedback Latency
For every important interaction, inspect the chain:
> **Player input → acknowledgement → gameplay state → visible/audible feedback → completion**
Look for delays or disconnects between these stages.
Examples:
- input is accepted but nothing visibly changes for noticeable time;
- targeting updates late after a command;
- interaction begins internally before animation acknowledges it;
- a movement destination changes but there is no immediate feedback;
- an ability enters cooldown without clear activation feedback;
- gathering starts but the player cannot tell whether the input registered.
Where safe, acknowledge intent immediately even when authoritative completion happens later.
---
# Observe Actual Gameplay
Where practical, inspect the game running.
Do not evaluate game feel exclusively from source code.
Use the strongest available evidence:
- actual gameplay;
- runtime inspection;
- recorded gameplay;
- tests;
- input handling;
- action state;
- animation state;
- VFX;
- sound triggers;
- pathfinding;
- networking;
- cooldown state;
- camera behavior;
- UI feedback.
Code can explain **why** something feels wrong.
It cannot fully substitute for observing what the player experiences.
If direct gameplay observation is unavailable, state that limitation and use the best available evidence rather than pretending the feel was personally validated.
---
# Establish the Core Interaction Loops
Identify the game's most frequent and important player actions.
Depending on the game, these may include:
- moving;
- changing movement destination;
- selecting targets;
- attacking;
- switching targets;
- using abilities;
- gathering;
- crafting;
- interacting with world objects;
- interacting with NPCs;
- looting;
- opening containers;
- equipping items;
- using inventory objects;
- jumping;
- dodging;
- blocking;
- building;
- placing objects;
- driving or controlling vehicles;
- interacting with gameplay menus.
Determine which actions happen:
- constantly;
- frequently;
- occasionally;
- rarely.
Polish the actions players perform hundreds or thousands of times before obsessing over rare interactions.
---
# Execution Strategy
Work autonomously where the environment permits.
Investigate before asking questions.
Use the actual project as evidence.
Ask for clarification only when:
- intended gameplay cannot be established;
- several materially different behaviors are equally plausible;
- a change would alter an important design decision;
- authoritative multiplayer behavior is unclear;
- required external access is unavailable;
- proceeding would create substantial regression risk.
Do not ask questions merely because investigation takes effort.
If the environment supports parallel agents, workers, subprocesses, or independent workstreams, use them for clearly separated tasks when useful.
Do not require delegation.
A single capable session should be able to execute this prompt sequentially.
When delegation is available:
- use mechanical work for searches, tracing, inventories, and validation;
- use bounded workstreams for isolated interaction families;
- reserve deeper independent analysis for shared, networked, stateful, or high-risk systems;
- centralize shared gameplay rules and integration decisions;
- prevent independent workstreams from inventing incompatible interaction semantics.
Parallelize independent areas such as:
- movement;
- combat;
- gathering;
- NPC interaction;
- inventory interaction;
- camera response;
- cursor feedback;
- interaction feedback.
Serialize work involving shared:
- action state;
- movement authority;
- targeting;
- combat state;
- animation state;
- cooldown rules;
- common interaction routing;
- camera foundations.
---
# Implementation Over Auditing
The audit exists only to create an **implementation queue**.
Do not spend most of the task creating:
- exhaustive interaction inventories;
- theoretical recommendations;
- giant UX documents;
- subjective critiques;
- speculative features.
Once sufficient evidence exists to improve something safely:
> **implement it.**
Use this loop:
> **Play/inspect → identify friction → determine root cause → implement → validate → compare → continue**
Work through coherent interaction families rather than making random micro-adjustments.
---
# Interaction Priority Queue
Classify findings approximately as follows.
## P0 — Broken Interaction
Examples:
- input is occasionally ignored;
- actions get stuck;
- movement locks incorrectly;
- interactions become impossible;
- cancellation leaves invalid state;
- targeting selects the wrong object;
- actions trigger twice;
- actions never complete;
- repeated actions corrupt state;
- animation/action state deadlocks;
- player control is unexpectedly lost.
Fix these first.
## P1 — Major Feel Problems
Examples:
- obvious input delay;
- no acknowledgement after important commands;
- awkward movement starts or stops;
- frustrating targeting;
- attacks feel disconnected from hits;
- gathering feels unresponsive;
- cancellation behavior is confusing;
- repeated interactions require unnecessary clicks;
- major state transitions feel abrupt;
- camera behavior fights the player;
- common actions feel inconsistent.
These strongly affect perceived quality.
## P2 — Significant Polish
Examples:
- weak hit confirmation;
- mediocre cursor feedback;
- inconsistent timing;
- imperfect action blending;
- awkward interaction sequencing;
- weak cooldown acknowledgement;
- repeated-action roughness;
- inconsistent target selection;
- weak failure feedback;
- mild camera-response problems.
Spend substantial effort here.
## P3 — Finishing Details
Examples:
- tiny timing inconsistencies;
- subtle feedback omissions;
- minor transition awkwardness;
- modest camera easing;
- small animation timing corrections;
- subtle cursor improvements;
- restrained secondary feedback.
Professional feel often comes from accumulated P3 improvements after larger problems are solved.
---
# Input Acknowledgement Pass
Inspect every high-frequency action.
When input is accepted, determine whether the player receives immediate enough acknowledgement.
Possible acknowledgement includes:
- cursor state;
- target highlight;
- destination marker;
- character orientation;
- animation anticipation;
- small UI state change;
- sound;
- VFX;
- action indicator;
- progress state.
Avoid unnecessary spectacle.
Acknowledgement simply needs to communicate:
> **Your action was received.**
---
# Click and Selection Feel
For games using mouse, touch, pointer, or targeting input, inspect:
- hover state;
- clickable boundaries;
- target highlighting;
- selected state;
- destination indication;
- misclick handling;
- click priority;
- overlapping objects;
- target switching;
- input passing through UI;
- inputs unexpectedly blocked;
- dead zones;
- double-click behavior where relevant.
Selections should feel:
- consistent;
- predictable;
- immediate;
- clearly confirmed.
Do not require players to wonder whether the game accepted an input.
---
# Movement Feel Pass
Inspect the entire movement loop:
> **request → start → travel → redirect → arrive → stop**
Look for:
- input delay;
- delayed facing;
- abrupt acceleration;
- unnatural stopping;
- overshooting;
- oscillation;
- jitter;
- path recomputation stalls;
- animation lag;
- foot sliding;
- destination confusion;
- turning awkwardness;
- stop/start snapping;
- poor redirection;
- poor arrival behavior.
For point-and-click movement specifically inspect:
- destination acknowledgement;
- changing destination while moving;
- clicking close to the character;
- repeated clicks;
- invalid destination feedback;
- obstacle/path failure behavior;
- arrival tolerance;
- path smoothing;
- animation/path synchronization.
For direct movement, inspect relevant:
- acceleration;
- deceleration;
- turning;
- direction changes;
- air control where applicable;
- slope response;
- ground transitions;
- stopping;
- camera-relative movement;
- input normalization.
Do not change the intended movement model.
Make that movement model feel better.
---
# Interaction Range and Approach
For interactions requiring the player to approach a target, inspect:
- when approach begins;
- where the player stops;
- orientation on arrival;
- distance tolerance;
- path failure;
- moving targets;
- interaction triggering too early;
- interaction triggering too late;
- tiny position corrections;
- oscillation around the target.
A common amateur-feeling sequence is:
> **approach → awkward shuffle → rotate → pause → finally act**
Reduce unnecessary mechanical hesitation while preserving the rules.
---
# Action Start and Commitment
Inspect transitions from idle or movement into actions such as:
- attack;
- gather;
- craft;
- talk;
- cast;
- loot;
- interact;
- use item;
- activate ability.
Look for:
- dead pauses;
- duplicated delays;
- late animation;
- animation beginning before gameplay state;
- state beginning before feedback;
- arbitrary lockouts;
- unnecessary reorientation delays.
The action should transition clearly from:
> **intent**
to:
> **commitment.**
---
# Repeated Actions
Repeated interactions expose poor game feel quickly.
Test relevant:
- repeated attacks;
- repeated gathering;
- repeated crafting;
- repeated movement commands;
- repeated target switching;
- repeated looting;
- repeated ability use;
- rapid UI interaction.
Look for:
- accumulating delay;
- lost input;
- duplicate input;
- action overlap;
- animation restart spam;
- inconsistent cooldown behavior;
- unnecessary re-clicking;
- state desynchronization;
- poor queuing.
High-frequency gameplay should remain smooth over long sessions.
---
# Action Queueing
Determine whether the game already supports or clearly benefits from bounded action queueing.
Do **not** automatically add an action queue.
Where queuing exists, inspect:
- queue size;
- replacement rules;
- duplicate requests;
- cancellation;
- priority;
- stale actions;
- target invalidation;
- state changes while queued.
Player intent should not survive long enough to become surprising.
Avoid:
> **"Why did my character just perform something I requested several seconds ago?"**
---
# Cancellation and Interruption
Inspect what happens when the player:
- moves during an action;
- changes target;
- selects another interaction;
- takes damage;
- becomes stunned;
- dies;
- loses range;
- loses line of sight;
- closes a menu;
- changes equipment;
- cancels manually.
Determine which actions:
- may cancel;
- may interrupt;
- must complete;
- may queue another action.
Make these rules internally consistent.
Avoid states where:
- animation stops but gameplay continues;
- gameplay stops but animation continues;
- progress disappears without explanation;
- controls remain locked;
- stale callbacks complete later;
- old targets remain active;
- queued input executes after the context has changed.
---
# Combat Feel Pass
If combat exists, inspect the complete attack loop:
> **target → commit → wind-up → impact → result → recovery**
Look for:
- target acquisition delay;
- unclear targeting;
- attack animation and hit mismatch;
- delayed damage feedback;
- damage occurring before apparent impact;
- sound occurring at the wrong time;
- effects occurring at the wrong time;
- awkward recovery;
- target death feeling disconnected;
- target switching delays;
- misses lacking readable feedback.
Combat should communicate cause and effect clearly.
---
# Hit Confirmation
A successful hit may use combinations of:
- animation;
- hit reaction;
- damage number;
- sound;
- VFX;
- health change;
- brief material response;
- camera response where appropriate.
Do not automatically use all of them.
Choose feedback appropriate to the game's style.
The player should understand:
> **I attacked.**
> **The attack connected.**
> **This was the result.**
These moments should feel temporally connected.
---
# Miss, Block, Dodge, and Failure Feedback
Failed outcomes need distinct enough feedback.
Avoid situations where the player cannot tell whether:
- the attack missed;
- the target dodged;
- the target blocked;
- the ability was unavailable;
- the action failed;
- latency delayed the action;
- the game ignored the input.
Use appropriate existing visual, audio, animation, or UI mechanisms.
Do not turn ordinary failures into giant error messages.
---
# Damage and Death Response
Inspect:
- damage timing;
- health changes;
- hit response;
- death timing;
- death animation;
- collision during death;
- targetability during death;
- target clearing;
- loot appearance;
- camera behavior;
- post-death input.
Deaths should not feel like an unrelated state suddenly flipped.
Ensure the preceding interaction resolves cleanly.
---
# Gathering and Repetitive Non-Combat Actions
If gathering, skilling, harvesting, or equivalent systems exist, inspect:
- target acknowledgement;
- approach behavior;
- start feedback;
- action cadence;
- animation loop;
- success feedback;
- progression feedback;
- depletion;
- interruption;
- repetition;
- requirements;
- failure;
- full-inventory or capacity behavior.
These activities may occupy more player time than combat.
They deserve equivalent interaction polish.
Avoid:
> **click → nothing visible → wait → result appears**
when lightweight acknowledgement can communicate state.
---
# Crafting and Production Feel
If crafting or production exists, inspect:
- selecting recipes;
- starting;
- repeated production;
- quantity handling;
- progress;
- completion;
- failure;
- inventory update timing;
- progression feedback;
- cancellation.
Remove artificial friction that does not serve gameplay.
Preserve intentional durations and resource rules.
---
# NPC and Dialogue Interaction Feel
Where applicable, inspect:
- selecting NPCs;
- approaching NPCs;
- facing;
- dialogue opening;
- repeated input;
- target changes;
- interruption;
- dialogue closing;
- returning to movement.
Remove mechanical pauses that communicate nothing.
Do not rewrite dialogue content as part of this pass.
---
# Loot Interaction Feel
Inspect:
- loot visibility;
- selection;
- pickup range;
- approach;
- inventory update;
- repeated pickup;
- pickup failure;
- capacity-full behavior;
- target disappearance;
- feedback.
Loot should feel like a resolved reward interaction rather than an arbitrary state mutation.
---
# Ability and Cooldown Feel
If abilities exist, inspect:
- activation acknowledgement;
- cooldown start;
- availability state;
- failed activation;
- target requirements;
- range failure;
- resource requirements;
- repeated input;
- cancellation;
- completion.
Avoid abilities appearing available when they are not.
Do not redesign balance.
This pass concerns the **feel and communication of existing rules**.
---
# Progression Moment Feedback
For moments such as:
- XP gains;
- skill increases;
- level-ups;
- unlocks;
- quest progress;
- objectives completed;
- rewards earned;
inspect whether feedback is:
- timely;
- understandable;
- satisfying;
- proportional.
Do not redesign progression.
Improve the moment when existing progression occurs.
---
# Animation Response
This is not a dedicated animation-system overhaul.
Modify animation where it directly affects interaction feel.
Inspect:
- animation starting too late;
- animation ending too late;
- animation locking input unnecessarily;
- movement animation lag;
- transition latency;
- snapping;
- repeated animation restarts;
- attack-impact timing;
- repeated-action cadence;
- animation cancellation.
Gameplay state and animation state should feel connected.
Do not rebuild the entire animation architecture unless necessary for a high-value interaction problem.
---
# Audio Response
This is not a dedicated audio-production pass.
Use sound where timing materially affects interaction feel.
Inspect relevant:
- clicks;
- attacks;
- impacts;
- gathering;
- ability activation;
- failures;
- rewards;
- UI actions.
Look especially for:
- late sounds;
- premature sounds;
- duplicated sounds;
- sounds disconnected from the visible event;
- frequent actions lacking acknowledgement where a suitable sound already fits the game.
Timing often matters more than complexity.
---
# VFX Response
This is not the visual-art polish pass.
Use VFX where they improve acknowledgement or cause and effect.
Examples:
- destination marker;
- target highlight;
- hit effect;
- gathering effect;
- ability activation;
- cooldown-ready feedback;
- loot pickup;
- progression feedback.
Keep effects:
- restrained;
- legible;
- synchronized;
- stylistically consistent.
Do not fill ordinary interactions with particles merely to create "juice."
---
# Camera Feel
Inspect camera behavior as it relates to player control and interaction.
Possible issues:
- delayed follow;
- over-responsive follow;
- jitter;
- unpleasant acceleration;
- sudden snapping;
- target changes causing harsh movement;
- camera fighting input;
- movement/camera timing mismatch;
- combat framing problems;
- zoom behavior interfering with control.
Camera motion should support player intent.
It should rarely become something the player is fighting.
---
# UI Interaction Feel
This is not a dedicated UI visual-design pass.
Inspect UI behavior where it directly affects gameplay interaction.
Examples:
- button response;
- press acknowledgement;
- selection changes;
- inventory interaction;
- context menus;
- drag and drop where used;
- action bars;
- target information;
- cooldown feedback;
- gameplay menus.
Do not turn this into a broad UI redesign.
---
# State Transition Pass
Inspect important transitions such as:
- idle → moving;
- moving → attacking;
- attacking → moving;
- gathering → interrupted;
- alive → dead;
- target A → target B;
- combat → non-combat;
- gameplay → dialogue;
- menu → gameplay;
- loading complete → controllable.
Look for:
- unnecessary pauses;
- stale state;
- conflicting animations;
- stale targets;
- lingering input locks;
- duplicated state changes;
- missing feedback.
Transitions are where otherwise-good systems often feel amateur.
---
# Timing Consistency
Compare equivalent actions.
Look for unexplained differences in:
- acknowledgement delay;
- movement transition;
- target selection;
- cooldown display;
- cancellation;
- result timing;
- feedback timing.
Players develop subconscious timing expectations.
Equivalent actions should usually behave similarly unless intentional gameplay differences justify otherwise.
---
# Tick-Based and Server-Authoritative Games
If the game uses:
- simulation ticks;
- authoritative servers;
- network round trips;
- deterministic simulation;
do not improve responsiveness by casually transferring authority to the client.
Instead determine whether safe local presentation can acknowledge intent before authoritative resolution.
Examples:
- immediate destination marker;
- immediate target highlight;
- pending-state animation;
- command acknowledgement;
- local UI feedback.
Do not fake authoritative outcomes.
Separate:
> **presentation acknowledgement**
from:
> **authoritative result.**
---
# Multiplayer Responsiveness
If multiplayer exists, inspect relevant:
- local action acknowledgement;
- remote movement;
- remote attack timing;
- prediction where already used;
- interpolation;
- target state;
- reconciliation;
- rejected-action behavior;
- disconnect behavior during actions.
Do not perform a broad networking rewrite as part of this pass.
For difficult network-authority issues:
1. establish the current authority model;
2. identify presentation versus simulation responsibilities;
3. define behavior that must remain authoritative;
4. make only justified bounded improvements;
5. record broad architectural issues separately.
---
# Failure-State Interaction
Test common failure conditions such as:
- target unreachable;
- target disappeared;
- target died;
- invalid item;
- inventory or capacity full;
- insufficient resources;
- cooldown active;
- out of range;
- line of sight blocked;
- action interrupted;
- path failed;
- server rejected request.
Failures should not feel like ignored input.
Communicate enough for the player to understand what happened.
Avoid noisy repetitive messages for obvious failures.
---
# Rapid Input Test
Stress relevant interactions with:
- rapid clicking;
- alternating targets;
- repeated movement commands;
- repeated action presses;
- rapidly opening and closing UI;
- cancelling and restarting actions;
- input during transitions.
Look for:
- duplicate actions;
- lost state;
- stuck state;
- animation spam;
- stale target references;
- queue explosions;
- crashes;
- incorrect cooldowns;
- delayed stale actions.
Fix demonstrable problems without making normal controls artificially unresponsive through excessive debounce.
---
# Boundary Interaction Test
Test actions:
- exactly at range;
- just outside range;
- beside obstacles;
- while the target moves;
- while the player moves;
- during higher latency where testable;
- while another action completes;
- on the same frame or tick as state changes.
Boundary conditions frequently reveal interaction roughness.
---
# "Does It Feel Like the Game Heard Me?" Test
For every major action, ask:
> **Immediately after I act, can I tell the game heard me?**
If not, determine why.
Potential improvements may include:
- immediate selection;
- cursor response;
- destination indication;
- orientation;
- pending state;
- animation anticipation;
- subtle sound;
- UI response.
This is one of the highest-value tests in the pass.
---
# "Why Did That Happen?" Test
After every meaningful result, ask:
> **Can the player understand why that happened?**
Especially inspect:
- failed attacks;
- cancelled actions;
- movement stopping;
- abilities not activating;
- target changes;
- death;
- action rejection.
Do not over-explain routine gameplay.
Prevent mysterious behavior.
---
# "Would I Want to Do This 10,000 Times?" Test
For repetitive core loops, ask:
> **If the player performs this interaction ten thousand times, what becomes irritating?**
Examples:
- unnecessary extra inputs;
- repeated delays;
- awkward target selection;
- redundant confirmation;
- slow transitions;
- excessive animation lockout;
- repetitive noisy feedback;
- cursor imprecision.
Fix friction that compounds over long sessions.
Do not remove intentional pacing.
---
# Work in Interaction Waves
Do not make random changes across every system.
Work systematically.
## Wave A — Core Input and Movement
Address:
- input acknowledgement;
- movement;
- selection;
- targeting;
- fundamental control transitions.
Validate.
## Wave B — Core Gameplay Interactions
Address the game's highest-frequency loops.
Examples may include:
- combat;
- gathering;
- crafting;
- NPC interaction;
- object interaction;
- ability use;
- inventory interaction;
- equivalent project-specific loops.
Validate.
## Wave C — Feedback Synchronization
Align:
- gameplay state;
- animation;
- VFX;
- sound;
- UI;
- camera.
Fix noticeable cause-and-effect disconnects.
Validate.
## Wave D — Cancellation, Failure, and Boundaries
Inspect:
- interruption;
- invalid actions;
- rapid input;
- edge ranges;
- target disappearance;
- repeated actions;
- transitions.
Validate.
## Wave E — Last 10%
Search for:
- tiny dead pauses;
- inconsistent timing;
- awkward cursor behavior;
- small camera snaps;
- imperfect animation/action timing;
- weak completion feedback;
- minor state-transition roughness;
- small repeated-action annoyances.
These accumulated details often distinguish functional interaction from professional interaction.
---
# Reassess After Every Wave
Ask:
- What still feels slow?
- What still feels disconnected?
- What common action still lacks acknowledgement?
- What requires too many inputs?
- Where does movement feel awkward?
- Which combat action feels least connected?
- Which repeated interaction becomes irritating fastest?
- Which transition still contains dead time?
- Where can the player not tell why something failed?
- Which action has mistimed animation, audio, or VFX?
- Did previous fixes create inconsistency elsewhere?
- Did responsiveness improvements accidentally change intended gameplay?
Update priorities based on evidence.
Do not mechanically follow an outdated original plan.
---
# Productive Session Loop
Do not stop after the first large improvement.
Game-feel work often exposes additional weaknesses as the roughest layer disappears.
Examples:
- movement improvements expose targeting problems;
- targeting improvements expose weak attack feedback;
- attack improvements expose animation timing;
- animation improvements expose sound timing;
- better acknowledgement exposes inconsistent cancellation.
Continue:
> **play/inspect → identify weakest interaction → diagnose → implement → validate → reinspect**
while clear, material, safely actionable improvements remain.
Do not manufacture meaningless "juice" simply to continue making changes.
Stop when remaining issues are primarily:
- subjective preference;
- balance changes;
- new-feature ideas;
- highly specialized low-impact edge cases;
- architecture better suited to another pass;
- disproportionately risky changes.
---
# Regression Review
Interaction polish can easily introduce gameplay regressions.
After shared changes, inspect:
- timing;
- cooldowns;
- resource consumption;
- range;
- movement speed;
- combat outcomes;
- authoritative state;
- animation locks;
- cancellation;
- multiplayer synchronization;
- repeated actions;
- input handling.
Do not accidentally buff or nerf gameplay while polishing feel.
If intended behavior changes, it should be because a confirmed defect was corrected or because the task explicitly authorizes the design change.
---
# Performance Awareness
This is not primarily a performance pass.
However, avoid interaction polish that introduces:
- expensive per-frame searches;
- uncontrolled raycasts;
- unnecessary allocations;
- excessive network requests;
- repeated unnecessary path requests;
- particle spam;
- audio spam;
- unnecessary UI rebuilding;
- duplicate action processing.
If poor responsiveness is caused by a clear bounded performance bottleneck, fix it where practical.
Record broad optimization needs for another pass.
---
# Fresh Final Interaction Review
Near completion, review the game again from the perspective of a player encountering it fresh.
Inspect independently:
## Movement and Selection
- movement requests;
- redirection;
- stopping;
- selection;
- targeting;
- path failures.
## Combat
- targeting;
- attack timing;
- hit feedback;
- cancellation;
- target death;
- repeated combat.
## Non-Combat Interaction
- gathering;
- crafting;
- NPC interaction;
- objects;
- loot;
- repeated interactions.
## Feedback Synchronization
- animation;
- VFX;
- sound;
- UI;
- camera timing.
## Edge Cases
- rapid input;
- cancellation;
- invalid targets;
- interrupted actions;
- state boundaries.
When independent review is supported, use fresh context for important shared systems rather than relying solely on the perspective that implemented them.
---
# "What Still Feels Unfinished?" Review
Perform a final broad interaction pass and ask:
> **What moment-to-moment behavior still makes this feel mechanically unfinished rather than professionally tuned?**
Focus on:
- dead pauses;
- ignored-feeling inputs;
- awkward movement;
- weak targeting;
- mistimed attacks;
- poor hit confirmation;
- abrupt transitions;
- inconsistent cancellation;
- cursor roughness;
- action/animation mismatch;
- camera awkwardness;
- repetitive friction;
- unexplained failures;
- weak reward moments.
Require concrete evidence.
For each meaningful finding establish:
### Interaction
What action is affected?
### Problem
What specifically feels wrong?
### Evidence
What observed behavior supports the finding?
### Impact
How frequently does the player encounter it?
### Recommended Fix
What concrete change is justified?
### Scope
Tiny / Small / Medium / Large.
Implement high-value justified findings.
Reject subjective redesign suggestions.
---
# Anti-"Juice" Review
Before completion, inspect whether the pass itself overdid feedback.
Ask:
- Are there too many particles?
- Are sounds firing too frequently?
- Is camera motion distracting?
- Are actions over-animated?
- Are cursor effects noisy?
- Is every small action demanding attention?
- Has responsiveness become twitchiness?
- Did meaningful anticipation disappear?
- Did actions lose intended weight?
- Has repeated gameplay become exhausting?
Remove or reduce unjustified excess.
Professional game feel requires:
> **restraint, hierarchy, clarity, and timing**
not constant stimulation.
---
# Final Cross-System Interaction Review
Before finishing, inspect whether the work introduced:
- inconsistent interaction timing;
- broken authoritative state;
- missed callers;
- duplicate action paths;
- stale input;
- broken cancellation;
- animation-state errors;
- camera regressions;
- duplicate feedback;
- performance problems;
- multiplayer disagreement;
- unexpected gameplay changes;
- temporary hacks;
- incomplete migrations.
Repair justified issues.
Run final validation.
---
# Completion Standard
The interaction polish pass is complete when, to the degree the existing project allows:
1. major player inputs receive clear acknowledgement;
2. core interactions feel responsive within intended gameplay timing;
3. movement starts, redirects, arrives, and stops cleanly;
4. targeting and selection are predictable;
5. high-frequency interactions contain no unnecessary friction;
6. combat cause and effect is clear where combat exists;
7. repetitive non-combat interactions feel deliberate where they exist;
8. repeated actions remain smooth;
9. interruption and cancellation behavior is consistent;
10. failed actions do not commonly feel like ignored inputs;
11. animation timing supports gameplay state;
12. VFX timing supports gameplay state;
13. sound timing supports gameplay state;
14. camera behavior supports rather than fights player intent;
15. important state transitions feel deliberate;
16. equivalent actions behave consistently where appropriate;
17. rapid input does not reveal obvious state problems;
18. boundary interactions behave sensibly;
19. multiplayer authority remains correct where applicable;
20. gameplay balance and intended pacing remain intact;
21. no known interaction regressions introduced by this pass remain;
22. common gameplay loops are more pleasant to repeat;
23. normal play feels substantially more deliberate and professionally tuned;
24. remaining weaknesses are low-value, subjective, architectural, balance-related, or better suited to another specialized pass.
The objective is not:
> **maximum juice**
The objective is:
> **maximum improvement in responsiveness, clarity of cause and effect, tactile satisfaction, consistency, and moment-to-moment interaction quality while preserving the existing game.**
---
# Final Report
When complete, provide a concise game-feel report.
## 1. Overall Result
Summarize the largest improvements to moment-to-moment play.
## 2. Input and Responsiveness
Describe meaningful acknowledgement and latency improvements.
## 3. Movement and Selection
Summarize meaningful improvements to:
- movement;
- targeting;
- clicking or equivalent input;
- selection;
- redirection.
## 4. Core Gameplay Interactions
Summarize improvements by systems that actually exist.
Examples may include:
- combat;
- gathering;
- crafting;
- abilities;
- NPC interaction;
- loot;
- inventory interaction.
Do not include nonexistent systems.
## 5. Feedback Synchronization
Summarize meaningful coordination improvements involving:
- animation;
- VFX;
- sound;
- UI;
- camera.
## 6. Interruptions and Failure States
Describe important improvements to:
- cancellation;
- invalid actions;
- failure feedback;
- rapid-input behavior;
- transition states.
## 7. Validation
State exactly what was tested.
Include representative:
- interaction loops;
- repeated-action tests;
- rapid-input tests;
- boundary tests;
- multiplayer checks where applicable.
## 8. Deliberately Unchanged
Describe noteworthy imperfections intentionally preserved because:
- they are intended gameplay;
- they are balance decisions;
- evidence was insufficient;
- risk exceeded benefit;
- they belong to another specialized pass.
## 9. Remaining Opportunities
List only genuinely worthwhile future interaction work.
For each include:
- **Opportunity**
- **Player impact**
- **Scope:** Tiny / Small / Medium / Large
- **Relevant system**
- **Recommended priority**
Do not pad the report with microscopic subjective tweaks.
---
# Final Directive
**Think like a game-feel designer playing the game, not a generic software reviewer reading the code.**
The player's moment-to-moment experience is the primary output of this task.
Prioritize:
> **what the player actually feels immediately after taking an action**
over invisible engineering elegance.
Do not redesign the game.
Do not drift into broad accessibility work.
Do not drift into visual art direction.
Do not drift into backend refactoring.
Do not turn "juice" into visual or audio spam.
Do not assume intentionally slower actions are inherently unresponsive.
Repeatedly ask:
> **Did the game clearly hear the player's intent?**
> **Did the resulting action feel connected to that intent?**
> **Was the outcome communicated clearly and satisfyingly?**
> **Would this interaction still feel good after performing it thousands of times?**
Continue:
> **play/inspect → diagnose → implement → validate → compare → reinspect**
while meaningful game-feel improvement remains.
Leave behind the **same game**, but make controlling it and interacting with it feel substantially more responsive, satisfying, coherent, deliberate, and professionally tuned.