路徑規劃: a star， A星演算法詳解
本文版權歸原作者、譯者所有，我只是轉貼；如果侵害到您的權益，請聯絡我，我將刪除本文。
Amit's A star Page中譯文
譯序
這篇文章很適合A*演算法的初學者，可惜網上沒找到翻譯版的。本著好東西不敢獨享的想法，也為了鍛鍊一下英文，本人譯了這篇文章。
由於本人英文水平非常有限，六級考了兩次加一塊不超過370分，因此本譯文難免存在問題。不過也算是拋磚引玉，希望看到有更多的遊戲開發方面的優秀譯作出現，畢竟中文的優秀資料太少了，中國的遊戲開發者的路不好走。
本人能力有限，譯文中有小部分詞句實在難以翻譯，因此暫時保留英文原文放在譯文中。對於不敢確定翻譯是否準確的詞句，本人用圓括號保留了英文原文，讀者可以對照著加以理解。
A*演算法本身是很簡單的，因此原文中並沒有過多地討論A*演算法本身，而是花了較大的篇幅討論了用於儲存OPEN和CLOSED集的資料結構，以及A*演算法的變種和擴充套件。
程式設計實現A*是簡單的，讀者可以用STL對本文中的虛擬碼加以實現（本人已花一天時間實驗過基本的A*搜尋）。但是最重要的還是對A*本身的理解，這樣才可以在自己的遊戲中處理各種千變萬化的情況。
翻譯本文的想法產生於2006年5月，實際完成於2007年4月到6月，非常慚愧。
最後，本譯文僅供交流和參考，對於因本譯文放到網上而產生的任何問題，本人不負任何責任。
蔡鴻於南開大學軟體學院
2007年6月9日
原文地址：http://theory.stanford.edu/~amitp/GameProgramming/
相關連結：http://www-cs-students.stanford.edu/%7Eamitp/gameprog.html#Paths
我們嘗試解決的問題是把一個遊戲物件（game object）從出發點移動到目的地。路徑搜尋(Pathfinding)的目標是找到一條好的路徑——避免障礙物、敵人，並把代價（燃料，時間，距離，裝備，金錢等）最小化。運動（Movement）的目標是找到一條路徑並且沿著它行進。把關注的焦點僅集中於其中的一種方法是可能的。一種極端情況是，當遊戲物件開始移動時，一個老練的路徑搜尋器（pathfinder）外加一個瑣細的運動演算法（movement algorithm）可以找到一條路徑，遊戲物件將會沿著該路徑移動而忽略其它的一切。另一種極端情況是，一個單純的運動系統（movement-only system）將不會搜尋一條路徑（最初的“路徑”將被一條直線取代），取而代之的是在每一個結點處僅採取一個步驟，同時考慮周圍的環境。同時使用路徑搜尋(Pathfinding)和運動演算法（movement algorithm）將會得到最好的效果。
1 導言
移動一個簡單的物體（object）看起來是容易的。而路徑搜尋是複雜的。為什麼涉及到路徑搜尋就產生麻煩了？考慮以下情況：
物體（unit）最初位於地圖的底端並且嘗試向頂部移動。物體掃描的區域中(粉紅色部分)沒有任何東西顯示它不能向上移動，因此它持續向上移動。在靠近頂部時，它探測到一個障礙物然後改變移動方向。然後它沿著U形障礙物找到它的紅色的路徑。相反的，一個路徑搜尋器（pathfinder）將會掃描一個更大的區域（淡藍色部分），但是它能做到不讓物體(unit)走向凹形障礙物而找到一條更短的路徑(藍色路徑）。
然而你可以擴充套件一個運動演算法，用於對付上圖所示的障礙物。或者避免製造凹形障礙，或者把凹形出口標識為危險的(只有當目的地在裡面時才進去):
比起一直等到最後一刻才發現問題，路徑搜尋器讓你提前作出計劃。不帶路徑搜尋的運動(movement)可以在很多種情形下工作，同時可以擴充套件到更多的情形，但是路徑搜尋是一種更常用的解決更多問題的方法。
1.1 演算法
電腦科學教材中的路徑搜尋演算法在數學視角的圖上工作——由邊聯結起來的結點的集合。一個基於圖塊(tile)拼接的遊戲地圖可以看成是一個圖，每個圖塊(tile)是一個結點，並在每個圖塊之間畫一條邊：
目前，我會假設我們使用二維網格(grid)。稍後我將討論如何在你的遊戲之外建立其他型別的圖。
許多AI領域或演算法研究領域中的路徑搜尋演算法是基於任意(arbitrary)的圖設計的，而不是基於網格(grid-based)的圖。我們可以找到一些能使用網格地圖的特性的東西。有一些我們認為是常識，而演算法並不理解。例如，我們知道一些和方向有關的東西：一般而言，如果兩個物體距離越遠，那麼把其中一個物體向另一個移動將花越多的時間；並且我們知道地圖中沒有任何祕密通道可以從一個地點通向另一個地點。（我假設沒有，如果有的話，將會很難找到一條好的路徑，因為你並不知道要從何處開始。）
1.2 Dijkstra演算法與最佳優先搜尋
Dijkstra演算法從物體所在的初始點開始，訪問圖中的結點。它迭代檢查待檢查結點集中的結點，並把和該結點最靠近的尚未檢查的結點加入待檢查結點集。該結點集從初始結點向外擴充套件，直到到達目標結點。Dijkstra演算法保證能找到一條從初始點到目標點的最短路徑，只要所有的邊都有一個非負的代價值。（我說“最短路徑”是因為經常會出現許多差不多短的路徑。）在下圖中，粉紅色的結點是初始結點，藍色的是目標點，而類菱形的有色區域（注：原文是teal areas）則是Dijkstra演算法掃描過的區域。顏色最淡的區域是那些離初始點最遠的，因而形成探測過程（exploration）的邊境（frontier）：
最佳優先搜尋（BFS）演算法按照類似的流程執行，不同的是它能夠評估（稱為啟發式的）任意結點到目標點的代價。與選擇離初始結點最近的結點不同的是，它選擇離目標最近的結點。BFS不能保證找到一條最短路徑。然而，它比Dijkstra演算法快的多，因為它用了一個啟發式函式（heuristic function）快速地導向目標結點。例如，如果目標位於出發點的南方，BFS將趨向於導向南方的路徑。在下面的圖中，越黃的結點代表越高的啟發式值（移動到目標的代價高），而越黑的結點代表越低的啟發式值（移動到目標的代價低）。這表明了與Dijkstra 演算法相比，BFS執行得更快。
然而，這兩個例子都僅僅是最簡單的情況——地圖中沒有障礙物，最短路徑是直線的。現在我們來考慮前邊描述的凹型障礙物。Dijkstra演算法執行得較慢，但確實能保證找到一條最短路徑：
另一方面，BFS執行得較快，但是它找到的路徑明顯不是一條好的路徑：
問題在於BFS是基於貪心策略的，它試圖向目標移動儘管這不是正確的路徑。由於它僅僅考慮到達目標的代價，而忽略了當前已花費的代價，於是儘管路徑變得很長，它仍然繼續走下去。
結合兩者的優點不是更好嗎？1968年發明的A*演算法就是把啟發式方法（heuristic approaches）如BFS，和常規方法如Dijsktra演算法結合在一起的演算法。有點不同的是，類似BFS的啟發式方法經常給出一個近似解而不是保證最佳解。然而，儘管A*基於無法保證最佳解的啟發式方法，A*卻能保證找到一條最短路徑。
1.3 A*演算法
我將集中討論A*演算法。A*是路徑搜尋中最受歡迎的選擇，因為它相當靈活，並且能用於多種多樣的情形之中。
和其它的圖搜尋演算法一樣，A*潛在地搜尋圖中一個很大的區域。和Dijkstra一樣，A*能用於搜尋最短路徑。和BFS一樣，A*能用啟發式函式（注：原文為heuristic）引導它自己。在簡單的情況中，它和BFS一樣快。
在凹型障礙物的例子中，A*找到一條和Dijkstra演算法一樣好的路徑：
成功的祕決在於，它把Dijkstra演算法（靠近初始點的結點）和BFS演算法（靠近目標點的結點）的資訊塊結合起來。在討論A*的標準術語中，g(n)表示從初始結點到任意結點n的代價，h(n)表示從結點n到目標點的啟發式評估代價（heuristic estimated cost）。在上圖中，yellow(h)表示遠離目標的結點而teal(g)表示遠離初始點的結點。當從初始點向目標點移動時，A*權衡這兩者。每次進行主迴圈時，它檢查f(n)最小的結點n，其中f(n) = g(n) + h(n)。
2 啟發式演算法
啟發式函式h(n)告訴A*從任意結點n到目標結點的最小代價評估值。選擇一個好的啟發式函式是重要的。
2.1 A*對啟發式函式的使用
啟發式函式可以控制A*的行為：
- 一種極端情況，如果h(n)是0，則只有g(n)起作用，此時A*演變成Dijkstra演算法，這保證能找到最短路徑。
- 如果h(n)經常都比從n移動到目標的實際代價小（或者相等），則A*保證能找到一條最短路徑。h(n)越小，A*擴充套件的結點越多，執行就得越慢。
- 如果h(n)精確地等於從n移動到目標的代價，則A*將會僅僅尋找最佳路徑而不擴充套件別的任何結點，這會執行得非常快。儘管這不可能在所有情況下發生，你仍可以在一些特殊情況下讓它們精確地相等（譯者：指讓h(n)精確地等於實際值）。只要提供完美的資訊，A*會執行得很完美，認識這一點很好。
- 如果h(n)有時比從n移動到目標的實際代價高，則A*不能保證找到一條最短路徑，但它執行得更快。
- 另一種極端情況，如果h(n)比g(n)大很多，則只有h(n)起作用，A*演變成BFS演算法。
所以我們得到一個很有趣的情況，那就是我們可以決定我們想要從A*中獲得什麼。理想情況下（注：原文為At exactly the right point），我們想最快地得到最短路徑。如果我們的目標太低，我們仍會得到最短路徑，不過速度變慢了；如果我們的目標太高，那我們就放棄了最短路徑，但A*執行得更快。
在遊戲中，A*的這個特性非常有用。例如，你會發現在某些情況下，你希望得到一條好的路徑（"good" path）而不是一條完美的路徑（"perfect" path）。為了權衡g(n)和h(n)，你可以修改任意一個。
注:在學術上，如果啟發式函式值是對實際代價的低估，A*演算法被稱為簡單的A演算法（原文為simply A）。然而，我繼續稱之為A*，因為在實現上是一樣的，並且在遊戲程式設計領域並不區別A和A*。
2.2 速度還是精確度？
A*改變它自己行為的能力基於啟發式代價函式，啟發式函式在遊戲中非常有用。在速度和精確度之間取得折衷將會讓你的遊戲執行得更快。在很多遊戲中，你並不真正需要得到最好的路徑，僅需要近似的就足夠了。而你需要什麼則取決於遊戲中發生著什麼，或者運行遊戲的機器有多快。
假設你的遊戲有兩種地形，平原和山地，在平原中的移動代價是1而在山地則是3。A* is going to search three times as far along flat land as it does along mountainous land. 這是因為有可能有一條沿著平原到山地的路徑。把兩個鄰接點之間的評估距離設為1.5可以加速A*的搜尋過程。然後A*會將3和1.5比較，這並不比把3和1比較差。It is not as dissatisfied with mountainous terrain, so it won't spend as much time trying to find a way around it. Alternatively, you can speed up up A*'s search by decreasing the amount it searches for paths around mountains―just tell A* that the movement cost on mountains is 2 instead of 3. Now it will search only twice as far along the flat terrain as along mountainous terrain. Either approach gives up ideal paths to get something quicker.
速度和精確度之間的選擇前不是靜態的。你可以基於CPU的速度、用於路徑搜尋的時間片數、地圖上物體（units）的數量、物體的重要性、組（group）的大小、難度或者其他任何因素來進行動態的選擇。取得動態的折衷的一個方法是，建立一個啟發式函式用於假定通過一個網格空間的最小代價是1，然後建立一個代價函式（cost function）用於測量（scales）：
g’(n) = 1 + alpha * ( g(n) – 1 )
如果alpha是0，則改進後的代價函式的值總是1。這種情況下，地形代價被完全忽略，A*工作變成簡單地判斷一個網格可否通過。如果alpha是1，則最初的代價函式將起作用，然後你得到了A*的所有優點。你可以設定alpha的值為0到1的任意值。
你也可以考慮對啟發式函式的返回值做選擇：絕對最小代價或者期望最小代價。例如，如果你的地圖大部分地形是代價為2的草地，其它一些地方是代價為1的道路，那麼你可以考慮讓啟發式函式不考慮道路，而只返回2*距離。
速度和精確度之間的選擇並不是全域性的。在地圖上的某些區域，精確度是重要的，你可以基於此進行動態選擇。例如，假設我們可能在某點停止重新計算路徑或者改變方向，則在接近當前位置的地方，選擇一條好的路徑則是更重要的，因此為何要對後續路徑的精確度感到厭煩？或者，對於在地圖上的一個安全區域，最短路徑也許並不十分重要，但是當從一個敵人的村莊逃跑時，安全和速度是最重要的。（譯者注：譯者認為這裡指的是，在安全區域，可以考慮不尋找精確的最短路徑而取近似路徑，因此尋路快；但在危險區域，逃跑的安全性和逃跑速度是重要的，即路徑的精確度是重要的，因此可以多花點時間用於尋找精確路徑。）
2.3 衡量單位
A*計算f(n) = g(n) + h(n)。為了對這兩個值進行相加，這兩個值必須使用相同的衡量單位。如果g(n)用小時來衡量而h(n)用米來衡量，那麼A*將會認為g或者h太大或者太小，因而你將不能得到正確的路徑，同時你的A*演算法將執行得更慢。
2.4 精確的啟發式函式
如果你的啟發式函式精確地等於實際最佳路徑（optimal path），如下一部分的圖中所示，你會看到此時A*擴充套件的結點將非常少。A*演算法內部發生的事情是：在每一結點它都計算f(n) = g(n) + h(n)。當h(n)精確地和g(n)匹配（譯者注：原文為match）時，f(n)的值在沿著該路徑時將不會改變。不在正確路徑（right path）上的所有結點的f值均大於正確路徑上的f值（譯者注：正確路徑在這裡應該是指最短路徑）。如果已經有較低f值的結點，A*將不考慮f值較高的結點，因此它肯定不會偏離最短路徑。
2.4.1 預計算的精確啟發式函式
構造精確啟發函式的一種方法是預先計算任意一對結點之間最短路徑的長度。在許多遊戲的地圖中這並不可行。然後，有幾種方法可以近似模擬這種啟發函式：
- Fit a coarse grid on top of the fine grid. Precompute the shortest path between any pair of coarse grid locations.
- Precompute the shortest path between any pair of waypoints. This is a generalization of the coarse grid approach.
（譯者：此處不好翻譯，暫時保留原文）
然後新增一個啟發函式h’用於評估從任意位置到達鄰近導航點（waypoints）的代價。（如果願意，後者也可以通過預計算得到。）最終的啟發式函式可以是：
h(n) = h'(n, w1) + distance(w1, w2), h'(w2, goal)
或者如果你希望一個更好但是更昂貴的啟發式函式，則分別用靠近結點和目標的所有的w1,w2對對上式進行求值。（譯者注：原文為or if you want a better but more expensive heuristic, evaluate the above with all pairs w1, w2 that are close to the node and the goal, respectively.）
2.4.2 線性精確啟發式演算法
在特殊情況下，你可以不通過預計算而讓啟發式函式很精確。如果你有一個不存在障礙物和slow地形，那麼從初始點到目標的最短路徑應該是一條直線。
如果你正使用簡單的啟發式函式（我們不知道地圖上的障礙物），則它應該和精確的啟發式函式相符合（譯者注：原文為match）。如果不是這樣，則你會遇到衡量單位的問題，或者你所選擇的啟發函式型別的問題。
2.5 網格地圖中的啟發式演算法
在網格地圖中，有一些眾所周知的啟發式函式。
2.5.1 曼哈頓距離
標準的啟發式函式是曼哈頓距離（Manhattan distance）。考慮你的代價函式並找到從一個位置移動到鄰近位置的最小代價D。因此，我的遊戲中的啟發式函式應該是曼哈頓距離的D倍：
H(n) = D * (abs ( n.x – goal.x ) + abs ( n.y – goal.y ) )
你應該使用符合你的代價函式的衡量單位。
(Note: the above image has a tie-breaker added to the heuristic.}
（譯者注：曼哈頓距離——兩點在南北方向上的距離加上在東西方向上的距離，即D（I，J）=|XI-XJ|+|YI-YJ|。對於一個具有正南正北、正東正西方向規則佈局的城鎮街道，從一點到達另一點的距離正是在南北方向上旅行的距離加上在東西方向上旅行的距離因此曼哈頓距離又稱為計程車距離，曼哈頓距離不是距離不變數，當座標軸變動時，點間的距離就會不同——百度知道）
2.5.2 對角線距離
如果在你的地圖中你允許對角運動那麼你需要一個不同的啟發函式。（4 east, 4 north）的曼哈頓距離將變成8*D。然而，你可以簡單地移動（4 northeast）代替，所以啟發函式應該是4*D。這個函式使用對角線，假設直線和對角線的代價都是D：
h(n) = D * max(abs(n.x - goal.x), abs(n.y - goal.y))
如果對角線運動的代價不是D，但類似於D2 = sqrt(2) * D，則上面的啟發函式不準確。你需要一些更準確（原文為sophisticated）的東西：
h_diagonal(n) = min(abs(n.x - goal.x), abs(n.y - goal.y))
h_straight(n) = (abs(n.x - goal.x) + abs(n.y - goal.y))
h(n) = D2 * h_diagonal(n) + D * (h_straight(n) - 2*h_diagonal(n)))
這裡，我們計算h_diagonal(n)：沿著斜線可以移動的步數；h_straight(n)：曼哈頓距離；然後合併這兩項，讓所有的斜線步都乘以D2，剩下的所有直線步(注意這裡是曼哈頓距離的步數減去2倍的斜線步數)都乘以D。
2.5.3 歐幾里得距離
如果你的單位可以沿著任意角度移動（而不是網格方向），那麼你也許應該使用直線距離：
h(n) = D * sqrt((n.x-goal.x)^2 + (n.y-goal.y)^2)
然而，如果是這樣的話，直接使用A*時將會遇到麻煩，因為代價函式g不會match啟發函式h。因為歐幾里得距離比曼哈頓距離和對角線距離都短，你仍可以得到最短路徑，不過A*將執行得更久一些：
2.5.4 平方後的歐幾里得距離
我曾經看到一些A*的網頁，其中提到讓你通過使用距離的平方而避免歐幾里得距離中昂貴的平方根運算：
h(n) = D * ((n.x-goal.x)^2 + (n.y-goal.y)^2)
不要這樣做！這明顯地導致衡量單位的問題。當A*計算f(n) = g(n) + h(n)，距離的平方將比g的代價大很多，並且你會因為啟發式函式評估值過高而停止。對於更長的距離，這樣做會靠近g(n)的極端情況而不再計算任何東西，A*退化成BFS：
導致低效能的一個原因來自於啟發函式的ties（注：這個詞實在不知道應該翻譯為什麼）。當某些路徑具有相同的f值的時候，它們都會被搜尋（explored），儘管我們只需要搜尋其中的一條：
Ties in f values.
為了解決這個問題，我們可以為啟發函式新增一個附加值（譯者注：原文為small tie breaker）。附加值對於結點必須是確定性的（也就是說，不能是隨機的數），而且它必須讓f值體現區別。因為A*對f值排序，讓f值不同意味著只有一個"equivalent"的f值會被檢測。
一種新增附加值的方式是稍微改變（譯者注：原文為nudge）h的衡量單位。如果我們減少衡量單位（譯者注：原文為scale it downwards），那麼當我們朝著目標移動的時候f將逐漸增加。很不幸，這意味著A*傾向於擴充套件到靠近初始點的結點，而不是靠近目標的結點。我們可以增加衡量單位（譯者注：原文為scale it downwards scale h upwards slightly）（甚至是0.1%），A*就會傾向於擴充套件到靠近目標的結點。
heuristic *= (1.0 + p)
選擇因子p使得p < 移動一步（step）的最小代價 / 期望的最長路徑長度。假設你不希望你的路徑超過1000步（step），你可以使p = 1 / 1000。新增這個附加值的結果是，A*比以前搜尋的結點更少了。
Tie-breaking scaling added to heuristic.
當存在障礙物時，當然仍要在它們周圍尋找路徑，但要意識到，當繞過障礙物以後，A*搜尋的區域非常少：
Tie-breaking scaling added to heuristic, works nicely with obstacles.
Steven van Dijk建議，一個更直截了當的方法是把h傳遞到比較函式（comparison function）。當f值相等時，比較函式檢查h，然後新增附加值。
一個不同的新增附加值的方法是，傾向於從初始點到目標點的連線（直線）：
dx1 = current.x - goal.x
dy1 = current.y - goal.y
dx2 = start.x - goal.x
dy2 = start.y - goal.y
cross = abs(dx1*dy2 - dx2*dy1)
heuristic += cross*0.001
這段程式碼計算初始-目標向量（start to goal vector）和當前-目標向量（current point to goal vector）的向量叉積（vector cross-product）。When these vectors don't line up, the cross product will be larger.結果是，這段程式碼選擇的路徑稍微傾向於從初始點到目標點的直線。當沒有障礙物時，A*不僅搜尋很少的區域，而且它找到的路徑看起來非常棒：
Tie-breaking cross-product added to heuristic, produces pretty paths.
然而，因為這種附加值傾向於從初始點到目標點的直線路徑，當出現障礙物時將會出現奇怪的結果（注意這條路徑仍是最佳的，只是看起來很奇怪）：
Tie-breaking cross-product added to heuristic, less pretty with obstacles.
為了互動地研究這種附加值方法的改進，請參考James Macgill的A*確applet（http://www.ccg.leeds.ac.uk/james/aStar/ ）[如果連結無效，請使用這個映象（http://www.vision.ee.ethz.ch/~buc/astar/AStar.html）]（譯者注：兩個連結均無效）。使用“Clear”以清除地圖，選擇地圖對角的兩個點。當你使用“Classic A*”方法，你會看到附加值的效果。當你使用“Fudge”方法，你會看到上面給啟發函式新增叉積後的效果。
然而另一種新增附加值的方法是，小心地構造你的A*優先佇列，使新插入的具有特殊f值的結點總是比那些以前插入的具有相同f值的舊結點要好一些。
你也許也想看看能夠更靈活地（譯者注：原文為sophisticated）新增附加值的AlphA*演算法（http://home1.stofanet.dk/breese/papers.html），不過用這種演算法得到的路徑是否能達到最佳仍在研究中。AlphA*具有較好的適應性，而且可能比我在上面討論的附加值方法執行得都要好。然而，我所討論的附加值方法非常容易實現，所以從它們開始吧，如果你需要得到更好的效果，再去嘗試AlphA*。
2.5.6 區域搜尋
如果你想搜尋鄰近目標的任意不確定結點，而不是某個特定的結點，你應該建立一個啟發函式h’(x)，使得h’(x)為h1(x), h2(x), h3(x)。。。的最小值，而這些h1, h2, h3是鄰近結點的啟發函式。然而，一種更快的方法是讓A*僅搜尋目標區域的中心。一旦你從OPEN集合中取得任意一個鄰近目標的結點，你就可以停止搜尋並建立一條路徑了。
3.1 概略
如果不考慮具體實現程式碼，A*演算法是相當簡單的。有兩個集合，OPEN集和CLOSED集。其中OPEN集儲存待考查的結點。開始時，OPEN集只包含一個元素：初始結點。CLOSED集儲存已考查過的結點。開始時，CLOSED集是空的。如果繪成圖，OPEN集就是被訪問區域的邊境（frontier）而CLOSED集則是被訪問區域的內部（interior）。每個結點同時儲存其父結點的指標因此我們可以知道它是如何被找到的。
在主迴圈中重複地從OPEN集中取出最好的結點n（f值最小的結點）並檢查之。如果n是目標結點，則我們的任務完成了。否則，結點n被從OPEN集中刪除並加入CLOSED集。然後檢查它的鄰居n’。如果鄰居n’在CLOSED集中，那麼它是已經被檢查過的，所以我們不需要考慮它*；如果n’在OPEN集中，那麼它是以後肯定會被檢查的，所以我們現在不考慮它*。否則，把它加入OPEN集，把它的父結點設為n。到達n’的路徑的代價g(n’)，設定為g(n) + movementcost(n, n’)。
(*)這裡我忽略了一個小細節。你確實需要檢查結點的g值是否更小了，如果是的話，需要重新開啟（re-open）它。
OPEN = priority queue containing START
CLOSED = empty set
while lowest rank in OPEN is not the GOAL:
current = remove lowest rank item from OPEN
add current to CLOSED
for neighbors of current:
cost = g(current) + movementcost(current, neighbor)
if neighbor in OPEN and cost less than g(neighbor):
remove neighbor from OPEN, because new path is better
if neighbor in CLOSED and cost less than g(neighbor): **
remove neighbor from CLOSED
if neighbor not in OPEN and neighbor not in CLOSED:
set g(neighbor) to cost
add neighbor to OPEN
set priority queue rank to g(neighbor) + h(neighbor)
set neighbor's parent to current
reconstruct reverse path from goal to start
by following parent pointers
(**) This should never happen if you have an admissible heuristic. However in games we often have inadmissible heuristics.
3.2 原始碼
我自己的（舊的）C++A*程式碼是可用的：path.cpp (http://theory.stanford.edu/~amitp/ GameProgramming/path.cpp)和path.h (http://theory.stanford.edu/~amitp/GameProgramming/ path.h)，但是不容易閱讀。還有一份更老的程式碼（更慢的，但是更容易理解），和很多其它的A*實現一樣，它在Steve Woodcock'的遊戲AI頁面（http://www.gameai.com/ai.html）。
在網上，你能找到C，C++，Visual Basic ，Java(http://www.cuspy.com/software/pathfinder/ doc/)，Flash/Director/Lingo, C#(http://www.codeproject.com/csharp/CSharpPathfind.asp), Delphi, Lisp, Python, Perl, 和Prolog 實現的A*程式碼。一定的閱讀Justin Heyes-Jones的C++實現（http://www.geocities.com/jheyesjones/astar.html）。
3.3 集合的表示
你首先想到的用於實現OPEN集和CLOSED集的資料結構是什麼？如果你和我一樣，你可能想到“陣列”。你也可能想到“連結串列”。我們可以使用很多種不同的資料結構，為了選擇一種，我們應該考慮我們需要什麼樣的操作。
在OPEN集上我們主要有三種操作：主迴圈重複選擇最好的結點並刪除它；訪問鄰居結點時需要檢查它是否在集合裡面；訪問鄰居結點時需要插入新結點。插入和刪除最佳是優先佇列（http://members.xoom.com/killough/heaps.html）的典型操作。
選擇哪種資料結構不僅取決於操作，還取決於每種操作執行的次數。檢查一個結點是否在集合中這一操作對每個被訪問的結點的每個鄰居結點都執行一次。刪除最佳操作對每個被訪問的結點都執行一次。被考慮到的絕大多數結點都會被訪問；不被訪問的是搜尋空間邊緣（fringe）的結點。當評估資料結構上面的這些操作時，必須考慮fringe(F)的最大值。
另外，還有第四種操作，雖然執行的次數相對很少，但還是必須實現的。如果正被檢查的結點已經在OPEN集中（這經常發生），並且如果它的f值比已經在OPEN集中的結點要好（這很少見），那麼OPEN集中的值必須被調整。調整操作包括刪除結點（f值不是最佳的結點）和重插入。這兩個步驟必須被最優化為一個步驟，這個步驟將移動結點。
3.3.1 未排序陣列或連結串列
最簡單的資料結構是未排序陣列或連結串列。集合關係檢查操作（Membership test）很慢，掃描整個結構花費O(F)。插入操作很快，新增到末尾花費O(1)。查詢最佳元素（Finding the best element）很慢，掃描整個結構花費O(F)。對於陣列，刪除最佳元素（Removing the best element）花費O(F)，而連結串列則是O(1)。調整操作中，查詢結點花費O(F)，改變值花費O(1)。
3.3.2 排序陣列
為了加快刪除最掛操作，可以對陣列進行排序。集合關係檢查操作將變成O(log F)，因為我們可以使用折半查詢。插入操作會很慢，為了給新元素騰出空間，需要花費 O(F)以移動所有的元素。查詢最佳元素操作會很快，因為它已經在末尾了所以花費是O(1)。如果我們保證最佳排序至陣列的尾部（best sorts to the end of the array），刪除最佳元素操作花費將是O(1)。調整操作中，查詢結點花費O(logF)，改變值/位置花費O(F)。
3.3.3 排序連結串列
在排序陣列中，插入操作很慢。如果使用連結串列則可以加速該操作。集合關係檢查操作很慢，需要花費O(F)用於掃描連結串列。插入操作是很快的，插入新元素只花費O(1)時間，但是查詢正確位置需要花費O(F)。查詢最佳元素很快，花費O(1)時間，因為最佳元素已經在表的尾部。刪除最佳元素也是O(1)。調整操作中，查詢結點花費O(F)，改變值/位置花費O(1)。
3.3.4 排序跳錶
在未排序連結串列中查詢元素是很慢的。如果用跳錶（http://en.wikipedia.org/wiki/Skip_list）代替連結串列的話，可以加速這個操作。在跳錶中，如果有排序鍵（sort key）的話，集合關係檢查操作會很快：O(log F)。如果你知道在何處插入的話，和連結串列一樣，插入操作也是O(1)。如果排序鍵是f，查詢最佳元素很快，達到O(1)，刪除一個元素也是O(1)。調整操作涉及到查詢結點，刪除結點和重插入。
如果我們用地圖位置作為跳錶的排序鍵，集合關係檢查操作將是O(log F)。在完成集合關係檢查後，插入操作是O(1)。查詢最佳元素是O(F)，刪除一個結點是O(1)。因為集合關係檢查更快，所以它比未排序連結串列要好一些。
如果我們用f值作為跳錶的排序鍵，集合關係檢查操作將是O(F)。插入操作是O(1)。查詢最佳元素是O(1)，刪除一個結點是O(1)。這並不比排序連結串列好。
3.3.5 索引陣列
如果結點的集合有限並且數目是適當的，我們可以使用直接索引結構，索引函式i(n)把結點n對映到一個數組的索引。未排序與排序陣列的長度等於OPEN集的最大值，和它們不同，對所有的n，索引陣列的長度總是等於max(i(n))。如果你的函式是密集的（沒有不被使用的索引），max(i(n))將是你地圖中結點的數目。只要你的地圖是網格的，讓索引函式密集就是容易的。
假設i(n)是O(1)的，集合關係檢查將花費O(1)，因為我們幾乎不需要檢查Array[i(n)]是否包含任何資料。Insertion is O(1), as we just ste Array[i(n)].查詢和刪除最佳操作是O(numnodes)，因為我們必須搜尋整個結構。調整操作是O(1)。
3.3.6 雜湊表
索引陣列使用了很多記憶體用於儲存不在OPEN集中的所有結點。一個選擇是使用雜湊表。雜湊表使用了一個雜湊函式h(n)把地圖上每個結點對映到一個雜湊碼。讓雜湊表的大小等於N的兩倍，以使發生衝突的可能性降低。假設h(n) 是O(1)的，集體關係檢查操作花費O(1)；插入操作花費O(1)；刪除最佳元素操作花費O(numnodes)，因為我們需要搜尋整個結構。調整操作花費O(1)。
3.3.7 二元堆
一個二元堆（不要和記憶體堆混淆）是一種儲存在陣列中的樹結構。和許多普通的樹通過指標指向子結點所不同，二元堆使用索引來查詢子結點。C++ STL包含了一個二元堆的高效實現，我在我自己的A*程式碼中使用了它。
在二元堆中，集體關係檢查花費O(F)，因為你必須掃描整個結構。插入操作花費O(log F)而刪除最佳操作花費也是O(log F)。調整操作很微妙（tricky），花費O(F)時間找到節點，並且很神奇，只用O(log F)來調整。
我的一個朋友（他研究用於最短路徑演算法的資料結構）說，除非在你的fringe集裡有多於10000個元素，否則二元堆是很不錯的。除非你的遊戲地圖特別大，否則你不需要更復雜的資料結構（如multi-level buckets（http://www-cs-students.stanford.edu/~csilvers/））。你應該儘可能不用Fibonacci 堆（http://www.star-lab.com/goldberg/pub/neci-tr-96-062.ps），因為雖然它的漸近複雜度很好，但是執行起來很慢，除非F足夠大。
3.3.8 伸展樹
堆是一種基於樹的結構，它有一個期望的O(log F)代價的時間操作。然而，問題是在A*演算法中，通常的情況是，一個代價小的節點被移除（花費O(log F)的代價，因為其他結點必須從樹的底部向上移動），而緊接著一些代價小的節點被新增（花費O(log F)的代價，因為這些結點被新增到底部並且被移動到最頂部）。在這裡，堆的操作在預期的情況下和最壞情況下是一樣的。如果我們找到這樣一種資料結構，最壞情況還是一樣，而預期的情況好一些，那麼就可以得到改進。
伸展樹（Splay tree）是一種自調整的樹結構。任何對樹結點的訪問都嘗試把該結點推到樹的頂部（top）。這就產生了一個快取效果（"caching" effect）：很少被使用的結點跑到底部（bottom）去了並且不減慢操作（don't slow down operations）。你的splay樹有多大並不重要，因為你的操作僅僅和你的“cache size”一樣慢。在A*中，低代價的結點使用得很多，而高代價結點經常不被使用，所以高代價結點將會移動到樹的底部。
使用伸展樹後，集體關係檢查，插入，刪除最佳和調整操作都是期望的O(log F)（注：原文為expected O(log F) ），最壞情況是O(F)。然而有代表性的是，快取過程（caching）避免了最壞情況的發生。Dijkstra演算法和帶有低估的啟發函式（underestimating heuristic）的A*演算法卻有一些特性讓伸展樹達不到最優。特別是對結點n和鄰居結點n’來說，f(n') >= f(n)。當這發生時，也許插入操作總是發生在樹的同一邊結果是使它失去了平衡。我沒有試驗過這個。
還有一種比堆好的資料結構。通常你可以限制優先佇列中值的範圍。給定一個限定的範圍，經常會存在更好的演算法。例如，對任意值的排序可以在O(N log N)時間內完成，但當固定範圍時，桶排序和基數排序可以在O(N)時間內完成。
我們可以使用HOT（Heap On Top）佇列(http://www.star-lab.com/goldberg/pub /neci-tr-97-104.ps）來利用f(n') >= f(n)，其中n’是n的一個鄰居結點。我們刪除f(n)值最小的結點n，插入滿足f(n) <= f(n') <= f(n) + delta的鄰居n'，其中delta <= C。常數C是從一結點到鄰近結點代價改變數的最大值。因為f(n)是OPEN集中的最小f值，並且正要被插入的所有結點都小於或等於f(n) + delta，我們知道OPEN集中的所有f值都不超過一個0..delta的範圍。在桶/基數排序中，我們可以用“桶”（buckets）對OPEN集中的結點進行排序。
使用K個桶，我們把O(N)的代價降低到平均O(N/K)。通過HOT佇列，頂端的桶使用二元堆而所有其他的桶都是未排序陣列。因而，對頂部的桶，集合關係檢查代價是預期的O(F/K)，插入和刪除最佳是O(log (F/K))。對其他桶，集合關係檢查是O(F/K)，插入是O(1)，而刪除最佳根本不發生！如果頂端的桶是空的，那麼我們必須把下一個桶即未排序陣列轉換為二元堆。這個操作（“heapify”）可以在O(F/K)時間內完成。在調整操作中，刪除是O(F/K)，然後插入是O(log (F/K))或O(1)。
在A*中，我們加入OPEN集中的許多結點實際上根本是不需要的。在這方面HOT佇列很有優勢，因為不需要的元素的插入操作只花費O(1)時間。只有需要的元素被heapified（代價較低的那些）。唯一一個超過O(1)的操作是從堆中刪除結點，只花費O(log (F/K))。
另外，如果C比較小，我們可以只讓K = C，則對於最小的桶，我們甚至不需要一個堆，國為在一個桶中的所有結點都有相同的f值。插入和刪除最佳都是O(1)時間！有人研究過，HOT佇列在至多在OPEN集中有800個結點時和堆一樣快，並且如果OPEN集中至多有1500個結點，則比堆快20%。我期望隨著結點的增加，HOT佇列也更快。
HOT佇列的一個簡單的變化是一個二層佇列（two-level queue）：把好的結點放進一個數據結構（堆或陣列）而把壞的結點放進另一個數據結構（陣列或連結串列）。因為大多數進入OPEN集中的結點都“壞的”，它們從不被檢查，因而把它們放進出一個大陣列是沒有害處的。
注意有一點很重要，我們並不是僅僅關心漸近的行為（大O符號）。我們也需要關心小常數（low constant）下的行為。為了說明原因，考慮一個O(log F)的演算法，和另一個O(F)的演算法，其中F是堆中元素的個數。也許在你的機器上，第一個演算法的實現花費10000*log(F)秒，而另一個的實現花費2*F秒。當F=256時，第一個演算法將花費80000秒而第二個演算法花費512秒。在這種情況下，“更快”的演算法花費更多的時間，而且只有在當F>200000時才能執行得更快。
你不能僅僅比較兩個演算法。你還要比較演算法的實現。同時你還需要知道你的資料的大小（size）。在上面的例子中，第一種實現在F>200000時更快，但如果在你的遊戲中，F小於30000，那麼第二種實現好一些。
基本資料結構沒有一種是完全合適的。未排序陣列或者連結串列使插入操作很快而集體關係檢查和刪除操作非常慢。排序陣列或者連結串列使集體關係檢查稍微快一些，刪除（最佳元素）操作非常快而插入操作非常慢。二元堆讓插入和刪除操作稍微快一些，而集體關係檢查則很慢。伸展樹讓所有操作都快一些。HOT佇列讓插入操作很快，刪除操作相當快，而集體關係檢查操作稍微快一些。索引陣列讓集體關係檢查和插入操作非常快，但是刪除操作不可置信地慢，同時還需要花費很多記憶體空間。雜湊表和索引陣列類似，但在普通情況下，它花費的記憶體空間少得多，而刪除操作雖然還是很慢，但比索引陣列要快。
關於更高階的優先佇列的資料和實現，請參考Lee Killough的優先佇列頁面（http://members.xoom.com/killough/heaps.html）。
為了得到最佳效能，你將希望使用混合資料結構。在我的A*程式碼中，我使用一個索引陣列從而集合關係檢查是O(1)的，一個二元堆從而插入操作和刪除最佳都是O(log F)的。對於調整操作，我使用索引陣列從而花費O(1)時間檢查我是否真的需要進行調整（通過在索引陣列中儲存g值），然後在少數確實需要進行調整的情況中，我使用二元堆從而調整操作花費O(F)時間。你也可以使用索引陣列儲存堆中每個結點的位置，這讓你的調整操作變成O(log F)。
3.4 與遊戲迴圈的互動
互動式的（尤其是實時的）遊戲對最佳路徑的計算要求很高。能夠得到一個解決方案比得到最佳方案可能更重要。然而在所有其他因素都相同的情況下，短路徑比長路徑好。
一般來說，計算靠近初始結點的路徑比靠近目標結點的路徑更重要一些。立即開始原理（The principle of immediate start）：讓遊戲中的物體儘可能快地開始行動，哪怕是沿著一條不理想的路徑，然後再計算一條更好的路徑。在實時遊戲中，應該更多地關注A*的延遲情況（latency）而不是吞吐量（throughput）。
可以對物體程式設計讓它們根據自己的本能（簡單行為）或者智力（一條預先計算好的路徑）來行動。除非它們的智力告訴它們怎麼行動，否則它們就根據自己的本能來行動（這是實際上使用的方法，並且Rodney Brook在他的機器人體系結構中也用到）。和立即計算所有路徑所不同，讓遊戲在每一個，兩個，或者三個迴圈中搜索一條路徑。讓物體在開始時依照本能行動(可能僅僅是簡單地朝著目標直線前進)，然後才為它們尋找路徑。這種方法讓讓路徑搜尋的代價趨於平緩，因此它不會集中發生在同一時刻。
3.4.1 提前退出
可以從A*演算法的主迴圈中提前退出來同時得到一條區域性路徑。通常，當找到目標結點時，主迴圈就退出了。然而，在此之前的任意結點，可以得到一條到達OPEN中當前最佳結點的路徑。這個結點是到達目標點的最佳選擇，所以它是一個理想的中間結點（原文為so it's a reasonable place to go）。
可以提前退出的情況包括檢查了一定數量的結點，A*演算法已經運行了幾毫秒時間，或者掃描了一個離初始點有些距離的結點。當使用路徑拼接時，應該給被拼接的路徑一個比全路徑（full path）小的最大長度。
3.4.2 中斷演算法
如果需要進行路徑搜尋的物體較少，或者如果用於儲存OPEN和CLOSED集的資料結構較小，那麼儲存演算法的狀態是可行的，然後退出到遊戲迴圈繼續運行遊戲。
3.4.3 組運動
路徑請求並不是均勻分佈的。即時策略遊戲中有一個常見的情況，玩家會選擇多個物體並命令它們朝著同樣的目標移動。這給路徑搜尋系統以沉重的負載。
在這種情況下，為某個物體尋找到的路徑對其它物體也是同樣有用的。一種方法是，尋找一條從物體的中心到目的地中心的路徑P。對所有物體使用該路徑的絕大部分，對每一個物體，前十步和後十步使用為它自己尋找的路徑。物體i得到一條從它的開始點到P[10]的路徑，緊接著是共享的路徑P[10..len(P)-10]，最後是從P[len(P)-10]到目的地的路徑。
為每個物體尋找的路徑是較短的（平均步數大約是10），而較長的路徑被共享。大多數路徑只尋找一次並且為所有物體所共享。然而，當玩家們看到所有的物體都沿著相同的路徑移動時，將對遊戲失去興趣。為了對系統做些改進，可以讓物體稍微沿著不同的路徑運動。一種方法是選擇鄰近結點以改變路徑。
另一種方法是讓每個物體都意識到其它物體的存在（或許是通過隨機選擇一個“領導”物體，或者是通過選擇一個能夠最好地意識到當前情況的物體），同時僅僅為領導尋路。然後用flocking演算法讓它們以組的形式運動。
然而還有一種方法是利用A*演算法的中間狀態。這個狀態可以被朝著相同目標移動的多個物體共享，只要物體共享相同的啟發式函式和代價函式。當主迴圈退出時，不要消除OPEN和CLOSED集；用A*上一次的OPEN和CLOSED集開始下一次的迴圈（下一個物體的開始位置）。（這可以被看成是中斷演算法和提前退出部分的一般化）
3.4.4 細化
如果地圖中沒有障礙物，而有不同代價的地形，那麼可以通過低估地形的代價來計算一條初始路徑。例如，如果草地的代價是1，山地代價是2，山脈的代價是3，那麼A*會考慮通過3個草地以避免1個山脈。通過把草地看成1，山地看成1.1，而山脈看成1.2來計算初始路徑，A*將會用更少的時間去設法避免山脈，而且可以更快地找到一條路徑（這接近於精確啟發函式的效果）。一旦找到一條路徑，物體就可以開始移動，遊戲迴圈就可以繼續了。當多餘的CPU時間是可用的時候，可以用真實的移動代價去計算更好的路徑。
4 A*演算法的變種
在A*的主迴圈中，OPEN集儲存所有需要檢查的結點。Beam Search是A*演算法的一個變種，這種演算法限定了OPEN集的尺寸。如果OPEN集變得過大，那些沒有機會通向一條好的路徑的結點將被拋棄。缺點是你必須讓排序你的集合以實現這個，這限制了可供選擇的資料結構。
4.2 迭代深化
迭代深化是一種在許多AI演算法中使用的方法，這種方法從一個近似解開始，逐漸得到更精確的解。該名稱來源於遊戲樹搜尋，需要檢視前面幾步（比如在象棋裡），通過檢視前面更多步來提高樹的深度。一旦你的解不再有更多的改變或者改善，就可以認為你已經得到足夠好的解，當你想要進一步精確化時，它不會再有改善。在ID-A*中，深度是f值的一個cutoff。當f的值太大時，結點甚至將不被考慮（例如，它不會被加入OPEN集中）。第一次迭代只處理很少的結點。此後每一次迭代，訪問的結點都將增加。如果你發現路徑有所改善，那麼就繼續增加cutoff，否則就可以停止了。更多的細節請參考這些關於ID-A*的資料：http://www.apl.jhu.edu/~hall/AI-Programming/IDA-Star.html。
我本人認為在遊戲地圖中沒有太大的必要使用ID-A*尋路。ID演算法趨向於增加計算時間而減少記憶體需求。然而在地圖路徑搜尋中，“結點”是很小的——它們僅僅是座標而已。我認為不儲存這些結點以節省空間並不會帶來多大改進。
4.3 動態衡量
在動態衡量中，你假設在開始搜尋時，最重要的是訊速移動到任意位置；而在搜尋接近結束時，最重要的是移動到目標點。
f(p) = g(p) + w(p) * h(p)
啟發函式中帶有一個權值（weight）（w>=1）。當你接近目標時，你降低這個權值；這降低了啟發函式的重要性，同時增加了路徑真實代價的相對重要性。
4.4 頻寬搜尋
頻寬搜尋（Bandwidth Search）有兩個對有些人也許有用的特性。這個變種假設h是過高估計的值，但不高於某個數e。如果這就是你遇到的情況，那麼你得到的路徑的代價將不會比最佳路徑的代價超過e。重申一次，你的啟發函式設計的越好，最終效果就越好。
另一個特性是，你可以丟棄OPEN集中的某些結點。當h+d比路徑的真實代價高的時候（對於某些d），你可以丟棄那些f值比OPEN集中的最好結點的f值高至少e+d的結點。這是一個奇怪的特性。對於好的f值你有一個“範圍”（"band"），任何在這個範圍之外的結點都可以被丟棄掉，因為這個結點肯定不會在最佳路徑上。
好奇地（Curiously），你可以對這兩種特性使用不同的啟發函式，而問題仍然可以得到解決。使用一個啟發函式以保證你得到的路徑不會太差，另一個用於檢查從OPEN集中去掉哪些結點。
4.5 雙向搜尋
與從開始點向目標點搜尋不同的是，你也可以並行地進行兩個搜尋——一個從開始點向目標點，另一個從目標點向開始點。當它們相遇時，你將得到一條好的路徑。
這聽起來是個好主意，但我不會給你講很多內容。雙向搜尋的思想是，搜尋過程生成了一棵在地圖上散開的樹。一棵大樹比兩棵小樹差得多，所以最好是使用兩棵較小的搜尋樹。然而我的試驗表明，在A*中你得不到一棵樹，而只是在搜尋地圖中當前位置附近的區域，但是又不像Dijkstra演算法那樣散開。事實上，這就是讓A*演算法執行得如此快的原因——無論你的路徑有多長，它並不進行瘋狂的搜尋，除非路徑是瘋狂的。它只嘗試搜尋地圖上小範圍的區域。如果你的地圖很複雜，雙向搜尋會更有用。
面對面的方法（The front-to-front variation）把這兩種搜尋結合在一起。這種演算法選擇一對具有最好的g(start,x) + h(x,y) + g(y,goal)的結點，而不是選擇最好的前向搜尋結點——g(start,x) + h(x,goal)，或者最好的後向搜尋結點——g(y,goal) + h(start,y)。
Retargeting方法不允許前向和後向搜尋同時發生。它朝著某個最佳的中間結點執行前向搜尋一段時間，然後再朝這個結點執行後向搜尋。然後選擇一個後向最佳中間結點，從前向最佳中間結點向後向最佳中間結點搜尋。一直進行這個過程，直到兩個中間結點碰到一塊。
4.6 動態A*與終身計劃A*
有一些A*的變種允許當初始路徑計算出來之後，世界發生改變。D*用於當你沒有全域性所有資訊的時候。如果你沒有所有的資訊，A*可能會出錯；D*的貢獻在於，它能糾正那些錯誤而不用過多的時間。LPA*用於代價會改變的情況。在A*中，當地圖發生改變時，路徑將變得無效；LPA*可以重新使用之前A*的計算結果併產生新的路徑。然而，D*和LPA*都需要很多記憶體——用於執行A*並儲存它的內部資訊（OPEN和CLOSED集，路徑樹，g值），當地圖發生改變時，D*或者LPA*會告訴你，是否需要就地圖的改變對路徑作調整。在一個有許多運動著的物體的遊戲中，你經常不希望儲存所有這些資訊，所以D*和LPA*在這裡並不適用。它們是為機器人技術而設計的，這種情況下只有一個機器人——你不需要為別的機器人尋路而重用記憶體。如果你的遊戲只有一個或者少數幾個物體，你可以研究一下D*或者LPA*。
- Overview of D*（http://www.frc.ri.cmu.edu/~axs/dynamic_plan.html）
- D* Paper 1（http:// http://www.frc.ri.cmu.edu/~axs/doc/icra94.ps）
- D* Paper 2（http:// http://www.frc.ri.cmu.edu/~axs/doc/ijcai95.ps）
5 處理運動障礙物
一個路徑搜尋演算法沿著固定障礙物計算路徑，但是當障礙物會運動時情況又怎樣？當一個物體到達一個特寫的位置，原來的障礙物也許不再在那兒了，或者一個新的障礙物也許到達那兒。處理該問題的一個方法是放棄路徑搜尋而使用運動演算法（movement algorithms）替代，這就不能look far ahead；這種方法會在後面的部分中討論。這一部分將對路徑搜尋方法進行修改從而解決運動障礙物的問題。
5.1 重新計算路徑
當時間漸漸過去，我們希望遊戲世界有所改變。以前搜尋到的一條路徑到現在也許不再是最佳的了。對舊的路徑用新的資訊進行更新是有價值的。以下規則可以用於決定什麼時候需要重新計算路徑：
- 每N步：這保證用於計算路徑的資訊不會舊於N步。
- 任何可以使用額外的CPU時間的時候：這允許動態調整路徑的性質；在物體數量多時，或者運行遊戲的機器比較慢時，每個物體對CPU的使用可得到減少。
- 當物體拐彎或者跨越一個導航點（waypoint）的時候。
- 當物體附近的世界改變了的時候。
重計算路徑的主要缺點是許多路徑資訊被丟棄了。例如，如果路徑是100步長，每10步重新計算一次，路徑的總步數將是100+90+80+70+60+50+40+30+20+10 = 550。對M步長的路徑，大約需要計算M^2步。因此如果你希望有許多很長的路徑，重計算不是個好主意。重新使用路徑資訊比丟棄它更好。
5.2 路徑拼接
當一條路徑需要被重新計算時，意味著世界正在改變。對於一個正在改變的世界，對地圖中當前鄰近的區域總是比對遠處的區域瞭解得更多。因此，我們應該集中於在附近尋找好的路徑，同時假設遠處的路徑不需要重新計算，除非我們接近它。與重新計算整個路徑不同，我們可以重新計算路徑的前M步：
- 令p[1]..p[N]為路徑（N步）的剩餘部分
- 為p[1]到p[M]計算一條新的路徑
- 把這條新路徑拼接（Splice）到舊路徑：把p[1]..p[M]用新的路徑值代替
因為p[1]和p[M]比分開的M步小（原文：Since p[1] and p[M] are fewer than M steps apart），看起來新路徑不會很長。不幸的是，新的路徑也許很長而且不夠好。上面的圖顯示了這種情況。最初的紅色路徑是1-2-3-4，褐色的是障礙物。如果我們到達2並且發現從2到達3的路徑被封鎖了，路徑拼接技術會把2-3用2-5-3取代，結果是物體沿著路徑1-2-5-3-4運動。我們可以看到這不是一條好的路徑，藍色的路徑1-2-5-4是一條更好的路徑。
通常可以通過檢視新路徑的長度檢測到壞的路徑。如果這嚴格大於M，就可能是不好的。一個簡單的解決方法是，為搜尋演算法設定一個最大路徑長度。如果找不到一條短的路徑，演算法返回錯誤程式碼；這種情況下，用重計算路徑取代路徑拼接，從而得到路徑1-2-5-4.。
對於其它情況，對於N步的路徑，路徑拼接會計算2N或者3N步，這取決於拼接新路徑的頻率。對於對世界的改變作反應的能力而言，這個代價是相當低的。令人吃驚的是這個代價和拼接的步數M無關。M不影響CPU時間，而控制了響應和路徑質量的折衷。如果M太大，物體的移動將不能快速對地圖的改變作出反應。如果M太小，拼接的路徑可能太短以致不能正確地繞過障礙物；許多不理想的路徑（如1-2-5-3-4）將被找到。嘗試不同的M值和不同的拼接標準(如每3/4 M步)，看看哪一種情況對你的地圖最合適。
路徑拼接確實比重計算路徑要快，但它不能對路徑的改變作出很好的反應。經常可以發現這種情況並用路徑重計算來取代。也可以調整一些變數，如M和尋找新路徑的時機，所以可以對該方法進行調整(甚至在執行時)以用於不同的情況。
Note：Bryan Stout 有兩個演算法，Patch-One和Patch-All，他從路徑拼接中得到靈感，並在實踐中執行得很好。他出席了GDC 2007（https://www.cmpevents.com/GD07/a.asp?option =C &V=11& SessID=4608）；一旦他把資料放在網上，我將連結過去。
Implementation Note：
反向儲存路徑，從而刪除路徑的開始部分並用不同長度的新路徑拼接將更容易，因為這兩個操作都將在陣列的末尾進行。本質上你可以把這個陣列看成是堆疊因為頂部的元素總是下一個要使用的。
5.3 監視地圖變化
與間隔一段時間重計算全部或部分路徑不同的是，可以讓地圖的改變觸發一次重計算。地圖可以分成區域，每個物體都可以對某些區域感興趣（可以是包含部分路徑的所有區域，也可以只是包含部分路徑的鄰近區域）。當一個障礙物進入或者離開一個區域，該區域將被標識為已改變，所有對該區域感興趣的物體都被通知到，所以路徑將被重新計算以適應障礙物的改變。
這種技術有許多變種。例如，可以每隔一定時間通知物體，而不是立即通知物體。多個改變可以成組地觸發一個通知，因此避免了額外的重計算。另一個例子是，讓物體檢查區域，而不是讓區域通知物體。
監視地圖變化允許當障礙物不改變時物體避免重計算路徑，所以當你有許多區域並不經常改變時，考慮這種方法。