Game Feel

Game feel is the experienced response between intention and consequence. Treat it as a measured chain, not a checklist of shake, flash, freeze, particles, and sound. Polish must clarify the mechanic without changing trusted simulation state, blocking input, hiding readability, or making the game inaccessible.

When to use this skill

Use it to:

• diagnose a mechanic that works but feels delayed, soft, weightless, slippery, or noisy;
• inspect input-to-visible-response and action-to-consequence timing;
• tune movement, attack, jump, dash, fire, impact, pickup, death, or button feedback;
• coordinate animation, camera, VFX, audio, haptics, UI, and recovery;
• compare a baseline and one controlled feel variant;
• add reduced-motion, flash, haptic, or redundant cue alternatives;
• separate actual input latency from animation, camera, rendering, or network delay.

Do not use it to invent the base mechanic, build a camera system, author a VFX effect, mix sound, or profile a whole frame budget. Route those to the relevant game-design, Three.js, game-vfx, audio, or game-performance-profiler skill.

Instructions

1. Freeze one mechanic and context

Record the exact build, scene, mechanic, target devices, input methods, frame mode, network state, camera, and player context. Define what "better" means in observable terms, such as clearer confirmation, faster perceived response, stronger impact distinction, or easier control recovery.

If the mechanic is not functionally correct, route to debugging or implementation first. Game feel cannot hide broken collision, authority, state transitions, or frame pacing.

2. Capture the baseline response chain

Capture video or telemetry that can connect:

intent -> device event -> input read -> simulation decision -> state change -> rendered motion -> feedback channels -> return to control/rest

Use frame stepping, input event timestamps, engine profiler markers, or a synchronized camera only where available. Report which stages were measured and which are inferred. Do not claim input latency from a visual impression alone.

3. Name the first weak link

Classify the primary problem before adding effects:

• input sampling or device mapping;
• state-machine gating, buffer, cancel, or recovery;
• simulation response or interpolation;
• animation startup, anticipation, contact, follow-through, or return;
• camera framing or secondary motion;
• impact recognition across visual, audio, haptic, or UI channels;
• feedback priority, clutter, habituation, or accessibility;
• rendering, frame pacing, network, or authority delay.

Choose one primary hypothesis. Route a real frame-time or network bottleneck outward instead of masking it with more feedback.

4. Design one controlled variant

Change the earliest causal variable that could explain the problem. Examples include input buffer policy, animation phase, easing, anticipation, contact pose, visual-only recoil, secondary motion, event priority, or one redundant feedback channel.

Keep gameplay truth separate from presentation. Camera shake moves a visual camera layer, not the authoritative body. Hit pause must not duplicate actions, deadlock scaled timers, violate multiplayer authority, or discard buffered input. Every transient effect must return to a known rest state.

Do not stack a fixed number of effects or copy another game's durations, amplitudes, coyote window, input buffer, or shake curve. Proposed values need a mechanics rationale and capture plan for the target build and device.

5. Preserve signal hierarchy

Map each event to importance and necessary information. Stronger events may receive stronger or additional channels, but routine events must not compete with threats, damage, objectives, or player control.

Use redundant channels for critical information so color, sound, haptics, or motion is not the sole carrier. Avoid overlapping feedback that makes contact timing or state unreadable.

6. Build accessibility controls with the effect

Provide a real off or reduction path for camera shake, head bob, motion blur, repeated motion, flashing, and haptics where applicable. Preserve the gameplay signal through another channel. Settings must apply immediately enough to verify and persist according to the product's settings contract.

Do not treat reduced motion as "less feedback." Replace vestibular or flashing intensity with stable spatial, shape, text, audio, or haptic signals appropriate to the player's settings.

7. Compare baseline and variant

Use the same mechanic, route, build conditions, device, and capture method. Repeat enough to observe consistency, not just one attractive take. Check:

• response and consequence are easier to read;
• input remains accepted according to the mechanic's policy;
• collision, authority, scoring, and cooldown state are unchanged;
• effects end and restore camera, scale, time, audio, and haptic state;
• routine repetition does not become noisy or uncomfortable;
• reduced-motion and alternate-channel variants preserve information;
• frame time and memory remain within project-owned budgets.

Return evidence, not only implementation details.

8. Write and validate the contract

From this skill directory, copy references/contract-example.json, replace the example, and run:

python3 scripts/validate-game-feel.py game-feel-contract.json
python3 scripts/validate-game-feel.py --self-test

Return:

### Game feel packet
- Mechanic and context: <build, scene, device, input, network>
- Baseline evidence: <measured response chain>
- Primary weak link: <one stage>
- Controlled change: <one causal variable>
- Signal hierarchy: <event and channels>
- Accessibility alternative: <off/reduced path and replacement signal>
- Verification: <baseline versus variant result>
- Next owner: <implementation, VFX, audio, profiler, network, or UI route>

Examples

Attack lands but feels weak

First verify contact, damage, and animation timing. Change one causal element such as contact pose or visual-only recoil, then compare the same attack. Add channels only when the missing information is identified; do not begin with a full shake/flash/freeze bundle.

Jump feels laggy

Trace device event, input read, state transition, physics update, interpolation, animation, and render. A delayed visible pose and a late input sample require different fixes. Measure before changing coyote time or the jump arc.

Frame rate collapses during combat

Route the bottleneck to game-performance-profiler. Do not label a performance failure as "game feel" and cover it with stronger feedback.

Best practices

1. Measure one mechanic and fix its earliest weak causal link before layering polish.
2. Keep simulation separate from presentation and ship an accessible replacement with each effect.
3. Compare one controlled variant, then route implementation or profiling to the narrowest specialist.

References

• references/response-chain.md: capture, classification, channel, recovery, and comparison model.
• references/contract-example.json: complete validator-accepted contract.
• references/source-notes.md: book, upstream, engine, and accessibility evidence.
• scripts/validate-game-feel.py: read-only Python 3.9+ validator.