关于路径规划与路径同步/验证的一些疑问与思考

今天鹏哥在讲nav mesh agent的时候提到了在开发中他们并没有用unity自带的nav，而是自己重新写了一套同时部署在客户端与服务端

听到这里我的疑问顿时就来了，为什么不用？？？

最早之前在寒假做demo(unity 2D)的时候因为考虑到做帧同步时逻辑计算都需要用整型而不能用浮点数，unity自带的navmesh并不适合，所以采用的是状态同步

我草草的想了一下以为是这个原因，所以在课后问了下鹏哥这个问题，可是鹏哥却说这个不是原因，鹏哥的解释是因为nav放在客户端是ok的，但是放在服务端用这个寻路会出现一些奇奇怪怪的问题，然后如果都把验证逻辑放在服务端，角色的一个动作就得等到服务端处理完再执行，如果在延迟高了，比如100ms，打击感就会不好

然而我还是觉得微妙的奇怪…

后来和牙哥瓜哥又就这个问题聊了聊

要不然你还要考虑网卡时候的预测，先行，然后后面还要差值跟踪，还有一堆断线重连

瓜哥

可是我怎么觉得鹏哥说的有点问题

因为有延迟你客户端通知服务器要寻路 这延迟也是一样有的啊

跟你客户端算好，把这个发服务器让他验证返回来不是一样么

牙哥

后来再聊又觉得怎么整都可以了🤦‍

我最开始在demo中的想法是路径规划交给客户端是计算，服务端仅仅就路径可行性进行验证就好了，后来牙哥又提了个问题

动态阻挡呢

我想的是，你服务器验证路线上 是否有别的怪物可能比较困难把

而且可能还需要验证爬坡之类的

这就是完整的一套recast了

牙哥

确实，我在demo中做的是个pvp类战棋，除了主角就没有别的怪了，根本没考虑过在服务端判断动态阻挡的问题

瓜哥当即又表示

要我就是客户端跟一个导航一样，一直动态算路径，服务端就用这个路径跑，撞墙就换一个路

瓜哥

闲扯到最后还是发觉，轮子还是自己造用起来顺手

牙哥表示他们组实际上的逻辑全在服务器，前后统一用了一套recast，也有一部分路径规划放在客户端

大概是为了防外挂

瓜哥的意思感觉还是更注重服务端计算消耗

有空还是该去看看recast的源码