Autosave Blues

This topic has been sitting in the backlog for a while, and although nothing major has catapulted it to the forefront, a few comments about recent games tipped the scales. Plus after several more abstract position pieces, I wanted to get back to something very tangible. Let's talk about autosave and how pretty often, it sucks. And sometimes, it really sucks.

"Are you sure you want to quit? Any unsaved progress will be lost."

We've seen various instances of this phrase in countless games. We vaguely understand what it means, but if you really break it down, useful information in that message is tragically absent, especially if the game relies exclusively on autosaving.

Imagine that message appearing in a game where saving manually was not possible. You want to stop playing, but it immediately casts doubt on your intended action. "If I quit, what am I going to lose?" the player may ask. This certainly doesn't provide that information, and likely there's no way to ascertain that information at all. Worse, this message appears any time you quit, whether or not the game saved one second before this message was triggered. Even if there's no unsaved progress to lose, this message is still ambiguous about what consequences, if any, will occur as a result of this action. Simply, this is not a well designed interaction.

This is the kind of message that's build to satisfy TRCs/TCRs, not to actually provide a good, usable experience for the player. So I've compiled a set of thoughts/principles/whatever, in an attempt to encourage others to be a bit more conscientious. This seemingly inconsequential feature actually matters a great deal to broad playability of your game.

0) Let players save whenever they want

This is totally side-stepping the issue, but honestly, it's not an outlandish request. It should be really, seriously considered as to what benefits players will get with an exclusively automatic save system. Taking away manual control completely is a dangerous proposition and one that should only be considered if it has real, tangible benefits. Saying, "Well, now the player won't have to worry about it" usually just means "this is easier to implement" and will usually result in the player worrying about it more, not less.

Now, there are genuine gameplay complications to a general save-anytime system. Turn-based tactics games like Final Fantasy Tactics Advance don't offer a save/load within any particular battle. Doing so would encourage micro-optimizing every single turn, which might lead to a more successful battle in the long run, and also gives players tool for creating boring, tension-less fights. But rather that offering no save features at all, they have a one-time save slot (especially important since it's a portable game which needs to be safely turned off any almost any time). Saving mid-battle quits immediately after the save and loading that file restore precisely to that point and then deletes the save. Essentially, it does just what a save is meant to and restores that game state. While popular amongst mobile games, this feature is certainly a viable option for games where saving anytime is not viable. But really, most of the time, you should just allow players to save anywhere.

1) Let people know what happens if they quit

Alright, enough deflection. If an autosave system is a must, it's vital to let players know what happens when they quit. And this does not mean saying "Any unsaved progress will be lost." At the very least, let the player know when the save occurred. That information is available to you, and easily. Even that simple addition makes "Any unsaved progress will be lost (last save was 30 seconds ago)." so, so much more useful to the player. But ideally the player will know far more specifically what "unsaved progress" really consist of, which leads to ...

2) Provide consistent autosave behaviour

The indelible Chris Remo was discussing Crysis 2 on Twitter, relating that he found the exclusively autosave system very frustrating (especially for a freakin' PC game and considering you could quicksave anywhere in the first Crysis). He said he'd play for ~20 before work in the morning, but when it was nearing time to go, he had no idea how long he had to continue playing before he'd be able to save again. Two minutes? Five? Twenty? Such information was totally invisible to the player.

I'm sure we've all had a similar experience. Gotta dash out, partner needs help in the kitchen, etc. We're forced to either leave the game paused (not often viable) or spout the repugnant, "Just a minute, I have to get to a save point."

At the least, make those autosave moments evenly spaced. Either literally, as in every 5 minutes, or after some very specific and readable events. Having to just stumble blindly forward, hoping you cross that trigger soon, is basically unacceptable.

3) Make autosave part of another system and obvious

At the very least, try to make autosaves part of another readable system. In DeathSpank respawning from death and loading from a save were the exact same action. I think (hope?) that consistent behaviour made it obvious to players who'd saved and loaded once what future behaviour would be like. If your autosaves occur after any level or changing map, that's better than it being tied to random checkpoints or worse, completely invisible (you laugh, but more games than you'd think have done that).

This may seem like a quibble, but really, it's important. Developers don't see it much, since we've got command line options, debug cheats and a heap of other things. But for players that have to just start at the beginning and go until the end, this can be a big deal. How many reviews of the otherwise excellent Costume Quest negatively mentioned its autosave system? How many FAQs and forums have that same question?

I wrote a good chunk of DeathSpank's autosave behaviour, and honestly, it's not that hard. And we had all kinds of ugly issues to resolve. E.g. dependent sets of gamestate variables and conversation variables that would get set during a conversation but if the console was rebooted before the conversation was over, those would fall out of the sync and it would be impossible to progress in the game. Finding reproduction steps for those bugs, before we realized what the general issue was, was not fun at all. But even then, it was manageable and something that basically myself and our system engineer were able to hand. Nobody has any good excuse not to do this well.

It's easy to skim on basic usability like this, because it's one of those things that only gets mentioned if it's bad. Nobody praises a good autosave system. But unsung valour is sometimes the most important. A poorly implemented autosave system can be one of the biggest sources of frustration for an audience. Sorry folks, this is one of those things we just gotta suck up and do right. At you know, at least not awful. It's really not that hard.

(As a footnote, I updated yesterday's post to include a link to a second podcast I recorded over the weekend. It's Graham and I talking about the burgeoning Vancouver indie dev scene. Being such topics are near and dear to my heart, I thank you for indulging this extra linkage and encourage you to give it a listen)