A good AI prompt for a factory automation game defines what each machine accepts, what it produces, how items move, and what counts as a win. Start with one line and one delivery target; add decoration only after the production rules are checkable. The Brassline Works example below is an original fictional design with a hand-resolved six-cycle ledger. The four prompt blocks are authored templates; none was run for this page, and no playable build or test result is claimed.
Start with one line and one delivery goal
Keep the first slice small enough to audit. In Brassline Works, the player connects a Copper Mine to a Smelter, a Press, and a Shipment Crate. The only objective is to ship two gears by the end of cycle six. That one target gives every recipe, buffer, and transfer rule a reason to exist.
Write the start state and success condition before asking for a larger factory. The line begins empty at cycle zero. The Mine makes one ore each cycle; two ore become one plate, and one plate becomes one gear. The Shipment Crate counts a gear when its belt delivers it. No extra machine, side quest, or inventory system is needed to explain this loop.
Prompt 1 — define the slice: ask for the smallest scene and objective first. Check that the output describes a visible player goal and a fixed line before you introduce more content.
Design a small factory automation game prototype called Brassline Works. The player connects one Copper Mine, one Smelter, one Press, and one Shipment Crate in a single line. The goal is to ship two gears by the end of cycle six. Start with every buffer empty at cycle zero. Before adding art or extra systems, return a table of each station's input, output, and capacity, then state the exact win condition and restart state. Treat these details as a proposed game design; do not add unlisted machines, resources, or permanent progression.Specify recipes and full-buffer behavior
A recipe is incomplete until the prompt says what happens when its output has nowhere to go. In this example, a machine consumes inputs only when its output slot is free. If that slot is occupied, the machine waits and keeps its inputs. This rule prevents a blocked belt from silently deleting or duplicating items.
| Station or link | Capacity and rule | What to verify |
|---|---|---|
| Copper Mine | One-item output; makes one ore each cycle when free. | If the output is occupied, production waits and the item stays put. |
| Smelter | Input holds two ore; output holds one plate; recipe is 2 ore → 1 plate. | It consumes ore only when both inputs and the output slot permit the recipe. |
| Press | Input holds one plate; output holds one gear; recipe is 1 plate → 1 gear. | It keeps the plate if its gear output is occupied. |
| Belts and Shipment | Each belt transfers at most one item per cycle; Shipment counts incoming gears. | A transfer occurs only when the source has an item and the destination can accept it. |
Keep input and output slots separate in the design. An item that is waiting in a machine's output has not reached the next machine yet. A reader should be able to point to the exact slot where each item waits, especially when a downstream station is full.
Prompt 2 — close the buffer rules: include the capacities and recipes in one pass, then ask for an explicit blocked-output rule.
Use these exact capacities: Mine output 1 ore; Smelter input 2 ore and output 1 plate; Press input 1 plate and output 1 gear. The Smelter recipe is 2 ore into 1 plate. The Press recipe is 1 plate into 1 gear. A machine may consume its input only if its output has room for the full result. If it cannot run, preserve all inputs and wait. Belts never drop, duplicate, or teleport items. Return a compact state table showing every buffer and the condition that makes its machine wait.Fix the cycle order before asking for polish
One global order keeps the same item from being processed twice in a single cycle. Brassline uses this sequence: resolve the Smelter, resolve the Press, let the Mine produce, move eligible items on belts, then check the shipment goal. Belt transfers happen after machine processing, so an item arriving at a receiver cannot be processed until the next cycle.
| Phase | Rule | Timing consequence |
|---|---|---|
| 1. Process | Resolve Smelter, then Press using buffers present at cycle start. | Items arriving later in the cycle are not available yet. |
| 2. Produce | Mine adds one ore if its output buffer is free. | A full output makes the Mine wait; it does not create overflow. |
| 3. Transfer | Each belt moves up to one item if its source and destination allow it. | New arrivals become usable in the next cycle. |
| 4. Check | Shipment counts incoming gears and checks the two-gear goal. | The delivery test uses the completed end-of-cycle state. |
Prompt 3 — define the tick: get the order in writing before requesting animation or more machines. Use this prompt to make the transfer boundary explicit.
Use one shared cycle order for the whole line: first process the Smelter, then the Press, using only buffers present at cycle start; second, let the Mine produce if its output is free; third, transfer at most one item on each eligible belt; fourth, count incoming gears at Shipment and check the goal. Transfers happen after processing, so a newly arrived item is not usable by a receiving machine until the next cycle. Show the order in the interface and return a six-cycle state trace before adding visual polish.
Hand-resolve the six-cycle line
A short paper trace is a useful oracle for later inspection: if a future build differs, you can identify the first cycle where the implemented state diverged. The table is manually calculated from the rules above. It is not an executed prompt, game run, playtest, or measured result.
| Cycle | Processing and transfer | End state: Smelter ore / Press plate / shipped gears |
|---|---|---|
| Start | All buffers are empty. | 0 / 0 / 0 |
| 1 | Machines wait; Mine produces one ore; belt moves it to Smelter. | 1 / 0 / 0 |
| 2 | Smelter waits with one ore; Mine produces another; both ore are in Smelter input. | 2 / 0 / 0 |
| 3 | Smelter makes a plate; Mine makes ore; belts move plate to Press and ore to Smelter. | 1 / 1 / 0 |
| 4 | Press makes a gear; Mine makes ore; belts move gear to Shipment and ore to Smelter. | 2 / 0 / 1 |
| 5 | Smelter makes a plate; Mine makes ore; belts move plate to Press and ore to Smelter. | 1 / 1 / 1 |
| 6 | Press makes a gear; Mine makes ore; belts move gear to Shipment and ore to Smelter; goal succeeds. | 2 / 0 / 2 |
The two gears arrive at the end of cycle six, with two ore still waiting in Smelter input. The delay comes from two separate rules: the Smelter needs a pair of ore, and a belt-delivered plate cannot be processed until the next cycle. The final state closes the target without an extra item or a hidden action.
Check back-pressure with a seeded blockage
Test the blocked-output rule with a deliberately prepared state rather than waiting for a rare timing accident. Temporarily close the gear belt while one gear is already in the Press output and the Shipment Crate is ready to receive it. Advance one cycle. The gear should remain in Press output; any machine whose output is full should wait with its inputs unchanged. When you reopen the belt, the gear should transfer once and later production should resume without loss or duplication.
| Acceptance check | Expected design response |
|---|---|
| Gear belt closed with a gear in Press output | The gear stays in its slot; the Press cannot overwrite it. |
| Smelter output occupied | The Smelter preserves its ore inputs and waits. |
| Mine output or destination full | The Mine waits instead of making a second item. |
| Belt reopened | The waiting gear transfers once; the next eligible production step can continue. |
| Restart selected | All buffers return to empty, cycle returns to zero, and the same line and goal load again. |
Prompt 4 — add observable checks: ask for a simple way to pause a belt and inspect state, then compare the expected and observed buffers. This is a test plan for a future implementation, not a record that the checks ran.
Add a temporary way to close the Press-to-Shipment belt for one cycle. Provide an acceptance state with one gear in Press output and the Shipment Crate ready to receive it. When the belt is closed, the gear must stay in the output slot; the Press must not overwrite it. If any downstream output remains full, upstream machines preserve their inputs and wait, and the Mine waits when its output or next destination is full. Reopen the belt and verify the gear transfers once and production resumes. Add a restart control that clears all buffers and returns to cycle zero. Show each before/after state so a tester can record actual behavior.Use a creation workspace for a first implementation
The official Free AI Game Maker page describes entering a game idea in plain English, testing a playable first version in the browser, and refining it with follow-up prompts. Before submitting, its guidance asks creators to check the selected AI model, available Koin balance, and displayed generation cost. These are general workflow facts; they do not show that this factory example has been generated or that its buffer and tick rules are supported. Comparing any future output with the written ledger is this article's recommendation, not a product guarantee.
Carry over the four prompt stages as a design brief, then inspect the result against the written ledger. If a machine consumes a newly transferred item in the same cycle, record the exact phase where that happened and revise one rule at a time. To begin your own line, open the Free AI game maker, describe one production goal, and review the result and displayed costs before continuing.
Build the first line around a rule you can inspect
A useful first factory has one measurable delivery goal, a recipe and buffer contract, a shared tick order, and a way to see what happens when output is blocked. These prompts give you a compact starting point; the hand-calculated trace gives a future build something specific to check. Start with one line, record the first real run when you have one, and expand only after each transfer is understandable.
Factory automation prompt questions
What should an AI prompt for a factory game specify first?
Start with one player goal, a short machine chain, and a measurable success condition. Then list each machine's inputs, outputs, and buffer sizes before adding visual style. This order gives you a clear state to inspect and makes it easier to see whether an implementation followed the design rather than merely looking like a factory.
Why do buffer sizes matter in an automation game?
Buffer sizes determine whether machines can accept, hold, and pass items without losing them. A recipe should state when it consumes input and what happens if its output is occupied. If those conditions are missing, the same belt layout can appear to behave differently from one cycle to the next, making a later test hard to interpret.
When can a machine use an item delivered by a belt?
That depends on the cycle order you specify. In Brassline Works, machines process first and belts transfer later, so a newly delivered item waits until the next cycle before its receiver can use it. Writing this boundary explicitly prevents one item from being processed twice during the same tick.
What should happen when a factory machine's output is blocked?
For this example, the machine preserves its inputs and waits until its output has room. The prompt also asks the Mine to wait if its one-item output or next destination is full. These are authored rules for the fictional line; a future build must be checked to confirm whether it follows them.
Does this prompt kit include a tested playable factory?
No. Brassline Works is a fictional teaching design, and the six-cycle trace is hand-resolved from its written rules. The prompt blocks were not run for this page, and no playable build or user test was supplied. Treat the trace as an expected-state reference, then compare it with a real build only after one exists.
