Start with the Player’s Stance, Not Just the Crate Route
A box-pushing puzzle is only solvable when two routes work at once: the crate must be able to reach the goal, and the player must be able to stand on the correct side before each push. Plan those stance cells before decorating the room. A crate that can move toward a goal can still become stuck when a wall blocks the player’s next position.
This tutorial uses one player, one crate, one target, cardinal movement, and no pulling. Its invented Tideglass Archive board has a paper-checked dead end and a one-cell wall revision that opens a winning route. The board, positions, and outcome are fictional design material. No prompt has been run, no game has been built, and no playtest or SEELE result is claimed.
The practical method is small: write the board contract, check the stance and destination for each push, and trace a legal sequence before adding more mechanics. If a route fails, change one cell and recheck the same contract.
Write the Board Contract Before You Design a Room
Use an 8-column by 7-row grid. Coordinates start at the upper-left corner, so (0,0) is the top-left border cell; x increases to the right and y increases downward. The outer edge is a wall. Inside the border, the player walks one cell at a time in four cardinal directions. The player may push the single crate if the next crate cell is open, but may never pull it or move diagonally. A blocked step or invalid push leaves the board unchanged.
Represent the goal separately from floor: a crate can occupy the goal, while a wall cannot. Each reset restores the player, crate, walls, goal, and all feedback to the printed starting state. These rules remove common ambiguities such as whether a blocked input consumes a turn or whether the crate can slide more than one square.
| Question to settle | Tideglass rule | What to check |
|---|---|---|
| Where can the player walk? | Any open orthogonal neighbor, except a cell occupied by the crate. | Walls and the crate block movement; diagonal corners do not count as paths. |
| When does a push work? | The player steps into the crate’s cell and the crate advances one open cell in the same direction. | The stance cell, crate cell, and destination must be distinct and reachable. |
| Can the player undo a bad push? | No pull rule. Reset restores the original board. | Do not quietly move a crate backward or teleport it during reset. |
| What happens when a move is blocked? | Position and board state remain unchanged; show a brief blocked-move cue. | Keep the crate, player, and goal in their previous cells. |
For any proposed push, write down three positions: where the crate is, where the player must stand, and where the crate will land. If the desired push direction is d, the stance is the crate’s current cell minus d, and the destination is the crate’s current cell plus d. Then check that the player can walk to the stance without crossing a wall or the crate. This turns “the crate looks close enough” into a repeatable rule.
Trace Why the Starting Board Dead-Ends
In Tideglass Archive, the player starts at (1,3), the crate at (3,3), and the goal at (6,3). Interior walls sit at (3,2), (3,4), and (5,3). The direct row is closed by the wall at (5,3). The upper and lower cells beside the starting crate are also blocked, so its first push must be sideways.
########
#......#
#..#...#
#P.B.#G#
#..#...#
#......#
########The critical test is not just whether the crate can enter an open tile. Suppose it reaches (4,4) by being pushed south from (4,3). To push it east into (5,4), the player must stand at (3,4). That is a wall. The crate’s eastward destination is open, but the required stance is unreachable because the cell itself is blocked.
Other directions do not repair the route. Pushing the crate across the upper corridor cannot bring it down into the goal lane: a south push at the far-right column would require the player to stand on the top border. Sending it down to the bottom edge creates the reverse problem: a north push from the far-right bottom lane would require standing beyond the lower border. The middle wall at (3,2) also blocks a stance needed to push east from the upper row. A finite paper state-space check of these rules finds no winning crate state. This is a rule-graph result for the invented grid, not a test of a playable build.
Use this diagnostic order when a crate seems trapped:
- Choose the next crate direction and write its required stance cell.
- Check the crate’s destination, including walls, borders, and other objects.
- Trace a player-only walking route to the stance. The crate itself may cut off that route.
- Repeat after each push. A legal push can still lead to a later deadlock.
A permanent corner is an obvious deadlock when it is not a goal. Less obvious deadlocks happen along walls or in corridors: the crate is not in a corner, but the player cannot reach the side needed for the next push. Mark goals and stance cells on the same board; checking only the crate’s path misses this failure.
Open One Stance Cell and Replay the Pushes
Change exactly one tile: turn (3,4) from wall into floor. Keep the border, crate, player, goal, and other two interior walls fixed. The revised board now contains the stance cell needed to push the crate east from the lower corridor.
########
#......#
#..#...#
#P.B.#G#
#......#
#......#
########The full player input trace is R R L U U R R D D L D R R D R U. Each letter is one attempted cardinal step. Whenever the player’s next cell contains the crate and the cell beyond it is open, that input performs one push; the trace contains five such pushes, while the other inputs reposition the player. The push checkpoints are:
| Push | Crate movement | Player stance | Why it is legal |
|---|---|---|---|
| 1 · east | (3,3) → (4,3) | (2,3) | The stance and destination are open. |
| 2 · south | (4,3) → (4,4) | (4,2) | The upper corridor lets the player reach the north side of the crate. |
| 3 · east | (4,4) → (5,4) | (3,4) | The one changed floor cell creates the missing stance. |
| 4 · east | (5,4) → (6,4) | (4,4) | The player follows behind the crate through the opened lane. |
| 5 · north | (6,4) → (6,3) | (6,5) | The crate enters the goal from below and the stance stays in bounds. |
The important change is the third push, not a shorter crate route. Before the edit, (3,4) was inaccessible because it was a wall. After the edit, the player can walk there and push the crate into the lower corridor. The target, other walls, and movement rules do not change. Keeping the revision to one cell makes it clear which constraint caused the deadlock.
Write a First-Room Prompt That Can Be Checked
A useful brief states the board, actions, feedback, failure behavior, and reset. It also asks for a visible initial state so the creator can check the result against the written rules. Here is a game-generation prompt template for a future build attempt; it has not been run:
Create a small top-down 2D box-pushing puzzle called Tideglass Archive. Use one player, one glass crate, one brass goal, and an 8-column by 7-row grid. Coordinates start at the top-left. Keep the outer border as walls. In the first room, place interior walls at (3,2), (3,4), and (5,3); player at (1,3), crate at (3,3), and goal at (6,3). The player walks one cell orthogonally at a time and may push a crate one cell into an open cell, but cannot pull or move diagonally. A blocked move or push leaves the state unchanged and shows a short blocked-move cue. Add a reset that restores all objects and feedback to the listed start state. Show the grid, controls, crate, goal, and walls clearly. Do not add extra crates, enemies, portals, timers, narrative branches, or procedural rooms. Let the creator revise one wall cell and inspect whether the player can reach the stance needed for each push. Keep the displayed board state observable; do not claim the level is solvable until it has been checked under these exact rules.Then make the single planned revision from (3,4) wall to floor and request a new view of the same room. Keep the initial setup and all other rules fixed. A good review asks whether the player can reach (3,4), push the crate east from (4,4), and still approach the final north push from (6,5). If the output differs, record the exact first mismatch and correct only the rule or layout that caused it.
Check Deadlocks Before Adding More Rules
For a first room, use a compact acceptance list rather than adding extra mechanics to hide a confusing route:
- Every accepted walk changes the player’s cell by one orthogonal step.
- A legal push checks both the stance and destination; a blocked push changes nothing.
- The crate never moves backward unless the player pushes it from the opposite side.
- The revised board’s written input trace reaches the target under the same rules.
- Reset restores the exact initial positions, walls, and visible feedback.
- A crate entering a non-goal corner produces a clear deadlock state or an obvious reason to reset.
If a check fails, first compare the game state with the coordinate board. Then inspect whether the player can reach the required stance, whether the crate destination is truly open, and whether the goal is in a reachable lane. Keep the revision local: change one wall, one starting position, or one rule at a time. Preserve the previous state so the cause of a changed route stays visible. These are proposed checks for a future implementation, not results from a build or player session.
Use a Puzzle Maker as a Workflow, Not a Solver Claim
SEELE’s puzzle-creation guidance recommends stating the puzzle rule, the clue the player can see, and the action that solves it; it also recommends checking that the puzzle is solvable. For this example, those inputs are the push-only rule, the visible wall and goal, and the player’s stance before each push. Keep the coordinate trace as your own design check. The general game-maker workflow describes giving a plain-English brief, reviewing a playable 2D or 3D result, iterating in Workspace, and reviewing the selected AI model, available Koin balance, and displayed generation cost in Workspace before submitting. Those product facts do not establish that a particular crate rule or board has been implemented correctly.
After any future generation, inspect the actual room: can the player reach the stance at (3,4)? Does a legal push move only one cell? Does the invalid push leave the state unchanged? Can the final push start from (6,5)? A visual preview can help identify mismatches, but only the current implementation and its observed behavior can answer those checks. Keep generated output, paper reasoning, and player feedback as separate evidence.
Keep the First Puzzle Small and Verifiable
When a box-pushing level stalls, inspect the player’s next stance as carefully as the crate’s destination. Tideglass Archive shows how a single wall can close a required stance and how changing that cell can open a complete route. The coordinates and result are a fictional paper example, not an actual game or playtest. Start your own room with one crate, one goal, explicit push rules, and a reset; check every stance before expanding the level.
To begin shaping a puzzle brief around one visible rule and one solving action, use the AI puzzle game maker. Then review any playable output against your own board and movement contract.
Frequently Asked Questions
Can a crate be pulled in this design?
No. The rule is push-only: the player must stand on the opposite side of the crate and move into its cell. If the next crate cell is blocked, the attempted push changes nothing. A reset returns the room to its printed starting state; it does not silently pull the crate back or undo only one object.
How do I spot a deadlock before finishing the level?
For each planned push, mark the crate’s destination and the player’s required stance. Check that the stance is reachable without crossing walls or the crate. Then repeat after the push. Corners are easy to spot, but a crate can also become stuck in a corridor when its next stance cell is blocked, as the original Tideglass layout demonstrates.
How many mechanics should the first room have?
One crate, one target, one push rule, one blocked-move response, and one reset are enough to teach the core decision. Extra crates, timers, portals, or enemies introduce additional constraints before the player can read the basic push loop. Add another rule only after the first room’s walking and pushing behavior is clear.
What should reset restore?
Restore the player, crate, goal, wall layout, and visible feedback to the exact starting board. Keeping the entire state fixed makes a new attempt comparable with the previous one. If reset leaves a wall changed or a crate displaced, the printed trace no longer describes the room that the player sees.
Was Tideglass Archive generated or playtested?
No. Tideglass Archive, its board, wall revision, and route are fictional author-created design material checked against the stated movement rules. No game-generation prompt was run. Codex ImageGen created the three concept illustrations only; no playable build was observed, and no player test or SEELE-generated result is claimed. Use the example as a planning method, then verify your own implementation separately.
