Wednesday, April 8, 2009

World Save(2)

Got the basics of a world save in place. Right now it's crude, dumping the various generated buffers into a collection of files inside a .ZIP archive. A lot of things are hacked or hard coded at present, but the guts are there and functioning. Need to do a small bit of cleanup, and I've added some things to my TODO list:

Integration of PhysFS into the asset pipeline:
Currently, assets are loaded from the base directory, but making assumptions about where save files should be stored, where assets should be loaded, etc... can be bad, especially if you plan to deploy on different operating systems. For instance, sure, the user's folder or Document folder might be a good place on Windows to dump a save file, but on Linux it would be in /home/user and so forth. A virtual filesystem like PhysFS adds a layer of abstraction between the game and the filesystem. I don't have to worry about where the user's home directory is, where the root directory of the game is, etc... I can just query PhysFS to get all of that. The drawback is that I have to re-write all of my various asset loading and saving routines to use PhysFS file handles. TGA loaders, WAV loaders, etc... I've written a lot of code over the years to save data to disk, and I'll need to selectively re-write implementations of all of them to use PhysFS. That's, like, a half-dozen of TODO list items right there.

File versioning and re-structuring of world saves:
As the game matures, the format of world saves will change. I need to settle on a version numbering system for the various save formats, including the world save file.

Cleanup and re-structuring of .ZIP archive reading/writing for world saves:
I use minizip from the /contrib folder of the zlib compression library to read and write the world save archive, but I've hard-coded some bits, and I need to abstract things just a tad better, to make updating and expanding the world save format easier. The library code in minizip does make it a lot easier, though, so this should be no problem.

There are a few other items that I really should tick off the list before I get too deeply involved in the sub-map generation stuff. I've written some spaghetti code this day, and I don't want to leave it in place.

2 comments:

evolutional said...

I found that PhysFS was fairly easy to drop in-place in places that I used old C-style handles - for other stuff that uses istream or ostream, it's a bit more difficult. What I ended up doing was encapsulating the file system into a specific system and forcing anything that needed file access to go through that. In that way I could fully control which system I was using and could add in compression/encryption very easily without having to change anything else.

Joshua said...

Once upon a time, years ago, I started integrating PhysFS with my stuff, but all that has been left by the wayside. Should try to find it, I guess...