Volume IV · The Rewrite
If it were rewritten today, which essentials must be kept and which accidents can be peeled away — an exam, not a work order. Three parts: defining the problem, an architecture proposal, product and ethics. Read Volume II chapter 16 and Volume III chapter 18 before entering.
This volume's thesis: rewriting is not doing it all over again in a new language; it is peeling the accidents of 2009 out of the essentials. This volume is a thought experiment and a design exam — what it produces is a list of essential properties, not a work order of any kind.
1Before the exam
This is the book's final volume, and the only one "with no history to tell": it consumes every conclusion the first three volumes banked and produces no new facts of its own. Before opening it, confirm that two answer sheets are in hand — the twelve transferable principles of Volume II, chapter 16 (the methodology list), and the five-item minimal kernel of Volume III, chapter 18 (the architecture list). Every chapter of this volume answers on those two lists, amends them, or adds to them.
The other thing to know before the exam is the posture. Every few months the internet produces another technical proposal for "rewriting Minecraft," and it rarely survives its own comment section. What separates this volume from those is not technical depth but how the problem is defined: before rewriting a product, you must first answer what the object of the rewrite actually is, what must not move, what can be thrown out, and who rewrites and answers to whom. The answers to these questions are not in the code; they are in the history, design, and implementation of the first three volumes. That is why every chapter here reads like a design review, not a project proposal.
2A map of the three parts
Part One · Defining the Problem (chapters 1–3). What is being rewritten (four products that cannot substitute for one another); what must not move (the list of design invariants); what can be thrown out (the list of historical accidents). Entrance: What Exactly Are We Rewriting.
Part Two · The Architecture Proposal (chapters 4–8). Five long questions: world representation, simulation scheduling, the two-layer arrangement of scripting and mods, network and the sinking of authority, rendering and creation tools. Each chapter offers principle-level directions and trade-offs only — never a choice of language. Entrance: World Representation.
Part Three · Product and Ethics (chapters 9–11). Compatibility strategy (old saves are an ethic), who holds the right to rewrite (three things that must not be conflated), and the book's closing word — the rewrite exists so the original can be seen clearly. Entrance: The Compatibility Strategy.
3How to read this volume
Three ways to read it. As an exam paper (recommended): read each chapter's thesis first, write down your own answer, then check it against the text — this volume is at its best when you argue with it. As a design handbook: the five long questions of chapters 4–8 are independent of one another and can be consulted as needed. As the book's summary: readers who want only the ending can go straight to chapter 11, "Rewriting to See the Original Clearly" — the book's final closing word, and honest enough to tell you up front that even if no one ever performs the rewrite, this volume still deserves to exist.
An Engine That Can Be Modded Is the Complete Product
Volume III's close: kernel, protocol, data plane, toolchain, and community implementations form one inseparable composite product; which debts are in fact assets; and the five-item minimal kernel — the first answer sheet for the rewrite exam.
What Exactly Are We Rewriting
"Rewrite Minecraft" packs at least four undertakings that cannot substitute for one another. This chapter separates the vanilla experience, the mod platform, the server platform, and the creation tools; draws the line between the compatibility road and the inheritance road; and declares that this volume sets exam questions, not answers.