00:00
加载中……请稍等……

事实上,对于开发游戏逻辑这个特定范畴,在很多情况下,设计cache友好的代码,非常困难。因为游戏逻辑并不是全部都是路径单一且数据密集的情况。如果你的游戏,像unity里的ECS demo那样,模拟成千上万的单位做一样的简单逻辑事情,就一样地移动、放相同的技能,那么你可以很容易就写出几个for循环,每个循环内用很少的数据,就可以完成整个逻辑。又或者你的项目像守望先锋那样,可以触及到底层,能够对数据密集的代码进行优化(寻路、碰撞、移动等等),那么这些地方也很适合通过for循环来高效遍历。然而对于大部分游戏逻辑,特别是不能触碰底层的unity项目,要符合这个条件并不容易。做一次伤害结算,你需要读取敌我双方的各种属性、状态,有些复杂的情况甚至还要计算双方的距离、甚至牵连到AI状态。然后一次伤害又可能产生各种附带的事件,比如触发一个buff、触发了死亡、等等等需要处理的逻辑。你需要对数据精心设计和拆分,才可能做到数据连续读写。稍有不注意,可能某个人加了一些功能就会破坏原来连续的存储访问,导致丧失cache友好的优势。Cache友好的编程方式真正牛逼的地方是用于解决数据单一而密集的问题,比如frostbite在做culling的时候就分享过放弃对场景做树状划分,直接暴力遍历,反而因为cache友好而获得更好的性能以及更简单的代码。这是因为culling时候数据结构单一,逻辑也单一,才获得了好的效果。目前来说,移动逻辑、寻路逻辑,这些相对容易简化的密集运算,才真正适合cache友好的写法。而AI、技能则要视乎项目,往往多数项目在这块需求极其复杂,几乎无法构建出真正cache友好的数据结构。

Last modification:April 3rd, 2021 at 02:26 pm
如果觉得我的文章对你有用,请随意赞赏