A light-and-shadow puzzle is satisfying when the player can predict what changing the light will do. Start with one lamp, one blocker, one target and one visible consequence. This guide uses a fictional room where a shadow becomes a bridge only when it reaches two marked endpoints; the same connection lights a receiver and opens a gate. The rule is invented for a game, not a claim about real optics. No SEELE prompt, playable build or playtest is available for this example.
Start with one shadow decision
Use one question to organize the first room: can the player aim the lamp so the shadow connects the start and destination markers? In the proposed Lantern Gallery, a fixed-pivot brass lamp throws light past a tall stone fin. When the cast shadow touches both coral-edged markers across a short gap, the game treats that strip as a solid path. The far receiver glows and the gate opens. The player then crosses the bridge.
This small rule creates a complete loop: inspect the room, adjust the lamp, read the shadow, confirm the receiver response, and cross. It also gives you a clear way to judge a first design. If the player cannot see what changed, cannot tell whether the path is connected, or sees the gate respond before the rule is met, improve the clue or state feedback before adding more puzzle objects.
Keep the light source fixed in place and let the player rotate its aim around a pivot. That makes the relationship between the lamp, fin and shadow easier to understand than a free-moving light with many possible positions. Controls such as dragging the lamp handle or tapping left and right are design choices for this example, not confirmed SEELE controls.
Choose what the shadow does
Before you decorate the room, decide whether the shadow reveals something, hides something, or creates something the player can use. Each choice creates a different puzzle. A revealing shadow can expose a symbol; a hiding shadow can conceal a hazard; a shadow bridge can change where the player is allowed to walk. The Lantern Gallery uses the bridge because it connects the light puzzle to a visible traversal goal.
Write the bridge rule as a game state, not as a vague visual effect. In this fictional design, the bridge is inactive until the projected shape reaches both endpoint markers at once. A connected shadow is traversable and also reaches the receiver. When the connection breaks, the receiver turns off and the gate closes. If a real game changes one of those conditions, record the actual behavior separately rather than assuming the design brief was implemented.
| Shadow state | What the player sees | What the game does |
|---|---|---|
| Short of the first marker | The shadow stops before the near coral endpoint. | No bridge; receiver stays dark; gate stays closed. |
| Connected across both markers | A continuous strip touches the near and far endpoints; the receiver glows. | The path becomes traversable and the gate opens. |
| Past or away from the far marker | A visible break appears before the receiver. | The bridge and receiver turn off; the gate closes. |
The table is a proposed rule contract, not an observation from a running game. It helps you ask three separate questions: what is the clue, what state is active, and what action becomes possible? Keep those answers distinct. A glowing receiver should confirm that the shadow reached it; the bridge should communicate traversal; the open gate should communicate the consequence.
Block the room as a light path
Place the puzzle objects so a player can trace a simple path from cause to result. Put the lamp at the start side of the gap, the fin between the lamp and the far ledge, and the endpoint marks where the shadow should begin and finish. Place the receiver at the far endpoint and the gate just beyond it. Give the player a clear standing area beside the lamp and enough room to see the far ledge while changing the aim.
| Room object | Puzzle job | Clue or response |
|---|---|---|
| Fixed-pivot lamp | Lets the player change the beam angle. | A visible handle or beam direction suggests what can be adjusted. |
| Stone fin | Shapes the cast shadow into a narrow route. | Its silhouette should be visible between the lamp and the gap. |
| Near endpoint | Marks where the route begins. | A coral outline remains visible in both lit and shadowed states. |
| Far endpoint and receiver | Confirms that the route reaches the destination. | The receiver glows only when the shadow connects to it. |
| Gate | Shows the consequence of a valid connection. | It opens after the receiver activates, not merely because the lamp moved. |
Keep a small raised camera that shows the explorer, the floor edge, the gap and the far receiver together. If the player must turn away from the source to check the destination, consider a fixed camera angle or a simple view that keeps both ends visible. Do not rely on text to explain the main rule when the room can show it directly.
Make the receiver mark survive the shadow. A dark patch can hide a dark target exactly when the player needs to verify alignment. The coral border in this design sits just outside the shadow's interior, so it remains visible while the center of the receiver darkens. This is a readability choice, not an additional activation rule.
Write a focused prototype prompt
A useful prompt names the first action, the state change and the check that proves the rule is connected. It also tells the builder what to leave out. For this design exercise, the reader could adapt the following brief; the control bindings are suggestions for a new game, not SEELE interface instructions.
Create a small 3D puzzle room called Lantern Gallery. Use a slightly raised third-person camera that keeps the player, lamp, floor gap, both endpoint markers, receiver and gate visible. The player stands on a safe start ledge beside a fixed-pivot brass lamp and can rotate its aim with left and right input. A stone fin blocks part of the beam and casts a deep-blue shadow toward the far ledge.
Use this fictional game rule: the shadow is a solid path only while one continuous shape touches both coral-edged endpoint markers across the gap. When the shape reaches the far receiver, light the receiver and open the simple gate beyond it. If either endpoint loses the shadow, turn off the receiver and close the gate. Keep the coral marker borders visible inside and outside shadow so the player can judge alignment.
Give the player a short route across the connected shadow bridge to the far ledge. Make the lamp, fin, shadow, receiver and gate visually distinct. Start with one room and one puzzle; exclude extra light sources, collectibles, enemies, timers and unrelated switches. Provide the proposed scene and a short checklist of the connection rule, receiver response, gate response and player traversal for the creator to inspect. This is a fictional design specification, not a claim that a generated result has been tested.Then review the result as a set of questions, not as a promise that one prompt guarantees a working mechanic. Can the player identify which lamp to aim? Can they see both endpoints while adjusting it? Does the bridge become usable only when the continuous shadow reaches both marks? Does the receiver and gate respond to that same condition? If an implementation differs from the intended rule, record the observed state and ask for one focused change.
Inspect alignment, traversal and feedback
Separate the shape of the shadow from its state and from the player's contact with it. The shadow may look connected without being walkable; the player may touch the far receiver without the receiver being active; the gate may open for the wrong reason. Inspect those steps in order using the same starting room and lamp position each time.
| Symptom | Likely design question | Focused adjustment |
|---|---|---|
| The shadow looks like a path but the player cannot cross. | Is traversal tied to the connected state? | Make the state boundary visible, then specify when collision becomes active. |
| The far target vanishes in the dark patch. | Can the player still locate the receiver? | Move its outline outside the shadow while leaving the rule unchanged. |
| The gate opens while the shadow is broken. | Does the gate listen to the receiver or a different trigger? | Bind the gate response to the receiver's connected state. |
| The player cannot tell where to stand or go. | Are the start ledge, gap and destination visible together? | Clear the route and adjust the camera before adding more effects. |
Change one design variable per pass. If you change the lamp angle, endpoint locations and gate animation at once, you will not know which change made the route easier to read. Keep a simple expected-state note beside each future test: “both marks touched → bridge active → receiver lit → gate open.” A later real build can then be compared with a clear reference, but this article has no observed build results.
Simulated iteration: keep the receiver visible
Here is a hand-resolved design rehearsal, not a measured iteration. In fictional v0, the receiver's center mark sits inside the darkest part of the shadow. The bridge may be aligned, but the player loses sight of the target needed to confirm it. In fictional v1, keep the exact same endpoints, connection rule and gate condition, and add a thin coral outline just outside the shadow. The player can now read the target in both light states.
The proposed checks are simple: the endpoint border remains visible when the receiver center is dark; the bridge appears only when one continuous shadow touches both markers; and the receiver and gate respond to that same connected state. A paper walkthrough can confirm that the design statements fit together. It cannot establish that a real player understands them, that the rendering communicates them, or that any game engine implements them correctly.
Where an AI game maker fits
Once the room rule is specific, a game maker can be asked to turn the brief into a starting game for inspection. SEELE's current Free AI Game Maker page describes plain-English game ideas, review of a playable 2D or 3D result in a browser, and follow-up prompt refinement. Before submitting, review the selected AI model, available Koin balance, and displayed generation cost in Workspace. These broad capabilities do not verify this shadow bridge, its collision behavior or its receiver logic. Treat the proposed prompt as an input to assess, then inspect the actual result.
Keep your own rule card beside the result: beam past the fin, shadow reaches both marks, bridge becomes traversable, receiver lights, gate opens. If a result only draws a dark streak, that is not the same as the walkable rule. Ask for a focused change and verify the changed behavior in the resulting playable build before calling it successful.
Write your own one-room brief
Choose one light source, one blocker, one visible target and one consequence. Decide what the player moves, what state must be true, what feedback confirms it and how the player will know the puzzle is solved. Start with that compact brief in the Free AI game maker, then inspect the result against the rule you wrote. The Lantern Gallery is a fictional teaching design, not a published game or proof of a product outcome.
Frequently asked questions
Should the player move the lamp or rotate it?
Choose one clear interaction for the first room. This example keeps the lamp fixed and lets the player rotate its aim, which makes the relationship between source, blocker and shadow easier to inspect. A movable lamp can work too, but it adds position changes to the same puzzle; treat that as a separate design choice rather than assuming the product has a particular control scheme.
How can I keep the target visible in a shadow puzzle?
Use a high-contrast outline or marker outside the darkest part of the shadow. The player should be able to locate the target whether the light is aligned or not. In the simulated Lantern Gallery revision, only the coral receiver border moves; the bridge and gate rules stay the same.
Can a shadow become a platform?
Yes, as an explicitly fictional game mechanic. The Lantern Gallery treats a connected shadow as a traversable surface when it touches both endpoint markers. That is a design rule for the game, not a statement about real shadows or a guaranteed engine capability. Specify the condition and inspect the result in an actual build.
How many light sources should a first puzzle room use?
Start with one controllable source so the player can connect a change in aim to a change in shadow. Add another source only when it introduces a distinct decision that the room needs. More lamps can create ambiguity about which shadow activated a target, so keep each source and its consequence readable.
Can an AI game maker guarantee the shadow mechanic will work?
No. The official product page describes general game creation and review capabilities, but it does not guarantee this specific shadow-to-bridge mechanic. Treat the prompt as a brief, inspect the playable result, and verify traversal, receiver and gate behavior yourself. This package contains a fictional design and paper-only revision, not a generated or tested game.
