[人工智能][Bukkit插件开发教程] [高质量插件系列] [算法] - A*寻路算法在三维MC中的实际应用

注意：本文适合 有JavaSE基础 勇于尝试 有耐性的读者食用
（正所谓算法开发 学到头了 也就到头了orz）

本文中二维A*思想部分来自于?A* Pathfinding for Beginners - Artificial Intelligence - Tutorials - GameDev.net

在开始之前：

本文不会完全将最终代码贴出，仅取部分作为参考。您的代码理应源于您自己，我们不是为了开发而开发！
撰写本文的想法起始于本人最近进行的一款寻路插件的开发，在研究现有寻路算法时发现了最具优越性的A*寻路算法，但是网络上几乎无法找到三维空间下的A*，即便有也未有详细思路或查询代价过高(此点会在下文说明)，故本人特意以MC特性为基础在二维A*的基础上进行改进，经过几天的调试与分析，最终得出本文中完全具备经典二维A*思想的三维A*算法。如若对本文内容持有异议或拥有更好的观点，欢迎各位进行留言！

初始化

我们先了解几个概念：
首先我们将要搜索的地图视作二维的 区分出来两类方块?地面?和?墙面
地面可以是草方块、原石等?可供玩家正常行走的方块
墙面可以是水、岩浆等可视为?无法行走，不进行查找的方块
那么在地面上我们就可以确定搜索的?起点?和?终点

在正式搜索之前 我们先定义一个内部类Node作为节点储存寻路过程中产生的每个结点的位置信息(Location)、父节点(Node)、G值(父节点移动到当前节点的成本)、H值(从当前节点移动到终点的估算成本)以及当前节点与终点的高度差(int)

要注意的是虽然我们在寻路的过程中以Node的实例进行操作，但事实上对位置进行操作时我们仍是对Location进行操作。故为了方便储存与对节点进行操作，我们再定义一个名为NodeSet的类继承HashSet来储存节点与覆写contains、get与remove方法。并实例化一个openList与closeList便于节点的回溯与处理(见下文)

搜索开始
?

一旦我们把搜寻区域简化为一组可以量化的节点后(就像上面做的一样)，下一步要做的便是查找最短路径。在二维 A* 中，我们从起点开始，检查其相邻的方格，然后向四周扩展，直至找到目标。

我们这样开始我们的寻路旅途：

1.? ?? ? 从起点 A 开始，并把它就加入到一个由方格组成的 open list( 开放列表 ) 中。这个 open list 有点像是一个购物单。当然现在 open list 里只有一项，它就是起点 A ，后面会慢慢加入更多的项。 Open list 里的格子是路径可能会是沿途经过的，也有可能不经过。基本上 open list 是一个待检查的方格列表。

2.? ?? ? 查看与起点 A 相邻的方格 ( 忽略其中墙壁所占领的方格，河流所占领的方格及其他非法地形占领的方格 ) ，把其中可走的 (walkable) 或可到达的 (reachable) 方格也加入到 open list 中。把起点 A 设置为这些方格的父亲 (parent node 或 parent square) 。当我们在追踪路径时，这些父节点的内容是很重要的。稍后解释。

3.? ?? ? 把 A 从 open list 中移除，加入到 close list( 封闭列表 ) 中， close list 中的每个方格都是现在不需要再关注的。

如下图所示，深绿色的方格为起点，它的外框是亮蓝色，表示该方格被加入到了 close list 。与它相邻的黑色方格是需要被检查的，他们的外框是亮绿色。每个黑方格都有一个灰色的指针指向他们的父节点，这里是起点 A 。
?

注意

截至到此处是为二维A*的思想 迁移到三维我们需要在起点A的临近的8个节点中再进行?可达行分析(常规三维A*是对当前节点周围 3^3 -1 即26个子节点进行路径值(G + H)排序)?在本贴中我们将以这种独特的选择方式对常规三维A*进行较大程度上的优化

我们知道在MC中 如果玩家处于一个方块上(在此记此方块为节点N) 那么对于节点正上方和正下方的点玩家是不能到达的 所以我们只需要分析N点周围八个点及其上下的方块是否可达(即玩家前往下一个节点是向上走、向下走还是直接走)
所以根据N点子节点是否可通过?Block#isPassable()?将情况分为两大类
1.子节点上存在实体方块
?

此时又有两种可能
如果子节点上方无实体方块，则判断其上方的上方处是否有实体方块阻挡玩家
如果子节点上方有实体方块，则判断玩家是否能走到该方块上(需判断玩家头顶是否有方块及目标方块上方是否有空间)

2.子节点上不存在实体方块
?

我们此时可以继续以子节点(白色玻璃被打掉代表子节点上无实体方块，但N的位置仍不变)上方是否有实体方块为判断依据，分成玩家向上/向下走两种，此处判断细节省略。
下方为我插件中此处判断的源代码，仅供思路上的参考

通过上述操作，我们已经将A点周围8个子节点进行了二次筛选并获得了一个Node[] 接下来我们应该从这个数组中选择下一个需要分析的子节点，按下面描述的一样或多或少的重复前面的步骤。但是到底选择哪个方格好呢？具有最小 F 值(即G + H)的那个。

G = 从起点 A 移动到指定方格的移动代价，沿着到达该方格而生成的路径。
H = 从指定的方格移动到终点 B 的估算成本。这个通常被称为试探法，有点让人混淆。为什么这么叫呢，因为这是个猜测。直到我们找到了路径我们才会知道真正的距离，因为途中有各种各样的东西 ( 比如墙壁，水等 ) 。本贴将以一种较为简单的方式估算H，你也可以在网上找到其他方法。

我们的路径是这么产生的：反复遍历 open list ，选择 F 值最小的方格。这个过程稍后详细描述。我们还是先看看怎么去计算上面的等式。
如上所述， G 是从起点Ａ移动到指定方格的移动代价。在本例中，横向和纵向的移动代价为 10 ，对角线的移动代价为 14 。之所以使用这些数据，是因为实际的对角移动距离是 2 的平方根，或者是近似的 1.414 倍的横向或纵向移动代价。使用 10 和 14 就是为了简单起见。比例是对的，我们避免了开放和小数的计算。这并不是我们没有这个能力或是不喜欢数学。使用这些数字也可以使计算机更快。稍后你便会发现，如果不使用这些技巧，寻路算法将很慢。

既然我们是沿着到达指定方格的路径来计算 G 值，那么计算出该方格的 G 值的方法就是找出其父亲的 G 值，然后按父亲是直线方向还是斜线方向加上 10 或 14 。随着我们离开起点而得到更多的方格，这个方**变得更加明朗。

有很多方法可以估算 H 值。这里我们使用 Manhattan 方法，计算从当前方格横向或纵向移动到达目标所经过的方格数，忽略对角移动，然后把总数乘以 10 。之所以叫做 Manhattan 方法，是因为这很像统计从一个地点到另一个地点所穿过的街区数，而你不能斜向穿过街区。重要的是，计算 H 是，要忽略路径中的障碍物。这是对剩余距离的估算值，而不是实际值，因此才称为试探法。
把 G 和 H 相加便得到 F 。对于三维的MC来说，我们Node节点下的height属性也有了用武之地！你可以像我一样直接将H += height*10 也可以给height分配更高的权重让程序在一定环境下倾向于寻找离终点高度差更小的子节点。

搜索继续

让我们回到二维A*的概念图上，我们第一步的结果如下图所示。每个方格都标上了 F ， G ， H 的值，就像起点右边的方格那样，左上角是 F ，左下角是 G ，右下角是 H 。
?

为了继续搜索，我们从 open list 中选择 F 值最小的 ( 方格 ) 节点，然后对所选择的方格作如下操作：
- 把它从 open list 里取出，放到 close list 中。
- 检查所有与它相邻的方格，忽略其中在 close list 中或是不可走 (unwalkable) 的方格 ( 比如墙，水，或是其他非法地形 ) ，如果方格不在 open lsit 中，则把它们加入到 open list 中。
- 把我们选定的方格设置为这些新加入的方格的父亲(node.parent)。
- 如果某个相邻的方格已经在 open list 中，则检查这条路径是否更优，也就是说经由当前方格 ( 我们选中的方格 ) 到达那个方格是否具有更小的 G 值。如果没有，不做任何操作。相反，如果 G 值更小，则把那个方格的父亲设为当前方格 ( 我们选中的方格 ) ，然后重新计算那个方格的 F 值和 G 值。如果你还是很混淆，请参考下图。
?

Ok ，让我们看看它是怎么工作的。在我们最初的 9 个方格中，还有 8 个在 open list 中(起点被放入了 close list)。在这些方格中，起点右边的格子的 F 值 40 最小，因此我们选择这个方格作为下一个要处理的方格。它的外框用蓝线打亮。

首先，我们把它从 open list 移到 close list 中 ( 这就是为什么用蓝线打亮的原因了 ) 。然后我们检查与它相邻的方格。它右边的方格是墙壁，我们忽略。它左边的方格是起点，在 close list 中，我们也忽略。其他 4 个相邻的方格均在 open list 中，我们需要检查经由这个方格到达那里的路径是否更好，使用 G 值来判定。让我们看看上面的方格。它现在的 G 值为 14 。如果我们经由当前方格到达那里， G 值将会为 20( 其中 10 为到达当前方格的 G 值，此外还要加上从当前方格纵向移动到上面方格的 G 值 10) 。显然 20 比 14 大，因此这不是最优的路径。如果你看图你就会明白。直接从起点沿对角线移动到那个方格比先横向移动再纵向移动要好。

当把 4 个已经在 open list 中的相邻方格都检查后，没有发现经由当前方格的更好路径，因此我们不做任何改变。现在我们已经检查了当前方格的所有相邻的方格，并也对他们作了处理，是时候选择下一个待处理的方格了。

因此再次遍历我们的 open list ，现在它只有 7 个方格了，我们需要选择 F 值最小的那个。有趣的是，这次有两个方格的 F 值都 54 ，选哪个呢？没什么关系。从速度上考虑，选择最后加入 open list 的方格更快。这导致了在寻路过程中，当靠近目标时，优先使用新找到的方格的偏好。但是这并不重要。 ( 对相同数据的不同对待，导致两中版本的 A* 找到等长的不同路径 ) 。在此你还可以专门为新节点检查一遍height属性以期望获得与终止结点高度差更小的节点。然后我们选择起点右下方的方格，如下图所示。

这次，当我们检查相邻的方格时，我们发现它右边的方格是墙，忽略之。上面的也一样。我们把墙下面的一格也忽略掉。为什么？因为如果不穿越墙角的话，你不能直接从当前方格移动到那个方格。你需要先往下走，然后再移动到那个方格，这样来绕过墙角。 ( 注意：穿越墙角的规则是可选的，依赖于你的节点是怎么放置的 )

这样还剩下 5 个相邻的方格。当前方格下面的 2 个方格还没有加入 open list ，所以把它们加入，同时把当前方格设为他们的父亲。在剩下的 3 个方格中，有 2 个已经在 close list 中 ( 一个是起点，一个是当前方格上面的方格，外框被加亮的 ) ，我们忽略它们。最后一个方格，也就是当前方格左边的方格，我们检查经由当前方格到达那里是否具有更小的 G 值。没有。因此我们准备从 open list 中选择下一个待处理的方格。不断重复这个过程，直到把终点也加入到了 open list 中，此时如下图所示。
?

注意，在起点下面 2 格的方格的父节点已经与前面不同了。之前它的 G 值是 28 并且指向它右上方的方格。现在它的 G 值为 20 ，并且指向它正上方的方格。这在寻路过程中的某处发生，使用新路径时 G 值经过检查并且变得更低，因此父节点被重新设置， G 和 F 值被重新计算。尽管这一变化在本例中并不重要，但是在很多场合中，这种变化会导致寻路结果的巨大变化。那么我们怎么样去确定实际路径呢？很简单，从终点开始，按着箭头向父节点移动，这样你就被带回到了起点，这就是你的路径。如下图所示。从起点 A 移动到终点 B 就是简单从路径上的一个方格的中心移动到另一个方格的中心，直至目标。就是这么简单！

总结

1.? ?? ?? ?把起点加入 open list 。
2.? ?? ?? ?重复如下过程：
? ?? ???a.? ?? ?? ?遍历 open list ，查找 F 值最小的节点，把它作为当前要处理的节点。
? ?? ???b.? ?? ?? ?把这个节点移到 close list 。
? ?? ???c.? ?? ?? ?对当前方格的 8 个相邻方格的每一个方格？
? ?? ?? ?? ?? ? ◆? ???如果它是不可抵达的或者它在 close list 中，忽略它。否则，做如下操作。
? ?? ?? ?? ?? ? ◆? ???如果它不在 open list 中，把它加入 open list ，并且把当前方格设置为它的父亲，记录该方格的 F ， G 和 H 值。
? ?? ?? ?? ?? ? ◆? ???如果它已经在 open list 中，检查这条路径 ( 即经由当前方格到达它那里 ) 是否更好，用 G 值作参考。更小的 G 值表示这是更好的路径。如果是这样，把它的父亲设置为当前方格，并重新计算它的 G 和 F 值。如果你的 open list 是按 F 值排序的话，改变后你可能需要重新排序。
? ?? ???d.? ?? ?? ?停止，当你
? ?? ?? ?? ?? ? ◆? ???把终点加入到了 open list 中，此时路径已经找到了，或者
? ?? ?? ?? ?? ? ◆? ???查找终点失败，并且 open list 是空的，此时没有路径。
? ?? ???3.? ?? ?? ?保存路径。从终点开始，每个方格沿着父节点移动直至起点，这就是你的路径。