Puzzle design research

Saving Puzzle Progress Without an Account

A puzzle that loses your board when you close the tab is not usable for more than one sitting. The obvious fix is an account, which adds friction and a server for no product benefit in a browser-local game. BeanNest instead persists progress locally against a versioned canonical state. The interesting part is not that this works, but how it behaves when the game itself changes after a board has been saved.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

How does a puzzle resume exactly where you left off with no account, and what happens when the game changes underneath a saved board?

This research explains the local progress model used by published BeanNest games. It does not claim cross-device sync, which the product does not provide, and does not describe any storage implementation detail beyond the public contract.

Try it on the anchor product: BeanNest Games /games/.

The canonical-state boundary

The repository requires that game rules and canonical state transitions stay independent of browser surfaces. That means the state that must be saved is defined by the game's own model, not by the DOM or by a storage API. A renderer can change entirely and the save format remains valid, which is what makes a durable local snapshot possible at all.

Versioned snapshots

Published games declare a progress version and a bounded snapshot size. The version is what makes a change recoverable. When a game's state shape changes, the version increments, and a snapshot written by the previous shape can be recognised and handled rather than misread.

What happens when versions disagree

A snapshot from an older version is not silently loaded into a newer model, because the fields may not mean the same thing. The safe behaviour is to detect the mismatch and either migrate deliberately or start a fresh board. The product choice is to be predictable: a player should never see a corrupted board that looks authoritative.

Why the size is bounded

A snapshot has a declared maximum size. That bound protects the player from an unbounded write and protects the game from depending on storage capacity it cannot guarantee. It also keeps the snapshot small enough to move between the synchronous storage path and an embedding host without special handling.

Same-device is a deliberate limit

Progress follows the device, not the person. That is a real limitation and it is stated rather than hidden. The alternative is an account and a server, which contradicts the browser-local privacy position and is not something a single-player puzzle needs. A player who wants to continue on another device gets a new board, and the game says so.

Why this matters beyond convenience

Because progress is local and typed, it also avoids sending puzzle state anywhere. A saved board never leaves the device, which means resuming a puzzle carries no privacy cost. The persistence model and the privacy position are the same decision viewed from two directions.

Why local persistence fits a browser game

A single-player puzzle needs to survive a closed tab and a refreshed page, and nothing more. An account would add a credential, a server, and a privacy obligation for a benefit the product does not offer. Local storage satisfies the real requirement with no infrastructure, which is why the boundary between canonical state and presentation is the only design problem that actually needs solving.

Why the snapshot must be versioned

Game state shapes change as games are developed. A snapshot written by an older shape may contain fields that no longer exist or that now mean something different. A declared progress version lets the game recognise that mismatch and handle it deliberately instead of loading fields into the wrong positions and producing a silently corrupted board.

Why the size is capped

A bounded snapshot protects against an unbounded write and keeps the payload small enough to pass between the game and an embedding host without special handling. A cap also forces the state design to stay compact, which is a useful discipline because a large snapshot usually indicates that presentation detail has leaked into canonical state.

What the same-device limit really means

A player who opens the game on a second device starts fresh, and the game says so rather than pretending otherwise. That is an honest limitation of a local-only design and it is the correct trade for a product whose privacy position is that nothing leaves the browser. Stating the limit is what prevents a player from expecting synchronization the product does not provide.

How the boundary is drawn

Canonical state contains the facts that determine the puzzle: which cells are filled, which notes exist, and what has been completed. Presentation contains how those facts are drawn. The repository requires the first to be independent of the second, which means a saved snapshot describes the puzzle rather than the interface, and a renderer can be replaced without invalidating saved progress.

Why a version is stored with the snapshot

A version lets the game detect that a saved shape came from an earlier release and handle the mismatch deliberately rather than loading fields into positions that may no longer mean the same thing. Without a version, a shaped change would be indistinguishable from a corrupted snapshot, and the game would have no safe way to respond.

What the size bound protects

A bounded snapshot prevents an unbounded write and keeps the payload small enough to move between the game and an embedding host without special handling. The bound also discourages presentation detail from leaking into canonical state, because such leakage usually inflates the snapshot well before it inflates anything a player notices.

Why the same-device limit is stated

A player who opens a second device starts fresh, and the game says so. That is an honest limitation of a local-only design and the correct trade for a product whose privacy position is that nothing leaves the browser. Stating it prevents a synchronization expectation the product does not satisfy, which is more useful than leaving the limit implied.

How the design avoids a server requirement

Because the snapshot is local and describes canonical state, resuming needs no request and no account. That removes a server, a credential, and a privacy obligation that a single-player puzzle does not need. The absence of infrastructure is a consequence of the state design rather than an additional decision.

What the guide does not cover

It does not describe how any specific browser stores data, because that is an implementation detail outside the public contract. It describes the boundary, the version, the bound, and the limit, which are the properties a reader needs in order to understand what the product does.

First-party evidence and provenance

How we checked this

We reviewed the evidence contract and the published progress metadata for a representative game to confirm that canonical state is separated from presentation and that the snapshot is versioned and bounded. We did not read any player's stored data.

Method: We reviewed this repository's evidence contract and the published game metadata, then traced the shipping behaviour to confirm the mechanism described here. We deliberately did not read or publish a hidden solution state.
Environment: Repository source review of the current main branch. No live traffic, account data, or player-identifying information was read.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

docs/gameplay-reconstruction/EVIDENCE-CONTRACT.md
games/bit-balance/game.json