雖然A*（讀作A星）演算法對初學者來說是比較深奧難懂，但是一旦你找到門路了，它又會變得非常簡單。網上有很多解釋A*演算法的文章，但是大多數是寫給那些有一定基礎的人看的，而您看到的這一篇呢，是真正寫給菜鳥的。

本篇文章並不想給這個演算法題目作一些權威性論斷，而是闡述它的基本原理，併為你理解更多相關資料與討論打下基礎。文章末尾給出了一些比較好的連結，放在“進階閱讀”一節之後。

最後，本文不是程式設計規範，你將可能使這裡講述的東西編寫成任何計算機語言。在本文的末尾我還給出了一個例子程式包的下載連結，也許正合你意。在這個包中有C++和Blitz Basic兩個版本的程式程式碼，如果你只是想看看A*演算法是如何運作的，該包中也有可直接執行的檔案

[圖一]
　
你首先會注意到我們把這一塊搜尋區域分成了一個一個的方格，如此這般，使搜尋區域簡單化，正是尋找路徑的第一步。這種方法將我們的搜尋區域簡化成了一個普通的二維陣列。陣列中的每一個元素表示對應的一個方格，該方格的狀態被標記為可通過的和不可通過的。通過找出從A點到B點所經過的方格，就能得到AB之間的路徑。當路徑找出來以後，這個人就可以從一個格子中央移動到另一個格子中央，直到抵達目的地。

接下來，我們在開放列表中選一個相鄰方格並再重複幾次如前所述的過程。但是我們該選哪一個方格呢？具有最小F值的那個。

路徑排序

決定哪些方格會形成路徑的關鍵是下面這個等式：
F = G + H
這裡

• 
  G＝從起點A沿著已生成的路徑到一個給定方格的移動開銷。
• 
  H＝從給定方格到目的方格的估計移動開銷。這種方式常叫做試探，有點困惑人吧。其實之所以叫做試探法是因為這只是一個猜測。在找到路徑之前我們實際上並不知道實際的距離，因為任何東西都有可能出現在半路上（牆啊，水啊什麼的）。本文中給出了一種計算H值的方法，網上還有很多其他文章介紹的不同方法。

我們要的路徑是通過反覆遍歷開放列表並選擇具有最小F值的方格來生成的。本文稍後將詳細討論這個過程。我們先進一步看看如何計算那個等式。

如前所述，G是從起點A沿著已生成的路徑到一個給定方格的移動開銷，在本例中，我們指定每一個水平或者垂直移動的開銷為10，對角線移動的開銷為14。因為對角線的實際距離是2的平方根（別嚇到啦），或者說水平及垂直移動開銷的1.414倍。為了簡單起見我們用了10和14這兩個值。比例大概對就好，我們還因此避免了平方根和小數的計算。這倒不是因為我們笨或者說不喜歡數學，而是因為對電腦來說，計算這樣的數字也要快很多。不然的話你會發現尋找路徑會非常慢。

我們要沿特定路徑計算給定方格的G值，辦法就是找出該方格的父方格的G值，並根據與父方格的相對位置（斜角或非斜角方向）來給這個G值加上14或者10。在本例中這個方法將隨著離起點方格越來越遠計算的方格越來越多而用得越來越多。

有很多方法可以用來估計H值。我們用的這個叫做曼哈頓（Manhattan）方法，即計算通過水平和垂直方向的平移到達目的地所經過的方格數乘以10來得到H值。之所以叫Manhattan方法是因為這就像計算從一個地方移動到另一個地方所經過的城市街區數一樣，而通常你是不能斜著穿過街區的。重要的是，在計算H值時並不考慮任何障礙物。因為這是對剩餘距離的估計值而不是實際值（通常是要保證估計值不大於實際值――譯者注）。這就是為什麼這個方式被叫做試探法的原因了。想要了解更多些嗎？這裡還有更多式子和關於試探法的額外說明。

G和H相加就得到了F。第一步搜尋所得到的結果如下圖所示。每個方格里都標出了F、G和H值。如起點方格右側的方格標出的，左上角顯示的是F值，左下角是G值，右下角是H值。

我們來看看這些方格吧。在有字母的方格中，G＝10，這是因為它在水平方向上離起點只有一個方格遠。起點緊挨著的上下左右都具有相同的G值10。對角線方向的方塊G值都是14。

H值通過估算到紅色目標方格的曼哈頓距離而得出。用這種方法得出的起點右側方格到紅色方格有3個方格遠，則該方格H值就是30。上面那個方格有4個方格遠（注意只能水平和垂直移動），H就是40。你可以大概看看其他方格的H值是怎麼計算出來的。

每一個方格的F值，當然就不過是G和H值之和了。

繼續搜尋

為了繼續搜尋，我們簡單的從開放列表中選擇具有最小F值的方格，然後對選中的方格進行如下操作：

4.
將其從開放列表中移除，並加到封閉列表中。
5.
檢驗所有的相鄰方格，忽略那些不可通過的或者已經在封閉列表裡的方格。如果這個相鄰方格不在開放列表中，就把它新增進去。並將當前選定方格設為新添方格的父方格。
6.
如果某個相鄰方格已經在開放列表中了（意味著已經探測過，而且已經設定過父方格――譯者），就看看有沒有到達那個方格的更好的路徑。也就是說，如果從當前選中方格到那個方格，會不會使那個方格的G值更小。如果不能，就不進行任何操作。
相反的，如果新路徑的G值更小，就將該相鄰方格的父方格重設為當前選中方格。（在上圖中是改變其指標的方向為指向選中方格。最後，重新計算那個相鄰方格的F和G值。如果你看糊塗了，下面會有圖解說明。

好啦，咱們來看看具體點的例子。在初始時的9個方塊中，當開始方格被加到封閉列表後，開放列表裡還剩8個方格。在這八個方格當中，位於起點方格右邊的那個方格具有最小的F值40。所以我們選擇這個方格作為下一個中心方格。下圖中它以高亮的藍色表示。

[圖四]
　
首先，我們將選中的方格從開放列表中移除，並加入到封閉列表中（所以用亮藍色標記）。然後再檢驗它的相鄰節點。那麼在它緊鄰的右邊的方格都是牆，所以不管它們。左邊挨著的是起始方格，而起始方格已經在封閉列表中了，所以我們也不管它。

其他四個方格已經在開放列表中，那麼我們就要檢驗一下如果路徑經由當前選中方格到那些方格的話會不會更好，當然，是用G值作為參考。來看看選中方格右上角的那一個方格，它當前的G值是14，如果我們經由當前節點再到達那個方格的話，G值會是20（到當前方格的G值是10，然後向上移動一格就再加上10）。為20的G值比14大，因此這樣的路徑不會更好。你看看圖就會容易理解些。顯然從起始點沿斜角方向移動到那個方格比先水平移動一格再垂直移動一格更直接。

當我們按如上過程依次檢驗開放列表中的所有四個方格後，會發現經由當前方格的話不會形成更好的路徑，那我們就保持目前的狀況不變。現在我們已經處理了所有相鄰方格，準備到下一個方格吧。

我們再遍歷一下開放列表，目前只有7個方格了。我們挑個F值最小的吧。有趣的是，目前這種情況下，有兩個F值為54的方格。那我們怎麼選擇呢？其實選哪個都沒關係，要考慮到速度的話，選你最近加到開放列表中的那一個會更快些。當離目的地越來越近的時候越偏向於選最後發現的方格。實際上這個真的沒關係（對待這個的不同造成了兩個版本的A*演算法得到等長的不同路徑）。

那我們選下面的那個好了，就是起始方格右邊的，下圖所示的那個。

[圖五]
　
這一次，在我們檢驗相鄰方格的時候發現右邊緊挨的那個是牆，就不管它了。上面挨著的那個也同樣忽略。還有右邊牆下面那個方格我們也不管。為什麼呢？因為你不可能切穿牆角直接到達那個格子。實際上你得先向下走然後再通過那個方格。這個過程中是繞著牆角走。（注意：穿過牆角的這個規則是可選的，取決於你的節點是如何放置的。）

那麼還剩下其他五個相鄰方格。當前方格的下面那兩個還不在開放列表中，那我們把它們加進去並且把當前方格作為它們的父方格。其他三個中有兩個已經在封閉列表中了（兩個已經在圖中用亮藍色標記了，起始方格，上面的方格），所以就不用管了。最後那個，當前方格左邊挨著的，要檢查一下經由當前節點到那裡會不會降低它的G值。結果不行，所以我們又處理完畢了，然後去檢驗開放列表中的下一個格子。

重複這個過程直到我們把目的方格加入到開放列表中了，那時候看起來會像下圖這個樣子。

[圖六]
　
注意到沒？起始方格下兩格的位置，那裡的格子已經和前一張圖不一樣了。之前它的G值是28並且指向右上方的那個方格。現在它的G值變成了20並且指向了正上方的方格。這個改變是在搜尋過程中，它的G值被核查時發現在某個新路徑下可以變得更小時發生的。然後它的父方格也被重設並且重新計算了G值和F值。在本例中這個改變看起來好像不是很重要，但是在很多種情況下這種改變會使到達目標的最佳路徑變得非常不同。

那麼我們怎樣來自動得出實際路徑的呢?很簡單，只要從紅色目標方格開始沿著每一個方格的指標方向移動，依次到達它們的父方格，最終肯定會到達起始方格。那就是你的路徑！如下圖所示。從A方格到B方格的移動就差不多是沿著這個路徑從每個方格中心（節點）移動到另一個方格中心，直到抵達終點。簡單吧！

[圖七]
　
A*演算法總結

1.
將開始節點放入開放列表(開始節點的F和G值都視為0);
2.
重複一下步驟:
            i.
在開放列表中查詢具有最小F值的節點,並把查詢到的節點作為當前節點;
           ii.
把當前節點從開放列表刪除, 加入到封閉列表;
         iii.
對當前節點相鄰的每一個節點依次執行以下步驟:
1.
如果該相鄰節點不可通行或者該相鄰節點已經在封閉列表中,則什麼操作也不執行,繼續檢驗下一個節點;
2.
如果該相鄰節點不在開放列表中,則將該節點新增到開放列表中, 並將該相鄰節點的父節點設為當前節點,同時儲存該相鄰節點的G和F值;
3.
如果該相鄰節點在開放列表中, 則判斷若經由當前節點到達該相鄰節點的G值是否小於原來儲存的G值,若小於,則將該相鄰節點的父節點設為當前節點,並重新設定該相鄰節點的G和F值.
        iv.
迴圈結束條件:
當終點節點被加入到開放列表作為待檢驗節點時, 表示路徑被找到,此時應終止迴圈;
或者當開放列表為空,表明已無可以新增的新節點,而已檢驗的節點中沒有終點節點則意味著路徑無法被找到,此時也結束迴圈;
3.
從終點節點開始沿父節點遍歷, 並儲存整個遍歷到的節點座標,遍歷所得的節點就是最後得到的路徑;

一點感慨

原諒我的離題。但畢竟值得指出的是，當你在網上和論壇裡看到很多討論A*路徑尋找演算法的東西時，偶爾會遇到一些人所指的A*演算法並不是真正的A*的情況。實際上要應用真正的A*需要包含我們上面討論的那些元素：專門的開放列表和封閉列表，用F、G和H值來排序的路徑統計。有很多其他的尋找路徑演算法，但是其他的都不是A*，而A*一般認為是這些演算法當中最好的。本文末尾的參考文件裡有Bryan Stout對這些演算法的討論。在特定情況下某些演算法可能會更好，但是你至少要理解你要準備做什麼。好了，差不多了，還是回到主題吧。

實現時的注意事項

現在你已經理解了基本的演算法，下面將討論一些你在寫自己的程式時要考慮的東西。下面一些材料和我用C++和Blitz Basic寫的程式有關，但是那些要點是適用於任何其他語言的。

1.
開放列表的維護：實際上是A*演算法中最耗時的因素。每次你處理開放列表時你都要從中找出具有最小F值的方格。有幾種方法可以做到。你可以儲存所需的路徑元素，簡單的遍歷列表來找出最小F值的方格。這種方法是很簡單，但是在路徑很長的時候會很慢。也可以改進一下，變成維護一個有序列表，這樣在需要最小F值方格的時候僅須獲取該有序列表的第一個元素。我在寫我那個程式的時候，開始就是用的這個辦法。
這種方法很適合於地圖不大的情況。但這還不是最快的解決辦法。真正追求速度的認真的程式設計師往往會使用二叉堆。這也是我在我的程式碼中用的方法。據我的經驗，這種方法會比大多數解決方案快至少2－3倍，在路徑很長的時候更快（快10倍以上）。如果你有興趣瞭解更多二叉堆的內容，去看看我的這篇文章，Using Binary Heaps in A* Pathfinding。


2.
其他單位。如果你仔細看了我的例子程式碼，你會注意到它完全忽略了地圖上的其他單位。我的尋路者實際上是直接穿過彼此的。這樣行得通行不通是取決於遊戲的。如果你要考慮地圖上的其他單位並且它們還能夠移動，我建議你在路徑尋找演算法中忽略它們而另外寫一些程式碼去檢測它們是否發生了碰撞。當碰撞發生時，你可以馬上生成一個新的路徑或者應用一些標準移動規則（比如總是靠右走等等）直到路徑上不再有障礙物或，然後再生成一個新的路徑。為什麼在你最初計算路徑的時候就把這些單位考慮進去呢？那其實是因為其他單位也會移動，它們的位置在不停的改變。這樣會導致產生一些不可思議的結果，比如某個單位會突然轉向來避免一個實際上已經不在那兒的另一個單位，或者撞上一個後來移動到它的預定路徑上的單位。
在尋路演算法中忽略其他單位意味著你將不得不寫一些單獨的程式碼來避免衝突。這完全是由遊戲特性決定的。所以我把解決方案留給你自己去琢磨。本文末尾參考文章一節Bryan Stout的一些地方提供了幾個解決方案（比如魯棒式跟蹤等等），不妨去看看。


3.
一些提速技巧：你在開發你自己的A*程式或者改變我寫的那個時，總會發現這個尋路演算法很耗CPU，特別是地圖上有大量的尋路者和地圖相當大的時候。如果你在網上讀過一些資料你會知道這個對於像星際爭霸或者帝國時代這樣專業的遊戲也不例外。當你發現你的尋路演算法使你寫的東西變慢了的話，可以參考下面這些提速的辦法：

• 用小一點的地圖或者尋路者少一點。
• 
  不要在同一時間為很多個尋路者計算路徑。不如把它們放進一個佇列裡並分散在幾個遊戲迴圈中。如果你的遊戲執行時大約是，比如說，40個迴圈/秒的話，沒人會注意到。但是要是有一堆尋路者在同一時間計算路徑而導致遊戲在短時間內變慢的話，就非常引人注意了。
• 
  將地圖的區塊劃分得大一些。這樣會減少搜尋路徑時的區塊總數。如果你夠強，可以設計兩種以上的尋路系統來適應於路徑長度不同的情況。這正是那些專業人士所做的，路徑長的時候用大區塊，當接近目標路徑變短的時候又用小區塊來進行精確些的搜尋。要是你對這個概念感興趣，不妨讀讀我的文章Two-Tiered A* Pathfinding
• 考慮採用路標系統來處理長路徑的情況，或者預先處理一些對遊戲來說很少變化的路徑。 
• 對地圖進行預處理並計算出哪些區域是從其他地方根本到達不了的。我把這些區域叫做“島”。實際中這些區域可能是島也可能是牆圍起來的地方。A*演算法的一個缺陷是當你在找到這樣一個不可達區域的路徑時，幾乎會把整個地圖都搜個遍，直到地圖上每一個區塊都被搜尋過了才會停。這樣會浪費很多CPU時間。解決這個問題的辦法是預先得出哪些區域是根本不可達的（通過洪泛法或者其他方式），用一個數組記錄下這些資料並在尋找路徑前先檢查一下。在我那個Blitz版本的程式碼中，我建立了一個地圖前處理器來完成這樣的處理。這個前處理器還能提前找到可在尋路演算法中忽略的死角，因而大大提高了演算法速度。 

4.
地形多樣化的開銷：在這個入門教程和我附帶的程式中，地形地貌只包括兩種情況：可通過的和不可通過的。但是假如還有一些地形那是可以通過的只是移動的開銷更大一點呢？比如沼澤、山丘、地牢裡的梯子等等呢？這些都是可以通行的地形的例子，只不過比開闊的平地具有更高的開銷。類似的，公路地形會比路郊的移動開銷小。
這個問題很容易解決。只要在計算給定區塊的G值時把地形的開銷加上去就行。把某個區塊加上額外的開銷，A*演算法仍然有效。在我描述的那個簡單例子裡，地形只分可通過和不可通過兩種，A*演算法會找到最直接最短的路徑。但當在一個地形多樣化的環境裡時，最小開銷路徑可能會是比較長的一段路程。例如從公路上繞過去顯然比直接通過沼澤地開銷要小。
還有一個有趣的辦法是專業人士們叫做“感應對映”的東西。如同上面描述的多樣化地形開銷一樣，你可以建立一個額外的點數制度並將之應用於AI方面的路徑中。假設在一張地圖上有一堆傢伙在守衛一個山區要道，每次電腦派遣某人通過那條要道時都會被困住。那你就可以建立一個感應地圖使得發生很多戰鬥衝突的那些區塊開銷增大，以此來告知電腦去選一個更安全的路徑，並避免僅憑著是最短路徑（但是更危險）就持續派遣人員通過某條路徑的愚蠢情形。


5.
處理未探索區域：你有玩過電腦總是知道怎麼走，甚至地圖都還沒探索過的PC遊戲嗎？由此看來這個路徑尋找演算法真是好得不現實。還好這個問題可以很容易解決。
方法就是為不同的玩家和電腦（不是每個單位，不然會耗掉好多記憶體）建立一個獨立的“已知可通行”陣列。每個陣列包含了玩家已探索區域和未知區域的資訊，並把未知區域全部視為可通行區域來對待，除非後來發現是其他的地形。使用這種方法的話，移動單位就會繞到死角或犯類似錯誤，直到它們發現了周圍的路。一旦地圖都被探索過了，路徑尋找演算法就會正常運行了。

6.
平滑路徑：A*演算法會得出開銷最小路程最短的路徑，但沒法得到看起來最平滑的路徑。看看那個例子的最終路徑（圖七），該路徑的第一步是起始點的右下方的方格。如果第一步是正下方那個方格，那得到的路徑不是就要平滑很多嗎？
有幾種方法可以處理這個問題。如在計算路徑的時候你可以給那些改變了路徑方向的方格一個額外開銷，使其G值增大。這樣，你可以沿著所得路徑看看哪些取捨能使你的路徑看起來更平滑。對於這個話題，可以看看Toward More Realistic Pathfinding（是免費的，但是檢視需要註冊）來了解更多。


7.
非方格的搜尋區域：在上面的例子中，我們用的是簡單的二維方格佈局。你可以不這樣弄，不規則區域也行。想想棋盤遊戲Risk和Risk裡的那些國家。你可以設計一個那樣的尋路的關卡。要做這樣的關卡，你得建立一個查詢表來儲存每個國家對應的鄰國，和從一個國家移動到另一個國家的開銷G。另外也得選一種計算估計值H的方法。其他的處理就和前面的例子差不多了。只是當對新區域進行檢驗時，即新增新專案到開放列表中的時候，是從表中查詢鄰近國家而不是選擇鄰近方格。
類似的，你可以針對固定地形的地圖來建立一個路標系統。路標通常是橫穿路徑的點，可能是在公路上也可能是在地牢的主隧道里。對於遊戲設計者來說，需要提前設定好這些路標。如果兩個路標所成的直線路徑之間沒有障礙物的話就稱之為“相鄰的”。在Risk遊戲的例子中，你會將相鄰資訊儲存在一個查詢表中，並會在新增開放列表元素時用到這個查詢表。然後你會用到相關的G值（可能通過兩個節點間的直線距離得到）和H值（可能通過該節點到終點的直線距離得到）其他的運算就和普通的差不多。
另外一個使用非方格搜尋區域的斜視角RPG遊戲的例子參見我的文章Two-Tiered A* Pathfinding。

進階閱讀

好了！現在你基本上掌握了基礎知識，並對高階的概念也有了些印象。在此我建議把我的程式碼拿來研究研究。壓縮包裡有兩個版本，分別是C++的和Blitz Basic的。它們的註釋都很詳細，我想應該很容易理解。下面是連結：

• Amit's A* Pages:這是Amit Patel的一篇廣為引用的文章。不過如果你沒讀先讀本文的話看他這個可能會有些困惑。非常值得一讀。特別是Amit對此的獨特觀點。
• Smart Moves: Intelligent Path Finding: Gamasutra.com網站上Bryan的這篇文章是需要註冊才能閱讀的。不過註冊是免費的而且為了這篇文章麻煩一點也值得。Bryan用Delphi寫的那個程式幫助我瞭解了A*，那也是我的A*程式的靈感來源。這篇文章也寫了一些A*的變種
• Terrain Analysis:這是一篇高階的文章，不過很有趣，它是由Ensemble Studios的專家Dave Pottinger所寫。這傢伙負責協調帝國時代II：Age of Kings的開發。要想把這裡所有東西都看明白是不可能的，不過它或許會給你自己的專案帶來一些有趣的想法。文章還包括一些關於材質貼圖，感應對映和其他一些高階AI/路徑尋找概念。其中關於“洪泛（flood filling）”的討論是我的死角和島嶼等地圖預處理程式碼的靈感來源。在我的Blitz Basic版的程式中包含了這個東西。。

其他值得一讀的文章：

好了！如果你在寫程式的時候用到了任何以上的觀念，我將非常高興。你可以通過Email聯絡我：

就到這兒吧，Good luck！




最後貼上eidiot的程式碼，原配註釋，大家一起學習下~~

這裡是eidiot的教程：http://eidiot.net/2007/04/17/a-star-pathfinding/