New Save System

[Storm-Peter]

This is my replacement for the current system.

Instead of saving every single block and loading them all from a file, it saves the world seed that was used to generate the world and generates the same world again to load it. Then in the file it stores only the blocks that have changed and slots them in after the world has been generated.

This system uses 82 bytes for a blank world compared to the 30 million bytes used in the current system. Each changed block adds 10 bytes to the file size so the player would have to change a lot of blocks to get anywhere close to the current file size.

The trade-off is slightly increased memory usage.

I've tested it and as far as I can tell it loads and saves perfectly.

[egordorichev]

Hm, that is interesting feature. But what about 100k blocks edited in the world? It wouldn't help much.
There is another way to modify current world save system: it called RLE.

It adds a flag to the block HP and if RLE is present and greater than 0, you should copy the current tile and all of its information RLE times down. RLE will never be greater than the number of tiles you have left in the current column. This should help us quite a lot.

And again, the world gen is much slower (why? did not find the reason), then load.

[Storm-Peter]

@egordorichev 100,000 * 10 = 1MB

With this you would have to edit most of the blocks in the map including the air to be as bad as the current system.

While this isn't optimal, it's sort of like how minecraft does it, by generating instead of saving everything you can have huge maps without storing gigabytes.

I think a sort of run length encoding would be possible too.

DATA (Short) DATA (Byte) DATA (Short) DATA (Byte) Frequency (Short) Location Location Location

And so on where the frequency is the number of positions using this data and the locations are the positions that the data needs to be put in. If you had a lot of repetition then this would be very efficient and unlike RLE it is completely unaffected by the order of the data.

Having "wood air wood air wood air" in RLE would only let you do groups of one whereas this would just group all of the identical woods into one group and all of the airs into another group.

I just made this compression up on the spot so there might be a better way but I think that's quite a good solution to the problem.

[egordorichev]

But as you can see, the current generator only creates a simple surface. If we would add more biomes, and stuff, every load will take quite a lot of time..
I probably need to make a research about this theme. By the way, here is how Terraria handles it.

[egordorichev]

Or, we should implement chunks and infinite world. But then, what about the corruption spreading and other processes? We should apply them to the whole world....

[Storm-Peter]

It would be much quicker if we did have chunks because you could just load say 2x the width of the screen and then load the neighbouring chunks as you approach them rather than loading the entire map.

And really we need to eventually scrap the entire the whole map is stored in a static array thing because it's kind of silly.

I'm not sure about how to modify chunks that aren't loaded but my first thought is that you include corruption in the generation process with a variable that changes how corrupted the chunk is. As the variable increases the corruption spreads until it reaches its max.

So then for the unloaded chunks you just increment the corruption variable and you don't need to load them because when they are loaded the generation will handle it all.

[egordorichev]

Yes, that is a great solution. But what if we use the region save/load technic? But in general, we will implement the chunk system then. So closing this pull. And thanks for your contribution!

[egordorichev]

Added an issue #41