A星寻路得到路径数组，而如果目标是移动单位，该如何优化呢？
如图所示，这是理想的中间无障碍物的情况，而两个士兵都在移动，而移动到位置后目标已到了别处。
想到了一个办法是
每移动完一个格子，就判断一下，最后的路径和目标的距离是否已经超出攻击范围，比如
if (！最后的移动坐标.fuzzyEquals(this.B.node.position, 10)) {
//目标移动了,重新A*寻路
}
就再一次寻路，但这个性能消耗太大了，上去一百个士兵担心性能不足，估计肯定会性能不足。
1赞
求助求助求助
- 让寻路的终点P为起点继续寻路得到路径B，之前的寻路结果A保留。
- 等到操作目标移动到终点P时候再使用此路径B进行移动。
- 如果目标距离这个终点A比较远时或者离目标比较近，放弃所有寻路结果A、B，重新计算移动路径。
总之，思路就是 保留基本不变的路径，只改变需要改变的路径。
几个方面，首先连续使用A的性能可能并没有你担心的那么差，我那个塔防投兵就是总重新使用传统A的，我自己测试同屏10塔50兵，小米6的chrome没有什么性能问题。
其次，如果你真的需要改善，有两个方向
- 改善传统A*，这个后面说
- 了解一下所谓"NavMesh"，这个我没用过但unity有现成(https://docs.unity3d.com/Manual/nav-BuildingNavMesh.html)，你可以对比一下
方向一我做过一些实验，的确是有改善的，但是也要分两步进行，分别对应一大类论文要看
- 兵自己的位置作为"源(src)"不变，但是"目的地(dst)"不断变动，减少后者变动后的重新寻路代价。这种要看，但对游戏没什么帮助，代表作有LPA* https://www.cs.cmu.edu/~maxim/files/aij04.pdf
- 兵自己的位置和目的地都不断变动，这种应该是最常见的情况了，代表作有Anytime D* http://www.cs.cmu.edu/~ggordon/likhachev-etal.anytime-dstar.pdf
我也做了些图说明更新单次获取expander与边权重的关键步骤示意图，可以看看。
另外论文都是针对有向图的，游戏的网格地图一般是无向稀疏图，你可以把无向边拆成两条有向边来做（至少我自己是这么做）。
1赞
设计map存储a*的第一步结果，格式例如1,2点到7,8点：astarMap[‘1,2,7,8’]={x:2,y:3};
如果已经存在，使用结果，不存在开始计算a*，并将结果存进astarMap。
每帧都重新计算很耗时，可以平摊到每一帧只计算多少个角色
设定一个间隔