Road to Minecraft 1.0, Day 90: Infdev 2010-06-24 and the Zone File Format

Thursday.
Real date: 27 November 2025
Time machine: 24 June 2010

This update's main changes are improvements to the way rails behave when placed, the addition of the vignette effect in dark areas, the lagometer in the debug menu (though it is shown by holding F6), and slight tweaks to worldgen. I don't think it will be necessary for me to go find new chunks, because it really just tweaks the height scaling for mountains.

This is also the update when the pause menu changed to the layout it would use until Beta 1.5 added achievements and statistics. It also made 3D clouds all solid white instead of textured, which I think is a sad change.

Minecarts now visually contain a chest when placed. Ironically, they no longer store items, and are rideable. Yeah, I don't know. Notch logic.

Speaking of Notch logic, he decided to introduce a new save format, but before I discuss that, I want to talk about how brilliant the format he was already using truly was. You see, Notch basically invented a special data structure format called Named Binary Tree, or NBT, specifically for storing data in Minecraft. It's brilliant - so brilliant, in fact, that we still use it to this day. A Minecraft Infdev or Alpha world save is essentially folders of folders of individual chunk files. A chunk file is a GZip-compressed NBT file that contains some metadata about the location and status of the chunk, a couple arrays for storing entity data (like monsters, chests, etc.), and several binary sections for the raw data contained in the chunk, mainly lighting and blocks. This file, being an NBT file, is in a standardized format that is easily edited with external programs. No, really, you can just open it. 

 

This particular chunk, since it's compressed, is 3,080 bytes. A nearby chunk is 3,211 bytes. The problem is, because they are each in individual files, they actually take up 4,096 bytes of disk space, because that is the smallest amount of space a file can take on most modern filesystems. The result of this is that my 14.3 MB save actually takes up 31.2 MB of disk space, which is pretty horribly inefficient. Now, the data is already compressed, so by consolidating all these files into containers, we could solve this issue and any related performance issues (which were common back in 2010 when computers weren't typically very powerful).

...But that's not what Notch did. Or rather, he did, but he also for some bizarre, unfathomable reason undid a significant portion of what he was already doing right. 

Before I demonstrate anything, I want to explain what should be happening with this new world format, which the community has named the Zone format.

The Zone format takes all these thousands of individual chunks and splits them up into "zones," which are 32x32 areas of individual chunks. This is a good idea; Scaevolus did the same thing with McRegion, which did eventually find its way into the game in an official capacity. The thing is, Notch chose to abandon NBT in favor of a new completely proprietary barebones binary format. Worse, he chose to use no compression. 

Looking at the Zone format, the zone files store a count of chunks, a collection of 1,024 integers marking which chunks inside the zone are populated, and, of course, the chunks themselves. The chunks are stored basically as a bare binary representation of the top level items shown in the NBT file above (LastUpdate and below). Entities are stored in separate files, which have a slightly different format and are compressed, for some reason. I'm really not convinced he thought this through at all.

Let's go ahead and load up our save. I'll make a copy of it in the second slot before we begin.

Starting out, like I said, 14.3 MB data, 31.2 MB actual.

 

Oh, wow. This wasn't mentioned on the wiki, but this is the first version with the more familiar "Building terrain" and "Saving chunks" screens.

I loaded in only briefly, then saved and quit to the title. The size of the save increased massively.

 

155 MB. In what world is this acceptable? Keep in mind, only the chunks that were initially within my render distance have been converted.

The save folder now looks like this:

 

Keen-eyed and sharp-minded readers may notice that the coordinates of these files are nowhere near each other. For comparison, here is the save folder from a Minecraft 1.0 world in Region format:

 

The coordinate system here is the same. The region coordinates are very clearly adjacent to one another.

Anyway, I'm going to make the trek all the way back to my home base and we'll check the size of the world then. 

Arrived.

 

An absolutely ludicrous 465 MB. 

I'm now going to turn it to peaceful for the sake of testing and walk all the way back to prove a point.

At worst, walking the same path again, you would probably expect a size increase of a few megabytes. Maybe 20-50, to account for loading some more chunks you didn't quite load before.

So explain to me why it grew by almost 100 MB. 

 

The data folder reveals a whole bunch of nonsense:

 

These coordinates make absolutely no sense, and judging by the file sizes, there are probably some exact duplicate zones in there.

So what's going on?

To illustrate the problem, I will delete all of the old format chunks from the save folder. This will force the game to generate new terrain for any chunks that it doesn't find in the Zone format, rather than converting existing old chunks. 

Upon loading in, which took an unusually long time...

Suffocating in the ground. Now, why would that happen? 

I took a backup of level.dat before I walked back to my new base, so I'm going to load that backup. That will put me back at my home base.

Loading the save once again took ages.

Wow, I got really lucky here, this could not have been a more perfect illustration!

Obviously, half of my house is gone. Shortly after this version of the game was released, some players were reporting that their progress wasn't being saved consistently: they would make changes to their world, walk to another area, then walk back, and their stuff would be gone.

As we can clearly see here, saving isn't the issue. Loading it is.

Remember how the coordinates of all those zone files didn't make any sense? That's our problem. In short, the game is incorrectly calculating the zone coordinates.

There is a simple bit of math the game does internally to determine the zone coordinate it should be saving or loading. It takes the current chunk coordinate, divides it by 32, and uses that quotient as the zone coordinate...except it doesn't. Due to a simple mistake in the code, it actually just shoves the current chunk coordinate into that field instead. This means the game is using the coordinates of whatever chunk it happens to be trying to load or save for all operations in which it would be using the zone coordinate. 

In other words, the game is always saving, but it's saving with incorrect filenames. The result is a bunch of parallel universes that may or may not successfully be loaded at a later time. It also seems to destroy the game's performance sometimes due to a bunch of erroneous disk operations.

At 9:22 AM on the morning of the 25th (the very next day), Notch reverted the world format to the old one, which was the correct option given the fact that the Zone format was rather ill-conceived in the first place. A while later, in Beta 1.3, the game would receive a modified version of Scaevolus' McRegion in an official capacity which would solve the world format problem properly. 

...But what if he didn't do any of that?

My friend Kasami created a small patch to allow this version of the game to work correctly. You can find it here.

I'm going to demonstrate how the world format was intended to work, but please note that it's still crap and is a terrible solution to a problem that barely existed in the first place.

Once again, I will be walking from my new base back to my first base with my fancy now-not-in-half house. 

 

It is still an absurdly large save, but notice how it's 105 MB smaller than the first time I did this. That's because it didn't create a bunch of weird duplicate files:

Allow me to demonstrate that I can actually load back in with the source chunks deleted. 

Wow, it didn't take a year to save or load, either. 

And there you have it. A working Zone format.

I did want to briefly show the goofy minecart changes, so let me do that real quick.

Minecarts are rideable and have chests in them for some reason. They are also breakable now, so you can pick them up and move them around without just pushing them. There's no proper sitting pose, so you kinda just stand with your legs inside of a chest.

In testing, I was unable to get the booster glitch to work. I think it was much later that the booster glitch was introduced, meaning we have a while yet until minecarts are truly useful.

Thank you, and have a very safe and productive day. 
--Sidney

Links:
Kasami's Zone Patch 
Zone file format at Minecraft Wiki

Note: This post has been modified from its originally posted form. The real post date was 21 December 2025, which corresponds to 18 July 2010 and day 114 of the project.