Start from a recorded behavior
RDC names iterative control as part of the Build expansion. Existing Creator Hub guidance already supports refinement through follow-up instructions. The safe working method is to describe the observed behavior, the desired change and what must stay unchanged.
Use a short change record: “The player reaches the goal before noticing the score. Keep the route and controls. Show a small score confirmation after each collection, without pausing movement.” This separates the problem from a vague request to make the game better.
Three kinds of change
Mechanical change: alters an action or rule. Example: a collected item should disappear once and increment the score exactly once.
Feedback change: makes an existing rule understandable. Example: briefly highlight the return basket after a collection, without adding a new objective.
Pacing change: alters the time or effort between meaningful decisions. Example: increase the gap between two hazards so the first jump teaches the control before the second tests it.
Do not mix all three when investigating one bug. A faster timer, brighter interface and new upgrade shop can make a broken score event harder to see.
Use a repeatable iteration cycle
- Reproduce the issue from a fresh start.
- Write the expected and actual result.
- Choose one change that could explain the difference.
- State what must remain unchanged.
- Run the same test again.
- Check start, progress, failure, completion and restart.
- Keep the result only if the intended improvement survives those checks.
This is an editorial test method, not an automatic Build version-control feature. Keep your own brief and screenshots where appropriate; do not assume an unannounced rollback control exists.
Before and after example
Weak request: “Improve my arcade game and make it more fun.”
Focused request: “Keep the current movement and scoring. The first obstacle arrives before I can identify the controls. Give the player a clear starting space and show the movement instruction before the first obstacle. Do not add new enemies or purchases.”
Next test: ask someone who has not seen the game to begin without coaching. Note whether they move intentionally before the first failure. That observation is more useful than counting how many new objects appeared.
Separate iteration from usage and publishing
Every follow-up message uses prompts under the current documentation. Check AI usage before repeating broad generations. After release, use the post-publish update workflow and review the actual live version.
If repeated chat changes cannot express the required behavior, Studio handoff may be appropriate, but its current product-status consequence still matters. Use bad-generation diagnosis before starting over, and the prompt builder to preserve the intended loop.