A readable horizontal shooter begins with a small promise: watch one attack, choose a lane, fire through an opening, dodge a changing hazard, and reach a clear endpoint. Keep the first wave to one interceptor, one hostile drone, and one timed gantry. The player should be able to tell what is dangerous, where the safe route is, and why the wave has ended.
The example below is a fictional design exercise. Its rules, wave sequence, and revision are proposed on paper. No game-generation prompt was run; Codex ImageGen prompts were used only to create concept illustrations. No playable build, combat test, or measured improvement is claimed.
- Define the player’s lane decision
- Build one short wave
- Write a focused prototype prompt
- Inspect readability and fairness
- Simulate one narrow revision
- Choose a next step
Define the decision before the enemy count
Start with three vertical bands: upper, middle, and lower. The interceptor travels from left to right, steers between bands, and fires forward. A hostile drone occupies a readable position ahead. Its coral shots form a short volley through one band, while the ship’s own pale-blue fire remains visually separate. The point is not to fill the screen. It is to give the player enough time to read one threat and make one useful choice.
In the proposed first wave, the drone begins in the middle band and pauses between volleys. The gantry gives a separate warning: coral lamps light before the physical barrier starts lowering across the middle route. The upper or lower lane remains open. The player can dodge the drone’s volley, use the brief pause to line up a shot, then move into an open band before the gantry closes. Keep enemy shots and obstacle warnings distinct by color, shape, and timing so one signal does not impersonate another.
| Player question | Signal to show | Useful response |
|---|---|---|
| Where will the drone fire? | A short, readable volley aimed along one band | Move to another band before the shots arrive |
| When will the gantry block the middle? | Coral warning lamps light before the barrier moves | Take the visibly open upper or lower route |
| Did the shot or collision matter? | Distinct hit feedback, then a same-wave restart on collision | Retry the same pattern with the lesson intact |
This is the information the first wave needs to teach. A second drone, a boss, weapon inventory, and a score economy would add decisions before the player can judge this one. Add those only after the attack, obstacle, and exit read cleanly on their own.
Build one short wave with a timed gantry
Write the wave as a sequence of visible states. Begin with a quiet entry: the ship starts in the middle band, the gantry is raised, the drone is visible, and no shots are in flight. The drone then signals its attack and sends a short volley through the middle. Give the player a brief pause after that volley, long enough to move and line up a forward shot. The gantry’s lamps light before it lowers; the warning must be readable even while the ship is firing. Once the middle lane closes, at least one alternate band stays passable.
Collision has a simple cost. If the player touches the lowered gantry, show an unmistakable hit state and restart the same wave from its entry. Do not randomize the drone, move the barrier, or change the lane layout on that restart. A stable retry lets the player understand the relation between the warning, the move, and the collision. The wave clears only after the drone is disabled and the interceptor reaches the lit exit beacon. Defeating the drone alone is not the endpoint, and reaching the beacon while the hostile remains active is not a clear.
| Wave beat | Visible change | Player decision or check |
|---|---|---|
| Entry | Raised gantry, quiet lane, drone ahead | Locate the target and the three travel bands |
| Volley | Drone tell, then a short coral attack | Leave the threatened band |
| Firing window | Shots stop briefly; the target stays visible | Align and fire without crossing a hostile projectile |
| Obstacle warning | Gantry lamps light before the middle barrier descends | Read the warning separately from weapon fire |
| Detour and clear | Alternate band remains open; exit beacon lights after the drone is cleared | Pass the obstacle and reach the beacon |
The outcome is a completed wave, not a victory claim for a whole game. A tight endpoint makes the first prototype easier to inspect: the player either sees the beacon after clearing the drone and barrier, or gets clear feedback about what stopped progress.
Write a focused prototype prompt
A useful game brief names the player, first action, visible signals, legal route, failure behavior, and completion state. It also tells the creator what to inspect. Controls below are design suggestions, not confirmed SEELE controls. Replace them with the mapping that suits the target before asking for a build.
Create a compact side-scrolling 2.5D shooter wave set in an orbital shipyard. The player pilots one small interceptor moving left to right through upper, middle, and lower lanes. Suggested input: one control steers vertically, one fires forward. Begin with one visible hostile drone ahead and a raised physical gantry across the middle lane.
The drone gives a readable tell, fires one short coral volley through a single lane, then pauses long enough for a deliberate response. Keep hostile projectiles visually distinct from the player's pale-blue fire. After the volley, light the gantry's coral warning lamps before lowering it across the middle lane. Keep either the upper or lower detour open and visible. Do not let firing effects hide the warning.
If the interceptor touches the lowered gantry, show a clear hit state and restart the same wave with the same drone, obstacle timing, and lane layout. Clear the wave only when the drone is disabled and the interceptor reaches a lit exit beacon beyond the gantry. End with an unmistakable beacon state.
Return a concise control summary, the wave-state sequence, and a playable first-pass result. Exclude extra enemies, boss phases, upgrades, rescue objectives, text-heavy overlays, and systems not needed for this wave. Review whether the drone tell can be seen, the warning precedes movement, an open route remains available, collision restarts consistently, and the exit requires both the cleared drone and the beacon.The prompt asks for a compact first pass and a review plan, not a guarantee. If the eventual output changes the attack pattern or route, update the brief to match what is actually visible before judging it. A generated idea still needs inspection for collision, timing, and clarity.
Inspect combat readability and fairness
Readability is a relationship between a signal and a response. The warning must arrive early enough to matter; the safe route must remain physically possible; feedback must identify what happened. Use one inspection pass for each relationship instead of adding more visual effects to make a weak signal louder.
| What looks wrong | Likely design cause | One adjustment to try |
|---|---|---|
| The player is hit before reacting | The tell is too short, hidden, or visually similar to damage | Separate its color or silhouette, then give the warning more lead time |
| The gantry seems to appear without warning | The lamps begin at the same instant as movement | Show the lamps first and hold the barrier in place during that warning beat |
| Every route appears blocked | The alternate band is obscured or the collision boundary is unclear | Expose one continuous detour and keep its edges visible |
| The player cannot tell why the wave stopped | Hit, restart, drone-clear, and exit cues overlap | Give collision a distinct hit state and reserve beacon lighting for the completed objective |
Change one variable at a time. If you lengthen the warning and also slow the drone, a clearer pass cannot tell you which change helped. Keep a short note of the current rule, the single proposed adjustment, and the visible check that would resolve the question. That is a design discipline, not evidence that any generated result has passed.
Simulated iteration: separate warning from damage
Here is a paper-only revision. In fictional v0, hostile drone shots and gantry warning lamps both use coral. A player could mistake the obstacle warning for another attack. This is a predicted ambiguity in a design description, not an observed usability problem.
The proposed v1 changes one color rule: keep hostile shots coral and shift the gantry warning lamps to amber. Friendly fire stays pale blue. Keep the lamp shape and timing, drone volley, player speed, obstacle movement, route, collision rule, and exit condition fixed. The question stays narrow: can a reader identify the warning and still see a safe lane before the barrier moves?
The acceptance list is still pending real observation. Check that warning lamps appear before movement, at least one lane remains open, a collision triggers a clear hit and same-wave restart, and the exit beacon lights only after the drone is disabled and the ship arrives. A hand-written prompt or attractive frame cannot answer whether timing feels fair in play.
Take the brief into a game-making workflow
Once the first wave has a defined player action and endpoint, a plain-English game brief can give a creation workflow a focused task. SEELE’s Free AI Game Maker page describes entering a game idea in plain English, reviewing a playable 2D or 3D result, and iterating in Workspace. The capability is general: it does not establish that a particular shooter, collision rule, attack pattern, or timing will be generated correctly.
Give the tool the player, one attack, the timed obstacle, the safe detour, and the completion state. Then inspect what the result actually does: can you see the drone tell, is the gantry warning distinct, does a route stay open, and does collision restart the same wave? Before submitting, check which AI model is selected, how much Koin balance is available, and the displayed generation cost. Keep any prompt change tied to a specific observed issue rather than asking for a broader “more exciting” pass.
Start with one readable wave
A horizontal shooter earns complexity one decision at a time. Begin with a visible volley, a distinct obstacle warning, one open lane, a consistent collision restart, and an exit the player must reach after clearing the threat. Add more pressure only when each signal still has a clear meaning. To turn that plan into a first brief, start with the Free AI game maker, review the actual result, and check the displayed cost before another generation. The example here remains a design proposal, not a tested output.
FAQ
How many enemy types belong in a first wave?
One is enough when the wave is also teaching a timed obstacle. A single drone lets you judge its tell, volley, firing pause, and relation to the gantry before adding another pattern. If the player cannot identify what caused a hit, adding enemies will make the first problem harder to diagnose.
How can a player dodge without stopping fire?
Separate movement from firing in the design contract, then test whether the player can keep aiming or firing while changing bands. The exact input mapping is a design choice, not a documented SEELE control. Preserve a short firing window and avoid filling that window with an unavoidable obstacle move.
What makes a bullet pattern readable?
Use a visible tell, a small number of distinct projectile paths, and enough separation between warning and impact for a response. Keep hostile shots visually distinct from the player's fire. A pattern is not readable merely because its colors are bright; its direction and threatened lane must be apparent.
Should the first build include a boss?
Not for this first-wave exercise. A boss brings extra phases, attacks, health rules, and victory conditions that compete with the lane-and-gantry lesson. Add one only after the drone volley, open route, collision restart, and exit state can be judged independently.
Can an AI game maker guarantee balanced combat?
No such guarantee is documented here. A plain-English brief can describe the intended loop and a playable result can be reviewed, but balance depends on what the game actually does and how it feels in use. Inspect the timing and collision behavior yourself, then revise the specific rule that needs work.
