Simulation Scheduling

This chapter's thesis: the rewritten scheduler should promote "interest" (whose attention drives whose settlement) to a first-class citizen — the granularity, frequency, and order of settlement are allocated explicitly by interest, so that singleplayer and ten-thousand-player servers share one kernel and differ only in interest radius and budget size; meanwhile a special institution, the "strict-sequence zone", is reserved for causality-sensitive gameplay (redstone). If an interest-driven scheduler cannot preserve singleplayer-grade causal explainability at ten-thousand-player scale, this thesis is wrong.

1The problem

The servers chapter (Servers and Scale) set two legacies before the rewrite: vanilla's "one global clock" contract (perfect discipline, single-threaded budget) and the community's two jailbreaks (Paper's performance patches; Folia's regional parallelism — the latter proved feasible, at the price of rewriting the plugin ecosystem¹). Chapter 3 (Discardable Accidents) listed "causal explainability" among the invariants this chapter must keep: what redstone players need is exactly the "integer-tick delay, same-tick interlock" certainty that can be written into tutorials.

Which makes the exam question precise: design a scheduler in which interest decides resources (solving scale), causality decides order (keeping redstone), and the two never fight. The skeleton of the answer is one principle: interest decides "whether it is computed at all, and how soon"; causality decides "in what order it is computed" — untie the two from the same rope. Vanilla tied them together (the global clock governed both frequency and order), and that is exactly where the scale ceiling came from.

2The limits of the global 20 TPS

First see clearly what is being untied. In vanilla, the global clock holds three offices at once: metronome (the world's unit of time), budget sheet (one round per fifty milliseconds), and order guarantee (the order of events within a tick is determined). The Game Loop and the Tick told its greatness; here is its limitation: three offices in one mean the three check and constrain one another — for all chunks to share one beat, the budget must be provisioned for the worst case; for order to be determined, computation must be serial; and serial computation plus a unified beat equals "every part of the world, whether or not anyone cares, being settled at the same granularity and the same priority". The grass in an unwatched desert and the redstone clock under a player's feet queue in the same line.

There is the limit: the global clock is precise about causality and blind about interest. Yet the overwhelming majority of simulation work (grass growing, zombies wandering, distant water) demands far less causal precision than it does resources — it does not need "the same tick"; it needs "roughly on time". To mistake blind equality for discipline is to scatter a scarce budget on places that never needed it.

One comparison of two servers exposes the conflict of the three-in-one office. Server one, a redstone engineering server: dozens of large machines running around the clock, players demanding extreme "same-tick precision" and caring not at all about entity counts or terrain area — the ideal budget is "nearly everything to strict-sequence settlement". Server two, a survival challenge server: a thousand players scattered across a huge map, each surviving on their own, not one machine anywhere that cares about timing, while the total mass of entities and crops is staggering — the ideal budget is "nearly everything allocated by interest, with timing coarsened". Today's global clock hands both servers the same configuration, so the redstone server struggles inside a budget diluted by irrelevant load while the survival server wastes timing precision it cannot use — and each server's admin hand-forges patches, snipping, one by one inside plugins, the knots that one rope cannot untie. To rewrite the scheduler is to propose institutionalizing this long-running "knot-snipping movement" in a single stroke.

3Interest management and sharding: the first step of explicitness

The proposal's first layer makes interest explicit: each player declares (or the system derives) a region of interest; simulation resources are allocated strictly by interest. Near: full speed, fine grain. Middle ring: lower frequency, coarse grain. Outside: suspended, with only the stock retained. Vanilla already carries the embryo of the idea — the separation of simulation distance from render distance was interest explicitation's first step — and the rewrite merely generalizes it from "two distance parameters" into "a continuous, declarable interest model, set separately per content type": this farm settles once a day; this redstone contraption settles every tick; the grass along that desert highway — does not settle at all.

The design of "declaration" has three tiers worth distinguishing, because they answer to three real constituencies. Implicit interest in the player's position is the default tier — where I am is what gets settled; that is today's simulation-distance logic, operated by no one. Explicit interest from players and communities is the middle tier — an admin or author sets settlement tiers for specific areas in the management interface ("this farm: one beat per second"; "this machine: full speed every tick"), and the manual optimizations now scattered across assorted plugin configs become, here, one unified interest map. Interest declared by content itself is the top tier — a map author writes the scheduling needs of their gameplay into the datapack (the data-driven philosophy extended to the scheduling layer); a minigame map declares "the opening needs high frequency; settlement needs atomicity", and the engine supplies per the declaration. Three tiers, from implicit to explicit, conscripting the invisible labor of three kinds of people today (the engine's built-in assumptions, the admin's plugins, the author's documentation) into institution.

Sharding (the spatial partitioning the servers chapter covered) is the interest model's execution structure: the world is divided by space into scheduling units, each unit holds its own queue and clock offset, and the players' interest map decides each unit's settlement tier. Units talk through explicit messages — and here Folia's lesson must be recorded honestly: once the units are cut, if the interface is not designed, the ecosystem shatters. The rewrite proposal therefore adds one hard requirement: the inter-unit interface (message semantics, order guarantees, timeout behavior) must be a first-class, documented object, not an implementation detail. The solution to the redstone problem lives inside this requirement; the next section unfolds it.

4Causal tiers: redstone, fluids, and entities each in their place

Interest settles "whether at all"; what remains is "in what order". The proposal's core institution is causality-tiered settlement: the world's simulated objects are ranked into three grades by causal sensitivity, each grade with its own settlement discipline.

Strict-sequence zones (redstone and machines): the space where causality-sensitive simulation lives — redstone signals, piston interlocks, everything players treat as a "program" — is registered as a strict-sequence unit: settlement inside is fully ordered, atomic, reproducible, equivalent to a high-fidelity local replica of today's global clock. Relaxed zones (the world's background): fluids, crops, natural growth — settled in lower-frequency batches; approximate order suffices, since players can neither notice nor depend on it. Background zones (the far away nobody is interested in): state is kept and nothing is settled, or a statistical model does rough work (a generalization of the entities chapter's LOD).

The tiering's key institutional design: grades are declared by content, never guessed by the system. A redstone machine's author (or an automatic connected-graph analysis) registers the machine as a strict-sequence zone; a farm's author does not care about order, and does not register. Thus the strict-settlement budget is spent only where it is truly needed — a ten-thousand-player server's compute stops being evenly wasted on grass in the no-man's-land — while redstone players' causal discipline receives a stronger promise than vanilla's (vanilla's "same tick" was in truth a global act of grace; the strict-sequence zone turns it into a contract clause).

The prerequisite question — "where does a machine end?" — has an engineering-mature answer: automatic discovery by connected graph. Redstone components and the blocks they influence form a graph (dust joins to dust, a torch clings to its block, a piston pushes its target); walk a graph traversal out from any redstone component, and the connected region reached is a "machine's" natural boundary — it is exactly the diagram the community draws when it sketches machine blueprints today (the redstone chapter told how the blueprint is the circuit diagram: Redstone's Implementation). Automatic discovery cannot be perfect — the traversal walks only causal edges, and coincidence beyond the edges does not count as dependence — and when a machine extends dynamically (a piston pushes out a new block), the graph extends on the spot. Beyond automatic discovery, player marking remains the backstop and the override: people know better than algorithms that "these machines that look unconnected are really one system". The dual mechanism has one goal: to land the precious resource of "strict sequence" precisely on every machine, not scattered across the whole map.

5Entity budgets and LOD: writing the tax into the institution

The entities chapter established that "entities are the real tax"; the proposal makes that tax explicit as a budget institution: every scheduling unit has an entity settlement budget (weighted by importance), and overdraft triggers automatic downgrading — distant entities freeze AI and keep only a visual shell (a faraway cow no longer "thinks"; it just stands), middle-distance entities get simplified settlement, nearby ones pay full price. The officials' tax-relief designs (aggregation, lifespans, caps) are promoted here into a scheduler-built-in entity LOD (level of detail) — just as the render layer cuts triangles for distant blocks (the rendering chapter), the simulation layer cuts "thoughts" for distant entities.

A side payoff of the budget institution: entity performance stops being "mystery" and becomes "parameters". Today's admin line "too many entities cause lag" can become "this area's entity budget is N; over budget, automatic downgrade to low detail" — players could even see how much budget their own farm consumes. Performance moves from flame-war topic to resource-management interface — which is what "interest management as a first-class citizen" (the servers chapter's demand) looks like when it lands in front of ordinary players.

6Time-travel debugging: causal explainability's final form

Chapter 4's replay proposal (event sourcing — World Representation) lands on the scheduling layer as: strict-sequence zones are reproducible by nature; relaxed zones can be recorded and then replayed. A strict-sequence zone's settlement is ordered and atomic; its input log replays directly — any failure of a redstone machine can be "rewound" for diagnosis. Record a relaxed zone's settlement order and it replays too (the order itself goes into the log). The scheduler thereby incidentally solves its own debugging problem: a reproducible scheduler, when a fault is reported, can hand over not a mystical description ("it just breaks sometimes") but a stretch of history that can be re-enacted exactly.

For the redstone community there is an emotional layer too: their debugger, as documented, is "watch the signal lamps, pull half of it apart and try again" — a replayable scheduler amounts to giving this folk science a laboratory. The invariant of causal explainability (an entry on chapter 3's list) is honored here to the utmost: not merely "order is determined" but "order is determined and can be re-enacted".

7Redstone causality, unshattered: the acceptance test

Finally, the acceptance question head-on: will interest-driven sharding shatter redstone causality? The answer hides in a design called causal ownership: the unit of sharding is space; the unit of causality is the connected graph; the two are not required to coincide.

A redstone machine (an automatically discovered connected graph, or an author's explicitly marked region) registers as one causal unit — inside the unit, strict sequence and atomic settlement, and no way the sharding cuts can affect it (a unit is never torn across a settlement boundary). Where units must interact (one farm's machine pushing another's), they take the explicit interface: message passing with defined semantics (chapter 3's "cross-region grammar"). Here Folia's lesson receives its correction: what gets parallelized is not "spatial regions" but "causal units" — spatial partitioning is only the physical mapping of where causal units end up placed, never the basis of the partitioning itself. The rare case of a machine straddling units (a colossal farm complex) is declared by its author as a single causal unit, and the scheduler reserves contiguous settlement territory for it.

Thus interest management governs "where computation is spent", causal units govern "in what order it is spent", each to its own office: ten-thousand-player scale saves its money through interest; redstone discipline saves its life through units — one kernel, two institutions, and a singleplayer save is merely the special case of "a very small interest radius and very few causal units". The exam question is answered.

8What this chapter leaves behind

• For players: the redstone clock at your feet can, in the future engine, be "registered as a strict-sequence zone" — it sounds cold, but it means every beat of your machine is written into the scheduler's constitution.
• For developers: what you can take away is the decoupling formula — "interest decides frequency; causality decides order" — and the causal-ownership design (connected graphs registered as atomic units, explicit interfaces between units): a systematic correction of the Folia lesson. What you cannot take away is strict sequence's compatible stock: what decides which machines must run in strict sequence is the several million machines that grew over fifteen years — a rewriter must first own that community before this institution comes within their means.

注释

1. Minecraft Wiki, "Folia" (the Paper team's regionized multithreading experiment; cited here as the lesson of spatial partitioning), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Folia . ↩