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-0203 · TROUBLESHOOTING

Editorial review 2026-09-26

Roblox Build Ignored My Prompt

Before concluding that Build ignored a prompt, map each requested outcome to an observable result. Mark it satisfied, contradicted or not yet testable. A feature hidden behind an unmet prerequisite is not the same as a tested feature that did the opposite, and a changed sentence in the reply is not proof of gameplay compliance.

Symptom

The result seems not to reflect instructions, but requirement coverage is mixed or unobserved.

Immediate action

Match the actual sent requirement to the state where its result can be observed.

Diagnostic branches

The prerequisite for observing the requested outcome was never reached.: Mark the outcome untested and identify the blocking prerequisite.
The game contradicts the requirement in the relevant state.: Write that precise expected-versus-observed correction.
The result satisfies the rule with a different optional appearance.: Keep behavior success separate from a remaining style preference.
The viewed result cannot be tied to the request.: Resolve the available project context without claiming a hidden revision cause.

Least-destructive change

Preserve satisfied requirements and correct only a demonstrated gap.

Retest

The relevant prerequisite is observed, or the outcome remains explicitly untested.
The repaired rule is checked in the game rather than accepted from the response text.
Previously satisfied requirements remain in the preservation record.

Escalation

Carry confirmed and untested requirements separately into further investigation. Do not manufacture a completion test or model-compliance score. An instruction order does not guarantee that a request will be followed.

Working notes

Use the actual message that preceded the result, not a rewritten version of what you meant. Split only independent observable requirements: where the player begins, what the action changes, and which outcome appears. Keep optional preferences separate so a different decoration does not count as failure of the entire game.

For each requirement, identify the state in which it can be observed. If the requested completion effect needs a delivered object, an attempt that never reaches delivery cannot establish whether that effect works. Record the blocked prerequisite and stop calling the downstream outcome absent until that state is genuinely reached.

Compare game behavior with the requirement, not with the assistant's explanation of the change. The reply may describe the intended improvement while the visible game still behaves differently. Conversely, the game may satisfy the requirement in a different but acceptable visual form. Preserve that distinction before sending a corrective message.

Repair a confirmed discrepancy with the smallest useful requested difference and retain requirements already met. If the observed game might be an older result, establish the available project or revision context first; this method cannot infer cache behavior or prove which hidden version is running.

Examples

Coverage row: request says show completion after delivery; delivery could not be reached because the parcel was unavailable. Result: not tested, with collection as the blocker—not completion ignored.
Confirmed mismatch: the instruction requires the entry gate to remain closed before the key is carried, but the gate opens in that observed state. Request that boundary correction while preserving the already working key pickup and route.
Record: exact requirement / observable prerequisite / actual result / satisfied, contradicted or untested / preserved working behavior. This is an inspection aid, not a generation-accuracy percentage.