Puzzle design research
How BeanNest Pins a Deterministic Daily Puzzle Board
A Daily puzzle is only fair if two players on the same date see the same board. That sounds trivial, but it rules out a surprising amount of ordinary game code. If a board is generated when the page loads, two players refreshing at different moments can receive different boards, and a shared result becomes meaningless. BeanNest handles this by pinning each dated board to a deterministic derivation rather than generating it live.
What this guide helps you decide
Why does every BeanNest player get the same Daily puzzle on the same date, and how is that actually enforced?
This research explains the deterministic board model used by current published BeanNest puzzle games. It does not publish a solver witness, a hidden answer map, or a seed value that would let a reader skip a live puzzle. The play pages remain the place to solve an actual board.
Try it on the anchor product: BeanNest Games /games/.
What a Daily puzzle actually promises
A Daily board makes a specific, checkable promise: for a given calendar date, every player receives an identical starting position. The promise is what makes comparison meaningful. If two people message each other about today's board, they must be describing the same cells, the same clues, and the same constraints. Once a board can differ between players, the Daily format stops being shared and becomes an ordinary practice mode with a date label attached.
Why generating at page load breaks the promise
The obvious implementation is to build a board when the page opens. That approach fails for three separate reasons. First, any randomness read at load time can differ between two players, so the same date yields different boards. Second, a board generated from a clock reading can change meaning across time zones, so a player just after midnight sees a different board than a player just before it. Third, an expensive generator can fail or be interrupted, leaving a player with a partially built board and no clear recovery. A Daily board has to be a value, not a process.
The pinned-derivation model
The model BeanNest uses treats the date as the input to a deterministic derivation rather than to a random generator. A specific date maps to a specific board, and the same date always maps to the same board. Nothing about the page load, the device, the network, or the moment of arrival can change the result. The board can still be difficult, and it can still be verified as solvable, but it cannot be different for two players who share a date.
Reproducibility requires verifiability
Pinning a board is only half the job. The board also has to be solvable, and that has to be established for the pinned value rather than assumed from the generator. In the current repository, game contracts separate the canonical puzzle state from the presentation layer so the same board can be checked against the same rules outside the browser. That separation is what allows a reviewer to confirm a Daily board is solvable without reproducing a player's session.
What this means for a player
For a player, the practical consequences are narrow and reassuring. A Refresh does not reshuffle the board. Changing device does not change the puzzle. A friend on another continent working the same date sees the same board. Progress saved locally attaches to that pinned board rather than to a regenerated one, so a resumed session continues the puzzle the player started. None of this requires an account, a server call, or a shared database.
What this deliberately does not do
The model does not claim to prevent every form of solving assistance, and it does not pretend a Daily board is secret. Anyone can solve the board and describe it. What the model protects is fairness of the starting position, not secrecy of the answer. That distinction matters because a walled-off board would defeat the shared-comparison purpose that makes a Daily format worth publishing in the first place.
Why a date is a better input than a random seed
A random seed produces variety but not reproducibility, because two players cannot be guaranteed to draw the same seed. A date is shared, checkable, and requires no coordination: two people on the same calendar day already have the value in common. Using it as the derivation input gives variety across days and identity within a day, which is exactly the property a Daily format needs.
How verifiability is separated from play
The repository requires canonical puzzle state to stay independent of the presentation layer. That separation means the same board can be evaluated against the same rules by a reviewer, a test, or a solver, without running the browser experience. A pinned board is therefore checkable for solvability before it is ever served, which is what turns reproducibility into a guarantee rather than a hope.
What a player can and cannot conclude
A player can conclude that their board matches every other player's board for that date, because the derivation is deterministic. They cannot conclude that the board is unique in the world or that nobody has seen it before, because the date is public and the derivation is not secret. The guide states the achievable guarantee rather than a stronger one.
Why progress attaches to the board
Because the board is a value for a date, a saved snapshot can be tied to that value. Resuming restores the same board rather than regenerating one, which is what makes saved progress meaningful. If the board were generated at load time, a resumed session could legitimately restart with a different puzzle, and the saved state would be describing a board that no longer exists.
Why the Daily promise is worth the constraint
A shared board creates a small social surface: two people can compare an experience without exchanging coordinates or a saved state. That surface exists only if the board is identical, which costs the implementation some freedom, because generation must be rule-driven rather than random. The guide frames the constraint as the price of the feature rather than as an accidental limitation.
How the constraint interacts with verification
Because the board is derived rather than generated, a reviewer can derive it too and check it against the same rules, which is what makes solvability verifiable before publication. If the board were random at load time, verification would have to run the generator and trust its internal checks. Determinism therefore buys not only fairness but also an auditable release process.
What the model deliberately leaves out
It does not address hints, difficulty selection, or scoring, because those are separate design questions with their own evidence. Keeping them out of scope lets the guide make one precise claim about board identity rather than a broad claim about the whole Daily experience. The paired guides in this cluster cover the adjacent questions under their own contracts.
How a reader can check the claim
Opening the same route on two devices on the same date should present the same board, and a refresh should not change it. Those two observations test the promise directly without special tooling. The guide recommends them because a claim about identity should be verifiable by the person reading it.
How the derivation is bounded
Deriving a board from a date means the board is a function of the date and the game's rules, so the set of possible boards is the set the generator can produce. That is a real constraint: a deterministic derivation cannot reach a board its generator cannot construct. The guide states the bound because it explains why the property is achievable at all, and why a generation step is still required somewhere in the pipeline.
Why the date is used rather than a random seed
A random seed produces variety across runs but no shared value between players, so two people would have to exchange the seed to compare. A date is already shared and requires no coordination, which is why it is the natural input. Using the date also means the board changes on a predictable boundary rather than whenever a generator happens to run.
How saving interacts with the derived board
Because a board is a value for a date, a saved snapshot can be tied to that value and a resume restores the same board. If the board were generated at load time, a resumed session could legitimately start a different puzzle and the saved state would be describing something that no longer exists. The determinism is therefore what makes the save meaningful rather than merely convenient.
What the guide leaves to the other cluster guides
It does not address hints, difficulty, scoring, or persistence, because those are separate questions with their own evidence. Keeping each guide to one precise claim is what lets a reader check them individually rather than judging a broad statement about the whole Daily experience.
First-party evidence and provenance
How we checked this
We reviewed the current BeanNest evidence contract and the published Bit Balance game metadata, then traced the shipped Daily behavior to confirm that a dated board is a pinned deterministic value rather than a page-load generation. We verified that canonical puzzle state is separated from the presentation layer so the same board can be checked against the same rules outside the browser. We deliberately did not read a hidden solution state or publish any seed.
- 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
- Reviewed by
- BeanNest Studio
Repository evidence artifacts:
docs/gameplay-reconstruction/EVIDENCE-CONTRACT.mdgames/bit-balance/game.json