A programming puzzle strategy game becomes easier to design when the player can predict how each planned action changes the board. Start with a short command queue for every unit, a fixed order for resolving each beat, and a win condition that can be checked from the final state. This guide builds those pieces around Relay Gate, an original five-beat, two-unit puzzle. Its v0 failure and v1 repair are hand-calculated from the written rules; no prompt run, playable build, or real playtest is being reported. You will leave with a compact rule contract, a trace for finding a timing bug, and a focused brief you can later inspect in a generated result.
Define the command-programming loop
The core loop is simple: write one command queue per unit, resolve one slot from each queue, apply the level rules in a fixed order, inspect the new state, then change one instruction if the trace exposes a problem. The player makes a strategy decision before the units move, so the interesting question is whether their plans still work together after the same beat resolves.
For a first design, choose whether commands resolve simultaneously or one unit at a time. Relay Gate uses simultaneous slots: both units act from the board state at the start of the beat. That makes timing a visible design problem. If the Operator leaves a pressure plate during the hazard beat, the Scout can lose access to the gate one beat later. Another game could use sequential resolution, but it must state who acts first and when switches or hazards update.
Keep the first puzzle small enough to trace by hand. Two units, one switch, one gate, one hazard, and a short objective are enough to reveal whether the command model is understandable before adding more rooms, enemies, or resources.
Write a rule contract before the level
Before drawing the puzzle, define what each command does and when the world responds. This avoids hidden timing assumptions, such as whether a gate closes before or after a unit tries to cross it.
| Rule | Relay Gate definition | What to verify later |
|---|---|---|
| Command slots | Each unit has five slots. EAST, NORTH, SOUTH, or WEST attempts one orthogonal step; WAIT stays; GUARD stays and spends the Scout’s single pulse-blocking charge. | Both queues advance once per beat, including WAIT and blocked moves. |
| Blocked movement | A unit that tries to enter a wall or a closed gate remains in place, and the attempted slot is still consumed. | No blocked command is silently retried on the next beat. |
| Beat order | Read the previous gate state; execute both commands simultaneously; resolve the sentry pulse after beat 3; then evaluate the plate for the next beat. | The gate never changes halfway through a beat. |
| Gate dependency | The gate is open for the next beat only when the Operator ends the current beat on the plate. | Leaving the plate closes the gate on the following beat, not the current one. |
| Hazard and reset | After beat 3, the pulse disables an unguarded Scout on (3,2). GUARD blocks this one pulse. Reset restores starts, closed gate, one guard charge, and beat zero. | GUARD is consumed once, and reset restores every listed state. |
Write the win and fail checks just as plainly. Relay Gate is cleared only if the Scout reaches the exit while the Operator is still on the plate. The run fails if the Scout is disabled or the five-slot program ends first. These checks turn “the level feels solved” into a state that another person can verify from the trace.
Set up the Relay Gate puzzle
Use a five-column by three-row orthogonal grid. Coordinates are written as (column,row), with column 1 at the left and row 1 at the top. The floor lane follows row 2; the closed gate occupies that lane at (4,2). The Scout starts at (1,2), and the Operator starts at (1,3), one step from the pressure plate.
| Object | Coordinate | Job in the puzzle |
|---|---|---|
| Scout | (1,2) | Follow a five-command route to the exit and guard against the timed pulse. |
| Operator | (1,3) | Reach and hold the pressure plate at (2,3) to keep the gate open. |
| Pressure plate | (2,3) | Opens the gate for the next beat when occupied by the Operator. |
| Gate / exit | (4,2) / (5,2) | Block the lane until the plate is held; the Scout must reach the exit. |
| Stationary sentry | (3,1) | Pulse tile (3,2) after beat 3; an unguarded Scout there is disabled. |
The two roles create a coordination puzzle rather than a race. The Scout can reach the exit in time, but only if the Operator remains on the plate. The sentry adds one timing decision: the Scout must spend its one GUARD slot when the pulse resolves, or reset and plan again.
Trace v0 and find the failure
Keep the Scout queue fixed at [EAST, EAST, GUARD, EAST, EAST]. In v0, the Operator queue is [EAST, WAIT, EAST, WAIT, WAIT]. Read each row after both commands resolve and the beat-3 pulse has been handled.
| Beat | Scout state | Operator state | Gate and hazard result |
|---|---|---|---|
| 0 | (1,2) | (1,3) | Gate closed; Scout has one GUARD charge. |
| 1 | (2,2) | (2,3) | Operator lands on the plate; gate opens for beat 2. |
| 2 | (3,2) | (2,3) | Plate remains held; gate stays open for beat 3. |
| 3 | (3,2), using GUARD | (3,3) | GUARD blocks the pulse. Operator leaves the plate, so the gate closes for beat 4. |
| 4 | (3,2); EAST is blocked | (3,3) | Closed gate blocks the Scout; the slot is consumed. |
| 5 | (3,2); EAST is blocked again | (3,3) | Program ends with the Scout short of the exit: fail. |
The failure is not that the Scout needs another movement slot. It is that the Operator leaves the plate on beat 3. Because the gate state updates for the next beat, it is still open during beat 3 but closed when the Scout tries to cross on beat 4. That distinction gives the revision a precise target.
Repair one instruction and verify v1
Change only Operator slot 3 from EAST to WAIT, producing [EAST, WAIT, WAIT, WAIT, WAIT]. Keep the Scout queue, map, pulse, command rules, and win condition unchanged. Replaying from reset gives this trace:
| Beat | Scout state | Operator state | Gate and hazard result |
|---|---|---|---|
| 0 | (1,2) | (1,3) | Gate closed; one guard charge. |
| 1 | (2,2) | (2,3) | Plate held; gate opens for beat 2. |
| 2 | (3,2) | (2,3) | Plate held; gate remains open. |
| 3 | (3,2), using GUARD | (2,3) | Pulse blocked; plate held; gate remains open for beat 4. |
| 4 | (4,2) | (2,3) | Scout crosses the gate that was open at beat start. |
| 5 | (5,2), at the exit | (2,3) | Plate remains held; both parts of the win condition are true. |
To verify a later implementation, reset before each run and inspect one beat at a time. Check that the same slot number advances for both queues, the pulse occurs after beat 3 commands, the gate uses the prior beat state during movement, and the plate sets the next state. Confirm that GUARD is spent once, blocked movement consumes a slot, and the final exit does not count as a win if the Operator has left the plate.
Turn the rules into an AI build brief
A useful first brief gives the builder the smallest playable slice and asks for visible state feedback. The following template is unexecuted; it is an input to test later, not evidence that a game has been made.
Create a small top-down programming puzzle strategy game called Relay Gate on a 5-by-3 grid. Use the exact coordinates, unit starts, plate, gate, exit, and beat-3 sentry pulse from the design brief. Give the Scout and Operator separate five-slot command queues with EAST, WEST, NORTH, SOUTH, WAIT, and GUARD. At each beat, execute both commands simultaneously using the previous beat's gate state; then resolve the beat-3 pulse; then update the gate for the next beat from Operator occupancy on the plate. A blocked move consumes one slot. GUARD consumes the Scout's single charge and blocks the pulse. Win only when the Scout reaches the exit while the Operator holds the plate; disable the Scout on an unguarded pulse; include a reset. Show a readable tile grid, the two queues, Run and Reset controls, gate/plate/pulse feedback, and a beat trace. Include the v0 queues, then change only Operator slot 3 to WAIT and show why v1 clears. Keep the rule order literal. Let the player inspect and replay each beat.When you later inspect a result, compare it with the contract rather than judging only by appearance. Verify command order, blocked slots, pulse timing, gate persistence, guard reset, both terminal states, and a complete reset. If the result differs, note the exact beat and expected state, then request one focused change. A brief can make an implementation easier to inspect; it cannot guarantee that a generation tool follows every rule.
Review and iterate the prototype
SEELE's current Free AI Game Maker page says creators can describe a game in plain English, generate a playable 2D or 3D first version, test it in a browser, and refine it with follow-up prompts. It advertises free Koins and says to review the displayed cost before each generation; its cost FAQ says to check the selected model, Koin balance, and displayed cost in Workspace. These are general workflow facts, not evidence that Relay Gate's simultaneous queues or exact rules are supported or guaranteed. If you try the idea, inspect the returned result against the acceptance checks.
Keep the next step narrow. First look for a readable queue and a trace that exposes the order of events. If a result hides the state you need to verify, revise the brief to request that feedback before adding more mechanics. Treat the five-beat paper example as a design aid, not a report of a generated or tested game.
When you are ready to explore a game idea in a general creation workflow, start with the Free AI game maker. Bring the smallest clear brief, review the result, and decide which single rule needs another pass.
Programming puzzle strategy game FAQ
What makes a programming puzzle strategy game different?
The player plans commands for autonomous units and then studies how those commands resolve under the level rules. In Relay Gate, the strategic choice is whether the Scout's route and Operator's plate timing remain compatible across five simultaneous beats. Other games may resolve commands differently, so specify the model rather than assuming a genre-wide rule.
Should both units execute commands at the same time?
That is a design choice, not a universal requirement. Simultaneous slots make it easy to create timing puzzles in which two plans depend on the same beat. Sequential turns can make cause and effect easier to read, but they introduce an action-order decision. State who acts when, then test a short trace for the outcome you want.
How many commands should a first puzzle use?
Use only enough slots to show the core decision and one meaningful failure. Relay Gate uses five beats to show a switch, a timed pulse, and an exit without a long program. That number is specific to this teaching example, not a genre limit. If readers cannot follow the trace, shorten the route or remove a mechanic.
Can SEELE make this exact Relay Gate game?
The official page describes plain-English game input, a playable 2D or 3D first version, browser testing, and refinement with follow-up prompts; it also tells users to review the displayed generation cost. It does not establish that Relay Gate's command queues or timing rules are supported, or promise rule fidelity. Inspect any returned result before treating a rule as implemented.
Is the Relay Gate walkthrough a tested game?
No. Relay Gate is an original design example, and the v0 and v1 traces are calculated by hand from the rules printed here. No prompt execution, generated build, playable sample, real playtest, or measured iteration is being reported. The proposed scenes illustrate those states; they are not screenshots or evidence of software behavior.
