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

Editorial review 2026-09-27

Should You Playtest After Every Build Prompt?

Inspect the actual result after a completed Build revision, but choose the test scope from what changed and what it could affect. A label edit and a core state-rule change need different checks. Do not carry previous passes into changed behavior or repeat an entire suite blindly after every message.

Symptom

The creator is unsure how much testing a completed revision needs before another change or release.

Immediate action

Write the actual change and nearby protected behavior, then select checks from the affected paths.

Diagnostic branches

The change is narrowly presentational and behavior appears unchanged.: Inspect the real displayed context and truthfulness without claiming unperformed broad tests.
A state rule or connected path changes.: Check dependencies, invalid cases and return behavior relevant to that rule.
The output changed beyond the requested scope.: Expand coverage according to the observed differences and retain untested gaps.

Least-destructive change

Inspect a completed candidate before another speculative prompt; do not interrupt active generation to satisfy a test schedule.

Retest

Coverage follows actual output rather than only the requested edit.
Historical passes are not silently transferred to a changed candidate.
The record distinguishes targeted checks from broader release checks.

Escalation

Use the full gameplay checklist when changes affect core behavior or combine into a release candidate. No fixed message cadence or universal amount of testing is promised.

Working notes

Begin with an impact statement: requested change, actual observed change and protected nearby behavior. Generated output can differ from the request, so the test scope should follow what is present rather than the prompt alone. Keep unfinished or still-changing output separate from a candidate ready to inspect.

Select the changed path and its immediate dependencies. A depot relocation affects reachability, delivery contact and route guidance; a completion rule can affect invalid attempts, repeated triggers and retry. A spelling correction needs its displayed context checked, but it does not automatically justify claiming all gameplay was retested.

Escalate coverage when the observed change spreads beyond the intended scope, when a core rule changes, or when a release candidate brings several revisions together. If something important cannot be inspected, record the gap and avoid presenting it as a pass. Testing cadence is a risk decision, not a fixed prompt count.

Keep the record version-specific. A previous successful movement test can remain historical evidence but does not prove movement in an altered scene. Use the existing checklist for broader checks and maintain a short delta record for the specific revision.

Examples

Scoped check: a control label is clarified; inspect the displayed label, whether it fits and whether it still describes the actual action. Do not mark unrelated devices or game rules passed.
Expanded check: a retry change unexpectedly relocates the player and alters carrying feedback. Include the route, collectible availability and completion path rather than testing only the requested panel.