Puzzle design research
One Signature Rule Beats a Reskin
A grid with numbers can be filled in dozens of ways, and most of those variations are cosmetic. The difference between a real puzzle and a reskin is not the theme, the palette, or the board size. It is whether the player is asked to make a new kind of decision. BeanNest applies one test: each game must state a signature rule that changes what counts as a legal move.
What this guide helps you decide
Many grid puzzles look similar. What makes one a distinct game rather than a themed copy of another?
This research explains the design constraint BeanNest applies to published puzzle games. It does not claim every published game is equally distinct and does not evaluate competitor games.
Try it on the anchor product: BeanNest Games /games/.
What a reskin actually is
A reskin keeps the rule set and changes the presentation. The board still fills the same way, the win condition is unchanged, and the deductions the player makes are identical. Playing it teaches nothing new and the difficulty is inherited rather than designed. The player notices this quickly, which is why reskins rarely hold attention even when they look polished.
What a signature rule changes
A signature rule is a constraint that alters the set of legal completions. It is a rule a player can state in one sentence and then use to derive a forced move that would not exist under the base rules. When the rule is removed, the puzzle collapses back to its ancestor, which is the test that the rule is doing real work.
The test applied to a real constraint set
Consider a binary grid puzzle whose published metadata declares three constraints together: every completed line balances its two symbols, no line contains three identical consecutive symbols, and every completed line stays unique. Each constraint independently forces moves. Balance forces the remainder once one symbol reaches its quota. The no-triples rule forces the middle of a two-and-a-gap pattern. Uniqueness forces the last cell once a line is one value away from an existing line.
Why one rule beats several
Several unrelated constraints can produce a puzzle that is hard to explain and hard to teach. One well-chosen rule that combines with the base rules produces depth without explanation cost. The design preference is for the smallest rule set that still changes the decision space, because a player who understands the rule can reason rather than guess.
How this shows up in the shipped contract
Each published game carries metadata that states its rules, its controls, and its modes, and the repository's evidence contract requires that described behaviour match what the release can demonstrate. A signature rule therefore has to be a claim the game can substantiate, which rules out decorative rules that never actually constrain play.
What this is not
This is not a claim that originality guarantees quality, and it is not a claim that every BeanNest game is equally original. It is a stated design constraint that can be checked against the published rules of any game on the catalog, and the games that fail it should be treated as candidates for rework rather than as finished work.
Why players detect a reskin quickly
A player who has solved one grid-filling puzzle already knows the deduction pattern. On a reskinned board the same reasoning works immediately, and the new theme does not create new decisions. The experience is thin because the interesting part, discovering the rule and its consequences, has already happened elsewhere. That is a product problem rather than an aesthetic one.
How to test whether a rule is doing work
State the rule in one sentence, then ask whether a forced move exists that would not exist without it. For balance, the quota forces the remainder once one symbol is exhausted. For the no-triples rule, the middle of a split pair is forced. For uniqueness, the last unresolved cell is forced against an existing line. Each passes the test, which is why the constraint set is described as a signature rather than as decoration.
Why fewer rules can produce more depth
Each rule a player must learn adds explanation cost. A small set of rules that interact produces depth without that cost, because the player combines a few remembered facts rather than consulting a list. The design preference is therefore for the smallest rule set that still changes the decision space, and the guide states that preference as a design constraint rather than as a claim about any specific game.
Where the constraint is enforced
The repository's evidence contract requires that described behaviour match what a release can demonstrate, and each published game declares its rules in metadata. A decorative rule that never actually constrains play would be a claim the game cannot substantiate, so the contract itself discourages the failure mode this guide describes.
Why a reskin feels familiar before it feels shallow
The recognition happens first, because the board and the fill mechanic look immediately familiar. The shallowness registers later, when the player notices that the new rule only changed the appearance. That delayed realisation is why reskins can look appealing in a screenshot and disappoint in play, and why the guide tests for a rule that changes the decision space rather than for visual novelty.
How the forced-move test works
State the rule, then look for a deduction that would not exist without it. Each constraint in the reference set passes: the quota forces remaining cells once one symbol is exhausted, the no-triples rule forces the middle of a split pair, and uniqueness forces the last cell against an existing line. A rule that produced no such deduction would be decorative regardless of how it sounded in a description.
Why interaction between rules matters more than count
Two rules that interact produce deductions neither would produce alone, which is where depth comes from. Adding rules that sit beside each other without interacting increases explanation cost without increasing the reasoning available. The design preference is therefore for a small interacting set rather than a long independent list.
What the shipped contract enforces
Each published game declares its rules in metadata, and the repository's evidence contract requires described behaviour to match what a release can demonstrate. A decorative rule would be a claim the game cannot substantiate, so the contract discourages the failure mode this guide identifies without needing a separate policy.
How to tell the difference from the outside
Compare the rules as stated rather than the screenshots. If the rule set is unchanged and only the presentation differs, the game is a reskin regardless of how polished it looks. If a rule has been added or changed, check whether a forced move follows from it. Those two checks can be performed on any published game from its documentation alone.
Why the test uses forced moves rather than difficulty
Difficulty is an experience claim that requires measurement of solving behaviour, which this repository has not collected. A forced move is a structural fact that follows from the rules and can be derived without observing any player. The guide therefore uses the structural test because it is checkable, not because it is the only interesting property of a rule.
What interaction between rules produces
When two constraints both apply to a position, the deduction may follow from either or from their combination, which produces reasoning a single rule could not. That is where a small rule set gains depth, and it is why the design preference is for a few interacting constraints rather than a long list of independent ones.
How the constraint is documented
This guide states the design preference explicitly rather than applying it silently, so a reader can judge a specific game against a stated standard. The repository's evidence contract supports the practice by requiring described behaviour to match what the release can demonstrate.
How the preference is stated rather than implied
The design preference for one interacting rule set is written in the guide and reflected in the repository's evidence contract, which requires described behaviour to match what a release can demonstrate. A reader can therefore hold a specific game against a stated standard rather than against a private taste.
What this guide does not evaluate
It does not rate any published game and does not compare against products outside this repository. It states the test and the preference, and leaves the application to the reader who has the game's documented rules in front of them.
First-party evidence and provenance
How we checked this
We reviewed the repository's evidence contract and the published rule metadata for a representative binary-logic game, then checked that each stated constraint independently forces at least one deduction. We did not evaluate unpublished games and did not compare against competitor products.
- 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