Immersion: A Matter of Scale

If there's a buzzword the triple-A videogames industry has been aspiring to achieve lately, then it's "immersion."  It doesn't really matter what kind of game you're playing, or being sold - immersion is going to be at the forefront of the marketing campaign, as well as the developers' own design.  Of course, the actual meaning of "immersion" is itself highly variable and prone to much interpretation.  As a subjective quality different for every player, immersion can't really be pinned down in the same way "stunning graphics" or "impressive soundtrack" can, especially as it is often an amalgam of those same things (though that won't stop me from trying a little).

Above most other meanings, I've found that the immersion referred to by most of the games industry, as well as the press and fans, pertains to the illusion of virtual worlds - the idea that a game is taking place in a place and time that "feels real."  Usually, this is the result of one thing - painstaking obsession with detail and spending huge amounts of time, effort and resources on building unique art assets, recording tons of dialogue, writing pages upon pages of supplementary text.  While these certainly have their value, producing content of this nature is both more expensive - and, in the long run, often less effective than creating wider-scale universal game mechanics and infusing thematic consistency into the virtual world.

What is Immersion?

Talking about immersion by itself is a whole other article, but like most pieces I write, I think it's important that I first establish some common ground.  To speak broadly, immersion is both the capacity for a game to draw players into its virtual world and system of rules (aesthetics and mechanics), as well as the nature of the process by which this is achieved.  From a slightly different perspective, immersion can be understood as the degree to which a game is able to reinforce the player's own personal narrative - whether that's game mechanics that form circular patterns of play, or a game world that gives context for the player to operate within.

I make special mention of process, because immersion is not an either/or quality - it must be created by game developers with an acute understanding of the experience they intend to provide, and, from the player's perspective, it is built up over the course of playing that game.  One does not simply switch a game on and become immersed - rather, it is a paradigm accumulated through exposure to and participation within a virtual world.  As its rules, mechanics, characters, geography, conflicts, factions, and other unique qualities are slowly learned and understood, players become more and more drawn.  Just as important is that, as immersion is earned over time, it can also be lost the longer a player inhabits a virtual space.

It is also important to note that while immersion can result directly from gameplay mechanics, game mechanics often aren't enough for us to label an experience as immersive.  While a game of chess can be just as engrossing as the virtual vista of a digital world, rarely do we speak of games as being immersive on mechanical levels alone.  Rather, it is the coherence between game mechanics, story, visuals, sound and so on that create that sense of immersion.  For a far more detailed and adept discussion of this, I encourage you to check out Bart Stewart's recent article.

Macro and Micro

With that (admittedly tenuous) definition of immersion out of the way, it's time to turn towards the theme of this article: immersion on a macro scale vs. a micro scale.  On the surface, the two terms are fairly self-explanatory, with micro-level details covering the smaller, individual bits and pieces of a game players will come into contact with, and macro-level elements defining the overall experience.

To use an couple of examples, a micro-element might be a graphical detail the player picks up on - Half-Life 2 does a fantastic job with this, by littering the homes and offices of its characters with little details that give insight into their histories and personalities.  A macro-element, meanwhile, could include the overall structure of a game - the journey the player makes through the city streets of Grand Theft Auto IV, moving from mission to mission or simply exploring, learning the layout of the game world, does as much to create a feeling of a living, breathing city as any incidental details are able to on their own.

In StarCraft, the statistical differences in units create gameplay, as well as tie into the narrative context of the game.

Of course, both the micro and macro pieces have their strengths and weaknesses.  The core strength of micro-level details tends to pertain to their ability to communicate individual pieces of information to the player.  In ideal scenarios, this will have both narrative value as well as gameplay value.  A Zergling in StarCraft has less health and does less damage than a Hydralisk, for instance, which allows the player to infer not only a simple mechanical relationship between the units (that A is stronger than B) but also their place within the hierarchy of the game's world.  This can often form the centerpiece of scenarios the player experiences.  Again in StarCraft, certain missions that revolve around the acquisition of new technology, or even resources, also have mechanical value - in these cases, unlocking a new unit to use, or learning how to manage resources.

Macro-level game elements are sometimes harder to pin down, but can usually be understood as that which gives meaning to the entire experience.  That is to say, they serve less to highlight the individual facets of a game, and more to give context to situations, or provide weight to the narrative, or create a sense of consequence to actions.  Deus Ex: Human Revolution, for example, uses the theme of transhumanism to inform the individual portions of the game, but it also serves as a thematic model for the entire game - its neo-Renaissance art style, the soundtrack's mix of electronic and organic instrumentation, the mechanics of the augmentation system and experience points, etc.  Without that consistent theme augmenting the game, much of its character, consistency and context would be lost, and those micro-level elements wouldn't draw the player into the game experience with the same effectiveness.

One Without the Other

Game development, of course, is very much about prioritizing, trade-offs, and effectively getting "bang for buck" as far as all parts of a game are concerned - not just in terms of raw economics and management, but also in terms of design effectiveness (as many games are better off with dissonant elements removed), and in terms of asset and content creation (why spend months working on a level that will only be seen for five minutes, or a model that only shows up in the background?).  The exact same logic applies to creating immersion.

Extreme details are all well and good...

Some readers will notice, above, that I made the implication that macro-level elements trump micro-level ones, and this was no accident: speaking bit-for-bit, those macro-elements, including the wide-scale rules of the game world, long-term persistent mechanics, etc. are far more effective, and cost-effective, in building that sense of immersion for players.  Consider that while many games can do without the smaller bits and pieces of content or the individual pieces of mechanics, without any context to define an experience in the first place, or to give longitudinal meaning, the end result is a lack of direction, or a feeling of meaninglessness - the end result of which is a boring game that the player probably isn't going to be invested in.

... but it's also possible to accomplish as much with less.

To use an analogy, it's a bit like looking at an impressionist painting: while the overall level of detail in a work by Van Gogh might not necessarily rival that of the Baroque period's Rembrandt, the, well, impression one is left with when looking at the work as a whole is just as if not more coherent as the Rembrant piece.  For fewer brushstrokes and comparatively less "work", the impressionist piece captures just as much; the ideal case of more with less.  Mind, this isn't about one type of work being harder to produce - the emphasis, however, shifts between execution to conceptualizing as you go from one end of the spectrum to the other.

Tying it Together

Esoteric ramblings aside, how does this relate to immersion?  Well, consider one game that's been receiving awards left and right and has had more discussion than just about any other game this year, The Elder Scrolls V: Skyrim.  One foundation of Bethesda games, and made even more apparent than ever in Skyrim, is the degree to which the micro-level details of the game world serve to immerse the player.  Walking through the virtual streets of Whiterun, one overhears conversations specific to characters (that often tie in with story events or quests), people attend their jobs and perform tasks during the appropriate hours (based not just on the time of day, but also days of the week), and so on.  One is struck immediately by just how well-realized the game world is, how much care and effort went into it, how each conversation must have been written in advance, and painstakingly scripted and bug-tested...

... and therein lies the major problem.  As impressive as a game like Skyrim is, especially upon initially starting it up and being staggered by the sheer amount of detail it achieves over such a huge scale, it's also woefully expensive to produce that amount of unique content.  It might keep more developers working (something I certainly can't argue with!), but it also means that the production cycle is lengthened significantly.  Skyrim, on its own, is huge, and even without all its personalized NPC schedules, contextual conversations, hand-placed props in every house that speak to the personalities of the owners, and so on, it'd be a massive undertaking to build... adding all that on top, while certainly helpful, doesn't really astound much beyond the intitial first impression.  The first few hours might be absorbing, but even after that, the dialogue starts to repeat, the character behaviours are revealed to ultimately be pretty limited, and those individually-placed objects blend into the backdrop of the game world.  What was once special, and which probably took so much of the game's development time, is in the long term no more persuasive or immersive than the content of any other Bethesda game.

Meanwhile, another problem rears its head: for all its detail, Skyrim is also extremely poor at implementing that macro-level consistency as far as game mechanics are concerned.  The game initially reeks of political intrigue and drama, the expanded speech skill hints at benefits to winning over allies, and quest lines like the Dark Brotherhood allow the player to do some pretty drastic things... only, none of it ever really matters.  Aside from being able to, occasionally, kill a few named quest NPCs, the player's impact on the game world is minimal at best.  No matter how many Thieves Guild members the player finds (or kills), the city as a whole will always be plagued by thieves even of most of them lie dead.  Likewise, no matter who wins the civil war, most NPCs fail to even acknowledge that it's ended in the first place.  What could have become the crux of the game instead becomes only more noticeable and hurts immersion more and more the longer the player inhabits the game world.

A screen full of global statistics, and the emergent events that they can spawn, often make S.T.A.L.K.E.R. far more engaging than the thousands of static, scripted elements in Skyrim.

Compare the world of Skyrim to the one found in the S.T.A.L.K.E.R. series by GSC Game World.  Despite the size of the Zone being miniscule next to the Nordic theme park in Bethesda's game, the interactions between the different factions forms a backdrop for the experience, with their different ideologies and goals creating a natural clash that has value in the story, as well as playing out in the game world itself.  In Clear Sky, territories will actually shift as different factions gain control or lose it, rendering once-safe areas extremely dangerous, and vice-versa.  Meanwhile, loners, animals, and other independents will often find themselves caught in the crossfire, and avoiding taking sides carries with it some very obvious penalties, namely in far more difficult exploration and less access to high-level equipment.  Even the endings of Call of Pripyat change based on which factions (if any) the player has aligned with, and whether those factions were led to success or failure.

Despite S.T.A.L.K.E.R. having not even a percentage of the characters and dialogue Skyrim does, in focusing less on the individual details and much more on reinforcing aspects of gameplay and story on the macro level, the Zone is infinitely more immersive and realistic.  While I'm not privy to the development details of either game, and it's always a bad idea to conflate the design and technical aspects of each game, it's also hard not to look at a game like S.T.A.L.K.E.R. and wonder just what a developer as big as Bethesda could do with more overarching mechanics beyond the character system.

Conclusion

 If there is one thing I'd like to mention in finishing up, it's that I certainly value the smaller details as much as I do the big picture.  I spent some time differentiating and defining the values of the two, and did so fully because I don't believe that one entirely supersedes the other.  Just as those micro-level elements can seem arbitrary without common ground for them to sit on, the larger-scale ones can also be rendered as artificial, cold and lifeless without the small details to give them colour and personality.

As much as I love coherent game worlds governed by an overarching theme, logic or mechanic, the fact is that Kleiner's lab in Half-Life 2 would not be nearly as engaging to explore if not for all those smaller details, and I don't think expressing Alyx's story value in the form of a virtual pet-style game mechanic would be very appropriate either.  There is a place for both, but it's in recognizing their relative values and producing games that take full advantage of that knowledge that defines good game design and project management.  For all the talk those small details get, ultimately I don't think that's what sticks with players or makes for a better game, and it's certainly not making games any cheaper or easier to produce.

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!

Save Scumming and Incentivization

In my previous article, I examined different methods used by developers to combat save scumming.  Among them were the use of checkpoint saves, limited save slots/numbers, and punishments for repeated saving/reloading.  Although all of those systems have their strengths and weaknesses when it comes down to save scumming, I feel that usually the best choice is to work to design your game in a way where the motivation to save scum in the first place is diminished, or doesn't exist at all.

A few remaining thoughts were left on my mind, however, and there was a big topic that I skipped over in the original piece that I'd like to take some time to address.  Specifically, it's incentivization, which I feel is related to punishments but deserves its own discussion due to the different ways it can be accomplished, and the way in which it can interact with punishments.

Incentives vs. Punishments

The first thing to consider is what differentiates an incentive from a punishment.  This might sound obvious at first - punishments are bad, incentives are good - but the reality behind the situation is a little bit more complex.  In many cases the difference between the two is a matter of perspective - is locking the player out of computer systems in Fallout: New Vegas an incentive to play the mini-game properly (and thus get an XP reward), or is it a punishment for not playing as the developer intended (you have to wait to try again)?

The reasonable answer is that the distinction between incentives and punishments is one of opinion, and that in almost every case you have to have a mix of an incentive and a punishment for either one to really make sense.  It's definitely possible to express something as primarily positive or negative, especially to the player ("don't do this" vs. "do this"), but there's always going to be a downside to every upside.  The job of a game designer (at least, one concerned with eliminating save scumming) is to frame the outcomes in a way that comes across as generally positive to the player, rather than punitive.

This can be easier said than done, especially because the ways in which players experience games can be very different from one another.  Some players might love to get rewarded, while others think that missing out on rewards because they aren't as skilled as others isn't very much fun.  Similarly, there are those who love a great challenge, and others who stop playing after losing no more than two or three times in a row; for them, the motivation to save scum is both situational and personal.

With that in mind, what are some of the ways in which developers can provide incentives to keep playing the game without resorting to save scumming or other forms of related abuse?

Understanding the Decline of Attrition

As I've written about before, if there is one trend covering just about all modern game design, it has been the reduction of attrition.  This is something both enforced within gameplay and which often forms the entire basis of a game's mechanics (regenerating health), as well as something which stems less explicitly out of the structure of a game itself (the tendency towards shorter game levels or goals, with obvious break points).  I'm not here to talk about whether I think this is a good or bad thing, but it's clear that it's defined many games released in the last console generation especially, and doesn't show any sign of disappearing as developers move towards the mobile market.

What tends to be lost with this reduction of attrition, however, is the incentive for players to keep playing a game for longer sessions.  Whereas many past games were heavily focused on keeping the player in the action and moving forward at all times - strategy games like Command & Conquer with lengthy missions requiring long-term planning, or shooters like Half-Life refusing to break gameplay up into distinct levels - these days the challenges players face are immediate, the risks and rewards occurring within the same repeated 30-second cycle of gameplay rather than over the long term.

Many games used to emphasize long-term strategy more than they do now - making save scumming less viable then, and more essential now.

Instead of long-term goals being the default, now other types of goals have been superimposed upon this smaller cycle of short-term goals.  Completing the level may now be a fairly trivial task, but can you get the achievement for completing the game in 5 hours?  How about collecting all the hidden objects throughout the game?  Gaining a high score on the leaderboards?  Do you spend your superweapon's ammo now, or later on?  Long-term goals exist nowadays primarily to satisfy the hardcore completionist players, and thus the motivations for save scumming tend towards meta-gaming and power-gaming.

Why do I go into this?  It's important, I think, to understand how modern game design has changed and how and why save scumming now manifests.  If developers are to create important incentives for players, they need to be able to know why players are save scumming in the first place, the sorts of functions it serves for them, and how those problems in gameplay can be remedied.  Attrition, or rather, its decline, is at the heart of this problem.

Rewarding Consistent Play

While you can't really change the nature of players, you can reward them to keep them in the game, rather than reloading every five minutes to get ideal outcomes.  One of the best ways to do this is by providing players a reward for avoiding reloads (specifically reloads done to avoid bad outcomes).  Though this isn't going to be appropriate to every game for the reasons I've discussed above, I think it has a lot of potential in getting players to keep going.

The best recent example of this I can think of is in Jay Barnson's indie RPG Frayed Knights: The Skull of S'makh-Daon.  In Frayed Knights, the player gains Drama Stars for opening doors, solving quests, defeating enemies, and so on.  Drama Stars are obtained at a fairly fixed rate, with the distinction being that most of them are achieved for new accomplishments rather than old ones, so opening the same old door obviously won't reward the player like opening a new, unknown door will.  When you save and quit the game, your Drama Stars are saved, but if you reload a save, they disappear and need to be re-earned.

Frayed Knights' Drama Stars reward players for sticking with it and surviving by the skin of their teeth, rather than loading up a previous save file.

Drama Stars can then be spent on special abilities used both in and out of combat.  Some of these are pretty mundane and have small effects, like a temporary damage boost, but as the player accumulates more Drama Stars, the potential abilities become game-changing, up to and including a full party revive and restoration, turning a losing battle into a winning one instantly (provided the player has played consistently up until that point, of course).  Although this doesn't eliminate save scumming entirely, it does a lot to encourage players to avoid reloading.

Another hypothetical example might be found in an action game, where the player gains a long-term bonus for killing enemies (i.e. 30 kills = +5% damage bonus), and which persists until the player either completes the current level or challenge, or reloads the game.  Players aren't punished, per se, by reloading, but by continuing with the current challenge, they'll have an easier time in the long run for it.  Admittedly, the nature of the game design would need to reflect this (avoiding instant death scenarios, giving the player a large supply of health rather than a small, regenerating one), but of course, these sorts of incentives are going to be different for every type of game.  Frayed Knights' Drama Stars wouldn't work in a shooter, for example.

Additional Objectives & Bonuses

A related but different mechanic for encouraging the player to avoid save scumming involves providing the player with larger or extra rewards for completing tasks in an ideal manner, or for completing secondary tasks.  This could be anything from bonus experience points and gold, to extra items, to a simple congratulations from a character in the game.  Balancing these sorts of rewards is a challenge, as they'd have to be proportionate to the risks involved, as well as not being so significant that the player feels it's a good idea to reload the game if the demands aren't met.

Though I haven't seen this implemented on a universal level in recent games, the one that springs to mind the most for me is Fable: The Lost Chapters.  In Fable, the player can take on different quests during the game, both required and optional, and choose to boast about them.  Boasting effectively unlocks a set of secondary objectives for the player to complete during the mission, in exchange for a greater reward (usually money and experience), but also requires an investment cost, so it's not a sure-fire way to make tons of money easily.

Fable's boasting gave optional incentive for hardcore gamers to challenge themselves - indirectly encouraging them to avoid the save/reload cycle.

 Combined with Fable's checkpoint saving system, it's more or less impossible (certainly inconvenient) to load up a previous save upon failing a boast, and the ability to take multiple boasts on any given quest also means that failing one still leaves the others open.  This gives more options for the hardcore players to show off their skills or get the challenge they want, but still ensures that everyone will be able to move on in the game, without losing anything.  While not specifically designed to prevent save scumming, this sort of mechanic once again encourages players to stick with the results they've got.  Because of the investment required to boast in the first place, it's not a simple matter of "do it right and get a bigger bonus"; rather, it's directly tied to the player's own choice to undertake the additional challenge.

When talking about secondary or optional objectives, it's worth clarifying their importance in the game.  If an optional task feels too important to the player - it has been given a lot of importance in the story, or the rewards for completing it are huge, or the player will miss game content by not completing it - then in my opinion it's hard to even really consider it optional at all, from a save scumming perspective.  Since players who resort to save scumming are usually meta-gamers or power-gamers to begin with, they're going to want to complete just about every secondary task available before moving on in the game.  Therefore, it's fair to say that rewarding an extra health potion or a 5% experience bonus for completing a secondary task incentivizes consistent play... but giving the player a whole new level to explore, or a new weapon or set of armour, only adds to the problem.

Meta-Game Incentives

Last, it'd be hard to talk about giving players incentives without talking about meta-game rewards.  Though meta-game rewards aren't always available depending on a given game's platform, genre, etc., it does tie in quite nicely with the hardcore player mindset of "100%ing" a game that often fuels save scumming in the first place.  Moreover, because so many games are geared towards long-term goals, and which are themselves often meta-game goals, it only makes sense to use those features to one's advantage.

The first and most obvious meta-game system to highlight is achievements.  Most major gaming platforms have some sort of achievement system, regardless of the name, and a similar type of functionality can be added into a game even if it doesn't tie into any sort of meta-game system (the Mass Effect series does this on the PC).  While an anti-scumming achievement might be a little too blatant for some players, the same sorts of problems can be solved by using achievements in conjunction with other goals - for instance, rewarding an achievement for saving all the peasants from an attack, which itself might only possible without save scumming.  A more brute-force method of "no achievements for you, save-scummer!" can also be used, but again, being this blatant about it might turn some players away.

Rewarding achievements for fair and consistent play could encourage players to avoid exploits.

Another option is to cut save-scummers off from leaderboard rankings, or include some sort of high-score penalty for repeated reloads. Even games that don't have explicit scoring systems can have some sort of leaderboard compatibility, whether that's being able to track the progress and accomplishments of friends who are also playing, or listing completion speed, accuracy, and so on rather than high score.  For single-player games this might be a little more out of place, but it's still certainly possible to integrate such functionality.

It's worth noting that these solutions start to border on punishments again.  As I described above, I don't think the distinction between the two is quite as absolute as some might suggest, and when players aren't really missing out on any game features when save-scumming, I think it's a non-issue.  Just as the Grand Theft Auto games disable achievements when players activate cheat codes, I think it's fair to do the same when players begin to abuse the save system - though care must be taken about the particulars.  So long as a game isn't broken enough to actually require the use of save scumming to complete, I interpret achievements and leaderboards as rewards on top of the core game experience, rather than features all players should be privileged to.

Conclusion

Once again, I'm forced to admit that there is no sure-fire way to deal with save scumming.  As many incentives as you throw at the problem, players are probably still going to continue to do so, and without outright restricting the player's ability to save and load the game in the first place (the hallmark of some genres, but not most), all a developer can do is push players in the right direction and hope they take the cues.

There are still some unanswered questions about save scumming that I'd like to get into at a later time.  I realize that these articles can occasionally come across as very anti-player, punitive, and generally one-sided.  I fully admit to this, but it's not a result of my personal opinion on save scumming, on the nature of the discussion's tone.  There are plenty of arguments to be made for save scumming as well, as not all games are created equally and not all players are willing to subject themselves to the limitations imposed by developers.  I'll be getting into that myself soon, but better yet, if you have a strong opinion about save scumming one way or the other, I'd love to hear it as well.

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.

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.

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.

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.

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.

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.