# Is there a game-design related reason why games with checkpoints don't implement "save on exit" as well?

This seems like a common question but I couldn't find it anywhere. Please excuse me, if this is a duplicate.

EDIT: After receiving the first answer I realized this is too broad of a question. It does make a lot of sense to always restart from the start of the level in genres I wasn't even thinking about when writing the question. My question specifically relates to open-world/metroidvania games. Examples of the games I played that relate to this problem would be Hollow Knight, Legend of Zelda games for 3DS (including remakes), Castlevania series, Metroid series, Ori games (in "The Blind Forest" you still get warped, but to a player-set checkpoint).

As an example of a game that does what I see as a better option, Shining Soul II allows the player to save at any point in a dungeon. After saving, the game automatically turns off and upon reentering, spawns the player character at the beginning of the level where they saved and that mid-dungeon save gets destroyed.

# The problem

In a game with checkpoints, after exiting and loading back a game one of two things can happen: either the player is warped back to the last checkpoint or the player is placed back more or less where they left with the same amount of health/mana/ammo/whatever as when they quit the game. Yet for some reason every game I played that implements checkpoints always implements the first and not the second option.

From the development standpoint, I can understand that the first option is easier to implement. But from game design standpoint this doesn't make sense to me for several reasons.

# Why I believe auto-save on exit is better

First, it's a hostile design. If I need to stop playing right this moment and cannot continue, all my progress is lost for a reason not related to the game itself. In theory, checkpoints are meant to create a pace for the game, the difficulty spikes between one checkpoint and another are carefully designed to create the best experience for the player. For that reason, in a well designed game, players would rarely stop playing mid-checkpoint even if their progress was saved, because they would lack the sense of completeness that comes from reaching the safe spot. Implementing auto-save will not ruin the pace but add player agency for those situations when they absolutely cannot continue or remove the need to continue under stress, because they are needed somewhere else ASAP. Personally, I find it less frustrating and unfulfilled to just turn off the game without completing an objective than rushing to the next checkpoint and dying in the process, getting even further behind.

Second, this grants a hidden ability in the game, that allows the player to warp to the last checkpoint at any moment in the game. While not obvious to most players and somewhat cheesy, once the player realize they can escape any situation, they will eventually start to abuse it. This can happen if the threat of dying is so much worse than inconvenience of restarting the game, for example in Hollow Knight, at first I considered bench warp to be an exploit but when I played Steel Soul and not exploiting this mechanic meant loosing 4 hours of progress, I too started abusing it.

There is a good reason, why the ability to warp to the last checkpoint without dying is important. It allows the player to quickly disengage from challenges they are not yet prepared for. It prevents soft locking if there are bugs in the game (either mechanical or in level design) and the player can get stuck because of them. But if this mechanic is so ubiquitous and important to this kind of games, it would be a much better design to make this an in-game ability of the character, not force the player to access that ability from the game menu. If the recall ability doesn't fit the game in-universe, I would still consider explicit menu option to go to the last checkpoint better than quitting the game and loading again.

Imagine if in League of Legend in order to teleport to the fountain the player would need to close the game and load it again instead of using the Recall ability that every player has. That would be absolutely ridiculous. Yet in single-player games for some reason this is a norm and I don't understand why.

Some games do have the "Restart from the last checkpoint" option in game menu but for those games the first reason still applies.

# The question

Considering the reasons above, why is it that warping on restart is so much more common than auto-saving on exit? Is there something I'm missing here that makes the more common approach better than what I believe makes more sense? Considering I have the technical abilities to easily implement the save system I prefer, is there any reason why should I follow the industry standards?

• But, aren't checkpoints some sort of auto-save feature? Or, are you talking about good ol' manual game saves? Aug 31 '21 at 9:34
• @liggiorgio I'm talking about automatically saving the game-state on exit and loading that save automatically when returning to the game. Almost all games with checkpoints instead of freezing the world on exit, warp players back to the last checkpoint and I don't think this is correct. In example I gave, "Shining Soul II", when loading the game player has a choice of either continuing the dungeon or returning to the castle and for me that is a much better alternative. Give player a choice. I asked this question because if the "worse" way is so common, I want to know a reason why. Aug 31 '21 at 11:09

I think Tooster's answer covers most of the important points, but I do want to elaborate on a couple of details.

## Maintaining Flow

This builds on Tooster's references to "context" that can be lost between play sessions. When I quit a game, I might intend to come back to it in a minute or an hour. But in practice, sometimes it will be days or weeks in between. During that time, my memory of where I was and what I was doing, and even my skills in the game will atrophy.

In Metroidvania and Zelda games like Reverent Lapwing describes, sections of the map will often be designed around a theme. Introducing a new element (like a new enemy, obstacle, player ability, or strategy), then developing it over the course of several challenges/rooms/waves, twisting it by juxtaposing it against previously-introduced elements, and finally culminating at a boss fight or major test that lets the player show off their mastery of the new skill.

When played through in one session, this creates an enjoyable progression - your understanding and skill in dealing with the new ingredient grows, parallel to the escalation of the challenge. Designed well, this facilitates the player in finding a "flow state" that can be very engaging.

Dropping cold into the middle of this flow, however, can be quite painful. I've forgotten what trick I needed to navigate this area, or I've lost the particular timing that I'd practiced in the previous room due to the time spent away from the game. Instead of a feeling of flow, I find I'm bashing by head against the wall just trying to get back up to speed.

In a scenario like this, starting the player back at the checkpoint can be a mercy - giving them a chance to practice the early challenges again and pick back up the thread of what they were doing. This is even more true if the reason they ended the last session was because they got stuck - a chance to practice the early lesson again is often all they need to unstick themselves, but they won't get that if we spawn them back at the part that frustrated them into quitting.

Meanwhile, the impact on a player who did learn and retain the skill is (if the checkpoint frequency is well-designed) relatively mild. They can breeze through the early parts of the challenge with their already-developed skills, maybe finding it at worst dull for a couple minutes until they get back to the novel part. If you have great 3Cs, then even fighting your way back to where you were should still be pleasurable - if it's not, then you have deeper problems that skipping the replay only partly masks.

## Preventing Soft-Lock

Reverent Lapwing touches on this in the question: if you spawn the player at a checkpoint, you can guarantee the game is playable and winnable from every possible spawn point. Generally speaking, we cannot make this guarantee for every possible game state that can arise at runtime and get snapshotted by a background auto-save or save-on-exit feature. In a game of even modest size, there are enough possible interactions between mechanics that it basically reduces to the Halting Problem.

I recently worked on a AAA open world game, and the variety of navigational tools and explosive mechanics open to players meant there were plenty of opportunities to get hurled out of the ordinarily-navigable area and get stuck somewhere. If we spawned you back at the exact position where you quit, then these would become walkthrough breaks. Even though they were exceedingly rare, even a one in a million chance means it happens to tens of players if you sell tens of millions of copies. So instead, we always snapped the player to the closest "known good" spawn point, of which we had a reasonable number that we could exhaustively verify.

The chaos that can be introduced by an overly-faithful save system can be even worse during development of the game. Let's say I'm doing a test of "chapter 2", and I'm halfway through at the end of the day, so I save and log off, recording my exact position. The next time I get a chance to continue my test, I'm working with a slightly more updated build (which is good - fewer bugs, right?), not realizing that yesterday the level designer checked in a change that raised the floor 1 centimeter. Now my save file - which has recorded the exact position where I should be spawned - places me under the floor and I'm stuck or fall to my death.

These kinds of changes are happening continuously during development, and having to create new save files for each test scenario or redo the test from scratch anytime something changes can seriously slow down development.

(Yes, we could fix this particular example by having the load system scan for a valid place to stand near the saved position, but that fixes only the one case, not the general problem, and adds complexity - something we'll get to shortly)

This can happen in non-buggy ways too, like being on the wrong side of a damaging obstacle with 1 health left, or in a boss fight with your ammo exhausted. We can say "oh, that's the player's own fault" and yeah maybe it is, but it's not necessary for the game to rub your nose in your mistake and force you to struggle in vain or kill yourself when it could have spawned you in a state it knows is winnable instead. Especially in cases like Tooster's Portal example, where the fact that they're in a dead end might not be obvious to the player.

As Reverent Lapwing points out, a workaround for soft-lock issues is to offer a "return to last checkpoint" option as a menu item or in-game ability of some kind, and I do think those are valuable inclusions. However, from observing playtests, I can attest that even when these options are present, players frequently miss them or forget about them, because they're not part of their routine play. So ensuring the player always starts a fresh game session in a winnable state can still improve the player experience and reduce negative reviews or customer service calls from frustrated players.

## Complexity

A checkpoint save system can be dirt simple. Upon entering a trigger zone, you save the character's current progression state (like XP/items/etc), and the ID of the checkpoint they're at, and that's all the information that you need to reconstruct this game state reliably.

The checkpoint location will generally be designed such that it has no other complicated state in its immediate vicinity - no enemy spawners, etc - so everything else can just be spawned "from scratch" as the player approaches, and there will be no visible or game-altering discrepancies.

A save that records you "in the moment" needs to contend with a lot more. Just about every feature you add to the game, the save system needs to be made aware of it in order to put that feature back into the right state on load.

Even simple things like moving platforms can be a can of worms. If you can save on a moving platform, then the position/phase of the moving platform (and other platforms you might need to jump to from there / hazards you might need to avoid) also need to be saved and synchronized with your load, so you don't spawn in mid air or in an unwinnable configuration. If you want to avoid this complexity by disallowing saves on moving platforms, then you need to save a bookmark anytime the player jumps or is knocked around just in case they might land on a moving platform and quit before returning to solid ground. Both ways have a cost. Multiply this by every other thing your player can do or have done to them. Alternate forms/movement modes, status effects, multi-stage enemy waves or boss battles, and especially any kind of exotic gameplay for a narrative beat or level design set piece.

These types of complexity can creep in unexpectedly. Say a level designer makes a room where you need to hit a series of switches in a particular order to open and shut doors, giving you access to other switches and other doors. You've probably played dozens of segments like this. The level designer doesn't know this needs special save handling - they don't know the guts of the save system, and other times they've used one switch-door pair at a time there were no issues. And the programmers working on the save system usually aren't playing every part of the map or attending every review, so they don't spot it either.

But a player who quits in the middle of the puzzle might come back to an unwinnable state - spawned somewhere in the middle, but with a door still in the initial state, so they can't reach the next switch. Worse, this kind of bug can go undetected, because any tester playing the puzzle through in one pass finds it works perfectly - it only shows up if the player quits at just the wrong moment.

This may seem like a contrived example, but at least one nasty issue like this has cropped up in every AAA game with an autosave system I've worked on, often being discovered months later, and always at the most inconvenient time to overhaul either the offending content or the underlying save system. We've had it arise from things as unassuming as loot containers or sidequest completion. The bigger the project, the more susceptible it is, because you have more cooks in the kitchen and it becomes infeasible for the save system programmer(s) to stay abreast of every change being made that might impact game saves.

Conceptually "snapshot the game on exit" sounds simple, but in practice it carries a heavier development cost.

## Priorities

You may object to the preceding sections, "but that's all solvable!" and yes, it is, given unlimited time to fix the problems or wisdom to avoid them all in the first place (and all the time needed to implement that wise robust solution).

Unfortunately, we work with finite time and finite wisdom. In practice, the more complexity there is in the save system, the more time and brain cycles your team will be spending on that complexity instead of other parts of your game.

Sadly, games don't get rave reviews about the quality of their save system. You could have the greatest feat of engineering under the hood, and players will only ever notice it when something goes wrong.

So sometimes, it makes more sense to make a simple, predictable save system that does one thing reliably (say, a simple contract with the player "when you load, you'll spawn at the last checkpoint you touched, with full health and ammo"), and spend the dev time and energy freed in this way on parts of the experience that get players more excited - like the 3Cs and combat mechanics, adding new bosses or new items and abilities, etc. (all of which become cheaper to create when you don't have to contend with every save contingency).

This is especially true if you're making a game that you expect will almost always be played in sessions that are one or more "checkpoint span" long. Respawning a player at the exact moment they left off might save an individual player some seconds or minutes of retracing their steps, but this will often have less impact on their appreciation of the game than say an extra hour of new gameplay.

## Wrapping Up

None of this is to say "Auto-save bad. Always use checkpoints." - both systems have their merits, but they also have drawbacks. If you were making a mobile game meant to be played in very short snippets that could be interrupted at any time and had very simple state considerations, then a background auto-save that puts you exactly where you left off might be a no-brainer.

For a designer, the challenge is to be aware of the trade-offs of each decision, and find the one that's right for the game they're making and the team/production practices making it. And then to design the feature and the features it intersects with in such a way as to capitalize on its strengths and minimize the frustration or risks introduced by its weaknesses.

• Reading "Preventing soft-locks" also reminded me about the "Fear of Missing Out" -- players are often more tenacious than other people, and they could see an option to "go back to the last checkpoint" option in a menu as losing the progress or opportunities. They could stubbornly try to repeat a soft-locked game save not even knowing about it. Their mentality could simply prevent them from ever clicking that button the same way it makes Skyrim players avoid using potions they hoarded. It's all about "The Loss". Aug 31 '21 at 22:28
• Wow, this is more than I ever could have wished for. The specific examples of problems that happened or could have happen during development are especially helpful. Now I see why making sure that checkpoints are never spread further than 5 minutes apart is so much easier than doing it "the proper way". It was a good idea to ask, I'd have never considered many of those issues. It could be easy to implement "respawn at beginning of last scene" in a game like Hollow Knight but after this answer I don't know if I even would want to do that from a game design perspective. Sep 1 '21 at 7:49

I think this is a bit too shallow of a viewpoint focusing only on the player's perspective. It would be better If you posted more examples of games doing it first and the latter way. It's hard to say about games "in general" because many games are unique and must be considered separately. I'm just gonna post my own thoughts. First from player's POV, then from producers and developers.

# Puzzles

Consider puzzle games. They are often divided into units - be it a level, location or a world. The way they are usually meant to be played is finding a certain solution from many possibilities. Those solutions depend on all the actions you take in a specific order -- one wrong move and you may have to start again.

Assume now that you are in the middle of solving a puzzle, but you got bored/had to go and quit the game. You come back later - an hour, a day or a week. Now you most probably lost the context of what you were doing. What if you took a wrong step at the very beginning and now you are stuck with what you perceive as "unsolvable" puzzle? You would probably think that the game is broken. But when a game forces you to start a level from the beginning you can make your context from scratch and solve it. I experienced it once in Portal (or some other game) -- I thought I was stuck, but in reality I was just quick-loading in a moment that already led to a dead end. So there you have your first reason in favor of checkpoint-warp -- regaining context of actions. By reverting to a checkpoint you can discover a completely new perspective on the problem.

# Platformers

For a second example let's take a platformer: N++ game (you can play an original free flash version in the browser). Game is divided into episodes, each consisting of 5 levels: 0 to 4. You play episode as a whole - you can't start level 2 of episode 5, you always play from level 0 to 4. Why? Let's ask the creators!

So what's the answer? To make players feel time pressure and give them this sense of epicness when they complete a run! It's all about emotions and feelings of a player. I highly recommend you give this game a try to understand what I'm talking about. The feeling of mastery that you get from completing an episode with time rapidly running out -- you have so much adrenaline pumping in you that you just want to keep playing it. It also encourages you not to give up - you will lose your progress if you quit now! This indirectly translates to game's statistics (replayability, session length etc.), which in turn translate to more profits and better player reception.

# MMO

Now let's take a MMORPG PvE/PvP game -- Tera. You can exit the game whenever you want... buuuut you get a penalty if you exit outside of town (at least that was true when I played it several years ago, idk if anything changed). Why does it do that?

My first guess is to discourage "evasion of fast travel tax" -- i.e. you would be able to travel back to last town from dungeon simply by reloging, and that in turn would mean that you don't have to use teleportation scrolls etc. which... translates again to real profits of a game (you don't contribute to economy).

Second guess: to make players stay longer - when you have to go back to a town just to avoid XP-loss penalty you are forced to make a trip and spend more time in the game. You can eventually encounter some new mobs, some strange location or engage more with community -- LOOK, SOMEONE IS SELLING RED-ASSED MONKEY'S RING FOR ONLY 2KK GOLD!!! WHAT AN OPPORTUNITY! GOOD GOD I DIDN'T LEAVE!!! Basically the longer you stay logged in the more they earn and you commit more to the game.

# Rhythm games, Bullet hells, race games

Imagine quitting in the middle of a song or shooting. Those games rely heavily on the context of a game - speed of song, speed of objects and their movement. You load the rhythm game in the middle - what's the BPM? You can't tell without starting or going back a little. You load bullet hell - what's the direction and speed of projectiles? What phase of a boss I'm now in? You can't tell without sampling a little bit of the past.

# Why FreezeTheWorld > Checkpoint

Now this in fact is a separate category of games -- Nuclear Throne, Enter the Gungeon, Noita, Minecraft, Factorio, Strategies, Board games, Storytelling games, actionless games. Here quitting the game is the only way to save it and you don't have checkpoints. The lack of checkpoints gives those games a feeling of a "single adventure". You learn to cherish the moment. You learn that actions have consequences.

@Edit "Freeze The World" (short FTW) type of save is a very early design decision that basically determines the game's direction. I see them implemented in games that don't create this "sense of urgency", but rather want to be a "one time adventure" -- always different, always changing.

Writing this I came to a conclusion, that checkpoints are used in games that focus on goals -- complete a level, complete a quest, solve a puzzle, finish something in the fastest time. FTW on the other hand are used mainly in open-ended games, where it's not a goal that is important, but the journey: Noita, sandboxes, simulators -- anything where you want your player to be free. If there are no strict goals then there is no way that you can determine checkpoints.

# From Developer's POV

It's easy. You don't have to write a daemon that runs once every x minutes and saves a game. You prevent game freezes and performance issues, because you don't have to serialize the whole game state.

Let's say you are in the middle of an epic battle with lots of bots. Serializing all of that data would take a lot of time. Loading it back would take probably twice as much. Have you ever been stuck in a quick-load loop in the middle of a difficult encounter, just because you can't feel the rhythm of keypresses? Saving only in save-zones, with few entities, enemies etc. is simple, quick and doesn't irritate the player.

Saving only in safe-zones can also help when developer publishes a patch to the game - you could get glitched if you load a patched location, or a location that due to an event is now completely terraformed. You could by accident bypass content that was added to the game. And if developers have to force you either way to the location entrance to prevent bugs - it's only natural that you already have checkpoint system in the game.

Checkpoints are also often placed in strategic places, where difficulty starts to ramp up. I imagine them as valleys on a sawtooth graph -- you start from lower difficulty and progress to higher difficulty. It works like a warm-up and reduces your frustration when you are stuck in a quick-load loop of a difficult situation.

Finally, making reliable "save-anywhere" system is hard - it should be used together with checkpoints -- otherwise you could get locked. What's the good moment to save a game? How often to save a game? Does this system require player to manually manage his savefiles? Save-anywhere to a player is like manual checkpoint placement - you have to remember to create them, how often to make them and you can make poor decisions that you could regret later if you saved in a bad moment (Say your last save was 4h ago and the next one is 5 minutes ago -- I've been there, done that and I don't recommend...).

# Final thoughts

Checkpoints are like chapters in a book. They establish pacing, give reasonable points to stop, divide story into coherent units and encourage you to read "just 5 more pages".

TL;DR:

• In puzzles - you would loose context or could get locked
• In platformers - you would loose the sense of urgency and adrenaline
• In MMOs - you would play less and generate lesser profit
• rhythm, race, bullethells - you loose sense situational awareness and fall out of "the zone"
• FreezeTheWorld saves teach that actions have consequences and determine game's direction. They are crucial to open-ended games.
• as developer - it's easier to make checkpoints
• as story designer - it's good for pacing and splicing story later.

Things you can check out:

• Excellent answer, but to clarify - the auto-save system I describe would run only on exiting the game and it wouldn't be possible to load that save ever again after entering the game. There is no daemon or "save everywhere" needed. Hollow Knight already has invisible safe zones where the game respawn the character after falling into acid or spikes. What I think would make more sense is respawning in such zones after restarting the game rather than back at the checkpoint. For example Shining Soul II after restarting spawns player at the beginning of the stage of the level where they left. Aug 30 '21 at 16:02
• @ReverentLapwing I changed "Roguelike" section to "FreezeTheWorld" and added some thoughts based on your clarification. Also consider giving a +1 if you like my answer :) Aug 30 '21 at 17:19