作者：Eric Schwarz

保存系统是个很棘手的东西。无论你玩哪类游戏，都有可能碰到你不希望发生的情况。无论游戏采用的是保存点自动保存、快速保存、设置保存点、自由保存或限制保存次数，保存系统对玩家在游戏中的挑战的影响总是得不到应有的重视。对于保存系统的优劣，玩家间存在不同的评判标准。有些人喜欢保存点保存带来的紧张感，而有些人坚持认为保存应当尽可能地自由便利。

但是，多数开发者和玩家似乎都同意以下观点：滥用保存功能可能成为巨大的问题。最糟糕的情况是，可能会完全摧毁游戏的挑战性，破坏开发者花大量时间制定和完善的游戏规则和机制。本文主要阐述解决滥用保存功能问题的几种方法，评估各种方法的优缺点。

滥用保存功能的定义

尽管多数人可能对滥用保存功能都有些自己的看法，但我还是要提出一个相当基础的定义。这个定义经得起考量和推敲，而且还囊括了玩家的动机和目标。正如保存系统本身那样，对于滥用保存功能以及对它的看法、何种程度下算是公平和何种程度下会影响游戏之类的问题，每个人的看法都各不相同。

通常来说，滥用保存功能指玩家通过做出操纵游戏保存状态的动作，以便获得正常游戏过程中无法得到的优势或实现渴望得出的结果。通常来说，此类行为的出现有以下3种原因：

1、操控故事事件和选择，以获得玩家心目中理想的结果。比如，确保所发生的事件能够获得“最好的”解决。

2、通过保存和加载来确保游戏玩法中所偏爱结果的出现。比如，强大攻击未命中敌人后重新加载游戏。

3、使用已知的知识来通过面临的挑战。比如，通过反复尝试的方法完成谜题，然后重新加载游戏，利用先验知识避开所有失败结果。

毫无疑问，游戏的差异可能还会导致其他特殊原因的出现，但以上这些是滥用保存功能发生的最普遍原因。当然，有些人还觉得以上这些并非都属于滥用保存功能，或者认为在某些情况下滥用保存功能本身就是合理的玩法（游戏邦注：比如通过重复加载来体验游戏的各种不同结局），但我仍觉得上述内容可以算是该问题的综合分析结果。

检查点

开发者可以减少或消除滥用保存功能的最有效和最具限制性的方法是，强迫玩家使用检查点，不提供自由保存选项。检查点保存法在主机和掌机游戏中较为常见，但是其变体存在于其他类型的游戏中。需要澄清的是，这里所说的检查点指的是使用单个自动保存点，而不是传统的自动保存。后者往往会设置多个保存点或同其他类型的保存方式相结合，比如手动的“硬”保存和快速保存。

通常来说，保存点可以确保玩家无需多次完成游戏中的某些难度较高的阶段，从而使玩家具有一定的优势。事实上，与其他的解决方案相比，尽管这种方法允许玩家进行多次尝试以到达下个检查点，但是这会使得玩家对结果的操控变得更为困难甚至无法实现，这意味着检查点的位置设置极为重要。

检查点的优势之一是，它们往往有助于故事决定的执行，确保玩家在动作的结果中继续接下来的游戏体验。虽然这种情况并非对每款游戏都非常重要，但这对帮助玩家学会欣赏他们的选择和结果有很大的用处。以《阿尔法协议》为例，游戏专门使用检查点来调整玩家在开放式故事中的移动。玩家有大量的个人关系需要管理，需要做许多与故事有关联的决定，甚至还有些许有时间限制的选择，这样游戏中结果的短期和长期影响都将显著地减弱。

Alpha_Protocol(from gamasutra)

检查点还可以确保玩家不会有意操控遭遇战和其他挑战的结果，让玩家考虑更长远的目标而不是短期内的胜负。使用检查点后，单个挑战的解决情况同游戏结局间的关联性变小。在多数游戏中，检查点可让玩家尽量利用手上拥有的资源，而不是单纯依靠运气等方法来通关。

但是，检查点无法解决使用先验知识的问题。除非游戏在每个选择做出后、每次遭遇战或谜题完成之后都设置检查点保存游戏，否则便很难阻止玩家重新加载游戏，从头开始选择正确的选项。此外，随着多数游戏趋向于将检查点设置在上述这些场景之前，玩家更有可能采用先验知识的方法。与滥用保存功能的其他两个动机相比，业界对这种做法的顾虑较少，但仍然值得考虑。

最后，由于检查点带有限制性的本质，所以其缺点便是强迫玩家在动作结果中继续下去。这意味着，有些时候玩家不得不接受意外做出的决定，或者非自身过失而导致的游戏玩法结果。如果在游戏的挑战中，由于漏洞或游戏外的其他干扰因素而导致玩家必须接受某个令人不快的结果，那么这感觉似乎并不公平。同样，角色扮演游戏中的对话选项也经常会向玩家提供意料之外的结果。在这些情形中，出现不如意的故事结局的确令人感到很沮丧，原因就在于游戏在重要信息交流上存在不足之处。

限制保存次数

游戏限制滥用保存功能的第2种主要方法是，提供数量有限的存盘栏位（游戏邦注：或限制存盘的次数）。这种方法在主机游戏上较为常见，它既是技术有限的结果也是设计选择。以《时空之轮》为例，玩家只有3个保存栏位。如果你的好友或家人新建游戏进程，那么你可以使用的保存栏位也就相应减少。同样，在《生化危机》的早期版本中，游戏的最高保存次数取决于玩家在游戏世界中收集到的墨盒数量。

Hitman_Blood_Money(from gamasutra)

尽管与以往相比，现在这种方法的使用相对较少，但是依然不时会出现采取这种措施的游戏。IO Interactive的《杀手》系列游戏的著名之处便在于，根据难度等级的不同向玩家提供不同数量的保存次数，最高难度的游戏不可保存。此类游戏的目标在于，确保玩家既拥有有效的计划能力也能够精确地执行计划。相对而言，其他难度显得更为仁和，并没有要求玩家同时顾及计划和策略两个层面，只需要让角色活着通过游戏关卡即可。

与检查点相比，限制保存次数对游戏玩法的影响相对较小。但是将保存游戏的功能转变成需要管理的资源，这就需要玩家细心考量保存的时机，在覆盖之前的保存记录和用完有限的保存次数之间做出选择。限制保存次数的主要优势在于，它对所有滥用保存功能动机产生的效果几乎相同。如果玩家知道他们或许在游戏后期需要用到保存栏位，那么重新加载早期存档或保存新存档的意愿就不会那么强烈。它也几乎避免了玩家只能在错误选择下坚持下去的问题，至少可以避免让玩家产生自己是因设计师的错误而受到惩罚的感觉。

但是，限制保存次数也需要付出很大的代价，那就是游戏本身的核心功能性。现实情况是，开发者无法知晓玩家会于何时何地保存游戏，因为他们无法预测到玩家退出和重返游戏的情境以及他们玩游戏的频率。我们固然希望玩家能够连续花几个小时的时间来享受游戏，但是在现实生活中，玩家需要面对家人，需要完成各种家务和任务，需要做工作，所以多数玩家无法达到上述理想情况。限制保存次数显然没有考虑到玩游戏的现实情况，虽然玩家可以根据自己的需要来保存游戏，但它依然是个很不完善的解决方案。

最后，在保存次数有限的游戏中（游戏邦注：比如《时空之轮》），往往玩家会面临前期犯下的漏洞或过失在后期产生巨大的影响，妨碍甚至破坏整个游戏进程。即便某个玩家在《塞尔达传说：天空之剑》中使用了所有的保存栏位，也很有可能出现下述情况：出现足以摧毁整个游戏的漏洞时，玩家已经无所选择。失去游戏进程永远都不是件有趣的事情，但失去5个小时的游戏进程终归比失去30个小时要好。

惩罚

使用各种方式来惩罚连续重载游戏的玩家，这种阻止玩家滥用保存功能的方式并不常见，但是有不断增加的趋势。惩罚的方式各不相同，但是它们有着相同的基础想法，那就是让反复重载游戏逐渐变得没意思。惩罚方式包括：刷新难度较高的敌人，削弱玩家的战斗能力，存档加载后被删除，增加某些动作的等待时间，设置加载时间不断增加或加载后提供更大的挑战。

不同的游戏适合采用不同类型的惩罚。比如，在以规则为主的游戏中，变更敌人能力或关卡挑战也不是合适的解决方案。而且，惩罚的设置必须适中，过于严厉会完全打消玩家体验游戏的激情（游戏邦注：最后受到惩罚的就成了游戏开发商），过于轻度则会使之形同虚设。

在这里我要举的例子是《辐射：新维加斯》。在该游戏的前作《辐射3》中，小游戏要求玩家在尝试次数有限的情况下使用推理能力获得密码。许多玩家觉得这个小游戏很快就变得乏味无趣，最后选择只做简单的随机猜想，在最终选择到来之前退出小游戏重新开始。事实证明，这样玩起来反倒比使用正常的推理玩法更快。

Terminal(from gamasutra)

《辐射：新维加斯》给每台电脑终端设定了约为30秒的锁定时间，重新加载游戏并不能刷新这个时间。虽然这会减少前作出现的随机猜想情况，但随之而来的失败（游戏邦注：电脑终端被锁定就意味着部分游戏内容被锁定）比等待多次重载的时间更令人厌烦。虽然游戏设计改变的出发点是好的，但问题依然存在，而且小游戏的乏味感对许多玩家而言更明显了。事实上，完全移除小游戏本就可以解决这个问题，也能够杜绝滥用保存功能现象，但这种极端的做法向来不被人青睐。

惩罚难以评估，但通常情况下这种方法可以有效地确保玩家不滥用保存功能。如果每次保存和重载都会使成功的可能性降低，那么玩家就不会觉得这样做很有趣。但是，考虑惩罚带来的消极影响也是非常重要的。进行大规模的游戏测试是很有必要的，这样才能够找出和改善那些对游戏机制产生影响的惩罚。此外，作为一项游戏功能，惩罚也可能让游戏产生更多的漏洞，某些情况下惩罚本身也可能成为玩家利用的对象。

其他做法

虽然上文中提到的方法可以用来减少或消除滥用保存功能现象，但保存系统设计的重要性仍居于游戏机制设计之下，设计师可以通过节奏和文字来防止玩家滥用游戏保存功能。如果你需要强迫玩家遵从规则来玩游戏的话，倒不如让他们自觉遵守游戏规则。而实现上述目标的惟一方法是，对游戏玩法的各个层面进行精巧的设计。

以消极故事结局为例。玩家重载场景来获得他们最想要的结果，不管所获得的实惠是有形的还是无形的，这种现象在角色扮演游戏中相当常见。从开发的角度来看，如果多数玩家选择操控事件来获得“最好的”结果的话，那么就不值得花大量的时间和精力来设计不同的故事结局。其实，让所有的故事路径和结果都显得鲜活且带有奖励性，这可以削减玩家重载游戏的意愿，因为玩家会专注于长期结果而不是短期结果。

只要游戏开始进行，胜利或失败等对立状态就会让玩家产生滥用保存功能的冲动。在任务无法重做或者失败会受到惩罚的游戏中，这种冲动变得愈发激烈。拥有对立状态是所有游戏的共同特征，这是无法避免的，但游戏可以通过设计让玩家感到自己的选择得到了认可，即便它并非最理想的选择。生活并不简单，游戏也是如此，对进程或胜利的精巧设置（游戏邦注：比如添加新的故事事件、分数和星级评定等方式）能够鼓励玩家提升自己，而不是关闭游戏。

如果玩家感觉他们因非理想化的结果而失去大量的游戏内容，那么他们重新加载游戏的可能性会大大增加。理想情况下，即便是失败也应该有其独特的结果和奖励，比如产生改变失败结果的新任务或给予玩家其他优势的特殊道具。比如，我觉得在《龙腾世纪2》中，失败感觉起来并不像是失败，更像是另一个可以接受的结果。对于我做出的非理想选择，游戏并没有进行惩罚，或者让我觉得自己像个傻瓜，游戏世界中的其他角色都认可我做出的结果。显然，在实际开发中，并非所有的游戏都能够做到这点，但这种做法确实值得众开发商关注。

呈现方式同样也是影响滥用保存功能现象的重要因素。想象我们通常看到的失败状态：屏幕上呈现“任务失败”的红色字样，同时播放沉闷或悲伤的音乐。对玩家来说，这是种明显的失败信号，多数人不会继续玩下去。对这种做法进行些许改变，在玩家失败后只需让其重新回到挑战起点处即可，这可以传达出与上述相同的失败信息，但不会让玩家过于受伤。而且，这种设计完全有可能实现，既能够有效地削减玩家的挫败感，也可以节省玩家的时间。

结语

但也有些例外情况，比如，有些游戏的成功和失败并不像我们惯常理解的那样，在有些情形中滥用保存功能对玩家是有帮助的，并不会破坏游戏玩法。

最重要的是，在杜绝玩家滥用游戏保存功能上，游戏的结构和机制同保存系统本身同样重要。即便游戏采用了最适合的保存系统，依然有可能被以意料之外的方法使用。给玩家设置过于严厉的约束，倒不如让玩家欣然接受他们得到的东西。设计游戏和系统时需要考虑到游戏中的所有要素，理解游戏机制、用户界面元素或故事事件能够对玩家保存或重载游戏的决定产生何种影响，这样便会赋予游戏全新的面貌。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The Save Scumming Problem

Eric Schwarz

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.

Checkpoints

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.

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.

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.

Punishments

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.

Conclusion

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)