本系列：
- 關於尋路演算法的一些思考（1）：A* 演算法介紹
- 關於尋路演算法的一些思考（2）：Heuristics 函式
- 關於尋路演算法的一些思考（3）：A* 演算法的實現
- 關於尋路演算法的一些思考（4）：A* 演算法的變體
- 關於尋路演算法的一些思考（5）：處理移動中的障礙物
- 關於尋路演算法的一些思考（6）：預先計算好的路徑的所用空間
- 關於尋路演算法的一些思考（7）：地圖表示
- 關於尋路演算法的一些思考（8）：長期和短期目標
- 關於尋路演算法的一些思考（9）：尋路者的移動成本
最短路徑的使用者體驗
玩家是遊戲最重要的部分。你想讓用玩家愉快地玩耍！你不想讓他（她） 認為電腦在作弊，或是遊戲單位執行不正常。
愚蠢的移動
如果尋路演算法執行不正常，使用者將最後放棄並選擇手動移動單位。避免出現這種情況！在《文明》中，遊戲的規則允許利用鐵路無代價地移動。但是，遊戲的導航只能進行其他方式的有代價移動。這樣導致玩家拒絕使用遊戲導航，而選擇利用鐵路手動移動單位。在《命令與征服》中，遊戲單位會被困在U形的陷阱中，玩家將不得不手動引導這些遊戲單位。一個愚蠢的遊戲導航會使激起玩家的不滿，導致他們自己手動移動單位，因此請讓你遊戲的導航程式更加完善。
聰明的移動
把遊戲單元做得太過聰明和做得太過愚蠢一樣會造成不好的後果。如果玩家需要應對戰爭迷霧導致的視野受限影響，而遊戲尋路單元能看到全地圖，能在玩家毫不知情的時候神祕地知道該去往哪裡。這會讓玩家明顯地感到奇怪的事情正在發生。換句話說，它給出了更好的路徑。一種妥協的方法是提高在未被探索區域的移動花費。例如，如果你的正常移動花費是草地上1，森林中3，山地7，在未被探索區域就應該設定對應的不同花費：草地為5，森林為6，山地為7。這樣遊戲單元會把山地和草地納入考慮，但只是一個提示，不會過度考慮。提高穿越未被探索地區的移動代價，將會使尋路程式傾向於儘可能停留在已被探索的區域中。你可能也想為偵察單元提供一個相反的策略：它們應偏愛未被探索的區域。
儘量使你的尋路單元在太過愚蠢和太過聰明之間保持平衡。你的目標應該是使遊戲尋路單元和玩家可能的移動行為相匹配。
多執行緒
你可以使用多執行緒來改善玩家體驗。當有一個遊戲單位需要一條路徑時，允許它開始向著目標位置直線移動，同時向尋路佇列新增一個請求。在另一個（優先順序較低）的執行緒中，把請求從佇列中去除並進行路徑尋找。該遊戲單位會立即開始移動，因此玩家不會疑惑是不是出現了問題，你也不會有過高的CPU負載（會拖慢遊戲的其餘部分）在進行路徑計算的時候。
多單元
如果你的遊戲允許多個單位構成組一起移動，請試著讓移動看起來更加有趣。你可以找到一條路徑讓它們都沿著路徑移動，然後讓它們單獨沿著路徑移動，但這會導致這些單位中的一條直線或者單位會穿過其它單位前進。因此，稍微區分一下路徑它們就能平行地移動了。另外，還可以選取一個“領導”單元來沿著路徑移動，同時讓其它單元執行單獨編寫的“跟隨”行為。這個跟隨行為可以非常簡單，只要向著“領導”所處的方向前進，同時停留在一段距離之外，或者它就像鳥類成群結隊飛行。
多路徑點
即使給定了最優的路徑，玩家可能會偏愛其它不同的路徑。你應該允許玩家在路徑上標記路徑點：玩家可以點選通向目的地的路徑上二到三個路徑點，而不是簡單地點選目的地。（很多實時策略遊戲使用shift-點選來完成這項操作。）你當前有了三到四條較短的路徑來進行計算，同時你節省了一些時間。玩家對於整體的路徑安排同樣擁有部分的控制權，例如，你的遊戲導航找到了一條通向西部山地的路徑，但出於安全考慮，玩家希望停留在東部山地（靠近友軍防禦塔）。
在單位移動程式中的主要改變是，你將擁有一個目的地的列表，而不是一個單一的目的地。首先尋找一條到達第一個目的地的路徑，當你到達時，從列表中刪除它然後繼續尋找到達下一目的地的路徑。這種做法可以降低遊戲過程中的延時並且提高系統的吞吐量。