Why We Have Checkpoint Saves

 Pages PREV 1 2
 

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.

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

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

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

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.

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.

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

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.

mascotbeaver:

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.

Bad Jim:

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.

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.

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

You can version the save file and load it with the old code. In that case you just get the old data structures but the new variable is undefined. You may then have to figure out a way to define it, depending on what it does and how it works.

I never thought that it was a technical issue, but an artistic one. The PC/console discussion would be framed as "PC users like games where they're at the controls of a game world that's theirs, going so far as the keybindings and when they can save (and mods, etc.)" and "console users want to sit on the couch and be given a hand-tailored experience where all the 'behind the scenes' stuff is handled for them". There's obviously exceptions, and for PC minded games moving towards the console, quicksave was replaced by having to press start and hit save in the menu. This discussion we're having recently seems to be from console-minded developers porting to the PC, and keeping the checkpoint system intact.

For Bioshock: Infinite, what that all boils down to is that Irrational wanted more control over the experience. Moving in a more tightly controlled, artistic direction for the series meant that they didn't want the player saving wherever the hell they wanted and messing up the experience (the experience Irrational wanted them to have, not the player's own). You were experiencing their beauty, not taking their beauty and deciding when it was supposed to hit intermission.

I'm merely speculating and could be entirely wrong about all of that, of course.

Meeting half-way: No-save zones (such as combat situations where the amount of complexity skyrockets).

sid:
But that still doesn't explain why PC games are famous for having save-anywhere features.

Maybe because save-anywhere features are more common in strategy games than anywhere else, and strategies are more common on PC than console? Just a suggestion.

lacktheknack:
Meeting half-way: No-save zones (such as combat situations where the amount of complexity skyrockets).

That gives you the worst of both worlds. There's little advantage to saving outside combat over regular checkpoints and it won't be much easier to program.

Shamus Young:

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.

It's also worth noting that save-on-demand (SOD?) is going away. In fact, when I saw this article title, I figured it was inspired from people noticing how Bioshock: Infinite is pure checkpoints; even on PC. Both Borderlands games are also checkpoint-based, but it's a bit smoother since it'll usually save your data as you quit (and tells you when it won't); though you still load at a checkpoint.

Shamus Young:

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.

Now I find myself searching around to see how accurate the assumption even is. I mean, QTE games ala Uncharted are usually meant to be played in chunks, not with the amount of freedom that something like Fallout would warrant. It's understandable from the perspective of God of War or Lara Croft seeing as they're more of a movie than a playground most of the time. Those games are found in Consoles mostly. Games like Starcraft or Sim City, however, would be thrown completely off-balance by an inaccurate save file, and would provoke some pretty heavy sighs if all they had going for them was checkpoints. I guess if you were to point the finger at anyone, it would have to be the Hollywood-esque triple A market that seems to take care of consoles, as they wouldn't have any use for specific saves in the first place.

Either way, I think it's pretty safe to say that checkpoints are only really an issue in games that could really benefit from local saves. Imagine playing Fallout New Vegas, except every load leads directly to the Lucky 38.

Anyone else notice the large difference between his profile pic and his updated pic?

Just sayin'

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.

Yeah, that's what I'm not exactly getting. It's a lot of shit when you write it down but it's not like some poor fucker is doing it by hand every time someone saves.

To be honest, I'm fine with save-anywhere outside of a combat scenario, but coming from my position of utter ignorance on the subject, I'm not really buying this. It's not like games have grown an order of magnitude more complex over night.

The obvious way out, of course, is to have both save anywhere and checkpoints, so you can start playing from where you left off but if you fuck up (or the game glitches up) you have the chance of restarting.

The harder, less obvious less out is to have checkpoints plentiful enough that the amount of playtime lost never feels significant.

The Real True One Way Out is to play only roguelikes, forever.

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 are manually writing this stuff down. Someone has to design every bit of code that will make it work and then they have to QA and bug correct that code. They have to make the memory requirements correct, they have to make it functioning within the game systems, they have to keep the saving time down to a reasonable level. And the point is that's a non-trivial amount of time and effort

WhiteTigerShiro:
It's also worth noting that save-on-demand (SOD?) is going away. In fact, when I saw this article title, I figured it was inspired from people noticing how Bioshock: Infinite is pure checkpoints; even on PC. Both Borderlands games are also checkpoint-based, but it's a bit smoother since it'll usually save your data as you quit (and tells you when it won't); though you still load at a checkpoint.

On the latest podcast he was doing someone got onto the subject of (not having)autosaves as a relic of old bad design features and offhandedly called a developer lazy for not having quicksaves in combat if they have them out of combat and I think that's probably what inspired this particular article

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.

It took absolutely forever to create a new save file though. I've never seen a game take so long just to save something in another slot. There was obviously something very complex going on in the background

Aye, I was rather miffed to have had to pretty much untimely, suddenly, immediately quit playing Bioshock: Infinite three times, without having an option to save my current progress, sending me back between half an hour to almost an hour on my next session. I did not like that.

Funny how Dark Souls, a game that's been considered to be so utterly unfair to the uninitiated, lets you just quit the game and saves everything just nicely, without any punishments or repercussions whatsoever. At first, I was terrified of the Save & Quit option. Remembering what, say, Fallout 3 did to my save games and my data, I was wary, to say the least. But Dark Souls handled it just nicely, even throwing in some surprisingly nice advantages into the mix (Bed of Chaos, anyone?)...

Meh; I simply do not buy it. It's a design flaw, and will remain so.

But if you Have to do checkpoints, have LOTS of them. There is nothing more annoying than to have to battle the same idiots and watch the same cutscenes for 15 minutes before a bossfight, then get killed immediately and have to do it again. And again. And again.

Bioshock Infinite is the one that springs most immediately to mind; there can easily be half an hours playtime between savepoints in that; way, way too long.

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!

Difference between possible and unnecessary expenditure when they could fix a few bugs or better balance a section of the game with that budget instead.

Also, some people here stating 'take it back a bit and simplify it' are essentially saying 'checkpoint it!' as that's the last time it was simple, and doing it anywhere near combat gives it the potential to break the game.

I agree too, Bioshock: Infinite's save system is terrible, with 15 minutes between the earlier checkpoints at least.

i quite liked the way stalker saves worked. im not sure if this was intentional or just an accident.

say you are in a building with 2 doors and a few windows you 4 guys show up and you are a gonner so you reload and crouch down behind some cover waiting for them to burst through the door again, but they dont maybe only one person shows up and the rest come through the other door. there always seemed to be differnt reactions.

i dont know if this was a shortcut in the saving process as all npcs were saved where they were but not what they were doing so had to work out what they needed to do again and didnt carry on the same path as before but it always added a nice random feel to things that even if you did save all the time you didnt really know what was about to happen so a hard area was still hard just in a differnt way.

It's a great argument for disallowing saves in combat. But what about forcing checkpoint saves when not in combat? Many of the games I have disallow saves in the middle of combat for just the very reasons outlined. But then allow them again once combat is resolved. Someone above said that they felt like a page was missing from this piece. I concur.

EyE: Divine Cybermancy had a weird saved game system. If you die, you lose a life, wait ten seconds, and respawn exactly on top of your old corpse. Lose all of your lives, and you get sent back to the mission hub with a message stating that what you just experienced was actually a prophetic dream.

Another twist would be a mechanical respawn system like in Borderlands or System Shock. Die, and you respawn at the nearest Respawn Machine. But enemies also tend to either respawn or else filter in from other areas. So if we turn the game off, come back to it later, and respawn, it's easy to imagine that some time has passed and the game world's natural respawn has had time to kick in.

Both of these techniques make it unnecessary to show a loading screen every time the player dies, and make it feasible to reload the entire map from scratch when the player first starts playing or enters the area. They can also both sort of be seen largely as multiplayer death systems re-purposed for single-player.

Contrast with a game like Fallout 3, where yes, every single object in the game world (at least in the current area,) is part of the saved game file. Some PC games even use Object Serialization to LITERALLY stuff game objects into the save file, but this is generally regarded as a suboptimal use of disk space, even on PCs.

Headdrivehardscrew:
Funny how Dark Souls, a game that's been considered to be so utterly unfair to the uninitiated, lets you just quit the game and saves everything just nicely, without any punishments or repercussions whatsoever. At first, I was terrified of the Save & Quit option. Remembering what, say, Fallout 3 did to my save games and my data, I was wary, to say the least. But Dark Souls handled it just nicely, even throwing in some surprisingly nice advantages into the mix (Bed of Chaos, anyone?)...

Dark Souls performs the best kind of trick: it makes you think it is constantly saving everything, when it really isn't saving much of anything except the world state. If you reload your game, the player and enemies will be completely reset except for their last saved position, and you can't reload into a boss battle at all (it will reload you just before the boss door). Careful level design minimizes the number of enemies with canned animations so they don't break the system. For example, the enemy who closes the door on you in the Undead Parish is invincible while he's closing the door, and the door closing triggers an immediate autosave.

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.

BloodSquirrel:

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.

BloodSquirrel:

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.

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.

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

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.

 Pages PREV 1 2

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