A stealth-action prompt becomes useful when it explains what the guard checks, when the check happens, and what the player can do before it resolves. Start with a short corridor, two cover points, one exposed card, and a fixed scan schedule. That gives you a rule set you can trace before asking for a playable scene.
Archive Shift is a fictional paper example in this guide. The three prompt templates below are unexecuted, and the six-turn routes are calculated by hand. They are a design and review method, not a generated game, playtest, or observed result.
Set a small patrol route the player can read
Give the level one visible objective and one source of pressure. In Archive Shift, an infiltrator enters an orbital archive at A, takes a data card at C, and leaves through E. The guard scans one sector after each player action. The player can use cover at B or D, but C remains exposed. That simple line creates a decision: cross C immediately, or wait at B for a safer timing window.
| Sector | What is there? | What the player can do |
|---|---|---|
| A | Entry | Start here without the card. |
| B | First cover block | Move in, then wait through a scan. |
| C | Exposed data card | Move here and spend a separate action to interact. |
| D | Second cover block | Cross to cover on the way out. |
| E | Exit | Win after reaching it with the card. |
The five-sector route keeps the objective legible: the card is not automatically collected by walking over it, and the exit does not count until the card is in hand. The two cover points also make a wait action meaningful without adding a hiding meter, noise system, takedown, weapon, health bar, or random patrol behavior.
This scene introduces the route and its feedback. The empty card slot gives the player a reason to continue, while the unchanged alert meter shows that a scan on cover is safe in this example.
Specify detection and action order before movement
A patrol schedule is only testable when its timing is explicit. Archive Shift starts with the player at A, no card, and alert 0/2. Each action costs one turn. The legal actions are Move one adjacent sector, Wait in place, or Interact at C to take the card. After the action resolves, the guard scans the next sector in the fixed sequence B, C, C, D, E, C.
| Rule | Resolution | Check for a future build |
|---|---|---|
| Movement | Move only one sector along A–B–C–D–E; it costs one turn. | A two-sector move must not happen in one action. |
| Wait | Stay in the current sector for one turn, then resolve the next scan. | Waiting in cover still advances the guard schedule. |
| Interact | At C, spend one turn to take and retain the card. | The card is not collected by movement alone; the scan still follows the interaction. |
| Cover | A matching scan on B or D does not add alert. | Only the two named sectors count as cover. |
| Exposed scan | If player and scan sector match at C, add one alert. | Use the scan after the action, not before it. |
| Terminal state | Alert 2 locks the route and loses. Reaching E with the card wins after that turn resolves. | The alarm loss takes precedence if a scan raises alert to 2. |
Write the order in plain terms: choose one legal action, apply it, advance the guard to the next listed sector, resolve detection, then check for loss or a card-carrying exit. Naming that order prevents a common ambiguity: whether the guard checks the player before or after a move. The fictional rules do not include line-of-sight, sound, detection decay, diagonal movement, or an alternate route. Add such a rule only when the first loop is clear enough to judge.
Compare a safe route with a fast failure
The safe line waits in cover so the first scan of C passes before the infiltrator crosses. Each row records the player position after the action, the guard scan that follows, and the resulting state. That makes the explanation repeatable instead of relying on a vague claim that the route “feels stealthy.”
| Turn | Player action and position | Scan after action | Card / alert |
|---|---|---|---|
| Start | At A | — | No card; 0/2 |
| 1 | Move A→B | B | Cover absorbs the match; 0/2 |
| 2 | Wait at B | C | Player is elsewhere; 0/2 |
| 3 | Move B→C | C | Exposed match; 1/2 |
| 4 | Interact at C; take card | D | Card held; 1/2 |
| 5 | Move C→D | E | Card held; 1/2 |
| 6 | Move D→E | C | Card held; exit reached; win at 1/2 |
Now compare the rush. Turn 1 moves A→B and the B scan is harmless. Turn 2 moves B→C as the first C scan arrives, raising alert to 1. Turn 3 Interact collects the card, but the second consecutive C scan lands while the player is still exposed; alert reaches 2 and the route locks. The player’s action can collect the card, but loss takes precedence at the end of that turn. Waiting costs one turn and prevents that repeated exposure.
The mechanism frame maps to turn 2: the card is still on its plinth, the infiltrator stays at B, the scan cue is on C, and alert remains 0/2. A useful prototype check would compare all four visible facts with the written trace, not just whether the character appears hidden.
Use three prompts with separate jobs
Do not ask one long prompt to invent rules, build a room, and verify its own result in a single answer. Split the work so each request has a concrete input, a bounded output, and a way to check it. The templates below are ready to adapt, but none has been run. Replace the bracketed title or art direction, then inspect any future result against the same turn sequence.
Prompt A: close the rule contract
Design a small stealth-action game called Archive Shift using this fixed room: A Entry, B Cover, C exposed data card, D Cover, E Exit. The player starts at A with no card and alert 0/2. Legal actions are Move one adjacent sector, Wait in place, and Interact at C to take the card. Every action costs one turn. After each action, the guard scans the next sector in this exact order: B, C, C, D, E, C. A matching scan on B or D is ignored because those are cover; a matching scan on C adds one alert. Alert 2 locks the route and loses. The card is retained after pickup. Reaching E with the card wins after the turn resolves. No other mechanics are allowed.
Return a compact state table, action rules, event order, win/loss checks, and a reset state. Flag any ambiguity instead of inventing an extra system. Then hand-resolve both sequences: safe = Move, Wait, Move, Interact, Move, Move; rush = Move, Move, Interact. For each turn list position, scan sector, card state, alert, and terminal result. Acceptance check: the safe route wins at alert 1/2; the rush loses at alert 2 on turn 3.This first request converts genre words into state transitions. Its acceptance check catches timing and interaction errors before visual detail can obscure them.
Prompt B: request one playable scene
Rules contract from Prompt A: [paste the approved contract here]
Using that contract, plan one playable orbital archive corridor with five adjacent sectors A–E. Show the player, the two cover blocks at B and D, the exposed card at C, and the exit at E. Use a clear over-the-shoulder camera and restrained alert feedback. The player must be able to move one sector, wait, and interact with the card. After every action, visibly show the next guard scan. Show cover ignoring a match at B or D, a match at C raising alert, a separate Interact action, and the card carrying to the exit.
Return a scene layout, control list, state HUD, and ordered event description. Keep the first build to this room and these rules; do not add weapons, takedowns, random patrols, extra guards, noise, health, timers, or another objective. Acceptance check: a reader can identify the current sector, next scan, card state, alert, action result, and restart from the opening state. Do not treat a concept image as the playable scene.The second request asks for the smallest playable presentation of the contract. “Show the scan” should mean a visible cue the player can understand before the next decision, while the feedback after an action should reveal whether alert changed. The wording leaves room for an artist or tool to choose the corridor’s details without changing the game’s rules.
This outcome illustration is the expected state after the safe route, not evidence that Prompt B produced it. Its filled card slot, exit marker, and one-of-two alert meter give a future reviewer three visible details to compare.
Prompt C: check a future build without guessing
Rules contract: [paste the approved contract here]
Expected traces: [paste the safe and rush traces]
Observed build evidence: [attach an actual run log or capture, or leave blank if none is supplied]
Review a future Archive Shift build against the supplied fictional contract and expected traces. Do not claim that you executed the game unless an actual run log or observed state is supplied. For each check, request the player action, before-state, guard scan, after-state, alert, card, and terminal result.
Checks: (1) cover at B ignores scan B; (2) Wait at B advances the sequence to C without raising alert; (3) moving B→C before scan C raises alert to 1; (4) Interact at C costs a turn and picks up the card; (5) the next C scan during the rush raises alert to 2 and loses; (6) the six-action safe trace exits at E with the card and alert 1; (7) restart returns to A, no card, 0/2, and scan B next.
Return a table with columns: expected state, observed state supplied by the tester, match or mismatch, and first divergence. If no observed data is supplied, leave observed state blank and describe how a person can check it; never invent a result. Recommend one rule clarification at the first mismatch, then wait for a new observed run before claiming it is resolved.This third request separates an expected result from a real observation. A future tester can supply a capture or written run log; without it, the correct response is a checklist, not a pass claim.
Debug the first divergence, not the whole game
When a future build disagrees with the trace, record the first turn where the state changes. Later differences may be consequences of that one error. Use the table to identify the rule to inspect, then repeat the same input after changing one rule at a time.
| Observed symptom | Rule to check | Next controlled check |
|---|---|---|
| The player is detected while waiting at B. | Does the game classify B as cover before it resolves the scan? | Reset, wait at B, and check whether alert stays 0. |
| The guard scans before a move is applied. | Is scan timing reversed? | Move A→B on turn 1 and verify scan B resolves after the move. |
| The card appears without Interact. | Is pickup incorrectly automatic? | Move onto C without interacting and check that the card remains there. |
| The exit succeeds without the card. | Is the win condition missing its inventory check? | Reach E in a controlled trace with no card and inspect the terminal state. |
For a real review, save the actual before-state and after-state rather than paraphrasing an impression. If a result differs, update the written rule or the implementation request, then capture a new run. The examples here stop at paper calculation because no prompt or build evidence was supplied.
Hand the brief to a general game workflow
The current Free AI Game Maker page describes plain-English input, a playable first version in 2D or 3D, browser testing, and refinement through follow-up prompts. Those statements describe a broad workflow; they do not confirm Archive Shift, guarantee that these rules will be implemented, or show a generated result.
If you use the Free AI game maker, provide a compact rules brief, inspect the returned states, and compare transitions with the expected table. Before submitting, review the selected model, available Koin balance, and displayed generation cost in Workspace. The candidate article path and its entry-source slug are provisional until the page route is accepted.
Archive Shift’s rules and images are fictional teaching materials, not an online game, customer example, or SEELE output. The useful deliverable is a repeatable request-and-review method: state the patrol schedule, state what counts as cover, trace one safe choice and one failure, and use the first mismatch to decide what to clarify.
Frequently asked questions
What should a first stealth-action game prompt specify?
Specify the player’s starting state, one objective, the guard’s exact scan timing, legal actions, cover behavior, and win/loss conditions. Then give an expected route with one action per turn. A builder or reviewer can inspect those details before you add weapons, multiple guards, sound, or other systems that make the first result harder to diagnose.
Is Archive Shift a real or tested game?
No. Archive Shift is an original fictional design used to explain a prompt workflow. Its six-turn safe route and three-turn failure are hand-resolved from the rules in this article. No prompt was executed, no playable build was inspected, and no test or player observation is being reported.
Why name the guard’s scan timing?
Because the same move can be safe or detected depending on whether the guard checks before or after it. In this example, the player acts first and the guard scans second. Naming that order makes the B-to-C crossing, repeated C scan, alert increase, and failure trace reproducible.
What does cover do in this example?
Only B and D are cover, and only a matching scan on those sectors is ignored. Cover does not stop the guard from advancing its schedule, collect the card, or protect the exposed sector C. That narrow rule gives the player a reason to wait at B without adding a second concealment system.
What should I do when a future build diverges from the trace?
Record the first mismatching turn with the action, scan sector, player position, card state, and alert before and after resolution. Check the rule responsible for that transition, clarify one point, reset, and repeat the same sequence. A paper expectation is not proof that a build behaves as intended.
