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

Editorial review 2026-09-26

Does a Published Game Stay a Build Game?

Creator Hub says published Build games remain live while their creators keep making changes in Build chat. Publication itself is not the documented Studio-editing boundary; record how later changes are made, and review the separate Build-status and automatic-rating consequences before a handoff.

Objective

Track status by editing workflow and version rather than assuming publication changes the product category.

Before you start

Identify the specific version and published destination.
Know whether the planned change stays in chat or uses Studio editing.
Review product-status and automatic-rating statements as separate requirements.

Steps

Record the workflow that produced the current version.
Define the next change and why it needs that workflow.
Review handoff consequences before editing in Studio.
Keep the status record distinct from rating and audience-review actions.
Verify the changed version without treating prompt history as a state-restoration mechanism.

Verification

The version note names the actual editing path.
Opening an editor is not conflated with applying edits.
Product status and the automatic-rating consequence are described separately.
Recovery wording does not promise recreation of the same generated state.

Limitations

The live-update statement is not a zero-downtime or instant-propagation guarantee.
This page does not inspect the user's project status or provide a rollback feature.
The dedicated handoff source note must remain current before relying on it.

Working notes

Track the editing path as part of the version record. A public destination, a working copy and an edited Studio version should not be treated as interchangeable just because they share a familiar name. Record which project and workflow produced the change you are about to rely on.

Keep product status and rating workflow in separate columns. The Creator Hub statement about an edited version's Build status answers a different question from Support's explanation of the automatic rating after changes beyond prompting. Combining them into a vague claim that everything changes as soon as Studio opens loses that distinction.

Choose a handoff for a concrete reason. If the next update is an inspectable change that fits the existing chat workflow, use the dedicated post-publish update guidance. If deeper editing is needed, write what the new workflow must control and what evidence of the working game should be retained before acting.

Do not mistake retained prompt history for restoration of the edited version. A written description can help explain or attempt to reconstruct a game, but it is not proof that the same generated state or status can be recovered. Keep the edited version's actual status and the recovery plan honest.

Examples

Version note: project identity / published destination / last change made through chat or Studio / observed status / rating-related action shown / next intended edit. Mark unknown fields instead of inferring status from the project's title.
Hypothetical decision: a post-release goal label needs clarification. The next step is a bounded label revision and regression check in the existing workflow, not opening another editor solely because the game is now public.
Handoff record: a named behavior requires deeper inspection, the current control and reset behavior is documented, and the creator has reviewed the version-status boundary. This record describes a deliberate decision, not a reversible-mode guarantee.