It still feels like it should be orders of magnitude less. For example, if each piece of cheese has an ID number that maps to cheese, an ID for what area it’s in, three coordinates for where exactly it is, and maybe a few more variables like how much of it you’ve eaten. Each of those variables is probably only a couple of bytes, so each item is probably only 20B or so, which means that even if you interacted with a million different items and there was no compression going on then that’s still only 20MB of save data.
Bold of you to assume the data in save files is packed binary and not something like JSON where { “x”: 13872, “y”: -17312, “z”: -20170 } requires 40 bytes of storage.
It’s not really laziness. Storing as JSON solves or prevents a lot of problems you could run into with something bespoke and “optimally packed”, you just have the tradeoff of needing more storage for it. Even then, the increased storage can be largely mitigated with compression. JSON compresses very well.
The problem is usually what they’re storing, not how they’re storing it. For example, The Witcher (first one) has ~20MB save files. These are mostly a bespoke packed binary format, but contain things like raw strings of descriptions in multiple localisations for items being carried, and complete descriptors of game quests. Things that should just be ID values that point to that data in the game files. It also leads with like… 13KB of zero-padding for some reason.
Save bloat is more often related to excess values not being properly discarded by the engine, if I remember right. So it’s not that the objects themselves take up a lot of space, but the leftover data gets baked into the save and can end up multiplying if the same scripts/references/functions get called frequently.
It was a lot worse with Skyrim’s original engine, and got better in Fallout 4 and Skyrim SE. The worst bloat happens with heavy modlists, of course, as they’re most likely to have poor data management in some mod.
Inefficient/unoptimized would be an accurate description. I think it’s important to add, for bethsoft games specifically, that the save includes all changes to objects, even if the player themselves didn’t interact with them(e.g. Physics interactions, explosions moving things, npcs bumping stuff around), and also includes all NPC changes. Master files(ESMs) get loaded, then the save loads the changes it has baked in to the databases. So, when you load up a save that has traveled the world and loaded a lot of things into save memory, the engine has to sit there and reconcile all the changes with the ESMs, which can add up quick if you’re playing modded.
It still feels like it should be orders of magnitude less. For example, if each piece of cheese has an ID number that maps to cheese, an ID for what area it’s in, three coordinates for where exactly it is, and maybe a few more variables like how much of it you’ve eaten. Each of those variables is probably only a couple of bytes, so each item is probably only 20B or so, which means that even if you interacted with a million different items and there was no compression going on then that’s still only 20MB of save data.
Bold of you to assume the data in save files is packed binary and not something like JSON where { “x”: 13872, “y”: -17312, “z”: -20170 } requires 40 bytes of storage.
Agreed. JSON solves:
For saving games, JSON+gzip is such a good combination that I’d probably never consider anything else.
protobuf does all of these (well, except compression which you dont need)
That’s excusable in My First Game™ but surely professional AAAAA game would never cut corners and code something so lazily, eh?
It’s not really laziness. Storing as JSON solves or prevents a lot of problems you could run into with something bespoke and “optimally packed”, you just have the tradeoff of needing more storage for it. Even then, the increased storage can be largely mitigated with compression. JSON compresses very well.
The problem is usually what they’re storing, not how they’re storing it. For example, The Witcher (first one) has ~20MB save files. These are mostly a bespoke packed binary format, but contain things like raw strings of descriptions in multiple localisations for items being carried, and complete descriptors of game quests. Things that should just be ID values that point to that data in the game files. It also leads with like… 13KB of zero-padding for some reason.
Good points!
looking at you x3
and rimworld
Save bloat is more often related to excess values not being properly discarded by the engine, if I remember right. So it’s not that the objects themselves take up a lot of space, but the leftover data gets baked into the save and can end up multiplying if the same scripts/references/functions get called frequently.
It was a lot worse with Skyrim’s original engine, and got better in Fallout 4 and Skyrim SE. The worst bloat happens with heavy modlists, of course, as they’re most likely to have poor data management in some mod.
Aha, so unexpectedly it’s bad/inefficient code that’s ultimately to blame
I wouldn’t say bad, but inefficient might be fair. Unoptimized I think is more representative.
Inefficient/unoptimized would be an accurate description. I think it’s important to add, for bethsoft games specifically, that the save includes all changes to objects, even if the player themselves didn’t interact with them(e.g. Physics interactions, explosions moving things, npcs bumping stuff around), and also includes all NPC changes. Master files(ESMs) get loaded, then the save loads the changes it has baked in to the databases. So, when you load up a save that has traveled the world and loaded a lot of things into save memory, the engine has to sit there and reconcile all the changes with the ESMs, which can add up quick if you’re playing modded.
Each object also needs the orientation, possibly also velocity and angular rates.
Yeah that’s why I rounded up a bit. But even if there’s triple the amount of cheese data then a million cheeses is still only 60MB