The lecture map

The video series is an ordering over the system pages, which are the stable content. Each part’s landing page lists its lectures in watching order and says in a line what each one is; this page assembles the thirteen orders and states the dependencies between them — where a later part is assumed by an earlier one, and what to watch first because of it. It was drafted one part per session, and the owner confirms it — reading each part with the decompile open — before anything is recorded. Nothing in Reference is watched, and nothing in the maps is: the maps are looked at once, the reference pages are looked up, and a lecture links into them wherever a viewer would pause the video to read a table.

Because the subject here is the order, nothing below describes a lecture. What each one is about is said once, on its part’s landing page; what is here is what the order needs — how each part is ordered inside itself, the lectures that must be watched together or in a fixed sequence, and the pages worth taking out of turn. There is exactly one departure from the sidebar order, environment attributes and timelines before Part III’s second lecture; and there are three pages a viewer coming for one part alone has to fetch from elsewhere in the book, which the end of this page names.

The one rule that holds everywhere: each part assumes only the parts before it, and where that is not true the section says so and names the page to watch early. The dependencies between parts, at the end, draws the whole graph.

I · Anatomy

Anatomy — watched first, because every later diagram’s lanes assume it.
What this book skips — second and not last, because a boundary is worth drawing before you invest in thirteen parts rather than after.

II · Foundations

Watch 1 and 2 in that order and before everything else in the part. The five below them lean on those two far more than on each other, so 3 to 7 have little order among themselves: tags come after the resource system, whose stack they are read from, and 7 is the pattern the other six exist to make possible and reads best last.

III · The server

Part III is a line into a loop and out again: the loop first, because it is what the rest of the book lives inside, and the beginning and the end last, because they are only interesting once you know what they start and stop.

The server tick
The level tick — watched immediately after the first, and never apart from it.
Players and sessions
Starting a server
How a server dies

Watch environment attributes and timelines (Part IV) before the level tick if you want its opening to mean anything. It costs nothing to take out of order — it depends on nothing but registries and codecs — and Part III is the earliest of the six other parts that lean on it.

IV · The world

Lectures 2 to 6 are the vocabulary page and the conveyor after it, and must be watched in that order — nothing later in the chain can be watched first. Lecture 1 is off the line on purpose. Of the last four, 7 comes before 8; the other two need only the vocabulary page and can go anywhere after it.

Environment attributes and timelines — first, for the reason Part III already gave: it depends on nothing but registries and codecs, and nine pages in six other parts cite it, though only four of those parts’ landing pages list it (the table at the foot).
Chunk anatomy — the vocabulary page. Everything below assumes it, and so does Part V.
Tickets and loading
The chunk generation pipeline — Part XII is the cargo on this conveyor and cannot be watched before it.
Lighting — inside the chain, but nothing later in this part needs it first (chunk storage points at it only for the layers an unload drops); one page each in Parts IX and X cites it, and neither part’s landing page lists it.
Chunk storage
Scheduled ticks — two of Part V’s redstone lectures assume this one, and so does the next.
Fluids
Game events and vibrations
Points of interest — Part VI’s AI lecture reads this index, so watch this one first if you are taking that part next.

V · Blocks

Part V is a hub and six spokes, and the hub is watched first because the other six all reach back into the same pair of figures in it: what Level.setBlock and LevelChunk.setBlockState do with a write. Those figures are also where the two update channels are defined, which is the vocabulary every later lecture in the part uses. Two of the six are one lecture in two halves.

Blocks and states
Block interaction
Block breaking — the same lecture’s other half. Watch it immediately after, and never apart from it.
Block entities — reaches forward into Parts VI, VII and XI, most of all for the menu a furnace’s progress travels in.
Signal and dust — assumes scheduled ticks only lightly.
Pistons and block events
Diodes and the observer — assumes scheduled ticks properly: a repeater’s delay is an entry in that queue.

Part V’s two click lectures are the applications of prediction and acknowledgement in Part X, and that page’s own scenario needs this part’s vocabulary. The dependency is circular and this book cuts it here.

VI · Entities

Part VI is a ladder, and nothing in it can be reordered without breaking something.

Entity anatomy
Authority — short, and the rung the rest of the ladder leans on hardest.
Entity lifecycle — assumes tickets and loading for what entity-ticking means.
Synched entity data
Attributes — watched immediately after synched entity data, the two being a pair.
Movement and collision — needs authority in front of it, and blocks and states for what a collision shape is.
AI: goals and brains — assumes environment attributes and timelines for the schedule and points of interest for the bed.
Pathfinding — the other half of the same lecture, watchable on its own once goals and brains has run.
Damage and death

Part VI must precede Part VIII, which is the player half of nearly every page here, and it should precede Parts IX and X, both of which lean on authority. It assumes Part III first — two of this part’s surprises are claims about which phase of the tick something ran in — then Part IV for what makes an entity tick at all and Part V for what it collides with.

VII · Items and inventories

Part VII is two tiers. The first three lectures are the vocabulary and are watched in order; the last five are three engines that touch each other only at their boundaries, so they can be watched in any order — though the two pairs below want to stay together, and contexts and predicates leans on no stack at all and could come first.

Items and stacks — assumes data components completely.
Using an item
Containers and menus — needs both of Part III’s tick pages for when a broadcast happens: the packet drain at the top of the tick, the level’s entity phase, and a pickup in the connection phase after the levels.
Recipes
Enchantments
Enchanting — watch it directly after enchantments.
Contexts and predicates — the page in this part that Part XIII’s landing page names.
Loot tables — watch it directly after contexts and predicates, which it is the worked example of.

Part VII assumes Part II for components, codecs and the reload, Part III for where in a tick a packet is drained and a broadcast lands, and Part V for how a chest gets opened. It must precede Part VIII, which is the player’s own inventory and the swing that spends an item’s durability. Contexts and predicates is a prerequisite of Part XIII’s /execute if predicate and of the advancement system, and is the one lecture here a viewer coming for commands should watch out of order.

VIII · The player

Lectures 1 and 2 are the trunk and are watched in that order; the five below them fall into four groups that need nothing from each other. Only one of the four has an internal order — the spear is the sword swing’s sequel — so 3, 6 and 7 can go anywhere after the trunk.

Player anatomy — the vocabulary lecture.
The two-phase tick — watch it immediately after player anatomy.
Input to movement
The sword swing
The spear
Hunger and experience
Status effects

Part VIII assumes Part VI above everything — authority in particular, which is where the whole part’s premise is stated — and Part III for the tick phases the two-phase tick lives between. It assumes Part VII for using an item, which is the machinery both the spear’s charge and the meal run on; the inventory itself is Part VIII’s, and Part VII stops at the slot. Nothing later in the book is needed to watch it, but Parts X, XI and XIII come back to it.

IX · Networking

Part IX is the wire three times, and two things it carries. The first two lectures are one lecture in two halves and should be watched together; the third finishes the wire’s own story by showing the connection changing language, and the last two both sit inside the play language and need neither it nor each other.

The connection
Packets and stream codecs — the second half of the same lecture.
Protocol phases
What the client is told
Chat and signing

Part IX assumes Part III for the tick phases its traffic is timed against, and Part I’s anatomy for the two loops, which is the fact most of what looks like network jitter comes back to. It assumes Part II for codecs and for Component, and Part VI’s authority for the premise under lecture four. It is a prerequisite of Part X, which is the same wire watched from the receiving end.

X · The client

Nothing here hands off to anything except inside the GUI stack, six to nine, and between two and three, which share a ledger; every other page after the first answers “when in the client’s one loop does this happen” and needs only the hub. Watch the hub first and then take the rest in any order that suits, except the three groups noted below.

Six to nine are the part’s one internal pipeline and are watched consecutively, tree before text. Two and three are a pair. Ten and eleven are the two halves of sound, in either order.

Part X assumes Part IX for the wire it is the far end of, and Part I’s anatomy for the two loops. It assumes Part VI’s authority as the premise under lectures two and three — which split its question between them, what the client may simulate and what it may show before it is told — and Part V before lecture three, because Part V’s landing page rules that its two click lectures come first and they are the ledger’s two applications. Lecture six assumes Part VII’s containers and menus, which is the thing behind the screen it opens on, and lecture eight assumes Part II’s text components. Lecture one is a prerequisite of Part XI, whose frame is one span inside the loop’s turn.

XI · Rendering

The part opens on the frame itself rather than on the substrate underneath it — an inversion made for the viewer rather than for the dependencies, like the late place of Part XII’s structure lectures — so the watching order below is not the order a frame runs in.

Four and five are a pair — two pages that were one, and still one journey seen from its two ends — and so are seven and eight, the second written as the differences from the first. One to three can also be watched one, three, two.

Part XI assumes two pages of Part X: the client loop, which is what says when a frame happens, and the client level, for what the thing being drawn is. Lecture six assumes Part II’s resource system; lecture nine assumes Part IV’s environment attributes and timelines, which owns the system this part only consumes.

XII · World generation

The three structure lectures run first in the game and are watched last here, bar lecture ten: a structure is decided at ChunkStatus.STRUCTURE_STARTS, two statuses before the biomes it will stand in exist, and writes no block until ChunkStatus.FEATURES, one status after the noise fill. Keeping them together at the end costs two of the earlier pages a forward topic and buys a whole arc in one place.

One to six are the chunk being made, in the order it is made, and each from two on leans on one before it. Seven, eight and nine are one arc, and eight and nine are alternatives to each other rather than a sequence. Ten is the object the other nine read, told last because it is a tree of everything they explain — but it is the one lecture that moves, and a viewer who wants the origin before the machinery can watch it first.

Part XII assumes Part IV’s chunk generation pipeline, and hard: it is the only page that says when any of this runs and what the ten statuses are, and eight of the ten lectures here name one. It also assumes Part IV’s chunk anatomy for what is being written into and Part IV’s environment attributes and timelines for lecture two, where the biome is one layer of a modifier stack; and three Part II lectures — codecs, registries and the data-driven type pattern, whose fifty-six instances this part owns twenty-six of — because worldgen is the most thoroughly data-driven system in the game.

XIII · Commands and data packs

The dependency runs strictly one way: lectures 1 to 3, then 4 and 5, then the last four. Those last four are peers rather than a sequence — watch them in any order, or only the ones you care about — but none of the five before them is optional for any of them.

Two and four are the pair that most changes how a viewer reads everything else, and two is the one an existing mod author most needs; three sits between them because it needs the atom two defines and hands its fan-out to four. Six, seven, eight and nine each assume one through five and nothing else in this part.

Part XIII assumes Part III’s server tick twice over, because two of its pages turn on where in that order a thing sits. It assumes Part II’s codecs and the data-driven type pattern, of which dialogs and game tests are the two clearest instances; Part IX’s connection for the boundary between the Netty threads and the Server thread, which the command packets and the suggestion request each cross their own way; and Part VII’s contexts and predicates, which advancements need for every trigger that tests a player and selectors for one option.

The dependencies between parts

Every arc below is a before you start entry on a landing page: the part at the tail is one the part at the head assumes. The two dependencies the whole book leans on, whether or not a landing page lists them, keep their boxes and the one arc each along the spine, and have the rest of their arcs left off, because those would reach almost every node — Part I’s anatomy, for the threads every diagram’s lanes are on, and Part II’s codecs and registries, assumed wherever something is written to disk, sent on the wire or looked up by name. Two arcs out of Part II rest on neither — Part X’s on text components and Part XI’s on the resource system — and are left off with the rest. Read a solid arc as watch before: the parts run down the page in the sidebar’s order, and every solid arc runs down with them.

The thirteen parts top to bottom in watch order; an arc on the right runs from a part to one that assumes it, always downward, and the two dashed arcs on the left are the only places a part assumes a later one, each labelled with the pages it needs.

The graph is a line with two knots in it, and the sidebar order is a valid walk through it: no solid arc points at an earlier part. The two dashed arcs are the places where it does not hold, and each is cut on purpose rather than solved by reordering.

Part III assumes two pages of Part IV. The level tick uses entity-ticking and block-ticking range, which tickets and loading owns, and its first step throws away a cache belonging to environment attributes and timelines. The first is cut by definition — the level tick defines both ranges before it uses them — and the second by order: the environment page depends on nothing but registries and codecs, so it is the first page of Part IV in the sidebar, in that part’s watch order and in the list above, and it is the one lecture worth watching before its part.

Part V and Part X assume each other. The two click lectures in Part V are the applications of prediction and acknowledgement, and that page’s own scenario is a block placed against a wall, which needs Part V’s vocabulary. The cut is at Part V: both click pages state the ledger’s contract in the same four sentences near their top, which is all either needs, and the machinery waits for Part X, so the whole of Parts V and VI is watched before that one Part X lecture. Part VI hands something forward to two Part X pages: the client level opens by saying it is not an authority either, and prediction and acknowledgement answers the same question a second way, and both need authority behind them.

Ten pages carry most of the graph — nine rows below, because the two server ticks are one dependency in two lectures. The membership rule is mechanical: a page that two or more landing pages name under before you start, less anatomy, codecs and registries, the three pages the whole book leans on. A viewer who has watched these ten can take the parts they belong to in almost any order; a viewer who skips one of them will find a later part’s first surprise unexplained.

the page	its part	the parts whose landing pages assume it
The server tick and the level tick	III	IV, V, VI, VII, VIII, IX, XIII — seven of the eight later parts on the server’s side of the game, for which phase something ran in
Environment attributes and timelines	IV	III, VI, XI, XII — the clock, the schedule, the colour of the sky, and the biome as one layer of the stack
Chunk anatomy	IV	V, VI, XII — a block state’s home, the heightmaps that decide where a mob may spawn, and what terrain is written into
Authority	VI	VIII, IX, X — the premise under every page about a player, and under what the client is told
The resource system	II	III, VII, XI — the staged load and its barrier: a server’s own data at startup, where recipes and loot tables come from, and the reload the atlases are built by
The connection	IX	X, XIII — the thread boundary between the network and the game, and the hop most packets make across it
Tickets and loading	IV	III, VI — what entity-ticking means
The data-driven type pattern	II	XII, XIII — the type field in a data-pack file and the registry it dispatches on; these two parts own most of its instances
Text components	II	IX, X — what a chat line and a screen’s label are before anything draws them

Nineteen other system pages are named by exactly one landing page, and each belongs in that part’s before you start rather than in this table. Three are worth saying out loud anyway, because a viewer coming for one part alone most often has to fetch them from elsewhere in the book: blocks and states before Part VI, contexts and predicates before Part XIII’s advancements, and the client loop before Part XI.

Watched straight through, the sidebar order still needs one departure from itself, and it is now as small as it can be: environment attributes and timelines is the first lecture of Part IV and wants watching before Part III’s second. A viewer coming for one part rather than the whole book takes that part’s before you start list as the order.

The book’s two ends are chosen rather than inherited. What this book skips is the second lecture for the reason Part I’s entry gives; Part XIII’s game tests are the closing lecture because they are the game’s own answer to the question the whole book has been asking — how do you know what it does — and because nothing later depends on them.

Keyboard shortcuts

How Java Minecraft Works