Friday, January 13, 2012

The Save Scumming Problem

Save systems are tricky business.  No matter what kinds of games you play, chances are you've run into at least a few that don't work quite the way you'd expect or prefer.  Whether it's checkpoints and autosaves, quicksaves, the number of save slots, free saving versus limiting saving, or even limited save numbers, the ways in which a save system can influence how players navigate the challenges of a game is often given less attention than it deserves.  There are a lot of conflicting beliefs about what differentiates a good save system from a bad one, especially as many players have very different standards; some like the tension that checkpoint saves provide, while others are adamant that saving should be as convenient as possible.

One thing that most developers and players do seem to agree on, though, is that save scumming can be a major problem, at the worst of times outright removing the challenge of a game entirely, and undermining the finely-tuned game rules and mechanics that the developers spend so long perfecting.  There have been a number of different attempts at solving the save scumming issue, but few have been sure-fire solutions and fewer still haven't had drawbacks.  In this article, I'd like to take a close look at what save scumming is, the different ways it can be combated, and to evaluate the relative successes and failures of each method.

Defining Save Scumming

Although most people probably have some idea of what save scumming is, for the record, I'd like to lay out a fairly basic definition that stands up under some degree of scrutiny and is relatively inclusive of players' motivations and goals.  Like save systems themselves, save scumming and opinions on what it is, how much is fair and how much becomes an exploit, and so forth, tends to vary quite a bit from person to person.

Generally, save scumming is an action performed by the player which involves the deliberate manipulation of save game states for the purpose of obtaining an advantage during play that normally would not occur, or to achieve a desired outcome.  This is usually done for three reasons:
  1. Manipulation of story events and choices in order to obtain the player's ideal outcome, i.e. making sure the "best" resolution to an event occurs.
  2. Saving and loading in occurrence with favorable outcomes in gameplay, i.e. reloading if a powerful attack misses the enemy.
  3. Using prior knowledge to get past an existing challenge, i.e. completing a puzzle through trial and error and then reloading to remove any consequences of failure.
While there are undoubtedly a few special cases depending on the game, these are the three occurrences of save scumming that are most common and most prone to use (or abuse) by players.  Of course, some also won't agree that all of these constitute save scumming, or that save scumming itself is a valid play-style in certain situations (such as to view all endings of a game), but I think this gives us a pretty comprehensive survey of the problem.


One of the most effective, but also most restrictive way that developers can reduce or eliminate save scumming is by forcing the player to use checkpoints rather than providing free save options.  Checkpoints are typically a bit more common on console and handheld games, but usually show up in just about all games in some form or other.  For clarification, checkpoints here refer to the use of a single autosave slot, as opposed to traditional autosaves, which often work with multiple save slots or are combined with other types of saves, such as manual "hard" saves and quicksaves.

Typically, checkpoints and checkpoints can work to the player's advantage by making sure difficult stages of the game don't have to be completed multiple times over.  Indeed, more than any other solution, checkpoints make it difficult or impossible for the player to manipulate outcomes, although they do allow for multiple attempts to be made prior to the next checkpoint down the road, meaning placement is extremely vital.

One strength of checkpoints is that they can often enforce story decisions in order to make sure players live with the consequences of their actions.  While not important to every game, this can be extremely useful for helping players learn to appreciate their choices and their outcomes.  Alpha Protocol, for instance, used checkpoints exclusively to regulate the player's movement through the open-ended story.  With lots of personal relationships to manage, story-relevant decisions to make and even a few time-limited choices, the effects of the game's consequences, both in the short and long term, would have been dulled significantly.

Alpha Protocol got players to consider their actions by forcing them to live with their consequences.
 Checkpoints also typically ensure that players don't manipulate the outcomes of combat encounters and other challenges, and more broadly make players consider the long haul rather than the short term.  With checkpoints, overcoming single challenges becomes less relevant than making it to the end of a scenario in one piece.  Attrition is a dying art in most games, especially those in the mainstream, and checkpoints make players work with what they have rather than rely on luck or other exploits to pull them through.

The one thing checkpoints can't really protect against is the use of prior knowledge.  Unless a game saves at each and every junction where a choice is made, or an encounter or puzzle completed, it's very hard to prevent the player reloading to pick the right option from the beginning.  Moreover, as most games tend to place checkpoints right before these scenarios, there's very little dissuasion for players actually doing so.  This is a lesser concern than the other two motivations for save scumming, but still worth taking into consideration.

Finally, checkpoints, by their restrictive nature, have the unfortunate drawback of forcing the player to live with the consequences of his or her actions, no matter what they are.  That means that sometimes, players will be stuck with decisions they made accidentally, or gameplay outcomes that weren't their fault.  If a game includes a challenge, and the player is stuck with an unfavorable result because of a bug or an out-of-game distraction, then that does not feel particularly fair.  Similarly, it's common for the dialogue choices in role-playing games to provide players with unintended results (especially in cases where dialogue wheels are employed, and the exact meaning of a player choice is ambiguous); in these situations, it's downright frustrating to end up with a story development that wasn't the result of a "bad" choice, but rather because the game was poor at communicating important information.

Limited Saves

The second major way games limit save scumming is by providing limited save slots (or save numbers).  This is more common on consoles, and traditionally was as much the result of technical limitations as it was a design choice.  In Chrono Trigger, for example, the player is limited to three save slots only, regardless of whether or not those save slots are from separate game sessions; if you have friends or family playing a separate session, then your number of save slots is actually reduced.  Similarly, in the early Resident Evil games, the ability to save was limited by the number of ink cartridges the player collected around the game world.

Though generally a lot less common than it was in the past, it does crop up from time to time these days.  IO Interactive's Hitman series rather famously provides the player a different number of saves depending on difficulty, with zero save slots at all on the highest difficulty level.  The goal in such a game is to make sure the player has both effective planning skills as well as is able to execute on that plan; the other options are much more lenient and don't require the same devotion to planning and tactics, only on getting through the game's stages alive.

Limited saves in Hitman encouraged players to plan their actions carefully, and avoid unnecessary carnage.
Limiting save slots has a less drastic effect on gameplay than checkpoints do, but by making savegames effectively a resource to manage, players need to think about whether it's worth their time to save, and either overwrite earlier progress or use up a limited capability.  The major upside of limited save slots is that it has a relatively equal effect on all motivations for save scumming - players aren't going to be nearly as tempted to reload an earlier save, or make a new save, if they know they may need that save option later in the game, regardless of whether it's a story event or gameplay scenario.  It also mostly avoids the problem of the player being stuck with a mistake, or at the very least avoids the feeling that the game is punishing the player for a mistake the designers made.

However, limiting save slots also comes at a pretty big price: the core functionality of the game itself.  The fact is that developers cannot, and probably should not, insist when and where players can save, because they are unable to anticipate the situations players will need to pick up and put down a game, or with what frequency, or the numbers of players who might be playing on a single device or copy.  As much as we'd like to imagine players sitting down for hours to enjoy games, the fact is that with real life, including family members to manage, chores and tasks to complete, work to do, etc., it's simply not convenient for most players to do so.  Limited save slots simply don't take the reality of gaming into account, and while it's possible for players to pause the game for hours on end, that's a pretty poor solution by any standard.

Last, in cases where there are limited slots for the player (as in the Chrono Trigger example), often the player will be left out of luck when a bug or glitch shows up at some later point in the game to hinder or ruin progress.  Even if a player were to use all save slots in The Legend of Zelda: Skyward Sword, there's a pretty good chance the recent game-ruining bug uncovered could strike, and by the time the player encounters the fallout from the choice, it'd be too late.  Losing progress is never fun, but losing five hours is still preferable to losing thirty hours.


A less-common, but growing way of dissuading the player from save scumming, is through the use of various punishments for continuous reloads.  These can vary radically from game to game, but all of them share the same basic idea of making repeated reloading unattractive, whether that's through respawning difficult enemies, reducing the player's effectiveness in combat, deleting savegames upon loading them, adding wait times to certain actions prone to abuse, artificially inflating load times, or providing greater challenges.

It's clear right from the start that punishments of different natures will be appropriate to different games.  There's no reason to make die rolls or other random odds less favorable in a game where random odds aren't a major concern, for instance, while in a heavily rules-driven game, the idea of rubber-banding an enemy's abilities or challenge level is equally inappropriate.  Moreover, punishments walk a very fine line - too drastic and they can be a turn-off from playing the game altogether (and effectively feel like "real" punishment), too subtle and they might as well not be there at all.

The time delay between hacking attempts punished players who abused quicksaves in Fallout: New Vegas, but the resulting wait periods were more an annoyance than a real deterrent.
One example of this I like to bring up appeared in Fallout: New Vegas.  In Fallout 3, the game's predecessor, the hacking mini-game required the player to take time and use deductive reasoning to piece together a password using a limited number of guesses.  Many players found that this mini-game quickly grew tedious and instead chose to simply guess at random, quitting the mini-game before the final choice was used and starting over - in the end it was still faster than playing the game "properly." 

New Vegas added a lockout timer of about 30 seconds to each computer terminal, which persisted after reloading the game.  Although this reduced the random guessing, the alternative of legitimate failure - being locked out of a terminal, and thus game content - was still far greater than waiting those painful seconds.  Despite good intentions, the problem remained, and the tedium of the mini-game was only exaggerated for many players.  Truth be told, removing the mini-game entirely would have solved the tedium and the save scumming in one fell swoop, but such drastic measures aren't always an option.

Punishments are hard to evaluate because of their case-by-case nature, but in general they can be effective means of making sure players don't perform exploits.  The prospect of saving and reloading isn't so much fun if the odds of success get worse every time.  However, it's also very important to consider the negative consequences punishment can have, and it's necessary to devote extensive play-testing in order to tweak those punishments just like a full-blown game mechanic would be tweaked.  Moreover, as effectively a game feature, punishments can also introduce more bugs and may themselves be exploitable in some cases.

What Else Can be Done?

Though the techniques mentioned above, and more, can be used to reduce or eliminate save scumming, oftentimes the design of a save system is secondary to a game's mechanics, pacing and writing in preventing abuse.  As much as you can force the player to play by the rules, it's often a far better choice to make them want to play by those rules in the first place, and the only way to do this is through smart design from the beginning in every aspect of gameplay.

Consider negative story outcomes.  It's very common in role-playing games for players to replay scenarios in order to get the outcomes they approve of the most, whether the benefits are tangible or not.  It doesn't make much sense from a development perspective to spend a lot of time and effort on different outcomes in a story if most players are going to manipulate events to get the "best" outcome over all others.  Instead, taking care to make all story paths and outcomes feel valid and earned can reduce the desire to load up a prior save, as can focusing on long-term consequences rather than short-term consequences (if only because it's a lot less convenient to reload three hours after a choice has been made).

As far as gameplay goes, the tendency towards binary pass/fail or win/lose states can be just as great a temptation to save scum, as it's as undesirable an outcome as any.  This temptation is made even greater in games where there is no way to repeat a mission, or where penalties are given for failure.  This is a fundamental design consideration in all games, and thus it may not be possible to take this into account, but where possible it's usually better to make the player feel validated by an outcome, even if it isn't the most ideal.  Just as life isn't simple, games don't have to be either, and a level of granularity to progression or victory (whether it's a new plot event, a score, a star rating, etc.) encourages players to improve rather than switch the game off.

Jeez, even the game insults me?  Might as well stop playing right now, at this rate.
This isn't an argument for "no failure," make no mistake, but if players feel they're missing a significant amount of game content for a non-ideal outcome, they'll be far more likely to reload.  Ideally, failure should have its own unique outcomes and rewards - new missions to resolve the consequences of the failure, or special items to give the player an added edge.  Dragon Age II, for intance, made my failures feel less like failures and more like alternate, but acceptable, outcomes.  Did I want a negotiation to end in a bloodbath?  No, but the game didn't grind to a halt because of it, or make me feel like an idiot for screwing up, especially as the rest of the characters in the game world acknowledged the outcome as well as any other.  Obviously, this isn't possible in all or even most cases due to the realities of development, but it's worth taking notes on all the same.

Presentation is also a huge factor in cutting back on save scumming.  Consider the usual failure state: red text proclaiming "mission failed" while dreary or sad music plays in the background.  That's a pretty big signal for players right there that they screwed up, and certainly doesn't encourage most of them to keep playing.  Simply resetting the player back at the beginning of the challenge communicates the same failure, but also avoids adding insult to injury.  Again, this isn't always possible, but it appreciably cuts down on frustration and also avoids wasting the player's time.


Though I've tried my best to break things down here and be as comprehensive as possible, there are always going to be exceptions, whether that's games that don't fit our normal understandings of success and failure, situations where save scumming can be helpful for players rather than an exploit, and so on.  Dealing with save scumming is a challenge that's unique to every game, and more than any it's one worth considering, as it is, in a way, an embodiment of every unexpected variable that players bring to the gameplay equation.

If there is one lesson to be drawn from this discussion, it's that more than anything, the structure and mechanics of a game are just as important if not more important than the save system itself in mitigating abuse and exploitation.  The most appropriate save system for a given game can still be broken and taken advantage of in unintended ways, and placing overly hard restrictions on the player is generally inferior to getting the player to accept what he or she has been given.  Context in designing game and systems is everything, and taking care to understand how a given game mechanic, user interface element, or story event can affect the player's decision to save or reload the game can often make all the difference.


  1. Great article. I'm not sure I understood what you said about the hacking in "New Vegas", though.

    When I played it, what I would do was save right in front of the terminal before I used it at all. Then I'd make all my four guesses, and if I failed, I'd reload the save from before I logged in. And there was no waiting period for me.

    I'm not proud of this, but like you said, sometimes it was the only way to see game content, and I figure that since I paid for it, I might as well.

  2. The problem with save scumming is that the game gives the player bad choices in the first place, riddled with uncertainties. Exacerbating this is the reality that some decisions are obviously more optimal than others - but a player would only recognize they were needlessly suffering if they knew exactly what they were deciding and what the consequences were. Games are terrible about telling the player what's behind doors # 1 or 2. And if the player is being forced to guess, then why offer the choice at all?

    How many people playing Mass Effect 2 knew that two hours in, they'd make a decision that would make completing the Suicide Run with all their crew alive impossible to complete? This is an example of a bad choice.

    I only save scum because often, I'm being asked to decide something where I don't have all the information or even a context with which to base the decision on. Dialogue wheels are just as bad - I wish Bioware would just tell me whether I want to agree, disagree, or ask a question, because interpreting the vague comments on the dialogue wheel is a needless complication.

    Adding fuel to the flames are the often terrible storytelling attached to games that offer the player choices - so your decision can very well not matter at all because the story is on rails and the game will go wherever it wants to go. So you may have kept some character alive because you're a good person, but no one in the game will care and the thought you put into your decision (which is what the game designer was looking for in the first place) gets completely overlooked. Thanks a lot, game!

    I can summarize bad decisions as the ones where the player is asked how they want to start the action, how they want to initiate the plot. Going back to Mass Effect 2 - choosing the save the plant workers or go after the crime lord in Zaeed's loyalty mission is an example of a bad decision.

    It is a bad decision because the player is being asked to decide on an issue that will also answer another, unspoken issue, this other one being the one the player actually cares about. Yes, if you pay attention and scrutinize dialogue, you can intuit what's really going on, but this level of subtlety is so inconsistent that rewards for paying attention are sparse, at best.

    If the game was more direct about broadcasting where the story will go (into a Suicide Mission) and that Shepard's choices will have a direct impact on the survivability of his comrades (loyalty missions) and that any survivors will make appearances in the next installment (Mass Effect 3), then players might not have to save scum as much BECAUSE THE GAME TOLD THEM WHAT THE HECK WAS GOING ON IN THE FIRST PLACE!

  3. @Mysterious Man from the shadows:

    There is a waiting period, but it's about 30-60 seconds (I forget exactly what). If you reloaded the game you may not have noticed it depending on the length of time spent, as I'm pretty sure the delay does tick down even as you load the game. I may have made it out to be a little worse than it is in reality here, but that's also because I'm generally not a fan of the hacking in New Vegas to begin with. :p

  4. @David Armstrong:

    Sounds like you're getting at much of what I said in the latter part of the article - that the context for decisions is key and that staying away from obvious good and bad choices (both with gameplay and story) is a good idea. It's both more interesting to the player to have to pick between two grey choices than one good and one bad choice.

    I do have to disagree a bit on delayed consequences, with the key point being that arbitrary consequences (like all your companions getting exploded if they aren't loyal) are no fun, but consequences you can kind of predict, see coming, or rationalize in retrospect, are far better. The Witcher 2's choices are so good (and difficult) not just because they do have fallout, but because we're given enough information at that point in the game to predict where they might go. It's that speculative battle that makes the dilemmas (and their later fallouts) interesting.

    On dialogue wheels... well, suffice to say, I'm not a big fan of those, mostly because they can a) be used to deliberately hide the "true" meaning of a statement from the player and b) you're not giving the player enough information to really make the choices expected of him/her.

    Thanks for the feedback, both of you!

  5. I've been gaming for 35 years (started on the Magnavox Odyssey), and have known hundreds of gamers as it's been a very social activity for me. I can't recall one person ever complaining that a game allowed saving far too often.

    You're making games, not curing cancer. Let me play the damn game the way I want to play it. Forcing me into some supposed important choice and making me "live with the consequences" is not going to affect my life or world. It's a game. My avatar is a collection of textured polygons. There are no real consequences. Accept the fact that you are involved in an entertainment industry, and stop trying to make it so serious.

    So I save before hacking a computer in Fallout. Why do you care? Let ME decide for ME how to have fun. It's like a movie director demanding his film only be viewed in certain lighting or in a captain environment. Accept that once you release a game into the wild, individuals are going to find individual ways to enjoy it, many times in ways you never thought of no matter how much you try to take player freedom away.

    If I were designing the next gen console, I'd have a way to save any game in its current state to a file, of like hibernate on Windows. I'd take the whole save game thing right out of the developers hands and give it to the players where it belongs.

  6. I know this blog is a bit older, but I have to agree with Uberjuju. I play games because it's not real life. I don't want to be haunted all the time by choices I made because the developer wants to take away my ability to get the "best" ending. I have enough haunting choices in real life to deal with. I don't need a developer telling me I can't make something happen amazing in a game because they want me to experience this "gray" zone of real life choices, or because I messed up. Let me enjoy the "Heroes Journey" and win all the time if I want please! The trend has been too much real life in games and movies lately. It's always "lets be dark and gritty and not have any happy endings." Well you know what western world...I'm tired of it. Don't take away my save ability and let me play the way I want. Even if it's Save Scumming

    1. I should also note that "Punishing" a gamer for using saves is showing that you aren't appreciative of their time. So why should they be appreciative of your game with their time and money?

  7. hey. I just wanted to say I agree with the last two commentors :).

    I don't see why any system needs to be enforced. I understand that whoever is designing the game wants the game to be played a certain way. Well that's fine...but why do you have to *force* people to play that way? Why not just make a statement to the affect of "we recommend that you try to stick to your choices as much as possible, and treat this as real life".

    To aid the player they could even put an optional checkpoint-only system, or something with limited saves, to help players resist the urge to quickload where they made a 'legitimate' error.

    But it should all be optional. Every game should have limitless saves, so that the player can decide for him/herself how they want to play the game. I don't mean to sound like a teenage anarchist, but how about letting people enjoy the game how they want to? How about giving people the power instead of forcing them to play how you think the game can *only* be played? Its just ridiculous that developers take such excessive liberty away from you for your own good. You are not my government or my parent, GIVE ME THE FREEDOM TO DO WHAT I WANT.

    I will choose to save scum or not save scum, don't treat me like a child.

  8. My response to this blog and the comments afterwards, inspired me to create my own blog and post my reply.

    Sortof a requirement, given that it requires a 4096 character maximum to post a comment here. My response was 1500 words, not characters...hehe...