To turn a twin-stick shooter idea into a buildable brief, separate the controls, combat rules, and future checks. Give the left stick the job of moving, the right stick the job of aiming, and define when a shot and enemy attack resolve. Then ask for one small arena, not an entire campaign.
The Kestrel Relay Deck below is an original fictional design, manually resolved from fixed rules. The prompts are templates only: none has been run, and no playable build or playtest is available. Treat the listed outcomes as expected states, not observed results.
Separate Left-Stick Movement from Right-Stick Aim
A twin-stick design becomes hard to evaluate when movement direction silently becomes firing direction. Make the input contract explicit: the left stick changes the pilot’s position; the right stick changes the aim vector. The pilot can move north while aiming east, or step north while aiming southeast. A shot should use the latest aim direction and the pilot’s position after movement resolves.
That distinction gives the first prototype a useful question: can a player dodge a telegraphed attack while keeping a target lined up? To make the question answerable on paper, use one enemy, one attack lane, one health pip, and a short damage window. Remove cover and extra systems for this example so geometry does not hide a control mistake.
The image shows a proposed gameplay state, not a screenshot of an existing game. Its purpose is to make one choice visible: movement leaves the lane while aim stays on the target. The Warden is still shielded, so no damage is possible yet.
Write the Control Contract Before the Build Prompt
Start with a compact arena called Kestrel Relay Deck. It is a clear 10-by-8-meter orbital service platform, viewed from above, with no obstacles or tile grid. Put one pilot at (2,4) with health 1/1 and eastward aim (1,0). Place one Relay Warden at (8,5) with core health 2 and a closed shield. Restart restores those values.
Resolve every one-second beat in the same order: sample left and right input independently; move the pilot by at most one meter and clamp to the arena boundary; update aim from the right stick, retaining the last non-neutral direction; if Fire is pressed, send at most one instantaneous bolt from the post-move position; then resolve the Warden’s phase. A bolt removes one core point only when the shield is open and its unobstructed ray crosses the core center. Otherwise it dissipates. There is no ammo counter, reload, spread, recoil, homing, or aim assist.
| Beat | Warden phase | Rule to preserve |
|---|---|---|
| 1 | Telegraph | Mark a horizontal sweep at y=4; it has not fired. |
| 2 | Sweep, then open | After player input and any shot, sweep y=4. A pilot there loses the only health pip. Then open the core for player beats 3 and 4. |
| 3 | Open window | A valid hit lowers core health from 2 to 1. The Warden does not attack. |
| 4 | Final open beat | A valid hit lowers core health from 1 to 0 and wins. If the Warden remains active after this player phase, the pilot loses. |
This order matters. If the sweep happened before player movement, Beat 2 would punish a dodge that the rules intend to allow. If a shot used the pre-move position, the final northward sidestep could aim from the wrong point. Naming the order turns those disagreements into simple checks.
Prompt 1: define the rules before asking for a build
This first template asks for a contract, not a generated game. It should return a state list, a transition table, and any ambiguity it cannot resolve.
Design a deterministic top-down twin-stick shooter encounter called Kestrel Relay Deck. Do not build or claim to test it. Use a clear 10-by-8-meter arena with no obstacles or tile grid. Start a pilot at (2,4), health 1/1, aim east (1,0); place one Relay Warden at (8,5), core HP 2, shield closed. Restart restores the exact start.
At each one-second beat, sample left-stick movement and right-stick aim independently. Clamp movement to one meter and to the arena bounds. Neutral aim keeps the last non-neutral direction. Resolve player position, then aim, then at most one Fire bolt from the post-move position, then the Warden phase. A bolt deals one core damage only while the shield is open and an unobstructed ray crosses the core center. There is no ammo, reload, spread, recoil, homing, or aim assist.
Beat 1 telegraphs a horizontal sweep at y=4. After player input on Beat 2, the sweep hits any pilot still at y=4; the pilot has only one health pip. Then the core opens for player beats 3 and 4. A hit on Beat 3 changes Warden HP 2 to 1; a hit on Beat 4 changes 1 to 0 and wins. An active Warden at the end of Beat 4 wins the encounter. No Warden attack occurs on beats 3 or 4.
Return (1) a state schema, (2) the exact phase order and legal actions, (3) a beat-by-beat transition table, (4) one safe trace using movement north on Beat 1, east on Beat 2, east plus fire on Beat 3, and north plus diagonal fire on Beat 4, (5) the loss trace for holding at (2,4) through Beat 2, and (6) a list of contradictions or assumptions. Keep expected states separate from any future observations.Ask for One Fixed Arena with Independent Sticks
Only after the contract is stable should the build request describe the scene. Repeat the constraints that determine behavior, then define what feedback lets a player read the result. Use the same one-pilot, one-Warden scope. Ask for a visible lane warning, a clear shield state, a distinct hit response, a compact health pip, and an immediate restart. Keep effects modest so a missed sweep and an open core are easy to tell apart.
A prompt should also name what to exclude. “Make a twin-stick shooter” leaves open whether the sticks are coupled, whether movement is normalized, when shots spawn, and whether an attack can happen before a dodge. A focused request prevents those gaps from being filled with an unreviewed weapon system or a second enemy.
Here, two separated cyan chevrons signal aim without depicting a shot. The faded warning sits behind the pilot, the Warden’s petals part, and the core is newly vulnerable. Those visual cues correspond to different state changes rather than decorating the frame.
Prompt 2: request a single playable encounter
Use this as a proposed build request when you are ready to implement the design. It is not a report that a generation was attempted.
Build one playable real-time 3D top-down twin-stick shooter prototype from this fixed contract. The original Kestrel Relay Deck is a plain 10-by-8-meter orbital service platform with open floor and no grid or obstacles. Include one cobalt-and-ivory pilot at (2,4), one stationary Relay Warden at (8,5), one health pip, one two-point Warden core, and a restart that restores the initial state.
Use the left stick only for movement, at most one meter per one-second beat; use the right stick only for aim. Resolve movement first, aim second, Fire third, and Warden phase last. The pilot may move and aim in different directions in one beat. Fire creates at most one instantaneous bolt from the post-move position. A closed shield deflects the bolt; an open shield loses one core point if the ray crosses the core center. Aim direction persists through neutral right-stick input. Do not add ammo, reloads, recoil, spread, homing, aim assist, cover, pickups, additional enemies, waves, upgrades, or extra weapons.
Show a red-amber horizontal warning at y=4 on Beat 1. After Beat 2 player input, sweep that lane and open the Warden core for exactly beats 3 and 4. A pilot left at y=4 loses its one health pip; a pilot who moves off the lane survives. Beat 3 and Beat 4 have no enemy attack. Defeating the Warden on Beat 4 ends the encounter immediately; an active Warden at the deadline means loss.
Make position, aim direction, warning lane, shield state, health, and core hits readable with restrained icon-only feedback. Include a retry control and a clear return to the exact start state. Keep the screen focused on this one encounter. Do not imply that a prompt has been run or that this design is already tested.Resolve the Arena Trace by Hand
Before trusting an implementation, work through the expected state one beat at a time. Movement resolves before Fire. The ray starts at the new position, not the previous one. There are no obstacles, so a horizontal shot from (4,5) reaches the Warden at (8,5); from (4,6), the diagonal vector (4,-1) points to the same core.
| State | Left input and position | Right aim and Fire | Expected result |
|---|---|---|---|
| Start | (2,4) | East; no Fire | Pilot 1/1; Warden 2 HP; shield closed |
| Beat 1 | North to (2,5) | East; no Fire | Warning appears at y=4; pilot has left the lane |
| Beat 2 | East to (3,5) | East; no Fire | Sweep crosses empty lane; health remains 1/1; shield opens for beats 3–4 |
| Beat 3 | East to (4,5) | East; Fire | Post-move ray reaches the core; Warden HP 2→1 |
| Beat 4 | North to (4,6) | (4,-1); Fire | Post-move diagonal ray hits; Warden HP 1→0; pilot 1/1; win |
The successful trace tests two jobs at once. First, the pilot leaves the sweep lane without changing the eastward aim. Second, the final movement points north while the shot takes a southeast line from the new position. A prototype that rotates aim with movement would fail this contract even if it eventually damaged the Warden.
The failing path is deliberately short: hold at (2,4) through Beats 1 and 2. The warning appears, then the Beat 2 sweep resolves after player input. The pilot is still on y=4, so health changes from 1 to 0 and the run ends before the core opens. Do not add a later shot or call this a tested failure; it is the result of applying the written rule by hand.
Validate a Future Build with Expected States
If a playable build becomes available, compare it with a blank observation sheet. Record inputs and actual values separately from the expected column. If one check differs, preserve the exact scene and input, note whether the action was accepted, and repeat only after identifying the rule or implementation that needs correction.
| Check | Expected state | What to record later |
|---|---|---|
| Independent controls | Move north, aim east; position changes while aim remains east | Input vectors, pre/post position, displayed aim |
| Post-move shot origin | Beat 3 bolt starts at (4,5), not (3,5) | Accepted movement, shot origin, target health |
| Closed shield | A Beat 1 shot dissipates and leaves Warden HP at 2 | Shield state, trigger event, damage and feedback |
| Sweep dodge | At y=5, the Beat 2 sweep misses; at y=4, it removes the only pip | Telegraph lane, player coordinate, phase order, health |
| Deadline and restart | Beat 4 hit wins immediately; an active Warden loses; restart restores start state | Beat, core HP, ending, reset position and values |
The final frame represents the expected paper-trace endpoint, not a recorded test. The Warden is disabled at core HP 0, the warning has ended, and the pilot keeps the single health pip.
Also check right-stick neutrality, movement boundaries, and a shot fired without changing aim. These are useful implementation tests, not facts established by the paper trace. If the build differs, change one rule or one request at a time; do not silently revise expected values to make a result appear correct.
Prompt 3: check an accessible future build
This template is conditional. Use it only when you can actually access a build, and fill the observation fields from that session. Leaving them blank is more accurate than inventing a result.
Validate the accessible Kestrel Relay Deck build against the expected state contract below. Do not infer a result from the design description. Run each check in the build, record the actual observation, and mark it pass, fail, or not run. If the build is unavailable, stop and state that no test was performed.
Expected checks:
1. Move north while aiming east. Expected: position changes to (2,5), aim stays east, no shot is emitted unless Fire is pressed.
2. Move east to (3,5) on Beat 2. Expected: the sweep crosses y=4 and misses; health stays 1/1; the Warden core opens for beats 3 and 4.
3. Move east to (4,5) and Fire on Beat 3. Expected: shot origin is the post-move position, the ray reaches the core, Warden HP changes 2 to 1.
4. Move north to (4,6), aim along (4,-1), and Fire on Beat 4. Expected: the ray reaches the core, Warden HP changes 1 to 0, the win is immediate, pilot health remains 1/1.
5. Hold at (2,4) through the Beat 2 sweep. Expected: health changes 1 to 0 and the run ends before the core opens.
6. Restart. Expected: pilot (2,4), health 1/1, east aim, Warden (8,5), core HP 2, shield closed, Beat 1.
For every step, fill in the actual input, actual position, aim, shot origin, shield, Warden HP, pilot HP, phase, ending, and evidence note. Keep these actual observations separate from the expected values. Do not claim a test if a step was not run.Take a Focused Shooter Brief to SEELE
SEELE’s official AI space shooter generator page offers broad space-shooter guidance: set a clear objective, start with one enemy pattern, leave room to dodge, show a warning, and review combat feedback. It is a relevant place to begin a space-shooter brief, but the page does not establish that the exact twin-stick controls above are supported or that this fictional encounter has been created.
Carry your short contract into a creation workflow, then inspect any result for stick separation, shot origin, warning timing, and restart behavior. The official AI Space Shooter Generator page recommends a clear objective, one enemy pattern, room to dodge, visible telegraphs, and readable movement or weapon feedback in a short encounter. The Free AI Game Maker page describes plain-English prompts, a playable first 2D or 3D version, browser testing, and follow-up refinement. Before submitting a generation request, review the selected model, available Koin balance, and displayed generation cost in Workspace. These are general product descriptions, not a promise that this exact twin-stick mechanic will work.
Twin-Stick Shooter Prompt FAQ
What does each stick control in a twin-stick shooter?
In this design, the left stick controls movement and the right stick controls aim. They are sampled independently, so the pilot can move north while aiming east. This is the explicit rule for the fictional Kestrel encounter, not a claim that every game or SEELE workflow uses the same controls.
Why should a build prompt specify shot origin?
Shot origin decides which position the projectile uses when movement and firing happen in the same beat. This example resolves movement first, so a shot begins at the post-move position. Naming that order prevents a prototype from quietly firing from the pilot’s old location. If aim and movement update together, recording both makes the contract easier to check.
Did these prompts produce a playable prototype?
No. They are copy-ready design templates, and no prompt was run for this article. Kestrel Relay Deck, its control rules, and both traces are fictional and manually resolved. There is no supplied playable build, play session, or measured result, so the expected table must not be presented as observed gameplay.
How can I test independent movement and aiming later?
When a build is accessible, move in one direction while aiming in another, then record the input, post-move position, displayed aim, and shot origin. Compare those actual observations with the expected states. If the build cannot be opened or the step was skipped, mark it not run rather than filling in a result. Keep a note of the build version and the exact input sequence.
Does SEELE’s space-shooter page promise twin-stick support?
The page gives general guidance about objectives, enemy patterns, room to dodge, telegraphs, and combat feedback. It does not confirm the exact two-stick input contract in this example. Treat the page as a relevant starting point, then check current product options and inspect any specific result yourself.
