Entities and Collision

This chapter's thesis: blocks and entities have fundamentally different cost structures — a block is static data (stored once, read a thousand times, spends computation only when changed), while an entity is continuous computation (every tick, every one of them has to decide, move, and run collision queries); the number of entities therefore eats into the 20 TPS budget directly, making them the server's first tax. If a server carrying tens of thousands of entities performed on par with one carrying a few hundred blocks, this thesis would be wrong.

1The problem

A server can comfortably carry tens of millions of blocks: the whole Overworld's data lies on disk, and the active slice in memory sits as quiet as air. But concentrate a few thousand chickens in one place — some player's "chicken farm," say — and the server's CPU starts to smoke, and the whole world drops TPS together.

Tens of millions against a few thousand, and the heavyweight loses to the lightweight. To explain this inversion, return to the budget sheet this volume keeps coming back to (chapter 5): in every fifty milliseconds, the world has to do one round of business with "everything alive." Blocks are dead data and transact nothing; entities are living things — every tick, every one of them has to "think" (AI decisions), "move" (physical displacement), and "collide" (collision queries), and then sync its state to every client that can see it. This chapter runs from cost structure to the three classes of objects, then to the AI bill and the farm crash — the claim "entities are the tax," thrown down at this volume's door, gets cashed in here.

2Blocks are cheap, entities are expensive: two cost structures

The block's cost model was assembled in chapters 1 and 4 (see The Data Model of a Voxel World and Light, Fluids, and Block Updates): a static datum in a cell, stored in a palette, quiet, compressed, triggering an update only when changed. A block of stone's daily workload is zero — it just sits there, stored.

The entity's cost model is a different species. A chicken standing idle still gets three tasks from the server every tick. Think: run its AI decisions — what now, keep wandering or look for food? The decision itself is a table lookup and a priority comparison, but behind it sit cooldown timers and target-validity checks. Move: run its physics — gravity pulls it down, displacement gets split into small steps to prevent wall-clipping, and every step runs a collision query (which touches both world data and other entities). Speak: pack its position, facing, and animation state into sync packets headed for clients — any entity seen by any player is "on camera" every single tick.

Three tasks times the entity count is the entity's tick cost. The key asymmetry sits here: a growing block count is a storage problem (buy more disks), while a growing entity count is a compute problem (repayable every tick). Storage can be compressed, offloaded to disk, even pretended out of existence; computation happens again every tick — it cannot be compressed, cannot be offloaded, and pretending not to see it is how you drop TPS. That is the full meaning of "tax": the entity's cost is a floating debt re-levied on every tick; the block's cost is a one-time fixed asset.

3Three classes of objects: entities, block entities, display entities

"The movable" and "the data-bearing" actually hold three different household registrations in this engine.

Entities are everything that "has a continuous position in the world and moves by itself": mobs, players, item drops, arrows, minecarts, boats, armor stands. They live on top of the block grid and settle per tick — the main body of the tax bill. One entry deserves to be named specially: the item drop. Every item lying on the ground un-picked-up is an entity — it flies, it spins, it merges, it despawns. New players don't know this, so after a big server event the unlooted loot scattered across the ground quietly becomes several thousand entities — cause number one of servers "mysteriously getting laggy."

Block entities are the kind that "live inside a block but carry private data": a chest remembers what it holds, a furnace remembers how far its smelting has gotten, a sign remembers what is written on it. They don't move and don't pay the entity tax, but each one opens an object for its own data and joins tick-level processing (a furnace that is burning settles its progress tick by tick). A base full of containers, a warehouse building of thousands of chests — they pay another kind of tax, the fixed tax of data objects: lighter than the entity tax, but not zero.

Display entities are the third class, added officially in 1.19.4¹: lightweight "display-only, non-active" objects built for map makers — place a model, a line of text, or an item floating in the air, and it runs no AI and does no physics, at a cost far below a real entity. Its arrival is a textbook-grade architectural response: map makers had long kept armies of armor stands (real entities, full tax) just to "put up a decoration"; the officials looked at that wasteful bill and opened a low-tax registration for the "pure display" need. It is the architecture-layer counterpart of Volume II chapter 15's "add verbs" principle: open the right cost account for the right granularity of need.

4Collision and special-case physics

The reason an entity's "move" is expensive is collision. Minecraft's collision model is the plainest this book has seen: every entity's hitbox is an axis-aligned bounding box (AABB) — a cuboid that does not rotate. No capsules, no precise meshes; a horse's hitbox is a box lying on its side.

Plain is not the same as cheap to build. Stepped movement is the key trick against wall-clipping: a fast-moving entity can cross more than a block in one frame, and moving it directly would slide it through a thin wall — so the engine splits each frame's displacement into several small steps, runs a collision query at each step, and stops and corrects at the first hit. One move equals many queries, and the queries run against both world blocks (grid lookups) and other entities (neighborhood lookups, usually optimized with spatial bucketing — only check the entities near the same cell, not the whole world).

Special-case physics carries a few famous historical debts too. Boats and minecarts are the two most celebrated: their movement logic is hand-written special case rather than general physics — the minecart's rail-snapping and the boat's behavior on water each come with a private rulebook polished for years (and complained about for years); ghost collisions and hard-turn drifting, the community's oldest jokes, both trace back here. Riding is another special case: a player mounted on a horse stops being an independently moving entity and becomes an attachment hung on the horse — position derived from the mount every tick. The special cases all say the same thing: in any general physics engine, a few classes of objects get their own stove, for the sake of feel or historical compatibility — each stove is an extra maintenance tax, and players have grown fond of these stoves; they cannot be dismantled.

5AI: targeting, pathfinding, and the villager schedule

The fastest-growing line on the entity tax bill is AI. Its structure is a three-layer funnel. Volume II explained what mobs are for; this is what they cost (see Mobs, Combat, and Threats).

Target selection is the top layer: every mob keeps a list of "things it wants to do" (wander, chase, flee, eat, breed) and polls it by priority and cooldown — when the current target goes invalid or a higher-priority one appears, it switches. The per-run cost of this layer is low, but it runs every tick for every mob.

Pathfinding is the middle layer, and the bulk: once a mob has decided "walk over there," it has to find a walkable path across the block grid — essentially an A*-style grid search that also accounts for jumping, cliff avoidance, and opening doors. Pathfinding is expensive enough that the engine has to throttle it: recompute frequency is pressed down, paths are cached, and far-away targets are simply downgraded to "rough direction." One zombie chasing you is several grid searches per second — a zombie siege is a pathfinding storm.

Schedules are the villagers' exclusive top layer (a product of the 1.14 village rewrite): clock in by the timetable every day, idle, go home to sleep, with work stations and beds each assigned to an owner. Villagers are the most complex civilian AI in the game — and also the object players have industrialized most deeply (the trading halls of Volume II, chapter 10): at one end the most expensive civilian schedule system in the game, at the other end players squeezing it into a money printer. The villager's two faces line up exactly on the same ledger.

The AI layer hides one more tax base that gets overlooked: entities no player is watching are still thinking. Every mob inside the simulation distance makes its decisions as usual, whether or not you are looking — which is why "spawn fewer mobs" became common sense in server economics. The next section looks at how players bargain with this tax.

The entity tax also has a copy on the network dimension. Once the server finishes a round of computation, it still has to "say" the results out loud: an entity must appear on however many clients' screens it can be seen on, and so must send each of those clients its own sync packet — ten spectators watching a hundred-player battle means the entity-sync bill is the product "entities × viewers." This network tax explains two pieces of server common sense. First, large gatherings (weddings, tournaments, explosion scenes) lag a server more easily than large factories do — the factory is heavy in server-side compute tax, the crowd in network distribution tax. Second, "don't send what can't be seen" is a throttle built into the engine (entities outside your view are not pushed to you), and it incidentally became the first wall against wallhacks — what hides behind the wall never reached your client in the first place. One tax, two uses.

6Farms and crashes: players bargain with the tax table

The relationship between players and the entity tax is a history of bargaining, and both sides have produced masterpieces.

The players' masterpiece is the farm: mob towers control the rhythm of spawning and execution, chicken farms manage breeding and batch collection, and drops are funneled and flushed straight home by water — a well-designed farm is, at bottom, a school of tax optimization: compress "how long an entity exists" to the minimum (executed on spawn, collected on drop) so that the same output occupies the fewest "entity·ticks." A clued-in player asks "how many seconds does the entity stay" before building a farm, the way an engineer asks for the memory footprint.

The players' other masterpiece is called the crash: a chicken farm whose mass breeding ran out of control, unlooted drops piled up like hills, a minecart network spanning thousands of blocks (every cart an entity) — the classic trinity, dragging a server into the TPS abyss. The server's governance response belongs to the legislative framework of Servers and Scale: entity caps, timed cleanup of drops, mob caps per region — plugin legislation wrote the "entity budget" into the server's constitution.

The officials keep a set of built-in tax reliefs of their own, scattered across the engine and rarely read as a whole: drops automatically merge (two piles of the same wood on the ground soon become one, halving the entity count on the spot); drops carry a five-minute lifespan (this book met that countdown from its other side in chapter 3 — the despawn timer is also a tax-collection deadline); mob spawning obeys caps and density rules (a region that is full spawns no more); and, newest, the lightweight registration opened for display entities. Each of these reads on its own as a gameplay detail; read together, they are a tax-incentive policy written into the engine: the officials have been lightening the entity tax with the four instruments of "merge, deadline, quota, classification." Players' cleanup plugins are nothing more than the same idea rebuilt as a configurable administrative edition.

The official answer, though, is architectural, and besides display entities it includes one move that pulls the root out from under the problem: migrate the static things out of the entity registration. What doesn't need to move, best not move — every adjustment of this kind, "the right cost account for the right granularity of need," thins the tax base by one layer. Look back now at the complete statement of "entities are the tax": the tax is the engine's pricing of aliveness — think, move, collide, speak, each billed by the tick. And this game's economic history — the players' farms, the server owners' constitutions, the officials' re-registrations — is all a story unfolding around this one tax table.

7What this chapter leaves behind

• For players: your chicken farm is a major account on the server's bill — sweeping your drops into chests promptly is the most practical contribution you can make to everyone's TPS.
• For developers: what you can take away is the dichotomy of cost structures — price static data by storage, tax dynamic entities by the tick; when designing an object, first ask "does it need aliveness," and open a lightweight account for pure-display needs (display entities are the model). What you cannot take away is tax-table culture: players could turn a performance budget into an industry (the science of farm optimization) because this community has fifteen years of tradition in scrimping every tick — optimization awareness is a community asset, not a code asset.

注释

1. Minecraft Wiki, "Display" (display entities added in 1.19.4: block display, item display, and text display, letting map makers present static content at low cost), minecraft.wiki, retrieved 2026-09-18: see https://minecraft.wiki/w/Display . ↩