In Defense of Save-Scumming

The last two articles I wrote discussed the issue of save-scumming, framing it as a design problem that needed to be solved, with the underlying assumption made that save-scumming was by nature was something that should be avoided at all costs, or mitigated as much as possible.  Due to the tone of these pieces and the lack of recognition for the virtues of save-scumming (or a recognition that it is a non-issue in some players' eyes), I may have given the impression that I don't like save-scumming, or frown on those who save/load repeatedly.

In this piece I'd like to offer up a contrary opinion: that save-scumming isn't just important, but necessary.  While I still believe it is worthwhile to spend effort in addressing save systems and the problem of save-scumming, I also want to make it abundantly clear that, from a player's perspective, save-scumming is often an ideal solution (or the only solution) when a game's design itself breaks down.  Though my goal here is to present these points in a positive light, I also want to make sure that objections to them are heard in order to maintain a more balanced viewpoint.

Competition, and Lack Thereof

The first and most obvious point in defense of save-scumming is that, in non-competitive game environments (whether that's single-player or co-operative play), there is less motive for game designers to ensure balance, or to enforce players to follow an unfavorable outcome - after all, if there's nobody else interested in the outcome but the player itself, and the player's actions won't harm another player's experience of the game, is there really a good reason to prevent players from simply doing what they want?

To present this concern at face value, however, is to ignore the deeper discussion.  Though we talk about player choice, and freedom, and how there should be no unreasonable restrictions on what players can and can't do, especially when it comes to such subjective and functional aspects of a game as the simple ability to save, in reality we're talking about something else entirely - the sorts of boundaries that we must accept when we experience a game's content.  We are always going to be bound in some way when playing a game, whether that's by the laws of in-game physics, the explicit rules and goals of the game, the collision mesh in the environment, failure and success states, the time it takes to perform a given action, the controls, and so on.  Playing a game is by nature to accept a set of limitations... otherwise there is no game to speak of.

Alpha Protocol may have combated save-scumming with its strict checkpoint saves, but it also locked players out of content, including both items and objectives... despite there being no competitive balance to maintain.

The question of save systems and save-scumming comes in largely where we draw the line - where are the boundaries of the experience, and how willing are we to accept them?  Saving is such a critical issue not just because we like to exert a degree of control over our game experience (when and where we can stop playing, and how often we can retry or replay a game from a given state), but also because it fundamentally affects our relationship with a game.  Our tactics, techniques, time investment, and rate and direction of progress through the game all change based on the limitations we have in saving.  It's why roguelikes, with their strict no-saving rules, are so different to play than other games - not because they're necessarily more difficult, but because cautious and self-restrictive play wins out over all other forms.

Even though it's true that players have already been told and are conforming to the limits and rules of the game as soon as they actually start playing, that perspective ignores the fact that not all players have the same needs, the same goals, or the same desires - thus, while maintaining balance and integrity of gameplay may be a priority for some players, other simply don't care, or even take it as a triumph that they have broken a system.  Moreover, that logic used above can be turned on its head - if it's a choice to follow the rules or not, even if the end result is failure, then isn't it a choice to abuse those same rules, even if the end result is success?

Completionism

Another point in defense of save-scumming concerns the matter of completionism.  Though not all gamers are concerned with getting that "100%" value next to their save files, or simply the best outcomes to the story, the desire to see all a game has to offer (and then be able to brag about it or gain some recognition for the act) is one that many players share.  Unfortunately, save systems often run contrary to the goal of 100% completion, especially in that they can force the player to stick with consequences that are not conducive to such an outcome.  I can certainly say I've been trapped beyond a point of no return in a game before completing everything I wanted to, and that wasn't fun in the slightest.

Tying in with this concern about completionism is a general grievance that games should communicate outcomes to players in advance - that hiding information from players, or not providing enough data to make an important decision, can end up as frustrating rather than interesting.  I personally can't say I agree with this in all situations, but there is merit to the argument.  For example, in Mass Effect 2, players must complete a loyalty mission for each of their crew members in order to ensure their survival in the endgame.  Instead of loyalty tying into the game in a logical way (such as, say, a mutiny), it determined which characters would be killed at the end of the game.  These deaths were arbitrary, and represented a clear story/gameplay segregation that was neither rewarding nor remotely logical.

Mass Effect 2 hinged the fates of party members on loyalty, but the cause and effect weren't clear - a clear failure of design that save-scumming can help mitigate.

Denying information to a player can be a useful tool, admittedly - obviously a plot twist holds no weight if players see it coming a mile away, or are outright told about it in advance, and sometimes having to make a guess as to whether a final attack will defeat an enemy or only lead to your demise is rewardingly (or disappointingly) suspenseful.  Likewise, that same plot twist also lacks impact if players can't look back on prior events and see hints of it in retrospect, and if an enemy has no guaranteed strategy that works against it, it isn't satisfying to finally pull out ahead.  Success is an emotion felt when we feel we have conquered a challenge, not when we have been granted victory at random.  

When we end up in a situation where our success feels arbitrary, or the ideal outcomes to the story are the result of extremely obscure actions near-impossible on a first play-through, or we miss out on a character's ultimate weapon, or pass a side-quest by unknowingly, we understandably end up feeling cheated by the game.  I'm not going to even attempt discussing whether this is a problem or not, but there's no denying players have little recourse in such situations other than reloading saves until things work out for them.  While it's always best to ensure this sort of situation never occurs, players should probably not be denied the option to reload in cases where it does happen.

Differing Player Motivations

Another concern with combating save-scumming is that it's effectively a gameplay measure that punishes all types of players for the perceived sins of a relative few - when in fact players have many different reasons for playing, and thus different motivations other than abuse or gaming the system to its fullest.  A player dedicated to completing goals, for instance, might well be driven to save-scum for reasons entirely separate from a player driven by the desire to explore.

To take the example of The Elder Scrolls V: Skyrim, imagine a player has wandered into a dense forest out, and has come face-to-face with a powerful, high-level enemy.  The player tries to fight, or run away, and is killed.  Depending on the type of player, his or her next actions may be substantially different.  For instance, he or she may:

1. Reload a save, and try to fight the enemy again using the same tactics.
2. Reload a save, and try to fight the enemy again using different tactics (i.e. ranged instead of melee).
3. Reload a save, and try to avoid the enemy.
4. Reload a save, and try to find an exploit to defeat the enemy (such as hoping the AI gets stuck).
5. Reload a save, travel around a bit or wait for the enemy to move on, then continue exploring.
6. Reload a save, and go in another direction, never to return.
7. Reload a save, make a note of the location, level up a bit, and return later to conquer the enemy
8. Reload a save, travel back to town, purchase some better equipment, and return to conquer the enemy.

Many players meet their match at the end of a Giant's club, so why should Skyrim assume that the motivations of players that led to that outcome are the same, or their actions afterwards?

The point is, there are a whole slew of different things that could be driving the player to reload, as well as dozens of outcomes possible once the player has actually reloaded.  To term all of these as "exploits" or to say that they violate the spirit or nature of the intended experience is to be presumptuous about the motivations of all of these players in a way that may be extremely inaccurate.  In such a situation, how is it even possible for developers to accurately anticipate what players want?  Who are the developers to make a judgement and reward or punish accordingly

Once again, this ties in with the discussion about the rules and boundaries we accept when playing any game, but the key difference is that any sort of anti-save-scumming measures undertaken by a developer will inevitably seem unreasonable to certain players, especially those who don't fall into the category of "abusers."  The "easy" answer to this problem is to have more intelligent ways of rewarding, punishing and limiting save-scumming, but of course, the measures taken are going to be completely different for any given game in the first place.  Sure, it's easy to detect if the player has reloaded, say, five times in the span of 30 seconds of gameplay while inside the casino... but to create a robust anti-scumming system that is applied intelligently to all aspects of a game is a huge undertaking, and one which, frankly, probably isn't worthwhile.  If you can't do it right, in a way effective and applicable for all players, why do it at all?

One's Reward Is Another's Punishment

Some people aren't so much opposed to the idea of save-scumming itself as they are opposed rewards and punishments granted in response to it.  As I touched on in my article on incentivization, in order for a reward to be granted, there also has to be the capacity for a reward to not be granted... and the reverse is true of punishments.  Whether or not it's an incentive or disincentive will depend on which side of the line you're standing; the question of who's a damn dirty cheater is almost irrelevant in such a case, because you're bound to upset some players no matter what.

In truth, it's hard to offer up a reasonable counter-argument to this, save for that one has to make certain a game's incentives and disincentives aren't too great so as to alienate players.  When dealing with something so fragile as individual player preferences, which cannot be reasonably evaluated in objective terms, it's impossible to satisfy everyone, and to the same degree.  Some players are going to love incentives and disincentives, others are going to hate them.  Some players are going to be "okay" with them and won't mind much one way or the other.  Some more players may not mind in practical terms, but will object to the principle of the matter.  You really can't win.

Fallout: New Vegas makes players who try to break the hacking mechanic wait before trying again, but how can a developer anticipate a player's reasons or judge them effectively?

It'd be easy for me to say what I did before: that all players are going to have to accept boundaries in playing a game, and thus accept different outcomes for their own actions within the game, whether that's tactics or use of the save system.  No matter what you do, nobody will be fully satisfied with how your game handles everything.  However, what's different in this case with save-scumming is that game-saving is not just a mechanic, or a utility, but a hybrid of both, one aspect influencing the other, and further interacting with the rest of the game.

Just as a title's controls might be made theoretically "perfect" from a utility perspective, the actual rules governing them may be subject to debate for every individual player; a save system's utility may be "perfectly" executed, but the context for that save system and the mechanics it influences - and is influenced by - may also be open to myriad interpretations.  Something like game balance can be expressed in objective terms, but there is no objective language that does justice to a save system, nor the measures governing its use.  It's not a binary pass/fail condition, and can't be treated as such... otherwise, you're handing out those rewards and punishments based on a set of arbitrary conditions.

Conclusion

In closing this series, I think it's important to acknowledge that there is no right answer to any of this.  As much as I might view save-scumming as a problem that needs to be remedied, I must also recognize the reason the practice exists in the first place.  I save-scum myself; in fact, the first time I finished Fallout, I did so by saving and reloading in the middle of some particularly difficult battles.  I'm also a fan of speed runs and other hyper-optimized forms of play, at least as an observer; such practices would not be possible without the sorts of meta-game manipulation that save-scumming is a part of.

As is often the answer with matters of game design, the problem can't be boiled down to one particular element, or one type of player, or one specific scenario, or mechanic - rather, it is holostic, influencing and influenced by the game as a whole.  What I do hope, in light of this, is that this discussion got some people thinking, not just about save systems, but about the relationship between player and game, as well as the relationships between different game mechanics and systems, and all the "fuzzy" things that happen in between.  I certainly didn't intend to follow up on the topic so long, but it was impossible not to when one question led to another so readily.

Thanks to all the readers and commenters, who were kind enough to interrogate my ideas and provide more food for thought than my own mind ever could.  Many of them inspired the content of this article.  As always, feedback of any kind is more than appreciated!