Design a Side-Scrolling Brawler Around Readable Enemy Waves

Make Enemy Waves Readable Before Adding More Moves

To make a side-scrolling brawler with AI, start with a room where the player can read one attack, evade its lane, and recover before the next enemy checks a hit. A small crowd encounter is not fair just because it contains two foes; their tells, hit timing, spacing, and recovery windows must give the player a meaningful choice. This guide uses one Rusher and one Guard to show how to turn that idea into a precise first-room brief.

The room and its timing below are fictional design parameters, not a prompt result, game build, player test, or observed SEELE output. The comparison is a hand-calculated timing rehearsal because no real run or playable result was supplied. It can check whether the written schedule makes sense; it cannot prove that a build works or that players understand the cues.

Keep the first loop narrow: read the tell → dodge the lane → regain the action → punish recovery → clear the pack → open the next room. The main design decision is when the next foe enters relative to the player’s dodge cooldown. That makes this a crowd-timing tutorial, not a recoil system or a ricochet puzzle.

Lock the Two Enemy Roles and Action Order

Call the room Foundry Walk. It spans horizontal positions 0 through 12 and has a near lane and a far lane. The player begins at x=2 in the near lane; the exit gate stands at x=11. One command resolves at a timestamp before enemies run hit checks at that same timestamp. A lane step changes lanes in 0.25 seconds. A dodge moves one horizontal unit and switches lanes in 0.25 seconds, avoids a hit checked during that movement tick, and then has a 0.75-second cooldown. A light strike can hit the nearest foe within 1.5 units in the same lane; a foe in recovery can take one hit.

The Rusher’s near-lane path crosses the player’s starting x=2. At t=0.75, the player’s dodge command resolves before the dash hit check, moving the player from (2, near) to (3, far). The Rusher continues through the near lane. The dodge ends at t=1.0 and its cooldown ends at t=1.75. The Guard must be scheduled around that ready time, not simply inserted when the room looks empty.

A two-lane escape is useful against the Rusher, but it is not a universal safe state: the Guard’s authored rectangle covers both lanes. This distinction prevents a common readability bug. If the art shows a cross-lane sweep while the rules only hit the near lane, players cannot infer the actual danger. Keep the picture, tell, and collision footprint consistent.

Prompt a Small Encounter with Observable Feedback

A useful prompt names the arena, player controls, enemy state changes, action order, failure feedback, and reset. It also tells the builder what not to add yet. The prompt below is a design artifact for a hypothetical game. It has not been run; every mechanic is a request to inspect in any future playable result.

Create a compact side-view 2.5D brawler room called Foundry Walk. Use a 0–12 horizontal arena with near and far lanes. Start the player at x=2 in the near lane and place a closed exit gate at x=11. Give the player one light strike that reaches the nearest foe within 1.5 units in the same lane, a 0.25-second lane step, and a dodge that moves one horizontal unit and switches lanes in 0.25 seconds, avoids hit checks during that movement tick, then has a 0.75-second cooldown after the dodge ends. At each timestamp, resolve the player's command before enemy hit checks.

Spawn one Rusher at x=0 in the near lane. Show a clear 0.75-second near-lane tell, then dash it +3 units through that lane and check the hit after the player action. Give it recovery from t=1.0 to t=1.75; it can take one light strike while recovering. Spawn one Guard at x=2.5 in the near lane after delay d. Its 0.75-second tell previews a fixed x=1.5 to x=3.5 sweep footprint across both lanes. Check that footprint after the player action, then give the Guard 0.75 seconds of recovery and one-hit vulnerability. Use d=0.5 for the initial paper scenario; keep all other values fixed when comparing d=1.5.

Show distinct tell, dodge, hit, recovery, defeat, and gate-open feedback. Clear the gate only when both foes are defeated. Add a reset that restores player health, foe positions, spawn delay, and gate state. Do not add ranged weapons, bosses, progression trees, gore, random timing, or extra enemies. Make the collision boxes, timeline, cooldown, and reset easy to inspect. This is a fictional design brief, not evidence that the game has been generated or tested.

After any future generation, inspect the first room against that contract before adding features. Check that there is one Rusher and one Guard, that their tells precede their hit checks, and that the hit rectangles match the lanes shown. If the tool returns a playable prototype, treat it as a starting point: the game still needs to be tested rather than assumed correct from the prompt.

Trace Why the Half-Second Spawn Overlaps Dodge

Use a timeline instead of describing the wave as “too fast.” The baseline Guard delay is d=0.5 seconds, so its 0.75-second telegraph ends and its hit check occurs at t=1.25. The Rusher’s opening sequence has already forced the dodge at t=0.75. The dodge finishes at t=1.0, leaving the player unable to dodge again until t=1.75. The Guard’s check therefore arrives half a second before that next dodge is available.

The Guard’s rectangle includes both the near and far lane, so the Rusher dodge does not make the player safe from that sweep. At x=3 the player is also inside the rectangle’s horizontal span. The miss is not caused by an invisible tracking rule or an enemy that changes its mind; it follows from the fixed spawn schedule, cooldown, and footprint. This is a fictional trace for checking the rule set, not a recorded play session.

Paper-Check One Timing Change

Change only the Guard’s spawn delay from 0.5 to 1.5 seconds. Keep its x position, 0.75-second tell, fixed two-lane footprint, damage, player movement, Rusher path, and gate condition unchanged. The Guard’s check moves from t=1.25 to t=2.25. The dodge is ready at t=1.75. At t=2.25, the player uses it from x=3 to x=4 before the Guard check; x=4 lies beyond the Guard’s fixed x=1.5–3.5 range, so the hit is avoided.

This is a one-variable paper calculation. It does not establish that 1.5 seconds is fun, that a player can react comfortably, or that an implementation follows the intended order. It only shows that the revised schedule allows the defined dodge to leave the fixed hit rectangle at the defined check time. A later build should test both whether the cue is readable and whether the player’s available actions feel fair.

The full outcome is larger than this safe dodge. The Rusher and Guard must each enter a readable state, provide a punish window, and then transition to a clear defeat response. Only after both are defeated should the gate open. The comparison above isolates the Guard schedule so the reader can verify one decision without silently changing damage, geometry, or enemy behavior.

Diagnose the First Room Before Expanding It

If a future build fails the intended encounter, identify the first place where its visible state diverges from the rules. Avoid changing several timings at once: a revised spawn, shorter windup, larger dodge, and smaller hitbox would make it impossible to know which correction mattered. This table keeps each diagnosis tied to an observable check.

Record observed results separately from the paper schedule. For a real prototype, capture the build version, exact action inputs, visible cue, hit-check result, reset state, and any divergence. A prompt is not a substitute for those observations, and a generated frame cannot prove the timing worked.

Use an AI Game Maker as a Starting Workflow

SEELE’s current Free AI Game Maker page describes a general process: describe a game in plain English, generate a playable first 2D or 3D version, test it in a browser, and refine it with follow-up prompts. It says Workspace displays the selected AI model, available Koin balance, and generation cost before submission, and the page advises reviewing the cost before each generation. These broad workflow facts do not guarantee that a specific enemy schedule, collision footprint, or brawler room will be implemented correctly.

For this design, provide the arena, player actions, enemy tells, timestamp order, hit areas, clear condition, and reset as one focused brief. If a playable result is available, inspect each rule in a build and note what differs. In Workspace, confirm the selected AI model, available Koin balance, and displayed generation cost before submission. Keep the authored numbers in your acceptance checklist, not as a claim that the product has already delivered them.

That distinction makes the next step useful: a creator can use a broad prompt-to-playable workflow to explore the idea, while still validating the game-specific logic in its actual result.

Continue with One Readable Brawler Room

Keep the first encounter to one Rusher, one Guard, one dodge rule, and a gate that opens only after both foes are defeated. First decide whether each cue matches its hit area; then compare the next spawn time with the dodge-ready time. Add another enemy only after the player can understand and answer this wave. The exact timings here are paper design values, not a tested balance target.

When you are ready to turn the brief into a prototype, start with the Free AI game maker, check the current generation cost, and inspect the playable result against the room contract. Preserve the timing table, run a real build check, and revise one variable at a time.

Frequently Asked Questions

What is the first loop in a side-scrolling brawler?

Start with a readable tell, a lane dodge, a recovery window, and a clear pack-complete response. The player should know where an attack will travel and when an enemy can be punished. In this example, two foes are enough to teach spacing and timing before adding bosses, weapons, or progression.

Why does the 0.5-second Guard delay cause a hit?

After dodging at t=0.75, the player’s dodge ends at t=1.0 and cannot be used again until t=1.75. A Guard with d=0.5 completes its 0.75-second tell at t=1.25, while the player is still in the fixed x=1.5–3.5 hit range across both lanes. The result is a fictional paper trace.

Does the 1.5-second revision count as a playtest?

No. It is a hand calculation showing that the defined dodge is ready at the Guard’s revised t=2.25 check and can move the player to x=4 before that check. It does not show a generated build, a human reaction, or whether the encounter feels fair. Those require a playable result and observed testing.

What should I inspect in a playable brawler prototype?

Compare each telegraph with the actual hit footprint, confirm that the player action resolves before the same-timestamp check, time the dodge cooldown, verify recovery vulnerability, and reset the entire encounter. Record the exact input and result. If a rule differs, isolate one change and check again rather than adjusting several timings together.

Can an AI game maker guarantee this enemy timing?

No specific timing result is guaranteed by the general product workflow described here. A plain-English brief can communicate the requested loop, and a playable 2D or 3D result can be reviewed and refined. The creator still needs to inspect its actual tells, collision areas, cooldowns, gate condition, and reset behavior.