BC-0176 · TROUBLESHOOTING
Editorial review 2026-09-26
Enemy Does Not Move in Roblox Build
A motionless enemy is not automatically broken. First establish whether it should patrol, react to an approach or remain still in the current phase. Compare its visible movement before and after the intended activation condition, then request the missing transition without inventing a pathfinding diagnosis.
Symptom
An enemy whose intended role includes movement remains in place.
Immediate action
Identify the intended movement mode and activation condition before changing speed.
Diagnostic branches
- No movement role was defined or stillness is intentional.
- Clarify the design instead of diagnosing a missing implementation.
- Other game activity is also stopped.
- Check the current phase or freeze state before an enemy-specific repair.
- The enemy animates but does not change location when its movement should be active.
- Request the intended traversal between observable locations.
- Movement should begin after an encounter trigger but does not.
- Describe that trigger and missing response without naming an unseen technical cause.
Least-destructive change
Restore the existing enemy's intended movement role without changing the entire encounter.
Retest
- Movement occurs in the intended phase and only under its defined activation condition.
- The enemy can traverse both intended route directions.
- Player controls and the original outcome rule remain intact.
Escalation
If safe observations cannot establish the trigger, keep the role/activation uncertainty explicit. A motionless enemy does not establish a specific AI, collision or navigation implementation.
Working notes
Name the enemy's intended role and movement trigger. A stationary turret, waiting guard and patrolling obstacle have different correct behavior. If the original brief only requested an enemy's appearance, decide the desired action before treating the lack of movement as an implementation failure.
Observe the enemy relative to a fixed landmark while the player remains in a safe position. Animation without changing location is not patrol movement. If other game activity is also stopped, investigate the round phase or freeze before changing this enemy's behavior.
For a conditional reaction, record whether the visible prerequisite was reached through ordinary play. Compare before approach, during the intended encounter and after leaving it if a safe route exists. Do not claim that an invisible detection radius or navigation mesh is defective; record only the expected reaction and actual position changes.
Keep a repair bounded to the enemy's role. Define a patrol between existing landmarks or a response within a clearly described encounter area, preserving the player's controls and the current outcome rule. Do not add more enemies to compensate for the original never activating.
Examples
- Role mismatch: the brief asked for a guard beside a doorway but never specified a patrol or chase. A stationary guard is not evidence that a requested movement system failed; define the intended role first.
- Proposed patrol repair: During active play, move the existing guard between the marked arch and crate, turning back at each endpoint. Keep its current appearance and the player's movement unchanged. Inspect both directions from a safe position.
- Activation record: round active / enemy role / expected trigger / enemy position before / position afterward / other scene activity. Unknown internal target selection stays unknown.