Build a Ricochet Shooter Around One Bank Shot

Make One Bank Shot the Core Decision

A ricochet shooter becomes readable when the player can predict one bounce before firing. Start with a fixed target, one reflective wall, and one blocker that makes a direct shot impossible. Let the player inspect the lane, choose an angle, see a one-bounce preview, fire once, and then compare the landing point with a clear hit radius. That small loop gives the mechanic a purpose: the player is solving a spatial shot, not merely waiting for an authored projectile animation.

For the first room, keep gravity, moving targets, random spread, enemy behavior, and extra bounces out of the rules. The example below uses an invented room called Glassline Bank Shot. Its coordinates, collision rules, target radius, and outcomes are a fictional paper model. They are not a built game, a prompt result, a measured test, a player observation, or a claim about a SEELE-generated project.

The goal is a dependable design brief: define the room, mirror the target across the wall to calculate a bank shot, and write down what a future prototype must verify. This article is a one-room fixed-target tutorial. It excludes competing enemies and a prompt-library-to-playable-build deliverable; the Glassline example is independent paper-only work.

Define the Room Before You Add Combat

Use a top-down room with coordinates so every collision is easy to inspect. Put the launcher at S=(0,0), the stationary target center at T=(8,1), a rectangular blocker across the direct lane, and a horizontal mirror wall above them. Define the wall as a deliberately authored game rule: it preserves horizontal direction and reverses vertical direction exactly once. This is a simple arcade convention, not a statement about real-world ballistics or a general physics engine.

With those values, a straight shot from S to T crosses the blocker. At x=3, its direct-line height is only 3/8 unit, inside the blocker’s y=0…2 band. So the player cannot solve the room by aiming straight at the target. The target and wall remain stationary, and the first room has no enemy AI or opponent-versus-opponent behavior. That keeps the decision about angle, reflected path, and feedback.

Specify what happens at every stopping point. If the projectile contacts the blocker, leaves the finite wall segment, or reaches a second reflective surface, the shot ends as a miss. If it lands inside the target radius, flash the target and increment one hit marker. On a miss, mark the stopping point and allow a complete reset. Never leave it unclear whether the game is waiting for a second bounce, whether the target moved, or whether the preview and fired shot used different angles.

Write a Prompt with Testable Inputs and Feedback

A useful game prompt names the player action, world geometry, collision behavior, visible preview, success test, and reset. The input should tell a builder what must stay fixed as well as what the player can change. Here is a single-room specification prompt for this paper model. It is one tutorial artifact, not a prompt sequence or an already playable result.

Create a small top-down 2D arcade ricochet-shooter room called Glassline Bank Shot. Use a fixed launcher at S=(0,0), a stationary target centered at T=(8,1), an opaque rectangular blocker covering x=3 to 5 and y=0 to 2, and one horizontal reflective wall segment at y=4 from x=0 to 8. The player may rotate aim counterclockwise from +x before firing one shot. The projectile has no gravity and follows a fixed straight path. It may reflect once: at the wall, preserve horizontal direction and reverse vertical direction. A blocker hit, wall contact outside the segment, or a second bounce ends the shot as a miss. Show a thin preview of the exact path and bounce point before firing. The shot hits only if its path enters a 0.25-unit radius around the target center. On success, flash the target and add one hit marker; on a miss, show the collision or stopping point. Reset every room object, aim and charge to the same starting state. Keep the room compact; add no enemies, moving targets, gravity, random spread, ammunition economy or extra bounce surfaces. Acceptance checks: direct fire is blocked, a 45-degree bank shot misses, a 41.19-degree shot reflects once and reaches the target, the preview matches the fired path, and reset restores the initial room.

Before accepting a generated version, inspect more than its theme. Check whether aiming rotates in the stated direction, whether the trajectory preview uses the same coordinates as the shot, whether the reflection happens at one valid wall contact, and whether the blocker stops a collision. Then verify the hit-radius comparison, miss feedback, and reset. If the preview curves or the shot makes a second bounce, the implementation does not match this room contract even if the scene looks like a shooter.

Trace the Shot Before Firing

Measure the baseline rather than guessing. A 45-degree aim has slope 1, so it rises from (0,0) to y=4 at x=4. That contact is inside the wall segment. Under the authored reflection rule, the path then travels down-right with the same horizontal rate and reaches x=8 at y=0. The target is centered at (8,1), so this shot misses the center by 1 unit. That is outside the 0.25-unit hit radius.

The route clears the blocker: between x=3 and x=5 the path is above y=2, both before and after its wall contact. The direct line to T is blocked, but this 45-degree shot goes over the rectangle and misses below the target. That creates useful feedback: the angle is wrong even though the wall reflection and obstacle clearance are valid. A miss can teach the player which relationship to change rather than simply punishing a failed shot.

Paper-Check One Angle Change

Change only the aim angle. To calculate a bank shot without trial-and-error, reflect the target across the wall y=4. The image target (8,1) becomes a mirrored target T′=(8,7). A straight line from S=(0,0) to T′ has slope 7/8, corresponding to arctan(7/8), about 41.19 degrees counterclockwise from +x. It meets the wall at y=4 when x=32/7, approximately 4.571. That contact lies within the wall’s x=0…8 segment.

After reflection, the authored rule reverses the vertical component while keeping the horizontal component. The path therefore descends toward the real target T=(8,1). It passes above the blocker: at x=3 before the wall it is at y=21/8, or 2.625; at x=5 after the bounce it is at y=29/8, or 3.625. Both heights exceed the blocker top at y=2. The line reaches the target center, making the paper-model result a hit under the 0.25 tolerance.

Keep the game rule deterministic. The wall can reverse only vertical direction because it is horizontal; horizontal direction remains positive. If the hit is judged by distance from the target center, write whether it uses the full two-dimensional distance rather than only comparing x or y. For this example the corrected path reaches the center exactly, so it satisfies either centerline interpretation, but a future non-perfect shot should be checked against the explicitly chosen circular radius.

Read this as a predicted trajectory before firing. It represents the written room rule, not a recorded game screen or an observed shot.

This is a single-variable paper design rehearsal: only the aim changes from 45 degrees to arctan(7/8). The target, wall, blocker, collision rule, and hit radius stay fixed. It does not show that a player understood the preview, that a built game fired correctly, or that any AI system generated the result. A real iteration would require a playable build, an observed shot, the recorded angle, and a check that the outcome matches the written contract.

Use the image as a target state for the design, not as proof of a running game. When testing a real prototype, compare the actual preview and shot with the same table: wall contact inside the segment, no blocker collision, one reflection, and target-center distance within 0.25. If any of those fail, record the first divergence and change one rule or parameter at a time.

Diagnose Misses by Their First Divergence

When the room is implemented, a useful miss report identifies where the observed path first diverged from the contract. Avoid changing the mirror rule, hit radius, and target position together; then you will not know which change fixed the shot. Start with a reproducible reset, fire the same angle, and compare preview and output at the first collision or wall contact.

This checklist is a proposed validation plan, not a report of tests already performed. Leave actual observations empty until a build is available. If a build later uses a different coordinate origin or wall normal, update the specification first, recompute the example, and then compare the preview with the changed rule.

Use an AI Game Maker for the Brief, Then Verify the Build

SEELE’s current Free AI Game Maker page describes a broad workflow: write a game idea in plain English, generate a playable 2D or 3D first version, test it in a browser, and refine it with follow-up prompts. It says Workspace shows the selected AI model, available Koin balance, and displayed generation cost before submission. Those statements support using the product as a place to explore a concise game brief; they do not establish that this exact ricochet mechanic will be generated or behave as specified.

Give the tool a bounded first room and ask it to make the launcher, aim direction, obstacle, wall, target, hit feedback, and reset visible. Then inspect the result against the same acceptance list. If the first output bends the path, lets it pass through the blocker, or hides the target tolerance, request a focused correction and inspect the next build. Generated code and gameplay still need human review and testing before you describe the result as working.

The article’s Glassline numbers are an original paper model, not an online game or product case. A future playable example would need a real accessible build and evidence tied to it. Keep this tutorial’s value in the readable one-bounce calculation and the testable room contract, rather than implying that an unverified tool output has already solved the mechanic.

Continue with a Focused Playable Brief

A one-bounce room gives you a practical first scope: a fixed target, one wall, one blocker, one adjustable angle, and a visible hit-or-miss result. The reflected-target method turns the aim into a calculation; the acceptance checks turn it into a build task. Keep the example labeled as paper-only until you have observed the mechanic in a real playable result.

When you are ready to explore a first version, start with a plain-English brief and review the playable output against the geometry, collision, tolerance, preview, and reset rules above. Check the selected AI model, available Koin balance, and displayed generation cost in Workspace before submitting. The Free AI game maker can help you explore your own focused game idea.

Frequently Asked Questions

Is this wall rule meant to model real ballistics?

No. It is an authored arcade rule for a fictional game: one horizontal wall preserves horizontal direction and reverses vertical direction. Real projectiles and materials involve more factors, and this article makes no claim about firearms or measured physical behavior. The simplified rule exists so a player can predict a bank shot and so a developer can test a clear route contract.

Why mirror the target across the wall?

Mirroring replaces a two-segment reflected path with one straight line to a virtual target. For this room, reflecting (8,1) across y=4 gives (8,7), so the slope from (0,0) is 7/8. The wall contact then follows from that slope. This is a planning calculation; a game still needs to implement and verify its own stated reflection rule.

Does the paper angle revision count as a playtest?

No. It checks that the written geometry is internally consistent: the revised line touches the wall segment, clears the blocker, and reaches the target center. It does not show that an implemented preview matches the shot or that a person can understand the puzzle. Call it a paper-only design rehearsal and leave empirical findings blank until you test a playable build.

Why limit the first room to one bounce?

One bounce isolates the decision the player needs to learn: where the shot meets a wall and where it travels afterward. A second bounce adds another surface, another collision order, and another opportunity for the preview to disagree with the projectile. Add that complexity only after one wall, one blocker, the hit radius, and reset are clear in a tested build.

What should I verify before adding enemies?

First verify angle direction, wall bounds, blocker collision, one-bounce enforcement, preview-to-shot agreement, hit tolerance, miss feedback, and full reset. Then ask a new player to predict the path before firing and observe where the prediction differs. This tutorial intentionally keeps the target stationary and excludes competing enemies; add enemy behavior as a separate design decision after the bank-shot loop is dependable.