Save me!

Originally published 2007 in Atomic: Maximum Power Computing
Last modified 03-Dec-2011.

 

You buy a new game. It pretty much works, but saving takes a while, and the save files are three hundred megabytes.

Five patches for the game come out over the next year, but not a one of them does a thing to fix the save problem.

When you look at where the space on your hard drive's going, the game folder now contains the original one gigabyte of game, plus six gigs of save files.

W, you may be wondering, TF?

Like pretty much everything else in programming, saving games is trickier than it looks. But all a game's save function has to do is, well, function, to pass muster with the average game reviewer. So saving elegantly is not high on the list of priorities of the slavedrivers in charge of most game development.

And this, in brief, is why a lot of games have half-baked saving.

For some games, saving is easy. A good old-fashioned adventure game, say, may be able to save the entire game state in a handful of bytes. Where you are, what you've got, status of anything you've changed in the game; done.

Turn-based games of all kinds also have a beautifully quantified game world. It'd take some pretty inspired programming to make a save-file for a game of chess larger than 64 bytes. Actually, 16 uncompressed 8-bit bytes would be perfectly adequate, if all you wanted to save was the board positions and whose turn it was. Your save file could just consist of a string of binary digits, with four bits per square. That'd give you 16 possible settings for each square, when all that can actually be on any given square is one of the 12 pieces, or nothing.

(A reader's now pointed out to me that if you want to follow all of the rules of serious chess - repetitions-draw, time limits, initial and special timing conditions - you need a bit more data. Portable Game Notation is a popular human-readable format that implements much of this. See what I mean about things always being trickier than they look?)

This principle scales up, too. Even if there are zillions of entities in your giant game of Civilization VIII, they each have a definite state and location that can be summed up in very little data, and saving and restoring should therefore be simple.

If you're old enough to remember games that gave you a cryptic code every time you passed a level, be advised that sometimes that string of letters actually encoded the game state. That's right - the save game was short enough that you could just jot it down.

Things are different, though, in our brave new world of huge 3D First Person Shooter and Real Time Strategy games. As games have grown, save schemes have had to develop too. There are now some frightfully clever ways to save a game.

If the game you're playing doesn't use one of them, here's what it may be doing.

Probably the simplest way to save a game is to grab all of the memory that the game engine's looking at, and dump it to a file.

The problem with this is that, by definition, it makes a save file as big as all of the memory the game's using. That works A-OK if you're playing some old arcade or console game in an emulator on your PC; the total size of the "virtual machine" created by those emulators is almost always laughably small by modern standards, so it's easy to just hit a hotkey, freeze the machine status, and write it to a file for later reloading.

For modern PC games, though, the total game status can be many hundreds of megabytes. Gigabytes, even, for a game with tons of entities, like a true-3D RTS game.

Now, that data is probably quite compressible. But compressing a few hundred megabytes of save, even if it's more compressible than everyday plain text, is likely to take at least a minute on a fast dual-core PC, or several minutes on Joe Average's old Dell. And things can get much worse if there isn't much system RAM available - which will of course probably be the case, because you haven't finished saving that giant slab of game data yet.

So big, "airy", save files it is.

And before you know it, the game directory's 12 gigabytes.

(If you're wondering why even a first-person-shooter game can't just take a snapshot of every object in the world and save that, Civilization style, I suggest you take a photograph of a person juggling and then attempt to use it to teach another person how to juggle.)

A less painful way of implementing saves is to only allow them at certain spots in the gameplay - the dreaded console-style "save points". Save points are, or at least were, a console staple precisely because they let the game store its status quickly and in a small amount of memory - which is all the memory that pre-hard-drive consoles had. At the save point, all "pending" situations in the game are resolved or reset to their defaults (depending on the type, and quality, of game...), and the player status is static and thus easy to save in a small amount of space, just as with a turn-based game.

Today, save points are seldom strictly technically necessary, and are often a large pain for less committed gamers who're likely to just give up if they have to play ten minutes of the same darn level over and over again to reach a boss who keeps killing them.

But from a programmer's point of view, save points still have considerable attraction. And you can't blame the programmers for where the save points end up being located.

"Journaling" is another simple way to save - actually, it's probably the best of the simple save techniques. It gets around the vast-files problem, and it also lets you save anywhere in the game you like. To make a journaled save, a game simply records all of the user input. That, plus a little more information about player status and each journal's starting point (starting points are very similar to save points), constitutes the save file.

When you load a journaled save, the game starts from whatever the right point is - probably the start of a level. Then the game simply reads the journal data into its control input, with graphics and sound turned off, and silently plays back all of your actions until it gets to the place where you saved.

Journaling gives quite a small save file, and very fast saves. In effect, it's saving constantly as you play, so there's little more for the game to do when you actually press the "save" button.

But loading the game can take forever, because of the silently-playing-back thing. If a save file that's only ten seconds into a new level loads much faster than one that's ten minutes in, you're probably looking at journaling.

(Journaling is also the standard technology for game recordings, the surprisingly small files that let you watch someone else's RTS or FPS game session like a movie on your own copy of the game. You often can't rewind a recorded game, because most real-time game engines can't run backwards.)

So why, in the final analysis, do patches for games that don't have decent save functions usually not improve those functions?

Because to add intelligent saving you have to grovel over the game's code, giving everything that needs saving the ability to export its status and import it again later. That's why.

These sorts of changes can take a lot longer than writing proper save code in the first place. And it's not worth it for a "finished" game. Not many customers are likely to be waiting for the developers to speed up the save/load function before they'll buy a game.

But all this is still kid stuff.

If you really want to make game developers crazy, ask them about multiplayer saves.

Other columns

Learning to love depreciation

Overclockers: Get in early!

Stuff I Hate

Why Macs annoy me

USB: It's worth what you pay

"Great product! Doesn't work!"

The virus I want to see

Lies, damned lies and marketing

Unconventional wisdom

How not to e-mail me

Dan's Quick Guide to Memory Effect, You Idiots

Your computer is not alive

What's the point of robot pets?

Learning from spam

Why it doesn't matter whether censorware works

The price of power

The CPU Cooler Snap Judgement Guide

Avoiding electrocution

Video memory mysteries

New ways to be wrong

Clearing the VR hurdles

Not So Super

Do you have a license for that Athlon?

Cool bananas

Getting rid of the disks

LCDs, CRTs, and geese

Filling up the laptop

IMAX computing

Digital couch potatoes, arise!

Invisible miracles

Those darn wires

Wossit cost, then?

PFC decoded

Cheap high-res TV: Forget it.

V-Pr0n

Dan Squints At The Future, Again

The programmable matter revolution

Sounding better

Reality Plus™!

I want my Tidy-Bot!

Less go, more show

In search of stupidity

It's SnitchCam time!

Power struggle

Speakers versus headphones

Getting paid to play

Hurdles on the upgrade path

Hatin' on lithium ion

Wanted: Cheap giant bit barrel

The screen you'll be using tomorrow

Cool gadget. Ten bucks.

Open Sesame!

Absolutely accurate predictions

The truth about everything

Burr walnut computing

Nothing new behind the lens

Do it yourself. Almost.

The quest for physicality

Tool time

Pretty PCs - the quest continues

The USB drive time bomb

Closer to quietness

Stuff You Should Want

The modular car

Dumb smart houses

Enough already with the megapixels

Inching toward the NAS of our dreams

Older than dirt

The Synthetics are coming

Pr0nBack!

Game Over is nigh

The Embarrassingly Easy Case Mod

Dumb then, smart now

Fuel cells - are we there yet?

A PC full of magnets

Knowledge is weakness

One Laptop Per Me

The Land of Wind, Ghosts and Minimised Windows

Things that change, things that don't

Water power

Great interface disasters

Doughnut-shaped universes

Grease and hard drive change

Save me!

Impossible antenna, only $50!

I'm ready for my upgrade

The Great Apathetic Revolution

Protect the Wi-Fi wilderness!

Wi-Fi pirate radio

The benign botnet

Meet the new DRM, same as the old DRM

Your laptop is lying to you

Welcome to super-surveillance

Lemon-fresh power supplies

A>B>C>A!

Internet washing machines, and magic rip-off boxes

GPGPU and the Law of New Features

Are you going to believe me, or your lying eyes?

We're all prisoners of game theory

I think I'm turning cyborg-ese, I really think so

Half an ounce of electrons

Next stop, clay tablets

A bold new computer metaphor

Won't someone PLEASE think of the hard drives?!

Alternate history

From aerial torpedoes to RoboCars

How fast is a hard drive? How long is a piece of string?

"In tonight's episode of Fallout 4..."

How hot is too hot?

Nerd Skill Number One

What'll be free next?

Out: Hot rods. In: Robots.

500 gig per second, if we don't get a flat

No spaceship? No sale.

The shifting goalposts of AI

Steal This Education

Next stop: Hardware piracy

A hundred years of EULAs

The triumph of niceness

The daily grind

Speed kings

Alt-tCRASH

Game crazy

Five trillion bits flying in loose formation

Cannibalise the corpses!

One-note NPCs

Big Brother is watching you play

Have you wasted enough time today?

The newt hits! You die...

Stuck in the foothills

A modest censorship proposal

In Praise of the Fisheye

Filenames.WTF

The death of the manual

Of magic lanterns, and MMORPGs

When you have eliminated the impossible...

Welcome to dream-land

Welcome to my museum

Stomp, don't sprint!

Grinding myself down

Pathfinding to everywhere

A deadly mouse trap

If it looks random, it probably isn't

Identical voices and phantom swords

Boing!

Socialised entertainment

Warfare. Aliens. Car crashes. ENTERTAINMENT!

On the h4xx0ring of p4sswordZ

Seeing past the normal

Science versus SoftRAM

Righteous bits

Random... ish... numbers

I get letters

Money for nothing



Give Dan some money!
(and no-one gets hurt)