Infdev water and save-breaks news

Good news and bad news. Infdev is getting a massive water update! when? tomorrow! (15th june 2010)

Now, the bad news. I hate to do this, but I will break all your infdev saves.

One of the major performance issues with infdev is how it saves levels. I need to give it a major overhaul, and that will cause all old saves to break.

It would be possible to write a level converter for it, but I’m leaning towards not doing it, as it’s quite a bit of work just for preserving levels in a development build of an alpha version of the game..
If people are REALLY in love with their games, I could probably do something that converts only the terrain (no mobs, no chest contents, not keeping track of the time of day), or possibly work with some volunteer and give out information on how to write a level converter. If you wish to do this, first make sure you understand the NBT file format.

This save breaking change almost certainly won’t happen this week, and I won’t delete the old files after the change, so there’s still time to implement a converter after the change.

As requested, here’s the actual technical reason:

Right now, the level is saved in files that cover 16*16*128 blocks. Each file gets a unique name for the zone it covers, and gets saved to a subdirectory of a subdirectory to avoid having too many files in a single dir. My test level (which isn’t huge by any means) takes up 6.11 MB in 4825 files in 4160 folders. That’s an average of just over 1 kb per file. The file system on my computer (and many others) won’t allocate less than 4 kb per file, so the actual space used for this save is 18.8 mb. That means that the save is three times the size it really should be.

Saving and loading new areas of a map causes a lot of file seeks and reads (30 per second is not uncommon), which is far from optimal. Added on top of this is the time spent compressing and decompressing the data.

Instead, the new plan is to store data in much larger individual zones of uncompressed terrain data that can be directly memory mapped. Each zone will probably be something like 256*256*128 blocks and will occupy 4 MB each. Entities and Tile Entities will be saved in a separate database like structure.

(development blog links #1, #2)