Unity碰到的坑小结

Unity碰到的坑小结

很久没有记录坑了，做一个小结水一期

• 物理系统的优劣
  这次接手上一个人的项目，物体在轨道上移动的方式人 他全都用别人写好的带脚本的资源来实现，而该实现是完全使用Unity物理系统的。
  • 不要随便修改带有碰撞体的物体的缩放比例，修改也应该3个方向一起修改
    首先是他将一个带有碰撞体的对象的z轴缩放成0.5倍，这个就给之后的开发留坑
  • Is Kinematic带来的影响
    勾选这个会让物体不再受碰撞影响，但其实这也意味着，另一个进行碰撞的刚体会承受更加大的“反弹力”。
    项目中需要碰撞来进行多个物体的连接，但碰撞会可能会导致物体离开轨道出现bug
    因此最终也无法完全去除碰撞，在部分过程中将两个碰撞体的刚体都勾选Is Kinematic，还减慢速度来减少碰撞的影响。
  • 铰链的运动
    在以前我去找绳子的插件时，就遇到过一种基于Unity Joint组件的绳子
    使用这种绳子在大多数情况下都时运作良好的，但当Joint之间受力超i过某个阈值时，就会产生无法停止的乱飞，抖动现象
    而这次使用的资源，其连接物体的方式就是使用铰链组件的，一旦碰撞力过大，铰链就会化为bug
  • 滥用触发器
    之前的人代码写的很烂，估计也不懂数据结构那些基础课，结果一点点小问题就用触发器来做。
    比如用触发器来计轨道上有多少物体，其实完全没必要
    而且计轨道上有多少物体也不一定100%成功，大概3%-5%会出现计数错误的bug
  • 未读懂使用资源的代码
    虽然我也没读资源里的代码，但是上一个人作为使用者，在操作资源时，具有大量冗余代码和不合理的代码
    最经典的莫过于通过调整时间速率来加快物体运动速度，其实稍微查下方法栈就知道如何调整速度了
    于此同时，又有很多代码我感觉应该改了没问题的，删掉后立即就崩了，想必也是为了强行让资源受控制的代码。
    而我想要修改，又必须写新的代码来强行控制他的代码。

第一点说到缩放成0.5倍的坑，当我解决好各种物理Bug后，发现这个缩放0.5倍带来的物理bug是无法人为控制的，也因此导致项目重做（幸好不大）
我们需要的的确是0.5倍的z大小，而其他两个轴由于需要和轨道匹配也必须保持1。
但由于z轴变化，原资源能保持的物理平衡在这里完全失衡
原资源并没有提高刚体的解析度来提高铰链的稳定。
但我开发时将解析度翻了几倍后，依然有可能在轨道弯曲时让铰链失效，而在原资源中则没有这些问题

• 之后的改进和重做
  虽然个人感觉已经将发生bug的概率降的很小，但由于看到了物理系统的不可靠，且该项目之后是同时给百人以上的人使用，因此决定重做
  • 调整前后的代码量对比
    调整前个人认为我已经读了所有他写的代码，七八成也已经理解了。而我现在也已经重写了七八成的代码。说实话，代码量是比他少的。写新的代码只花了3，4天的时间
    就算我不加上读懂他写的代码，光是改他代码所产生的物理bug就已经是2个星期了
    尤其是用触发器计数的地方，既不好理解（指向触发器的引用在不同情况下指向不同的触发器），代码也会变得又臭又长，失去连贯性（很难知道触发器让什么东西耦合在一起了）
    个人吐槽：计算机师范的人，虽然不是每个人代码都写的很烂，但代码力平均值绝对比软工这种低
  • 去除物理系统，使用代码控制运动
    由于时间紧迫，因此我也使用了插件，是Cinemachine的DollyCart组件。我清楚这个组件原本并非是做这种事的，但他十分契合我的要求，比DOTween的轨道更契合
    之后在使用DOTween1来控制运动，2天时间就让物体能初步按所想的运行
    下图是初次整理的控制物体的思路，现在有些地方已经不一样了，也进行了部分封装，大思路大致相同