Does a generated playable scene mean the test passed?

No. It means there is a result to inspect. Compare the actions and state transitions with the brief, including failure and retry, before recording any behavior as passed.

Should I fix everything before testing again?

Repair the defect that blocks the next useful observation, then repeat its original sequence and check the preserved behavior. A large unrelated revision makes it harder to know which change affected the result.

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

Editorial review 2026-09-26

First Playtest Checklist for a Build Game

Inspect the first generated version from a clean start, through the intended action, into completion or failure, and back through retry. Record actual observations against expected behavior instead of treating a successful generation as a passed test.

Objective

Produce an honest first-version observation sheet with reproducible defects and explicit untested areas.

Before you start

Keep the brief associated with the version being inspected.
Identify its starting state, objective, failure condition and retry behavior.
Prepare to record observations without marking untried cases as successful.

Steps

Inspect whether the opening scene communicates the immediate goal and relevant controls.
Perform the intended action and compare visible feedback with the expected state change.
Attempt an incomplete-objective or failure case that matters to the loop.
Retry after progress has accumulated and compare the reset state with the brief.
Repeat a failed sequence to distinguish a reproducible defect from an unclear observation.
Choose a narrowly scoped repair, then rerun both the failing sequence and a behavior that should remain unchanged.

Verification

Every recorded pass identifies an action and an observed result.
Untried devices, sequences and sharing workflows remain explicitly untested.
The normal completion path and a meaningful failure path are both represented in the sheet.
Retry is checked after changed state, not only immediately after opening the scene.
A repair note names both the desired difference and the behavior to preserve.

Limitations

The examples are proposed test cases rather than gameplay results obtained by Build Creator.
This first inspection does not replace broader accessibility, performance or release testing.
A locally correct attempt is not evidence that the published version, audience settings or private sharing are correct.

Working notes

Begin with the brief that produced the version you are inspecting. Turn its requested behaviors into observation rows: starting state, player action, expected feedback, observed result and next decision. Leave the observed-result column blank until you have tried the scenario.

A normal completion path is not enough. Try arriving at the goal before its prerequisite is satisfied, failing with progress already accumulated and retrying after completion. These sequences expose state that a fresh untouched scene cannot reveal. Choose cases relevant to the actual loop instead of collecting unrelated test ticks.

Keep local gameplay inspection separate from the status of sharing controls. You can describe the checks your version needs without assuming that every account has a particular invitation or private-link workflow. The dedicated Playtest guide owns that source-sensitive availability question.

Prioritize defects by what they prevent you from learning. If movement cannot reach the objective, decorative changes will not help assess completion. If retry keeps stale progress, inspect that before comparing difficulty between attempts. Preserve the current brief and the observed sequence before requesting a repair.

Examples

Test row to fill: Starting state—parcel waiting at pickup. Action—reach the depot without collecting it. Expected—objective remains incomplete and feedback explains what is missing. Observed—record the actual result. Next decision—leave unchanged if correct, or request a completion-condition repair with route layout preserved.
Regression sequence: collect the parcel, fail before delivery, retry, then inspect its starting location and carried status. This checks the transition between attempts rather than repeatedly testing pickup from a brand-new scene.
Evidence packet for a repair: brief or follow-up used, exact action order, expected state, observed feedback and whether the same sequence repeated the problem. Exclude account credentials and unrelated private information. A recorded sequence is more actionable than 'sometimes broken.'

Common questions

Does a generated playable scene mean the test passed?: No. It means there is a result to inspect. Compare the actions and state transitions with the brief, including failure and retry, before recording any behavior as passed.
Should I fix everything before testing again?: Repair the defect that blocks the next useful observation, then repeat its original sequence and check the preserved behavior. A large unrelated revision makes it harder to know which change affected the result.