I built my own Minecraft — and learned why Minecraft is built the way it is

This year I’ve been making Antica, a game in the spirit of Minecraft: a voxel world of blocks, procedural terrain, structures.

Antica, February 2026: procedural terrain — a river, its bank and mountains.

The gap at the water. I spent a whole day on one small thing: when you go down into water, there should be no gap on screen between water and not-water. While the camera crosses the surface, part of the frame is already underwater and part is still above it, and the border between them usually tears. I came up with a tricky algorithm based on intersecting planes — the water plane and the camera’s near plane — and the border became clean. In Minecraft itself, as far as I can see, the gap is still there.

Debugging in the Unity editor: the camera sits right on the water surface, its view frustum in yellow.

The same algorithm being debugged: the camera frustum in red and the polygon that comes out of intersecting the planes.

Then I worked through the rest: splitting the world into chunks, lighting, generating terrain and structures. And I came to the conclusion that you can’t really do better than Minecraft here. All their decisions are tied to each other.

Lighting. It isn’t ray tracing but a flood fill from the light source over about 16 blocks: light spreads from block to block and fades. That keeps the balance — fast enough to run, with acceptable quality.

Chunks the full height of the world. It would seem more logical to make chunks 16×16×16. But lighting always needs to know which block is the topmost: where the sky ends. I actually started that way — generating 16-block cubes, thinking I could walk the surface through connected chunks. But that can’t be guaranteed: the terrain formula may produce something even higher, above the “ceiling”, and then you can’t tell whether you’re in a cave. So a chunk has to be generated whole, the full height of the world — it makes things harder, but otherwise you can’t compute the light.

Chunk-by-chunk generation in debug view, seen from below the world: the frames are chunks.

Villages and idempotency. Structures are their own story. Whichever side the player approaches from, the village at that spot has to come out the same. But a village isn’t built by a formula from the terrain, like the relief: it grows recursively from a single point — streets, houses and everything else. So you need to know that point’s coordinate in advance, and that coordinate is baked into the region.

Block, chunk, region. Storage came out logical too: a block → chunk → region hierarchy, and a region is saved whole into one file. Nothing in between is needed.

And separately — respect for the optimisation Minecraft did when it reworked caves. You can see how fast it all runs and that they really put work into it. It looks like under the hood they do have smaller chunks after all — purely technically, so the mesher can work on them quickly.

What I took from it: before inventing your own, find out why the leader did it exactly this way. In Minecraft one decision pulls in the next: lighting dictates the chunk height, structure generation dictates the region, and the region dictates the storage format.