Unity3D 解决检测碰撞某类物体的一种方法

目录

前言

启发

实现前的失败案例

实现

总结

思考 

后言

---

前言

        2022年十月份报名参加了Unity和Bilibili联合举办的NewbiesJam游戏开发挑战。在处理不同物体之间的碰撞逻辑时，由于自身知识浅薄，选择了使用Tag去判断触碰了哪一个物体，这就导致了随着物体类型的增加，不单是Tag，写在OnColliderEnter、OnColliderExit、OnColliderStay等等等等方法里面的语句也会越来越庞大臃肿，并且一旦物体的Tag没有进行标识，编写的碰撞逻辑就会失效。

        在学习 《Unity3D 网络游戏实战（第2版）》这一本书时，Server在分发接收到的网络消息时，会根据消息的协议名，通过反射的方式从MsgHandler获取与协议名同名的方法，在自定义需要传入的object[]类型的参数列表parameters后，通过Invoke(null,parameters)的方式传入参数并且执行方法。

服务端

NetManager分发消息

1.  
   public class NetManager
2.  
   {
3.  
    
4.  
   public static void ReadClient()
5.  
   {
6.  
   ....
7.  
    
8.  
   //假设收到的协议消息
9.  
   MsgBase msg = new MsgMove();
10.  
     
11.  
    //从MsgHandler获取和协议同名的方法
12.  
    MethodInfo mi = typeof(MsgHandler).GetMethod(msg.protoName);
13.  
     
14.  
    //定义需要传入的参数列表
15.  
    object[] o = {state,msg}
16.  
     
17.  
    //执行同名方法,并传入参数
18.  
    mi?.Invoke(null,o)
19.  
     
20.  
    ....
21.  
    }
22.  
     
23.  
    }
24.  
     

MsgHandler消息处理

1.  
   public partial class MsgHandler
2.  
   {
3.  
   public static void MsgMove(SocketState state,MsgBase msgBase)
4.  
   {
5.  
   //向下转型还原为MsgMove类型
6.  
   MsgMove msg = (MsgMove)msgBase;
7.  
    
8.  
   //通过msg的内容执行其他逻辑
9.  
   ........
10.  
    }
11.  
    }

---

启发

        在检测物体之间的碰撞时，一般都是两个挂载有脚本的物体进行检测，那么是否可以在OnCollisionEnter方法中，一旦某个物体进入了Collider，就尝试检测这类物体是否是自己要监听的类型，通过GetComponent方式尝试获取物体的某一类脚本，如果获取的结果不为空，则触发相应的方法。

---

实现前的失败案例

        假设有两类物体。一类物体挂载类型为人物（BaseCharactor）的脚本，并且带有Rigidbody。另一类物体挂载类型为格子（Node）的脚本。当人物走到某类格子上时，双方都会触发OnCollisionEnter(或OnTriggerEnter)。

以人物（BaseCharactor）为视角

        现在有这样一个情景，玩家控制的人物（CtrlPlayer,继承于BaseCharactor）走到陷阱类型（TrapNode，继承于Node）的格子上时会死亡，走到泥地类型（MudNode，继承与Node）的格子上时速度会变慢。

        为了检测双方，我添加了三个Tag，分别是CtrlPlayer、TrapNode和MudNode。在Node物体进入玩家的Collider的时候，触发了玩家的OnCollisionEnter，此时如果要实现触碰到不同格子实现不同的方法，我一开始是这么写的：

1.  
   public class CtrlPlayer:BaseCharactor
2.  
   {
3.  
   private void OnCollisionEnter(Collision collision)
4.  
   {
5.  
   if（collision.gameObject.tag == "TrapNode"）
6.  
   {
7.  
   //玩家死亡
8.  
   .....
9.  
   }else if(collision.gameObject.tag == "MudNode")
10.  
    {
11.  
    //玩家速度变慢
12.  
    ....
13.  
    }
14.  
    }
15.  
    }

        典中典。

        当我准备继续加不同类型的角色和格子的时候，我就开始发现Tag真的越来越多了，在OnCollisionEnter里面的if-else语句也越来越多。所以现在存在两个问题:

1. Tag太多
2. if-else语句太多。

解决Tag太多

        后来我改成了只使用两个Tag，BaseCharactor和Node。然后我的逻辑就变成了这样：

1.  
   public class CtrlPlayer:BaseCharactor
2.  
   {
3.  
   private void OnCollisionEnter(Collision collision)
4.  
   {
5.  
   if（collision.gameObject.tag == "Node"）
6.  
   {
7.  
   OnNodeEnter(collision.transform.GetComponent<Node>());
8.  
   }
9.  
   }
10.  
     
11.  
    private void OnNodeEnter(Node node)
12.  
    {
13.  
    if(node.NodeType == Node.NodeType.Trap)
14.  
    {
15.  
    //玩家死亡
16.  
    ....
17.  
    }
18.  
    else if(node.NodeType == Node.NodeType.Mud)
19.  
    {
20.  
    //玩家移速变慢
21.  
    ...
22.  
    }
23.  
    }
24.  
    }
25.  
     
26.  
    public class Node:Monobehaviour
27.  
    {
28.  
    public enum NodeType
29.  
    {
30.  
    Normal,
31.  
    Trap,
32.  
    Mud,
33.  
    ....
34.  
    }
35.  
    }

        新典中典。

        这个时候Tag确实减少了，但是依旧没有减少if-else语句，并且甚至在添加新的Node或Charactor的时候需要维护NodeType。于是在这个时候，我灵光一闪想到了前面所提到的使用反射，通过名字获取方法并且调用。

---

实现

        这个是我在开发挑战中使用的方法，这一方法在我看来仍然不够好，但已经非常足够我的项目去使用，并且解决了一定关于if-else的问题。

 以人物（BaseCharactor）为视角

      由于项目很小，我没有去考虑性能的开销问题，因此我把检测格子的逻辑直接写在了BaseCharactor里，如果希望一些角色不去检测格子（比如场景中不断飞，用来装饰的鸟），在鸟的类中重写OnCollisionEnter就好了。

1.  
   public class BaseCharactor:Monobehaviour
2.  
   {
3.  
   protected virtual void OnCollisionEnter(Collision collision)
4.  
   {
5.  
   //声明Node对象
6.  
   Node node;
7.  
   //获取碰撞对象身上挂载的Node组件
8.  
   node = collision.gameobject.GetComponent<Node>();
9.  
    
10.  
    //如果结果不为空，说明对象身上挂载有Node类型脚本
11.  
    if(node != null)
12.  
    {
13.  
    //获取脚本类型名字，如果是TrapNode名字就是TrapNode，如果是MudNode名字就是MudNode
14.  
    string name = node.GetType().Name;
15.  
     
16.  
    //获取同名方法
17.  
    MethodInfo mi = this.GetType().GetMethod($"On{name}Enter");
18.  
     
19.  
    //定义需要传给方法的参数,参数包括了参与碰撞的双方
20.  
    object[] o = {this,node};
21.  
     
22.  
    //如果方法存在，则执行
23.  
    mi?.Invoke(this,o);
24.  
    }
25.  
    }
26.  
     
27.  
    public void OnTrapNodeEnter(BaseCharactor actor,Node node)
28.  
    {
29.  
    //角色死亡逻辑
30.  
    ...
31.  
    }
32.  
    public void OnMudNodeEnter(BaseCharactor actor,Node node)
33.  
    {
34.  
    //角色移动速度变慢
35.  
    ...
36.  
    }
37.  
    }

        通过尝试获取进入物体的Node脚本，如果获取到了就通过Node类型脚本的名字，去执行On<脚本名字>Enter方法。        

        这一方法不仅直接不使用Tag去检测，并且直接从表层面上消除了if-else语句，看上去舒心很多。并且子类可以重写检测方法，实现不同的逻辑。

---

总结

        这一方法适用于检测的大类别不怎么变化的情况。我的作品中，格子（Node）只需要检测人物（BaseCharactor），人物也只需要检测格子，只需要考虑了不同的人物走到不同的格子所触发的逻辑。如果检测的类别越来越多，比如还需要检测是否触碰了物体（Item），是否触碰到了场景中可以交互的建筑（Architecture），这个时候就需要往OnCollisionEnter等检测方法添加新的逻辑了，会违反开闭原则。

        使用这一方法后，在检测物体触发碰撞时候，只需要类中添加方法On<想要检测对象的类型>Enter就好了。假设旱鸭子(Landlubber,继承BaseCharactor)走到了水格子（WaterNode,继承于Node），只需要在Landlubber类中添加方法OnWaterNodeEnter，就会在进入水格子的时候触发OnWaterNodeEnter。由于使用了mi.?Invoke()方式去触发方法，会在触发前判断是否有这一方法存在，否则就不触发。所以当检测到了WaterNode，类中没有OnWaterNodeEnter这一方法也没有关系。

---

思考 

        关于由于如果检测的大类频繁地修改的话，会违反开闭原则的事情，有一个想法是给物体声明一个检测列表List<Type>，在开始时把需要检测的物体的脚本基类添加在里面就好了。在OnCollisionEnter等检测方法中把List遍历一遍就知道进入的物体是不是希望被检测的了。但是这样的话，mi.Invoke（）传入的参数就不能够变化了。

        另外，使用反射这一方式是否会有什么不安全的情况吗？我对C#的了解还是过于浅薄，只是这一方式确实对我的游戏开发起到了帮助。

---

后言

        我的NewbiesJam开发挑战的作品《Shadow》链接在这里：

        【萌新开发挑战 NewbiesJam】 作品《Shadow》试玩视频_哔哩哔哩bilibili

        因为只有一个人并且只有七天的时间开发，所以无论是美术还是玩法都十分的简单（好像看上去甚至和挑战主题不搭边，这就要看评委怎么理解了哈哈哈哈哈）。简介还有试玩链接可以试玩（Unity的云渲染有时候会卡住玩不了），欢迎来试试我的游戏。

        欢迎提出问题和修改意见！

这篇好文章是转载于：学新通技术网