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

Editorial review 2026-09-26

Prompt Accidentally Made the Game Harder

If a revision unexpectedly makes a previously playable segment harder, compare the same scenario before and after the change. Look for a lost opportunity—less warning, an obstructed route, an unavailable response or a reduced recovery margin—before increasing health or weakening every challenge.

Symptom

A previously observed response becomes unreliable or unavailable after a revision intended to change something else.

Immediate action

Locate the first lost opportunity in a comparable before-and-after scenario.

Diagnostic branches

A new visual or geometry change obstructs an existing cue or route.: Restore access to the intended response before broadly reducing difficulty.
The response remains possible but its intended margin changed.: Specify that changed relation while preserving unrelated improvements.
The comparison uses different players or starting conditions.: Keep the regression conclusion uncertain rather than claiming the prompt caused it.

Least-destructive change

Restore the lost response opportunity without weakening every later challenge.

Retest

The original response is observable under comparable conditions.
The desired recent improvement remains where compatible.
Untested later segments and familiarity differences stay explicit.

Escalation

Keep the opportunity comparison and any real restoration tradeoff. Do not claim a measured difficulty increase or a lossless rollback without evidence.

Working notes

A difficulty regression needs comparable evidence. Note what the recent request was meant to improve and which earlier route or response was observed to work. A less familiar tester, different starting condition or later segment cannot by itself establish that this prompt increased difficulty.

Trace the opportunity the player lost. Added decoration may hide a warning; an enlarged obstacle may remove a safe landing; an interface panel may prevent the needed action. Those are correctness or readability regressions, not reasons to rebalance the whole game around the obstruction.

If the opportunity still exists but its authored margin changed, identify the changed relation precisely. Keep the desired new appearance or mechanic while restoring the intended warning-to-response relationship where possible. Do not prescribe a universal speed or success rate, and do not require repeated frustrating attempts to prove the same observation.

A real restore option may revert more than difficulty. Compare the loss of the intended improvement with the scope of a targeted repair before using an available recovery action. A history entry does not establish exact-state rollback and does not guarantee recovery.

Examples

Hypothetical regression contrast: the player previously saw the route warning before entering a narrow passage; the requested foliage now covers that warning. Preserve the foliage concept while restoring the readable approach cue, rather than awarding extra health to compensate.
Comparable record: same segment and starting state / previous usable response evidence / intended revision / first lost opportunity / useful new feature to retain / unavailable comparison clearly marked.