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

Editorial review 2026-09-27

Choose Build Recovery, Repair or a New Concept

Choose the next action from the current state: leave actively changing generation alone, use documented recovery for stopped unfinished output, repair a playable result, or plan a genuinely new concept separately. Starting over is not a neutral refresh and can abandon useful work without resolving the original issue.

Symptom

The creator is unsure whether to continue generation, repair a result or replace existing work.

Immediate action

Identify both the actual request state and the exact meaning of the proposed restart action.

Diagnostic branches

The response is still actively changing.: Preserve that process and avoid overlapping instructions.
Output has stopped before completion.: Use the documented recovery branch and its ordering.
A playable result exists with a bounded discrepancy.: Consider a focused repair while preserving useful work.
The desired concept is genuinely different.: Treat a new project as a deliberate design choice, not recovery of the original.

Least-destructive change

Choose the state-appropriate continuation or repair before abandoning existing work.

Retest

The action's target and possible loss are understood.
Recovery is not confused with a new concept or gameplay retry.
No spending or destructive reproduction is required to fill an evidence gap.

Escalation

Preserve unresolved request and result information for legitimate assistance. A fresh generation does not guarantee recovery of the earlier request or explain a missing charge result.

Working notes

First decide what restart means in the proposed action. Retrying a game round, reopening the app, regenerating a concept and replacing a project have different effects. Do not accept a vague restart suggestion until its target and potential loss are understood.

Generation stops: Roblox Support suggests typing please continue if generation stops before finishing.

Apply that recovery advice to stopped unfinished output, not an actively changing response or a completed game whose rules differ from your preference. Let an active response settle rather than piling new design instructions into it. The generation-recovery guide owns further documented steps and their ordering.

For an existing playable result, compare a focused repair with the cost of rebuilding the concept. Preserve useful original work and avoid repeating a purchase to test whether a fresh start helps. If the proposed new game has a genuinely different objective, record it as a new project decision rather than pretending it recovers the old state.

When a request or charge remains unresolved and existing recovery evidence is insufficient, preserve the project context for official assistance. A new generation can create another result to reconcile without answering what happened to the original. This decision tree does not establish a backup or restoration feature.

Examples

Different actions: Retry inside a finished round may reset its authored attempt state; creating a new concept begins different work. Neither label proves that it will resume an unfinished generation or restore a prior project.
Decision record: observed state / exact proposed action and target / useful work at risk / applicable documented recovery / expected evidence from the action / reason to stop. Keep unconfirmed effects unknown.