How Browser Arcade Games Save High Scores

When you beat your best score in a browser game, something has to remember it. What that something is — and where it lives — turns out to determine a surprising amount about how a game site can honestly present itself.

This guide covers the actual mechanism, its failure modes, and the consequence that most browser game sites quietly ignore.

The Web Storage API

Browsers expose a simple key-value store called localStorage. It stores strings, it is scoped to the site's origin, it persists across sessions, and — critically — it is never attached to network requests.

That last property is the important one and the most misunderstood. A cookie travels with every request the browser makes to the site, which is what allows a server to recognise a returning visitor. LocalStorage does not travel. It can only be read by JavaScript running on a page from the same origin, and it reaches a server only if a script explicitly sends it.

On this site, no script does. Which means that everything the games remember about you is genuinely, structurally private — not as a policy commitment but as a property of the mechanism.

What gets stored

The whole record for a game is five small numbers. Thirty games is a few kilobytes — well inside any browser's quota, which is typically several megabytes per origin.

The failure modes nobody plans for

LocalStorage is simple, which encourages developers to treat it as reliable. It is not, and it fails in ways that produce genuinely confusing bugs.

1. It can throw on access. Not on write — on access. In some browsers, with site data disabled, merely reading window.localStorage raises a SecurityError. Code that assumes the property exists crashes before it gets to the try/catch around the write.
2. Private browsing varies. Some browsers give private windows a working but ephemeral store; others give one with a zero quota that throws on every write.
3. Quota can be exceeded. Rare for a few kilobytes of scores, but a shared origin with other content can hit it.
4. Stored values can be corrupt. Anything JSON-parsed from storage might have been edited by hand, truncated by a crash, or written by an older version of the code with a different shape.
5. Data can vanish between sessions. Browsers may evict storage under pressure, and a user clearing site data removes everything without warning.

A safe storage layer

The fix is to wrap every access, including the initial availability probe, and to degrade to in-memory operation rather than failing.

The structure this site uses is four rules:

1. Probe once at startup, inside a try/catch, by writing and removing a test key. Store the result as a boolean.
2. Every read and write checks that boolean first and returns a fallback if storage is unavailable.
3. Every read is wrapped in try/catch anyway, because a JSON parse can fail even when storage works.
4. Every read has a typed fallback. A numeric getter returns a number or the default, never NaN and never a string that will silently corrupt arithmetic later.

The result is that a browser with storage disabled plays every game perfectly. It simply cannot remember anything, which is the correct degradation: the feature that depends on storage is lost, and nothing else is.

Only store improvements

A record store should write only when a record improves. That sounds obvious and is frequently got wrong, usually by storing the most recent run's value rather than the best.

The pattern is a compare-and-set: read the current value, compare, write only if the new value is higher, and return whether it changed. Returning that boolean matters — it is what lets the game-over screen highlight which specific records were beaten, which is a much better reward than a generic congratulation.

One subtlety: the comparison must handle a missing value. A first run has no stored best, so the read has to return zero rather than undefined, or the comparison silently fails and the first record is never written.

Why client-stored scores cannot support a leaderboard

Here is the consequence that most browser game sites avoid discussing.

LocalStorage is under the user's complete control. Anyone can open developer tools and set fa:game:burger-rush:bestScore to any number they like. There is no signature, no validation and no way to distinguish a played score from a typed one.

That means a leaderboard built from client-reported scores is meaningless. It is not weakly secured — it has no security model at all, because the value being reported is authored by the person reporting it.

There are exactly two honest options:

• Run a server that validates play sessions. Genuinely hard. Meaningful validation means replaying inputs server-side or accepting a well-designed heuristic and an ongoing arms race with people who find it interesting to beat.
• Do not publish rankings. Store records locally, label them as local, and say why.

This site takes the second. Every score display here reads "your local best", the popular games page ranks by your own play history rather than an invented global figure, and no page on the site carries an aggregate rating in its structured data — because we have no rating system and inventing one would be a lie told to a search engine.

It is a genuine loss. The social dimension of a shared high-score table was one of the best things about the arcade era. But an invented number is worse than an absent one.

LocalStorage compared with the alternatives

For a few kilobytes of scores, LocalStorage is the right choice: synchronous, trivially simple and more than large enough. IndexedDB is the correct tool if you ever want to store replays or a large history, but it is asynchronous and considerably more code.

Cookies would be actively wrong here. Sending a score on every request accomplishes nothing except making the request larger and creating a privacy footprint the site does not need.

What a player should know about their own data

• It is on one device, in one browser. Your best score in Chrome on a laptop is invisible to Firefox on the same laptop, and to your phone.
• It can be deleted at any time. Clearing site data removes it. There is no backup, because there is no server-side copy.
• Private windows usually will not keep it. The game plays fine; it just cannot remember.
• Nobody else can see it. Not the site operators, not advertisers, not other visitors.
• You can edit it. Nothing stops you. It is your browser and your data — which is exactly why it cannot support a ranking.

Designing records worth keeping

Since there is no leaderboard, the records have to be motivating on their own terms. Three design decisions help.

1. Track several dimensions, not just score. Best score, best food count, best combo, best distance, best time, total runs. A run that scored poorly may still have set a distance record, which keeps progress visible.
2. Highlight what improved. The game-over screen marks each beaten record individually rather than showing a generic message.
3. Show the records before the run. The ready screen displays your current best, so the target is in mind before you start rather than only after you fail.

Those three together are a reasonable substitute for a leaderboard: the comparison is against yourself, but it is specific, multi-dimensional and always visible.

Frequently Asked Questions