为什么动作影响了不该影响的对象
官方文档专门用一整页讲对象拾取(object picking),并提醒「不理解时它是困惑的根源」。这个机制吃透了,事件逻辑才算入门。
拾取是什么
写动作时选了「Enemy」这个对象,引擎要回答一个问题:场景里那么多 Enemy 实例,动作作用于哪一个? 默认答案是「全部」;但只要事件里出现了涉及 Enemy 的条件,答案就变成「条件筛出来的那些」。这个筛选过程就叫拾取。
条件:Player 与 Enemy 碰撞
动作:删除 Enemy ← 只删除正在碰撞的 Enemy
动作:把 Variable(Score) 加 1
碰几个删几个,其余的 Enemy 不受影响——因为条件只拾取了碰撞中的实例。
筛选结果在事件内传递
同一事件内(含其子事件),拾取结果向后传递:
- 前面的条件筛掉了部分实例,后面的条件只在剩下的实例里继续筛;
- 动作、子事件看到的都是「最终筛选名单」。
推论:把「距离小于 100」写在「血量小于 0」后面,效果与顺序无关(都在筛同一批);但把「删除对象」写中间,后面的条件就没东西可筛了。
跨事件不传递
拾取结果只在单条事件内有效。下一条事件重新开始:没有条件就作用于全部实例。想让 A 事件记住的对象在 B 事件里用,惯用手段是:
- 用一个全局/场景变量存下对象的关键信息(如编号、坐标);
- 或在 B 事件里用等价条件重新拾取一遍。
手动拾取的几个手段
| 需求 | 手段 |
|---|---|
| 只处理离玩家最近的一个 | 条件「按距离排序取最近的 Enemy」 |
| 编号固定的那个 | 实例变量 + 「变量等于 N」条件 |
| 恢复成「全部实例」 | 用「对每个对象事件」逐个处理,或避免在事件里加筛选条件 |
| 排除已处理的 | 打实例标记(布尔实例变量),条件里过滤 |
调试拾取问题最快的办法:开调试器(见 调试器:揪出变量和性能问题),实时看实例数量与变量值,对比「你以为的名单」和「实际被改的对象」。
- 上一页:条件与动作怎么组合才不出错
- 下一页:变量入门:记住分数血量和玩家名字