G   U   N   P   O   I   N   T

Gunpoint’s current save system is rough, but functional if you know how to use it. The game autosaves every ten seconds, and when you die, a message pops up telling you to press L to load the latest one, O to load the one before, or R to start the mission completely. It’s just placeholder, but it’s close to what I want: you should never have to repeat a chunk of progress you’re happy with, only the bit you actually screwed up.

But watching people play at GDC revealed a weird problem. Many people would get a long way through the level, die, and restart it completely. If they want to do that it’s fine, of course, but some of them seemed pretty frustrated. I’d tell them, “You can just press L and it’ll put you back much closer to where you were,” and they’d say “Ah!” and use that from then on.

Obtuse hotkeys are not how the final system will work, of course, but here’s why it’s weird: the message that tells you to press L to load the last autosave is the same one that tells you to press R to restart. If these players hadn’t seen that, how did they know to press R to restart the level?

I discovered they knew the key, they just didn’t know what it would do. Last save? When was that? I’m not gonna hit a button that might take me back three levels.

I could have an on-screen notification every time it saves – maybe a big sign that says “Saving content – please don’t turn off your PC, because apparently there’s some kind of epidemic of people randomly doing that in the middle of a game.” Much as I love patronising bullshit, Gunpoint saves a lot – any notification would be a constant distraction.

I already knew what I wanted, I just hadn’t built it yet: a small menu showing the last few autosaves and how old they are:

I wanted that just because it’s nice, but the GDC problem made it an actual priority. Hurray!

It gets tricky when you think about where to store that data. If you store it as a variable in-game, then how does the game know which one is the most recent when you start it up again? It won’t have that data until it loads one of the autosaves, and each of them thought they were the latest one when they saved.

I tried messing around with renaming savegames so the latest one always had the same name, but it got awkward fast. So did the times themselves. Even seemingly simple systems get complicated to think about and test when you’re dealing with savegames, because loading a savegame is essentially time travel. You’re going back in time, then creating a new parallel timeline from there.

I was handling it, keeping it all straight in my head, until this happened:

Minus what. What.

I had a savegame created 47 seconds in the future. I tried loading it. It was the past – about 15 seconds in the past. And now it claimed the last two autosaves were made at the same time.

I ended up drawing a pen and paper diagram that started to look like the plot of Primer in an attempt to understand how repeated and overlapping backward time travel could create a paradox like this.

It couldn’t.

Sure enough, I eventually found a bug in Game Maker’s time-keeping code that causes the number of seconds since the game started to occasionally reset. I made my own clock, but that behaved strangely for savegames too. It’s just super hard to keep track of time when the player is time-travelling, and the filenames he’s creating and loading can mean different things in different contexts.

The system I settled on picks a new filename for each successive save, so it’s easy for both the code and me to see which one is newest at any given time. And if it has trouble figuring out the save times, it can just look at the numbers – if the save interval is 10 seconds and this one’s 2 saves ago, it’s 20 seconds plus the time since the last autosave.

The last change it needed was one I didn’t expect to have to make. I’d had this great idea, throughout all these systems, to avoid Groundhog Death: the problem where an autosave happens just before you die, so when you load it you instantly re-die. It’s less of a problem with multiple autosaves anyway, but I thought I had a clever way to avoid it completely.

The game would save every 5 seconds, but assume the most recent save was ‘bad’. Only once the player has survived more than five seconds since the last autosave does it become a valid one to load. So with a 10 second save interval, the latest autosave will still be 10-15 seconds ago, but it’s guaranteed to be at least 5 seconds before you died.

Once the rest of the issues were ironed out, I discovered this system sucks. It’s possible, and actually pretty common, to load a point in your game when you did survive beyond five seconds, but you didn’t this time. Maybe you had a guy at gunpoint, or were in the middle of a tense situation, and when it loads you’re disoriented and screw it up.

My instinct as a gamer is not to think “This save sucks, take me further back!” It’s “Let’s go again, I can do this!” But now that we’ve time-travelled, that savegame is the latest one. And the latest one is always left off the load menu to be sure it’s not gonna screw you.

Instead, you feel extremely screwed. You deleted my savegame? The one I just loaded? I get one chance at this, with no knowledge of what I’m getting into, and then you take it away? Fuck you, Tom Francis. You are a shitty, shitty designer.

So I backed out of that: now you can load any save you like, and I give you three just to make sure you’re not screwed in all of them. You can even hammer the ’1′ key to repeatedly retry the same tricky situation if you want to.

Saves are tiny, take no time to create, and load instantly too. I’ve noticed that Gunpoint’s incredibly sudden, sometimes shocking deaths are often a positive thing – a lot of players at GDC would laugh when they got shot. So I never want that buzz to be dampened by the pain of having to repeat stuff you don’t want to, or being screwed by the save system.