debugging-game-feel

Diagnose subjective game-feel bugs by isolating and tuning one variable at a time.

66|4|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/SummerEngine/summer --skill debugging-game-feel-summerengine
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debugging-game-feel
Source: https://github.com/SummerEngine/summer/tree/main/library/skills/debugging-game-feel
Command: npx skills add https://github.com/SummerEngine/summer --skill debugging-game-feel-summerengine

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Gameplay features often work correctly yet feel wrong — floaty jumps, mushy combat, sluggish cameras — and no error or test failure points to the cause. This Skill provides a disciplined diagnostic loop for these tuning bugs, preventing the common trap of tweaking multiple variables at once and losing the thread. ## Core Features & Use Cases - Anchored Diagnosis: Establishes a reference target (a known game or a known-good sibling feature) before touching any value, so tuning has a direction. - One-Variable Isolation: Maps feel complaints to suspect variables per domain — jump gravity, camera lag, hit-stop duration, dash easing — and enforces changing only one at a time. - Frame-Level Measurement: Uses input-driven verification probes to sample per-frame values like velocity and camera offset when subjective feel becomes ambiguous. - Use Case: A player reports the jump feels floaty. You anchor to a reference game's jump arc, suspect gravity, tweak it alone, playtest, compare against the anchor, and commit or revert before moving to the next variable. ## Quick Start Use the debugging-game-feel skill to figure out why my character's jump works but feels floaty and tune it one variable at a time.

Frequently Asked Questions about debugging-game-feel

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix a jump that works but feels floaty?

Floaty jumps are tuning bugs, not logic bugs. Anchor to a reference game's jump arc, then isolate one suspect variable — gravity, jump velocity, terminal velocity, or apex hang time — tweak it alone, playtest, and compare against the anchor before touching anything else.

How do I debug game feel when the code has no bugs?

Treat it as a tuning problem: name a reference for what right feels like, pick the single most likely suspect variable from a domain shortlist, change only that value, play the feature, and decide whether it moved closer to or further from the anchor.

What variables should I check when combat feels mushy?

Mushy combat usually traces to hit-stop duration on attacker and target, screen shake amplitude and duration, knockback velocity and decay, or recovery frames. Pick the most likely one, tune it alone, and playtest before moving to the next.

Can I measure game feel objectively instead of relying on opinion?

Yes, for ambiguous cases. Run an input-driven verification probe that presses an input and samples values like velocity or camera offset per frame, returning an array you can count frames from. The final verdict on feel still stays with the user.

When should I not use game-feel debugging?

Do not use it when the feature has a concrete reproducible logic bug, crashes, or throws errors — those need standard bug investigation first. Also avoid it for features not yet built, and do not add juice or polish before the underlying tuning is fixed.