A lantern, a shutter, and a mirror can produce a puzzle that looks correct yet never opens its door. The missing ingredient is time: the player must arrange the actions before running them. To make a light-and-shadow puzzle game with AI, define how each event changes persistent state, then ask for one room that can replay the sequence from a known starting point. Lighting should communicate that state rather than secretly decide it. This tutorial uses the original teaching project The Lantern Archive to explain event ordering. You will define three action cards, specify their prerequisites, and prepare checks for valid and invalid sequences. Start with a single room and clear feedback before adding atmosphere. A compact scope makes it easier to compare the generated rules with your brief and request one focused correction at a time.
Define the one-room contract
The archive contains a closed shutter, an unaligned mirror, an unlit lantern, and a locked exit. The player arranges three cards: Open Shutter, Align Mirror, and Light Lantern. Opening the shutter exposes the mirror mount. Align Mirror succeeds only when that mount is exposed. Light Lantern sends a single pulse; the receiver charges only if the shutter is open and the mirror is aligned at that moment. The lantern does not continuously retry the receiver. This last rule makes the event order meaningful instead of allowing every permutation to converge on the same ending.
Keep the implementation independent of the artwork. Store shutter_open, mirror_aligned, receiver_charged, and run_finished as explicit values. Show each action result beside its card, including an explanation when a prerequisite fails. A blocked action consumes its position in the sequence but does not abort the remaining cards. Include these prerequisites explicitly in your implementation brief so the behavior follows your design.
Build the sequence before adding atmosphere
Start with labeled rectangles and one Run button. Ask the AI to let players reorder the three cards using selectable up and down controls; dragging can be added later. On Run, disable editing, restore the initial state, and execute each card once. Mark the active card with both an outline and an icon so the explanation remains readable without color. At the end, enable editing and offer Replay and Reset. Replay uses the currently arranged sequence; Reset also restores the original card order.
Keep timing cosmetic. A short pause between cards helps readers connect action and outcome, but the receiver should depend on event state rather than frame timing. In a Godot implementation, signals can notify the display that a rule has resolved, as described in the official signals tutorial. The teaching design does not require Godot: the same state transitions can be implemented in another engine.
Give the AI a bounded generation brief
Use the prompt below as a starting brief. Ask the generator to summarize the state transitions before requesting decorative assets. Compare that summary with your contract: if lighting the lantern creates a permanent beam that later benefits from moving the mirror, the generated rules have changed. Correct that discrepancy before expanding the room. Keep the first milestone limited to one valid sequence and understandable failure feedback.
After the basic room works in your environment, add the observatory art and a visible beam that reflects the stored receiver state. The beam is a presentation effect; do not replace your explicit prerequisite checks with a visual ray that happens to cross the receiver. This separation makes it easier to diagnose an attractive room that still accepts the wrong solution.
Plan one focused revision
A plausible first design shows only a red cross after a failed run. That tells the player nothing about the broken dependency. The proposed revision adds a short result to each event: mount hidden, mirror aligned, or pulse missed. Preserve the order and starting state while changing this feedback. Then ask a new reader to explain why Light Lantern before Align Mirror fails. Use the explanation you hear to decide whether the feedback needs another revision.
Do not add a fourth card to solve a feedback problem. First check whether the existing sequence communicates cause and effect. If the room can be solved by rapidly pressing Run, confirm that every run clears receiver_charged. Stale state can make a broken dependency look like an alternate solution.
A bounded prompt for your first prototype
Build one original light-and-shadow puzzle room. Provide three reorderable event cards: Open Shutter, Align Mirror, Light Lantern. Start every run with all state false. Align Mirror only succeeds after Open Shutter. Light Lantern emits one pulse and charges the receiver only if shutter_open and mirror_aligned are true at that event. Failed actions consume their slot and explain why. Open the exit only after receiver_charged. Include keyboard-accessible reorder buttons, Run, Replay, and Reset. Use placeholder art. Do not add extra rooms or automatic retries. Report the state transition rules before implementation.Checks to run on your build
Use these checks to compare your build with the intended rules and expected outcomes.
| Check | Expected outcome |
|---|---|
| Open → Align → Light | Receiver charges and the exit opens after the pulse. |
| Light → Open → Align | Pulse misses; the exit remains locked at the end. |
| Align → Open → Light | Alignment fails while hidden; opening later does not retroactively align it. |
| Valid run, then invalid run | The second run begins clean and cannot inherit a charged receiver. |
| Reset during editing | State and original card order return together; no old animation changes the result. |
Where SEELE fits in this workflow
SEELE's official site describes a prompt-driven game creation and editing workflow. That makes a compact rule contract a useful input: submit the bounded brief, inspect the resulting interactions, and describe one correction at a time. The product is an implementation aid in this workflow; the event prerequisites and acceptance checks remain your design responsibilities. Use the event contract as your reference when reviewing each generated iteration.
Use the AI puzzle game maker entry point when you are ready to turn the contract into a prototype. Request a summary of the current rules after a revision and compare it with the original brief. Avoid assuming that an attractive light beam proves the state machine is correct. Review actual controls, reset behavior, and run outcomes in the product before expanding the scope.
Build the first small version
Begin with three actions whose prerequisites make their order matter. Keep the light effects separate from the rules, clear state before every run, and explain failure at the event that caused it. A successful first milestone is a room whose valid and invalid sequences you can both explain. The next step is to take the brief to SEELE's AI puzzle game maker and build that bounded prototype. Keep this article's checks beside the project and record your actual observations; replace the conceptual images with verified captures only after you have a working build.
AI puzzle game maker: use the bounded brief above to begin your prototype.
Frequently asked questions
Does this require realistic lighting?
No. Labeled shapes and a simple beam illustration are enough to establish the rules. Realistic lighting can make a finished room more expressive, but it also makes rule errors harder to isolate. Keep the receiver's logical state explicit, then make the visuals reflect it. Add advanced lighting after the action order is understandable.
How do I stop players from solving it by repeated runs?
Restore every logical value before each run, including the receiver charge and any queued action callbacks. Lock editing while the sequence resolves. If an earlier run can still change the current room, add a run identifier and ignore outdated callbacks. Compare successive runs to confirm that each sequence begins from the same initial conditions.
Should I add undo or full replay first?
Start with replay from a clean initial state. With three cards, replay is easy for the player to understand and easy for you to compare against a written rule contract. Undo requires restoring the previous state of every affected object. Add it later if players need to explore longer sequences without repeating the entire room.
Official sources and design scope
Consult the official references below for the product workflow and engine features used in this tutorial.
