Bedrock Edition

While going through the code base, refactorizing huge parts in order to make it easier to update with newer versions in the future, an attempt was made to implement a prototype for Bedrock Edition(aka Pocket Edition). About 2 weeks were spent on and off, skimming through the minimal documentation that existed(and has been removed) and trying to avoid reading other mappers implementation unless necessary. Just recently after several hours debugging why the module crashed at what seemed randomly positions, finally it ran through all the tests without any issues. The following paragraph contains technical details on how the format works.

It has been known for a while that BE use Googles LevelDB at its core. To reduce bloat and to challenge myself, I decided to implement an in-house reader. This went quicker than expected, not thanks to the documentation, as most references to the code base. In short, data is split up into key-value pairs and further into block structures, where each block is compressed with any kind of compression that you pick, for Minecraft it is zlib(Which PixelMap already uses). What is less known is how Minecraft structure the keys and data. First off, the key contains either a name for a unique structure, or a specific size determining what the key itself contains. This was documented, but apparently Mojang updated the format recently, forcing me to deduct if the changes will impact anything I’ve recently implemented. The changes was minimal, but it is still unknown what the additional values is used for. For most keys, it is structured in a binary string that contains chunk position, data type and optionally some more attributes, like y position on the chunk section.

The data on the other hand depends highly on the key. The two types that was handled was the sub chunks and height map. Height map was as simple as reading 256 2-bytes integers. The sub chunks on the other hand made it more complex by implementing a second format. This format was made with nibbles in mind, with addition to “wedged blocks”, palettes and block entities for both features. What makes this even more odd, is that NBT is used for each element. And as LevelDB uses little endian for its values, so will this version of NBT. The confusing part is that each NBT structure is individually placed next to each other, with a single integer value representing the amount of them in succession. Luckily, as the data itself is similar to Java Edition, it will be an easy task integrating it in the PixelMap pipeline. The biggest problem right now would be to find a good way to process it over multiple threads. More refactorization may be needed to reduce boiler plate.

Basically, the Bedrock Edition save format is split up into at least 3 completely different formats, just so it can be even more optimized. It will be fun implementing the final version for this after the prototype will be “thrown away”.