The Juice Audit: A Systematic Process for Evaluating Game Feel
A step-by-step process for auditing an existing game's feedback completeness. The event inventory method, coverage matrix, intensity calibration, and how to run a feedback session that produces actionable prioritised improvements.
28 April 2026 · 5 min read
Most developers know their game needs more juice. The harder problem is knowing which juice, applied where, in what order. Without a systematic evaluation process, polishing a game becomes a cycle of adding random effects and hoping something sticks. The Juice Audit breaks that cycle.
The audit is a structured self-evaluation: a set of questions applied to each major gameplay moment that forces you to articulate what the moment should feel like, what feedback it currently has, and what the gap is. The goal is not to check every box. It is to make intentional decisions about what your game needs given its genre and emotional register.
How to Run the Audit
Print one copy of the worksheet per major gameplay event. Not per game -- per event. A hit on an enemy is one event. A player death is another. A level completion is a third. Each event has its own feedback requirements, its own target emotion, and its own gaps.
For each event, work through five dimensions: responsiveness and controls, visual feedback, audio feedback, kinesthetic and temporal feel, and emotion and design intent. The first four are checklists. The fifth is a design exercise that forces you to connect the technical feedback to the emotional experience you are trying to create.
Dimension 1: Responsiveness and Controls
Five checkpoints: action visible within 100ms of input (target under 50ms); no eaten inputs during animations; coyote time if it is a platformer; critical actions interrupt current animations immediately; and the toy test -- the core movement or interaction is enjoyable with zero objectives.
The toy test is the most important item on this entire worksheet. If the core action is not fun to do for its own sake, no amount of VFX will save it. Run the toy test by loading the game, removing any win/loss conditions in your head, and spending 5 minutes doing only the core action. Does it have intrinsic appeal? If not, the problem is design, not polish.
Dimension 2: Visual Feedback
Eleven checkpoints: tiered screen shake (light, medium, heavy profiles defined and consistently applied); hit flash on damage (1-3 frames, colour-coded); impact particles (burst on contact, pooled, direction-aware); squash and stretch on key actions; damage numbers (colour-coded, instant-spawn, critical scaling); hit stop on significant impacts; easing everywhere (no linear movement or UI transitions); permanence (player actions leave marks in the world); health bar with damage trail and low-health pulse; post-processing events reactive to gameplay; and colour language (consistent damage red, heal green, reward gold).
The most commonly missing item is colour language. Most developers add individual effects without thinking about the system. If a hit flash is white, the damage numbers are orange, and the health bar turns red, you have three different damage signals that do not reinforce each other. Pick one colour per meaning and apply it everywhere.
Dimension 3: Audio Feedback
Eight checkpoints: impact SFX layered (transient + body + sub-rumble, variant pool of 4-6); audio variation (pitch randomisation ±5-10% on repeated SFX, no identical repeats); spatial audio for all in-world events; reward/achievement tone (distinct, musical, joyful, not reused from other feedback types); failure/damage tone (distinct from success, not too harsh to avoid shame spiral); adaptive music (reacts to gameplay intensity, danger, victory); UI audio (hover, press, confirm, error all have distinct sounds); and a dedicated kill/completion sound not reused from the hit sound.
Audio variation is the quickest win on this list. A single SFX repeated without variation becomes an irritant within minutes. A pool of 4-6 variants with ±5-10% pitch randomisation sounds like a rich, alive game even if nothing else has changed. The cost is minimal; the impact is disproportionate.
Dimension 4: Kinesthetic and Temporal Feel
Six checkpoints: controller rumble with tiered intensity (left motor for low-frequency, right motor for high-frequency); ADSR sync (visual, audio, and haptic feedback share the same envelope); the Rule of Three (every major action has visual + audio + kinesthetic response); physics weight (appropriate gravity, friction, acceleration); hit stop implemented on major impacts (3-12 frame freeze or slowdown); and time manipulation used on key dramatic moments.
The ADSR sync checkpoint catches the most common polishing mistake: adding a visual effect, an audio effect, and a rumble event independently without checking whether they peak at the same moment. If the screen shake peaks on frame 3, the impact sound peaks on frame 1, and the rumble peaks on frame 5, the combined effect feels incoherent -- like three separate feedback signals rather than one unified event. Sync them to the same attack peak.
Dimension 5: Emotion and Design Intent
This dimension does not have checkboxes. It has questions. For each core gameplay moment: what is this moment? What is the target emotion in one word? What visual feedback is present -- describe the particle type, duration, colour? What audio feedback -- describe the tone, layering, variation? What kinesthetic feedback -- describe the rumble profile and duration? Does the juice match the genre: is it appropriately scaled, not too intense, not too quiet? What did playtesters actually say after playing -- does their description match the target emotion? And finally: what is one specific improvement you would make to this moment?
The playtester description question is the most powerful. Share the audit with playtesters and ask them to describe how each event feels after playing. Compare their words to your target emotion. If you want the moment to feel powerful and they describe it as fine, you have a gap to close. If they use the same word you wrote down, you are done. The audit has served its purpose.
Using the Audit in Practice
Run the audit at three points in development: once during early prototype (to set intent), once at first playable (to find gaps before too much content is built), and once at pre-release (as a final quality gate). Use it as a shared document between designers and developers -- the emotion intent column is designer territory, the implementation columns are developer territory, and the gap is the brief for the next sprint.
The audit is not a pass/fail test. A game that intentionally scores low on screen shake and controller rumble because it is a minimalist puzzle game is a good result -- it means the designer made a deliberate choice. A game that scores low because the developer never thought about it is a problem. The audit forces the distinction.
Part of a series
Systems & Process