作者的RCA寻路没毛病，单机项目可以直接用。对方说的go语言实现的更快的算法，最后就算说出花来？能免费下载给我用在项目里吗？一直说自己的更优，缺又不提供代码。就像罗永浩当年对王自如说的：你说有别的手机厂商比我的屏幕好，但是我问你是哪家，你又不说。这不是纯纯的耍流氓吗？
为作者的开源贡献精神点赞！
他要的数据，作者都提供了，测试用例也提供的可以下载的。要能在引擎上跑的，部署在手机上的，他提供的有？反反复复就光贴他go语言服务器跑的测试截图
准确来讲他啥也没做，坐着。光看作者忙来忙去提供东西
不多说了。精彩！
很久没有来论坛了，听说有这次的讨论特意来看看，很满意这个帖子的氛围（不是起哄）。感觉技术性的讨论哪怕有一些冲突，也很让人舒畅（为难两位了）
拿加特林和别人小米加步枪比射速
突然好感兴趣,怎么办. 忍不住有了一个想法.
就是故意找茬的。因为go语言Astar比ts语言Astar快，所以go语言Astar比ts语言RCA快。
你咋不说unity3d性能比cocos 3d性能好呢？俩语言都不一样，硬件环境也不一样，就硬说go语言法拉利V12比作者的小米SU7要快。
你说的是NavMesh寻路吧？仔细看我贴的介绍，其实RCA就是和NavMesh差不多的数据结构，都是提前链接外角顶点，但是RCA又保留了栅格格子地图的优点，里面提到外墙角对应的是多边形寻路的凸多边形，内墙角对应的是凹多边形。烘焙阶段把外墙角连在一起和NavMesh的凸多边形角连在一起时一样的。并且还比NavMesh多了内墙角连外墙角的信息。
结合栅格化格子地图的优点，可以轻松做射线检测，能快速找到附近的其它墙角和是否能达终点。
所以整体还是RCA算法快。
而且RCA算法烘焙时间短，可以运行中烘焙，也可以在游戏中地形被破坏变形了进行二次局部烘焙。nav的烘焙只能在游戏外借助编辑器烘焙数据，烘焙个中等地图可能花1分钟。
1赞
Go 版本的开源库里没有截图里的这段代码。
但我确实看到了有 ResetMap，寻路耗时确实已经计算在内了。
我收集了许多其他算法发布了一个基准测试帖子，里面包括了 AStarRoadSeeker.ts
别招笑了，真的求你了
这么小的图，路径能差快30%的长度，你还在拿A不是最短说事，你再去学学什么是A吧求你了，还在扯四向八向，你连代价函数用在什么地方都没学过，你就想用所谓的墙角来加速，还隔这商业moba，等你追到我，我已经把你的基地打爆了知道吗。你知不知道你的蜘蛛网映射是有多么愚蠢，还隔着烘培呢，我纳秒级的地图变化响应，服务器60tick随便变化。你的地图变化一块，你那个几十万映射关系的蜘蛛网，又要重新织了，笑死了哈哈哈
都是搞客户端的为啥还要用A星格子寻路，这套东西是给不懂图形学的服务端程序用的。
要不你们都去看下cocos做的《迷雾大Lu》的寻路算法。无限地图，支持斜边，同屏200个怪寻路完全不卡。抛弃传统A星寻路，基于WayPoint实现的。
就你这种还谈百万格，几万格都拉的要死，还讲商用呢，路线又烂，还有个逆天的蜘蛛网
哥们啊昨天都跟你说不跟你吵了，你还来。
作为一个开发者除了技术还需要人品道德，我不知道别人看了整个帖子里的争论谁敢去跟你做商业化，你作为一个人，连信用都没，小人得志，别人问东你答西，问道技术问题就刻意回避，问你检索了几个格子你回答影响运行时间。
我不知道有哪个大冤种会找你合作商业化，遇到bug，就凭你这种信用肯定是甩锅跑路的。
对于你说的问题，前面帖子和评论我多次说过了，遇到问题可以提给我，我可以去查找原因。
我不敢想，你1个墙角要关联10个别的墙角，那一个百万格的地图，100W /4 * N个墙角 *10映射，我叫我老板多加几根内存条吧