← All books
A moving crimson player shape and a burst of impact lines on the cover of Game Feel

Volume 03 / Design & Feedback

Game Feel

Making Simple Mechanics Feel Incredible

Make movement, combat, and interaction feel intentional. Tune the relationship between input, motion, camera, animation, sound, and impact.

Length
15 pages
Reading time
14 minutes
Format
PDF · 109 KB
Price
Free
Download PDF ↓Read a preview →

First edition · October 2026 · Published by Vertex Arc

Inside the guide

Responsive inputMovement and cameraImpact and hit-stopAudio, particles and UI

Contents

  1. 01Preserve the player's inputPage 5 ↗
  2. 02Shape acceleration, stopping, and air controlPage 6 ↗
  3. 03Let the camera explain the actionPage 7 ↗
  4. 04Design anticipation, contact, and recoveryPage 8 ↗
  5. 05Build impact without losing informationPage 9 ↗
  6. 06Make sound and particles describe the eventPage 10 ↗
  7. 07Connect UI feedback to the worldPage 11 ↗
  8. 08Combine the layers, then remove the excessPage 12 ↗

Also includes an introduction, practical exercises, a final checklist, and a conclusion.

Introduction

Game feel is the relationship between an intention and the response the player perceives. It includes input, simulation, collision, animation, camera behavior, sound, effects, and interface feedback. A change in any one layer can alter the whole action. That is why adding more particles rarely repairs a controller that drops inputs or a camera that hides the landing surface.

This handbook uses an original hypothetical Unity prototype called Switchyard. A small maintenance robot moves between platforms, strikes jammed switches, and redirects moving cargo. There is no finished game or performance claim behind the example. It is a compact test space for movement, impacts, and feedback. The same principles can be adapted to a platformer, action game, puzzle game, or slower exploration experience.

Begin with a repeatable scene and a named tuning profile. Change one meaningful relationship at a time and compare against the previous build. Ask testers what they expected, what they noticed, and when they felt control return. Their answers will help distinguish a timing problem from a presentation problem.

The aim is not maximum intensity. It is a coherent response that supports the game's character and the player's decisions. A gentle, precise interaction can feel excellent. A loud, shaking, brightly flashing interaction can still feel vague. Use every layer to communicate something specific.

Read chapter 01

01 / Preserve the player's input

The idea

An action begins with a request. Capture that request reliably, then decide whether the current game state permits it. Keep those two steps separate. If an action is intentionally unavailable, provide suitable feedback or a readable state. If the request vanishes between input collection and simulation, the result is an implementation failure rather than deliberate difficulty.

Continuous input and momentary input need different treatment. A movement direction describes an ongoing intention. A jump press describes an event that may need to survive until the movement system consumes it. A short input buffer can preserve a press made just before landing, but it must expire and be consumed once. Otherwise an old request can fire unexpectedly.

Unity example

Switchyard records the time of a jump request separately from its grounded state. When a valid landing occurs, the controller checks whether the request is still recent enough to use. The window is exposed as a tuning value. The developer tests it alongside the actual animation and camera rather than copying a supposedly perfect duration from another project.

Key takeaway

Reliable capture comes before generous timing. Make the system understand the request before deciding how forgiving it should be.

Try this

Add a temporary display showing input requests, the current movement state, and the action that consumed each request. Test presses just before landing, during pause, after focus returns, and while a controller is reconnecting. Remove stale requests at deliberate boundaries. Ask a player to attempt rapid sequences and compare their intention with the log.

Developer note

Do not let several scripts independently interpret the same button unless their responsibilities are explicit. A menu and a gameplay action responding together can make an otherwise correct input system feel unreliable.

Keep reading — download the book ↓
All five books →