Why We Have Checkpoint Saves

[RonHiler]

How do you guys feel about a save system where the game is auto-saved whenever something "permanent" happens? I will take, for example, Saints Row 3. There are only a few things that cause permanent changes in that game. Of course, finishing a mission counts. So does picking up a collectable, doing a stunt jump, or a barnstorm, or taking out a gang operation, etc. Basically, any time you do something that permanently affects the state of the game, it is recorded.

When you load, you don't start again where you saved, but at the nearest save point (which would be your closest crib for that game).

What is not saved: Enemy positions, because who cares. They are random spawns anyway, and you aren't going to be going straight back there on load (you go to your crib). Bodies (they disappear after a few seconds anyway). Wanted levels (going into a crib auto-erases all wanted levels, and since you are loading back into the crib, no need to save what they were).

In that game, you can save anywhere at any time (except while doing missions or activities). However, you still load back into your crib. So saving is pretty much just copying the last auto-save really, there isn't much point to it, except to create a slot for that save rather than relying on the auto-save slot.

I was going to use something kinda similar to that, so I wonder how people feel about it. I always thought it was a good solution myself.

 

[Phishfood]

You've clearly never actually tried to write a game-save system.

The current state of any game is represented by a very, very complicated nest of objects each with their own data and linking to each other in complicated ways. In order to save it all, you have to make every object such that all of its data can be accessed. Then you need to send all of that data up through the complicated object structure to a top-level object which can turn it to a serialized game state. Since your object structure isn't a simple branching tree, you need to be able to only save each object once, then recognize when you've already saved an object, and have a way to include that reference as part of another object's data. Then you have to be able to put all of it back together.

But that's only part of the fun: you don't want your save games to become unusable every time the code changes. Meaning that you need to find a way to do all this without tying it too closely to the details of the object structure.

And, no, computers are not "good at organizing information". They need to be told, in excruciating detail, how to organize any information you give them. We've got plenty of general-purpose cases which have already been solved by programmers, so you've never had to worry about it before, but none of those are going to work with the game engine that you just built.

Most of this can be accounted for by planning ahead. Sure, taking an existing game with objects all over and adding a save feature would be terrible. However, if you are starting from scratch it wouldn't be too bad. Assuming that simply dumping the memory associated with states to disk is not an option, there is still plenty to help. Give every object a "saved" boolean. Have an array of pointers to every object. It won't take much memory, then you can just loop through that array or arrays if you want one for npcs, one for physics objects and one for entities like ammo and just dump them to disc in XML. If the code changes you can simply have it ignore variables no-longer needed and automatically generate missing values to defaults. Hell, plenty of games don't transfer saves between versions. Is that really a problem? once a game hits release I wouldn't imagine enough goes on to cause any real issues.

Have a think what you really need to save. IS it vital to save the fact that an npc is 50% of the way through reloading? would anyone notice if you just left him at 0 ammo and had him start reloading again? Maybe I am odd, but when saving a game I generally don't commit the exact state of the game to my memory. I don't generally notice if a body is face up on load while it was face down on save, so long as it hasn't moved across the map or disappeared is perhaps close enough good enough? I know I've seen games where when you load the corpses re-do their ragdoll, this isn't really a problem..

So yeah, creating a save is a problem. It's far from an insurmountable problem, especially when held up to the problems of pathing and AI.

 

[4RT1LL3RY]

You've clearly never actually tried to write a game-save system.

The current state of any game is represented by a very, very complicated nest of objects each with their own data and linking to each other in complicated ways. In order to save it all, you have to make every object such that all of its data can be accessed. Then you need to send all of that data up through the complicated object structure to a top-level object which can turn it to a serialized game state. Since your object structure isn't a simple branching tree, you need to be able to only save each object once, then recognize when you've already saved an object, and have a way to include that reference as part of another object's data. Then you have to be able to put all of it back together.

But that's only part of the fun: you don't want your save games to become unusable every time the code changes. Meaning that you need to find a way to do all this without tying it too closely to the details of the object structure.

And, no, computers are not "good at organizing information". They need to be told, in excruciating detail, how to organize any information you give them. We've got plenty of general-purpose cases which have already been solved by programmers, so you've never had to worry about it before, but none of those are going to work with the game engine that you just built.

As a software developer myself (not games....yet) whenever I hear another developer say "Its too challenging to..." I translate it in my mind to "I'm too lazy to...."

Off the top of my head STALKER and Doom 3 were bit time FPS games that pulled off save anywhere just fine. Aliens vs Predator 2000 shipped with no save system and it was introduced later in an expansion.

Unity has the ability to just save the state of a scene in its entirety and I can't imagine more industrial strength engines don't have the same capabilities. Maybe back in the olden days of one-off engines saving might have been challenging but there is no more excuse now. Even emulators let you save the state of the system they are emulating to reload later. In summary yes it might be "hard" but that isn't an excuse.

Having an emulator save the state of the game it's playing is much easier- you can just straight up write the emulator's memory and register contents to a file. You don't have any external resources to worry about, and nobody expects to re-load a save emulated game state after patching the game.

Im a CpE Major and its not that hard to create a save system. Various objects in-game relate to known structures, there are a known number of states for each object. For instance we have enemy soldier, he will have an object ID, position and orientation, current behavior (from a finite enumerated list most likely), health, items. That tells us everything we need to know about that soldier, you will make a function that hashes this so its in a nice serialized chunk that is easy to deal with. Hashing an object in a specific way is an easy way to serialize things you would save, huffman encoding is a loss-less way to reduce the size of the save that is easy to load from.

Step 1: Create hash method that serializes the important bits
Step 2: Have hash of all non-area specific things; inventory, health, abilities, found items, etc
Step 3: Go through all non-static objects in the scene that you want saved recording them as you go
--Using object IDs its easy to loop through only a single time
Step 4: Write to file

That is a simplification of what is done, but its not to hard really. A save file is essentially an array of objects, objects themselves don't have much information being a structure full of variables where certain methods do work on said variables. Math and behavior doesn't need to be saved because that's not part of an object.

 

[Edguy]

..or you could just have saves allowed outside of combat, like the majority of modern games with free saves?

 

[tsb247]

I still see no justification for the complete lack of user-defined saves in modern PC games and/or ports to PC. They have always been a staple of PC gaming, and the trend of checkpoint only saving or only a single quicksave is becoming the norm. Modern PCs are more than capable of creating complex save states, just as PCs always have been, and it angers me to see a feature I came to depend on being tossed out in favor of convenience for the developer. It is also the primary reason why I hate console ports.

So, in summary, all I got from this article is, "Developers are getting lazy."

PC gamers have been getting user-defined save systems for decades. There is no reason why it should stop now.