BC-0249 · TROUBLESHOOTING
Editorial review 2026-09-27 · Official sources conflict
Playtest Feels Different From the Build Preview
For a discrepancy between creator and recipient inspection, compare the same project marker, starting state, input action and outcome. Change context alone only after the other conditions are matched. A difference is a useful observation, not proof of a hidden runtime or server defect.
Symptom
The same intended action appears to produce different outcomes in creator and recipient inspection contexts.
Immediate action
Match project marker and starting state before attributing the difference to the testing environment.
Diagnostic branches
- The visible project marker differs.
- Investigate identity or version before gameplay context.
- A prerequisite or starting state differs.
- Match it safely if possible or retain an explicitly unmatched comparison.
- State changes match but feedback differs.
- Investigate the cue or interface boundary without assuming the game rule failed.
Least-destructive change
Preserve both observations and avoid speculative game rewrites or unsupported environment settings.
Retest
- Input method and game action are recorded separately.
- A failed comparison is not presented as matched evidence.
- The reported discrepancy does not become an unsupported runtime, persistence or multiplayer claim.
Escalation
Escalate a minimal paired case with actual conditions and outcomes when unresolved. Omit guessed internal causes and private recipient information.
Working notes
First confirm that the comparison is about the same actual result. If a visible revision marker differs, use version-freshness diagnosis. If the marker agrees, record starting conditions such as collected items, checkpoint activation, an open menu or an already-completed goal before comparing the action.
Express the action in game terms as well as input terms. 'Move toward the depot' can use different inputs; 'tap this displayed control' tests a particular interface. A mouse action on a large screen and a touch action beside an overlay are not identical tests of control reachability. Record that difference rather than treating it as a mysterious environment change.
Compare observable boundaries: input acknowledged, required state met, game state changed and feedback shown. If both contexts change state but only one shows the cue, investigate feedback. If the prerequisite differs, restore an equivalent legitimate starting condition where safely possible; otherwise label the comparison unmatched.
Do not infer persistence, networking, multiplayer support or editor-only behavior from a discrepancy. These are hypotheses requiring evidence. Keep a minimal paired report with the same intended action and the difference actually observed, and avoid content edits until the comparison supports a bounded question.
Examples
- Unmatched test: the creator already carries the parcel, while the recipient approaches the depot empty-handed. Different delivery outcomes do not establish an environment defect.
- Matched-rule, different-interface example: both reach the same state, but the recipient's touch target is covered by a panel. Investigate control reachability before rewriting delivery logic.
- Paired record: project marker / entry context / starting state / game action / input method / acknowledgement / state result / visible cue / unresolved mismatch. Mark unavailable comparisons honestly.