A siege strategy game needs more than walls and a big weapon. Its core loop becomes interesting when the player must time damage against repair and decide when to commit troops. Start with one gate, one battery, one squad, a small number of shots, and a deadline. Then trace the battle order by hand before adding extra units or maps.
The Stonewake Gate example below is fictional and hand-resolved. Its values illustrate a design method; no prompt was run, no playable build was created, and no balance or player test is claimed.
Set one fortress, one breach, and one deadline
Give each position a job. The artillery approaches from x=0, the squad waits in a protected trench at x=1, the gate occupies x=2, and the courtyard is the destination at x=3. The player wins by reaching the courtyard by the end of round 3. This small lane is enough to test whether siege equipment and an assault actually depend on one another.
| Object | Starting state | Rule that matters | Player question |
|---|---|---|---|
| Stonewake Gate | Integrity 4; closed above 0 | Two battery hits open it | Can damage arrive faster than repairs? |
| Artillery battery | Two stone shots | One shot per round; each deals 2 | When should each shot land? |
| Infantry squad | x=1 in the trench | Moves at most one lane position per round | When is the route open? |
| Garrison | Repairs a closed gate | After player orders, restore 1 integrity | Can the player interrupt one repair? |
| Signal Flare | One use in v1 | Cancels the current round’s repair | Which repair phase is most valuable? |
Use a fixed phase order: the player fires and issues movement or support orders, then the garrison repairs if the gate is still closed. A troop move into a closed gate is blocked, and the squad stays where it is. If a shot opens the gate earlier in the player phase, the squad may move one tile onto the opening in that same phase. A gate at zero stays breached; it does not repair. These details remove ambiguity from a short rules test.
Keep other systems out of this first pass. No casualties, morale, extra gates, diplomacy, random hit chance, or siege supply economy is needed to answer the central question. Add one of those only after the breach timing works, because each new variable can hide whether artillery, repair, and infantry already form a useful loop.
Coordinate the battery with a precise battle order
Write the action order before writing lore. A round needs an explicit player phase, a defender phase, and a movement rule. In version 1, the player has two shots and a single Signal Flare. The flare can cancel one repair, so it is a timing resource rather than an extra source of damage. Holding the infantry in the trench until the breach opens protects the route from a blocked-move ambiguity.
The following is a copy-ready design prompt. It is an unrun template for a future prototype, not a prompt result.
Build a small single-lane siege strategy prototype from this fictional rules brief.
Map: artillery at x=0, a protected infantry trench at x=1, a stone gate at x=2, and the courtyard at x=3.
State: the gate starts at integrity 4 and is closed while integrity is greater than 0. The battery has exactly two shots and may fire once per round; each shot reduces gate integrity by 2, to a minimum of 0. The squad starts at x=1 and may move one lane position per round.
Round order: resolve the player's shot, movement, and support orders first. Then, if the gate is still closed, the garrison repairs 1 integrity. A gate at 0 stays breached. A move into a closed gate is blocked and leaves the squad at its current position.
Support: version 1 has one Signal Flare. If used before the defender phase, it cancels that round's repair and is consumed. It adds no damage.
Goal: move infantry to x=3 by the end of round 3. Show the current gate state, shots remaining, squad position, and whether the flare remains.
Review: include a restart to the initial state and make blocked movement, repair timing, and the round deadline observable. Do not add random combat, negotiation, extra troops, or unlisted repair bonuses. Treat this as a fictional design brief; do not present an unverified output as a tested game.Keep the interface cues tied to state: a closed or breached gate, the battery’s remaining ammunition, the squad’s tile, and whether the flare is available. Those are the pieces a reader needs to judge the next move. A large strategic map can wait; clarity about a single order sequence is more valuable than several untested systems.
This middle state explains the trade: the player has not made the gate stronger or added another shot. They have prevented one repair at the moment it would otherwise slow the assault. In a playable version, verify that using the flare consumes it once, that the garrison skips only that repair, and that later repairs still follow the normal rule.
Hand-check all three rounds before adding features
Trace state after each phase, not just at the end of the round. The ordering matters: in round 2, the second shot opens the gate before the squad moves. That lets infantry step from x=1 to x=2 in the same player phase. It still needs round 3 to reach the courtyard.
| Version 1 phase | Gate integrity | Battery | Infantry | Outcome |
|---|---|---|---|---|
| Start | 4, closed | 2 shots | x=1 | Three rounds remain |
| Round 1: fire, flare, hold; defender repair canceled | 4→2; stays 2 | 1 shot | x=1 | Gate is damaged, but route stays safe |
| Round 2: fire, move; defender cannot repair | 2→0, breached | 0 shots | x=1→2 | Opening is reached after the shot |
| Round 3: move into courtyard | 0, remains breached | 0 shots | x=2→3 | Win before the deadline |
The arithmetic is deliberately small enough to audit: each shot removes two from the starting four, and reaching zero opens the gate. The player uses one flare in round 1, so the defender does not restore the point that would otherwise leave the gate at three. The second shot then arrives against integrity two. Because the breach opens before movement, the squad gets the two steps it needs across rounds 2 and 3.
In the authored success state, the squad reaches x=2 after the round 2 shot, then enters the courtyard at x=3 in round 3. The battery has no third shot and does not need one. Keeping that fact visible prevents an illustration or prototype brief from implying a larger ammunition supply than the rules provide.
Compare a no-flare version with one focused change
To see whether the support order affects the core loop, make a paper-only version 0 with the same map, battery, damage, movement, repair timing, and deadline. Remove only the Signal Flare. Do not quietly grant another shot or weaken the garrison. The comparison then isolates one question: can the battery outpace the repair without an interruption?
| Version 0 phase | Gate integrity | Battery | Infantry | Why the route fails |
|---|---|---|---|---|
| Start | 4, closed | 2 shots | x=1 | Same initial state as version 1 |
| Round 1: fire; defender repairs +1 | 4→2→3 | 1 shot | x=1 | Net progress is only one point |
| Round 2: fire; defender repairs +1 | 3→1→2 | 0 shots | x=1 | Gate remains closed; no third shot exists |
| Round 3: move into closed gate, then repair +1 | 2→3, still closed | 0 shots | Move blocked at x=1 | Deadline check fails; the extra integrity cannot open the route |
This is a rules trace, not an observed balance result. Version 0 makes the failure legible: two shots cannot beat the end-of-round repair, and a blocked troop order cannot rescue the plan. Version 1 changes one support rule and creates a reachable path. That suggests a prototype question to test later, but it does not show that players prefer the flare or that its timing is balanced.
Write edge cases as checks, not hidden exceptions
Before expanding the design, list the events that could otherwise produce inconsistent outcomes. State the expected result next to each case so a future prototype has a clear acceptance target. A test should check the written order; it should not be treated as evidence until someone actually runs it.
| Case to inspect | Expected result under these rules | State that must stay unchanged |
|---|---|---|
| Battery fires when one shot remains | Gate loses 2 integrity; ammunition becomes 0 | No hidden third shot appears |
| Shot reduces gate from 1 to 0 | Gate opens before the movement order in that player phase | Damage never goes below 0 |
| Squad moves while gate remains closed | Move is blocked and the squad stays on its current tile | No position advance or free breach |
| Flare is used before repair | That round’s repair is canceled and the flare is consumed | Later repair phases still occur normally |
| Flare is already spent | It cannot cancel a second repair | Shot damage and troop location do not change |
| Round 3 ends with gate closed | Siege attempt fails at the deadline | No extra round begins automatically |
| Restart after either ending | Restore integrity 4, two shots, squad x=1, flare ready, round 1 | No result state carries into the next attempt |
These checks are more useful than adding another siege engine before the first one works. If a later build fails a case, compare its state transition with the expected result and revise the narrowest unclear rule. Keep any later change visible in a new version so the first trace remains reproducible from its written assumptions.
Hand the rules into a general game-creation workflow
The current official Free AI Game Maker page describes plain-English game input, a playable 2D or 3D first version, browser testing, and refinement with follow-up prompts. It advertises free Koins and says to review displayed cost before each generation; its cost FAQ says to check the selected model, Koin balance, and displayed cost in Workspace. These are general workflow facts. They do not establish siege-specific generation or show that these authored rules have been implemented.
For a first creation pass, give the tool the map, player action, gate state, phase order, repair rule, two-shot limit, one-use support order, win condition, and restart state. Then inspect the returned result against the table: does the second shot open the gate before movement, does the garrison repair at the end of the right phase, and does the squad stop at a closed gate? Review the displayed generation cost before each request. A clear brief helps focus inspection; it cannot substitute for checking the actual behavior.
Start with one breach window
A first siege prototype is easier to understand when its pressure comes from a small number of connected rules. Here, the battery spends limited shots, the garrison restores a closed gate, one signal can cancel a repair, and infantry needs two moves after the breach. Hand-checking the same deadline with and without that one support order shows exactly what changed. Keep the scenario fictional until it is built and tested; then add new systems one at a time.
When you are ready to shape a general playable-game starting point from your own rules brief, Free AI game maker.
Siege strategy game FAQ
What makes a siege game loop work?
Connect an attack, a defender response, and an assault decision so each phase changes the next one. Stonewake Gate uses limited artillery shots, a repair phase, and infantry movement toward a deadline. The values are fictional, but the loop is concrete enough to hand-check. A larger prototype can add resources or defenses after this sequence is clear.
How many artillery shots does the example allow?
The battery has exactly two shots and may fire once per round. Each shot removes two gate integrity, stopping at zero. In the version 1 trace, the first shot takes the gate from four to two; the second opens it. No third shot exists or is needed for the courtyard win.
What does the Signal Flare do?
It is a one-use support order in the fictional version 1 rules. If the player uses it before the defender phase, the garrison skips that round’s one-point repair. The flare adds no damage and cannot be reused. Its purpose is to let the second battery shot meet the gate at integrity two.
Is Stonewake Gate a tested playable game?
No. Stonewake Gate is an original teaching scenario and the version 0/version 1 comparison is resolved on paper from the stated rules. No prompt output, software build, playtest, measured balance result, or player preference is claimed. A future implementation would need to be inspected and tested against the acceptance cases.
Does SEELE generate siege strategy games?
The current page supports general plain-English input, a playable 2D/3D first version, browser testing, follow-up prompts, free Koins, and displayed-cost review. It does not promise siege-specific output or verify this example. Check the returned rules, movement, repair order, and displayed cost yourself.
