Is saving the prompt history enough?

It preserves the request but may omit the state and action that revealed a defect. Add the expected and observed behavior, the retest sequence and the decision you made from it.

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-0033 · CORE GUIDE

Editorial review 2026-09-26

Roblox Build Iteration Cycle

Keep an iteration log that connects each requested change to an observed result and a next decision. Save the original brief, record the exact defect sequence and retest that sequence after the follow-up.

Objective

Create a traceable request-to-observation record for the next editing session.

Before you start

Identify the brief or follow-up associated with the current result.
Keep a separate place for expected and observed behavior.
Avoid storing credentials or private account documents in the log.

Steps

Name the behavior you intended to change.
Describe the starting state and exact action order used to inspect it.
Record visible feedback without guessing an internal cause.
Write the narrow next request and the behavior it should preserve.
Repeat the recorded sequence after the edit.
Close the entry with the outcome, decision and remaining untested areas.

Verification

A reader can reproduce the observation from the entry without a spoken explanation.
The request and observation are distinguishable rather than blended into a success claim.
The retest uses the same meaningful starting state as the original defect.
The next decision cites the result that motivated it.
Untested behavior is not silently marked complete.

Limitations

The sample entries illustrate a record format; they are not reports from our own gameplay sessions.
An iteration log is not a version-control or backup mechanism.
A reproducible symptom can still have an unconfirmed technical cause.

Working notes

A chat transcript records what you asked, but not necessarily what the game did. Add the starting state, action and visible outcome beside the relevant request. This gives the next revision a concrete problem to solve instead of relying on your memory of whether the previous version felt better.

Distinguish the expected result from the observation. Write what should happen before the check and what actually happened after it. If the result is unclear, mark it unclear and describe the missing feedback. Do not convert an uncertain observation into a confident bug cause.

Keep the decision attached to the evidence. A revision might be retained, narrowed or investigated further; a successful local observation does not mean every related behavior passed. Note the preserved behavior you also checked and any areas you did not inspect.

Use the log as an editorial record, not an assumed recovery system. Saving prompt text and observations helps explain a previous version, but it does not itself create a restorable project copy or guarantee that repeating an old request recreates the same result.

Examples

Hypothetical log entry: Intended change—restart at the entrance. Starting state—checkpoint active. Action—press Retry. Observation—player returned to the checkpoint. Next request—clear the active checkpoint during Retry while preserving the level layout. Retest—the same checkpoint-to-Retry sequence, followed by ordinary movement from the entrance.
Illustrative unclear result: The objective panel changed, but the parcel disappeared before arrival. Record the action order and both visible changes. Do not label the cause as a server issue or a generation limit without supporting evidence.
Hypothetical handoff note: Retry now matches the intended starting state in the recorded sequence. Pickup after retry was inspected; completion after retry is still untested. Continue with that missing check before adding another mechanic.

Common questions

Is saving the prompt history enough?: It preserves the request but may omit the state and action that revealed a defect. Add the expected and observed behavior, the retest sequence and the decision you made from it.