Do not respond to a bad result with a larger, vaguer prompt. Convert the problem into one testable mismatch and protect the parts that already work.
Bad result versus stopped generation
A bad generation reaches a playable or visible result, but the behavior differs from the request. A stopped generation does not complete. If the progress view freezes or ends early, use please continue and the generation-stuck guide before diagnosing game design.
If the result exists, play it once from start to finish. List the behaviors you directly observed. Avoid conclusions such as “the AI ignored me” when the actionable evidence is “the score increases twice for one item.”
Identify one wrong behavior
Write four short lines:
- Expected: the intended response.
- Actual: what happened in the playtest.
- Preserve: working behavior that should not change.
- Change: one correction with a visible success condition.
Example: “Expected: the gate opens after five blue tokens. Actual: it opens after the first token. Preserve the token counter and finish area. Change only the gate condition to require five tokens, then show ‘Gate unlocked.’” This is more precise than “fix the level.”
Preserve working parts explicitly
Build iterates through follow-up messages, so state the boundary of the edit. Name the controls, score system, layout or art direction that already works. A correction can still alter another system, which is why the next playtest should cover both the fixed behavior and a short regression check.
The better-prompts guide owns proactive prompt structure. This guide is reactive: it begins after an observable result is wrong.
One change, then one playtest
Each message consumes AI allowance. Combining collision, score, UI and progression changes into one message makes failures harder to isolate and can waste follow-ups. Prioritize blockers:
- Controls and start state.
- Core-loop correctness.
- Win, fail and restart states.
- Feedback and interface clarity.
- Progression and polish.
After each correction, reproduce the original failure and complete one normal round. If the requested change never arrives, rephrase the observable condition rather than adding unrelated detail. Check the AI usage guide before a long repair session.
When to restart
Restart only when the first generation chose a fundamentally different core loop, the project cannot reach a stable start-to-finish round, or repeated focused corrections damage more than they repair. Save a short list of lessons and write a smaller first prompt through the creation workflow.
If a request is refused before a result appears, use the prompt-blocked guide. Never disguise restricted content as a repair request.
Keep a repair ledger
For each iteration, save the prompt, the behavior tested and a pass/fail note. Mark working systems that must survive the next change. After three focused attempts on the same mismatch, stop and reassess whether the prompt describes a measurable condition or whether the underlying project structure is wrong. This avoids spending allowance on synonyms that do not change the instruction. A restart should use a smaller core-loop prompt informed by the ledger, not the same broad request again.