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

Editorial review 2026-09-27

Playtest Feedback Is Too Vague

When feedback is vague, classify what the comment could mean before turning it into a change. Ask for the moment, expected outcome and observed difficulty without supplying the answer. If the person cannot recall a concrete event, keep the comment as an opinion rather than inventing a bug report.

Symptom

A feedback comment expresses a rating or solution without enough observable context to guide a repair.

Immediate action

Separate opinion, suggestion and event evidence before deciding whether a change is justified.

Diagnostic branches

The person can identify a concrete moment.: Record their action, expectation and visible outcome in their own terms.
Only a proposed solution is supplied.: Ask what difficulty the solution would address rather than assuming it is required.
No concrete event is recalled.: Keep the opinion and plan a focused future observation without inventing a defect.

Least-destructive change

Delay the generation request until the feedback supports a testable question.

Retest

The record distinguishes the tester's observation from the creator's interpretation.
Leading or coached answers are not presented as independent understanding.
A preference is not mislabeled a reproducible bug.

Escalation

When evidence remains weak, retain the uncertainty and use the task-based feedback guide for a future session instead of repeatedly spending prompts on speculative fixes.

Working notes

Separate an evaluative word from its possible evidence. 'Confusing' might mean the goal was unclear, the control label was misleading or success was not signaled. Ask where the uncertainty occurred and what the person tried. Do not choose the interpretation that happens to support your planned revision.

Distinguish observed difficulty from a proposed solution. 'Add arrows' is a design suggestion; 'I walked past the depot because I thought it was decoration' is an observation that can support several repairs. Preserve both, but connect a revision to the observation rather than treating the suggestion as a requirement.

A missing memory is a legitimate endpoint. If a tester only recalls disliking the pacing, record that preference and offer a focused future task through an available authorized path. Do not repeatedly interrogate them until they agree with a leading explanation, and do not report that later coached interpretation as their original experience.

Before requesting a change, state the remaining uncertainty. A comment tied to an actual task may support a narrow hypothesis; an unsupported rating does not. Retest the relevant task after a revision and label returning testers as familiar with the game.

Examples

Neutral follow-up: 'Where were you when you first felt unsure, and what did you expect to happen next?' This asks for context without telling the person the intended route.
Evidence split: suggestion—make the button larger; observation—finger hit the adjacent control. The underlying question is target separation, not automatically global button size.