Does a focused change mean a very short prompt?

No. Include the detail needed to define the intended behavior and its boundaries. Avoid unrelated objectives, not necessary explanation.

What if the revision changes something I asked to preserve?

Record the regression and its reproduction steps. Do not treat the target improvement as a complete pass until the preserved behavior has also been checked.

Plan and test game mechanics

A mechanic needs an observable rule: an action, a change in state and feedback to the player. Before adding more systems, test whether the first action, win condition and restart work together. The existing guides below provide the starting workflow and debugging checks.

Open Mechanics collection ↗

Prepare a game for publishing

Publishing starts with a game that can be tested, understood and maintained. Check the available creator controls, audience settings and safety requirements before a release. Use the publishing guide for the sequence, and the troubleshooting guide for an actual blocked step.

Open Publish collection ↗

BC-0034 · CORE GUIDE

Editorial review 2026-09-26

Why to Change One Thing at a Time in Build

Make a revision answer a specific question. Name the behavior to change, hold relevant comparison conditions steady and repeat the same test so you can tell whether the requested difference helped.

Objective

Create a revision whose observed effect can be compared with the preceding version.

Before you start

Record a concrete defect or design question.
Identify a repeatable scenario that exposes it.
List the conditions and behaviors that should remain unchanged.

Steps

State the question the revision should answer.
Choose a change directly related to that question.
Describe necessary consequences of the change without adding unrelated systems.
Name the comparison conditions and preserved behavior.
Repeat the original scenario after generation.
Record the target outcome and regressions separately before deciding what to change next.

Verification

The brief has a clear outcome that can be observed.
The before-and-after checks use comparable starting conditions.
An improvement is not attributed to a requested change when another relevant condition also changed.
Preservation instructions are followed by an actual regression check.
Inconclusive observations remain inconclusive rather than becoming proof of a better design.

Limitations

This is an editorial comparison method, not a guarantee of deterministic generation.
A local before-and-after observation does not establish a population-level engagement effect.
Urgent correctness repairs may require coupled changes; explain the shared invariant instead of forcing an arbitrary prompt limit.

Working notes

A controlled revision is not a word-count rule. A coherent change may need several clauses to specify its trigger, feedback and preserved behavior. What matters is that the request has an identifiable outcome rather than combining unrelated goals whose effects cannot be separated.

Choose the variable from the observation. If the player sees a hazard too late, changing both hazard visibility and movement speed makes the improvement hard to interpret. First decide whether the question concerns noticing the threat or responding to it, then select the change that tests that question.

Keep the comparison conditions relevant. Use the same starting state, route and objective when checking a movement revision. If a reset defect has already changed the starting state, resolve or record that difference before attributing the result to the new change.

Inspect preserved behavior as well as the target. A request to keep controls unchanged is an instruction to the generator, not proof that they stayed unchanged. Repeat a known control sequence after the edit and record any regression separately from the result you intended to improve.

Examples

Controlled question: Can the player recognize the hazard before entering its contact area? Revision: make the hazard contrast distinct from the floor while preserving its position, collision boundary and movement. Retest: approach along the same route without changing player speed.
Confounded request: Make enemies slower, move the exit closer, add a checkpoint and improve the lighting. A resulting easier attempt would not identify which change mattered. Pick the observed obstacle to progress and test a focused revision first.
Coherent multi-clause repair: Clear carried state on Retry, restore the parcel to pickup and remove the delivered message before interaction resumes. These clauses describe the same reset transition; splitting them into disconnected requests could leave inconsistent intermediate behavior.

Common questions

Does a focused change mean a very short prompt?: No. Include the detail needed to define the intended behavior and its boundaries. Avoid unrelated objectives, not necessary explanation.
What if the revision changes something I asked to preserve?: Record the regression and its reproduction steps. Do not treat the target improvement as a complete pass until the preserved behavior has also been checked.