AI prompts for a space-colony game are easier to check when they start with one short survival-and-production loop. Define the resources, action costs, timing, and win condition first; then ask for a small playable scene and a way to compare its state with an expected trace. This article gives you three reusable, unexecuted prompt templates and a hand-resolved fictional example called Kestrel Relay Shift. The numbers below are game units, not engineering data. No prompt has been run and no build or play-test is being reported. Treat the trace as a paper acceptance target for a future build, not proof that one already exists.
Set the colony boundary before asking for a world
Start with one outpost, three resources, and one objective. In Kestrel Relay Shift, the player manages air, battery, and ice for three shifts, then assembles a communications beacon. That is enough to create a real design question: can the player keep air above zero, gather the right material, and pay the assembly cost before the final shift ends?
Keep the first request small on purpose. A research tree, wandering crews, random storms, multiple habitats, and a map of nearby sites would all add state that makes a mismatch harder to explain. The first version needs only a visible ice rig, an air filter, a beacon assembly point, and a compact habitat. The player can understand the objective from one screen and judge each action from the resource bars.
The frame is a design target: the operator selects Mine, one of two maximum work-order slots fills, and ice changes from 0 to 1 while air and battery stay at 3. A useful scene prompt names that state transition instead of merely asking for “a realistic moon base.” It also makes the player’s next decision legible: gather more ice, filter air later, or preserve a work order.
Write rules before the scene
Before asking a model to build a room or add art, write a compact contract. Give every resource a starting value and cap. State what each action costs, what it changes, when passive effects happen, and when failure is checked. If an order lacks a required cost, say whether it is rejected without partial effects. These details prevent a prompt from leaving implementation-critical choices implicit.
Kestrel uses abstract values. NASA’s ECLSS overview describes real functions such as atmospheric pressure, oxygen levels, ventilation, waste management, and water supply. That is useful vocabulary for a life-support theme, but it does not support the fictional air meter, recipe, resource caps, or solar schedule here.
| Order or rule | Cost | State change | Limit or check |
|---|---|---|---|
| Solar gain | None | +1 battery before work orders in Shifts 1 and 3 | Battery cap 4; no gain in Shift 2 |
| Mine | One work order | +1 ice | Ice cap 3 |
| Filter | One ice and one battery | +2 air | Air cap 6; reject if either cost is missing |
| Assemble beacon | Two ice and one battery | Beacon becomes assembled | One-time action |
| End Shift | No work order | Air −1 | Air at 0 loses immediately |
This reference table answers “what does an order do?” without mixing in the example’s timing. A rejected Filter changes nothing; it does not consume one affordable resource and then fail on the other. That small sentence removes a common source of conflicting interpretations.
The full turn order is: apply that shift’s solar gain, offer up to two work orders, resolve each selected order before the next choice, then resolve End Shift when the player chooses it. End Shift may be selected at the beginning of a shift or after any completed order, and it is not itself a work order. At the end of Shift 3, the player wins only if the beacon is assembled and air is at least 1. There are no hidden events or random rolls in this teaching contract.
Trace the three-shift scenario by hand
A prompt is easier to evaluate when it includes one legal route and one negative check. The following table records the state after the chosen actions and after each shift’s air drain. Battery and ice are capped, so the expected states are reproducible from the rules above.
| Shift | Start effect and orders | End-of-shift state | Decision |
|---|---|---|---|
| 1 | Solar: battery 2→3. Mine, Mine: ice 0→2. | Air 2, battery 3, ice 2; beacon not assembled. | Keep the ice for a later Filter and assembly. |
| 2 | No solar. Filter: air 2→4, battery 3→2, ice 2→1. Mine: ice 1→2. | Air 3, battery 2, ice 2; beacon not assembled. | Restore air while preserving enough ice to assemble. |
| 3 | Solar: battery 2→3. Assemble beacon: ice 2→0, battery 3→2. End Shift: air 3→2. | Air 2, battery 2, ice 0; beacon assembled. | Win: final air is at least 1 and the beacon is assembled. |
The first shift uses two work orders; the last uses one. Because two is a maximum rather than a requirement, the final order may be followed by End Shift. The negative check is equally useful: if Filter is selected at the initial state, the game should reject it because ice is 0 and leave air 3, battery 2, and ice 0 unchanged.
This mechanism frame is the exact point after Filter resolves in Shift 2. The meter transitions show why an action is not simply “good” or “bad”: it adds two air, but spends one unit of battery and ice. The second Mine then restores the ice needed for the final assembly. A later prototype should be checked against those transitions, not judged only by whether a filter animation looks convincing.
Use three prompts with separate jobs
Do not ask one long prompt to invent the rules, stage a scene, implement everything, and grade itself. Split those jobs so each output has a clear acceptance check. The templates below are copy-ready starting points for the fictional contract. They are unexecuted; their sample outputs are expectations written by hand, not results returned by a model.
Template A: lock the rules
Design a compact space-colony game contract called Kestrel Relay Shift.
Use only this fictional state: air 3/6, battery 2/4, ice 0/3, beacon unassembled; three shifts; at most two work orders each shift.
Before work orders, add one battery in Shifts 1 and 3 only, capped at 4.
Mine costs one order and adds one ice, capped at 3.
Filter costs one ice and one battery, then adds two air, capped at 6. If either cost is missing, reject the order with no state change.
Assemble Beacon costs two ice and one battery, changes the beacon to assembled once, and cannot be repeated.
End Shift is not a work order. After the player chooses it, air drops by one; air 0 loses immediately. Win after Shift 3 only if the beacon is assembled and air is at least 1.
Return a state table, action table, turn-order list, and contradictions or ambiguities. Do not invent storms, extra resources, buildings, or actions.Expected output: a concise rules contract with the starting state, caps, action costs, solar timing, End Shift timing, and terminal conditions intact. Accept it only if: the model does not change the numbers, treat two orders as mandatory, drain air before actions, or partially charge a rejected Filter. If it proposes extra mechanics, remove them from the request rather than quietly adding them to the baseline.
Template B: request one playable scene
Using the accepted Kestrel Relay Shift rules below, specify one small playable colony scene, not a new ruleset.
[Paste the accepted rules contract here.]
Show one suited operator, a habitat, an ice rig, an air-filter console, and a beacon assembly point in one compact outpost. Use a readable third-person camera and one screen of state indicators.
Start at Shift 1 after solar gain: air 3/6, battery 3/4, ice 0/3. The player selects Mine. Show ice become 1/3, one of at most two work-order slots fill, and the other resources remain unchanged.
Return a scene description, the visible interaction, the before/after state, and what the player can choose next. Keep all interface labels minimal and do not add systems.Expected output: a screen-scale scene where the selected rig, Mine action, and 0→1 ice change can be identified. Accept it only if: the output preserves the specified resources, includes an immediate action result, and leaves room for another order or End Shift. A polished landscape that hides the interactive object is not enough; a state panel with no playable space is not enough either.
Template C: validate the fixed trace
Check this Kestrel Relay Shift rules contract against the expected trace below.
[Paste the accepted rules contract here.]
Expected after Shift 1: air 2, battery 3, ice 2, beacon unassembled.
Expected after Shift 2: air 3, battery 2, ice 2, beacon unassembled.
Expected after Shift 3: air 2, battery 2, ice 0, beacon assembled; win.
Also try Filter at the initial state air 3, battery 2, ice 0. It must be rejected with no state change.
Return each transition as input state, order, cost, output state, and pass/fail. If a rule and expected value disagree, identify the earliest mismatch and ask which source should control. Do not silently rewrite the contract.Expected output: a row-by-row comparison and the initial Filter rejection. Accept it only if: every cost is applied once, every shift drains air at the stated point, and the first mismatch is named instead of patched over. If this template is later used against a real build, add observed state from that build. Until then, “expected” means hand-calculated, not observed.
| Template | Question it answers | Acceptance evidence |
|---|---|---|
| A — rules | Are the state machine and costs explicit? | Rules table, caps, legal timing, and ambiguity list. |
| B — scene | Can the player see and perform the first order? | Selected Mine object, one used slot, and ice 0→1. |
| C — validation | Can a reviewer detect the earliest mismatch? | Three expected end states and unchanged rejected Filter. |
The templates work as a sequence: freeze the contract, request one scene inside it, then compare a trace. Keep the rules text identical when moving from one prompt to the next. If you change a cost, update the expected states first so a later comparison is measuring one rule change, not a moving target.
The outcome frame shows the paper pass condition: the mast is signaling, the operator has one used order slot, and the final resources match the end of the hand trace. It is a visual target for a future scene prompt, not evidence that a generated build reached this state.
Debug the first divergence, not the whole game
If a future build differs from the paper trace, stop at the first state that disagrees. Record the action, resource state before and after, shift number, and whether solar or End Shift has resolved. Then fix only the rule responsible for that transition. Repeating the full prompt with “make it work better” can change several unrelated behaviors and make the next result harder to compare.
| Observed mismatch | Rule to inspect first | Focused correction |
|---|---|---|
| Mine adds two ice | Mine effect and cap | Restate that one order adds exactly one ice, up to 3. |
| Filter succeeds with no ice | Precondition and rejection behavior | Require both costs before applying any state change. |
| Battery rises in Shift 2 | Solar schedule | List gains only at the start of Shifts 1 and 3. |
| Air drains before the final order | Action order and End Shift trigger | Resolve chosen orders first; drain only when End Shift is selected. |
| Beacon can be assembled twice | One-time state transition | Set assembled once, then disable the order. |
This diagnostic table maps symptoms to the earliest rule to check. For a real build, preserve a screenshot or a structured before/after log and label it with the build revision. For this article’s hand example, there is no observed build to compare; do not invent one to make the method look complete.
Hand the contract to a creation workflow
Once the rules and expected states are written, turn them into a short game idea: who acts, what the player does, what changes, and what the result should show. The current Free AI Game Maker page describes plain-English input, a playable first version in 2D or 3D, browser testing, and refinement through follow-up prompts. Those are general workflow facts, not a promise that Kestrel’s exact rules will be followed.
For a small first pass, ask for one readable order and its immediate state feedback. Review what actually appears, compare it with the contract, and then decide whether to request one focused correction. Before submitting, review the selected model, available Koin balance, and displayed generation cost in Workspace. The article’s trace is a preparation tool: it gives you a target to inspect; it does not replace inspecting a result.
Start with a rule you can check
A useful space-colony prompt begins with a bounded loop, exact resource costs, turn timing, and a pass condition. Write the contract, ask for one scene, then compare each future state with a hand-resolved trace. When something diverges, correct the first mismatching rule and repeat the same sequence. Kestrel is only a fictional paper example, but the method gives your next real prototype a clearer target before you add more colony systems.
Frequently asked questions
What should a first space-colony game prompt include?
Include one objective, the starting state, resource caps, legal actions, exact costs and effects, action order, end-of-turn pressure, and win or loss conditions. Add one expected route and one rejected-action check. Keep other systems out until these transitions are easy to inspect.
Did an AI tool generate a playable Kestrel game?
No. Kestrel is an original fictional rules exercise, and its three-shift route is calculated by hand. The prompts in this article are templates that have not been run. No generated build, playable result, play-test, or observed player behavior is being claimed.
Why split the rules, scene, and validation prompts?
Each prompt has one job. A rules prompt makes costs and timing explicit; a scene prompt asks for a visible player action inside those limits; a validation prompt compares expected states. Splitting them helps you locate whether a problem comes from an unclear rule, a hard-to-read scene, or a mismatch in the trace.
What happens if Filter lacks a resource?
Under the written Kestrel rule, Filter is rejected unless both one ice and one battery are available. Rejection causes no partial change: air, battery, and ice remain as they were. This is a fictional design choice that should be written directly into a prompt rather than left for a builder to guess.
How can I tell when a colony prompt is too large?
If a reviewer cannot name the current state, the player’s available actions, and the expected result after one action, the first request probably includes too many systems. Remove mechanics until one screen and a short trace explain the core loop; add new systems only after that loop is clear.
