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

Editorial review 2026-09-26

“Please Continue” Not Working in Roblox Build

If please continue did not resolve stopped generation, first record whether the message was actually sent, acknowledged, blocked by a notice or answered without a completed result. Creator Hub recommends closing and reopening the app if the continuation request does not work. That advice does not justify an endless retry loop or another purchase.

Symptom

The documented continuation message has been attempted but the unfinished generation is still unresolved.

Immediate action

Establish whether the recovery was sent and what response or blocking notice actually followed.

Diagnostic branches

The message was only typed or its send state is unknown.: Inspect the acknowledgement before assuming the recovery executed.
A usage or other explicit requirement blocked the send.: Record that requirement without promising that a purchase will repair generation.
The recovery is still producing changing output.: Preserve the active response and let it settle without reopening or overlapping instructions.
The recovery response has settled without finishing, explicitly stopped or failed.: Preserve its changed output and follow the scoped official reopen guidance.
A usable completed creation is found after returning.: Inspect that result instead of generating the same concept again.
The same unfinished state persists without a useful next step.: Stop duplicate recovery requests and prepare the attempt ledger for official assistance.

Least-destructive change

Retain existing output and use the documented state check without repeated spending or project replacement.

Retest

The ledger records actual send and response evidence separately.
Changing active output is not treated as a failed continuation merely because completion is absent.
An allowance block is not mistaken for an executed recovery failure.
A completed existing result is used rather than duplicated.

Escalation

Send official support the original request context, recovery acknowledgement and resulting state if the documented path remains unresolved. Keep any billing evidence separate and do not make another purchase solely to reproduce it.

Working notes

Preserve the original request and the continuation attempt as separate events. A typed message left in the field was not necessarily submitted, and a usage notice can explain why a new message did not proceed. Do not report the recovery itself as ineffective until its actual submission state is known.

If a response arrived, describe what it changed. New output still appearing is an active recovery, not a failed one merely because the game is unfinished. Let that response settle. Only apply failed-continuation recovery after it has settled without finishing, explicitly stopped or failed. Keep any partial useful result instead of discarding it to restart the concept.

Use the documented reopen step in this failed-continuation context, while retaining the relevant project and request identity. After returning, inspect the actual state before deciding whether another instruction is appropriate. Reopening is not proof that the earlier generation was cancelled or deleted.

Stop spending attempts when the recovery outcome remains unclear. A free or purchased allowance is not a diagnostic obligation. If a charge and missing output are independently observed, preserve that evidence and use the specific billing/result assistance path rather than paying to reproduce the failure.

Examples

Attempt ledger: original stopped request / continuation text entered / actual send acknowledgement / notice or response / resulting project state / reopen outcome. The ledger distinguishes an unsent attempt from an unsuccessful response.
Blocked-message branch: the continuation is entered but a usage notice prevents sending. Record the requirement; do not claim that an executed continuation failed or that buying more must repair it.
Response-without-completion branch: output is still changing after the recovery. Preserve the active response without reopening or repeating the instruction; lack of a completed result alone does not establish failure.