Show what packing means
A spatial packing puzzle works when the player can see what each piece would occupy before committing it. Start with a tiny tray, one clear shape rule, and an exact-cover goal; then test whether the first orientation set can fill the board. In this fictional paper exercise, two identical L triominoes cannot fill a 3-by-2 tray if they may only use their starting orientation. Allowing a 180-degree rotation creates one clean fit. The calculation is a design example, not a playtest or a generated build.
Define the tray and piece coordinates
Give the board and each piece coordinates before asking for animation or effects. Lantern Foundry uses one layer with three columns, x = 0 through 2, and two rows, y = 0 through 1. Each piece occupies three cells inside a 2-by-2 footprint: (0,0), (1,0), and (0,1). The fourth cell in that footprint stays empty. Pieces translate by integer anchors; they cannot overlap another piece or extend beyond the tray.
| Rule | Lantern Foundry value | Why it matters |
|---|---|---|
| Board | 3 columns × 2 rows, one layer | Every one of the six cells must be accounted for. |
| Piece | One L triomino with local cells (0,0), (1,0), (0,1) | Three unit cells give each piece a visible footprint and one missing corner. |
| Placement | Integer anchor, no overlap, stay in bounds | A preview can be checked before the player commits a move. |
| Goal | Cover all six tray cells exactly once | A filled tray is a precise completion condition, not a subjective score. |
The remaining mechanics are intentionally small: choose a piece, move its anchor, choose an allowed orientation, preview the cells, then place or reset. There is no gravity, stacking, timer, inventory progression, campaign, or hidden matching rule. Leaving these out makes the packing question easier to inspect.
Prompt the first tray
A useful first request names the board, the pieces, the legal moves, the goal, and the way invalid moves should behave. It also asks for the state representation, so a later implementation can compare occupied cells instead of relying on decorative shape art.
Design a small one-layer spatial packing puzzle called Lantern Foundry.
Board: a 3-column by 2-row tray at z=0, with integer cell coordinates.
Each of two identical pieces occupies local cells (0,0), (1,0), and (0,1) in a 2-by-2 footprint.
For version 0, allow only 0-degree orientation. Let the player select a piece, move its integer anchor, preview its occupied cells, and commit only when all cells are in bounds and empty.
Win only when every tray cell is covered exactly once. Show an incomplete-tray state, an overlap or bounds rejection, and a reset that restores both pieces and the empty board.
Return: a concise rule list, the board and piece state model, legal-placement checks, a move sequence or proof for whether the board can be filled, and acceptance checks for preview, rejection, completion, and reset. Do not say this design has been built or tested.Run the prompt as a planning request only if you have an actual tool session and record what happened. Here, the template is provided for a reader to use; it has not been run. Keep the output split into rules, state, and checks so that a charming foundry theme cannot hide an impossible board.
Enumerate the baseline
Two triominoes contain six cells in total, which matches the tray area. Matching area is necessary but not enough: their footprints must also fit without collision. With only the 0-degree orientation, the legal horizontal anchors are x = 0 and x = 1, each at y = 0. The placement table shows the conflict.
| Piece A anchor | Piece B anchor | Check |
|---|---|---|
| (0,0) | (1,0) | Both claim cell (1,0); cell (2,1) remains empty. |
| (1,0) | (0,0) | Same middle-top overlap; cell (2,1) remains empty. |
| Same anchor | Same anchor | The pieces overlap across all three occupied cells. |
There are no other in-bounds 0-degree anchors: shifting a footprint farther right or down would place a cell outside the 3-by-2 tray. This finite enumeration proves that the baseline has no exact cover under the stated translation and orientation rules. It does not prove anything about a software build, controls, or player experience.
Allow one rotation
Change one rule: add a 180-degree orientation while keeping the board, piece cells, anchors, collision checks, and goal unchanged. Rotate around the piece's 2-by-2 footprint. The local cells then become (1,1), (0,1), and (1,0): one cell above the right side and two across the bottom. The blank corner moves from bottom-right to top-left.
In an implemented game, show the footprint as a preview and let the player cancel before committing. Check the candidate cells against the tray bounds and current occupancy on every move. An invalid preview should explain whether the shape is outside the tray or overlaps another piece, then leave the prior state untouched. Those are design recommendations for a future implementation, not features verified in a running game.
Place both pieces and verify the exact cover
Keep Piece A in its starting orientation at anchor (0,0,0). It covers the top-left, top-middle, and bottom-left cells. Rotate Piece B by 180 degrees and place its footprint at anchor (1,0,0). That placement covers the top-right, bottom-middle, and bottom-right cells.
| Piece | Anchor and orientation | Covered cells (x,y) | Result |
|---|---|---|---|
| A | (0,0,0), 0° | (0,0), (1,0), (0,1) | Three unique left-side cells. |
| B | (1,0,0), 180° | (2,1), (1,1), (2,0) | Three remaining cells; no collision with A. |
Together, the rows contain each coordinate in the tray exactly once: (0,0), (1,0), (2,0), (0,1), (1,1), and (2,1). The total is six cells, there is no overlap, and no coordinate is missing. This is an authored paper-model solution.
Make placement errors informative
Before adding more levels, list the states a creator should check in a real build. Start with two pieces outside the tray, then try a legal preview, an out-of-bounds preview, an overlapping preview, one committed piece with five uncovered cells, and the completed tray. For each state, write what can be selected, what cells are highlighted, which action is accepted, and what the player sees after reset.
- Out of bounds: mark the cells that would leave the tray and block commit.
- Overlap: identify the occupied cells that conflict and keep both pieces in their previous positions.
- Incomplete: keep the tray visibly unfinished and do not trigger the completion cue.
- Exact cover: give one clear completion cue only after all six cells are covered once.
- Reset: clear occupancy, restore both piece orientations and anchors, and return to the initial state.
In a future test, check these in that order and note the actual behavior rather than assuming the prompt produced it. If a preview says “valid” but the commit overlaps, compare the preview's cell set with the commit validator's cell set. If completion fires early, count unique occupied coordinates and confirm the rule checks both full coverage and no overlap.
Use an AI game maker carefully
The product handoff should stay close to the task. SEELE's official puzzle-maker page frames puzzle creation around rules, clues, actions, and solvability guidance. The general game-maker page describes plain-English prompts, a playable 2D or 3D first version, browser testing, and follow-up prompts. It says Workspace shows the selected AI model, available Koin balance, and displayed generation cost before submission. These are workflow capabilities, not evidence that Lantern Foundry's exact rotation, collision handling, or exact-cover test has been implemented. The current catalog calls the relevant category “One Line, One Game Studio,” with the description “Say what the game should be. That's all it takes.”
Start with the rule contract, inspect whatever result the tool actually provides, and compare it with the six coordinate checks above. If rotation or overlap behavior is missing, revise one instruction at a time and record what changed. Do not treat a generated scene or attractive image as proof that a puzzle is solvable.
Take the next step
A small spatial puzzle becomes easier to reason about when its cells, piece footprints, legal orientations, and completion condition are explicit. The fictional Lantern Foundry model demonstrates a specific result: 0-degree-only placements collide, while one added 180-degree option permits a six-cell exact cover. The coordinates are hand-checked, not played or tested. Use the same contract to plan your own puzzle, then verify its preview, collision, win, and reset behavior in the actual build. To begin framing a rules-first puzzle brief, explore the AI puzzle game maker.
Frequently asked questions
What makes a spatial packing puzzle different from Sokoban?
In a packing puzzle, the main decision is where a piece footprint fits and which orientation it uses. Sokoban centers movement around the player and pushes crates through a level. This tutorial keeps the player outside the tray and treats each L piece as a shape to place, so rotation and occupied-cell checks are the central loop.
Why can’t the two pieces fit before rotation?
With the defined 0-degree L footprint, each piece has only two in-bounds horizontal anchors. Putting one piece at each anchor makes both occupy the middle top cell; using the same anchor overlaps them even more. The six-cell area count alone does not create a legal exact cover when the shapes collide.
Does a 180-degree turn guarantee every puzzle is solvable?
No. It creates one valid fit for this particular 3-by-2 tray and these exact L cells. Other board shapes, obstacles, piece counts, anchors, or rotation rules can still make a puzzle impossible. Recalculate or enumerate the legal placements for each authored level rather than generalizing from this example.
Was Lantern Foundry generated or play-tested?
No. The name, board, pieces, coordinates, placement proof, and images are fictional design material prepared for this article. The prompt template has not been run, and no playable build, control behavior, user observation, or empirical test is claimed. Treat the worked result as a paper exercise to verify before implementing your own version.
What should I verify in a real prototype?
Check that rotation changes the same cells shown by the preview, that out-of-bounds and overlapping placements are rejected without altering state, and that completion requires every tray cell exactly once. Also verify that reset restores the original anchors and orientations. Record observed behavior separately from the intended rules and fix any mismatch before adding more content.
