BLISTER
ONLINE WIKI

Community documentation for Blister Online, build 1327.

System mechanic — read this one

Characters and Saves

How your progress is actually stored, and how to keep it safe · arguably the most important page on this wiki

This covers something the game never explains at all: your save lives only in your browser, and there is exactly one way to get a real copy of it that isn't at the mercy of your browser. Everything on this page exists because of one real incident — see Version History — where a huge amount of progress was nearly lost permanently.

The most important fact on this page

Your character is stored in localStorage, inside your browser, on this one device. It is not backed up anywhere by default. Clearing site data, resetting your browser profile, using a private/incognito window, or your browser evicting storage under disk pressure can all erase it completely — backups included, because the backups described below live in the same storage.

The only copy that survives any of that is a file you download yourself. On the character select screen, every character has a SAVE TO FILE button. Use it. That download is the one piece of your progress that exists somewhere the game itself cannot reach, and therefore cannot lose.

What the character list shows you

  • Name, cash, and Total Level — level, not cash, is what actually tells characters apart.
  • Which game version created the character (a "made in vNNN" stamp) — see the version history caveat below if yours says "made in v356."
  • "last played" — a marker on whichever character you opened most recently.
  • Whether — and when — you last exported the character to a file. Understated for a normal export history; shown in a warning colour only if you've never exported at all.
  • A "save unreadable" warning in place of the usual cash/level line, if that specific character's data is truncated, corrupted, or otherwise fails to parse. Deliberately does not mention RESTORE here — the safety-net backup described below only sometimes exists, and promising a recovery that isn't actually there would be worse than saying nothing.

Managing characters

  • REN — rename. Updates the list entry and the save data together.
  • DEL — delete. Not recoverable. Every row is labelled by name so a delete can't land on the wrong character by position alone.
  • SAVE TO FILE — downloads the character. See "the most important fact," above.
  • LOAD FROM FILE — always creates a brand-new character, never overwrites one. A name collision is auto-renamed ("Name (2)", "Name (3)"...).

Switching between characters mid-session

Going back to select and loading a different character, without closing your tab, has its own long history of leftover state bleeding from your old character into the new one. If you've ever loaded a brand-new character and found something strange — locked in a place you never went, an aircraft you never boarded, a landmark from nowhere — this is almost certainly why. Every instance found has been fixed, but the pattern recurred enough to be worth understanding as a bug class, not a one-off: the teardown between characters clears specific, named pieces of state, and every time a new kind of state was added elsewhere in the game, it was easy to forget teaching this one function about it.

  • A sunken city could appear out of nowhere. Discovering Atlantis on one character left its whole ~26-mesh structure standing in every later character's world that session — and permanently blocked Atlantis from ever spawning again for anyone loaded afterward.
  • A defeated boss could become permanently unsummonable if it happened to be alive at the moment of a switch.
  • A new character could wake up already "aboard the Sun" or "inside the Dream," or inside a building, the casino, the chapel or a home — all survived a switch the same way at one point.
  • A new character's first tap of the interact key could silently teleport them — boarding an aircraft was never cleared either, so the "are you flying? exit the plane" check fired on someone who'd never boarded one.

The safety nets that run automatically

One tab owns the save at a time

Open the same character in a second, newer tab, and it quietly takes over saving — the older tab stops, with a one-time message telling you which tab actually has your progress now. This prevents two tabs from silently overwriting each other.

A safety-net backup, kept only when you might need it

Not on a timer — the game watches your total skill levels instead. Since levels never naturally go down, a save arriving 10+ levels below your best-ever total is treated as a sign something went wrong, and your previous best is kept as a backup. A RESTORE button then appears, labelled with how many levels the backup has; restoring swaps the two rather than discarding either.

Version history

  • The first documented instance of the character-switch bug class — Atlantis and Poseidon persisting/breaking across a switch, as described above.
  • The tab-claim guard — the direct fix for the incident this whole page exists because of: a save silently failing to persist, with nothing telling the player.
  • The high-water-mark backup and RESTORE button, described above — built as "the seatbelt for every other cause" beyond the tab-claim fix.
  • SAVE TO FILE added — the actual point of this page: a copy that exists outside the browser entirely.
  • The "last exported" indicator added to each row.
  • Total Level, then "last played," added to the character list display.
  • Fixed DEL not actually deleting everything — deletion was leaving five pieces of a character behind in storage, including a full duplicate backup save kept forever.
  • The character-switch bug class resurfaced and was swept properly — the Sun, then the Dream, then (once recognised as systemic) all four interiors at once, then the aircraft-teleport case.
  • Every character-row button confirmed to name the specific character it acts on, closing a gap where DEL in particular was previously identified only by list position.
  • Fixed the "made in vNNN" stamp itself being wrong for 206 versions in a row. The internal version number stamped at creation was hardcoded and never updated for a long stretch — every character made during that period is permanently stamped "made in v356," regardless of when it was actually created. Because the stamp is written once and never rewritten, this cannot be corrected after the fact for characters made during that window. (Also a repeat of a bug fixed once before, earlier in the game's history.)
  • A damaged save stopped lying about its own age. Before this fix, a character row that failed to load — a truncated or corrupted save — fell back to the same default text used for a genuinely old character, "pre-v238 character," at exactly the moment a player most needed to know something was actually broken. Found by deliberately corrupting a save and watching the row misreport it. Now reads "save unreadable" instead.
  • Fixed the desktop app losing entire characters between launches, not just recent progress. Three separate bugs stacked on top of each other. The native window's close event never triggered the same save checks the browser version relies on (those are web-page events a native window close doesn't fire at all). Separately and more severely, the desktop app's own local server picked a different network port every single launch — and a browser's local storage is scoped to that exact port, so every relaunch was, invisibly, a completely different storage location with nothing in it, no matter how the previous session had ended. On top of that, the desktop window was launching in a private-browsing mode that doesn't persist local storage at all, regardless of the port. Any one of the three would have caused real loss; together they meant a desktop character could fail to survive being closed and reopened at all. Fixed with a fixed port, private mode turned off, and a real save-on-exit path — and a fourth bug the first attempt at that exit fix introduced (closing the window could hang indefinitely waiting on itself) was caught and fixed before it shipped.

Why all of this exists

Every system on this page traces back to one real event, recorded plainly in the game's own source: the operator lost roughly ten hours and hundreds of levels to a stale tab. The tab-claim guard stopped that specific cause from recurring. Everything after it exists because that incident made clear that "it cannot happen again" isn't a promise a browser-only save system can make on its own — real durability needs a copy the game itself can't touch.

Trivia

  • The backup system deliberately does not trigger on ordinary play — losing levels isn't a thing that happens in this game at all, which is exactly why any drop at all is treated as a technical problem rather than a gameplay outcome.
  • Restoring a backup is designed to never be a one-way door — the save you're leaving is always kept, just no longer reachable through the RESTORE button once it stops being the better option.