Game Feel

Summary

Game feel is the tactile, moment-to-moment sensation of controlling a game: how quickly it responds, how clearly it communicates, and how satisfying its feedback is. Students often encounter it through questions like “why does my game feel floaty?”, “how do I add juice?”, or “why do these controls feel unresponsive?” A game with strong feel makes each input feel intentional and legible; a game with weak feel feels sluggish, dead, or disconnected even when the underlying mechanics are sound.

Swink (Game Feel, 2009) provides the field’s most rigorous formal treatment. Schell’s Lens #58 (Juiciness) describes the same phenomenon from a design-practice angle.

(Swink, Game Feel; Schell, The Art of Game Design, see source-game-feel, source-art-of-game-design)

Swink’s definition

“Real-time control of virtual objects in a simulated space, with interactions emphasised by polish.” — Swink, Ch. 1

The three building blocks

Real-time control — an uninterrupted flow of command from player to game. Not “click to set a destination” (Starcraft), but continuous steering where the player guides every moment of motion (driving a car, piloting Asteroids). Real-time control is the basis of game feel.

Simulated space — physical interactions between the avatar and a game world: collision detection, object response, level geometry. Without simulated space, motion has no frame of reference. Swink’s test: does the player actively perceive the space through their avatar, or is it managed indirectly (as in RTS pathfinding)?

Polish — effects that artificially enhance the impression of physical interaction without changing the underlying simulation: animations, particle effects, camera shake, sound effects, hit stop. Polish sells the reality of the interaction to the player. Remove animations from Street Fighter II and you have weird fighting boxes; the gameplay is unchanged but the experience collapses.

What these produce: When all three are present, the player experiences a “unique physical reality” in the game world. The game world feels like a place, not just a system.

What counts and what doesn’t:

• Sonic the Hedgehog, Super Mario 64, Half-Life: full game feel (all three)
• Starcraft: polish only (indirect control, indirect space perception)
• Civilization 4: polish only (turn-based; no real-time control)
• Bridge Builder: simulated space only (passive perception; no real-time control)

Five experiences of game feel

Swink (Ch. 1) identifies five distinct experiences that game feel produces:

1. Aesthetic sensation of control — the pure, kinetic pleasure of steering something and feeling it respond to input. What players mean when they say a game feels “smooth,” “floaty,” or “tight.” This is the starting experience: a thoughtless joy of control that is intrinsically pleasurable before any goal is imposed.

2. Learning, practising, and mastering a skill — game feel changes as the player’s skill grows. At first: clumsy, disorienting. After mastery: crisp, responsive, effortless. The controls haven’t changed; the player has. Swink’s point: skill is the price of admission for game feel — you cannot fully appreciate a game’s feel until you can play it.

3. Extension of the senses — the screen, speakers, and controller overwrite the player’s senses. Instead of seeing a room and a TV, the player sees through the screen into the game world. The avatar becomes an instrument of both perception and action — a tool, like a hammer that lets you feel the nail through the handle.

4. Extension of identity — Jonathan Blow’s term: “proxied embodiment.” When senses extend into the game world, so does identity. “My guy” becomes “me.” Players say “I hit a pole!” not “My car hit a pole.” This transfer is capricious — it flows in with mastery and out with failure. It mitigates frustration: cursing at the avatar lets the player maintain engagement.

5. Interaction with a unique physical reality — the game world has its own physics, which the player assembles from clues (sound, motion, collision feedback). When all clues harmonise, the player develops a mental model of the virtual space’s physical laws. Inconsistencies (a “realistic” character whose feet clip through stairs) erode this model.

Virtual proprioception

Swink introduces “virtual proprioception” to explain why game feel involves a bodily sensation that goes beyond what visuals and sound alone can account for. Proprioception is the sense of one’s own body position in space.

When controlling a game, the player’s real proprioceptive sense is still active — thumbs on a stick, fingers on keys. Minute real-world movements are amplified into large virtual movements: “a megaphone for your thumbs.” The game generates an amplified impression of proprioception — felt as real even though it’s illusory. This is why we lean in our chairs while playing racing games.

Game feel model of interactivity (Ch. 3)

Swink models game feel as a 7-element cycle. Each element must be present and must complete its step within one perceptual cycle (~50–200ms):

#	Element	Description
1	Human processor	Perception, cognition, motor instructions
2	Muscles	Execute motor instructions; provide tactile/proprioceptive feedback
3	Input device	Translate muscle movements into signals the computer understands
4	Computer	Processes input, updates game state
5	Game world	Computer’s internal model of the game’s reality
6	Output devices	Display updated game state (screen, speakers, rumble)
7	Senses	Player perceives updated state; cycle completes

The designer’s palette is steps 4–6. The player’s biology (1–2) and the input device (3) are mostly fixed. Output devices (6) are platform-determined. The computer (4), game world (5), and output device behaviour (6) are what the designer controls.

Six metrics for game feel (Ch. 5–11)

Swink provides a framework of six measurable elements for analysing and designing game feel:

Metric	Description
Input	The physical construction of the input device; which inputs are used; their sensitivity and degrees of freedom
Response	How the system processes and responds to input in real time; the ADSR envelope of parameter modulation
Context	The effect of simulated space: collision code, level layout, object spacing relative to avatar speed
Polish	Effects that enhance the impression of physical reality without changing simulation: animations, particles, camera shake, sounds
Metaphor	How the game’s visual representation shapes player expectations about behaviour and physics
Rules	How arbitrary relationships between abstracted variables give meaning to objects and define challenges

ADSR envelope (Response metric)

Any response to input can be described as an ADSR envelope — borrowed from audio synthesis:

• Attack: the time from zero to peak response (how quickly the avatar reaches full speed)
• Decay: the drop from peak to sustained level (if any)
• Sustain: the stable response level while input continues
• Release: the time from input release back to zero (how long the avatar continues to move after releasing the stick)

Mario’s horizontal movement: long attack (gradual acceleration), no decay, constant sustain, long release (momentum/deceleration). Feels organic and responsive.

Donkey Kong’s Jumpman: no attack, no sustain variation, no release (instant stop/start). Feels rigid and stilted.

ADSR analysis lets designers reverse-engineer why a movement system feels the way it does, and make targeted adjustments rather than guessing.

Intuitive controls and the challenge/interference distinction

Intuitive controls = near-perfect translation of player intent into game reality. The player can do what they intend.

Swink draws a critical distinction:

• Challenge: makes the game more difficult in the dimension of skill — the result is predictable, just hard to achieve. Challenge is good.
• Interference: ambiguity between intent and outcome — the game seems to give different results for the same input. Interference is bad.

Three causes of interference (predictability failures):

1. Control ambiguity — two inputs give different results depending on which came first (milliseconds apart), but the player cannot perceive the difference (e.g. the Mario 64 ground pound / long jump ambiguity)
2. State overwhelm — the same input does different things in different states; the state change is not perceptible to the player
3. Staging failure — the result of an input happens too fast, gets lost in other motion, or is otherwise imperceptible — the player cannot learn from it

Seven principles of game feel (Ch. 17)

Principle	Description
Predictable results	When players take action, they get the response they expect. No interference between intent and outcome.
Instantaneous response	The player perceives the response as immediate. Response delay >100ms breaks the impression of responsiveness. The attack phase can be long, but some obvious change must occur within ~70–100ms of input.
Easy but deep	Low skill floor, high skill ceiling. Minutes to learn, a lifetime to master. Exploit natural mappings for ease; add sensitivity and challenge for depth.
Novelty	Despite predictability, there is enough subtle variation in response to keep controls feeling fresh. Physics simulation and procedural variation help; linear animation repeating identically is an enemy of novelty.
Appealing response	The sensation of control is aesthetically compelling even removed from its context. Control should feel good in a blank space with nothing to accomplish.
Organic motion	Good-feeling games produce flowing, curved arcs of motion. Simulating velocity (forces + integration) produces organic curves; directly setting position every frame (Donkey Kong) produces rigid, linear motion.
Harmony	Each element of a game’s feel supports a single, cohesive perception of a unique physical reality. Consistency of abstraction: a cartoony car should have cartoony physics. Photorealism sets near-impossible expectations for active perception.

Underlying goal — Ownership: when all principles are achieved and a player fully masters the mechanic, the sensation of control becomes a tool for self-expression. “My guy” is no longer a character; the player’s skill finds expression through the game. This creates replayability, pride, and the desire to share achievements.

Common game feel techniques

Technique	What it does
Screen shake	Camera displacement on impact — communicates force and weight
Hit stop / freeze frames	Brief pause on impact — adds weight. A few frames suits light hits; fighting games scale it with damage and cap it (about 6–12 frames for a mid-strength hit in Smash, capped at 20–30). See vfx-shape-and-timing for sourced ranges, hit flash timing and a robust Unity implementation
Squash and stretch	Exaggerated deformation on collision/landing — sells mass and elasticity
Particle effects	Visual feedback burst on action — communicates result clearly
Sound design	Immediately reinforces action (attack, collect, land); pitched sounds communicate mass
Input buffering	Accept inputs slightly before they can execute — reduces frustration at missed inputs
Coyote time	Allow jump input briefly (~100ms) after walking off a ledge — forgiveness mechanic
Haptic feedback	Controller rumble proportional to action (console/DualSense)

Is impact in the damage numbers or the feedback?

Both, but they do different jobs. Damage values and timing windows are balance: they shape the dynamics of a fight over many exchanges (see mda-framework). The felt impact of a single hit comes from response timing and representation: the hit stop, the flash, the shake and the sound that arrive on the frame of contact. The course’s system/representation split makes the same point: when a mechanic feels wrong, check the representation layer before the numbers (see Representational layers and micro-mechanics below). A practical order, offered here as a working method rather than a sourced rule, is to tune the representation first with the damage fixed, then let damage decide only how much feedback a hit earns. Sakurai does exactly this in Super Smash Bros., where “the more damage an attack inflicts, the longer the hitstop period” (Sakurai, Famitsu column, “Thoughts on Hitstop”; sourced ranges and Unity code in the hit flash and hit stop section of vfx-shape-and-timing).

Is weight in the physics or in the feedback?

The same split applies to movement, and here the order is reversed: tune the physics response first, then let polish sell it. In Swink’s terms, weight is mainly a property of the Response metric (how input is turned into motion over time: acceleration, top speed, gravity, damping, the ADSR envelope above) and of Context (collision and spacing). Polish, in Swink’s account, is the effects that enhance the impression of physical interaction without changing the underlying simulation (Swink, Game Feel, as summarised in “Swink’s definition” above; see source-game-feel). It can make a good response read more clearly; it cannot change what the avatar actually does. A character that accelerates instantly, floats at the top of its jump and stops dead will still feel floaty with a landing shake and a dust cloud added, because the player’s hands feel the motion, not the particles.

A practical order (this wiki’s working method, built on Swink’s blank-room principle in “Testing feel” below):

1. Blank room, no effects. Tune acceleration, deceleration, gravity (including a stronger fall gravity), jump height and damping until moving and jumping feel right with nothing else on screen. In Unity these are values such as the force and linearDamping in the ADSR snippet below, or the curves in a velocity-based controller (see unity-rigidbody2d).
2. Add polish one layer at a time (sound, then squash and stretch, then particles, shake, hit stop), checking each with the A/B switches below.
3. If it still feels wrong, go back to step 1, not to more particles.

So the answer to “tune physics or is weight just feedback?” is: both, in that order. Weight is built in the response; feedback amplifies it.

In practice

In Unity (C#):

Simple screen shake via Cinemachine Impulse (see cinemachine-overview):

public CinemachineImpulseSource impulseSource;
 
public void ShakeCamera(float force = 1f)
{
    impulseSource.GenerateImpulse(force);
}

Hit stop:

IEnumerator HitStop(float duration = 0.05f)
{
    Time.timeScale = 0f;
    yield return new WaitForSecondsRealtime(duration);
    Time.timeScale = 1f;
}

This minimal version always restores timeScale to 1, so it will cancel a pause menu, and two overlapping calls can fight each other. A guarded version that remembers the previous scale and restores it in OnDisable, plus a hit-flash script, is on vfx-shape-and-timing.

Movement with ADSR-shaped acceleration (organic feel):

// rb is a cached Rigidbody2D field (rb = GetComponent<Rigidbody2D>() in Awake); call this in FixedUpdate.
// Using velocity and drag instead of direct position setting
// produces natural attack/release curves
rb.AddForce(inputDirection * moveForce);
rb.linearDamping = dragValue; // controls the "release"

Architecture for feel (Unity)

MDA says what the player should feel (the aesthetic, here usually Sensation, with Challenge once skill matters), but not how to structure the code that produces it. A structure that keeps feel tunable, this wiki’s recommendation rather than a rule from one source, has four layers:

Layer	What it does	Unity building blocks	Feel metric it serves
1. Input and control	Reads input every frame, buffers presses (accept a jump pressed a few frames before landing) and allows coyote time (jump just after leaving a ledge)	Read in Update, apply in FixedUpdate with a one-shot flag (see unity-rigidbody2d); input buffer and coyote timers as fields on the controller	Input, Response (latency)
2. Player state machine	Each mode (idle, run, jump, fall, dash, attack) owns its own movement rules and transitions, so tuning the dash cannot break the jump	state-pattern: IState classes with Enter / Execute / Exit; Animator transitions with Has Exit Time off so animation follows the state at once (see unity-animator-scripting)	Response (ADSR per state), Rules
3. Gameplay events	States and combat code announce what happened (Jumped, Landed, HitLanded) with the data feedback needs, and never call effects directly	C# events, or scriptableobject-event-channels when listeners live in other scenes; this is the observer-pattern	(separates logic from presentation)
4. Feedback layer	One component maps each event to hit stop, camera shake, particles and sound	A FeedbackPlayer component, Cinemachine Impulse for shake (see cinemachine-overview), guarded hit stop (see vfx-shape-and-timing)	Polish
Tuning	All timings and strengths in assets, with A/B switches	The FeelSettings asset in “Testing feel” below, or one ScriptableObject preset per kind of moment (see unity-scriptableobjects)	All of them

Mapping the aesthetic onto the layers makes design conversations concrete. If playtesters say “it doesn’t feel powerful”, the MDA question is which layer fails: a slow or mushy response is layers 1–2, a hit that is not announced or not distinguished from a light one is layer 3, and a hit that is announced but undersold is layer 4. Keeping layer 4 separate also makes the all-off juice baseline a single switch.

The state-pattern page shows layers 2–4 working together in “Feel across states”, with compilable code in feedback-layer (PlayerEvents, FeedbackPreset, FeedbackPlayer).

Game feel prototype foundations (Swink, Ch. 1): Three things must exist before game feel is reliably testable:

1. Mapping — input to motion relationship defined
2. Basic level layout — geometry for the avatar to interact with
3. Camera behaviour — how the player’s “eyes” move

Without all three, feel cannot be measured or iterated on.

Practical checklist:

• Does every player action produce immediate audio feedback?
• Does every significant impact produce a visual response (particles, flash, shake)?
• Does player movement have appropriate acceleration/deceleration curves (not linear snapping)?
• Is the response delay below 100ms to first visible change?
• Does the game feel satisfying with the sound off? With visuals stripped to shapes?
• Do all visual, audio, and simulation elements agree about the same physical reality (harmony)?
• Can the player reliably predict the result of any input (predictability)?

Testing feel

Feel is easy to argue about and hard to test, because “it feels good” mixes several things: how quickly the game responds, how the response is shaped, how much feedback decorates it, and whether the underlying numbers are fair. A systematic feel test pulls these apart. In MDA terms, feel is experienced at the aesthetics layer (mostly Sensation, with Challenge once skill matters), but it is produced by mechanics (response curves, timings, input handling) plus the polish that represents them. Balance, by contrast, is a property of the dynamics that emerge when the rule numbers interact over a whole core loop. The two need different tests, and it helps to change only one of them between test sessions.

1. A/B test juice with switches

Jonasson and Purho’s Juice It or Lose It demo is the model. Their Breakout clone never changes its rules; every effect (tweening, stretch, sound, particles, screen shake, the paddle’s face) is a separate switch that starts off, effects are enabled one category at a time, and the talk ends by switching everything off to show the plain game and then everything on (Jonasson & Purho, Juice It or Lose It, see source-juice-it-or-lose-it). Their published code also exposes each effect’s strength as a slider, so the same build can be tuned live.

To use this as a test rather than a demo:

• Build an all-off baseline and keep it playable for the whole project.
• Add or remove one layer at a time (for example hit stop only), so that any change in players’ responses can be attributed to that layer.
• Show testers both versions in a counterbalanced order (half see A first, half see B first) without telling them what changed, then ask which felt better and why.
• Include the strip-down checks from Swink’s checklist above: play with sound off and with visuals reduced to shapes. If the action only feels good with every effect on, the problem may be in the response itself rather than the polish.

Treat preferences as evidence about that build and audience, not as proof that more juice is always better: the talk’s own claim that juice improves a game “100% of the time” was made half in jest, and later talks argued that polish can cost immersion (see source-juice-it-or-lose-it).

2. Measure input-to-response latency

Swink’s threshold is the yardstick: “What feels bad is when there is a delay longer than about 100 ms between when the player tries to do something and when he or she perceives the result of that action” (Swink, Game Feel, Ch. 17, see source-game-feel). What matters is the first visible change, not when the avatar reaches full speed; a long attack phase is fine if something obvious happens straight away.

A practical way to measure it (a common hobbyist and QA technique, not a method from Swink):

1. Film the controller or keyboard and the screen together with a high-frame-rate camera. A phone’s 240 fps slow-motion mode gives one camera frame every ≈4.2 ms.
2. Count camera frames from the moment the button visibly bottoms out to the first change on screen, and convert: latency (ms) = frames × 1000 ÷ camera fps.
3. Repeat 10–20 presses and use the median, because each press lands at a random point in the game’s frame cycle.

This measures the whole chain: input device, engine, rendering and display. To find delays that are your design’s fault, also count game frames inside Unity: log Time.frameCount when the input is read and again on the frame the response first appears. At 60 fps, every frame of delay costs about 16.7 ms, so six frames already reaches 100 ms. Common culprits include Animator transitions with Has Exit Time enabled or long transition durations (see unity-animator-scripting), wind-up frames before any movement starts, and input handled only in FixedUpdate, which runs on physics steps (every 20 ms by default) rather than every rendered frame (see unity-input-system, monobehaviour-lifecycle). The unity-profiler shows whether long frames are adding to the delay.

3. Ask feel questions and balance questions separately

Use the observation and post-test survey methods on playtesting, with the questions deliberately split:

Testing feel (representation and response)	Testing balance (rules and numbers)
“The character went where I meant it to go.” (predictability)	“The fight felt fair."
"Controls responded immediately."	"I understood why I lost."
"Hits felt powerful.” / pick a point between floaty and tight, light and heavy	”Some weapons or strategies were clearly better than others.”
Observe: overshooting jumps, repeated presses on one action, flinching or leaning with the avatar	Measure: win rates, time-to-kill, damage taken, completion rates, choice frequencies

Two further techniques help keep the layers apart:

• The blank-room test. Swink’s appealing response principle holds that the sensation of control should be compelling even removed from its context, in an empty space with nothing to accomplish (Swink, Game Feel, Ch. 17, as summarised in the principles table above; see source-game-feel). A room with no enemies, scoring or rules removes balance from the question, so whatever players report there is about feel.
• MDA diagnosis. When a test goes badly, use MDA’s diagnostic questions to decide which layer to change (see mda-framework). If the dynamics are as intended but the sensation is wrong, adjust the response or representation layer (see game-atoms). If the action feels good but outcomes are unfair, adjust the numbers. Changing both at once makes the next test uninterpretable.

Arguably, Likert items like those above are more useful when tracked across builds than read in isolation, which is why they belong in a repeatable test script.

4. Expose tuning variables in the Inspector

Feel is tuned by iteration, so the numbers should be editable while the game runs. Mark tuning fields with [SerializeField] and [Range] (see serializefield, inspector), and collect the A/B switches and timings in a ScriptableObject asset so designers can keep several presets (see unity-scriptableobjects):

[CreateAssetMenu(menuName = "Feel/Feel Settings")]
public class FeelSettings : ScriptableObject
{
    [Header("A/B switches")]
    public bool screenShake = true;
    public bool hitStop = true;
    public bool hitFlash = true;
    public bool impactParticles = true;
    public bool impactSound = true;
 
    [Header("Tuning")]
    [Range(0f, 0.3f)] public float hitStopSeconds = 0.08f;
    [Range(0f, 3f)] public float shakeForce = 1f;
    [Range(0f, 0.2f)] public float flashSeconds = 0.05f;
}

Gameplay code then checks the switch before firing each effect, for example if (feel.hitStop) HitStop.Instance.Stop(feel.hitStopSeconds);. Values typed into a component during Play mode are lost when Play mode ends, whereas Unity’s Manual notes that data can be saved to ScriptableObjects in both Edit mode and Play mode (Unity Technologies, Unity Manual: ScriptableObject), so tuning done in a ScriptableObject during a play session is kept. Record which preset each playtester used in the test notes.

Schell’s contribution

Schell’s Lens #58 (Juiciness) describes the same phenomenon from the designer’s perspective:

“Is every action rewarded with feedback? Does the player feel victorious when they succeed? Is the game satisfying when the player interacts with it, apart from its strategic elements?” — Schell, Lens #58 (paraphrase, source-art-of-game-design)

Juiciness is Schell’s term for the density and expressiveness of feedback — a juicy game makes doing things feel inherently satisfying. Swink’s formal framework and Schell’s design-practice lens are complementary: Swink explains what produces good feel and how to measure it; Schell reminds designers to prioritise it at every level.

The term “juicy” was popularised in game design culture by Martin Jonasson and Petri Purho’s 2012 talk “Juice It or Lose It” (Nordic Game Indie Night, then GDC Europe 2012), a live demonstration that layered feedback transforms a flat Breakout clone into a satisfying game without changing its rules. The speakers themselves credit the word to the Gamasutra article “How to Prototype a Game in Under 7 Days” and define juice as “maximum output for minimum input” (Jonasson & Purho, Juice It or Lose It, see source-juice-it-or-lose-it).

Representational layers and micro-mechanics (the course)

The course introduces a complementary vocabulary that extends Swink’s framework:

Macro-mechanics vs micro-mechanics: Macro-mechanics define the system (combat, traversal, crafting). Micro-mechanics define the feel — the split-second exchanges between input and feedback that make play tactile.

System layer vs representation layer: Every mechanic has two realities. The system layer is the coded logic (“+3 m/s vertical velocity for 0.4 s, gravity = −9.8 m/s²”). The representation layer is the player’s perception (character crouches, stretches, camera tilts, vibration, jump sound). The same system layer can produce completely different feel through different representation.

Celeste vs Hollow Knight use similar jump physics but produce radically different emotional tones: Celeste’s fast animation and bright palette communicate urgency and agility; Hollow Knight’s slower wind-up and darker palette communicate weight and melancholy.

Design implication: When a mechanic feels wrong, check the representation layer (audio, animation timing, camera response) before adjusting system values. Feel problems are usually in the representation, not the code.

For the full treatment of atoms, representational layers, and emergence, see game-atoms. (course lecture series, see source-player-psychology-lectures)

Open questions

• Where is the line between “juicy feedback” and “visual noise”? Excessive screen shake, particle density, and sound effects can overwhelm players and reduce readability.
• Are there genres where restraint in game feel is correct? (Horror games where stillness is intentional; puzzle games where clean UI outweighs expressive feedback.)
• Swink’s definition excludes turn-based games and RTS games from “true game feel.” Is this the right line? Starcraft has exceptional polish — does Swink’s taxonomy undervalue that?
• The ADSR framework describes single-parameter modulation. How does it extend to complex, multi-parameter systems (e.g. a character with independently simulated limbs)?
• Haptic feedback is underexplored in PC games. As controllers become more common on PC (Steam Deck, DualSense), how should game feel design account for haptic channels?

Related

• source-player-psychology-lectures

• holographic-design — Game feel is the “skin” layer — what the player directly experiences

• flow — Game feel supports flow through responsive feedback; Swink explicitly connects the two

• player-agency — Swink’s proxied embodiment and extension of identity deepen Poole’s control-centric argument

• player-guidance — Audio and visual game feel techniques double as guidance signals

• layered-tetrad — Polish is inscribed; the experience of feel is dynamic

• design-lenses — Lens #58 (Juiciness), Lens #57 (Feedback), Lens #15 (The Toy)

• foundational-vocabulary — Feedback, juiciness, interactivity

• prototyping — Swink’s three-foundation prototype (mapping + layout + camera) is a game-feel-specific prototyping method

• interest-curves — Micro-level feel sustains engagement between larger interest curve beats

• game-atoms — Micro-mechanics and representational layers as components of feel

• cinemachine-overview — Unity’s camera package for follow, damping, blending, and impulse-based feedback

• source-art-of-game-design

• source-game-feel

• source-player-psychology-lectures

• steve-swink — the author whose framework grounds this page

• unity-audiosource — implementing audio feedback in Unity

• unity-particle-system-scripting — implementing visual feedback in Unity

• unity-animator-scripting — hit reactions, state-based animation driven by code

• unity-transform — transform.Translate and Time.deltaTime for responsive movement

• state-pattern — player state machine and the “Feel across states” feedback layer

• scriptableobject-event-channels — gameplay events between systems and scenes for the feedback layer

• mda-framework — feel as an aesthetics-layer experience produced by mechanics; MDA diagnosis for feel problems

• playtesting — observation, test scripts and Likert surveys used in feel testing

• vfx-shape-and-timing — hit flash and hit stop timing, with Unity implementations

• source-juice-it-or-lose-it — Jonasson and Purho’s juice talk and its toggle-based demo

• unity-scriptableobjects — storing feel presets and A/B switches as assets

• unity-profiler — checking whether long frames add to input latency

• unity-rigidbody2d — One-shot jump input and interpolation for responsive physics movement

• unity-character-controller — CharacterController movement tuning (coyote time, grounded checks)