Comment by nexuist | Hacker News Reader

Comment by nexuist | Hacker News Reader

Parent Full thread

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?

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.

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.

Isn't `sizeof(bool) == 1` on most C99 compilers?

Having bool be 4 or 8 bytes is ridiculous.

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'"

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.

There are websites that pull down well in excess of 8mb of pure Javascript. Websites.

Reply on news.ycombinator.com