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

Editorial review 2026-09-26

How to Keep Version Notes for a Build Game

Keep version notes that join the requested change, the observed result and the decision to retain or revisit it. A note is a record of reasoning, not a backup or proof that a previous generated state can be restored.

Objective

Maintain a manual change record that supports testing and recovery decisions.

Before you start

Choose a consistent place to keep local notes.
Identify the current game state without relying only on memory.
Separate saved documentation from any confirmed recoverable project copy.

Steps

Record the current known behavior before a material edit.
Save the requested change and its preservation constraints.
Inspect the revised state and write the observed differences.
List regression checks actually performed and areas still untested.
Choose retain, investigate or redesign with a concrete reason.
Link the next revision to the unresolved observation rather than erasing the earlier record.

Verification

Each entry identifies the inspected state and its preceding change.
Expected behavior and observed behavior occupy separate fields.
The record does not claim unperformed regression tests.
Recovery notes distinguish real saved copies from prompt text.
A later reader can understand why the revision was kept or reconsidered.

Limitations

Manual notes do not create version control, a backup or a rollback feature.
Reusing an old prompt may produce a different result.
Only recovery controls actually available and tested in your workflow should be treated as recovery options.

Working notes

Give each inspected state a label you can recognize later. Record the prompt or action that produced it, what you expected and what you actually saw. Dates help order the record, but a date alone does not explain which game state was inspected when several revisions happened close together.

Write differences, not promotional release copy. 'Retry now returns to the entrance, but the parcel remains unavailable' is more useful than 'improved gameplay.' Include unchanged behaviors that you retested, especially when they were at risk from the edit. Leave untested areas explicit rather than implying the whole game passed.

Before a risky revision, record what you would lose if you abandoned the current state. Preserve the prompt, design rules and observations using controls actually available to you. If there is a genuine saved copy or export, identify it separately. Do not describe a prompt transcript as a complete recoverable project snapshot.

Use notes to decide the next action. Retain an edit when it satisfies the intended change without an unacceptable regression; investigate when the outcome is unclear; narrow or replace the design when repairs keep changing unrelated behavior. Notes make that decision traceable even when a direct undo path is unavailable.

Examples

Hypothetical version-note entry: label—courier retry revision; request—clear attempt checkpoint; expected—entrance spawn after retry; observed—entrance restored, parcel still absent; regression checks—movement unchanged; decision—retain the understood change and investigate parcel reset before expanding.
Pre-change inventory: preserve the current route description, prompt wording, completion rule and known defects. Record whether any actual backup or duplicate exists. 'I saved the prompt text' belongs under documentation, not under confirmed project recovery.
Comparison question: did this revision improve the intended reset behavior without changing the route? Read the observations for both states. If the earlier state was never tested, say the comparison is incomplete rather than reconstructing a successful baseline from memory.