Light, Fluids, and Block Updates

This chapter's thesis: light, fluids, and block updates are the world's "invisible infrastructure": everything a player can see — brightness, running water, collapsing sand, lag — is the visible surface of these three systems computing in the background; the cascade update is at bottom an implicit graph computation a player can trigger at any moment, its scale the source of lag, its gaps the window through which exploits enter. Swap all three systems for "scripted performances" (texture-style light, animation-style water) and the game's feel should not change — any observed result to the contrary is this thesis's falsification.

1The problem

Three moments every player has lived through. One: you break open a roof, and a shaft of skylight spreads down through the hole while the darkness below retreats into a ring of shadow. Two: you pour a bucket of water into a ravine; the water spreads along the slope, forks, drops into a waterfall, and a few seconds later everything goes quiet. Three: you knock one stone out from under a sand wall, and the whole face of sand comes down with a crash.

Three moments, three background systems: light is recomputing everything within reach, fluids are advancing tick by tick, block updates are notifying the neighbors. What players see is the result; what they do not see is the cost — and these three costs are the entire origin of the word "lag" in Minecraft, and the delivery room of its most famous family of exploits. This chapter lays the three systems out one by one, so that enthusiasts can translate gut feeling into mechanism, and developers can read every entry on the bill.

2Light: how far a single dig reaches

Minecraft's light comes in two kinds: skylight (from the sky above, lighting the open air) and block light (from torches, glowstone, and other emitters). Both are measured on a scale of 0 to 15 (Volume II, chapter 1 covered the brilliance of this integer language), losing one level per block traveled.

The implementation keyword is propagation: light is not a label stuck onto cells that says "lit" or "unlit" — it spreads outward from the source cell by cell, like ripples, weakening level by level until the level runs out. The data structure of this propagation is the classic breadth-first search: starting from the source, asking ring by ring, "is your cell brighter than mine?", updating where the answer is yes, and spreading on. In its quiet everyday work nobody notices it; but its cost structure decides two sensations every player knows.

First, a single dig is a single lighting event. Break open one cell underground and skylight comes pouring down the new passage; the walls on both sides, the depths, the dark zones past the corners all have to be recomputed — an edit to one cell, and the reach of the lighting update is a large patch of three-dimensional space. Change terrain in bulk (leveling a mountain with TNT, say) and the lighting bills all come due at once: that is the mechanistic identity of "the game hitches after you blast a mountain."

Second, the lighting engine was once the biggest tenant on the main thread. Historically, lighting computation shared a thread with game logic, and when a recomputation bill came due, the game simply waited — lag's most habitual offender in Minecraft. In 1.14 the officials rewrote the lighting engine, moving recomputation into its own thread and overhauling the propagation algorithm¹; before and after, community performance mods kept working the same track in mutual confirmation with the officials — folk implementations repeatedly led, official rewrites absorbed the ideas. This pattern, "optimization mods as the advance guard," will be seen again and again in this volume.

The system's player-facing interface deserves a look too: the debug screen (the information layer summoned with F3) prints the light level at your feet and at your head as plain numbers. Light thereby turned from "a feeling" into "a reading" — every rule of thumb ("this cell is level 7, mobs can spawn here"; "place a torch every this many blocks") was computed against the integers on the official debug screen. Volume II, chapter 9 covered the contract between mob spawning and light (places below a brightness threshold belong to the dark side); this chapter supplies the contract's auditing tool, the one players used to turn "mob-proofing" from folklore into engineering. An internal debugging feature ending up as the building-code measuring stick of an entire community — that is the most dignified fate an invisible infrastructure can hope for.

3Fluids: design and implementation, deeply coupled

Minecraft's water is not a fluid simulation; it is a blockified fluid: water occupies cells, flows on a "depth level" from 0 to 7, drops one level per cell away from its source, and thins to a trickle at the end of its reach. Lava works the same way, only slower. Every clause of this rule is a design decision and an implementation decision at once — it is the book's finest specimen of design and implementation coupled.

Infinite water is the coupling's signature case: an empty cell pinched between two source cells turns into a source itself. Physically the rule is absurd; as design it is beautiful — it makes water a renewable resource, so that farm irrigation, underwater engineering, and canal transport can all be planned with confidence. Players made it into an infrastructure rule — infinite water was never in a changelog; it lives in the placement of two buckets.

The gameplay that blockified fluid produces depends entirely on its fakeness: cobblestone generators (water meeting lava makes stone) rely on the deterministic ruling on fluid contact; water elevators rely on the rule that flowing water pushes entities; item-sorting streams rely on the current carrying drops to a chosen cell. Swap in real fluid simulation (eddies, pressure, erosion) and all of these — half the foundation of the redstone engineering in Volume II, chapter 7 — are voided wholesale. Volume II, chapter 15 called unreal physics a concession (see Constraints Are Depth); fluids are the largest single entry on the concessions list: what was given up was physical truth, and what was bought was the determinism of an entire family of automation gameplay.

The implementation-side cost must be entered too: blockified fluid is "thinking" every single tick — flowing water is re-evaluated each tick, and one poured bucket puts dozens of downstream cells into the queue. Fluid is the biggest customer of the scheduled tick; on the next section's timetable, water fills the most slots.

The rhythm differences inside the fluid family are one of the game's rhythm devices: water and lava both run on scheduled ticks, but at different densities — water is diligent, lava is languid (several times slower), so slow that a player can watch its front crawl forward one cell at a time. Players read the difference as two personalities: water is a partner (transport, firefighting, water elevators), lava is a heavy object (fuel, waste disposal, defensive barrier). Even the tempo of "lava meets water makes stone" was tuned: whichever arrives first sets into obsidian, and the later arrival hardens into stone — the entire craft of the cobblestone generator rests on those two lines of scheduling parameters. Game feel, at the fluids, comes down concretely to how the timetable is drawn up.

4Three kinds of ticks: the simulation's timetable

The world runs twenty ticks per second (the contract itself gets a full hearing in The Game Loop and Tick), but the feeling that "the world is alive" is supplied by three different kinds of ticks. To borrow the language of a schedule, the three are three different ways of booking time.

The scheduled tick is an appointment calendar. A block "books" an appointment to do something at a future tick: water books its next flow, sand books its fall, fire books its spread and its dying out. Once booked, the appointment is kept — on time, in order. Its discipline is the foundation of automation gameplay: everything "predictable" in redstone and fluids is rooted in the scheduled tick's punctuality.

The random tick is a spot-check lottery. Every tick, the world draws a few blocks at random in each section and "attends" to them: a drawn crop may grow one stage, a drawn leaf may decay, grass may spread one cell. The draw probability has an official parameter (the random tick speed); server players know it well — turn it up and the crops come in faster². The world's sense of life (everything slowly growing) is supplied entirely by this lottery, and its cost is naturally even — unlike light, whose orders arrive in one burst.

The neighbor update is a knock on the door. When a block changes, its six neighbors (indirectly, more) receive notice: "I changed." A block that receives the knock checks its own rules: the sand whose support vanished should fall; the torch whose neighbor took in water should pop off; the redstone wire should recompute its signal. Of the three kinds it is the least conspicuous, and the most expensive — the next section explains why.

5Cascade updates: an implicit graph computation

Put the three kinds of ticks together and you can see how the world really runs: the block world is one enormous graph — every block a node, adjacency the edges — and any single cell's change triggers a round of local recomputation on that graph. That is the cascade update.

An ordinary cascade: you break one cell and the neighbors receive the knock; a sand neighbor books its fall (scheduled tick), a water neighbor books its flow, redstone wire recomputes its signal — itself a graph traversal down the line, the implicit virtual machine doing its rounds (the implementation of redstone); each response changes new blocks, and new knocks go out... An edit to one cell reaches everything inside a three-dimensional region drawn around it at whatever radius the rules allow. Almost always the cascade settles within a few dozen cells and the player feels nothing; but in places dense with redstone machines and crisscrossed with water (large farms, industrial bases), a single cascade can sweep tens of thousands of cells — and that meal is eaten on the main thread, with your frame rate sitting at the same table. The mechanistic identity of lag is now fully clear: it is not "too many things"; it is a storm of recomputation on one graph.

The cascade update is also the delivery room of the game's most famous family of exploits: item duplication (players say "duping"). The technical incubator of duplication bugs is almost always in the gaps of the cascade — two systems altering the same item data within the same tick, and once a player has measured the window in execution order precisely enough, one of a thing becomes two. This section offers no specifics, no methods — only two judgments. First, these bugs are the shadow of a difficulty inherent in graph computation: the tasks to be executed depend on one another and must all finish inside a twentieth of a second, so a gap between order and concurrency is bound to exist. Second, the official repair history reconfirms the law from Volume II's redstone chapter — in a world where players have already built on the behavior, repairing the order is changing the semantics: a change that plugs one duplication bug often alters the behavior of a generation of machines along with it, so the repair itself must be handled with the gravity of legislation — repairing is legislating. Exploits, lag, and frozen semantics share one root: the cascade's graph exceeds, in both scale and complexity, any budget anyone ever made for it.

And the end of this road once more runs toward adoption: while hunting the gaps, the community invented the craft of "update detection" (turning the quirks of update order into switches), and the officials' final answer was not a wall but a badge — the observer block (the co-optation Volume I, chapter 4 already told), a part that "sees a neighbor change and emits a signal." With it, the officials conceded that block updating itself is gameplay. From incubator of exploits to signal interface: the cascade update has walked the same road quasi-connectivity walked.

6What this chapter leaves behind

• For players: the hitch after you level a mountain, the two-bucket arrangement of infinite water, crops tuned fast or slow — now you know which system is on duty for each.
• For developers: what you can take away is the budget consciousness of "invisible infrastructure" — the cost models of light, fluids, and update propagation belong in the design document on day one, not in the incident report after launch; plus the timetable model that manages "randomness" in layers (the determinism of appointments, the sense of life from spot-checks, the immediacy of notifications). What you cannot take away is the players' industrial-grade creativity for exploits — wherever there is a graph computation, there will be people hunting its gaps; that is not a security problem, it is a cost of the ecology.

注释

1. Minecraft Wiki, "Lighting" (light comes in skylight and block light, propagated on a 0–15 level scale; 1.14 rewrote the lighting engine with multithreading), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Lighting . ↩

2. Minecraft Wiki, "Tick" (random ticks pick blocks at random in each section every tick to run growth and decay; the random tick speed defaults to 3 and is adjustable via a gamerule), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Tick . ↩