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

Editorial review 2026-09-27

Build Game Is Not Available to Roblox Kids

Build games remain unavailable to Roblox Kids ages 5–8. This Build-specific restriction is not fixed by a successful publication, Select progress or a general publishing fee. Separate the desired audience from the workflow's documented current boundary before making changes.

Symptom

A creator expects a Build game to reach the Kids audience despite the documented Build-specific restriction.

Immediate action

Separate the intended audience from the actual game's workflow and current Support boundary.

Diagnostic branches

The assumption comes from successful publication or Select progress.: Treat those as different outcomes, not Kids access.
A fee or account change is proposed as an override.: Do not take that action on an unsupported access promise.
A different creation workflow is being considered.: Review its independent requirements and handoff consequences before changing the project.

Least-destructive change

Preserve the current project and avoid fee payments or identity changes intended to bypass the restriction.

Retest

Audience claims match the actual workflow and current official boundary.
No general publishing option is described as an automatic override.
A possible alternative workflow remains a plan, not promised approval.

Escalation

Use current official audience and Studio guidance for a deliberate workflow decision. Do not promise an exception that Roblox has not documented.

Working notes

First verify that the question concerns a Build game and the Kids audience rather than a different access notice. Creator access, a game's content label and a player's audience category answer different questions. A young creator being eligible to use a tool does not establish that every younger player can access the resulting game.

Do not treat the broader Roblox publishing process as automatic Build feature parity. Do not assume that a general paid review path changes this restriction. Avoid paying or changing account identity in an attempt to force a result the documented workflow does not offer.

If the intended design depends on a different audience, reconsider the publishing workflow before changing the project. A Studio handoff has its own consequences and review requirements. It does not guarantee a lower-age outcome. Consult those requirements and preserve the distinction between a design plan and an actual audience decision.

Communicate the current limitation in invitations and presentation. Do not market the game as available to an audience that cannot enter, and do not suggest that a parent, a different link or a renamed listing necessarily overrides the restriction.

Examples

Wrong inference: a game completes publication and the creator assumes every family audience is enabled. Publication is not the same as audience eligibility.
Planning record: intended audience / actual game workflow / official current boundary / alternative workflow research needed / no access claim until verified. This is a planning aid, not an approval test.