A game that takes an evening to finish has to remember you, because nobody finishes it in one sitting. A game that takes four minutes does not, and adding it would be work in the wrong place.
Our painted adventure is the first kind. Here is what it writes down, and why the list is so much shorter than you would expect.
Where it goes
There is no server in any of our builds. The game is one HTML file, opened from a link, and nothing is transmitted anywhere.
Browsers provide a small amount of storage attached to a site on a device, which any page from that site can read and write. It holds text. That is the whole mechanism: the game turns its state into a line of text, puts it in the box, and reads it back the next time the page opens.
Two consequences worth being straight about. The save lives on that device, so opening the game on a different phone starts fresh. And it survives closing the tab, closing the browser and restarting the machine, but not clearing site data.
For a game given to one family as a keepsake, that is the right shape. An account system would be a login screen standing between a child and a bear, which is a poor trade for cross-device sync nobody asked for.
What gets written
This is the part that takes the thought. The save in our adventure holds roughly a dozen fields, and none of them is a picture of the world.
Where you are, as the name of a location. How many buttons you have collected. How many tickets you have left. A set of places already visited. A set of things already found. Counts of letters and clues. The notes you have picked up. Whether you have met Grandad yet. The journey so far, and a small block of statistics.
From those facts the entire world can be rebuilt. The scene is constructed from the location name. The map redraws its route from the journey. Doors that should be open are open because the thing behind them is in the found set.
What is deliberately not in there: any character's position, anything in motion, anything currently animating, anything that can be worked out from something else already listed. A save containing a character halfway through a jump has to be capable of restoring a character halfway through a jump, and that is a category of bug nobody needs.
The rule is: store the smallest set of facts the world can be regenerated from. Everything else is derived on load.
Two saves, not one
The game keeps a second, separate save for audio settings: music mode, whether ambience is on, whether narration is on, and three volume levels.
Splitting them is deliberate. Settings and progress have different lifetimes. Somebody starting a new game should keep their volume preferences, and somebody who has muted the music should not have that undone by finishing a chapter. Putting both in one object means every change to either rewrites both, and a bug in one can lose the other.
It is a small thing and it is the kind of small thing that shows up as a complaint six months later.
Everything is wrapped
Every read and every write in the save code sits inside a guard that swallows failures.
This is not defensive habit, it is because failure is normal here. Private browsing modes can refuse to write. A device with no space left throws rather than silently dropping. A save written while the tab was being closed can be half a line of text that does not parse. Browsers can be configured to block site storage entirely.
In every one of those cases the game must do the same thing: behave exactly as if this were a first visit. Start at the beginning, offer a new game, say nothing. A game that shows a child an error about storage quota has failed at something more important than saving.
The load routine also fills in a default for every field it reads, rather than trusting what it finds. A save written by an earlier version of the game will be missing fields the current version expects, and the game has to survive that too, because the family playing it did not upgrade anything on purpose.
Continue is a real decision
The title screen shows a Continue button only when a save exists. That check is a single test for the presence of the stored value.
It sounds trivial and it is the most important line in the feature. A Continue button that is always visible, and that does nothing or starts a new game when pressed, is worse than no Continue button. Showing it conditionally means its presence is information: it tells you the game remembers you, before you have to find out by pressing it.
The mirror of that decision is worth noting too. We had a case during testing where the game resumed at an airport because of a save from a previous session, and the level select had to be used to get back to the earlier chapters. That is correct behaviour and it is also a reminder that a save is a thing a tester has to think about, not just a player.
What this means for a commission
Saving is a length decision, not a quality one. A game with a single level does not want it. The question is whether anyone will put this down before finishing it, and that follows from the brief.
It costs less than people expect and more than it looks. The write is one line. Deciding which dozen facts belong in it, and making the load survive every version of the file that has ever existed, is the actual work.
It only exists because the game is big enough to need it. Our adventure runs across two continents and 502 illustrations, which is why it is also the largest thing we have built. That relationship is in why one game is 104KB and another is 20MB, and the build itself is documented in how we built a painted London adventure.
And it is one more thing that has to be tested rather than assumed. Ours is, along with everything else in proving a game is actually finished.
