Hi all - Steve here. I’m a programmer working on Off Grid - and I’ve had the pleasure of working on save systems recently. :)
Ha! This is really one of the short straws of game development. When I was at Sony, it was almost a rite of passage; these were the days that not only did you have to save and load, but you were responsible for ensuring things didn’t die when the memory card (remember those?) was pulled out mid-operation.
Prior to this month, we had the beginnings of a save system in place, but were aware that certain things didn’t seem to be working quite as they should - so I took a look.
What I discovered was that we kept a save in memory as well as writing it to disk. This is a good thing - loading a checkpoint is faster. But a side effect was that there were two code paths to reinstating a save - to load it from disk, or to just reference the save data as game data. The danger with this is that the in-memory data can reference ‘live’ game data, which means the save on disk diverges with this during gameplay. Lots of copying data later, the bits that weren’t working quite correctly now seem much happier.
The other work I’ve done was on a system level. Saving and loading requires making a list of all the files available. Previously, we loaded all of these into memory - but as we cannot know how big they’re going to be, this will eventually cause us all sorts of problems. I’ve instead created a header at the top of each save file, containing the information we need to present to the player. Load the first 1000 bytes or so of each file, grab the header, close the file.
Saving and loading done then? Certainly not! We will still have new data that needs to be added to our save structure, and I bet there are still some bugs in there. But I’m confident that we are on firmer ground than we were a month ago.
Til next time!
Steve
Ha! This is really one of the short straws of game development. When I was at Sony, it was almost a rite of passage; these were the days that not only did you have to save and load, but you were responsible for ensuring things didn’t die when the memory card (remember those?) was pulled out mid-operation.
Prior to this month, we had the beginnings of a save system in place, but were aware that certain things didn’t seem to be working quite as they should - so I took a look.
What I discovered was that we kept a save in memory as well as writing it to disk. This is a good thing - loading a checkpoint is faster. But a side effect was that there were two code paths to reinstating a save - to load it from disk, or to just reference the save data as game data. The danger with this is that the in-memory data can reference ‘live’ game data, which means the save on disk diverges with this during gameplay. Lots of copying data later, the bits that weren’t working quite correctly now seem much happier.
The other work I’ve done was on a system level. Saving and loading requires making a list of all the files available. Previously, we loaded all of these into memory - but as we cannot know how big they’re going to be, this will eventually cause us all sorts of problems. I’ve instead created a header at the top of each save file, containing the information we need to present to the player. Load the first 1000 bytes or so of each file, grab the header, close the file.
Saving and loading done then? Certainly not! We will still have new data that needs to be added to our save structure, and I bet there are still some bugs in there. But I’m confident that we are on firmer ground than we were a month ago.
Til next time!
Steve
