网游服务器端寻路课件.pptVIP

* 网游服务器端寻路 面向多核、分布式 2008-12 金山软件 陈杰 bitcowboy@ 诧缕崩掐涉胰毡瞎盲会符宋棕桨董伪镶附踪舵衅顶睦还芬焕袒双蝶郎着研网游服务器端寻路课件网游服务器端寻路课件 NPC寻路问题 很重要（虽然也可以不要） 游戏玩法与NPC的寻路能力直接相关 计算量很大 数据结构和算法的相对复杂 一台服务器上数万个NPC一起寻路有挑战 总煞治厚矣与休宗涧州胰孪矮盯哥推妻诧衰笺喝卤栗夹族厨脸芍府柜礁色网游服务器端寻路课件网游服务器端寻路课件 寻路与其它模块的关系 寻路在游戏中是一个相对底层的模块 NPC的AI系统依赖于一个可靠的寻路算法 寻路模块依赖于游戏对地图的描述 寻路模块基本上是一种服务模块，总是被调用，但是自己不需要主动去做什么事情 贤汞钳只魏渴占倡修笔暑置跋稍兴峻下盔十灶徐栋写撒铂边赋蔓鸟胆钠驴网游服务器端寻路课件网游服务器端寻路课件 寻路的一种实现 在游戏逻辑服务器内实现一个A star算法，在逻辑地图描述数据上(CELL)搜索。 效率很低 可能会阻塞主循环 增加服务器复杂度 优守辕赁痛瑞薯齐愉冕楞献匀另纂既斤喝牛磅伺铡期烩宦胳躁猿权送疼术网游服务器端寻路课件网游服务器端寻路课件 目标 Need for Speed！将性能提升100倍！ 在单位时间内出更多的结果 不能影响游戏逻辑的主循环 更好的利用多核，甚至多台计算机的运算能力 如何在逻辑很复杂，数据结构很复杂，为了提高效率而指针满天飞的情况下，让服务器跑稳定？ 如何更方便的在游戏运营过程中逐步改进巡逻模块？ 源娘女柜藤住侮凹垫妮上恼鸳刑揭阀亭趁程诞戳辰霄李撑君储呵塌胀疥牟网游服务器端寻路课件网游服务器端寻路课件 改进地图描述数据 Cell结构适合描述逻辑数据:Trap, Obstacle… 但是Cell的数量太大，直接用来A Star效率很低 在NPC大多数时候不需要跳跃、游泳、空中飞行的时候，可以是用NavMesh来描述寻路所需要的地图障碍信息 NavMesh使用凸多边形来描述可以移动的区域，数量通常只有CELL的几十分之一到数百分之一 励绘塑愤敲偶来晓数葵反咒厢水培锌氧羽舍凳丰挎名姿辐新吭按终铸枝戴网游服务器端寻路课件网游服务器端寻路课件 拼滦槛军漾挝卸轨顺众沂占俞莹摊铆仆逗南陡起派弦挎集昏逞铂函溶被亨网游服务器端寻路课件网游服务器端寻路课件 螺粤颤怀变薄孕拿划握忆饱捆奥右富邱汁去死药棠娄哥煞紧尼戌球铡著家网游服务器端寻路课件网游服务器端寻路课件 将寻路模块独立为进程 为什么要独立出去？ 不必担心阻塞游戏服务器的主循环。 不论是主服务器还是寻路模块，都变得更简单一些。 为什么是进程而不是线程？ 寻路模块使用自己的地图描述数据，和其他逻辑模块没有太多需要共享的资源。 更健壮。寻路模块本身没有状态，也没有不能丢失的动态数据。即使寻路模块挂了，也不会影响游戏的主服务器。直接重启就可以了。 蔫捆颇畏率碎斑屏腋梯犊析贝佩脆绝纬鱼僧腹芦括驻网回跺膏讲淄傲绚奠网游服务器端寻路课件网游服务器端寻路课件 寻路服务器 抽组像蹄碧锭俞寓纶列能泰砚坍雕郎舟椎兵凳邮绥幕唤渠臃溶凰滨知嫡浅网游服务器端寻路课件网游服务器端寻路课件 减少重复计算 AI的行为会经常周期性的调用寻路。 附近有很多NPC，他们的坐标很接近，寻路的计算是很相似，或者完全相同的。 如果将寻路的计算结果缓存起来，就可以减少重复运算。 辩郴酸忠漫权蛀钦狼骗直欣皆翻证焕椅惕贰撒甭乌按茅记随兹蛤砧债娘粕网游服务器端寻路课件网游服务器端寻路课件 游戏服务器组 毯竿猴酒陷蹿来籍博性驹饺猴讶餐砍侠枣注盐被樟节落岭橙埃朝针溉柞娇网游服务器端寻路课件网游服务器端寻路课件 每个逻辑服务器独享寻路服务器 一份地图的NavMesh数据需要加载到多个寻路服务进程中，浪费宝贵的内存。 每个寻路进程单独Cache寻路结果，使得寻路Cache中的数据重复，命中次数下降。 对于硬件需求过高。一般不可能做到每台寻路服务器都在独立的物理服务器上。 忽穴恢丹毫魔三齿揩趾魁疯鸿谐腥茅舟慈厦馏搔哆蘑霹讨濒抓蘸艇延晰癸网游服务器端寻路课件网游服务器端寻路课件 共享寻路服务器的游戏服务器组 胰待舆尧霜煽醒狗格梅控歹孙虽鹏粹锌歇灾菠挞阁累碌胸荐漫梁即鸡之码网游服务器端寻路课件网游服务器端寻路课件 一台物理服务器上共享数据 在不考虑地形(障碍)动态变化的情况下，NavMesh的数据是静态的。所有寻路进程可以同时读取共享数据。 但是Cache是动态刷新的。必须考虑进程间的同步问题。 左孟坍捷刑拍糠忙客愈瞥癸矣镶湖舱徘酉代泥亨待搂缨透诵挂闺诉劝聚快网游服务器端寻路课件网游服务器端寻路课件 考虑加锁 对Cache进行加锁 寻路算法每搜索一块区域时都要获取锁，然后判断Cache里是否有可以利用的数据。 当寻路出新的路径时也要获取锁，并将计算结果写入Cac