Plan a Boss-Rush Prototype with a Clear AI Prompt Sequence

Start with the rule contract, not a boss list

A boss-rush prompt becomes easier to build and inspect when each attack has a cue, a legal response, a miss result, and a clear opening. Write those rules for one encounter first. Then ask for a focused first pass, check its states, and only afterward describe the later bosses and run-wide resources.

The Bellvault Trials below are an original teaching design for that workflow. They use one runner, three bosses, and discrete combat beats. This is a hand-resolved example, not a prompt execution, generated game, play session, or balance test. Treat every value as a proposed rule to adapt.

Before describing lore or effects, fill in the same six fields for a single boss phase:

This small contract prevents a prompt from hiding a missing rule behind phrases such as “challenging,” “fair,” or “responsive.” A maker can still interpret details differently, so the contract should name visible feedback and a way to check each transition.

Map every cue to one defensive action

Give each phase one intended defense, then define the resource alternative separately. In this design, a correct defense prevents damage and creates an Opening. Spending one Focus during Tell can substitute for the matching defense, but it does not add a second strike or change the later boss rules.

All three bosses begin at 2 health. A successful Strike during Opening removes exactly 1 health and consumes that opening. At 1 health, show the boss’s Phase B tell. At 0, defeat the boss and clear its cue. An illegal action, such as Strike during Tell, changes no health, Focus, phase, or outcome.

For example, the Tide Cantor’s Phase A cue is already visible when the runner correctly parries the bolt. The deflection is feedback that Parry worked; the staggered boss marks the single safe action that follows. The runner has not struck yet, so the Cantor still has 2 health.

Keep this rule sequence visible in the prompt: Tell → matching defense or one Focus → Opening → one Strike → next phase or encounter end. If the screen shows several cues or grants an extra strike, it no longer matches this teaching contract.

Ask for one bounded first encounter

Do not begin by asking for all three bosses, an upgrade tree, or additional weapons. First request the Ash Regent alone. State the player actions, exact health values, input timing model, and response to illegal or incorrect actions. Ask for a state display that lets you inspect the rules, not just a dramatic fight.

This first prompt is a reusable design template. It has not been run in SEELE or another maker.

Make a small single-player 3D boss-rush prototype for one encounter only. Combat advances in discrete beats; do not use real-time reaction timers or add hitbox rules that are not stated here.

Player actions: Evade, Guard, Parry, Strike, and spend 1 Focus during Tell as an alternative to the matching defense. Start with 3 hearts and 1 Focus; Focus is capped at 2 and cannot go below 0. The boss starts with 2 health and Phase A.

Each boss has Tell and Opening states. During Tell, show one named cue and accept one response. For the Ash Regent, Phase A is a raised overhead hammer and Evade is correct; Phase B is flaring floor vents before an ember burst and Guard is correct. A wrong defense removes exactly 1 heart and repeats the same cue. If hearts reach 0, enter Defeat. Spending 1 Focus during Tell cancels that attack and creates Opening.

A correct defense also prevents damage and creates Opening. In Opening, the boss does not attack and the player may Strike once. Strike deals exactly 1 boss damage and consumes the Opening. At 1 health, show Phase B. At 0 health, defeat the boss, clear the cue, and show Victory. Strike during Tell and other illegal actions change no state.

Show the current boss health, player hearts, Focus, named phase cue, and Tell/Opening state using readable feedback. Provide Restart; restarting resets the encounter to 2 boss health, 3 hearts, and 1 Focus. Keep the arena compact and walkable. Do not add attacks, extra health, extra resources, or a second boss.

Return the control mapping and a state-transition checklist before adding visual detail. Identify any requested behavior that cannot be represented as written instead of silently changing it.

Before expanding, compare the returned controls and state sequence with the contract: does the tell appear before a response is accepted, does a miss repeat the cue and cost one heart, and does each successful Strike remove exactly one boss health? If the result cannot expose these states, revise the prompt or the inspection plan before adding encounters.

Extend the chain only after the first loop reads

Adding bosses introduces a second kind of state: the values that reset and the values that persist. In the Bellvault design, every fight starts with 3 hearts; Focus carries between fights. Beating Boss 1 or Boss 2 grants one Focus, up to a cap of 2, exactly once. Boss 3 ends the run without another reward.

After a first encounter has actually been inspected, a separate extension prompt can add Tide Cantor and Prism Warden. If no build exists yet, this remains a plan; do not report an inspection or carry a fictional state into a product claim.

Extend the inspected one-boss encounter by adding Tide Cantor and Prism Warden from this exact table. Keep the existing action names, Tell/Opening sequence, damage rules, and restart behavior unchanged.

Tide Cantor: Phase A—three chimes align before one bright bolt; Parry. Phase B—water blade draws back for a broad lateral sweep; Evade.
Prism Warden: Phase A—prism lens gathers light into a sustained beam; Guard. Phase B—the beam visibly reflects from a second lens toward the player; Parry.

Each boss has 2 health and two phases. A wrong defense costs 1 heart and repeats the same cue. A correct defense or a 1-Focus spend during Tell creates one Opening; one Strike there deals 1 damage and consumes it. A new boss starts at 3 hearts and carries current Focus. Defeating Boss 1 and Boss 2 grants 1 Focus once each, capped at 2. Boss 3 grants none and ends the run in Victory. Clear stale cues and openings at every handoff.

Return a transition table for boss defeat, handoff, restart, and final victory. Do not add bosses, attacks, rewards, or resource resets. Flag any rule conflict before changing it.

The sequence has four predictable stages: focus to start, two phases to resolve, reward once, then reset hearts and clear the old cue. That is what the handoff checklist should verify; merely seeing a different boss model is not enough.

Check state changes with fixed action sequences

Test rule correctness separately from whether the fight feels fair. First use short, repeatable action sequences with expected values. The following cases are planned checks for a future build; they are not observed results.

A hand-resolved sequence shows how a run-wide state can be checked. Boss 1 starts at 3 hearts and 1 Focus. Evade and Strike, then Guard and Strike: the Regent falls, Focus becomes 2, and Boss 2 begins at 3 hearts. Spend one Focus to open Tide Cantor A, Strike, then Evade and Strike on B; Focus returns to 2 after the once-only reward. At Prism Warden, take one wrong action, then Guard/Strike and Parry/Strike. The proposed final state is Victory with 2 hearts and 2 Focus. This arithmetic follows the fictional rules only.

When checking a real build, record the starting state, exact actions, visible response, and resulting values. If a result differs, first identify which transition failed; do not adjust several boss rules at once.

Revise one unclear behavior at a time

A failed check tells you what to investigate, not automatically why it happened. Separate a rule mismatch from a cue that is hard to read, a control that is not understood, or a camera that hides the tell. Record what the player saw, chose, and expected before changing the prompt.

For example, if a future player reports mistaking the reflected-beam cue for a Guard cue, a designer could revise only the cue silhouette and rerun the same sequence. That is a hypothetical response to a hypothetical observation, not evidence that the current design has confused a player or that a change improved comprehension.

Keep a small record with build version, starting values, action sequence, expected transition, observed transition, and one proposed change. If no actual build or observation exists, label the row “planned check” and leave the observed-result field blank.

Use a boss arena maker for the first focused pass

SEELE’s current Boss Arena page recommends beginning with one arena, one boss, and a readable attack loop. It describes specifying the player’s moves, the boss’s pattern, and how the fight ends, then reviewing timing, camera, feedback, and controls before expanding scope. That makes it a relevant starting point for the Ash Regent prompt, not evidence that the Bellvault chain or its Focus handoffs will work as written.

Bring the encounter contract, the intended control mapping, and one acceptance question. If a focused first pass is available, inspect the cue, response, opening, damage, and end state in the actual result. The broader game-maker flow also advises reviewing the result and displayed generation cost. That supports a prompt-led first encounter, but it does not document this specific combat logic or a multi-boss save system.

Keep your goal small: find out whether one cue and one response form a readable encounter. Only add the next boss after the first loop has been inspected and the remaining run rules are explicit.

Choose one boss and one check for the next pass

A useful boss-rush prompt starts with a state contract, not a roster. Specify the cue, response, miss result, opening, damage, transition, and reset; request one encounter; then check the values before extending the run. The Bellvault sequence is a fictional paper design, so its prompt blocks and final state are starting materials for a real prototype, not a claim that one exists.

For your first build, select one boss phase and ask a narrow question: does the player see the tell before choosing the response? Start with the Boss maker, review the focused encounter and its displayed cost, and verify each state before requesting more bosses.

How many bosses should I include in a first prompt?

Start with one boss and one attack loop. That keeps the first check focused on whether a cue appears, the intended response works, and the encounter reaches a clear result. Add another boss only after the first loop can be inspected; a longer roster adds handoffs and resources that can make a basic rule defect harder to locate.

Should every boss attack use a different cue?

Use cues that let the player tell which response is expected, but do not vary them only for novelty. In the Bellvault example, each phase has one named cue and one matching defense. The cue descriptions are author-designed, not a tested readability standard; check whether a real player can identify both the cue and the intended action.

How should a resource carry between fights?

Write down whether it resets, persists, is granted once, and has a cap. The Bellvault example carries Focus, starts at one, caps at two, and grants one charge after Boss 1 and Boss 2 only. Those are teaching values, not a recommended balance. Verify the handoff after each boss and test that a reward cannot trigger twice.

Can an AI game maker guarantee the full multi-boss chain?

No prompt should be treated as proof that a specific chain has been generated or tested. SEELE’s Boss Arena page describes a focused one-boss starting scope. Use the proposed multi-boss rules as a plan, then inspect actual cues, controls, resource handoffs, defeat, and victory in any generated result before relying on them.