Leonardo Giovanni Scur on Nostr: nprofile1q…8slxn game save formats usually come in one of three flavors: statistics ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqxlm22dggfnnfutmhlm5psyyfc6rvneyjmpaswnumqytfgm639j8q78slxn (nprofile…slxn)
game save formats usually come in one of three flavors:
statistics and settings and such, very unstructured data with little interdependency;
a tangled mess of references to static data, which expects to be consistent (think CRPG story states);
just a whole massive data dump, in such case taking in all that data is the main direction to optimize (you wouldn't want to store Minecraft chunks in a text format)
In cases 2 and 3, the data structures need to have internal consistency. For example if you edit a RPG so that you don't have a quest item, but you don't also update the quest state about having lost that item, you softlock that quest. Or in a voxel game, you can only refer to objects in the palette for that region as a way of compression. Or stupid things like saving the player being sat atop a horse that doesn't exist.
In addition to that, usually gamedevs don't think much about their save format, beyond it saving correctly, and having the properties they need to function well (case 3 for example)
So the data structures themselves might not be trivial to read, for example, saves for games that use Newtonsoft.Json's circular reference serialization will often look like a really deep object with $id keys pointing everywhichway, which is incredibly annoying for a human to read.
At which point it requires so much conscious interpretation by the user that the choice of format barely matters, a weird JSON blob or a weird binary blob are not that different if you can't understand either.
Which is not to say I endorse obscuring things against the player, for example deliberately encrypting saves of non-multiplayer games, but technical constraints usually end up coming first.
game save formats usually come in one of three flavors:
statistics and settings and such, very unstructured data with little interdependency;
a tangled mess of references to static data, which expects to be consistent (think CRPG story states);
just a whole massive data dump, in such case taking in all that data is the main direction to optimize (you wouldn't want to store Minecraft chunks in a text format)
In cases 2 and 3, the data structures need to have internal consistency. For example if you edit a RPG so that you don't have a quest item, but you don't also update the quest state about having lost that item, you softlock that quest. Or in a voxel game, you can only refer to objects in the palette for that region as a way of compression. Or stupid things like saving the player being sat atop a horse that doesn't exist.
In addition to that, usually gamedevs don't think much about their save format, beyond it saving correctly, and having the properties they need to function well (case 3 for example)
So the data structures themselves might not be trivial to read, for example, saves for games that use Newtonsoft.Json's circular reference serialization will often look like a really deep object with $id keys pointing everywhichway, which is incredibly annoying for a human to read.
At which point it requires so much conscious interpretation by the user that the choice of format barely matters, a weird JSON blob or a weird binary blob are not that different if you can't understand either.
Which is not to say I endorse obscuring things against the player, for example deliberately encrypting saves of non-multiplayer games, but technical constraints usually end up coming first.