http://games.sina.com.cn/zl/duanpian/2014-03-11/105973.shtml
编者按：在即时战略(RTS)游戏中，寻路系统可谓其核心要素之一，但它的算法也是较难攻克的内容之一。在这篇文章中，来自iSamurai工作室的伍一峰为广大游戏开发者带来了他对即时战略游戏寻路算法的深入思考。
在即时战略(RTS)游戏中，寻路系统一般需要满足以下几个条件：
1)效率高，由于rts地图普遍较大，单位较多，因此处理效率很重要；
2)易编辑，便于level design；
3) 效果真实，如能找出最优(或者是看上去合理)路径；
4) 可以应对动态的游戏世界，例如起建筑。
根据@王亞暉所说，用于寻路的算法一般是A Star。为何是A Star而不是其他函数呢？
首先，A Star用到启发式函数(Heuristic Function)[1]，和另一个算法Dijkstra(A Star的无启发函数版)相比可能会更有效率，因为启发函数设计得当，可以大大减少计算量。
又因为启发函数的估计往往不是精确的，所以A Star不一定能找出高出人类认知的最优解。但是对于游戏来说，看上去合理就行。
然而用A Star作为寻路算法，仅仅是解决了寻路系统基础部分的问题。作为系统，它还要有易编辑的特性。这就涉及到A Star中每个节点(Node)的表现方式问题。
一个最基本的表现方式是方块(Tile)，如下图 [2]
我们可以将山洞所占的的几个方块设为“Not Movable”，这样A Star就会不会考虑到这几个方块，系统所生成的路径就不会碰到山洞。用方块作为AStar节点，其优点是简单，但也存在一些问题：
1)如果地图很大，方块就变得很多，这样A Star的节点就会大大增加，处理时间也会相应增大；
2) 单位的移动只能是上下左右，最多加上斜行，总共八个方向，不够真实；
3) 如果单位的体积大小不一致的话，大单位的图像可能会覆盖到“Not Movable”部分。
以上图为例，若有一条路线途经山洞边，那么一个占四个方块大小的巨人走过该路径的话，就会走在山洞上面。
为了解决使用方块时面临的这些问题，我们可以使用路经点(Waypoint)来做A Star节点，如下图 [3]
图中的红色的路径点代替了方块，成为A Star节点，这样的好处是我们可以自由地添加路径点，并相对地减少A Star节点数目。同时，单位也可以按照设计师设计的方法走。但是，我们从上图也可以看出这种方法也存在一定缺陷：
1)如果是大地图，路径点数量太少会显得生硬。
2) 需要考虑得面面俱到，不然一条直路忘了加路径点，单位就会“绕”(看上去)过去。
为了更好地解决以上问题，导航网格(Navmesh or Navigation Mesh)出现了，如下图所示 [4]
现在，灰白色的多边形成为了A Star节点，它很好地解决了上面所出现的所有问题：
1) 从图中可以看出，节点的数目大大减少，因为多边形可以覆盖任意区域，因此不用将其限制成方块或点。使用这种方法，除了能提高计算速度外，编辑导航网格的效率也能获得提升。
2) 通过计算直线两点和导航网格的相邻点(上图蓝色点)的位置关系，可以计算出两点是否能直接行走而没有阻碍物阻挡。例如上图从A点到B点通过计算可以得出可以直线行走，而不用像方块和导航点那样绕来绕去。
3) 在转角位不一定要经过相邻点，可以加上单位的体积半径，这样不同体积的单位都可以合理地通过转角。
对于建筑的考虑：
对RTS中的寻路系统来说，除了上述问题，还有一个很重要的要素需要考虑——就是它必须能应对动态的游戏世界。举一个简单的例子，起建筑。
在一些需要频繁修改游戏世界的场景中，以方块为节点会更加容易作出修改 [14] ——只需要将建筑所占的方块的“Not Movable”修改成“Movable”。
例如著名的塔防游戏《Field Runner》应该就是利用这种方法来实现的。而且作为塔防，《Field Runner》可以只在建塔之后寻路一次，缓存起来就行，所以在这一场景中方块成为了一个方便快捷的选择。
然而，导航网格也是可以动态修改的，不过开发难度会更大，而且运行中动态修改可能会造成延迟。有一些方法可以优化，例如动态地修改局部导航网格 [12]，或者是完全不修改，而将建筑看作局部的障碍物用另一套机制来应对 [13]。
其实除了AStar算法之外，还有其他算法或技巧可用于RTS的寻路系统，在这里简单地介绍一下：
Potential Field：
它是将地图用一个矩阵来表示，矩阵储存着大小不同的电势(整数)。例如，正电势表示吸引，负电势表示排斥。游戏中的单位本身是一个负电势，游戏以一个数组储存所有单位的电势和位置 [7]。
那么在计算一个单位需要怎么从A点到B点时，我们可以用一个新的矩阵将目的地B点设成正电势，并以不同方式(如圆形、四边形等)辐射开，离B点越远电势越低，直到0。
然后将地图矩阵，目的地矩阵，和所有单位数组的电势相加，得出一个新的、反映当前游戏世界的电势矩阵。然后单位再选择周围所有电势点中的最高电势点去走。不过这里坑很多，因为它本质上是Greedy Algorithm，所以未必能找出解。[5]
但在某些设定中，例如在没有过于复杂地形，并且需要单位自动不相互覆盖的情况下，PotentialField还是可以完成任务 [8]。因为相比A Star的寻路系统来说，这个方法会比较简单。
Flocking Behavior：
在对于一大群单位的寻路，计算量是很大的，而且往往会有很多的重复，这些都是可以避免的。
如果单位的移动是利用Steering Behavior [9] 来实现的话，那么就可以为其中一个单位，称之为Leader，计算路径(例如用导航网格)，然后其他单位按照以下Flocking原则来移动：
1) 分离，避开相邻单位；
2) 一致，和整体的移动方向一致，这里应该是Leader的移动方向；
3) 聚合，向整体的平均位置靠拢；
这样的话，就可以降低寻路的计算量，并且能得到更加真实的群体单位行进效果。
另外一个技巧和Flocking Behavior类似 [10]：
对于不用Steering Behavior的一大群单位，可以将他们设为一个组，计算这个组的路径(并且要考虑到这个组的半径以便通过转角位)，然后给每个单位offset一个适当的距离。
如果遇到小的通道(例如门)可以适当调整offset。
《全面战争》里面一个队伍40人，大概就是用的这种方法 [11]。
还有一个优化技巧是Chunk [15]：
这个技巧和 @王亞暉所提到的“先切分地图然后分块去做”应该是一致的。
在规模宏大的地图中，为了进一步提高寻路速度，可以在编辑地图时将一些节点处理成一个Chunk，它有入口和出口，并且不同Chunk之间需要连接起来。
从A点移动到B点，首先在Chunk之间做寻路，得到一系列的Chunk，在Chunk 1的时候只需要在Chunk 1中寻路，去到Chunk 2的时候就只在Chunk 2中寻路。
它本质上是将地图分为两种维度，一种是粗略的Chunk，一种是Chunk里面的节点(可以是方块，路径点，导航网格)，并分开进行处理。有种空间分割(SpacePartition)的味道在里面。
这个方法我没有真正用过，还望大家补充。
还有DStar，它主要运用在机器人领域 [6]，可以在未知环境中寻路。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
注释和资料来源：
[1] 启发式函数 Heuristic Function：估计路径所需的资源花费的函数，资源可以是“时间”，“体力”等等。对于精度要求不高的游戏来说，常用的启发函数是估算曼哈顿距离。
[2] 图片来源： Implementing Auto-tiling Functionality in a Tile Map Editor
[3] 图片来源：http://mgrenier.me/2011/06/pathfinding-concept-the-basics/ (这篇博客也有讲述寻路的概念，是一个不错的学习资源)
[4] 图片来源：Game/AI:Fixing Pathfinding Once and For All (这篇博客更加全面地讲述各种寻路系统的节点代表方式，值得一看)
[5] 推荐参考：Using Potential Fields in a Real-time Strategy Game Scenario(Tutorial)
[6] 参考来源：http://en.wikipedia.org/wiki/D*
[7] 单位可以移动，所以以数组来储存会比较方便，不用频繁更新矩阵。
[8] 一个成功的例子：n-created
[9] Steering Behavior，将一个单位考虑成一个受力点，通过增加不同的力，如吸引的，排斥的等等，实现如搜索、逃跑、躲避障碍和Flocking等行为。
[10] [11] 资料来源：Flanking Total War’s AI: 11 Tricks to Conquer for Your Game
[12] 动态地修改局部导航网格：Dynamic Navigation Mesh
[13] RV Obstacles：http://gamma.cs.unc.edu/RVO/
[14] 资料来源：A*Pathfinding Project
[15] 资料来源：RTS寻路系统概要 中orange030的补充