BC-0170 · TROUBLESHOOTING
Editorial review 2026-09-26
Player Cannot Move in a Build Game
If the player cannot move, first determine whether the character stays fixed relative to the scene, is blocked only in a particular location, or appears stationary because the camera follows it. Compare a safe open area with the original failure when possible; do not assume every movement complaint is a broken control.
Symptom
The player appears unable to travel despite an intended movement action.
Immediate action
Compare the character with a scene landmark and establish the active game phase.
Diagnostic branches
- Landmarks move relative to a centered player.
- Recognize observed travel and investigate camera expectations separately.
- Movement works in open space but fails at a particular passage.
- Describe that route boundary without inventing an internal collision diagnosis.
- All harmless controls are unresponsive.
- Use the broader input or freeze investigation instead of a movement-only repair.
- Only movement is absent during an established active phase.
- Request the specified directional response while preserving other working actions.
Least-destructive change
Isolate the movement location or phase before altering the whole map or control scheme.
Retest
- Actual travel is judged against a visible landmark.
- The repaired passage works on approach and return while surrounding boundaries still block as intended.
- Existing jump or other harmless input behavior is preserved.
Escalation
Keep the location, phase and relative-motion evidence when a scoped repair fails. A stationary screenshot cannot establish a particular physics setting, script defect or unsupported input device.
Working notes
Use a fixed landmark on the playable route to judge position, not scrolling decoration or a parallax background. Camera motion, an animated walk cycle and actual travel are separate observations. If the player passes the route's doorway while remaining centered in the view, record that travel rather than judging only screen coordinates.
Check whether the game has reached an active phase and whether another harmless action responds. An end panel or intentionally inactive start state can explain why movement is not expected yet, but only if the game's actual rule establishes that state. Do not infer a pause mechanic solely from a stationary character.
If ordinary play already provides a safe open space, compare the same movement input there with the blocked location. Movement that works away from a doorway narrows the defect to that passage or state; it does not prove which collision property is wrong. If no open area can be reached safely, record that limitation instead of editing the scene for a test.
A useful repair describes the passable route or movement transition and protects unrelated behavior. Preserve jump response, goal placement and working boundaries unless the problem requires changing them. Test opposite travel and returning through the same passage so the result is not only a successful entrance.
Examples
- Landmark comparison: the player remains centered but passes an actual doorway on the playable route during input. That provides route-relative evidence; decorative background movement alone would not establish the same result.
- Localized problem: movement works in the starting area but stops at the visible open doorway. Proposed request: Make the intended doorway traversable in both directions while preserving walls outside the opening, movement speed and the goal location.
- Movement record: active phase / reference landmark / direction requested / relative travel observed / location where travel stops / other harmless action response. A walk animation without relative travel remains a different observation.