GDnD Wiki

GDnD Wiki

This site is for Ulster University students and staff. Enter the class access password to continue.

Game Feel

13 min read

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):

#ElementDescription
1Human processorPerception, cognition, motor instructions
2MusclesExecute motor instructions; provide tactile/proprioceptive feedback
3Input deviceTranslate muscle movements into signals the computer understands
4ComputerProcesses input, updates game state
5Game worldComputer’s internal model of the game’s reality
6Output devicesDisplay updated game state (screen, speakers, rumble)
7SensesPlayer 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:

MetricDescription
InputThe physical construction of the input device; which inputs are used; their sensitivity and degrees of freedom
ResponseHow the system processes and responds to input in real time; the ADSR envelope of parameter modulation
ContextThe effect of simulated space: collision code, level layout, object spacing relative to avatar speed
PolishEffects that enhance the impression of physical reality without changing simulation: animations, particles, camera shake, sounds
MetaphorHow the game’s visual representation shapes player expectations about behaviour and physics
RulesHow 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)

PrincipleDescription
Predictable resultsWhen players take action, they get the response they expect. No interference between intent and outcome.
Instantaneous responseThe 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 deepLow skill floor, high skill ceiling. Minutes to learn, a lifetime to master. Exploit natural mappings for ease; add sensitivity and challenge for depth.
NoveltyDespite 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 responseThe sensation of control is aesthetically compelling even removed from its context. Control should feel good in a blank space with nothing to accomplish.
Organic motionGood-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.
HarmonyEach 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

TechniqueWhat it does
Screen shakeCamera displacement on impact — communicates force and weight
Hit stop / freeze framesBrief pause on impact (e.g. 3–8 frames) — adds weight; inspired by traditional animation
Squash and stretchExaggerated deformation on collision/landing — sells mass and elasticity
Particle effectsVisual feedback burst on action — communicates result clearly
Sound designImmediately reinforces action (attack, collect, land); pitched sounds communicate mass
Input bufferingAccept inputs slightly before they can execute — reduces frustration at missed inputs
Coyote timeAllow jump input briefly (~100ms) after walking off a ledge — forgiveness mechanic
Haptic feedbackController rumble proportional to action (console/DualSense)

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;
}

Movement with ADSR-shaped acceleration (organic feel):

// Using velocity and drag instead of direct position setting
// produces natural attack/release curves
rigidbody.AddForce(inputDirection * moveForce);
rigidbody.linearDamping = dragValue; // controls the "release"

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)?

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” (in game design culture) originates in Martin Jonasson and Petri Purho’s GDC 2012 talk “Juice It or Lose It” — a practical demonstration that layered feedback transforms a flat prototype into a satisfying game. (Source not yet ingested.)

Representational layers and micro-mechanics (CRE342)

CRE342 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. (CRE342 Lectures, see source-cre342-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?

Graph View

Backlinks