RTS游戏流场寻路算法详解

RTS里面经常会有很多角色，群体一起寻路到目的地附近，这种寻路是如何实现的，今天给大家详细的讲解基于流场寻路的算法。在本教程中，我将解释向量场寻路及其相对于Dijkstra等传统寻路算法的优势。对Dijkstra算法和势场的基本理解将有助于理解本文，但不是必需的。

寻路的问题有很多种解决方案，如AStar等, 每种寻路的方案都各有优缺点，大部分的寻路，都是角色要从A点走到B点，然后调用寻路算法找出一条路径出来。通常情况下这样是不会有问题的，但是对于像RTS这种游戏需要做群体寻路，从A点到B点一群角色走过去，如果每个角色都单独寻路，这样性能开销会比较大，所以今天我们为了解决这个问题，介绍基于流场向量的寻路。它的原理是把目标点的流场计算出来，所有移动的目标共用这个流量场。接下来本文讲详细的介绍流场寻路的核心技术与步骤。(本文是将地图基于网格来讲解的，你也可以用到其它的地方，不限于网格)。

对啦！这里有个游戏开发交流小组里面聚集了一帮热爱学习游戏的零基础小白，也有一些正在从事游戏开发的技术大佬，欢迎你来交流学习。

基于流场寻路的算法的主要步骤

基于流场寻路的算法主要包含以下三个步骤:

生成Heatmap

Heatmap 是指从目标点到地图上每个图块的路径距离。路径距离不同于欧几里德距离，它是通过可穿越地形的最短的两点之间距离来计算。如下图，你可以看到从目标点（用红色标记）到地图任意的点（用粉色标记）的路径距离和线性距离之间的差异。不可行走的块以绿色绘制。如图，路径距离（以黄色显示）为9，而线性距离（以浅蓝色显示）约为4.12。每个图块左上角的数字显示由Heatmap生成算法计算出的到目标的路径距离。注意两点之间可能有一个以上的路径距离, 我们只算最短的那个距离。经过算法第一步，我们把地图上的每个块到目的地的最短距离都计算了出来，生成了Heatmap。

Heatmap生成算法是一种 wavefront 算法。它从值为0的目标开始，然后向外流动以填充整个可遍历区域。 wavefront 算法有两个步骤：

(1)从目标开始，并用0的路径距离标记它。

(2)获取每个标记的图块的未标记邻居，并用前一个图块的路径距离+1标记它们。

(3) 标记完所有地图的块后，算法结束。

注: wavefront 算法是在网格上执行广度优先搜索，并存储沿途到达每个块所需的步骤。这种算法有时也称为brushfire算法。

Vector Field 生成

现在已经计算了从每个块到目标的路径距离，我们可以很容易地确定接近目标需要采取的路径。通常计算一次Vector Filed，然后让所有要寻路的对象在运行时引用该Vector Filed。

Vector Field 简单地存储了一个向量，该向量指向每个地图块走向目的地的方向（朝向目标）。这里是向量场的可视化，向量从图块的中心沿着最短路径指向目标,形成了一个流场。（红色为原点，白色的线为方向，大体趋势都指向目标点）。

这个向量场里面的每个向量，是通过Heatmap计算出来的，具体的计算Vector向量方式如下:

Vector.x = left_tile.distance - right_tile.distance, 向量x为左边的块-右边的块;

Vector.y = up_tile.distance - down_tile.distance,向量y为上边的块-下面的块;

每个块的distance,就是上面Heatmap种计算出来的数值。

如果当前块的（左/右/上/下）不可行走(障碍物等)，则使用与当前块的距离来代替缺少的值。一旦粗略计算了路径向量，就对其进行归一化，以避免以后出现不一致。

角色移动导航

velocity_vector = vector_field(x, y) * desired_velocity

当我们导航的时候，只要沿着向量方向移动就可以了,很容易就实现了流场移动, 同时多个角色目标寻路的时候，只要计算一次。

如上图，紫色的点，水平不可以移动，上下两个块的距离都是一样的，这样就导致了不唯一性，一半这种情况，我们会随机选着一个方向，这样导致的结果可能就是我们选择的路径不一定是最短的，所以流场寻路又是基于局部最优解的。要解决这样的问题，还有一个好的方法，就是把块分小，降低这样的几率。

当然把块分小，计算量也会增大。

好今天的流场寻路的内容就分享到这里了，我这边实现了一个C++版本的流场寻路的代码，大家可以参考一下，需要的可以关注我们，回复“流场寻路”即可获得寻路代码。