One of the problems i run into building games, that I've never found a satisfactory solution for is the problem of getting save game to run fast by using binary files, adding variables to structs which are saved, the resulting file format changes, and its impact on saved playtest games.
long term play testing is done concurrently with development. many features added require additional variables that need to be loaded and saved. each time you add a variable, the save game file format changes, and you have to convert your save game files, or use a game editor to edit a new game up to where you were, or add a routine you run once that "edits up" a new game after it starts.
so at first, i'll use text files for save games. as variables are added, you add them to savegame() and init them in loadgame(). then load and save your saved games once, and all your files are converted to the new format. then you change the code to load them instead of init them in load game, and your up and running with new variables in your saved playtest games.
all fine and good til the file size gets big, and your "quick save" is pushing on 10 seconds, almost time enough to grab a beer right quick. and definitely too much time if your doing it every 30 seconds or so, cause you die a lot. you spend a lot of your testing time waiting for saves.
so then you go binary, and your 10+ second save is down to 2-3 seconds. quite reasonable for capturing the entire state of a simulation software program. but as soon as you add a new variable to a struct that already gets saved, your file format changes. then you need old and new versions of the struct declaration, and the load game and save game routines to convert the saved playtest games.
this often drives me to reuse or double up on the usage of existing variables that already get saved, to avoid converting save games. however, i consider this poor design. while doubling up on variable usage does speed up loads and saves, and avoids file format changes (whic is the reason i do it), it must be done with care to ensure the two usages of the variable do not overlap, and requires good commenting to make it clear whats going on. this leads to readability and maintainability issues, hence poor design.
another thing i've tried is adding filler fields to the end of struct declarations such as: unsigned filler[100]; // 100 bytes of filler
then when you add a new variable, you remove some filler, and the file format doesn't change. the problem with this is that adding enough filler to ensure room to grow slows down the binary save to almost the speed of the text file save.
another thing i've considered is just declaring structs with a few obvious variables, and then something like a data[10] array to hold whatever else is needed. as vars are needed, data[n] is assigned that duty.
here's the challenge:
you want a way to save and load data so that you can add a new variable to the file format and easily convert all old format files to the new format, with less hassle than the usual when changing binary file formats (IE old and new format declarations and versions of load and save). i found that with text files i could just add new variables to the end of load and save. you init a bank game to default values, then load. any variables not in the file because its an old format simply don't get loaded and the default values already set are used. i guess i'm looking for similar functionality at binary speeds.
does anyone have any suggestions?
clever database tricks was never my strong suit.