Las pistas se cruzan hasta revelar la imagen
A Nonogram describes a binary image with numeric clues beside rows and columns. Each number represents a consecutive filled block; multiple blocks appear in order and require at least one empty cell between them. Solving means combining row and column restrictions until cells become forced.
Current status: implemented engine, game still coming-soon
Blupoli has a native Nonogram engine, procedural generation and solution counting, but the current manifest remains coming-soon. This article documents real implementation without treating implementation as proof of public availability.
A clue represents a complete line domain
A clue such as 3,1 does not identify one arrangement. It defines every legal placement of those blocks inside the line. The solver can enumerate that domain and then eliminate patterns that conflict with cells already known to be filled or empty.
The solver works with compatible line patterns
Rows and columns each maintain candidate patterns. Whenever all remaining candidates agree on a position, that cell can be assigned safely. The assignment then filters the crossing line and may create another consensus.
Propagation alternates between rows and columns
One row deduction constrains a column, which can constrain another row. This repeated exchange is the central solving mechanism and a clean example of constraint propagation.
Solution counting stops as soon as the product decision is known
Uniqueness does not require enumerating every solution. The engine can stop at two: zero means impossible, one unique, and two is already enough to reject a candidate that should be unique. Early cutoff saves work without weakening the publication decision.
The normal generation path looks for unique candidates
generateUnique() creates a visual pattern, rejects extreme fill densities, derives clues and accepts the candidate when countSolutions(..., 2, deadline) returns exactly one. The solver is part of content generation rather than an optional debugging tool.
Generation has an explicit 1.8 second budget
The function sets a deadline 1,800 milliseconds ahead and allows at most sixty attempts. That acknowledges an important product constraint: an interactive generator needs a bound. A theoretically elegant guarantee is not useful if the page appears frozen.
The current fallback needs precise wording
If attempts or time are exhausted, the engine returns a border pattern and derives clues from it. That fallback path does not call the solution counter again inside generateUnique(). We therefore should not claim that every possible returned board has passed the same uniqueness gate.
A function name is not a complete guarantee
The label generateUnique sounds strong, but product guarantees depend on every return path, including timeout and fallback. Editorial review can expose architecture gaps when it forces us to translate code behaviour into precise statements.
The next technical closure is validating the fallback
A straightforward improvement would be to solution-count the fallback in tests or replace it with a fixture whose uniqueness is already proven. Then “every published Nonogram is unique” could be stated without qualification.
The current sizes are 5×5, 10×10 and 15×15
Difficulty currently selects size: Easy maps to 5×5, Medium to 10×10 and Hard to 15×15. Unlike Colors, scale and difficulty are still coupled in this implementation.
Coupling size and difficulty is simple but coarse
A larger board is usually longer, but a 15×15 puzzle is not automatically more logically difficult than every 10×10 one. Future calibration could separate board scale from solve complexity if the solver exposes stronger metrics.
Density also changes by profile
The current profiles use approximate fill densities of 0.42, 0.46 and 0.50. Density affects clue structure and visual shape, but it is not a complete difficulty model. Block distribution and pattern overlap matter as much as percentage filled.
Visual patterns need quality filters
The generator smooths noise and rejects candidates that are too empty or too full. A logically valid Nonogram can still produce a poor image or trivial experience. Procedural quality therefore has both visual and logical dimensions.
Uniqueness does not guarantee a good human route
A board can have one solution while still requiring search that the product does not want. If difficulty is meant to reflect human deduction, the engine should eventually record which line techniques make progress and where propagation stalls.
The current solver already exposes useful signals
We can measure how many candidate patterns survive per line, how many cells become forced in each pass and how many propagation rounds occur before search. Those metrics describe structure more directly than board size alone.
Line combinatorics are explicit
A 3,1 clue inside a length-10 line has a finite set of legal placements because blocks need spacing. Enumerating those placements turns the clue into a concrete domain. Known cells then filter the domain step by step.
Intersections drive deduction
A row may still have several candidates while all of them agree that one cell is filled. That forced cell changes a column. The solver gains power from partial consensus rather than waiting for complete line certainty.
Player crosses are meaningful information
The current UI supports unknown, filled and crossed states. Explicit empty marks let players record negative deductions instead of relying on memory. Domain state should distinguish a deliberate cross from an unresolved cell.
Right-click cannot be the only path to crossing
Desktop context menus are convenient, but mobile has no right-click. A published product needs a touch-friendly alternative and keyboard semantics that preserve the same three-state interaction.
Keyboard play can matter on 15×15
Hundreds of cells make pointer-only interaction tiring. Visible focus, arrow navigation and shortcuts for fill or cross can reduce friction, provided standard controls remain discoverable and accessible.
The Check action compares against the materialized solution
The current implementation can determine whether player marks match the generated solution. Product design still decides how much to reveal when they do not. A generic “not yet” message preserves deduction; highlighting every wrong cell would provide much stronger information.
Hints can use pattern consensus
A pedagogical hint can choose a line where every candidate pattern agrees on one cell and explain that consensus. This uses the same evidence as the solver without exposing an arbitrary answer.
Hints should teach line techniques
Overlap, completed blocks, impossible spaces and mandatory separators are understandable concepts. Translating candidate-domain logic into those techniques can turn an internal solver into useful guidance.
Onboarding should start with a short line
A 5×5 practice scene can show a clue 3 with known empty cells and demonstrate where the block must overlap. The next step can show how that forced cell changes a crossing column.
Responsive design must accommodate clues and grid together
A Nonogram cannot simply shrink cells because row and column clues also consume space. On mobile, multi-number clues can squeeze the board or reduce touch targets. The layout needs to budget for both axes.
Long clues need visual hierarchy
Spacing, alignment and typography should make 1 1 3 impossible to mistake for 11 3. Legibility is part of the rules because a misread clue changes the logical problem.
Persistence needs marks and puzzle identity
A save should retain size, difficulty, clues or materialized solution, player marks and enough provenance to identify the generated instance. Depending only on random regeneration would be fragile.
A seed alone may not remain sufficient forever
If the generator changes, a historical seed can produce another image. Durable saves therefore benefit from generation versioning or materialized clues and solution. Reproducibility needs context.
Common results need size and assistance context
Time, errors and hints mean different things on 5×5 and 15×15. Result storage should preserve the configuration and avoid rankings that silently mix incomparable sessions.
Generation should expose internal metrics
Attempts used, milliseconds consumed and whether fallback was activated are valuable health signals. If a code change increases fallback frequency, internal monitoring can catch the regression before players notice repeated content or latency.
The fallback should not be invisible to QA
Players do not need to know which generation branch produced their puzzle, but development tools do. A fallback counter makes generator health observable and gives a concrete target for future improvements.
Tests should exercise the deadline path
Tests that always complete quickly do not validate timeout behaviour. Forcing the fallback path can verify that rendering remains consistent and that any promised solution property is still preserved under stress.
Historical context should remain cautious
Nonograms became internationally popular under several names including Nonogram and Picross. History is useful context, but this article focuses on the mechanic and the Blupoli engine rather than making unnecessary attribution claims.
The catalogue can describe shading and line deduction
The observable activities are interpreting numeric clues, comparing patterns and combining row-column constraints. That is enough to describe the experience without unsupported cognitive-training promises, following Blupoli's catalogue taxonomy.
The visuals should explain intersecting constraints
The new infographic represents row and column domains converging on one cell. It communicates both algorithm and strategy instead of decorating the article with a solved-picture screenshot.
Finishing Nonogram means closing the fallback guarantee
Before publication we should verify the fallback property, review mobile input, keyboard navigation, onboarding, accessibility, persistence and results. The engine is a strong foundation, but coming-soon still accurately describes unfinished product layers.
The main lesson is to make evidence visible
A procedural candidate does not become a good puzzle merely because it produces an attractive image. We need to know how many solutions it has, how expensive verification was, which generation path returned it and whether the surrounding experience remains coherent.
Difficulty can eventually separate size from logic
Solver instrumentation can classify 10×10 and 15×15 boards by propagation depth, candidate-domain width and search requirements. That would let the product offer a large relaxed Nonogram or a compact demanding one instead of tying difficulty permanently to dimensions.
A line cache may improve repeated solving work
Candidate patterns depend on line length and clue sequence. Reusing generated pattern sets can reduce allocation when many rows or generated candidates share the same clues, provided cache keys include every rule-relevant dimension.
Cache correctness matters more than cache hit rate
A stale or incomplete key can return patterns for the wrong clue and silently corrupt verification. Performance optimizations should therefore be covered by equivalence tests against uncached line generation.
Search needs a deadline-aware contract
The solution counter already accepts a deadline. Recursive branches should check it consistently so the product never assumes a candidate was proven unique when verification actually timed out. Timeout is a third state, not equivalent to failure or ambiguity.
Timeout should be observable separately from multiple solutions
A candidate rejected because it has two solutions tells us something about generation quality. A candidate abandoned because the deadline expired tells us something about cost. Mixing those outcomes would make tuning harder.
Fallback content can be versioned like any other fixture
If a canonical border pattern remains part of the product, it should have an identifier and explicit tests. That lets support recognise repeated fallback boards and avoids pretending they came from ordinary procedural generation.
Image-like output does not require artistic judgement alone
Density, connected shapes, symmetry and local smoothness can be measured. Those metrics do not replace visual review, but they can prevent obviously noisy candidates from consuming expensive uniqueness checks.
The product can expose puzzle identity without exposing the solution
A seed or short puzzle code can let players share the same Nonogram. The receiver gets identical clues without receiving the filled image. Reproducibility can therefore support social features while preserving the solve.
Sharing needs version-aware links
If a code depends on generation version, the shared URL or payload should retain enough provenance to reproduce the original clues after future engine updates. A share link is another durable artifact.
Timeout should be a first-class outcome
If solution counting reaches its deadline, that does not mean “multiple solutions” or “invalid puzzle.” It means the engine did not obtain enough evidence inside the budget. Distinguishing timeout, ambiguity and contradiction lets generation tuning respond to the real cause instead of collapsing different failures into one rejection.
Solver metrics can guide difficulty without guessing
The engine can record average candidate-domain width per line, forced cells per propagation pass, search depth and the point where branching first becomes necessary. No single metric is a perfect model of human effort, but together they provide a stronger basis than coupling difficulty only to 5×5, 10×10 and 15×15.
Large Nonograms are also a viewport problem
On a phone, a 15×15 grid plus external clues can exceed comfortable space. The product can scale, allow controlled panning or adapt target sizes, but clue legibility and touch precision must remain intact. “It technically fits” is not the same as “it is comfortable to solve.”
Guide lines can improve orientation
Large grids often benefit from stronger separators every five cells. This does not change the puzzle rules, but it reduces coordinate mistakes when matching clues to rows and columns. The visual emphasis still needs to work in light mode, dark mode and keyboard focus states.
Reset should preserve the same puzzle instance
Reset means clearing player marks while keeping clues. New game means generating another puzzle. Keeping those actions distinct lets players retry the same challenge and gives analytics or result storage a clear understanding of whether a session continued or restarted.
Undo may be more natural than cycling states
When a click cycles unknown, filled and crossed, one accidental interaction can move two states away from the intended mark. A semantic action history makes it possible to undo exactly the last decision without serializing every visual detail.
Accessible labels should include clue context
A row can be announced as “row 4, clues 3 and 1,” while a cell can expose “row 4, column 7, crossed.” This translates the spatial puzzle into navigable information. Accessibility means understanding the problem, not merely being able to focus its buttons.
Sharing a puzzle should share clues, not the solution
A short code or link can encode seed, generation version and configuration so another player receives the same clue set. The solved image can remain hidden. Reproducibility creates a social feature without turning sharing into a spoiler.
Shared links need versioning
If generation changes later, an old link should still reproduce the puzzle that was originally shared. The payload can include a generation version or materialized clues. Durable artifacts need more provenance than an ephemeral run.
Generation history can reveal degradation
If a release increases fallback frequency or average counting time, comparing metrics by version can expose the change. The team does not need invasive player profiling to observe algorithm health; stable benchmarks and aggregate operational signals can be enough.
Fixtures should include deliberately ambiguous puzzles
A solution counter needs test cases with zero, one and at least two solutions, plus simulated timeout conditions. A suite containing only good puzzles does not prove that the gate can reject bad ones correctly.
Solver refactors should preserve semantic equivalence
If line-pattern generation, caching or cell representation is optimized, retained fixtures should return the same solution counts. Performance work is safer when small understandable cases defend the meaning of the algorithm.
Pattern caching can remove repeated work
Line length and clue sequence define a reusable candidate set. Caching it can reduce allocation during repeated generation. The key must include every relevant rule dimension; an incorrect cache would silently corrupt verification.
Fallback use should be explicit in diagnostics
A fallback puzzle can be perfectly playable, but QA needs to know when it appears. If its rate increases after a change, that is evidence that ordinary generation is finding fewer acceptable candidates inside the budget.
Release can require a verified fallback gate
A small automated test that solution-counts the canonical border fixture would close the main guarantee gap found during this editorial audit. Documentation work is valuable when it exposes a concrete code improvement rather than merely restating the implementation.
Nonogram captures the difference between producing and proving
Creating a binary image and deriving clues is easy compared with demonstrating that those clues define the kind of puzzle the product intends to publish. Counting, deadlines, fallback behaviour and UX all belong to the same chain of trust.
Difficulty labels should evolve with evidence
If solver metrics eventually separate logical complexity from board dimensions, the UI can offer size and difficulty independently. Documentation should then change with the implementation rather than preserving historical labels that no longer describe the engine.
A good fallback can still be boring
Logical correctness is not the only quality criterion. A canonical border image may be safe but visually repetitive. Monitoring fallback frequency therefore protects both proof guarantees and content variety.
Image quality can be screened before expensive counting
Cheap metrics such as fill ratio, local smoothness or component distribution can reject obviously poor patterns before running the more expensive uniqueness solver. Ordering filters from cheap to expensive can preserve the same contract with less cost.
The counter should report why it stopped
Returning only a number can hide whether the deadline interrupted search. A richer internal result such as unique, multiple, impossible or timeout makes generation logic and diagnostics more explicit.
Cancellation belongs alongside the deadline
If the user starts another puzzle while uniqueness counting is still running, the old search should stop even if its deadline has not expired. Time budget and relevance are two separate reasons to cancel work.
A worker can help only after domain messages are clean
Moving counting to a Web Worker may protect the main thread, but the message should contain clues, size and limits rather than UI objects. Clean domain boundaries make concurrency possible without coupling the solver to rendering.
Completion should derive from clues, not hidden styling
The game can compare player marks against the solution for a fast check, but domain tests should also be able to validate that the final marked grid satisfies row and column clues. That independent route reduces reliance on one stored answer.
A validator provides a second perspective
A lightweight clue validator does not need to search. It simply derives runs from the player's final grid and compares them with published clues. Agreement between validator and generated solution provides stronger evidence than one representation alone.
Result storage can include puzzle identity
A stable puzzle code, size and generation version allow completed runs to be revisited or shared without storing every internal solver structure. The player-facing identity should remain separate from hidden solution data.
The final publication standard is understandable trust
A player should be able to assume that the clues mean what they say, that any promised uniqueness has actually been checked, that a large puzzle remains usable on their device and that saved progress will reopen the same instance. Those are the guarantees that matter outside the engine.
Related architecture: generation is not solving, different puzzles need different proof contracts, and Blupoli's catalogue taxonomy.