So I've been programming for some time... and for as long as I have one thing still questions me... How are save files written and read. I've asked alot of people and I can't seem to get a straight answer. so maybe one of you or Paul knows... How does a game like Minecraft or Terreria store it's world data... I know it isn't binary since I've opened it plenty of times and found nothing
It _IS_ binary. And there are as many types of binary files as there are types of files. Binary files can be viewed with an editor that can deal with binary and then you can see the raw byte values. Every application will store their data a little differently unless they are using a standard format. There are numerous articles on the web on how to read Minecraft chunks so I won't go into that here.
If you view the raw bytes then sometimes you can reverse engineer the format... though if the format is compressed it will this difficult. For example, Mythruna run-length encodes its leaf data and I think I remember hearing that Minecraft gzips its chunks. (Mythruna will too someday on top of run-length encoding. It already does when sending files over the network but I like that I can dump and read the files from the command line with no special tools... because I know what I'm looking at.)
In Unix or Windows with cygwin, there is a command called "dump" which will dump the raw contents of a file as both hex notation and characters.
For example, I just dumped a Java .class file and it the beginning looks like:
build\classes\mythruna\BlockType.class:
00000000 cafe babe 0000 0032 00d4 0a00 2d00 9207 J~:>...2.T..-...
00000010 0093 0a00 0200 9409 002c 0095 0900 2c00 .........,....,.
00000020 9609 002c 0097 0900 2c00 9809 002c 0099 ...,....,....,..
00000030 0900 2c00 9a09 002c 009b 0900 2c00 9c09 ..,....,....,...
00000040 002c 009d 0900 2c00 9e0b 009f 00a0 0b00 .,....,...... ..
00000050 9f00 a10b 009f 00a2 0900 2c00 a309 0002 ..!...."..,.#...
00000060 00a4 0900 2c00 a507 00a6 0a00 1400 a707 .$..,.%..&....'.
00000070 00a8 0a00 1600 a70a 0002 00a9 0a00 1400 .(....'....)....
00000080 aa0a 0002 00ab 0900 0200 ac0a 00ad 00ae *....+....,..-..
00000090 0a00 ad00 af09 0002 00b0 0a00 0200 b10b ..-./....0....1.
000000a0 009f 00b2 0b00 9f00 b30b 009f 00b4 0b00 ...2....3....4..
000000b0 9f00 b507 00b6 0a00 2400 9208 00b7 0a00 ..5..6..$....7..
000000c0 2400 b80a 0024 00b9 0800 ba08 00bb 0a00 $.8..$.9..:..;..
000000d0 2400 bc07 00bd 0700 be01 0002 6964 0100 $.<..=..>...id..
000000e0 0149 0100 046e 616d 6501 0012 4c6a 6176 .I...name...Ljav
000000f0 612f 6c61 6e67 2f53 7472 696e 673b 0100 a/lang/String;..
Addresses on the left, hex values in the middle, text view on the right. You can see Java's magic number as the first 4 bytes. Hex: CA FE BA BE... "cafe babe".
This is a solid leaf file from Mythruna... so the RLE works really well:
..\Mythruna\mythruna.db\node-0x0x0\10x10x0.leaf:
00000000 2c00 0001 4000 0001 4000 0000 0000 0000 ,...@...@.......
00000010 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020 0001 0000 0000 0000 8000 0000 0006 0000 ................
00000030 0006 ffff 0004 0004 ffff 0000 0000 ..............
The first byte in a leaf file is the format version... hex 2c... or 44 in this case. The next four bytes is the X location of the tile in "big endian" format. Then Y, then Z. Then you get the generation level as 4 bytes. Then the file version, and the branch number, both of those are 8 bytes each.
X: 00 00 01 40
Y: 00 00 01 40
Z: 00 00 00 00
Generation level: 00 00 00 00
Version: 00 00 00 00 00 00 00 00
Branch: 00 00 00 00 00 00 00 00
Lit: 01
Empty cell count: 00 00 00 00
Solid cell count: 00 00 80 00 (32768... all cells filled)
Cell data size: 00 00 00 06 (6 bytes)
Light data size: 00 00 00 06
Then 6 bytes of block types and 6 bytes of light data. Since these are run-length encoded, a solid block (solid stone in this case since it is at the bottom of the world) is really short.
Those 6 bytes in the first case... first two bytes indicate that there are 32767 (the top bit is the flag that indicates that this is a size and not data) the next two bytes is the type of block... 00 04 or stone. Then there is one more block (to make the full 32768 blocks).
If you are curious, this is what the code to write a .leaf header looks like:
public void write( LeafInfo info, OutputStream out ) throws IOException
{
DataOutputStream dOut = new DataOutputStream(out);
dOut.writeInt( info.x );
dOut.writeInt( info.y );
dOut.writeInt( info.z );
dOut.writeInt( info.generationLevel );
dOut.writeLong( info.version );
dOut.writeLong( info.branch );
dOut.writeBoolean( info.lit );
dOut.writeInt( info.emptyCells );
dOut.writeInt( info.solidCells );
dOut.writeInt( info.typesSize );
dOut.writeInt( info.lightsSize );
}
The code that writes the data part of the file doesn't make as good an example because of the RLE.
