BC-0259 · TROUBLESHOOTING
Editorial review 2026-09-27
Restart Is Frustrating in Playtest
A frustrating restart can work correctly yet require too much repeated effort before the next meaningful attempt. Trace the path from outcome to restored control, repeated setup and renewed decision. Remove avoidable repetition without removing consequences, instruction or intentional challenge.
Symptom
A technically functioning restart makes the next meaningful attempt burdensome or confusing.
Immediate action
Map the path from outcome to the next decision and separate broken state from repeated setup.
Diagnostic branches
- The new attempt is impossible because required state is wrong.
- Use reset-correctness diagnosis before tuning the return flow.
- Repeated setup contributes no useful decision or teaching.
- Propose a shorter return while preserving the intended challenge.
- A shortcut would remove an intentional consequence.
- Resolve the design tradeoff explicitly rather than treating convenience as automatically correct.
Least-destructive change
Remove an evidenced friction point without erasing progression rules or replacing the entire retry system.
Retest
- The player reaches the intended next decision with usable controls.
- Required reset and retained states still follow the design.
- A repeated-player improvement does not silently remove necessary first-use guidance.
Escalation
Use an observed retry sequence for a bounded revision; if no unnecessary step is identified, retain the design question rather than promising that a shorter round will fix frustration.
Working notes
Separate correctness from cost. A retry that leaves a required collectible missing is a reset defect. A retry that restores the proper state but repeats a lengthy introduction is a flow problem. Fix the broken state first; making the retry faster cannot repair an impossible next attempt.
List what the player must do again: dismiss a result, locate the retry action, repeat instruction, travel through solved space and finally reach the failed decision. Mark which steps teach or test something and which merely replay already-understood setup. Do not measure frustration solely by counting button presses.
Choose the smallest change that preserves the intended consequence. Bringing the player closer may be appropriate, but removing a meaningful resource cost or bypassing the learned obstacle changes the game. Define what must reset, what remains earned and what challenge must still be faced before requesting a revision.
Retest from both failure and completion where relevant. A shortcut that helps repeated practice should not accidentally skip the opening goal for a newcomer or leave outcome controls covering play. Record familiarity, because repeated testers know setup that newcomers may need.
Examples
- Flow map: fail → read outcome → retry → repeat a solved corridor → reach the same jump. If the corridor adds no new decision, consider shortening the return while retaining the jump's intended difficulty.
- Tradeoff: automatically retaining a key might reduce repetition but remove the intended risk of carrying it. Resolve that design consequence instead of calling every retained item a usability improvement.