Studio / ROBLOX

角色为什么走不到终点：在 Studio 中检查 Pathfinding 路线

用一个小型练习院子，把路线计算问题与移动问题分开。先建立清楚的检查过程，再为游戏加入追逐或助手系统。

更新日期: 2026-10-08

为练习场景选择一个问题 #

设想一个独立测试院子：角色从左侧出发，右侧有标记好的目标区域，中间由两条通道连接。这是为你的项目设计的虚构练习，不是在说明本站作者的游戏已经拥有某个可用助手。第一个问题很简单：这个角色能否沿着宽阔、开放的通道到达目标？

启动前先记录起点、目标对象以及什么才算完成。第一轮练习暂时不加入奖励、追逐玩家或跨世界旅行。如果基础路线还解释不清，额外系统只会让排查更困难。把练习场景与正式关卡分开保存，后续每次修改也保留明确的版本说明。

查看可用空间 #

在 Studio 三维视图右上角打开 Visualization Options，启用 Navigation mesh。这个可视化功能帮助查看导航所考虑的空间。把它与院子对照：起点与终点之间是否有可辨认的连接？墙壁附近的边界在哪里？先记下观察，而不是立刻同时修改所有对象。

为自己的场景准备两个版本。第一版保留没有装饰物的宽通道，第二版增加一座低拱门。写清实际检查的是哪一版。导航网格是诊断线索；练习最终需要观察到角色抵达目标，而不只是得到一张漂亮的编辑器截图。

对照角色尺寸与通道 #

创建路线时使用的代理参数会影响能否通过现有空间。文档列出半径、高度和允许的动作。为练习选择一个角色和固定的一组参数。接下来只改变几何条件：加宽通道，或者移除拱门，再比较结果。不要把角色也同时换掉。

一次失败后，不必直接写“寻路坏了”。更有价值的记录是“有拱门时路线未确认，移除拱门后确认”。同时修改模型、宽度和设置，会丢失变化与结果之间的关系。用版本表记录每次唯一的修改，其他开发者才能重复你的观察并继续调查。

分开计算与移动 #

CreatePath 创建路线对象，ComputeAsync 在起点与终点之间进行计算，结果通过独立的 Status 属性判断。ComputeAsync 不会直接返回“角色已经到达”的确认。计算成功只是让你继续检查路线，并不等于整个游戏行为完成。

在日志里建立三个独立记录：计算、沿途推进、最终抵达。假如计算已确认，但角色仍停在起点，这与没有可用路线是不同问题。分开阶段后，你可以根据实际观察检查对应环节，不必同时改动整个系统。不要把成功计算的记录当成移动测试结果。

追踪路径点顺序 #

GetWaypoints 可以取得计算出的路径点。把这些点看作移动计划。在练习里用不同颜色标记起点和终点，并记录当前推进到哪一步。没有检查角色执行相应动作之前，不要把最后一个计算点描述成已经访问过的地方。

设想日志先显示取得路线，然后到达第一个点，但下一个点始终没有到达。记录停止位置并保存场景截图，这比“角色不走”更有帮助。同时说明项目中谁负责控制移动。官方页面的示例控制玩家角色，不能自动视为完整的服务器 NPC 控制系统。

在前方放置障碍 #

恢复已经成功的基础院子，再增加可移动箱子。首先记录通道开放时的经过情况，然后挡住角色尚未经过的一段。Path.Blocked 提供被阻挡路径点的索引；官方说明区分当前推进位置前方与后方的障碍。让你的试验也保持这一区别。

设计两轮独立练习。第一轮箱子阻挡接下来的移动，第二轮箱子关闭已经经过的部分。预期结果不应要求两种情况一律反应相同。练习要检查决策是否关注仍然相关的路线，而不是对院子里的所有变化都不加区分地重新处理。

描述失败后的行为 #

提前为项目选择找不到路线时的清楚行为：停下、记录开发者消息，或者条件改变后进行有限次数的重试。这属于项目设计，不是一次 API 调用自动带来的完整行为。不要在障碍完全不变时，把失败变成不停产生新计算的循环。

练习日志可以区分“路线确认”“计算未确认”和“检查发生错误”。为每个状态写出下一步。拱门仍然过低时，原样重复练习不会提供多少新证据。目标被替换后，还要检查旧移动和旧事件处理是否仍在替新路线作决定。

在正确的运行环境检查目标 #

开启 streaming 时，客户端可能没有世界中的部分内容，因此目标对象的访问需要单独考虑。文档说明服务器的世界视野与客户端对象可见性之间的区别。这并不表示所有动作都必须放在同一处：先明确你的系统实际在哪里运行。

在练习说明卡写明移动逻辑由谁运行，以及目标坐标来自哪里。分别检查目标可用与目标数据尚未准备好的版本。不要为了消除错误而随意替换终点。等待阶段应有清楚解释，不能把尚不可用的目标报告为已抵达。

区分规划穿门与真正开门 #

带有 PassThrough 的 PathfindingModifier 可以允许规划经过某个障碍。这不等于门自动打开，也不等于角色立即获得穿过它的物理能力。文档把这类方法用于更复杂的场景；具体游戏动作仍然需要实现并验证。

基础院子练习先不加入门。以后增加门时，分别记录两项检查：路线选择预期的一侧，门的机制确实允许通过。闭合物体后方出现一条路线线段，不是实际通过的证据。楼梯、船只和其他特殊连接，也可以采用这种分层检查思路。

版本	记录内容
开放院子	计算、推进和抵达
低拱门	与基础场景的差异
前方箱子	对尚未经过部分的反应
后方箱子	对已经过部分的反应

交付可重复的结果 #

保存一张简短说明卡：练习场景名、角色、代理参数、起点和目标坐标，以及最后一次试验的唯一变化。附上计算、推进和抵达的独立观察。补充自己项目的基础通道与问题版本截图，不要把他人的图片当作你已测试的证明。

本文提供检查计划，不是已完成的 NPC 控制器。我们没有在 Studio 中运行你的场景，也没有确认它的行为。实现后重新进行这一小组练习，包括前方与后方的箱子。再把检查过的方案带入拥有更多角色、障碍和目标的大关卡。

观察	下一项检查
计算未确认	几何与参数
有路线但不移动	移动控制者与阶段
在路线中停止	位置与场景变化
目标已替换	旧路线与处理器

原始资料

Roblox Creator Hub — Pathfinding
Roblox Creator Hub — Path API