A “New game” button compresses a surprisingly large engineering problem into a one-second interaction. The player expects a fresh challenge to appear, to obey the rules, to feel reasonably different from the previous one and to match the selected difficulty. If the puzzle is supposed to have a unique solution, the player also expects that no second answer is equally legitimate. And all of this is expected without seeing the system test hundreds of possibilities before deciding which one deserves to be shown.
As Blupoli Puzzles grew, procedural generation became one of the clearest examples of how product quality and algorithm design are inseparable. At first it is easy to think that generation means producing any initial state that satisfies the game rules. In practice, that definition is far too weak. Validity is the floor, not the ceiling. A useful generator behaves less like an indiscriminate factory and more like an editor. It proposes, checks, compares and rejects. Only a fraction of what can be created should ever reach the player.
Solving answers a different question from generating
A solver receives a puzzle and searches for a solution. A generator starts from the opposite direction: it has to construct an instance that satisfies a set of desired properties. Both may share knowledge about the rules, but they do not have the same goal. Finding one solution proves that a board is solvable. It does not prove that the answer is unique, that the puzzle is interesting, that it belongs to a particular difficulty band or that a similar board can be generated efficiently again.
This distinction stops being theoretical as soon as the generator relies too heavily on the solver. A common first version is “create something, check that it has a solution, publish it.” That pipeline validates very little. A puzzle product needs a third responsibility: evaluation. Evaluation looks at properties beyond the mere existence of a solution. Creating, solving and evaluating form a system, but treating them as the same job makes every one of those responsibilities harder to reason about.
The trap of the visually plausible board
Many generation defects are dangerous because they are not visually obvious. A Nonogram can present perfectly plausible clues while allowing two different images. A path puzzle can distribute terminals neatly while leaving almost every connection forced from the opening move. A Kakuro can obey its sums and still make each combination so obvious that there is barely a puzzle left. The interface cannot tell a strong candidate from a weak one just by looking polished.
There is a useful parallel with AI-assisted development. Producing output that looks convincing is much easier than proving its properties. That is why our workflow with development agents puts so much emphasis on independent evidence. Procedural generation needs the same mindset. The component that proposes a puzzle should not be its only judge. It needs tools that are able to contradict it.
A solver can become the factory inspector
One of the most valuable uses of a solver happens outside the player experience. The generator proposes a candidate and the solver inspects it. It can verify that at least one solution exists, continue looking for additional solutions, count decisions, record where branching occurs or track which logical techniques were needed to make progress. The same knowledge used to solve a puzzle becomes a manufacturing instrument.
That does not mean the solver can completely define quality. Some properties of the experience do not appear directly in a search trace. But it gives us reproducible signals that are far more useful than hard-coding an assumption such as “larger board means harder puzzle.” A solver can turn parts of difficulty and uniqueness into observable data, something we can compare across versions and preserve as regression tests when a problematic case is found.
Finding one solution does not prove uniqueness
This is one of the simplest and most important conceptual mistakes in puzzle generation. If an algorithm finds a solution, it has proved only that at least one solution exists. In puzzle families where the design promises a unique answer, the search must continue or use constraints that can demonstrate that every alternative leads to contradiction. Stopping at the first success can publish an ambiguous question.
Ambiguity is particularly unfair to the player. Someone can reason correctly, arrive at a valid configuration and then be told the application expected something else. In that situation the failure belongs to the generator, not to the person solving the puzzle. The system asked a question without proving that it had exactly one intended answer. Uniqueness is not a nice extra when it is part of the puzzle’s contract. It is a property the product should be able to justify.
Rejection is a core part of the algorithm
A naive generator is measured by how many candidates it can produce. A mature one is measured partly by what it knows how to reject. A board may be solvable but belong to the wrong difficulty. It may be unique yet repeat a pattern the player has seen three times in a row. It may be elegant but too expensive to validate within the response-time budget. It may obey every formal rule while containing a degenerate structure that makes the experience flat.
Once rejection becomes normal, the architecture changes. A generator can no longer be modeled as “a function that returns a board.” It becomes a process that is allowed to fail in expected ways, record why a candidate was discarded, try again and eventually use a fallback strategy. Rejection stops being an exceptional state and becomes the mechanism through which quality enters the generation pipeline.
Norinori taught us to prefer less variety over fake variety
During the early catalogue work, some generation strategies produced boards that were ambiguous or difficult to validate reliably. Norinori was one of the cases that reinforced an important principle: it is better to remove a strategy we cannot prove safe than to keep it solely because it appears to increase variety. A source of diversity that breaks the game contract is not useful diversity.
This choice can feel uncomfortable because it reduces the visible space of possibilities in the short term. But it protects something more important: trust that a published puzzle is a well-defined problem. In a broad catalogue, that trust has to be consistent. If some games silently allow accidental ambiguity while others do not, players cannot know what assumptions they are safe to make. Quality consistency is part of platform identity too.
Difficulty needs a theory, even if that theory is imperfect
Calling a puzzle Easy, Normal, Hard or Expert implies there is some model explaining why those labels differ. The model can evolve and it does not have to predict every player perfectly, but it needs to be stronger than simply changing the board size. A large board full of obvious moves can be easier than a small one containing a single deep deduction that unlocks everything else.
The signals depend on the puzzle family: number of forced moves, branching factor, logical techniques, candidate combinations, clue density, path length, symmetry, region structure and many other possibilities. A good difficulty system does not try to reduce every game in the catalogue to one universal score. It tries to make the label reproducible within a game so that the difference between levels corresponds to a real difference in the reasoning requested.
Numberlink exposed how difficulty can be fake
Numberlink made this failure mode especially visible. We could generate technically valid boards and still notice that supposedly high difficulty levels often produced paths that were almost obvious. The application could start, accept moves and detect completion correctly. The problem lived somewhere else: there were too few meaningful decisions.
That forced a different engineering question. Instead of asking “How do we generate a Numberlink board?” we had to ask “Which properties make a Numberlink board interesting?” The gap between those questions is huge. The first can be satisfied by structural correctness. The second requires understanding where decisions occur, how constraints interact, where bottlenecks appear and how information is revealed as the player progresses. Every procedural puzzle generator eventually needs at least a minimal theory of the experience it is trying to create.
Solver-based difficulty metrics have limits
A solver can provide excellent data, but we have to understand what the numbers actually represent. A search algorithm may explore branches a human would never consider. A heuristic optimized for speed may skip the very logical techniques that make a puzzle satisfying. Two boards with similar computational cost can feel completely different if one is built around a clean deduction while the other requires repetitive bookkeeping.
That is why automated metrics are signals, not oracles. We can combine multiple observations: decision count, depth, technique usage, discarded alternatives, spatial distribution or progress by phases. Then those signals need to be compared with actual experience. The advantage of instrumenting the solver is not that it gives an absolute truth about difficulty. It moves the product from arbitrary labels toward measurable hypotheses that can be tested and corrected.
Generation time is also a product constraint
Searching indefinitely for the perfect puzzle is useless if somebody is staring at a loading state. Generation has a budget. It needs limits on attempts, limits on time and a clear answer for what happens when quality filters reject too many candidates. An algorithmically elegant strategy can still be a poor product decision if it blocks the interaction for too long.
This creates an interesting tension. The stricter the quality policy becomes, the more candidates may fail. The answer should not simply be to grant the generator more seconds. Optimization means improving the distribution of candidates so that the generator proposes stronger structures earlier. A good generator is not the one that searches longer; it is the one that wastes fewer attempts on candidates it should have been unlikely to create in the first place.
Fallbacks need to be designed, not improvised
If the generator reaches its time or attempt budget without finding a satisfactory instance, it needs a known next step. It may relax a non-essential preference, switch strategies, return a prevalidated puzzle or restart with adjusted parameters. What it should not do is publish the most recent candidate simply because time ran out. A fallback cannot be a back door around the very checks that protect the player experience.
Designing fallbacks forces priorities to become explicit. Some properties are non-negotiable, such as basic validity or uniqueness when the puzzle promises it. Others can be treated as gradients, such as a score for novelty or visual balance. Encoding that hierarchy makes failure behaviour predictable and prevents performance pressure from quietly turning into lower correctness standards.
Seeds turn random defects into reproducible cases
Randomness is useful for variety, but it makes debugging harder. A player can hit a terrible board that never appears again during manual testing. Controlled seeds let us preserve the exact candidate, replay it and compare later versions of the algorithm against the same input. The product can remain random from the player’s perspective while engineering gains determinism whenever it needs it.
This is especially valuable for regression testing. If a seed once produced multiple solutions or a wildly misclassified difficulty, that seed can be stored and future versions can be required not to repeat the same failure. The defect changes from “this sometimes happens” to a concrete executable case. Over time, a library of problematic seeds becomes part of the generator’s memory and protects against old mistakes returning.
Variety needs memory too
A generator can produce individually good puzzles and still become repetitive as a sequence. If every board shares the same structural pattern, players quickly recognize the recipe. The quality of a session depends not only on each isolated instance but also on the distance between the current puzzle and the ones that came immediately before it.
That suggests another evaluation layer: compare candidates with recent history or with an expected distribution of structural features. Depending on the family, we can examine clue placement, shapes, density, technique usage, region patterns or path geometry. The goal is not maximum randomness. Too much randomness can be noise. What we want is meaningful diversity: puzzles that explore different parts of the design space while continuing to satisfy the same quality bar.
Good generation requires understanding the puzzle family, not just its format
There is no universal metric for a “good puzzle.” In Nonograms, quality may depend on how clues produce progressive deductions. In Kakuro, combinations and intersections matter. In Slitherlink, local constraints need to build toward a single loop. In shading puzzles, connectivity, regions and forbidden patterns can dominate. The platform can share infrastructure, but evaluation needs family-specific knowledge.
This is a natural extension of the puzzle-engine architecture. We can share the surrounding process—propose, validate, measure, select—while allowing each family to define which signals matter. Trying to force one evaluator across every puzzle type would produce shallow metrics. The useful reuse lives in the framework, not in pretending every game is the same problem.
A solver is not the same thing in every puzzle either
As the catalogue expanded, it became obvious that “has a solver” is not a homogeneous capability. Some puzzle families fit constraint propagation. Others lean on backtracking, graph algorithms or highly specific deductions. Even if two games can both be solved through generic search, the information we need for difficulty analysis may require very different instrumentation.
That is why we avoid turning the solver into one giant abstraction. A shared contract can expose common questions—solvable, number of solutions, rough cost signals—while the implementation remains specialized. We explore this idea further in “One solver does not fit every puzzle”. The infrastructure should make results comparable where comparison is meaningful without erasing the nature of the underlying problem.
Generation is part of game design
It is tempting to think that the rules are “the game” and the generator is a technical utility that merely supplies content. In procedural experiences, the relationship is deeper. The rules define the complete space of possible games. The generator decides which tiny fraction of that space players will actually see. Two generators operating under exactly the same rule set can produce products with radically different personalities.
That turns algorithmic choices into design choices. Clue distribution, the frequency of certain techniques, the probability of unusual structures and the shape of the difficulty curve all affect how the experience feels. Reviewing a generator is therefore not the same as optimizing an invisible helper function. It is editing the material players will be asked to reason about.
Quality filters can become executable specification
One benefit of formalizing generation is that many product expectations no longer have to live only in documentation. If uniqueness is required, the system can test it. If a difficulty band needs particular signals, thresholds can be defined and results recorded. If certain degenerate structures are forbidden, they can become validators. Part of the product specification becomes executable.
This works especially well with AI-assisted development. An agent can modify a generator quickly, but existing filters create independent constraints that the implementation cannot silently ignore without causing a test or build to fail. Product knowledge becomes partially protected by code that is separate from whoever makes the change. The more repeatable the verification becomes, the less the team depends on remembering every quality rule manually during review.
Engineering telemetry matters even without tracking players
We do not need to observe personal player behaviour in order to instrument a generator during development. We can record how many candidates are attempted, why they are rejected, how expensive they are to solve, which scores they receive or which seed produced an extreme case. Those numbers make it possible to compare algorithm versions under the same conditions.
The important distinction is between engineering metrics and conclusions about experience. If a new implementation cuts the number of attempts in half, that means it is more efficient under the current filters. It does not automatically mean the puzzles are better. If quality signals also hold or improve, then we have stronger evidence. Instrumentation helps ask better questions; it does not remove the need for product judgment.
The best generator knows how to fail clearly
Procedural generation will always contain edge cases. Some parameter combinations can be too restrictive. A particular board size can make validation explode. An unusual constraint interaction can exhaust the attempt budget. A mature system is not one that promises failure is impossible. It is one that fails within known limits, records the reason and takes a predictable recovery path without publishing garbage.
That improves debugging as well. “Generation failed because 200 candidates did not pass uniqueness” gives us a direction. “It does not work” does not. Error categories, counters and timing around generation turn a black box into an observable process. Observability makes it possible to optimize deliberately instead of adjusting heuristics blindly.
Pressing “New game” means trusting a chain of decisions
The final experience should still feel simple. The player presses a button and receives a puzzle. The system of solvers, metrics, seeds, filters and budgets should remain invisible. That invisibility is the goal, not evidence that the complexity does not exist. The better the infrastructure works, the less the player needs to know about it.
That is why generation and solving are related disciplines but distinct ones. Solving helps us prove. Generation proposes. Evaluation decides whether the proposal reaches the required standard. Product constraints add time, variety and experience requirements that none of those functions can ignore. When each responsibility is explicit, “New game” stops being a lottery and becomes a reasonable promise that the next challenge will be worth the player’s attention too.
The quality of a generator can be measured by its rejections
The central idea is almost counterintuitive. A generator is not better because it manages to publish everything it creates. It is better when it can distinguish between what is mathematically possible and what is desirable for the product. The list of rejected candidates is not wasted work. It is the filter that separates the raw solution space from the smaller set of experiences we actually want to offer.
Blupoli Puzzles will continue refining those boundaries game by game. There is no universal formula and not every puzzle family needs the same guarantees. But the shared principle is already clear: before a puzzle reaches the screen, we should be able to explain—at least technically—why we consider it valid, what we know about its solution and which evidence supports its difficulty or quality. Generating is not solving. And solving by itself is not enough to edit a good game either.