Audio, Particles, and the Lies of Feel

This chapter's thesis: most of game feel is the client's performance — positional audio, particles, on-screen feedback, and prediction together wrap the server-adjudicated world of discrete facts into a continuous bodily experience; the boundary between performance and simulation is exactly the boundary of the trick that makes latency disappear. Strip away every piece of client feedback, leave only the bare data, and if players felt no loss of feel whatsoever, this thesis would be wrong.

1The problem

Three instants, and in all of them the player's eyes and ears are "lying."

You press left-click and start digging stone: the arm swings, the crack advances stage by stage, chips fly, the digging sounds run together into a string — while on the server's ledger, the block does not truly become yours for several more seconds. A skeleton shoots you: red light flashes at the edge of the screen, your body flinches back, a grunt — the server's ruling was completed long ago; what you are watching is the ruling's "staged broadcast." You walk into a forest: footsteps arrive from beneath your feet, a distant waterfall sounds from the correct direction — sound, remarkably, knows where it is in three-dimensional space.

Not one of these three instants is "necessary simulation" — all of them are the client's performance. Now try taking them away: the game would instantly degrade from "the bodily experience of living inside a world" into "a window onto a stream of synchronized state data." This is where the word "lies" in this chapter's title comes from: a great deal of game feel is performed. This chapter walks the whole program of that performance — audio, particles, screen feedback, prediction — and closes with a question easy to miss: when performance is the main body of feel, what about the players who cannot hear it or see it?

2A dig, a hit — and the server hasn't spoken yet

First, stand up the chapter's analytical frame: simulation and feedback are two different kinds of work. Simulation — the tick of chapter 5, the block updates of chapter 4 (see The Game Loop and the Tick and Light, Fluids, and Block Updates) — answers "what state is the world in"; feedback answers "what should the player be made to feel." Under an ideal network the two happen at the same moment, and the player mistakes them for one thing; latency and prediction exist, and the two split apart.

Take apart the most ordinary action there is, digging a block. The visual layer: the arm's swing animation is played by the client itself, with no communication whatsoever of the server's ruling; the crack advances through its ten stages, drawn by the client from a locally estimated digging progress (the verbs chapter covered how hardness sets the duration — see The Minimal Verb Set and Game Feel; that "estimate" is computed locally); the chipping particles are an effect generated locally and dying locally, and of them the server knows nothing. The audio layer: the digging sounds play to the same local rhythm. The data layer: the real progress is recorded server-side, and the moment the client's estimate diverges from the server's actual ruling — network jitter, a tool swapped out, a haste buff kicking in — it is rolled back and redrawn.

So the feel of "digging" is nine-tenths the client performing against a guessed result. Guess right (the overwhelming majority of the time) and the performance is reality; guess wrong and the performance is withdrawn — the player watches a block "dug and grown back." The entire experiential meaning of the authority model from chapter 10 (see The Network Protocol) lives here: performance gives you the instant, the ruling gives you the real, and the gap between them is the shape of latency — performance is the fiction; authority is the fact.

Getting hit is the same machinery's other face. The damage flash (the world reddens for a frame), the knockback and the sound of being struck, the immunity hint inside the invulnerability frames — all of it is the client's staged translation of the server's ruling packet. The packet itself is only a number (how many hearts deducted) plus a source coordinate; translating it into red light, a grunt, and a flinch backward is the client's performance department. The quality of that translation between number and performance is the chemistry inside "hit feel."

3Positional audio: space you can hear

In Minecraft, audio does more than score the game; it carries an entire layer of spatial information — the item on the performance list closest to being "function."

Positional audio's principle takes one sentence: every sound has a three-dimensional coordinate, and the client computes volume (near is loud, far is quiet) and the split between left and right channels from the sound source's position relative to your ears. A whole stretch of gameplay thereby grew on the ears: a zombie's low growl from behind tells you "trouble at your back — do you turn?"; the direction of running water in a cave points out "the water is over there"; a creeper's fuse hiss carries no direction at all (which is part of what makes it frightening), while a skeleton's bow "click" is clearly placeable — veterans can identify most of the threats in a cave with their eyes shut; the ears are their second pair of eyes.

For hearing-impaired players, the loss of this information channel is a genuine reduction in combat capability — that is the final section's topic. Record the structural judgment first: positional audio is part of the simulation (the sound sources are real world state); its spatialization is performance, but the information it carries is true. It is the only item on the performance list where a truth is wrapped inside a lie.

Audio has one more layer that does not use the positional system: music. Its design is the exact opposite of sound effects — it provides no information, only emotion, and it is extremely sparse. The piano pieces C418 wrote for the game do not trigger by scene; they descend occasionally amid long stretches of mining and building, stay a few minutes, and quietly leave. The sparseness is not a budget saving; it is syntax: precisely because the music so rarely speaks, each time it sounds it feels like the world's own murmur; and precisely because it commands you to do nothing, it can keep company with play that has "no goal at all." Later versions added the jukebox and music discs, turning music into a collectible item — the emotion layer was drafted into the grammar of the item system, a gentle footnote to Volume II's line that everything can be filed into a grid (see Crafting, Items, and Inventory).

4Particles are feedback, not cinema

The particle system — chips, smoke, sparks, splashes — is easy to take for decoration; it is in fact the main vocabulary of the feedback language.

Translate a few of its common words. Block chips = "this is being changed, and the progress of the change is visible" (the voiceover of that crack from the verbs chapter). The thin white lines of a landed hit = "your attack's hit registration took effect — right now." The white smoke when flames are doused = "this state has ended." The swirling particles of a potion's color = "I have this status" — and the last is above all a functional word: players read their own buffs and afflictions off their own particles; here the particle is the status screen made visible.

A particle's "performance" property is decided by where it runs: particles are a purely client-side phenomenon — generated locally, moving locally, vanishing locally, never touching the network. The particles you see and the particles another player sees are two sets computed independently on two machines, with no communication between them (their trigger events are synchronized; the particles themselves each perform their own). This confirms the chapter's frame once more: the world of feedback is each client's own stage play — the script delivered by the server's events, the staging each of them responsible for its own.

"Particles are feedback, not cinema" also carries an engineering meaning: the number of particles is a framerate tax (the most active line on chapter 9's rendering bill — see The Client and Rendering), and their information value is uneven — critical feedback (a hit, a breakage) is worth spending framerate on; pure ambience (fireflies in the environment) must be spent sparingly. The video setting "Particles: All / Decreased / Minimal" is, in essence, the player choosing a point on this information-versus-performance curve. Ranking feedback's priorities into the render budget is the performance department's ledger.

5Client prediction: hiding latency inside the feel

Chapter 10 covered prediction on the network layer (movement acts first and confesses later; rubber-band rollback); this chapter looks once more at its performance edition, from the feel side.

The prediction list is longer than one imagines: movement (walking and jumping respond instantly), digging progress (estimated locally), the attack swing (animation first), the placement ghost (the block outline follows the crosshair instantly), eating progress, container interfaces (chapter 7's rehearsal — see Items, Inventory, and Crafting) — nearly everything the player does at high frequency is performed locally first, with the server's ruling arriving afterward to ratify it. This "perform first, confirm later" regime is feel's lifeline: a ruling rhythm of one beat per fifty milliseconds (chapter 5) plus a network round trip — if every action waited on its ruling, Minecraft's feel would fall back to a text MUD of the dial-up era.

The performance's boundary is the prediction's boundary. Prediction can cover actions whose result can be anticipated (walking, digging, placing); it cannot cover actions whose result is decided by the server (whether an attack hits is judged by the server, so hit feel always carries half a beat of genuine delay; the contents of an unopened chest are even harder to rehearse). The feel folklore that circulates among players — certain actions "glued to the hand," others "mushy" — reads crystal clear through this chapter's frame: what is glued to the hand is what was permitted to rehearse; what is mushy is what must wait for the ruling. Feel is not mysticism; it is the authority model's projection onto experience.

Prediction also carries a psychological cost rarely discussed: the erosion of trust by rollback. Every rubber-band (the server vetoing your rehearsal and dragging you back) is a miniature "the world lied to you" — rare on a healthy network, harmless; repeated under high latency, and the player subconsciously stops trusting the picture in front of them, grows hesitant, overcompensates. The whole performance system stands on the default trust that "the performance is reality" — the best authority system is the one you never notice — and rollback consumes exactly that unremarked trust. Tuning prediction is therefore not purely technical work; it is trust management: rather perform too little than perform wrong — a principle that holds in every system, and hurts most precisely here, in feel.

6Accessibility: the exception clause of performance

Performance manufactures feel for most players — and by the same act shuts a portion of them out: hearing-impaired players never receive positional audio's intelligence; visually impaired players never receive the red flash and the particle vocabulary; players who need high contrast or reduced motion are driven off by dense screen effects. The richer the performance, the more concrete the threshold.

The official investment in accessibility in recent years deserves its own record: subtitles — "zombie groans" and "skeleton bows" displayed as text with direction in a corner of the screen, in effect fitting the ears with a pair of eyes (since 1.9, Java Edition)¹; a high-contrast mode; toggles for screen shake and flashing; text-to-speech. These are not charity attachments; they are parallel translations of the performance list — the same world state, one translation prepared for each sensory channel. In this chapter's frame: the simulation unchanged, the feedback made multilingual.

It is also a mirror: how far accessibility goes exposes which items on the performance list were, in truth, lazy — if a piece of information travels only the sound channel, the designer deposited function inside performance; adding subtitles is the work of ransoming that information back from performance and returning it to simulation. So the answer to "is accessibility design or debt" is: it is the debt performance owes simulation — performance borrowed the information's carrier; accessibility ransoms it back. The debt has run from the game's minimalist early years all the way to today, and it is still being slowly repaid.

7What this chapter leaves behind

• For players: the next time you lag, watch closely: which things keep moving (the client's performance) and which things stop (the server's ruling) — you will see feel's two-layer structure with your own eyes.
• For developers: what you can take away is the division-of-labor table between performance and simulation — simulation owns the truth, feedback owns the experience, prediction covers predictable actions and never covers adjudicated outcomes; and accessibility's accounting view: information that travels only one sensory channel has been pawned to performance. What you cannot take away is the performance's inventory: a decade-plus vocabulary of sounds, particles, and animations accumulated jointly by community and officials — a new project can copy the entries with ease; growing the language sense is the hard part.

注释

1. Minecraft Wiki, "Subtitles" (the subtitles accessibility feature, available since Java Edition 1.9, displays in-game sounds as text with an indication of direction), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Subtitles . ↩