It’s not so much about time (although I have played a couple of things that would take a ridiculously long time to save or load), it’s about the number of chances to make a mistake. If you only save ten values, it’s really easy for a programmer to verify that they’ve got everything right, but if they save ten million, there are a million times more opportunities for mistakes to sneak in and it’s much harder to notice each mistake, let alone fix it.
Fallout 4 is a bit of an odd duck here as the save format for the BGS games is basically just another ESM file, so reuses all the same serialisation and deserialisation mechanisms. Most games don’t have multiple places the game data can come from and a way to combine them as they’ve not got an engine designed with this kind of modding in mind, so there’s nothing to reuse in this way for saves. Given the general standards of engineering from that studio, if they didn’t have this as a core feature of their custom engine for nearly three decades, and instead had to come up with something from scratch, they’d absolutely mess it up or have to simplify the saving system.
FishFace@piefed.social 1 week ago
You’re right, it’s not about that. It’s about how long it takes for a developer to create the saving and loading routines, how complex they are, and the risk of there being things wrong with them.
Suppose you want to introduce at arbitrary points in Blue Prince. It means you now have to track:
If you forget a single one of these, loading the game will break in some way - possibly in some niche way that will never come up in testing. Suppose the thing you forgot was the state of some late-game puzzle, and in playtesting no-one ever saved and reloaded after doing that puzzle?
Maybe the consequences are that the puzzle is just reset in that save - that’s fine, right? Well, not if the consequence of doing the puzzle is saved, and you can then do it again. Maybe you just put an infinite money glitch into the game, or maybe when doing the puzzle again, the game code tries to re-enact whatever happens when you solve it, which has already been done, and because some assumption is invalid the game just crashes.
None of this information is stored in a “database text file” at all. It is stored in RAM alongside vastly more information in a manner which makes writing it to disk impractical. Some games do essentially dump their entire in-memory state to disk, but this is only possible if the game is very small and simple: the size on disk will be roughly the same as the size in memory, and games often take up several GB of RAM; it is not acceptable to write out multi-gigabyte save files to disk unless there is simply no alternative.
Game saving and loading is extremely complicated.
The complexity may even extend beyond the save/load part of the game code. For example, in Superliminal you can create a lot of physics objects. Continuing with my assumption that the game doesn’t save the location of them, this means that when you load, they’re all gone. That means there is no possibility that physics objects build up over the course of playing the game and cause performance problems or simulation instability. There are other ways of tackling this problem that may be more elegant - but developer time is limited, and if you can solve a problem decently with a shortcut, then it is often a good idea to do so.