试玩时角色能走到目标旁边却完不成条件,多数情况不是碰撞检测本身失效,而是规则输入里某一环没对上:触发对象绑到了别的角色、条件引用了场景里并不存在的变量、或者表达式写法让条件恒为假。先别急着改碰撞体,回到规则编辑区,按「触发对象 → 变量名 → 条件表达式 → 最小场景 → 现象分类」这个顺序逐项核对,通常能在几步内判断到底该改绑定、改变量名,还是改条件。
碰撞不触发的排查顺序建议是:先在规则里确认触发对象绑定到正确角色,再核对该条件用到的变量名是否存在于场景变量列表且已初始化,然后用只含一条规则的最小场景复测,最后用通用表达式骨架分别试玩成功与失败各一次。适用场景是可配置规则、可看变量列表的试玩编辑器;验证方式是页面行为加变量取值观察,不是性能结论。若这些都对齐仍不触发,需要结合编辑器的碰撞层、触发时机与事件顺序再确认。
下面这张检查顺序表可以先照着走一遍,每一步都对应一个「看什么」和「常见误判」,不要跳步,也不要一次改多处。
| 顺序 | 检查点 | 看什么 | 常见误判 |
|---|---|---|---|
| 1 | 触发对象绑定 | 规则里选中的对象名称 | 绑到了道具或空物体,角色没被算作触发方 |
| 2 | 变量名一致 | 条件里的变量名与场景变量列表 | 拼写、大小写、中英文、前后空格不一致 |
| 3 | 条件表达式 | 比较符、阈值、是否取反 | 用了“等于”却期望“大于等于” |
| 4 | 最小场景复测 | 只剩这一条规则时是否触发 | 被其他规则或触发器抢先改状态 |
| 5 | 现象分类 | 不触发 / 触发多次 / 触发后不重置 | 把三种问题当成同一种修法 |
在规则编辑区确认触发对象是否绑定到正确角色
这一步用来排除「对象绑错导致的假性失效」。做法很直接:把规则里选择的触发对象名称抄下来,和场景中的角色、道具命名逐个核对。很多试玩编辑器里,角色由父节点加若干子碰撞体组成,规则面板里能选到的是其中一个节点,绑到不参与碰撞的子节点,就会出现走得动但不触发的现象。
建议建一张对照记录,边看边填,不要凭记忆:
| 规则里的触发对象名称 | 场景中实际角色/物件命名 | 是否一致 | 备注 |
|---|---|---|---|
| (照抄规则面板显示名) | (照抄场景层级列表名) | 是 / 否 | 大小写、空格、中英文标点 |
| 主角碰撞体 | Player / 主角 / 角色_01 | 是 / 否 | 是否为带碰撞体的那一层 |
如果规则支持「主体 / 客体」或「进入对象 / 离开对象」两栏,需要确认哪一栏放的是移动角色、哪一栏放的是目标物件。字段名以页面实际可见为准,不要把别处的叫法硬套进来。核对一致后再进下一步,否则后面查变量会白费功夫。
检查触发条件里的变量名与场景实际变量是否一致
变量名不一致或未初始化,是第二类高频原因。把规则条件里出现的变量名全部列出来,和场景变量列表做一次对照,标出不存在的变量,以及存在但初始值可疑的变量。
| 条件中的变量名 | 场景变量列表是否存在 | 类型 / 初始值 | 处理 |
|---|---|---|---|
| (照抄条件原文) | 存在 / 不存在 | 数值 / 布尔 / 文本,初值多少 | 改名对齐或新建变量 |
| 已接触 | 不存在 | — | 改名为场景中真实存在的变量 |
| 分数 | 存在 | 数值,初值未设 | 给一个明确初始值,否则比较可能恒为假 |
未初始化的变量,取值可能是空或按默认规则落到某个值,条件比较时容易一直不成立。可以先给它设一个明确初值,再在试玩里观察取值变化。另外,条件里如果同时用了两个变量做比较,要确认两者类型一致,数值和文本混比通常会静默失败。
单独建一个最小场景只测这一条碰撞规则
当上面两项都对齐仍不触发,建议另建一个最小场景,把干扰项全部去掉。最小场景通常只需要:
- 一个可移动的角色,带可参与碰撞的碰撞体;
- 一个目标物件,同样带碰撞体,位置放在角色能走到的地方;
- 一个场景变量,用于记录是否发生接触(例如「已触发」);
- 一条规则:触发对象指向目标物件,条件是对该变量的比较,动作是把它置位。
不要在这个场景里加计时器、加其他触发器、加多段分支逻辑。只保留这一条规则的好处是,触发与否只可能由这一条规则的对象、变量或条件决定,排查范围立刻收窄。如果最小场景能触发,说明问题出在原场景的其他规则或状态竞争上;如果最小场景也不触发,说明对象绑定或条件写法本身有问题,回到前两步继续核对。
给出通用规则表达式骨架并用试玩验证
在拿不到可靠的接口或字段说明时,可以先写一个只含三段占位符的通用骨架,字段名以你页面上实际看到的为准,再逐个填空:
规则 {
触发对象: <场景中可见、且带碰撞体的对象名,例如 主角 / 目标道具>
触发条件: <变量名> <比较符> <值 或 另一变量>
触发动作: <设置变量 / 播放表现 / 切换状态>
}
示例(字段名仅示意,需替换为页面实际名称):
触发对象: 目标道具
触发条件: 已触发 == 否
触发动作: 已触发 = 是
填好后分别做两次试玩并记录,不要只测成功的一次:
- 让角色走到目标物件上,记录本次是否触发、变量取值变成多少。
- 把条件改成一个明显不成立的值(例如把比较结果调成不可能满足的方向),再走一次,记录是否不触发。
两次记录对照,能区分「规则根本没生效」和「规则生效但条件判定不对」。如果第一次触发、第二次仍触发,说明条件没有真正参与判定,需要回到变量名和比较符再查。
把不触发、触发多次、触发后不重置分开记录
这三类现象看起来都像「碰撞有问题」,但优先修改的字段完全不同,混在一起改容易越改越乱。建议按下表分开记录,每次只改一类。
| 现象 | 典型表现 | 优先检查/修改的规则字段 |
|---|---|---|
| 完全不触发 | 走到目标上没有任何反应 | 触发对象绑定、条件变量是否存在且已初始化 |
| 触发多次 | 一次接触里计数跳了多次,或重复播放表现 | 触发时机(进入 / 持续)、是否有去重标志、是否按帧反复判定 |
| 触发后不重置 | 第一次能完成,之后再也触发不了 | 重置条件、离开事件、把状态变量归零的动作 |
记录时把时间、先后顺序和当时的变量取值一起写下。触发多次的问题通常出在「持续判定」被当成「一次判定」,触发后不重置的问题通常出在缺少离开事件或缺少把状态变量改回初始值的动作。分开记录后,每一步只动一个字段,再试玩一次确认,比一次性改绑定又改表达式更容易定位。