Why We Have Checkpoint Saves

[eBusiness]

Actually it is not only possible to make implement a save feature as a memory dump, it is also a pretty common method, or at least it was in the nineties. With a little fiddling and/or design consideration it is also possible to only save the relevant parts of memory, code and graphics assets can simply be loaded again, and they should end up building the same structure, where you just need to fill the unique game data into the address space it came from.

Of course even slight code changes would most likely break previous saves, and the exact structure of the data that doesn't get saved may depend on some system variables, but they should for any given computer be constant, so no problems (unless you install OS updates, update drivers, change the hardware configuration, or some other such stupid action, in which case those system variables might change).

 

[Clovus]

You could add 10 more paragraphs of stuff that has to be saved and it wouldn't be impressive. It's not like you are manually saving this stuff by writing it down. Gathering information, organizing it into files, and saving it is something that computers are really good at. If the developer goes in with the knowledge that they will need to save this stuff, then it shouldn't be super hard to do so.

And, yes, captcha, fezes ARE cool.

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

No, I haven't. I have a degree in CS, but you are right that I don't actually have specific knowledge of this system.

snip: saving is complicated

Yeah, I don't doubt that it is complicated or difficult, but it is something that has been handled just fine for years and years. I don't know, maybe everyone just recreates their save systems from scratch and there's not a known way of handling this problem. Although it sounds like you just described a bit of one. Difficult, sure, but it's not something that would take up a huge amount of developement time compared to the rest of the game.

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.

I thought computers just knew how to do this becuase they're smart or something. Yeah, you write code for the computer to remember stuff. That will often be custom code, but probably built using data structures and algorithms from previously developed games - you don't completely reinvent the wheel each time.

I'm just saying that it doesn't matter if the system has to save 10 things or 100 things. A database doesn't really get more complicated because it has more stuff to store. It's not hard to tell a computer what to do in "excruciating detail" - that's just normal programming, not rocket surgery.

 

[BloodSquirrel]

So what you mean is that the complete contents of the game's allocated RAM could be dumped to a file and then considered a "save file".

For Unreal games, that would be bad news, since Unreal uses A LOT of RAM (generally around 2 Gigabytes independent of map or game; I don't know why that is, it just is).

2 Gig save files are the least of your problems there.

1) Operating systems don't like you trying to manipulate memory that way, and programming languages aren't designed around that kind of practice. Even in C, you let the OS allocated memory for you and you use what it gives you to use. Trying to access addresses which haven't been allocated you is a quick way to hard-crash the game. You might be able to pull off something like that on a small scale using assembly, but Windows isn't going to let you do it with 2 gigs of memory while getting it to work with a game engine.

2) In order for a game to run on an operating system, it needs to have OS resources allocated to it. For example: If your game is doing anything over a network, it needs a socket allocated to it. If you were to re-load a saved game by simply copying a block of memory from the disk to ram, you would now have a program which thinks that it has socket #44431 allocated to it, but an OS which has done no such thing and will object to the assertion (ie, crash the program). Put simply: The program's state has to agree with the OS's state, and you're not going to get that if you load an old game state directly from ram rather than re-building one.

3) There's more to the game state than what's in RAM. There's the CPU registers, what's currently in the process of being read from the hard drive, VRAM, the sound card, etc. All of that would need to be restored to a compatible state as well.

4) Your game save files would suddenly become machine-dependent. When a game builds its game state, it's doing so partially based on system information provided by the OS. What happens when a game that was running on four cores now has to run on a system with two? What happens when your game was using version 1.1.3.0.1 of a system library, and since you've upgraded to 1.1.3.0.2? Or the game was being run from C:\Programs\Game, and now it's being run from D:\Programs\Games\Game?

5) Even the most minor patch to the game would render your game saves completely unusable. Now not only does the object hierarchy need to remain the same, but the actual code does as well, or otherwise you would have code in memory now trying to jump to the wrong place in the new code or a temporary variable being pushed onto the stack by the old code and not being popped back off by the new code.

For an emulator, none of those are a problem, since the emulator can let you save the exact state of the hardware, OS, and the state of the game and restore it all as well. And since all of those are internal to the emulator, all you need is for the emulator itself to not change in any way that breaks it.

 

[loa]

Yeah no sorry, this may sound overwhelming to the layman who has never coded something but saving hasn't become anywhere nearly as exponentially complex as other aspects of the game.
You can not justify bioshock infinite.

 

[Olas]

I don't know anything about game design or development, but I think there are lots of things being left out of this list. While this article might apply to something linear like a fps, what about games that take place in a gigantic complex world like Fallout 3?

When you kill an enemy in that game it's corpse doesn't disappear, it stays there in the same position for a long long long time, even after you leave the area. It also remembers every single crate and locker that you loot in every single hideout, what characters are alive and dead, who you've interacted with before, what specific questions you've asked and which you haven't. That map details every square inch of the game that you've been to before and leaves dark every place you haven't been. It remembers every mine that's still active, every dropped item still on the ground, the full altered inventory of every character you've traded with, every dungeon that's been completed, the entire state of literally the entire game world has to be captured in every single save.

This is in addition to everything mentioned in the article.

 

[UltimatheChosen]

Yeah no sorry, this may sound overwhelming to the layman who has never coded something but saving hasn't become anywhere nearly as exponentially complex as other aspects of the game.
You can not justify bioshock infinite.

The difference is that developers have a much larger incentive to do those "more complicated" things in other aspects of the game, because things like, say, graphics are much more noticeable to people who have yet to play the game.

Visuals feature prominently in game marketing and trailers. But when was the last time you saw a screenshot of the savegame menu on a game's Steam page?

 

[synobal]

Personally I'm not happy unless a game has a save system that lets me bind quick save and quick load to left and right click and actually needs me to do that because it's difficult is so stupidly hard.

 

[mascotbeaver]

This reminds me of the save system in FF 13-2. You could literally save anywhere and it would remember everything exactly the way it was.

RPG's are much more polarized (you're either in combat, wandering, or in a cutscene), and during all of those, not much is going on really in a game like FF.
Also, what's wrong with Bioshock Infinite? I played it on xbox and had no issues. Was this a PC quicksave esclusive issue?

 

[loa]

Also, what's wrong with Bioshock Infinite? I played it on xbox and had no issues. Was this a PC quicksave esclusive issue?

There is no manual saving in bioshock infinite, only invisible checkpoints.
It's easy to miss when it actually saves progress so you never know how much you'll lose if you stop playing right now.

 

[Boogie Knight]

Silent Hill: Downpour is probably the one game where I think this makes sense. The idea is that you're not in control, the town is, so it picks checkpoints and you don't have much of any say so.

 

[BreakfastMan]

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.

Eh, it might save the state of the SCENE, but the state of the script objects themselves? Somehow, I doubt Unity handles that.

 

[BloodSquirrel]

I thought computers just knew how to do this becuase they're smart or something. Yeah, you write code for the computer to remember stuff. That will often be custom code, but probably built using data structures and algorithms from previously developed games - you don't completely reinvent the wheel each time.

I'm just saying that it doesn't matter if the system has to save 10 things or 100 things. A database doesn't really get more complicated because it has more stuff to store. It's not hard to tell a computer what to do in "excruciating detail" - that's just normal programming, not rocket surgery.

Yes, it matters whether it's 10 things or 100 things, because you're having to write code for each of those 100 things.

The "Changes in code shouldn't break the save" is the biggie. You can write general-purpose code to serialize an object hierarchy; that's a non-trivial but solvable problem. But then you're tied to that object hierarchy. Any change will render a game save unusable.

To get around that, you need to take a complicated object structure and find a way to describe its state that's independent of the object structure. You need to write code for each item on that list telling the system how to pick it out of the object structure, and code telling it how to put it back. Oh, and that code will change as your object structure changes as well, so if you don't want to wait until the rest of the game is finalized to have a save system, you'll have to re-write it as you iterate on your game design. Since each game is mechanically different- even if it's using a stock game engine- there will be things that need to be saved that have no general pattern that the computer automatically knows how to interpret.

Example: You've got a space RTS, and you need to store a planet in your save file. The planet has 100 iron ore and 200 copper ore. Right now they're stored as integers, but later on you might have a 'resources' object that contains all of the planet's resources. A general case serialization algorithm won't automatically turn those ores into a resource object from an old save game after your code has changed, so your planet class needs to do the work itself, requiring both a new constructor and a new method for pulling that data back out when it's time to save. Then you need code that tells your game-state builder that this data represents a planet, and that it should create a new planet, use that constructor, and add it to the list of planets in your galaxy. Then it needs to know to get that list of planets, call the method that gives it the data, and store it in the game save with a code that says "this is a planet".

This needs to be done for every class that your game state would touch. If you game has 1000 different classes, you need to potentially write that code for each one.

Oh, and about databases? There are far, far more programmers out there building specific databases- where the difference between having 10 tables and having 100 is rather meaningful- than there are writing the code that actually executes the SQL statements where it isn't.

 

[Uristqwerty]

In the game engine, a lot of the individual bits of the level will refer to each other by the memory location that the data describing the other part is stored. Depending on the system, they can be up to 2 billion, 4 billion, or perhaps even 18446744073709551615.

When the game is saved, it has to go through all of the parts of the level that matter, and write them to a file. However, the OS will not guarantee that the game can use the exact same memory locations when it loads the game later. (This is complicated, especially on windows where a DLL may be loaded into the game process some times but not others, limiting what memory addresses may be used for game data).

So, perhaps you have a turret at memory location 0x27ffff38d1aa9c10. To store it in a save file, you need to uniquely identify it. Some game engines already give each object a unique identifier, but perhaps this one doesn't. So, we'll give it the identifier 0x07f2 (turret) 001b (number 37). Now, every time an object is referring to 0x27ffff38d1aa9c10 while we are saving it, we instead write 0x07f2001b to the file, and then do the reverse when loading (except now it's at 0x36ffffe1d7a99250).

This sort of translation between in-memory identifiers and in-savefile identifiers needs to be applied for every single bit of game state that needs to be saved, of which there is far more every year.

Older games may have done something simple like say "there will never be more than 256 bullets in the gameworld at a time, so we will set aside a list of 256 bullets, and always refer to a bullet by its number", then directly write out a list of 256 bullets into the save file, most of which are not being used. If it was an especially old game, it might even set aside memory addresses 0x2100 to 0x26ff for storing bullet data, and have been able to guarantee that memory will always be there.

Newer games are more likely to use a higher level language where it is not even possible to know what specific bit of memory is being used for an object, which may or may not complicate the saving process more.

 

[GoldenShadow]

I've always been a fan of the save station room in Metroid games. Super Metroid and Metroid Prime(3D equivalent) both let you save when you needed to stop playing, but you have to go to a save room first. This lets you save sooner than progressing in the game to reach the next checkpoint. And it avoids save scumming that develops from quicksave. The Metroid games in particular are easy to save because only a small amount of information is required for the save file.
Which items you have collected, which bosses you have defeated, which rooms you have explored(for the map), which missiles doors you've blasted open.
I think Batman Arkham Asylum did the same thing, but instead of save rooms, it just auto saved when you load a new area or collect an item.

 

[Bad Jim]

I call bullshit. Game development budgets have increased enormously while game complexity has not.

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.

It's possible to write a generic script to do all the object specific coding for you from the class definitions. That's assuming your programming language doesn't support introspection, in which case it's even easier. And it would work on arbitrarily complicated data structures, just as mark-and-sweep garbage collectors work on arbitrarily complicated data structures.

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.

Well you've got me. No programmer is going to find a way to represent the game state in a way that doesn't tie too closely with the way he has represented the game state, that nonetheless allows replicating that game state exactly. Certain kinds of code change will inevitably necessitate writing a save game converter of some sort or leaving old save files unsupported. That said, I do not believe that changes to data structures are common enough after release to be a killer argument against saving anywhere. Data structures should be more or less set in stone at the alpha stage.

 

[BloodSquirrel]

In the game engine, a lot of the individual bits of the level will refer to each other by the memory location that the data describing the other part is stored. Depending on the system, they can be up to 2 billion, 4 billion, or perhaps even 18446744073709551615.

When the game is saved, it has to go through all of the parts of the level that matter, and write them to a file. However, the OS will not guarantee that the game can use the exact same memory locations when it loads the game later. (This is complicated, especially on windows where a DLL may be loaded into the game process some times but not others, limiting what memory addresses may be used for game data).

So, perhaps you have a turret at memory location 0x27ffff38d1aa9c10. To store it in a save file, you need to uniquely identify it. Some game engines already give each object a unique identifier, but perhaps this one doesn't. So, we'll give it the identifier 0x07f2 (turret) 001b (number 37). Now, every time an object is referring to 0x27ffff38d1aa9c10 while we are saving it, we instead write 0x07f2001b to the file, and then do the reverse when loading (except now it's at 0x36ffffe1d7a99250).

This sort of translation between in-memory identifiers and in-savefile identifiers needs to be applied for every single bit of game state that needs to be saved, of which there is far more every year.

The problems you're describing are general serialization problems. They can be solved, and solved with a general-purpose solution that makes the size or complexity of the object hierarchy irrelevant.

The real problem- if you'll refer to my posts on this thread- is that you need to save the game in such a state that changes to the game's code don't make old save games unusable.

Newer games are more likely to use a higher level language where it is not even possible to know what specific bit of memory is being used for an object, which may or may not complicate the saving process more.

That would be a property of lower-level languages, which are more difficult to use, not higher-level ones which are more likely to be used in newer games. But it won't matter, because the OS isn't going to let you just write to wherever you want in memory anyway. You might have been able to get away with that shit in DOS, but Windows 8 is going to throw your ass out on the curb for trying it.

 

[1337mokro]

So it's because people are lazy?

Thank you for that Shamus. I'm not being sarcastic, thank you for voicing that, it needs to be said that game design shortcuts exist and dilute the experience and convenience of the player for nothing but developer convenience.

Now just a single save slot is enough for me. Just one save slot where I can decide when to save the game. Because this happened multiple times during Bioshock Infinite (goddamnit that game is a plague upon my house) where I would want to quit the game, but it just wouldn't give me a checkpoint. I kept moving and moving and moving and the checkpoint only came after 15 minutes.

This is a horrendous design flaw where I seriously considered just throwing out all my progress because 5 minutes more and I would have been unable to leave in time. The difference between save whenever you want and save only when we want at bad intervals is night and day, but not every game needs the save whenever you want feature.

Just a well implemented checkpoint system will do wonders for most FPS. However try to pull that shit in a strategy game and be prepared to get raging fans.

 

[FFP2]

RPG's are much more polarized (you're either in combat, wandering, or in a cutscene), and during all of those, not much is going on really in a game like FF.
Also, what's wrong with Bioshock Infinite? I played it on xbox and had no issues. Was this a PC quicksave esclusive issue?

True... It's nice to have it on consoles though.

About Infinite: You can't manually save. And they don't tell you where the checkpoints are so you risk losing a bit of progress each time you exit.

 

[BloodSquirrel]

Well you've got me. No programmer is going to find a way to represent the game state in a way that doesn't tie too closely with the way he has represented the game state, that nonetheless allows replicating that game state exactly. Certain kinds of code change will inevitably necessitate writing a save game converter of some sort or leaving old save files unsupported. That said, I do not believe that changes to data structures are common enough after release to be a killer argument against saving anywhere. Data structures should be more or less set in stone at the alpha stage.

You're underestimating how small the change needs to be. If you add a single variable to a class, then a general-purpose serialization scheme is going to throw an exception and not give you your object.

For a practical example; consider Minecraft. Consider how radically that game has changed over the years without rendering old saves useless.

 

[AlexMBrennan]

That mountain of data that allegedly makes creating arbitrary saves quickly hard is already stored in memory. File system snapshots (LVM, zfs) are common place, so I don't see the why applying the same to memory is suddenly an impossible task - just create a snapshot of the relevant game data, copy to disk and then delete the snapshot.