Start with a Readable First Room
A spellcasting shooter gets interesting when the player must read a target lane, choose a spell recipe, and decide whether the cast is worth its cost. This tutorial turns that loop into a small first-room specification: inspect target spacing, pick Cinder or Cinder+Fork, check range and mana, cast, read the feedback, then adjust one value if the paper design stalls.
The example, Lattice Ward, is an original fictional design. Its rules and arithmetic below are hand-calculated to teach a planning method. No prompt was run, no playable build was observed, and no real test or SEELE-generated result is claimed. All three illustrations are fictional scenes: room layout, spell action, or target feedback. They do not encode an exact mana value; use the written rules and paper ledgers for the 2- and 3-mana counts.

Define the Spell Recipe and Mana Rules
Write the rule contract before adding enemies, movement upgrades, or a larger arena. Lattice Ward uses a caster at coordinate (0,0) facing along the positive x-axis. Three stationary, one-hit brass wards stand at x=4, x=5.5, and x=8. Each is within the authored 10-unit cast range. There is one action per cast and no passive mana recovery during the room.
| Choice | Cost | Authored effect | What to inspect |
|---|---|---|---|
| Cinder | 1 mana | Hits the selected nearest active ward within 10 units for one damage. | Does the chosen target flash and clear after its single hit? |
| Cinder + Fork | 2 mana | Hits the selected ward, then chains once to the next aligned active ward only if it is no more than 1.5 units farther away. Each hit deals one damage. | Does the chain reach the 1.5-unit neighbor and stop before the next ward? |
Three details keep the puzzle legible. First, “selected target” means the first impact; the chain does not choose a distant ward on its own. Second, the 1.5-unit rule measures the gap from the first ward to the next eligible active ward, not distance from the caster. Third, the fork travels only once. The first pair is separated by exactly 1.5 units, while the second-to-third gap is 2.5 units. Thus the close neighbor is eligible and the farther ward is outside this combo’s chain limit.
With one durability per ward, the player can tell whether an impact worked from a clear hit flash and a change to the ward’s active state. Show cast cost before firing, subtract mana once per cast, and keep the remaining mana visible. If a cast is unaffordable, state that it is unavailable and leave the room unchanged. A reset should restore the same three positions, one durability per ward, spell choices, and starting mana. These are proposed acceptance rules, not observed behavior.

Prompt a Small First Firing Range
A useful first request names the goal, constraints, expected feedback, and a way to check the result. Keep this prompt compact enough to inspect. The wording below is a design aid, not a prompt that has been run:
Make a compact third-person spellcasting shooter training room. Place the player at the near end of one straight lane with three stationary one-hit ward targets at 4, 5.5, and 8 units. Add Cinder: one selected active target within 10 units takes one damage for 1 mana. Add Cinder+Fork: for 2 mana, hit the selected target, then chain once to the next aligned active target only when the gap is at most 1.5 units. Start with 2 mana and no regeneration. Show spell choice, selected target, cast cost, remaining mana, chain path, and each target’s hit or cleared state with readable icon feedback. Include a reset that restores the starting room. First make the room playable with these rules and a way to inspect selection, cost, and results. Then check the 2-mana combo: the close pair should be hit and the far ward should remain active. Report any difference from these requested rules instead of silently changing them.
Before expanding the room, check each rule against a visible response. Can the player select each target? Does the caster’s 10-unit range cover all three? Does Fork chain at the 1.5-unit gap but stop at the 2.5-unit gap? Does the mana total fall by exactly the chosen cast cost? Does a ward clear after one hit? Does reset restore the same state? If one check fails in a real build, record the observed input and result, then revise only the rule that failed. The list describes future checks; it is not evidence that any build passed them.
Trace the Two-Mana Baseline
Now follow the authored example on paper. Start with all three wards active and 2 mana. Select the first ward at x=4, choose Cinder+Fork, and pay 2 mana once. The first impact hits the ward at x=4. Its next aligned neighbor at x=5.5 is 1.5 units away, so the single permitted chain hit reaches it. Both one-hit wards clear in this designed state. The node at x=8 is 2.5 units beyond the second node and remains active. Mana is now 0.
| Paper action | Cost | Mana after action | Authored ward state |
|---|---|---|---|
| Start | — | 2 | x=4, 5.5, and 8 active |
Cinder+Fork at x=4 | 2 | 0 | x=4 and 5.5 hit; x=8 active |
This trace exposes two separate checks. Cost answers whether the player can cast. Reach answers which targets that cast can affect. Increasing range would not fix the remaining 2.5-unit chain gap if the Fork rule is still capped at 1.5; lowering the cost would change resource balance without changing target reach. Keep those knobs separate when diagnosing a design.
Change One Budget Value
For a controlled paper comparison, hold geometry, costs, durability, range, chain limit, and cast order fixed. Change only starting mana from 2 to 3. The first Cinder+Fork still costs 2 and hits the close pair. One mana remains. A single Cinder costs 1 and reaches the final active ward at x=8, which is inside the 10-unit range. The total cost is 2 + 1 = 3; after the second cast, all three one-hit wards are clear in the authored model and mana is 0.
| Paper action | Cost | Mana after action | Authored ward state |
|---|---|---|---|
| Start with revised budget | — | 3 | All three wards active |
Cinder+Fork at x=4 | 2 | 1 | Close pair hit; far ward active |
Cinder at x=8 | 1 | 0 | All three wards hit and cleared |
The outcome image illustrates this paper-designed end state: the close pair carries fork feedback and the far ward has a separate single-cast trace. The mana count comes from the ledger, not the illustration. This is a visual explanation of the hand calculation, not a recorded game result. The tuning exercise is a deterministic fictional rehearsal, not a measured iteration or an empirical claim about an AI tool.

Why add one starting mana instead of weakening a spell? It changes a single variable while preserving the reader’s understanding of both recipes. If a real implementation later behaves differently, the builder can compare observed cost and target state with this exact specification. That comparison still must be performed on a real build before calling it tested.
Diagnose Combo and Resource Failures
When a spell chain feels unfair, name the failure before revising the numbers. A small diagnostic table prevents a reach problem from being “fixed” with a larger mana pool, or a feedback problem from being mistaken for a balance problem.
| Symptom in a future build | Possible rule cause | Check | One-variable design response |
|---|---|---|---|
| The cast button is unavailable at the start. | Starting mana is lower than the selected recipe’s cost. | Compare visible current mana with the displayed Cinder or Cinder+Fork cost. | Change only the starting budget or the recipe cost, then compare again. |
| The first ward is hit but its neighbor does not react. | The gap may exceed the 1.5-unit chain limit, or the nodes may not be aligned. | Measure the next active ward’s gap and confirm alignment. | Change the gap or the chain limit, not both in the same pass. |
| The chain jumps to a surprising target. | “Next” may be interpreted by screen order, distance, or active-state order. | Define “next aligned active target” and test the nearest eligible node first. | Make target ordering explicit while holding the chain cap fixed. |
| The player cannot tell whether the combo spent mana. | Cost feedback is hidden or delayed. | Check pre-cast cost, post-cast mana, and target feedback as separate signals. | Improve one feedback element without changing the spell’s math. |
These are plausible design questions, not reports of failures observed in Lattice Ward. A clean test record for a future implementation should name the starting state, selected target, recipe, expected mana after casting, expected target states, and the actual observed response. If evidence is missing, keep the example as a paper model and label the limitation.
Use an AI Game Maker as a First-Build Loop
Once the rule contract is short enough to inspect, you can give a plain-language game request to a game-making workflow, review its playable output, and refine the request. The official Free AI game maker page describes natural-language requests, review of playable 2D or 3D results, and iteration in Workspace. Its broad shooter category and creation workflow do not establish that this specific Cinder+Fork mechanic will be implemented correctly.
For a first build request, keep the three target coordinates, both spell costs, one-hop rule, cast range, and reset behavior in the brief. Then inspect selection, cost display, impact, chain target, and cleared state one by one. If the build does not match a rule, note the actual state and revise only that rule. The product workflow supports a general request-review-iterate loop; the verification of this fictional design remains the creator’s work. The candidate article route and its entry_source value are local package metadata only, not an accepted or published URL.
Conclusion: Keep the Combo Legible
A spellcasting shooter first room can teach a useful decision with three wards, two recipes, and a visible mana budget. Separate spell cost from target reach, check the chain distance, and trace the cast result before adding more systems. In Lattice Ward’s paper calculation, 2 mana clears only the close pair; changing only the starting budget to 3 allows the same combo plus one single cast to reach all three. The arithmetic is an original, hand-checked design example. No game, prompt, or test result is claimed.
What makes a spell combo easy to understand?
Show the chosen recipe, its cost, the selected first target, the chain limit, and each target’s hit or cleared feedback. The player should be able to tell which effect happened and why the next target was eligible. Keep an out-of-range target visibly separate from the chain so the rule can be read without guessing.
How much starting mana should a spellcasting shooter give the player?
Set the budget from the intended decision. In this fictional example, 2 mana pays for one Cinder+Fork cast and leaves the far ward active; 3 mana pays for that combo and one single Cinder. This is a paper calculation, not a tested balance recommendation. If you change mana, hold geometry, recipe costs, target durability, range, and cast order fixed so the comparison has one clear cause.
How far should a chain spell jump?
There is no universal distance. State the rule and test it against nearby and out-of-range examples. Lattice Ward uses a 1.5-unit one-hop limit, so the 1.5-unit pair is eligible and the 2.5-unit next gap is not. In a first room, show one gap inside the rule and one beyond it, then inspect both responses before adding another spell.
Is Lattice Ward a real game or measured AI output?
No. Lattice Ward, its rules, hand-calculated states, and concept illustrations are fictional planning material. No prompt was run, no playable build or player test was observed, and no SEELE output is claimed. The named targets, spell costs, resource trace, and visuals are authored examples; they do not show how a generator behaves.
Was the copyable room prompt tested?
No. It is a proposed input and checklist, not a recorded prompt run. If you build a version, record the exact prompt, build identity, starting state, action, expected result, and observed result before describing it as tested. Record the test date and device as well so another reviewer can reproduce the check.


