antipattern

Use when

You are adding effects and the screen is getting busy.

What it is. Polish that costs clarity. The screen is so loud with effects — shake, bloom, particle storms, flash — that the player can’t read the one thing they need to act on: the hit, the telegraph, the resource, the enemy about to strike.

Why it hurts. Juice exists to confirm the read, not replace it. When spectacle drowns state, the player stops trusting the screen. Deaths feel unfair, wins feel accidental, and mastery stalls — you can’t get better at a game you can’t see. See pattern-readability.

The smell

The most important pixel on screen is not the loudest pixel on screen. Signal is buried under decoration.

How it happens

The tell (audit YOUR OWN design)

Twist seams (X but Y)

The fix

State first, spectacle second. Juice serves the read; it never competes with it.

PrincipleDo
HierarchyRank events by stakes. The rarest, most important event gets the loudest effect; routine events get quiet ones. Emphasis is a budget — see pattern-juice-choreography.
Layer separationKeep the actionable layer (player, threats, telegraphs) visually above and distinct from the decorative layer (dust, bloom, ambient particles). Dim or desaturate what can’t hurt or help.
Contrast, not volumeA hit reads because it’s different from its surroundings, not because it’s bright. If everything flashes, nothing flashes. See pattern-readability.
Reserve the shakeScreen shake is a spice. Reserve it for the top of your event hierarchy; a constant rumble reads as zero information.
Telegraph owns its channelGive wind-ups a dedicated color/shape/sound that no cosmetic effect uses. The player must never confuse “about to happen” with “just happened.” See system-telegraphs.
Peak-load testDesign and tune the effect stack at the busiest moment, not the calmest. If it’s readable at full horde, it’s readable everywhere.

For the accessibility floor — colorblind-safe channels, reduced-motion and screen-shake toggles — see system-accessibility. These aren’t extras; they’re proof your read survives without your prettiest channel.

Seen in…

Verify / guard

This is a design-time checklist you run before handoff, not a metric. Screenshot the busiest moment and ask: player, threat, objective — all three readable? Then hand to the verification half. For the JUICE budget, hierarchy discipline, and the readability gates that catch this after build, see design/JUICE.md (and design/JUDGE.md for the headless look-test). The design job is to make sure there’s a legible read for those gates to protect.

This module rendersthe repo's markdowndirectly — edit it there, it changes here.