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:
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.
Saving and loading in occurrence with favorable outcomes in gameplay, i.e. reloading if a powerful attack misses the enemy.
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.
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.
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.
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.
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.
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. (Source: Gamasutra)