A first nonogram is easiest to plan when every clue comes from a visible picture. Start with a five-by-five target, count each continuous run of filled cells, and let players record what is still unknown as well as what must be empty. This guide works through one original beacon puzzle by hand. The board is a fictional design example: its clues and solution can be checked on paper, but no game prompt, playable build, or player test has been run.
Start with a picture and one rule
Give the player one job: reveal the small picture hidden in a grid. In the proposed harbor puzzle, filled cells form a north-pointing beacon arrow. Each clue lists the lengths of consecutive filled runs in one row or column. For example, a clue of [3] means three adjacent filled cells; if a line has two separate runs, the clue lists both numbers in order and at least one empty cell separates them.
Keep the first level small enough to inspect without software. This five-by-five board has no timer, score economy, random generation, multiplayer, or secondary rule. The player selects one cell and marks it filled or empty; cells that have not been reasoned about remain unknown. The level is solved when the full row and column patterns match their clues and reveal the arrow.
That rule sets the boundary: a clue describes one line; it is not an instruction to guess a picture. Check both axes before adding animation or hints.
Translate the picture into clues
Write the target as five rows, using # for filled and . for empty. Read across each row and count each uninterrupted group of # symbols. Then repeat from top to bottom for each column. The beacon target is:
..#..
.###.
#####
..#..
..#..Reading across gives row clues [1], [3], [5], [1], [1]. The first row contains one filled cell; the second has one run of three; the middle row is full; and the last two rows each contain a single center cell. Reading down gives column clues [1], [2], [5], [2], [1]. The two middle side columns contain a pair of adjacent cells in rows two and three, while the center column is filled from top to bottom.
Do a quick consistency check before solving. The row clues total eleven filled cells: 1 + 3 + 5 + 1 + 1. The column clues also total eleven: 1 + 2 + 5 + 2 + 1. If those totals differ, a filled cell was missed or counted twice. Equal totals do not prove that a puzzle is unique, but they catch many transcription errors before a player sees the board.
Record each line clue in order; later puzzles can include multiple runs such as [2, 1].
Solve forced cells before guessing
Use the strongest clues first. Row three has clue [5], so all five cells in that row are filled. Column three also has clue [5], so the center cell of every row is filled. The top and bottom rows are not solved yet, but their center cells are known.
Rows one, four, and five each have clue [1]. Since the center cell is already filled, every other cell in those rows must be empty. Mark those cells as empty rather than leaving them unmarked; an unmarked cell could still mean “not decided.”
Now inspect column two. Its clue is [2]. Row three is filled in that column, while rows one, four, and five are empty. To make the only two-cell run required by [2], row two, column two must be filled. The same reasoning in column four forces row two, column four. Row two now has its center cell plus both neighbors, exactly the run [3]; its outside cells are empty.
The mechanism view captures one intermediate checkpoint after the forced r2c2 fill. The top column-two clue is complete, but row two is still incomplete because r2c4 remains unknown. A correct board can show both kinds of feedback at once: one line is finished, while another still needs a move.
These are deductions, not lucky guesses. If a player is asked to click the whole arrow before the clues force it, the picture is doing the puzzle's work. Let the line clues provide enough information to justify each mark, and keep a short note of which clue forced it.
Build a mark-and-feedback loop
A usable nonogram needs three explicit cell states: unknown, filled, and empty. A tap or click selects one cell; the player chooses a fill mark or an empty mark. Selecting a marked cell again can clear or change that mark, but the rule should be visible and consistent. The game should never silently change neighboring cells just because a line appears close to solved.
Line feedback should also have a clear condition. A row or column is complete only when its ordered run sequence exactly matches its clue. A partial match can show progress without claiming the line is finished. For example, the filled center and left neighbor in row two do not satisfy [3] until the right neighbor is filled and the outer cells are resolved as empty. In the mechanism image, column two is complete because rows two and three form the required run of two; row two remains open because r2c4 is unknown.
Make a mistaken mark reversible. If the player marks the wrong cell, allow them to clear or change that cell and keep the rest of the board intact. A reset should return every cell to unknown and every completion indicator to its starting state. These are design rules for the proposed game, not claims about a particular generated interface.
Write the input, state change, line feedback, correction, reset, and success condition as separate checks. If a line turns green too early in a future build, inspect the clue matcher and visible state independently.
Revise one unclear interaction on paper
In a paper-only v0 of this design, cells have just two labels: filled or unmarked. That leaves a problem. An unmarked cell might be untouched, or it might be logically known to be empty. The board cannot record the difference, and a later solver may repeat the same deduction or mistake an unresolved cell for a ruled-out one.
Make one change in a paper v1: add an explicit empty state. Keep the target bitmap, all clues, the win condition, and the line-matching rule exactly the same. Reapply the deductions: mark the non-center cells in rows one, four, and five empty; fill the forced cells at r2c2 and r2c4; then finish row two. The three states now record the reasoning without guessing.
This paper walkthrough shows that the written state model can express the solution and that the clue set is internally consistent. It does not show that players will understand the marks, that a screen communicates them clearly, or that the rule works in a real build. A future playtest would need a clean reset, the exact clues, and an observer who records where a new player hesitates without coaching them through the answer.
Verify every line and the solution
After the deductions, compare the finished grid with every clue. Across the rows, the runs are [1], [3], [5], [1], [1]. Down the columns, the runs are [1], [2], [5], [2], [1]. Each line matches in the correct order, and the picture is the planned beacon arrow.
For a five-cell line, there are only 32 possible filled/empty patterns. The clues [1], [3], [5], [1], [1] allow 5, 3, 1, 5, and 5 row patterns respectively. Combining those choices gives 375 candidate boards. Checking each candidate against the five column clues leaves exactly one board: the target shown above. This exhaustive hand-check is a small, reproducible uniqueness test, not a test of a playable game.
Use the same order when authoring another tiny puzzle:
- derive every row and column clue from the target, then compare the filled-cell totals;
- enumerate the patterns each line clue permits and fill only cells that are forced;
- mark forced empty cells separately from unknown cells;
- check all lines in both directions and count the remaining candidate boards;
- restart from a clean grid to catch state that was accidentally carried over.
If no board remains, a clue or target cell is wrong. If more than one remains, the puzzle is ambiguous under its written rules. If one remains, you have shown internal consistency and uniqueness for that puzzle; you still have not shown that its clues are readable or its difficulty is fair to a player.
Use AI to shape the brief, not as proof
A useful game prompt names the target, the visible clues, the player's action, feedback, reset, and the check that determines success. You can start with a prompt like this and adapt it for your chosen game-making workflow:
Design a small original nonogram puzzle game around this exact 5x5 target:
..#..
.###.
#####
..#..
..#..
Use row clues [1], [3], [5], [1], [1] and column clues [1], [2], [5], [2], [1]. Define a visible unknown, filled, and empty cell state. Let the player mark one cell at a time, revise an incorrect mark, and reset the whole board to unknown. Show a row or column as complete only when its ordered filled runs exactly match its clue. The level is solved when every row and column matches and the beacon arrow is revealed.
Keep this to one readable screen. Do not add a timer, score economy, random clue generation, or hidden rule. Return the proposed interaction rule and a short checklist for checking the clue values, forced cells, line feedback, reset, and final solution. Do not claim the puzzle is unique unless the returned board is checked against both clue axes.This is a prompt template, not a prompt that has been run. SEELE's current AI puzzle game maker page asks creators to state a puzzle rule, visible clue, and solving action. It also suggests checking whether the rule and result are fair and comparing starting directions against the same user action and visible outcome. This supports a general puzzle-brief workflow; it does not document nonogram-specific clue validation or show that this fictional beacon game was generated. Review any result and verify the line rules yourself.
Continue with a testable puzzle brief
For your next small puzzle, begin with one target picture and derive both clue axes before adding art or progression. Keep unknown, filled, and empty distinct; use forced cells before guesses; and check that every line matches. If a prompt suggests a solution, verify it independently rather than treating a plausible image as proof.
The harbor beacon is a fictional, hand-resolved teaching example, not an online game or product result. The paper calculation shows one unique solution under its stated rules; a real prototype would still need an actual build and player test. Start with the AI puzzle game maker to frame your own rule, clue, and solving action, then inspect the result against your written checks.
Frequently asked questions
Can a nonogram clue contain more than one number?
Yes. Each number represents one consecutive filled run in that row or column, listed in order. Separate runs need at least one empty cell between them, so a line might have a clue such as [2, 1]. The beacon example uses only one run per line to keep its five-by-five solution easy to verify by hand.
Why mark a cell empty instead of leaving it blank?
An empty mark records a deduction; a blank or unknown cell means the player has not decided yet. Keeping those states separate lets the player see which possibilities have been ruled out and avoids repeating the same reasoning. The paper v0/v1 example adds this state for clarity without changing the target or puzzle clues.
Does a unique solution prove that a puzzle is fair?
No. Uniqueness proves that one board satisfies the stated clues, but it does not prove that a player can discover that board or understand the feedback. After building a real prototype, ask a new player to solve from a clean grid and observe where the clues or cell states are unclear. This article contains no such player test.
Can an AI game maker automatically validate nonogram clues?
Do not assume that it can. The current SEELE puzzle page describes a general workflow for stating a rule, visible clue, and solving action, checking whether the rule and result are fair, and comparing starting directions against the same action and outcome. It does not document a nonogram clue validator. Check the clues and solution independently, then test any actual implementation before relying on it.
What should I include in a first nonogram game prompt?
Include a target grid, exact row and column clues, cell states, one-cell input, reversible marks, line-completion feedback, reset behavior, and the win condition. Ask for a short rule description and checks, not an unsupported promise of uniqueness. Treat any returned design as a proposal until its clues are verified and its playable behavior is inspected.
