Write Survivors-Like Prompts for a Testable First Run

How do you turn a survivors-like idea into a brief a creator can inspect? Define the movement, automatic attack, enemy timing, upgrade trigger, and run endpoint before asking for a full game. Then write one prompt for the rules, one for a small playable slice, and one for checking a future result against expected states.

Emberwake Circuit, its values, and the three scenes in this guide are fictional teaching material. The prompt templates have not been run, and the encounter below is calculated by hand. It is a planning method, not a generated build or playtest report.

Define the smallest first run

A short survivors-like prototype needs enough of the loop to show movement, an automatic attack, an enemy response, and a reason to make a second decision. Emberwake Circuit starts in one top-down arena. The player moves with WASD, but does not aim or press an attack button. A Pulse Needle fires on its own at the nearest visible Ember Moth within range. Defeated Moths award experience; at two points, combat pauses for a choice between a faster interval and longer range.

The coordinate origin is the arena center, so the 20-by-20-meter bounds run from −10 to 10 on both axes. The player begins at (0, 0) with 3 HP. The Moths use fixed, unobstructed spawn points. The first Moth is placed at t=0 as setup; that instant is not a movement tick. At each positive whole second, any scheduled Moth spawns, every present Moth moves 0.25 meters toward the player, a due shot resolves, and contact damage is checked. This order matters because the t=8 Moth moves once before the upgraded shot.

The full schedule gives a future builder precise positions to implement. It also keeps the eight-second hand trace small: the first three Moths are the only ones needed to explain how a level-up changes the next attack.

The runner is stationary here to make the attack distance easy to audit. An open route remains visible to suggest where movement belongs in a later build; the image does not document a run or a product screen.

Write a rule prompt with checkable state

Prompt 1 should ask for a closed contract before it asks for attractive effects. Name the coordinate system, valid movement, spawn positions, enemy speed, target rule, cooldown, experience threshold, upgrade effects, and terminal conditions. Also specify which event happens first. Without event order, two implementations can both look plausible while disagreeing about whether a newly spawned enemy moves before a shot or whether contact can happen after the target is removed.

For Emberwake Circuit, the initial Pulse Needle shot is due at t=3. It deals 1 damage to a 1-HP Moth. If a shot is due without a legal target, the weapon stays ready and fires when a target becomes valid. A kill adds 1 XP. At 2 XP and again at 4 XP, pause after the current tick and offer exactly two choices: Quick Needle changes the interval from 3 seconds to 2; Long Reach changes range from 6 meters to 8. Each option may be chosen once. Restart restores the player, cooldown, XP, upgrades, spawn schedule, and closed gate.

These checks turn each rule into something a later reviewer can see or reproduce. The values are not balance recommendations; they are an intentionally small fictional contract. The t=30 gate has no separate deadline, and no Moths spawn after t=24, so the player can move toward it once it opens without adding another timed system.

Prompt 1: close the rules before building

Specify a fictional survivors-like game called Emberwake Circuit using this contract. Arena: a centered 20×20-meter square with x and y from −10 to 10. The player starts at (0,0) with 3 HP, moves with WASD at 2 meters per second, and has no manual aim or attack button. The 1-HP Ember Moth moves 0.25 meters toward the player at each positive whole-second tick. Spawn one Moth at t=0 at (4,0) as setup without resolving movement at t=0; later spawns are t=4 at (−5,0), t=8 at (0,6), t=12 at (0,−6), t=16 at (6,0), t=20 at (0,5), and t=24 at (−6,0). At each positive whole second, spawn any scheduled Moth, move all present Moths including a just-spawned one, resolve a due shot, then resolve contact. Pulse Needle begins with its first shot due at t=3, deals 1 damage, and automatically targets the nearest visible Moth within 6 meters; ties select the earliest-spawned Moth. A due shot with no valid target stays ready until one is valid. Each kill gives 1 XP. At XP 2 and 4, pause after the current tick and offer exactly two unused upgrades: Quick Needle changes the interval from 3 seconds to 2, or Long Reach changes range from 6 meters to 8. Each can be chosen once. After resolving the t=30 tick, open an exit gate centered at (8,8) with a 0.75-meter entry radius. The player wins when entering it with HP above zero; HP 0 first is a loss. No spawns occur after t=24. Restart restores the complete initial state. Do not add random behavior or extra systems.
Return a compact state table, event order, win/loss rules, upgrade timing, and any unresolved ambiguity before proposing art. Hand-resolve the t=3, t=6, and t=8 states. Acceptance check: the Moth distances at those shots are 3.25m, 4.25m, and 5.75m; XP becomes 1, 2, and 3; the t=6 choice makes the next shot due at t=8.

This request separates design decisions from presentation. If the returned state table changes the spawn convention or cooldown timing, correct that before expanding the room; otherwise a later discrepancy can look like an art or input problem when the underlying rule was never fixed.

Request one arena and one visible level-up

Prompt 2 should translate the approved contract into a single playable slice. Ask for one open arena, one controllable runner, one enemy type, one automatic weapon, simple health and XP feedback, a paused level-up choice, and a restart. Keep the input contract small. The creator should be able to steer, watch the weapon select its target, read why an upgrade appears, and repeat the opening after a loss.

Give the builder explicit acceptance checks rather than asking it to “make the combat feel right.” Check the range boundary on both sides, the nearest-target tie rule, the order of spawn and movement, the first shot at t=3, the 2-XP pause, and the new t=8 cooldown. Check the gate only after the t=30 events resolve. These are implementation targets for a future build, not claims that a current result meets them.

Prompt 2: build the first playable arena

Using the approved Emberwake Circuit contract from Prompt 1, plan and build one top-down arena only. Keep the centered 20×20-meter bounds, WASD movement, fixed spawn schedule, 1-HP Ember Moths, automatic nearest-target Pulse Needle, XP, the two one-time upgrades, contact damage, and the gate exactly as specified. Add a restrained HUD for current HP, XP, weapon cooldown, and the level-up pause. Make the runner, Moths, attack pulse, and open route readable from a slightly elevated camera. Do not add weapons, bosses, random drops, currency, a shop, extra enemy types, or a hub.
Return the scene plan, controls, UI state list, event order, and reset behavior before implementation. Then provide one playable first pass and a checklist with the evidence needed to verify each rule. Include tests for: (1) t=0 placement without a movement tick; (2) t=3 first shot at 3.25 m; (3) the t=4 Moth reaching 4.25 m before the t=6 shot; (4) the t=6 XP-2 pause and Quick Needle selection; (5) the t=8 shot at 5.75 m; (6) an out-of-range target and an in-range target; (7) a tie resolved by spawn order; (8) a contact hit after movement when a Moth is within 0.5 m; (9) all remaining scheduled spawns and the ready-shot rule; (10) the gate opening after t=30 resolution and victory only after entering its radius; (11) HP reaching zero before gate entry; and (12) restart restoring the initial state. Mark any unavailable test as unverified instead of assuming it passed.

That image keeps the enemy field empty at the choice point. This matters because the rule example has two kills by t=6 and no third Moth until t=8. The two icon tiles represent different decisions: shorten attack timing or extend reach. Their appearance explains what a future level-up might ask the player to choose, while the article’s manual trace supplies the exact values.

Hand-check the first upgrade

A short expected trace gives a later reviewer a reference without pretending a build has been tested. Start at t=0 with the Moth at (4,0). It does not move during setup. At t=1, t=2, and t=3 it moves three times toward the stationary player, reaching 3.25 meters. The scheduled shot removes its 1 HP and awards 1 XP.

The t=8 target is still within the original six-meter range, so the trace isolates the interval change. The first two Moths are already gone, and no contact damage occurs. It does not test the full thirty-second run, prove the upgrades are balanced, or say anything about how an AI builder would implement the rules.

At t=10 the next cooldown is ready, but the arena has no target, so the shot remains ready. When the t=12 Moth spawns and moves to 5.75 meters, the weapon can fire. That follows from the same rule without adding a special case for empty cooldown windows.

Ask for a first-divergence report before changing more

When a future build differs from the expected trace, record its first mismatch instead of asking for a broad redesign. The useful report names the action and pre-state, the rule that should resolve, the expected state, the observation supplied by a person, and the smallest proposed correction. If no one has run the build, leave the observation empty. A model or author should not fill in a plausible result and call it a test.

Prompt 3: compare supplied evidence with the expected trace

Expected fictional contract and hand trace: [paste the approved Emberwake Circuit rules and t=3, t=6, t=8 table].
Observed build evidence: [attach an actual capture or tester log, or leave blank if none exists].
Compare only the supplied evidence with the expected rules. Do not claim you ran the game unless the evidence actually contains a run. At each checkpoint, record: player position and HP; active Moths and their distances; whether a shot was due; selected target; damage; XP; upgrade state; and terminal state. Check the t=0 setup convention, t=3 distance and kill, t=6 distance and XP-2 pause, Quick Needle timing, t=8 distance and next kill, ready-shot behavior on an empty tick, each fixed spawn, contact damage, t=30 gate order and entry, loss at HP 0, and restart.
Return a table with columns: checkpoint, expected state, observed state supplied, match or mismatch, and earliest rule involved. If observed evidence is blank, leave that column blank and return a human checklist only. Identify the first divergence, suggest one narrow rule clarification or code change, and state what identical action sequence should be repeated after a reset. Do not add an enemy, weapon, upgrade, or feature until the original trace can be compared fairly.

This request distinguishes diagnosis from invention. A useful correction changes one rule, then reruns the same actions. If the observed state is missing, the honest deliverable is a checklist a tester can follow, not a claimed resolution.

A table like this is useful only when it points to a state the tester can observe. It is not evidence that a discrepancy exists; it is a way to locate one when a future run supplies enough detail.

Keep the handoff honest and review the result

A prompt package can be checked on paper before anyone asks a creator to build it. The rules say what must happen, the arena request says what should be visible, and the diagnostic prompt says how to compare a future observation. Keep the same sequence in all three so the handoff does not quietly change the design between planning and implementation.

SEELE’s 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 do not confirm Emberwake Circuit as a preset or prove that these rules have been generated. Before submitting, review the selected model, available Koin balance, and displayed generation cost in Workspace. If you carry the brief into a creator, compare the result with the trace and mark every unavailable check as unverified.

Start with the one-room loop, make the first divergence easy to spot, and expand only after the action order is clear. The example is fictional and untested; its purpose is to make the next design request specific enough for a real review.

FAQ

What should the first prompt for a survivors-like game specify?

Set the arena bounds, player controls, enemy spawn positions and speed, automatic target rule, shot interval, XP gate, upgrade effects, event order, and win or loss conditions. A small expected trace then gives a future tester something concrete to compare.

Why split the rules, build, and review prompts?

Each prompt has a different job. The first closes ambiguities in the contract, the second asks for one playable arena, and the third compares supplied evidence with expected states. This makes a future mismatch easier to locate than one request that changes rules, art, and features at once.

Has Emberwake Circuit been generated or tested?

No. Emberwake Circuit is an original fictional design, the three prompt templates are unexecuted, and the t=3, t=6, and t=8 trace is calculated by hand. The images are conceptual teaching scenes, not screenshots or proof of a verified playable result.

When should I add more enemies or upgrades?

Add another system after the first encounter can be reproduced and checked. If the t=3, t=6, and t=8 states disagree, fix the earliest rule first. New enemies or upgrades make the test harder to diagnose until that small loop is stable.