Forgot password
Enter the email address you used when you joined and we'll send you instructions to reset your password.
If you used Apple or Google to create your account, this process will create a password for your existing account.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Reset password instructions sent. If you have an account with us, you will receive an email within a few minutes.
Something went wrong. Try again or contact support if the problem persists.
Escapist logo header image

Why We Have Checkpoint Saves

This article is over 11 years old and may contain outdated information
image

I’ve always been a big fan of being able to save and load the game at any time. I hate that feeling where I’m done with a game and want to take a break, but I have to keep playing because I have to reach the next checkpoint before I can safely quit. I also hate when the game throws an aggravating quick-time event at me and I have to stop enjoying the game so I can play this half-assed Simon Says while a cutscene plays in the background. When it’s over, I want to save right away so I’ll never have to do it again.

Years ago we were told that PC games have save-anywhere features and consoles use checkpoints because consoles just didn’t have the storage space available. This excuse was probably true in the PlayStation 2 era, but it’s become gradually less plausible since then as consoles have gotten fatter hard drives. I think everyone has figured out by now that we have plenty of space to store all the save games we could ever want.

An argument can be made that save-anywhere is unbalancing and leads to playstyles that make the game less fun. If the player saves the game in an unfortunate state (low health, low resources) then they could spend half an hour slamming face-first into a hard fight instead of spending a few minutes reloading a checkpoint from slightly earlier when their resources were in better shape. Excessive saving and loading might cause players to overcome systems with save-scumming instead of mastering skills they will need later in the game.

But even in cases where it’s not a balance problem, we still don’t get save-on-demand. Why is that? Are game developers just jerks? Do they hate fun and want to waste our time?

No, obviously. The truth is, the reason we’re not seeing more save-on-demand in games is annoyingly mundane: It’s hard to do it right. Save games are a concept that can seem easy but can get to be very complicated, very quickly. If we’re saving the game whenever the player wants? Like, in the middle of a firefight? Well …

In the save file, you (the programmer) need to save the state of everything in the gameworld that might have been altered directly or indirectly by the player and that is still relevant. The list of things that fall into this category is alarmingly large.

We need to keep track of where the enemies are, how much health they have, and if they’re actively engaging the player in combat. And if we’re doing that, then we need to save the AI state of every bad guy in the area. It’s not enough to remember that bad guy was behind the row of crates, heading east at a sprint. We can’t trust him to pick up where he left off because he doesn’t know where he left off. We need to record where he was going, what path he was taking to get there, and what he was going to do when he arrived. In extreme cases, this might mean saving a halfway-complete analysis of the local area using an A* search. We need to save all the paths the bad guy had considered, which paths it was favoring, and what routes were left to search. We need to save what they were doing at the moment of the save – running, shooting, throwing things, recoiling in pain, reloading, taking cover, etc.

But wait, there’s more!

It’s not enough to keep track of the positions of the bad guys. We also have to keep track of their animations. If the enemy is 50% of the way done reloading, or in the middle of vaulting over cover, or standing up to throw a grenade, then we need to save the current state of every animation being carried out by every active bad guy. Also, don’t forget to save the current state of the sound effects. I know I’ve seen more than one game where saving in the middle of a turret section would result in the player having a perfectly silent turret when they reloaded the game.

But wait, there’s more!

We need to save the state of every single physics object in the area. Have any objects been destroyed? What objects are moving through the air? What about the explosive barrels (federal law prohibits the creation of shooters that don’t feature 50-gallon drums that are painted red and detonate effortlessly even though their weight suggests they’re empty) that are scattered around the scene? Are any of them getting ready to blow? What about grenades, breakable crates, moveable objects, and destroyable scenery? We need to save all of that. We need to save not just the trajectory that a grenade is following through the air, but who threw it, because we need that information so the friendly-fire mechanics can work properly.

This is a ton of data to save, but there’s still more!

We need to keep track of which items have been picked up. We need to record the cooldown of special powers, particle effects in progress, the state of combat taunts, what’s going on with the vehicles,

All of this represents a huge, complex block of shifting data. Saving that data and then restoring the state of all of those disparate systems is a difficult and error-prone task. And when you do make mistakes, they can create bugs that are very strange and hard to unravel. If you’ve been playing games for any length of time you’ve probably seen a few load-game bugs: Bad guys that stop participating in the fight, weapons stop making sounds, physics objects that freak out, objects that vanish, and other randomly glitchy things.

The problem is, it’s incredibly time-consuming for a QA team to locate these bugs. “Oh, after three days of trial-and-error, we finally discovered that when you save the game while a companion is boarding the jeep and the player is reloading at the same time, that save game will cause the turret to not work when the save is reloaded.”

On the other hand, you can avoid all of this work and QA hassle if you just make the game have a bunch of one-way doors that do a simple checkpoint save when the player passes through. In this case, we just need to record which particular checkpoint the player is on and what resources they have. If this is the rare game to allow backtracking, we might need to keep track of who the player has killed. (Although sometimes they don’t bother. I’ve seen plenty of games where re-loading a save brings all the bad guys back to life.)

Given how difficult and expensive it is to make on-demand saves, and given how trivial it is to make checkpoint saves, it’s generally easier for developers to just leave out manual saves and blame it on hardware or game balance.

I’m not saying a robust save system isn’t worth it. (That depends on who you ask.) But I hope this makes it clear that this simple feature can be a lot more complicated than it seems at first glance, and maybe it’s understandable that so many developers take the easy way out.

Shamus Young has a blog, a book, a podcast, a webshow, and a background in software.And also a family.

Recommended Videos

The Escapist is supported by our audience. When you purchase through links on our site, we may earn a small affiliate commission.Ā Learn more about our Affiliate Policy