Does 'preserve everything else' guarantee a safe edit?

No. It expresses intent but does not verify the result or create a rollback point. Name the important behaviors and check them after the revision.

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

Editorial review 2026-09-26

How to Preserve Working Features While Refining Build

Protect a working mechanic by naming its observable behavior before requesting an edit. Include a preservation clause in the prompt, then repeat the relevant interaction afterward; the clause itself is not proof that the behavior survived.

Objective

Attach verifiable preservation requirements to a bounded revision.

Before you start

Identify a behavior that currently matches the intended design.
Record how to reproduce that behavior from a known starting state.
Describe the proposed edit separately from its protected surroundings.

Steps

Write the requested difference without unrelated additions.
List observable invariants that the edit must preserve.
Check whether the requested change conflicts with an invariant and resolve that design ambiguity first.
Save the current brief and observation record.
Send the revision with its preservation boundary.
Repeat both the target check and the protected interaction, recording any regression.

Verification

Each preservation clause names behavior that can actually be inspected.
The requested edit and its protected boundary do not contradict each other.
The recorded regression sequence starts from the same meaningful state as the earlier observation.
A successful visual change is not treated as proof that collision or reset behavior stayed correct.

Limitations

This is a proposed editorial regression workflow, not a tested guarantee of generated edits.
Not every interface exposes version restoration; verify the available recovery controls before relying on them.
A prompt cannot replace a complete technical review of a complex project.

Working notes

Avoid preservation instructions that are too broad to inspect, such as 'keep everything good.' Describe the behavior you care about: a pickup counts only on first contact, falling returns to the active checkpoint, or Retry clears attempt progress. These statements can become concrete regression checks.

Separate the allowed edit from the protected boundary. Replacing a background should not silently alter collision bounds, the route or movement controls. If the requested visual change actually needs geometry changes, acknowledge that dependency instead of labeling the whole revision cosmetic.

Preserve evidence as well as instructions. Keep the original brief and a note of the interaction that currently behaves correctly. Use a project-copy or version feature only when it genuinely exists in the current workflow; prompt history and a preservation sentence are not substitutes for a recoverable version.

If a regression appears, record the smallest sequence that exposes it before sending another broad request. Chaining repairs without retesting can make it unclear which version last satisfied the protected behavior.

Examples

Preservation clause: Change the background palette and improve hazard contrast. Keep the platform positions, collision boundaries, movement controls and checkpoint activation behavior unchanged. Retest movement, checkpoint activation and falling after the visual edit.
Hypothetical regression note: Before the edit, falling after activating the checkpoint returned to that checkpoint. After the edit, the same sequence returned to the entrance. The requested change was background color only; investigate the changed respawn behavior without redesigning the route.
Boundary clarification: Making a doorway look wider may involve both art and collision geometry. Decide whether the passable opening should change before asking for the edit, then protect the intended traversal behavior explicitly.

Common questions

Does 'preserve everything else' guarantee a safe edit?: No. It expresses intent but does not verify the result or create a rollback point. Name the important behaviors and check them after the revision.