Saving, Reloading and Player Failure

When the subject of free versus restricted saving comes up, people often end up conflating the issues of players being free to save their progress at any time and games requiring players to replay certain segments upon failure. The assumption is that the proper response to player failure is for the game to reload the latest save state, thus leading to a framing of the issue of loss of player progress in terms of free versus restricted saving.

Unrestricted saving mechanisms are essential in modern games in that they allow players to quit the game at any time without losing progress. This does not, however, mean that loss of progress upon failure is an illegitimate mechanic. Countless commercially successful game designs that purposely incorporate just such a mechanic show quite clearly that loss of progress upon failure is a perfectly legitimate mechanic. Ultimately, the answer to the "free save" dilemma is not to design a game such that progress can never be lost, but to design a game such that its response to player failure isn't coupled to the game's save system.


Principle: Uncouple a game's save/reload mechanism from the game's response to player failure.

Rationale: A game's response to player failure should be designed into the game rather than be defined by something as arbitrary as when was the last time the player saved the game. Instead of reloading the latest save game whenever the player fails at a particular task, restore the game to a state that is known at design time given the player's progress so far. This makes it possible to divide player progress into milestones without subjecting players to a crippled save system.


Steven Egan said…
I agree with that principle, but there is some relation between the save system mechanics and the responses as the saving system is the default system for responses to player failure. That being the case, all responses to player failure work within the constraints of the saving system.

The points at which the players progress becomes "safe" might be called a permanent save points, while any saves between those points would be temporary in some way. Normally the temporary ones immediately stop gameplay and allow one load. Permanent saves do not give the option to go back and fix mistakes, unless you have multiple copies of the save file.

Progress in the game is measure both in-game via the game mechanics, and outside the game via the saved game mechanics. If you loose your file, you've lost your progress. So, in a way, there will always be a connection between progress and the save system.

When we create a game, we are creating a set of rules to govern an experience. As such, the player must submit to those rules to experience it the way we intend. The temporary save allowing a single load allows the save system to be respectful to the player's time as well as allow the game design control over the progress that is at risk.

So, I must conclude that at the end of the day that the save system is inherently linked to the way the game responds to player failure. The first post that started this discussion specifically pointed out that if allowing permanent saves at any point causes a problem, allow temporary saves as a form of pause.

I must also conclude that to uncouple the mechanics of the save systems and the game's response to player failure requires making them compatible. As I stated at the end of my post, "The saving system is but one part of the game design that must work well with the rest to provide the best gameplay experience for the player." If it doesn't work well with the game's response to player failure, the game experience will suffer.
Adrian Lopez said…
A lot of games do make saving and reloading part of the game's response to player failure, which can lead to confusion whenever people discuss the issue of saving player progress.

People will argue against the loss of player progress by suggesting it's only a side-effect of the kind of restricted save system that due to modern technology is no longer necessary. "Nowadays we can afford to save state at any point in time," they argue, "so forcing players to replay certain segments of the game is just plain wrong."

This can clearly be shown to be false by looking at games that lose progress at a level other than that of the save system. Loss of progress, properly handled, is not a side effect of a flawed save system but a feature that's carefully designed into the game.
Unknown said…
I agree whole-heartedly with Adrian.

A perfect example is the game Dark Souls, which CONSTANTLY autosaves. A sudden blackout would most likely render no loss in progress, as the saves are so frequent. However, the player can only load the most recent save, and the setback punishment is built into the game, leaving the player stuck with whatever happens, good or bad.

This works very well, as there is no worry of frustration from the external factor of the timing of player-induced savestates. This eliminates the unfair and unbalancing punishment for lack of reverence in saving, leaving the punishment to the carefully designed and balanced mechanics of the game's internal setback punishment system.

Good post! I hope to see you start up again, as I am writing a blog with a similar theme, from the angle of effective game design theory through understanding and consideration of the psychology and physiology's proper application in creating games as stimulating aesthetic experiences.

It's currently a black pit of despair, but I plan on posting the hard-science (psychology/physiology) of game design theory very soon.


Popular posts from this blog

Controlling Aspect Ratio in Unity

Don't think "random", think "statistics"

Narrative and Consequences