Save Systems and Progress: How Browser Games Solved (or Didn't) Saving Your Game
Console games had memory cards. PC games had a file system to write to. Browser games, running inside a sandboxed plugin on someone else's website, had neither, and every developer who wanted a player to pick up where they left off had to improvise.
A Flash game ran inside the Flash Player plugin, which for good security reasons was deliberately sandboxed away from a visitor's file system. A game could not simply write a save file to the desktop the way an installed PC game could, and the browser tab hosting it offered no equivalent of a console's memory card slot. Any developer who wanted a player's progress to survive between sessions had to work within a narrow set of tools the platform actually provided, and a surprising number of games simply did not bother, treating each session as a fresh, self-contained arcade run with no persistence at all.
Local Shared Objects, the closest thing Flash had to a save file
The mechanism Flash did provide was the Local Shared Object, informally and widely known as a "Flash cookie," a small piece of data the Flash Player could write to and read from a reserved location on the visitor's own computer, functionally similar to a browser cookie but managed by the plugin rather than the browser itself. A game could write high scores, unlocked levels, or player settings into a Local Shared Object and read that data back the next time the same player opened the same game in the same browser on the same machine. This was genuinely useful and widely adopted for exactly the kind of light persistence most Flash games needed — a high-score table, a "levels unlocked" flag, a settings preference — but it came with real limitations that shaped what developers built around it.
Local Shared Objects were tied to the specific browser and computer that created them, meaning a player who switched from a home computer to a school computer, or simply cleared their Flash Player storage the way privacy-conscious users increasingly learned to do, lost everything without warning. There was no account, no login, no way to recover the data once it was gone. For a short arcade-style game this barely mattered. For a longer game with real investment — hours of unlocked content, a built character, a completed collection — it was a genuine risk that some players discovered only after the fact, when a routine cache clear wiped out progress they had assumed was safely stored.
Portal accounts as the more durable alternative
Portals with their own user account systems offered a more reliable answer by moving save data off the player's local machine entirely and onto the portal's own servers. Kongregate's developer API, for instance, let games hosted on the platform call functions that stored player statistics and progress tied to a Kongregate account rather than to Local Shared Object data sitting on one specific computer, which meant a player's progress in a supported game followed them across devices the same way modern cloud saves do. This required a developer to specifically build against a given portal's API, which meant the same game distributed across a dozen syndicated portals often had cloud-saving on the one platform that offered the integration and none at all on the others hosting the identical file.
Level codes and the password workaround
A third approach sidestepped the storage problem entirely by putting the burden of remembering progress on the player. Some games, particularly those built with an audience of shared or public computers in mind, generated a password or level code at the end of each stage that a player could write down and re-enter later to resume from that point, borrowing a convention from console games of decades earlier that predated reliable in-console saving. This was clunky compared to an automatic save, but it was also completely immune to a cleared cache or a different computer, since the entire save state lived in a string of characters the player kept in their own head or notebook rather than anywhere on a machine.
What replaced all of it
Modern web technologies made this entire category of workaround largely unnecessary. Browser-native storage APIs such as localStorage, documented today in reference form on MDN's localStorage page, give any web page a straightforward way to persist data on a visitor's device without a plugin-specific mechanism like Local Shared Objects standing in between, and account-based cloud saving is now a default expectation across nearly every platform rather than a portal-specific bonus feature. The Flash-era save landscape, split awkwardly between fragile local storage, portal-specific accounts, and manually copied passwords, is a reminder of how much infrastructure modern web games now take for granted.