Why We Have Checkpoint Saves

 Pages 1 2 NEXT
 

Why We Have Checkpoint Saves

Letting players save whenever they like can be a technical nightmare.

Read Full Article

But that still doesn't explain why PC games are famous for having save-anywhere features. I feel like I'm missing a page.

Seems like if you just prevent the player from saving in combat (like a lot of games do), you solve plenty of these issues.

And even after all of this, I still can't forgive Bioshock Infinite's abysmal save system.

sid:
But that still doesn't explain why PC games are famous for having save-anywhere features. I feel like I'm missing a page.

Same.

And what about the possibility of making a save game that sets things back to semi-default? It doesn't track every single effect, but reloads the game with characters in approximate positions (dead enemies removed) and reverts to basic AI; they see the player and switch to battle mode.

I know it's not perfect, but I think it's less back-breaking to make, and most players won't care if such a small crutch is used.

sid:
But that still doesn't explain why PC games are famous for having save-anywhere features. I feel like I'm missing a page.

Probably because save-anywhere appeared on PCs before things were quite so complicated, so now it's an expected feature, and developers risk pissing off customers if they don't include it?

I especially hate when PC games don't allow you to save on demand. Also, if bug-prone shops like Bethesda can pull it off, then there's no excuse!

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.

Tohron:

sid:
But that still doesn't explain why PC games are famous for having save-anywhere features. I feel like I'm missing a page.

Probably because save-anywhere appeared on PCs before things were quite so complicated, so now it's an expected feature, and developers risk pissing off customers if they don't include it?

When are you referring to? Like back before Wolfenstein 3d? I'm not sure there has been a massive change in the number of things to track since Half Life. Having better graphics doesn't increase the number of things to keep track of.

Clovus:

Tohron:

sid:
But that still doesn't explain why PC games are famous for having save-anywhere features. I feel like I'm missing a page.

Probably because save-anywhere appeared on PCs before things were quite so complicated, so now it's an expected feature, and developers risk pissing off customers if they don't include it?

When are you referring to? Like back before Wolfenstein 3d? I'm not sure there has been a massive change in the number of things to track since Half Life. Having better graphics doesn't increase the number of things to keep track of.

Well, the need to record physics objects happened. Also AI DID advance... even if not by much :( .
Still you are correct. I really like this feature and would love it if devs actually made use of it. There are few games where the lack of a save system is not really an issue/is kinda needed by design, but msot do not.

IF GSC game World can pull it of VERY well in their buggy games with not that great of a budget and great AI (It even works on maps the player is NOT), physics, great DX 11 graphics, large amount of objects, huge game world and large amount of other stuff, well no other AAA game should be able to say they cant.

the7ofswords:
I especially hate when PC games don't allow you to save on demand. Also, if bug-prone shops like Bethesda can pull it off, then there's no excuse!

The on demand saves are why Bethesda is so bug-prone. Hence the article.

One of my favorite things to read about are save game hacks, where modders will pinpoint what each part of a save file is actually saving and learn to alter it in order to create custom save game states. I think anyone who spends enough time gaming knows how complicated save game files have to be, but I also have never really had a problem with checkpoints as long as they're within reasonable distance of each other (I'm looking at you, first part of Borderlands 2).

Honestly, I don't see why more shooters don't do the Kingdom Hearts thing, where the game recognizes two states of being in combat and out of combat and only allows you to access menu options when out of combat.

Wow. Had no idea it was so complicated.

But . . .

sid:
But that still doesn't explain why PC games are famous for having save-anywhere features. I feel like I'm missing a page.

Yeah . . .

I mean, Half-Lif 2, as an example. Some really cool visual effects (lighting, physics, animations, etc.) and some tremendously smart AI, and it still has - to my knowledge - almost flawless quicksaving. Is it just engine/game optimization? Is is just the Source engine?

If I have to defeat all the enemies in an area to save, or go to a specific "safe zone" which I know the location of in advance to save, that's fine. But not knowing when I'll next be able to turn off my system without losing all my progress- that's just bad design, frankly.

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.

I think if there were a sufficient amount of save spots where you could save or if you'd be limited to not save in combat (like most games do), this wouldn't be much of a problem.
Plus, games where you have some sort of skill system that encourages playing a game in a completely different way/class should have manual saves... I love replaying games that allow me to play in a different way by skilling my character (melee, ranged, mage...) differently. But not if I'd have to replay the whole 'newbie' part of the game (where you can't really specialize anyways) again.

Shamus, I'm glad that you exist. Furthermore, I'm happy that The Escapist scooped you up. Finally, I'm pleased that you're able to articulate these concepts for microbiologists like me to understand.

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.

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.

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.

rembrandtqeinstein:
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.

sid:
But that still doesn't explain why PC games are famous for having save-anywhere features. I feel like I'm missing a page.

It's a good question. Making a save on one system shouldn't be any harder than on another, so I'm tempted to assume it's all due to expectations and conventions: PC players expect save-on-demand, and console players are okay without it. So PC devs put in the extra work and console devs sometimes let it slide.

That's just a guess, though.

I believe the technical hurdles, but frankly, this reason doesn't work.

Exhibit A: The Unreal Engine 3. You know, the engine which pretty much everyone uses these days? It supports everything you need to quicksave.

Exhibit B: The old games. Like, I dunno, the original Quake engine. Or Quake 3. Neither of them were even meant to support complex single player games, but they both had save/load functionality. And they worked great. Many engines of that era were like that - pretty much implementing the save/load thing more like an afterthought even when it wasn't needed. Also see - CryEngine (Far Cry) where you had to 'cheat' to get quicksave/load using console commands. And yes it worked great. My point is - apparently it's not THAT difficult to implement.

Exhibit C: Checkpoints can be done in 2 ways. Either "just respawn player at this location with stuff reset to default" (or maybe store ammo, health etc.) or "save everything". Again, many games use the 2nd option, so when you restart a checkpoint, you can pretty much have a rocket flying your way. In the latter case, there's no point to NOT offer custom saving.

Actually, apart form the technical difficulties, I see only 2 reasons NOT to provide the option to save anywhere:

1) Convenience - if the checkpoints are well placed, there's little reason to bother the player. Also, gamepads don't really have F5 and F9 keys.
2) Pacing - the game designer might place the check points deliberately. See Spec Ops: The line where you can't easily go back after you made your choice. Or some games which are deliberately difficult (Dark Souls or something, I think?)

I for one had a lot of fun with Max Payne, Splinter Cell, Crysis etc. where it was fun just trying out stuff after quicksaving. On the other hand, I don't see much point in save/load in something like Prototype.

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).

Though for SOURCE, CryEngine, PATH4 and RAGE-Engine based games that means that that would actually be doable. Considering we can buy terabyte hard drives for cheaps now, you'd just need a warning message saying "Attention! This save file is going to use up X MB. Continue?" so that people actually know how big their save files are (so that they don't wonder too much when their HDD is suddenly full when they save scum).

The system most open world games use is similar to a checkpoint system though, with most of the games barely even keeping track of your position. The system Bethesda (Gamebryo & whatever Skyrim is running on) games are using is similar to what you said, but the save files don't keep track of neither animations nor AI or anything like that. You've got "item XY has had its placement modified. Now at position XYZ", "player is at this location on map: XYZ2" and "NPC killed: X" followed by all other killed NPCs, and then statistics.

On the subject of free saving on consoles: most console game don't seem to need it for whatever reason and are most of the time actually made to be enjoyable without it. See the checkpoint system Crysis 2 uses, where you're never really spawned awkwardly or anything like that. Other good examples: Bioshock Infinite (checkpoints often enough) and Tomb Raider 2013 (checkpoints you at nearly everything you do). Come to think of it a little more, though... nearly all the games where I didn't feel that free saving was needed were linear games, not nonlinear or open-world ones.

the7ofswords:
I especially hate when PC games don't allow you to save on demand. Also, if bug-prone shops like Bethesda can pull it off, then there's no excuse!

Well, actually they didn't. Remember the whole thing with PS3 Skyrim being unplayable on on save games with 100+ hours playtime?

Personally I was a big fan of how Bioshock Infinite handled save games: quitting the game would set you back to a checkpoint, dying would merely play a cutscene, heal up nearby enemies, and then restore your health.

The main advantage of that is that it allows you to have dialogue / scripted events just after a checkpoint, without potentially forcing your players to sit through them a million times as they repeatedly die just after.

Honestly, there should be a special circle in hell reserved for game devs who combine checkpoints, unskippable cutscenes, and tough bosses - in that order.

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).

BloodSquirrel:

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.

Matthi205:
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.

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.

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.

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.

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?

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.

FFP2:
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?

mascotbeaver:
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.

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.

rembrandtqeinstein:

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.

Clovus:

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.

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.

 Pages 1 2 NEXT

Reply to Thread

Log in or Register to Comment
Have an account? Login below:
With Facebook:Login With Facebook
or
Username:  
Password:  
  
Not registered? To sign up for an account with The Escapist:
Register With Facebook
Register With Facebook
or
Registered for a free account here