Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

VI · Entities

Verified against Minecraft 26.3 · Part VI · Everything in the world that is not a block: what one is, who is allowed to move it, how it is described to the other side, and how it stops.

A zombie glides where your own movement is crisp. A sheared sheep changes on every screen at once. A mob you name-tagged never despawns by distance, a hit that lands during the red flash usually does nothing, and Strength II raises your damage without a single attribute packet leaving the server. Those are five different systems and one question: which of the two programs is allowed to decide this, and how does the other one find out? Part VI is that question asked about everything in the world that is not in the grid — the zombie, the arrow, the boat, the dropped pickaxe, the invisible marker a data pack left as a bookmark. All of them are an Entity, a base class deliberately thin on behaviour: it gives them a box, a numbered array for describing themselves to clients, one collision resolver and one abstract method for being hurt, and not much else besides the riding, fire, fluids and portals they all share. So the answer to the question is never in one place. It is five mechanisms that each decide it separately, and the part’s claim is that every surprise on this list is one of those five answering a question you thought a different one had already settled.

The shape of the part

Part VI is a ladder, and the numbers on it are the watch order below. Each page needs the ones above it and nothing below them, and the second rung — authority — is the one everything else leans on, including Parts VIII, IX and X, which link back to it rather than re-deriving it.

flowchart TD
    A["1 · Entity anatomy"]
    B["2 · Authority"]
    C["3 · Entity lifecycle"]
    D["4 · Synched entity data"]
    E["5 · Attributes"]
    F["6 · Movement and collision"]
    G["7 · Goals and brains"]
    H["8 · Pathfinding"]
    I["9 · Damage and death"]
    OUT["Parts VIII, IX and X"]
    A -- "one type, one factory, one live object" --> B
    B -- "one side of each pair decides where it goes" --> C
    C -- "now it is in a world, findable and ticking" --> D
    D -- "one of six channels, and here is another" --> E
    E -- "the physics knobs are attributes" --> F
    F -- "something has to decide where to walk" --> G
    G -- "a decision is only a position" --> H
    H -- "and one abstract method answers every hit" --> I
    B -- "and so do three later parts" --> OUT

The ladder, numbered to the watch order, where every arrow means what the next page needs from this one, so the labels are why the order is the order. The rung with two arrows out is the one to notice: authority is the only page in Part VI that three later parts name as a prerequisite.

Two of the eight steps down the ladder are pairings rather than sequels. Synched entity data and attributes are two channels doing the same job differently, and the contrast is the lesson, so the second wants the first fresh in mind. Pathfinding is the other half of goals and brains and watchable on its own once that page has said where a wanted position comes from.

The arrow leaving rung two for Part X lands on two pages, and it is Part X’s dependency rather than this part’s: the client level opens by saying it is not an authority either, and prediction and acknowledgement calls itself the client’s second answer to the same question, and neither lands until authority has said what one is. So this part is watched first, and nothing here waits on Part X.

Before you start

The level tick, because two of this part’s surprises are claims about which phase something ran in — the entity phase runs after the phase that broadcasts entity changes, which is why an attribute change waits for the next tick the entity’s update interval allows, while a sheep sheared out of the packet queue, before the tick proper, does not. Tickets and loading, because whether an entity ticks at all is a property of the chunk it is standing in — for everything except a player, which is exempt — and chunk anatomy for the heightmaps that decide where a mob may spawn. Points of interest, because a villager’s whole day is claims on them and goals and brains leans on PoiManager rather than explaining it. Blocks and states for the shapes that entities collide with. Part IV’s scheduled ticks is a page of the world part you can skip before this one: entities keep no appointment book.

One more Part IV page, for one lecture: environment attributes and timelines before goals and brains. A villager’s timetable is a data-pack Timeline looked up at a position, and this part asks that system a question rather than teaching it.

Watch in this order

  1. Entity anatomy — one EntityType from the registry, through a factory, to a live object the level ticks. The registry’s default is a pig, and that default reaches the network and never reaches your save file.
  2. Authority — a zombie, a player and a boat each take one step on both sides. The client runs no physics at all for the mob chasing you, and the server runs your own player’s physics every tick and then throws the answer away.
  3. Entity lifecycle — a zombie appears in the dark, is ticked for a while, and is either forgotten or written to disk. The spawner rolls one height per category per chunk each time it tries, so caves and the open field compete for the same slice.
  4. Synched entity data — a sheep is sheared and every screen in range agrees within the tick. The slot the wool lives in is written nowhere in Sheep: it is 18 because eighteen slots were handed out above it, and the ids stop at 254 because 255 means stop.
  5. Attributes — Strength II lands, and no attribute packet is sent at all. Eight of the forty attributes never reach the client, and attack damage is one of them.
  6. Movement and collision — one tick of a falling zombie. The mover answers what did I walk through afterwards, by replaying the tick’s movement, and it settles fire and water touched in one step in a fixed order, so they always end in the extinguish.
  7. AI: goals and brains — a villager’s day, and the same machinery under a zombie that has none of it. The timetable is not on the villager: it goes to bed because it asked the world what time it is where it is standing.
  8. Pathfinding — the other half of the same lecture. Giving up is machinery: the node being walked towards carries a timeout, and the mob you watch walk into a fence and then wander off is running a scheduled surrender.
  9. Damage and death — the part’s closer. An arrow, eight owners of one number, and one abstract method. A hit that lands inside the red flash usually does nothing at all, and when it is stronger than the last, only its excess lands — silently.

Where the part stops

This is the largest part of the book by lines — 766 files and 112,091 lines in world/entity (less world/entity/player), network/syncher, world/level/pathfinder, world/damagesource and world/effect — and 33% of the part’s lines are named on no page in the book. Most of that is one class per species, and a species is the same nine pages instantiated: Panda is 1,121 lines of Mob with a sitting animation, and the 103 behaviour classes and 61 goal classes are nearly all one of three shapes, drawn once on goals and brains.

Four mechanisms there are more than a species and are explained nowhere — the minecart’s two movement models, the ender dragon’s eleven phases, a raid, and villager gossip — and a second edition should take them. The part also stops one rung short of Avatar: everything player-shaped is Part VIII, drawing an entity is Part XI, and the prediction ledger is Part X. Two packages above have their lecture elsewhere: world/effect, because the split an effect demonstrates is the player’s (status effects), and world/entity/ai/village/poi, lectured with the rest of the world’s claims in points of interest.

Reference this part uses

Five were written for this part. Attributes — all forty, with defaults, ranges and the syncable flag, generated from the registrations. Entity data serializers — all 44, in wire-id order, which is registration order. Entity spawn reasons — all nineteen, with the classes that behave differently for each; six are labels nothing tests. Structure spawn overrides — which six structures replace a biome’s spawn list, and what they put there instead. Damage outside LivingEntity — what each of the twenty-two non-living classes does with a DamageSource, on either side.

Then the shelf the whole book shares: packets, registries, game rules — ten of which this part’s pages name — math and primitives for AABB and VoxelShape, the glossary, threads and diagram lanes.


Rules: names, never code · how the system works, not how the code reads · newest version only · every backticked name passes tools/verify_names.py.