A base-defense survival game becomes easier to plan when you reduce it to one shelter, one preparation window, and one night of pressure. Before you ask a game builder for a world, write down what the player can do, what each action costs, what the attackers change, and what counts as survival. Then give separate prompts to the rules, the playable interaction, and a repeatable validation case.
The worked example below is an original teaching simulation for a pine-forest refuge. Its numbers are assumptions calculated from the rules on this page. They are not from an actual game, a SEELE generation, or a playtest.
Start with one night, not a whole world
For a first base-defense prompt, define one shelter and one short loop: prepare, face a threat, read the consequence, and restart. The player should be able to connect a choice made before nightfall to a state they can inspect at dawn. If your brief begins with a map full of buildings, crafting trees, weather, and several enemy classes, it may be hard to tell which rule made the first attempt succeed or fail.
Keep the first slice narrow enough to reason about on paper. Name the starting state, the actions available before the attack, the cost and effect of each action, the enemy response, and the end condition. This gives you a target for a first build and a way to spot a broken transition without assuming that a generated result will follow every detail.
Write a rule contract the build can show
Use a fixed starting state so each action has a visible effect. In this hypothetical case, dusk begins with a gate at 2/4 strength, four timber, three survivor health, two attackers, and two preparation actions. The rules below are authored assumptions for the walkthrough, not a balance recommendation.
| Rule field | Teaching assumption | What the first build should make visible |
|---|---|---|
| Starting state | Gate 2/4; timber 4; health 3; two attackers; two actions | Gate strength, timber, health, phase, and remaining actions |
| Repair | Spend 1 timber and 1 action to restore 2 gate strength, capped at 4 | Gate 2→4 and timber 4→3 after one repair |
| Set a trap | Spend 2 timber and 1 action; remove the first attacker from this night's attack sequence | Timber falls by 2 and one attacker is skipped |
| Gather | Spend 1 action to gain 2 timber | Timber rises by 2; no gate repair happens automatically |
| Night attack | Each attacker still in the sequence deals 1 gate damage | One gate segment changes per resolved attack |
| Gate failure | If the gate reaches 0, an attacker reaches the shelter and removes 1 health; health at 0 ends the run | The breach and health loss happen only at the stated threshold |
Now compare two legal uses of the two actions. Repair first and the player has one action left with three timber. They can spend two timber to set the trap, or spend that action gathering two timber. There is no second action for doing both. That constraint makes the choice legible: immediate protection trades against a larger reserve.
| Hypothetical line | Preparation changes | Attacks resolved | State at dawn |
|---|---|---|---|
| Repair, then trap | Gate 2→4; timber 4→3→1 | The trap removes the first attacker; the other deals 1 gate damage | Gate 3/4; timber 1; health 3 |
| Gather, then repair | Timber 4→6→5; gate 2→4 | Both attackers deal 1 gate damage | Gate 2/4; timber 5; health 3 |
Both lines survive under these rules. The first ends with more gate strength; the second ends with more timber. That is a consequence of this small rule set, not evidence that one strategy is balanced or better. If you change an action cost, attacker damage, or the number of actions, recalculate both lines before comparing them.
Give each prompt one job
Split the request so a rule error does not get hidden by an attractive scene. These are reusable prompt templates, not prompts logged from a run. Replace the shelter details with your own, keep the rule contract fixed, and inspect the returned result before adding another system.
Prompt 1: ask for the rule model
Plan a one-night base-defense survival game using only this rule contract:
Start at dusk with gate strength 2/4, 4 timber, 3 survivor health,
2 approaching attackers, and 2 preparation actions.
Repair costs 1 timber and 1 action, restores 2 gate strength, and caps at 4.
A trap costs 2 timber and 1 action and removes the first attacker from
this night's attack sequence. Gathering costs 1 action and adds 2 timber.
Each attacker still in the sequence deals 1 gate damage. If the gate reaches
0, one attacker reaches the shelter and deals 1 health damage; health 0 ends
the run. Do not add actions, resources, enemies, or rules.
Return a state table for the start, each action, each attack, dawn, and failure.
Work through repair then trap, and gather then repair. Show every resource
and gate-strength change. Flag any transition the rules do not define.This first request asks for a contract and arithmetic, not a finished game. Check that repair stops at 4, that the trap removes exactly one attack, and that gathering changes timber without silently repairing the gate. If an output invents a third action or a different trap effect, correct the rules before asking for a scene.
Prompt 2: request one playable interaction
Build a small base-defense survival scene from the rule table below.
Show one stone-and-timber refuge, a gate, a reachable preparation area,
and one clear path for two attackers. Start at dusk with gate 2/4, timber 4,
health 3, and two preparation actions. The only preparation choices are:
repair (1 timber, 1 action, +2 gate strength up to 4), set a trap (2 timber,
1 action, skip the first attacker this night), or gather (1 action, +2 timber).
At night, each attacker still in sequence deals 1 gate damage. A breach at 0
gate strength costs 1 health; health 0 ends the run.
Make the current phase, gate, timber, health, action count, and enemy route
readable. Show immediate feedback after every choice. Keep restart available.
Do not add combat weapons, extra resources, extra actions, or extra enemy types.
Keep the first scene small enough to inspect each state change.The request is deliberately limited to one shelter and one enemy route. It asks for visible state and feedback but does not promise that a specific builder will implement every rule. When a first result is available, inspect the actual interactions and the resource display instead of treating the prompt as proof.
Prompt 3: check one fixed sequence
Validate the existing build against this exact paper case; do not change rules.
Start at dusk: gate 2/4, timber 4, health 3, two attackers, two actions.
Path A: repair, then set a trap. Expected: after repair gate 4/4 and timber 3;
after trap timber 1 and one attacker removed; the remaining attack leaves
gate 3/4 at dawn; health stays 3.
Path B: gather, then repair. Expected: timber 6 after gathering, then 5;
gate reaches 4/4 before night; two attacks leave gate 2/4 at dawn;
health stays 3.
For each path, report the state before and after every action and attack.
Identify the first mismatch only. Do not claim a path passed unless it was
actually played in this build. If you cannot observe a state, say so.| Prompt job | Expected output | Acceptance check |
|---|---|---|
| Rule model | State transitions and both worked lines | Every timber and gate change follows the written costs and caps |
| Playable interaction | A compact scene with phase, choices, routes, and feedback | Only the listed actions appear; each action updates the visible state |
| Validation pass | A state-by-state comparison against Path A or B | The first mismatch is named; an unobserved result is not called a pass |
Diagnose the first wrong state change
When a result differs from the rule contract, do not rewrite the whole request. Find the first state that diverged, then check the smallest rule that controls it. A later wrong dawn value may be a consequence of an earlier cost or attack error, so compare each action in order.
| Observed symptom | First field to inspect | Next check |
|---|---|---|
| Repair spends timber but the gate stays at 2/4 | Repair transition and feedback | Confirm that one action restores two segments, capped at 4 |
| The trap costs one or three timber | Trap cost and inventory update | Keep the trap cost at two and check the remaining timber is 1 after repair |
| Both attackers hit after setting the trap | Trap target and attack sequence | Check that the first attacker is removed before attacks resolve |
| Health falls while the gate is above 0 | Breach threshold | Apply health loss only after the gate reaches 0 and an attacker enters |
Replay the same starting state after changing one rule. Keep the other values fixed so the next comparison tells you whether the change repaired the intended transition. A conceptual outcome for Path A is shown below; the scene is not a recorded product run.
Move the rule contract into a first build
Once the written case is coherent, it can become a focused creation request. SEELE’s current Free AI Game Maker page describes entering a game idea in plain English, reviewing a playable 2D or 3D result, and iterating in Workspace. That supports a workflow for trying a defined concept; it does not establish that this hypothetical base-defense design has been generated or that its rules will work unchanged. Review the output, requested interactions, and displayed generation cost yourself.
Give the builder the player’s first decision, the small scene, the state to display, and the acceptance sequence. If the first result misses a rule, ask for one correction such as “after repair, increase the gate by two but never above four.” Then compare the same start state again. Keep the original contract beside the build so later visual or content requests do not blur the mechanics you are checking.
Choose the next slice from what you observe
Keep the first night if the player can explain why the gate changed and what the trap or gathering action did. Simplify it if you cannot trace a mismatch to one rule. Extend it only when the first loop is readable: a second enemy type, another preparation phase, or a larger refuge should each introduce a decision you can inspect. The two paper paths above are useful as written targets; your own build still needs to be observed before you claim either path works.
When your one-night brief is ready, take it into the Free AI game maker, inspect the result, and revise one state change at a time.
Frequently asked questions
What should a first base-defense prompt include?
Include the starting state, the player’s available actions, each action’s cost and effect, the enemy response, and the failure condition. Add one short sequence that shows how those rules combine. That gives you something concrete to inspect after a first build, while leaving art direction and extra systems for later iterations.
Do I need to build the whole base first?
No. Begin with one shelter, one gate, one preparation area, and a readable enemy path. A small playable space makes it easier to tell whether the player understands the choice and its consequence. Add rooms or resource systems when they create a decision the first loop cannot already answer.
When should I add a second enemy type?
Add one after you can follow the first enemy’s route and confirm how it changes the gate state. Give the new type one distinct behavior and one visible cue, then test that change in a short repeatable case. This helps you see whether the new threat adds a decision or merely increases pressure.
How can I separate a broken rule from poor balance?
First check whether the build follows the rule you wrote: costs, caps, action count, and attack order. If a transition is wrong, correct that before judging strategy. If the transition is right but one option still feels weak, compare the same starting state with one cost or effect changed. That is a design choice to assess, not a coding mismatch.
Has this example been playtested?
No. The pine refuge, its action costs, and both dawn outcomes are a fictional teaching simulation calculated from the stated rules. They are not a playable game, a SEELE result, or a measured balance test. Use the prompts to plan your own build, then report only the states you actually observe.
