Saving Games from Game Designers

David Sirlin offered a great essay at Gamasutra on September 1, 2008. His thesis this time around was that game developers need to stop trying to impose their vision on gamers of when they think players should be permitted to save their games.

As he put it: "Saving should be treated as one of the player's natural rights, not an earned privilege or a game mechanic around which to make strategic decisions."

For the first part of that statement, I agree whole-heartedly. I don't like the "we know what's best for you" attitude when it comes from the usual political social engineers; even less do I need or want it from the designers of the games I play.

As a diehard save-gamer, I was extremely unhappy when I discovered in playing the original Far Cry (for PC) that there was no quicksave/quickload feature. Save and load were implemented; they just weren't made available to the player because the developer had the "we know better than you how you're supposed to play this game" attitude. Fortunately there was a console hack that allowed a quicksave/quickload key-bind or that game would have been dumpstered on the spot... but why should such a gross hack have been necessary in the first place?

Furthermore, as a dedicated PC gamer, the (from my perspective) misbegotten choice being made more often these days to design first for consoles and only later -- if ever -- for the PC means that more games are following the Far Cry no-save-option model. As a result, my gaming experiences are becoming worse, not better. I'm buying fewer games. Isn't that the opposite of what game publishers should be wanting?

Having said this, however, I have to acknowledge I'm not closed to all no-save-option designs. I recently decided to give Call of Duty 4 a try. (Again, this is the PC version.) When I realized that there was no way to save when I wanted to save, I growled something about "Far Cry all over again!" and nearly quit. But out of curiosity I kept playing a little longer... and discovered that the checkpoint system in CoD4 actually worked pretty well. The number and location of the checkpoints was usually close enough to where I would have saved so that I was willing to accept the game's handling of that for me. I still didn't like it, but I could live with it.

So this approach can work, even for someone like me who absolutely hates having a developer's theory about when I "should" be able to save my gameplay experience imposed on me.

It's worth noting, however, that this may not work for all kinds of games. CoD4 and BioShock, for example, are very different kinds of games. A linear shooter intended to be a high-adrenaline experience might be able to justify a checkpoint system rather than a save/load option that could supposedly "interrupt" the visceral experience. (I'm not sure save/reload is any more interruptive than dying and magically restarting at a checkpoint, but let that go for now.) I could accept not being able to save in CoD4 because the pace of gameplay in that particular game made a checkpoint system feel reasonably natural.

But in a slower-paced, more thoughtful and more exploratory game like BioShock, I and, I suspect, most other players want to be able to do what Doug Hofstadter once called "subjunctive replays" -- we want to be able to explore one path, then reload and see what would have happened had we taken a different path. RPGs with branching dialog trees generate a similar desire in players to try all the options to see all of the possible content. Games like these need to reward players who try to explore that content, not punish them for their curiosity.

One approach for accomplishing this would be to provide the traditional save/load feature so that players can -- without having to replay the entire game or level -- see everything the designers spent time making (and for which publishers want $60). Alternately, designers could design games with some kind of explicit subjunctive replay feature that allows the player to scratch that "what would happen if I...?" itch. Why not design exploratory games so that the act of saving and reloading (which a game can easily be programmed to detect) is an active and perhaps even necessary feature of the gameplay? What if reloading wasn't thought of as a punitive "ha! got you!" but as a "hey, if you think that was cool, go back and try it again!"

It might be OK to treat saving as a game mechanic around which to make tactical decisions... if game designers can break out of thinking of saving only as an enemy to be destroyed and start thinking of it as a feature that, for the right kind of game, could be fun to explore and play with.