Save Games; how do they work?

Can anyone in the Gaming world explain how save games work? I’m fascinated by how the game saves your whole world state in a little file. Some games like Just Cause 2 have save games that take about 1 second to make, and the Elder Scrolls Games have save games that are like 5 megs each. Anyone care to explain or link?

Just a stab, but I think there are two possibilities.

  1. Assuming there is a reference “undisturbed” game world, one method would only store data about objects (in the programming sense) that are changed from their undisturbed state, including those added and removed, quest progression, etc.

  2. Every object in the game world writes itself and its current state to an object graph that is saved and restored upon loading a save game.

It depends how deterministic your world is. If the state can be regenerated from a few saved variables, the save file will be small. If the game needs to keep track of potentially hundreds of items on the floor and dynamic AI states and so on, the files will be larger.

Was that what you meant?

Mostly it’s hacky, error-prone, and breaks all the time. Which is why so many games don’t actually try to support saving anywhere and instead just save something like “player is at checkpoint 5” and on load restart the game in a known good state.

Iterate through all world attributes and objects that are worth saving. Write those relevant details to a file.

A technical tidbit about Unreal, for those who care, is that Unreal has default values that are set for all variables in all objects. So when it comes to save your game state, it only has to save variables that have changed from the default.

So, when loading a save, it creates the object type in question, preloads it with default values, and the loads just the changed values from the save file.

That’s a very high level description, but it’s interesting as that’s one way to keep save file sizes down.

Just Cause 2, like other type of games like it, is a very big and very open but static world, which basically disappear the moment you turn to back. In this type of game not only it is not simulated (nor saved) what is happening in a city 5 kms away, in fact sometimes when you turn your back fast you can see the traffic appearing out of thin air! So forget “the world is hundred of km2! how is all saved?!”, the game out of a bubble around of you of a few hundreds meters won’t even exist when you are playing it. It will make reappear/create/reactivate the ai and the random land/sea/air traffic as you get close.

I suppose they only save stuff which can be affected by the player, so the enemy buildings that can be destroyed, and the position of vehicles left by the players. Sometimes not even that, in some games you return to an old enemy base it will be like new again. I don’t remember if it was the case in JC2.

Apart from that, of course there are good coders, and… less good.

Yeah, there are a huge number of tricks devs use. Some include:
-You only save changes to default state of the world, not the full state of the world itself.
-When dynamic things are far enough away, they evaporate. When you enter that area again, they are recreated (randomly or as per some algorithm or whatever.)
-With things like a dynamic city in Oblivion, it doesn’t have to actually keep track of where everyone should be unless you’re in the immediate vicinity of them. This is generally deterministic due to NPCs’ programmed schedules.
-In procedurally-generated games like minecraft, why bother making terrain that the user hasn’t seen yet, and may never see? That’s why in Minecraft, the more you explore the large the save file gets – it has to actually figure out what’s there (and then save it) since it’s not the same for everyone.

Open world games aside, I can’t fathom why most save game files these days are as large as they are. I have no idea how they’re burning through so much storage space.

I was just thinking of Just Cause 2, since it tracks so many stats for you such as destroyed Xes. It may seem like a lot of data, but (we were talking about this in the Far Cry 2 thread and how seemingly simple it would have been to save the checkpoint state) really every entry is just two bits of text - the unique ID of the object and its destruction state (0 - 100%). Throw everything into a hash table and write to disk, done.

Or better yet, as stated above, only throw in the stuff that was changed and run a diff on game load.

'course, it helps if your game is written to support object save/restore to begin with, but if you look at JC2 which keeps track of every X destroyed, that right there is already enough to build a game world state out of.

Just plain old sloppiness in some cases. I was shocked to discover that The Witcher was taking up nearly 7 gigs in save games, of up to 20 megs each (yes, I am a hateable savebaby). Looking inside the save file, there’s a lot of text of things like item descriptions and notes, in multiple languages. WTF is that doing in the save file?!? It looks like they simply iterate over every item you have and dump its state to the file, but the item state includes everything about that item including its descriptions, and they don’t differentiate between mutable and immutable data, so it writes out a lot of redundant data.

One reason I can think of that they might deliberately do it this way is that it might make loading of save games easier if they can get an item’s state entirely from the save file instead of partly from the save and partly from the game’s resource files, but still, 20 megs a save. That definitely wouldn’t fly on a 360.

The first Witcher was based off BioWare’s Aurora engine, which was designed for NWN. Since NWN was a toolset game almost everything was mutable and therefore you could not make assumptions about the state, specs, description, etc. of any object. No idea why they would keep that system for Witcher 2 though.

Ah right, I’d forgotten that part. There might have been some opportunity to optimize it a bit, but another thing about save game sizes is that it’s probably going to be a relatively low priority compared to all of the other things the team is going to be struggling with as they get closer to shipping. As long as it works and isn’t too egregious, it’s not worth much further effort.

Maybe because it worked and reducing save file size is a rather low priority.

This isn’t always the case, but some games save a screenshot with the savegame state. That helps identify the save state a bit, but can definitely bloat the save games.

(As others have stated, some games just store stuff they don’t need to, I think PC games are more guilty of this, since they usually have little to no limits)

This is really fascinating guys, keep it coming!

The trick WarrenM mentioned, about saving only the stuff that’s changed, is definitely one I’d like to hear more of. I sorta get how JC2 is a big list of what’s blown up and what isn’t (is_this_blown_up is my new favorite variable), what really fascinates me is Morrowind, where you can move objects around and have them remain there session after session. Amazing. And that was on the Xbox!

This is probably the most boring topic ever.

How would it work?

You saves the state of objects to disk. Then to load, you restore the objects from disk.

You only need for objects to be serializable, and be able to spawn again from the serialized data.

Not everything is worth to serialize. Stuff like particles position is not worth saving. If you don’t want to save all the data, you mantain a flag for “touched” vars that has been modified.

Teiman thrusts to the heart of the matter.

Nah, it’s interesting to me, too – I never really considered all the madness that has to be saved in, say, an open-world game like Oblivion.

They did fail to get Witcher 1 running on a console remember.

While this may not be about save games in particular, I still think it’s somewhat relevant to the spirit of the topic.

One thing I always found interesting is how Supreme Commander saves its game replays. You can have a gigantic 8 player slog that takes hours to resolve and come out of it with a replay that is under 2 MB in size. Considering that you’re throwing around thousands of individual units in a game of that length, it seems very impressive.

What the game does is save the starting positions and a list of all player inputs over the course of the entire match. When you watch the replay the game just resimulates the entire thing from scratch by issuing the same orders as the players did at the exact same time. This demonstrates the fidelity of the engine, which goes so far as to track the trajectories of individual tank shells among other things, in that the same set of orders will produce the same results time after time. It doesn’t matter if my MA12 assault tank had 220 hit points at 11 minutes, 13.84 seconds. The game will figure that out based on the fact that it was shot three times by Mantis assault bots a minute prior so storing those variables is useless.

It also has the bizarre quirk of enabling you to tell how much micromanagement is in a game based on the file size. More orders leads to a larger replay.

You can’t hear it, but I just whistled appreciatively at the technology and game design that went into that system. Wow!