Choose the colony decision before you describe its world
A colony-management prompt needs a decision with consequences, not just a list of buildings and resources. Start with one action that competes with another, state when its cost and output resolve, then write down what counts as surviving and finishing. The first prototype can answer one question: can the player make a plan that keeps residents supplied while moving a separate objective forward?
Dayglass Outpost is a fictional surface colony used to teach that prompt structure. Each dawn, the player directs the outpost's two-unit battery to either a hydroponics bay or a relay mast. The bay produces meals; the relay advances a signal. The three-day example below is hand-calculated. No prompt was run, and no generated or tested build was supplied.
Keep the first decision small enough to follow from one state to the next. If the player cannot tell what they traded away, adding residents, research trees, or weather will make the prompt harder to check rather than more useful.
Write the state contract before asking for extra systems
A prompt becomes easier to implement when every number has a phase and every action has a limit. In Dayglass, the battery resets at dawn and the player must spend it all on exactly one manually selected module. The ration check comes after that module resolves. This order determines whether a relay choice is safe on a day when the meal store is low.
| Rule | Dayglass proposal | What the first check should show |
|---|---|---|
| Starting state | Day 1 dawn: 3 residents, 3 meals, signal 0/2. Battery resets to 2 units each dawn. | The player can read day, meals, signal, and the current battery before choosing. |
| Action limit | Choose exactly one module action per day. Either action spends both battery units; unused power cannot be carried over. | After one choice, both modules are unavailable until the next dawn. |
| Hydroponics | Manual activation adds 6 meals. Signal stays unchanged. | Meal stock rises by six before the dusk check. |
| Relay | Manual activation adds one signal stage while signal is below 2/2. At 2/2, Relay is unavailable. | Only a Relay choice advances signal; it never produces meals. |
| Dusk ration check | After the module resolves, check for at least 3 meals. If fewer than 3 are available, fail before subtracting anything. Otherwise subtract 3, one per resident. | The phase order is visible, including the fail-without-consuming case. |
| End and restart | After Day 3's ration step, succeed at signal 2/2 if no ration check failed. Otherwise fail. Restart restores the complete Day 1 state. | Success is tied to the objective and survival check, not to a score or hidden event. |
This table closes several gaps a short genre prompt would leave open. It says when power returns, whether a player can split an action, whether a relay can be repeated after completion, and whether food is checked before or after consumption. If you want to change one of those rules, change the contract first and recalculate the example.
Hand-resolve three days before adding features
Before asking a generator to build a colony, trace a route with the proposed rules. The arithmetic can reveal an impossible win condition or an unintended shortcut before art, residents, or additional resources make the prototype harder to diagnose.
| Day | Action | Meals before dusk check | Signal after action | Dusk and end state |
|---|---|---|---|---|
| 1 | Relay | 3 | 1/2 | Subtract 3 meals. End with 0 meals and 1/2 signal; the colony survives. |
| 2 | Hydroponics | 6 | 1/2 | Subtract 3 meals. End with 3 meals and 1/2 signal; the colony survives. |
| 3 | Relay | 3 | 2/2 | Subtract 3 meals. End with 0 meals and 2/2 signal; the colony succeeds after the final ration check. |
The result depends on the order written in the contract: module output resolves before dusk. If Hydroponics ran after rationing instead, the Day 2 state would be different. A second route can start with Hydroponics and then use Relay twice; the same rules leave enough meals for all three checks. By contrast, repeating Relay on Day 2 after the table's Day 1 choice leaves 0 meals before dusk, so that route fails without subtracting stock.
This is a hand-resolved teaching example, not a balance test. Keep it as an expected-state reference for a future build, not as evidence that an implementation followed the rules.
Use three prompts instead of one overloaded request
Separate rule clarification from implementation and repair. That makes each request easier to review and leaves room to catch a contradiction before expanding the scene. These are ready-to-try prompts for the fictional design; they have not been run.
Prompt 1: ask for a rule sheet
Turn this colony idea into a compact rules contract. Do not add new systems.
Start state: Day 1 dawn, 3 residents, 3 meals, signal 0/2, battery 2 units.
At each dawn reset battery to 2. The player chooses exactly one manual action,
which spends both units. Hydroponics adds 6 meals. Relay adds 1 signal stage
only while signal is below 2/2. Resolve the chosen action before dusk.
At dusk, if meals are below 3, fail without subtracting meals; otherwise subtract
3 meals. After Day 3's ration step, succeed only if signal is 2/2 and no ration
check failed. Restart restores the full starting state.
Return: (1) state variables, (2) phase order, (3) legal actions and limits,
(4) success/failure and restart rules, and (5) ambiguities or contradictions.
Hand-resolve Relay on Day 1, Hydroponics on Day 2, Relay on Day 3.
Do not claim these rules have been tested or invent extra events.Compare the returned contract with the source rules before continuing. If it moves the ration check, lets the player keep unused battery, or adds a hidden food cost, correct the rules sheet instead of asking for a larger build.
Prompt 2: request only the minimum prototype
Build a small single-player surface colony prototype called Dayglass Outpost
from the rules contract below. Show a compact habitat, one hydroponics bay,
one relay mast, three residents, and a meal store. Use a clear top-down or
isometric management view with readable paths between modules.
Display the current day, meals, signal progress, battery, selected action, and
resolved result. Give the player one manual module choice each day. Reset the
battery to 2 at dawn; either module spends all 2 units. Hydroponics adds 6 meals.
Relay adds 1 signal stage while signal is below 2/2. Resolve the module before
checking at dusk for at least 3 meals; on failure, stop before subtracting.
Otherwise subtract 3 meals. After Day 3's check, succeed only at signal 2/2.
Restart restores Day 1, 3 residents, 3 meals, signal 0/2, and battery 2/2.
Omit weather, worker assignments, automation, creatures, extra resources,
research trees, combat, random events, and multiplayer. Keep feedback local to
the chosen action. Treat this as a proposed design; do not report a test result.This asks for one decision and enough visible state to inspect it. It does not ask for every colony feature at once. If a tool returns something different, record the actual result before changing the prompt; do not assume the requested behavior appeared.
Check the rules that can silently drift
Use specific checks rather than a broad question like “does it work?” The list below is a plan for a future real build. It contains expected outcomes, not passed tests.
| Try | Expected state | Mismatch to record |
|---|---|---|
| Start a fresh run. | Day 1, 3 meals, signal 0/2, battery 2. | Any missing or different starting value. |
| Choose Relay, then try selecting Hydroponics again before dawn. | Relay spends both units, advances signal to 1/2, and the second action is unavailable. | Two actions resolve in one day, or battery carries over. |
| Resolve Day 1 Relay, then choose Relay again on Day 2. | The second dusk check sees 0 meals and fails before subtracting stock. | Food is consumed below zero, or the run continues despite the failed check. |
| Use Relay → Hydroponics → Relay on three days. | End-of-day meals are 0, 3, and 0; signal is 1/2, 1/2, and 2/2. The run succeeds after Day 3 rationing. | Any transition differs from the hand trace. |
| Try Relay after signal already reaches 2/2. | Relay is unavailable; signal stays at its cap. | Signal exceeds 2/2 or a second completion stage appears. |
| Restart after a result. | Return to Day 1 with 3 meals, signal 0/2, battery 2, and 3 residents. | Any old stock, day, or result state remains. |
For each check, write down the exact action and what the interface showed. If you have no build to inspect, keep this as a planned checklist. A predicted result from the table is not the same as an observed result from a game.
Ask for one evidence-based revision
When an actual build differs from the rule contract, give the next prompt a narrow job. State what you did, what you expected, and exactly what appeared. Ask to change only the implicated rule and preserve the rest. Then repeat the same action sequence. This keeps a repair tied to evidence instead of adding systems in response to a vague impression.
Observed mismatch in my current build:
Action: [exact day and module choice]
Expected: [state from the rule table]
Observed: [what the build actually showed]
Change only the rule responsible for this mismatch. Keep all other resource
values, action timing, success/failure conditions, and interface elements the
same. Tell me which rule changed and list the same check I should repeat.
Do not claim the correction has been tested until I run that check again.If you have not run a build, do not fill in the “Observed” line from the hand trace. Leave it as a template. The trace provides something to compare against later; it does not supply a real observation.
Bring the prompt to a general game maker
SEELE's current Free AI Game Maker page describes entering a game idea in plain English, reviewing a playable 2D or 3D result, iterating in Workspace, and checking displayed Koin costs and account options before generation. Those are general workflow details. The page does not establish that Dayglass Outpost, colony management, or these exact resource rules are supported.
Bring the rules contract and the check table as your own design brief. Inspect whatever result is currently offered, compare its visible state with one expected transition, and decide whether to revise or simplify. A page description is not evidence that this example has been generated or that a result will match every requested rule.
Frequently asked questions
Which mechanics belong in the first colony prompt?
Include the starting resources, one player action, its cost and output, the time when the action resolves, and the condition checked afterward. Add the win, failure, and restart rules that close that loop. Leave worker jobs, weather, research, and automation for later unless one of them changes the decision you are trying to inspect.
How many resources should a colony prototype start with?
Use only the resources needed to make the central decision understandable. Dayglass starts with meals, battery, and signal because those values explain the tradeoff between feeding residents and finishing the relay. If a resource does not change the action choice, survival check, or objective, omit it from the first request.
How can I show production and consumption clearly?
Show the state before a choice, resolve the selected module, then show the dusk check and final stock. Keeping those phases separate makes it easier to spot whether output arrived too late or a ration was subtracted twice. The exact panel design can vary; the prompt needs to specify which values a player must be able to inspect.
What should happen when a ration check fails?
Choose the failure rule before prompting. In this example, a stock below three meals causes failure before any meal is subtracted, so the displayed state stays consistent with the rule. A different colony may allow shortages or partial rations, but the prompt should say how those options change stock and whether the run continues.
Does a detailed prompt guarantee a playable colony-management game?
No. A detailed prompt makes the requested rules easier to inspect, but it does not prove that a particular tool will implement them correctly. Review the actual output, check the state transitions you care about, and keep any mismatch visible in your notes. Treat the Dayglass values as a fictional teaching example, not a tested result.
Build one checkable colony loop
Write the decision, timing, resource changes, survival check, and finish condition before asking for a larger colony. Hand-resolve one route, inspect one real result at a time, and use the first mismatch to guide a bounded revision. When you're ready to try your own brief, start with the Free AI game maker. Check the current displayed cost and verify what the resulting build actually does.
