Game Feel

What this is

Game feel is not polish sprayed on at the end. On a small machine, it is a set of plain rules that keep the player oriented: am I safe, did that count, can I press a button yet, what changed, why did I die? The answer is usually not a grand system. It is a byte, a timer, a branch, and a visible sign.

This module teaches the transferable shape of those rules before any one machine makes them local. A Spectrum, C64, NES and Amiga all draw differently, read input differently and budget their frames differently; they still need the same courtesies. A player who has just respawned needs a visible grace window. A game-over screen needs time to land. A prompt needs to breathe on a clock. A rule the player cannot see does not feel like a rule at all.

The point is not to make games soft. It is to make them legible. Fairness is a system the player can read.

Who it’s for

Anyone building a complete game, especially after the first moving version works. Once there is a player, a hazard, a title screen or an ending screen, the game needs to tell the player what state it is in. These ideas fit beside the machine tracks: Craft teaches the rule, then each track shows where that rule lives in memory, in the frame loop, in the interrupt handler, or in the drawing code.

What it is not

This is not an art-direction course and not a general UX essay. It does not decide what your game should feel like. It teaches the small mechanical tools that let a constrained game communicate honestly: timers, visible states, input locks, frame counters and consistent gates around damage, prompts and endings.

The final implementation belongs to the machine. On the NES, a blink might be a nametable write during vblank. On the Amiga, it might be a rectangle clear in a framebuffer. On the C64, a single timer might drive both a border flash and invulnerability. Craft teaches why the rule exists and what shape it has; the track teaches the code that survives the hardware.

The shape

• Rules the player can see — a game state is not finished until the screen, sound or motion tells the player what changed. Invisible protection, invisible locks and invisible difficulty changes feel like bugs.
• Blink on a clock — use a free-running frame counter to alternate between two renders: prompt and blank, visible and hidden, calm and urgent. No extra state, no reset, no drift.
• The grace window — after a respawn, harm is ignored briefly and visibly. The player can move out of danger, the game avoids death cascades, and the blink tells the truth about the temporary rule.
• The ending dwell — win and loss screens hold for a beat before accepting input. The pause lets the moment land and stops a held button from blasting through several states in a few frames.
• Presses, not held levels — some screens need an edge, not a button held from the previous state. Edge detection and dwell timers are siblings: one finds the new press, the other gives the screen room to breathe.
• A finished loop — combine them into a tiny state flow: title prompt, game, respawn, game over, restart. Every transition tells the player what happened and refuses the accidental input that would make the game feel slippery.

By the end, “feel” should look less like mystery and more like engineering: choose the rule, put it on a clock, show it, and make every damage path, input path and state path respect it. The Pattern Library keeps the reusable reference entries; the machine tracks turn them into real code.