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

Editorial review 2026-09-26

What Counts as a Roblox Build Prompt?

A sent message counts as a prompt, including a follow-up that changes an existing game. Treat corrections and refinements as usage decisions too; inspecting the game is a different activity from sending another instruction.

Objective

Distinguish sent instructions from preparation and inspection when reasoning about usage.

Before you start

Identify the action you are considering.
Look at the usage information available in your own interface.
Keep pricing and quota assumptions separate from message classification.

Steps

Determine whether the next action sends an instruction.
Include corrections and follow-ups in that classification.
Prepare the intended change and retest before sending.
Record observed usage information without extrapolating a price formula.
Inspect the result before deciding whether another message is needed.
Use an official support inquiry for an unresolved charge discrepancy rather than paid probing.

Verification

The log distinguishes drafted text from a sent message.
A correction is not assumed to be exempt merely because the earlier result was wrong.
No character-to-credit or fixed-price calculation has been invented.
Observation and further generation remain separate decisions.

Limitations

This page explains counting categories, not an account-specific balance.
It does not establish a universal allowance or a refund entitlement.
A more carefully prepared message can still require additional revision.

Working notes

Classify the action before deciding whether to send it. An initial game description, a request to alter a mechanic and a correction to the last result are all messages. A small change is not automatically outside the allowance simply because it feels like a repair rather than a new creation.

Do not confuse message counting with an exact price model. Knowing which actions count does not establish a universal free-message quantity, the cost of a particular request or a conversion from characters to credits. Read the account's displayed usage and purchase information rather than inventing a formula from prompt length.

Write and inspect locally before committing another message. Keep a draft of the requested difference, check for conflicting rules and prepare a retest. This is an editorial way to make the instruction more useful, not a technique that changes official counting or guarantees lower consumption.

If a displayed allowance seems inconsistent with your activity, record the observed state and action sequence. Do not send more paid requests merely to measure how charging works. A useful record distinguishes what was sent from what was only drafted or inspected.

Examples

Action classification: write a possible revision in a local note—draft preparation; send that revision in the game conversation—message; inspect the resulting reset behavior—observation; send a further correction—another message. Keep those actions separate in your session log.
Misleading assumption: 'This only changes the background, so it must not count.' Replace that assumption with a decision about whether the visual change is worth requesting now, using the actual usage information shown in the interface.
Usage question record: allowance display before the action—record if observed; message sent—retain wording; display afterward—record; purchase confirmation—record only if one actually occurred. Unknown fields stay unknown rather than being filled from an estimated character count.