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

Editorial review 2026-09-26

Roblox Build Creator Controls

Treat creator controls as an inventory of tasks you can actually complete, not a promised panel copied from an announcement. The RDC announcement describes an asset library and iterative control as part of Build's alpha expansion. Check the controls exposed in your own project before choosing an editing workflow.

Objective

Produce a control inventory that separates actual interface behavior from announced scope.

Before you start

Identify the project and the task you want to perform.
Keep documentation dates with any claimed capability.
Avoid applying an unclear destructive control to a working version.

Steps

Name the desired change without guessing a button.
Record the visible surface, label and selected target.
Read the stated operation and confirmation scope.
Mark the result observed, documented, announced or unknown.
Choose a bounded test or defer the operation based on that evidence.

Verification

Every inventory row has a target and evidence category.
Dashboard controls are not presented as Build-chat controls.
An announcement-only row has no invented click path.
Unknown destructive behavior leads to a pause rather than a speculative trial.

Limitations

This inventory does not unlock missing account features.
Interface labels and available controls can differ from the reviewed announcement.
A control's presence does not establish restoration or rollback behavior.

Working notes

Start with the intended action: inspect an object, describe a revision, test a behavior or manage a published destination. Those actions need different evidence. A visible label is not proof of what the control changes, and an announcement is not a complete description of your account's interface.

Keep separate columns for observed behavior, current documentation, dated announcements and unknown behavior. Record the project and surface alongside the label. A setting in Creator Dashboard should not be recorded as a control inside Build chat, even when both relate to the same game.

Inspect before making a destructive change. Read any description, confirmation and current selection. If the scope is unclear, preserve a note of the working behavior and defer the operation; do not discover what a delete or replace action does by applying it to the only useful version.

Use the inventory to choose a route, not to score feature completeness. A missing control may leave a specific task unresolved. It does not prove a hidden shortcut exists, that another account's interface can be enabled locally, or that moving to Studio preserves the same workflow.

Examples

Control inventory row: intended action = change the goal label; visible surface = project chat; current selection = named project; observed result = not yet tested; reversible path = not established. This row tells you what to inspect before sending the revision.
Announcement-only row: asset-library capability described at RDC; exact control label and selection scope not observed. Keep the row as announced scope rather than adding imaginary menu instructions.
Routing decision: if the requested operation needs direct inspection unavailable in the current surface, document that requirement and read the Studio handoff guidance before changing the working version.