Make one recorded action change the next loop
To make a time-loop puzzle game with AI, start with one action that persists after a reset, one different action the live player can take, and a visible rule that lets them work together. In the example below, an Echo repeats a recorded two-second plate hold while the player moves to another plate. The useful design question is whether their active time overlaps long enough to open the gate.
Clockwork Archive is an original fictional design exercise. Its coordinates, speeds, timings, characters, and room behavior below are authored assumptions, checked with arithmetic on paper. No prompt was run, no playable build or playtest was supplied, and these images do not show SEELE output. Treat the figures as a plan for a future prototype, not as an observed result.
Define the loop, plates, and reset rules
Choose a short loop and state exactly what survives a reset. Here, only the previous loop's recorded movement is replayed. The live player returns to the start and can make a new choice; the Echo follows the stored action at the same timestamps. A pressure plate stays active while an actor stands on it. The gate opens after both plates remain active together for the required dwell, then latches open until the three-second loop resets.
| Rule | Clockwork Archive assumption | What the player should be able to see |
|---|---|---|
| Loop and reset | The loop lasts 3 seconds. If the gate has not opened, the room resets at t=3. | A clear reset moment; the live player returns to Plate A. |
| Recorded action | The previous run's player inputs replay once as a visible Echo at the same times. | The Echo's position and the action it is repeating. |
| Plate hold | Plate A is centered at x=0; Plate B is at x=1. A plate is active only while occupied. | Each plate changes state while an actor stands on it. |
| Gate dwell | Both plates must stay active at once for a continuous dwell. After opening, the gate latches until reset even if an actor leaves. | Overlap begins the dwell; opening is distinct from the gate's later latched state. |
| Movement and win | The live player moves at 2 units per second. Reach the exit at x=2 with the gate latched open before t=3. | A reachable path through the gate and an unmistakable exit state. |
These are not universal time-loop rules. They are a deliberately small contract that lets a creator inspect one relationship: the Echo performs the old action, the player supplies the new one, and a timed gate connects them. If the Echo also made new choices, if the plate had a hidden cooldown, or if the gate closed as soon as either actor moved, the arithmetic and solution would change. Name those behaviors instead of leaving them implicit.
Prompt a small room with a visible echo
A useful first-room request names the starting state, recorded input, live control, replay timing, gate condition, reset, and success check. Keep it narrow so a future result can be compared with the rule list. The prompt below is an unexecuted design request; it is not a report that an AI system generated this room.
Create one original isometric time-loop puzzle room called Clockwork Archive. Use a 3-second loop. Put Plate A at x=0, Plate B at x=1, and a closed brass gate at the exit x=2. The player moves at 2 units per second. A plate remains active only while an actor occupies it. At reset, return the live player to Plate A and replay the previous loop's recorded player actions as a visible teal Echo at exactly the same timestamps.
Make the gate open only after both plates stay active continuously for the requested dwell. Once open, latch it until the loop resets at t=3, even if an actor leaves a plate. Start with a 2-second dwell. The player wins only by reaching the x=2 exit while the gate is latched open and before the reset. Make plate activation, dwell progress, gate opening, latch persistence, reset, and victory readable from the scene without text or a fake HUD. Do not add combat, collectibles, random timing, checkpoints, or extra rooms.
Return the control and state rules, then inspect whether the first loop records a Plate A hold from t=0 to t=2 and whether the Echo repeats it on the next loop. Check whether a live move from x=0 reaches Plate B at t=0.5, whether the two plates overlap for 1.5 seconds, and whether that is shorter than the initial 2-second dwell. Then change only the gate dwell to 1 second. Check whether the gate latches at t=1.5 and whether the player can reach x=2 at t=2 before reset. Compare any future observed result with these requested rules; do not treat this paper calculation as a test.This prompt is intentionally specific about the gate's persistence. “Open the door when both switches are pressed” would still leave unanswered how long they must overlap, whether opening is permanent, and whether leaving a switch closes the gate. Naming those transitions makes a later mismatch diagnosable.
Record the first plate action
In the first run, the player starts on Plate A and holds it from t=0 through t=2. The recording contains that position and its time interval. The loop resets at t=3. On the next run, the Echo repeats the Plate A hold from t=0 to t=2, while the live player is free to take a different route.
For this example, imagine the Echo as a translucent actor rather than a stored button prompt. That makes the rule visible: the old route is still happening in the room, but the player can act elsewhere. The drawing is only a target state for the design. A real implementation would need to show that the Echo follows the intended timestamps and that the live player remains controllable.
Coordinate the echo with the live player
On the second run, the live player moves from Plate A at x=0 to Plate B at x=1. At 2 units per second, that one-unit trip takes 1 ÷ 2 = 0.5 seconds. The Echo remains on A until t=2, so simultaneous A-and-B occupancy runs from t=0.5 through t=2: 2.0 − 0.5 = 1.5 seconds.
| Time | Echo | Live player | Paper-model state |
|---|---|---|---|
| 0.0s | Begins the recorded hold on A. | Leaves the start on A. | Both actors begin the second loop; no A+B dwell has accumulated yet. |
| 0.5s | Still holds A. | Arrives at B. | A+B overlap begins. The gate remains closed while dwell accumulates. |
| 1.5s | Still holds A. | Has held B for 1 second. | With a 1-second threshold, the gate opens and latches. |
| 2.0s | The recorded A hold ends. | Reaches the x=2 exit after leaving B at 1.5s. | The gate remains latched open; the player reaches the exit before reset. |
| 3.0s | The loop resets. | The loop resets if no earlier win state ended it. | The latched gate returns to its starting state. |
The original two-second dwell does not fit: 1.5 seconds of overlap is half a second short, so the gate stays closed in this paper model. That is a clean baseline because only one value—the required dwell—is being tested on paper. It also gives a visible difference to request: before the threshold, both plates can glow while the gate stays shut.
Change one timing rule
Reduce the dwell from 2 seconds to 1 second. Leave the loop, recorded action, plate positions, speed, and gate behavior unchanged. The plates begin their shared interval at t=0.5; adding one second puts the latch moment at t=1.5. Because the gate stays open after either actor leaves, the player can step off B and travel the remaining unit to x=2 in another 0.5 second. The paper-model win arrives at t=2, before the t=3 reset.
| Paper pass | Dwell rule | Gate state | Exit check |
|---|---|---|---|
| v0 baseline | 2 seconds | Does not open: 1.5 seconds of overlap is insufficient. | No win path is available before reset. |
| v1 revision | 1 second | Opens and latches at t=1.5, remaining open until reset. | The live player reaches x=2 at t=2, before t=3. |
This v0-to-v1 comparison is a hand calculation, not an empirical iteration. It does not show that a generated room implements the Echo, collision, dwell, latch, or victory rules. If you build the room later, log the actual trigger time, gate state after the player leaves B, and exit time. If those observations differ from the request, record the mismatch first and then change one rule at a time.
Diagnose replay and reset confusion
When a future build behaves differently, separate the failure from your explanation for it. A short check table can keep the next revision focused without claiming that any of these failures has already happened.
| If a future build shows… | Check first | Possible one-rule revision |
|---|---|---|
| The Echo is missing or appears at the wrong time. | Whether the recording stores position and action timestamps through reset. | Clarify exactly which inputs replay and when the loop clock restarts. |
| The gate opens before both plates overlap. | Whether dwell requires continuous simultaneous occupancy rather than accumulated time. | Restate the overlap condition and when its counter begins or resets. |
| The gate closes as the live player leaves B. | Whether opening is a one-time latch or a hold-open condition. | Keep the latch-until-reset rule explicit; do not change dwell at the same time. |
| The player reaches the gate too late. | Travel time from x=1 to x=2 and the loop deadline. | Adjust one value only if a real observation justifies it; recalculate the trace. |
| A new attempt begins with the old gate state. | Which states reset at t=3: actor positions, plates, gate and stored action. | Specify the complete reset state, not only the player's spawn. |
The table is a future debugging aid for this authored rule set. It is not a list of defects found in a game. Keep the actual playtest record separate from the design target so later readers can tell which values were requested and which were observed.
Use an AI puzzle maker as a rule-first workflow
A puzzle brief can state the learnable rule, the clue or state the player can observe, the action that solves it, and the outcome to inspect. SEELE’s official AI Puzzle Game Maker page describes that general framing and recommends observable clues, fair progression, informative failed moves, and testable solutions. It does not promise deterministic time-loop replay or validate Clockwork Archive’s arithmetic. A broad game-making workflow can help a creator express a request and review a playable first version, but the Echo, plate timing, latch, and win condition still need to be checked in any real result.
For that rule-first starting point, try the AI puzzle game maker. The route is a local CSV candidate, not a published or reserved page. No specific room, mechanic, or result is being claimed as generated.
Build the smallest loop you can explain
A useful time-loop puzzle starts with one recorded action, one new live action, a clear overlap rule, and a visible state change. Clockwork Archive turns that idea into a small paper trace: 1.5 seconds of plate overlap misses the two-second baseline; a one-second dwell latches the gate at t=1.5; the player reaches x=2 at t=2 before the t=3 reset. Those values are fictional design assumptions, not test evidence. When you build a version, observe what it actually does before calling the design successful.
How does a time-loop puzzle use an Echo?
In this design, the Echo repeats the previous loop’s recorded player action at the same timestamps. That lets the live player perform a different action during the next run. Other games may define Echoes differently, so state what repeats and what resets in your own rules.
How long do the plates overlap in the example?
The Echo holds Plate A until t=2, and the live player reaches Plate B at t=0.5. Their shared occupancy lasts 2.0 − 0.5 = 1.5 seconds. That is not enough for the two-second baseline dwell, but it is enough for the one-second paper revision.
Why does the gate stay open after the player leaves Plate B?
The authored rule says that once dwell is complete, the gate latches open until the t=3 reset. Without that persistence rule, leaving B could close the gate before the player reaches x=2. The latch is a design choice in this fictional model, not a verified behavior.
Does the paper revision prove that a playable room works?
No. It only checks that the stated intervals and distances are arithmetically consistent. No prompt was run, no game was built, and no playtest or collision check occurred. A real implementation must be inspected and tested before describing its behavior as observed.
Does SEELE guarantee this time-loop mechanic?
No. SEELE’s official pages describe general puzzle-brief guidance and broad game creation or review workflows. They do not promise this Echo system, timed overlap, gate latch, or exit result. Treat the prompt as a request and test any generated result against the rules you intended.
