Some people are saying there's a save-file "memory leak" around crafting, where if you craft an item and then sell it, it's still taking up some small amount of space in your save file, meaning your save file size strictly increases
If so there are two issues: total capacity and strictly increasing size
This is why I never buy ambitious open world games until 1-2 years post release. It’s not just Cyberpunk 2077. I can call out every Fallout from Bethesda, Skyrim, No Man’s Sky, and the list goes on.
Stay away for a while unless you want to pay to do QA
Can we talk about how it's even possible for a save file to reach 8mb? Back in the day (way before my day!) a z80 could only address 65kb of RAM total. It was still possible to load and play an entire 2D game + save file given that space constraint. Obviously I'm not going to compare a modern AAA title to Drug Wars from 1984, but I will compare strings to strings and ints to int. The basic data sizes haven't changed.
Let's be generous and assume every character in the save file is stored as 4-byte UTF-8 (the edge case - most characters are 1 or 2 bytes only). Given that 1MB is 1 million bytes, that means you can store 250,000 characters in 1 MB, or 2 million characters in 8MB.
What is being stored in this file to warrant space equivalent to 2 million characters?! As far as I'm aware the save file doesn't include PNGs or video recordings that would obviously blow up the size. It onlys contain strings and numbers. How are there so many to fill up all that space?
Maybe someone in the game dev industry can shed some light? It seems so crazy to me, although I am admittedly approaching this from an embedded hardware background.
EDIT: It seems like people are saying this is caused by craftable item data. Even then, with 2 million characters to work with, you'd have to craft 200 guns assuming each item takes up 10,000 characters, and 2,000 guns assuming each item takes up 1000 characters. As far as I can see each gun only has a handful of attributes, so...what gives?
It's not only modern games, I remember a similar issue with the first Deus Ex game which is ironically also a cyberpunk game and it was released 20 years ago.
I guess they saved the whole state of the map and items which made the save files several megabytes large. My hard drive was only around 100 GB back then, so it was a real concern to accidentally fill it when I saved too often.
I think it's just that you don't need to be clever when storage is cheap. A boolean in C is the same size as an int. In the past you would pack this into bitfields, but why bother any more? Right there that's a 32x or 64x blowup on space and it's the first thing I thought of.
Just checked, and you are right. I'm probably thinking of the pre c99 days where a boolean was often implemented as an enum.
(Perhaps unsurprisingly) the literals "true" and "false" appear to be of integer size in the compilers I tried on c99, implying they are implemented as "1" and "0" and not "'\001'" and "'\000'"
Consider that an 8MB save file isn't necessarily a problem.
If you have that much space to use, you might not want to just store the attributes of the items, but their entire history, without regard to the size of a history entry, because you can reasonably assume that people aren't going to spend a lifetime crafting items in this game.
You can just start implementing it this way because you speculate that you may find a cool use for it, somewhere way down the line during development, when changing that system would become prohibitive. If you don't find a use for it, the overhead still doesn't matter.
The latest generation of consoles have (or at least have been slated to have for some time) very significant improvements in IO bandwidth.
To the extent that it may make sense to use file formats that map very closely to in-memory formats, or to duplicate data, even at the cost of file size. If you can stream data faster than you could feasibly decompress it, and if having a flat format is faster than a normalised de-duplicated one, a lot of common sense ideas are inverted.
Well, if IO and disk is cheap, it is a smart engineering choice to use, say, JSON over a proprietary format. I would do the same. 8 MiB is nothing. I wouldn't even blink.
That's surprising. My saves for the original Witcher (from 2007!) are about 20 megabytes each. I guess they've actually gotten more efficient over time?
21 comments
[ 25.9 ms ] story [ 489 ms ] thread(not saying that for sure, just seems to be a big coincidence)
If so there are two issues: total capacity and strictly increasing size
Stay away for a while unless you want to pay to do QA
"AAA" is not a quality definition yet the size of the studio/marketing budget. Don't get fooled!
Let's be generous and assume every character in the save file is stored as 4-byte UTF-8 (the edge case - most characters are 1 or 2 bytes only). Given that 1MB is 1 million bytes, that means you can store 250,000 characters in 1 MB, or 2 million characters in 8MB.
What is being stored in this file to warrant space equivalent to 2 million characters?! As far as I'm aware the save file doesn't include PNGs or video recordings that would obviously blow up the size. It onlys contain strings and numbers. How are there so many to fill up all that space?
Maybe someone in the game dev industry can shed some light? It seems so crazy to me, although I am admittedly approaching this from an embedded hardware background.
EDIT: It seems like people are saying this is caused by craftable item data. Even then, with 2 million characters to work with, you'd have to craft 200 guns assuming each item takes up 10,000 characters, and 2,000 guns assuming each item takes up 1000 characters. As far as I can see each gun only has a handful of attributes, so...what gives?
Having bool be 4 or 8 bytes is ridiculous.
(Perhaps unsurprisingly) the literals "true" and "false" appear to be of integer size in the compilers I tried on c99, implying they are implemented as "1" and "0" and not "'\001'" and "'\000'"
If you have that much space to use, you might not want to just store the attributes of the items, but their entire history, without regard to the size of a history entry, because you can reasonably assume that people aren't going to spend a lifetime crafting items in this game.
You can just start implementing it this way because you speculate that you may find a cool use for it, somewhere way down the line during development, when changing that system would become prohibitive. If you don't find a use for it, the overhead still doesn't matter.
To the extent that it may make sense to use file formats that map very closely to in-memory formats, or to duplicate data, even at the cost of file size. If you can stream data faster than you could feasibly decompress it, and if having a flat format is faster than a normalised de-duplicated one, a lot of common sense ideas are inverted.