本文由 伯乐在线 - xxmen 翻译，黄利民 校稿。未经许可，禁止转载！
英文出处：theory.stanford.edu。欢迎加入翻译组。
本系列：
- 关于寻路算法的一些思考（1）：A* 算法介绍
- 关于寻路算法的一些思考（2）：Heuristics 函数
- 关于寻路算法的一些思考（3）：A* 算法的实现
- 关于寻路算法的一些思考（4）：A* 算法的变体
- 关于寻路算法的一些思考（5）：处理移动中的障碍物
- 关于寻路算法的一些思考（6）：预先计算好的路径的所用空间
- 关于寻路算法的一些思考（7）：地图表示
- 关于寻路算法的一些思考（8）：长期和短期目标
- 关于寻路算法的一些思考（9）：寻路者的移动成本
- 关于寻路算法的一些思考（10）：最短路径的用户体验
- 关于寻路算法的一些思考（11）：寻路算法的其他应用
- 关于寻路算法的一些思考（12）：AI 技术
最短路径的用户体验
玩家是游戏最重要的部分。你想让用玩家愉快地玩耍！你不想让他（她） 认为电脑在作弊，或是游戏单位运行不正常。
愚蠢的移动
如果寻路算法运行不正常，用户将最后放弃并选择手动移动单位。避免出现这种情况！在《文明》中，游戏的规则允许利用铁路无代价地移动。但是，游戏的导航只能进行其他方式的有代价移动。这样导致玩家拒绝使用游戏导航，而选择利用铁路手动移动单位。在《命令与征服》中，游戏单位会被困在U形的陷阱中，玩家将不得不手动引导这些游戏单位。一个愚蠢的游戏导航会使激起玩家的不满，导致他们自己手动移动单位，因此请让你游戏的导航程序更加完善。
聪明的移动
把游戏单元做得太过聪明和做得太过愚蠢一样会造成不好的后果。如果玩家需要应对战争迷雾导致的视野受限影响，而游戏寻路单元能看到全地图，能在玩家毫不知情的时候神秘地知道该去往哪里。这会让玩家明显地感到奇怪的事情正在发生。换句话说，它给出了更好的路径。一种妥协的方法是提高在未被探索区域的移动花费。例如，如果你的正常移动花费是草地上1，森林中3，山地7，在未被探索区域就应该设置对应的不同花费：草地为5，森林为6，山地为7。这样游戏单元会把山地和草地纳入考虑，但只是一个提示，不会过度考虑。提高穿越未被探索地区的移动代价，将会使寻路程序倾向于尽可能停留在已被探索的区域中。你可能也想为侦察单元提供一个相反的策略：它们应偏爱未被探索的区域。
尽量使你的寻路单元在太过愚蠢和太过聪明之间保持平衡。你的目标应该是使游戏寻路单元和玩家可能的移动行为相匹配。
多线程
你可以使用多线程来改善玩家体验。当有一个游戏单位需要一条路径时，允许它开始向着目标位置直线移动，同时向寻路队列添加一个请求。在另一个（优先级较低）的线程中，把请求从队列中去除并进行路径寻找。该游戏单位会立即开始移动，因此玩家不会疑惑是不是出现了问题，你也不会有过高的CPU负载（会拖慢游戏的其余部分）在进行路径计算的时候。
多单元
如果你的游戏允许多个单位构成组一起移动，请试着让移动看起来更加有趣。你可以找到一条路径让它们都沿着路径移动，然后让它们单独沿着路径移动，但这会导致这些单位中的一条直线或者单位会穿过其它单位前进。因此，稍微区分一下路径它们就能平行地移动了。另外，还可以选取一个“领导”单元来沿着路径移动，同时让其它单元执行单独编写的“跟随”行为。这个跟随行为可以非常简单，只要向着“领导”所处的方向前进，同时停留在一段距离之外，或者它就像鸟类成群结队飞行。
多路径点
即使给定了最优的路径，玩家可能会偏爱其它不同的路径。你应该允许玩家在路径上标记路径点：玩家可以点击通向目的地的路径上二到三个路径点，而不是简单地点击目的地。（很多实时策略游戏使用shift-点击来完成这项操作。）你当前有了三到四条较短的路径来进行计算，同时你节省了一些时间。玩家对于整体的路径安排同样拥有部分的控制权，例如，你的游戏导航找到了一条通向西部山地的路径，但出于安全考虑，玩家希望停留在东部山地（靠近友军防御塔）。
在单位移动程序中的主要改变是，你将拥有一个目的地的列表，而不是一个单一的目的地。首先寻找一条到达第一个目的地的路径，当你到达时，从列表中删除它然后继续寻找到达下一目的地的路径。这种做法可以降低游戏过程中的延时并且提高系统的吞吐量。
