Start with a rule you can resolve
Useful AI prompts for a merge puzzle name the board, matching rule, player action, move limit, and exact win state. Write those decisions before asking for extra levels or visual polish. Then trace a small example by hand so a later result has a clear state to compare against.
This guide uses Lantern Workshop, a fictional 3-by-4 puzzle where Shards combine into Prisms and then a Bloom. Its pieces, mechanics, and four-move route are invented teaching material. The prompt templates below have not been run through a game generator, and the board route is hand-resolved rather than playtested. That boundary keeps the example useful as a design brief without presenting it as a generated or playable result.
The practical sequence is: define the state contract, request the smallest playable loop, trace one solution, and ask for checks around the rule that matters most. A compact example makes omissions visible while changes are still inexpensive.
Define the board and progression
“Combine matching pieces” does not explain which pieces may combine, where the result appears, or what happens to the emptied cell. Lantern Workshop makes those choices explicit. Coordinates use (row, column), starting from the upper-left corner.
| Decision | Lantern Workshop rule | Why it belongs in the prompt |
|---|---|---|
| Board | Three rows by four columns; cells are either empty or occupied by one piece. | A small board is easy to audit and illustrate. |
| Progression | Two equal-tier pieces combine into the next tier: Shard → Prism → Bloom. | The target follows from a visible chain. |
| Merge | Select two orthogonally adjacent, equal-tier pieces. The second selected cell holds the new piece; the first cell becomes empty. | Direction and destination affect the resulting state. |
| Slide | Move one piece exactly one orthogonal cell into an empty cell. | It gives the player a way to align the later merge. |
| Turn and goal | A merge or slide costs one move. Create one Bloom within four moves. | The player and the future implementation share an end condition. |
| Excluded behavior | No gravity, refill, random spawn, diagonal movement, or automatic cascade. | Unstated systems cannot silently change the example. |
The initial state is Shards at (1,1), (1,2), (2,3), and (2,4); every other cell is empty. The player must create a Bloom before the four-move budget ends. Treat the exclusions as deliberate first-slice choices, not universal rules for merge games.
Prompt 1: set the rule contract
Design one small solo merge-puzzle level called Lantern Workshop. Use a 3-row by 4-column board with coordinates (row, column), starting at the top left. Place Shards at (1,1), (1,2), (2,3), and (2,4); all other cells are empty. Two equal-tier pieces may merge only when orthogonally adjacent. The second selected cell receives the next tier and the first selected cell becomes empty. The chain is Shard to Prism to Bloom. A merge costs one move. A piece may slide one orthogonal cell into an empty space for one move. The goal is one Bloom within four moves. There is no gravity, refill, random spawn, diagonal move, or automatic cascade. Return the player action, legal and illegal cases, move counter behavior, win and fail states, and any unresolved questions. Do not add systems.Check that the response preserves the destination rule and lists empty-cell behavior. If it adds a spawn mechanic or lets pieces merge diagonally, ask for that conflict to be resolved before requesting art or more levels.
Request a focused playable slice
Once the contract is clear, ask for one board with the interaction and feedback needed to inspect it. A first-slice prompt should say what the player can select, how legal actions resolve, what is rejected, and how the level restarts. It should also request readable board state so the player can tell which cell will receive the result.
Prompt 2: build only the first loop
Using the Lantern Workshop rule contract, create one playable puzzle board and nothing beyond the first level. Let the player select two pieces or slide one piece into an empty orthogonal neighbor. Show a clear selection state and preview the destination before confirming a move. Resolve merges exactly as specified: the second selected cell receives the next-tier piece and the first becomes empty. Spend one move per merge or slide. Reject diagonal actions, occupied slide destinations, unequal-tier pairs, and nonadjacent merge targets with visible feedback and no board change. Show the four-move limit, remaining moves, and Bloom objective. Report success as soon as a Bloom exists after a legal move; report failure after move four if no Bloom exists. Include a restart action that restores the exact starting state. Keep every cell visible and do not add gravity, refill, random pieces, cascades, levels, or unsupported rules. Return the control mapping and an explicit list of assumptions.The goal is a state that a person can inspect, not a feature count. Ask for the move budget and win state to remain visible while interacting. If the response makes the player guess whether a merge will leave a usable space, improve the preview and selection feedback before expanding the board.
Hand-resolve the four-move route
A short state trace catches contradictions between a rule description and its intended solution. Lantern Workshop uses this route: merge the first pair, merge the second pair in reverse selection order, slide one Prism beside the other, then combine them. Each action consumes one move.
| Move | Action | State after the action | Moves left |
|---|---|---|---|
| Start | — | Shards at (1,1), (1,2), (2,3), and (2,4) | 4 |
| 1 | Select (1,1), then (1,2) | Prism at (1,2); (1,1) is empty | 3 |
| 2 | Select (2,4), then (2,3) | Prism at (2,3); (2,4) is empty | 2 |
| 3 | Slide the Prism from (2,3) to empty (1,3) | Prisms at (1,2) and (1,3), now adjacent | 1 |
| 4 | Select (1,2), then (1,3) | Bloom at (1,3); goal reached on the final move | 0 |
The third move is necessary because the two Prisms begin in different rows and columns. The one-cell slide makes them orthogonal neighbors; a diagonal merge would not satisfy the contract. The second merge cell determines where the Bloom appears. These are expected design states, not software output.
Revise one observable mismatch
Prompt revision is easier to evaluate when one rule changes at a time. Suppose a future result permits a diagonal pair. Before changing anything else, restate the orthogonal-neighbor constraint, name a diagonal pair from a supplied board, and define the expected rejection: no merge, no cell movement, and no move spent. Keep the progression chain and the four-move route unchanged.
Prompt 3: constrain the revision
Review the current Lantern Workshop design against this rule: a merge is legal only between equal-tier pieces in orthogonally adjacent cells. Diagonal neighbors are not adjacent. If an attempted diagonal merge occurs, reject it, leave both pieces in their original cells, and do not spend a move. Change only this merge-validation rule and its visible feedback. Preserve the board size, tiers, slide rule, merge destination, move budget, and win condition. Return one before-and-after state for a diagonal attempt and explain how to verify that no other rule changed. If you cannot resolve an assumption from the supplied contract, ask a question instead of inventing behavior.This is a proposed revision, not a tested improvement. A useful comparison would check the same input state before and after the change and inspect the rejected move, counter, and neighboring cells. If the output also changes gravity, scoring, or progression, narrow the request and compare again.
Check the edge cases before adding levels
Once the main route is explicit, request examples that could reveal a competing interpretation. These checks are design acceptance cases for a later build; none have been executed against software.
| Case | Expected result | Visible check |
|---|---|---|
| Diagonal equal-tier pair | Reject the merge; preserve both cells and the move count. | No result piece appears. |
| Occupied slide destination | Reject the slide without moving either piece. | Destination stays occupied; move count is unchanged. |
| Unequal-tier pair | Do not merge the two pieces. | The player receives a clear invalid-action cue. |
| Third-tier merge | Two adjacent Prisms create one Bloom in the second selected cell. | The first cell becomes empty. |
| Bloom on move four | Resolve the move and report success immediately. | Success is visible even though no moves remain. |
| No Bloom after move four | End the level in failure and block another action until restart. | The board can be restored to its exact starting state. |
For each case, supply an input board, attempted action, expected stable board, remaining move count, and feedback. If a test requires a feature outside the first slice, record it as a later question rather than silently expanding the rules.
Carry the brief into a creation workflow
The official SEELE puzzle-maker page emphasizes a learnable rule, visible clue, and solving action. It asks creators to review whether the clue, action, and outcome are clear; its example is a 4-by-4 tile puzzle where symbols move into an empty neighboring square. That differs from this article’s merge mechanic and does not verify Lantern Workshop’s route. Use the written brief to check the result you receive.
Before generating, review the displayed cost. The general game-maker page describes a playable first version from a plain-English idea, browser testing, and follow-up prompts. A playable result still needs a direct review of selection, merge timing, destination cells, move counting, and restart behavior. Keep the hand trace beside the result so a mismatch points to a specific decision rather than a vague impression.
Keep the first prompt small and checkable
Define how pieces match, where the next tier appears, what movement is legal, and how many moves the player gets. Then follow one route to its final state and check the edge cases that could alter it. A clear contract helps you decide what to keep, what to revise, and when the first puzzle is ready to expand.
When you are ready to explore your own rules and clue, continue with the AI puzzle game maker. Compare the direction you want to build with the visible actions and outcomes in your brief.
Merge puzzle prompt questions
What should an AI prompt for a merge puzzle include?
State the board size, matching tiers, legal movement, merge destination, move cost, goal, and behavior outside the main route. Then ask for the starting state and one expected after-state. These details make the design easier to review before you add levels or progression systems.
Where should the new piece appear after a merge?
Choose a destination rule and say it directly. Lantern Workshop places the next-tier piece in the second selected cell and clears the first. Other designs may choose a fixed or player-selected target, but the prompt should define it and keep the feedback consistent.
Does a merge puzzle need gravity or automatic spawns?
No single rule fits every game. This teaching example excludes gravity, refill, random spawns, and cascades so each move has a predictable result. If your idea needs those systems, specify when they happen and provide enough state detail to check what follows a merge.
Were the Lantern Workshop prompts or board tested?
No. The setting, rules, and board are fictional, the four-move route is hand-resolved, and the prompt templates were not run through a game generator. There is no playable build or playtest result here. Treat the trace as a design expectation for a future comparison.
What should I check when a future result differs?
Replay the same starting state and compare legal actions, destination cells, move counts, and end-state timing. Change one rule at a time, keep the other inputs fixed, and record whether the expected board changes. That helps separate a rule mismatch from a visual or control issue.
