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

Editorial review 2026-09-27

Build Game Update Will Not Publish

When an update will not publish, separate the existing public version from the edited candidate and the latest publishing result. Earlier publication does not establish that a changed candidate meets every current requirement. Preserve the known working version and diagnose the actual returned notice rather than replacing the game.

Symptom

A previously published game's changed candidate has no successful confirmed publishing outcome.

Immediate action

Record the prior public version, changed candidate, editing workflow and latest action result separately.

Diagnostic branches

The candidate returns an explicit content or account requirement.: Follow that requirement without assuming earlier publication overrides it.
The action has no clear outcome.: Use publishing-state diagnosis while preserving the candidate and working public observation.
The editing workflow changed.: Review its current handoff and maturity consequences before retrying.

Least-destructive change

Protect the known working artifact and avoid replacing the game or deliberately disrupting live play for diagnosis.

Retest

Old public reachability and new candidate success are not conflated.
The remedy matches the actual notice or boundary.
No universal update sequence or automatic rollback is invented.

Escalation

Provide the candidate change record and exact publishing result through official assistance if unresolved; do not claim removal of the existing release without evidence.

Working notes

Identify what changed since the last confirmed public result and which workflow made the change. A Build-chat revision and an actual Studio edit have different source-backed consequences. Do not use an old successful publication as evidence about the new candidate's status.

Record the latest action and result: unavailable control, unacknowledged action, in-progress state, safety issue or another requirement. Follow an explicit notice rather than assuming every update failure is moderation. No universal republish or review sequence is established for every kind of Build edit.

Keep the prior public observation separate from the candidate observation. The old version remaining reachable does not prove that the update succeeded, and a candidate error does not prove that the old game was removed. Verify only through authorized safe paths and do not deliberately break the live version as a diagnostic step.

Choose a narrow remedy tied to the notice or observed boundary. Avoid mixing a failed update with a new feature request, identity change or broad redesign. If the current state is ambiguous, preserve the change record and ask about that state instead of repeatedly submitting altered candidates.

Examples

Version split: an earlier delivery loop is still reachable; the revised candidate returns a safety issue. Keep those outcomes separate and address the candidate's notice.
Workflow split: the update includes an actual Studio edit and now requests content information. Use the handoff and maturity process instead of assuming the former simplified flow still applies.