a*尋路演算法是最常用的尋路演算法了，下面介紹一些概念，及flex中實現的demo
節點（node）：
本質上就是方形網格裡的某乙個方格（yujjj注：為什麼不把他們描述為方格？因為在一些時候劃分的節點不一定是方形的，矩形、六角形、或其它任意形狀，本書中只討論方格）。由此可以看出，路徑將會由起點節點，終點節點，還有從起點到終點經過的節點組成。
代價（cost）：
這是對節點優劣分級的值。代價小的節點肯定比代價大節點更好。代價由兩部分組成：從起點到達當前點的代價和從這個點到終點的估計代價。代價一般由變數f，g和h，具體如下。
f：特定節點的全部代價。由g+h決定。
g：從起點到當前點的代價。它是確定的，因為你肯定知道從起點到這一點的實際路徑。
h：從當前點到終點的估計代價。是用估價函式（heuristic function）計算的。它只能乙個估算，因為你不知道具體的路線——你將會找出的那一條。
估價函式（heuristic）：計算從當前點到終點估計代價的公式。通常有很多這樣的公式，但他們的運算結果，速度等都有差異（yujjj注：估價公式計算的估計值越接近實際值，需要計算的節點越少；估價公式越簡單，每個節點的計算速度越快）。
待考察表（open list）：
一組已經估價的節點。表裡代價最小的節點將是下一次的計算的起點。
已考察表（closed list）：
從待考察表中取代價最小的節點作為起點，對它周圍8個方向的節點進行估價，然後把它放入「已考察表」。
父節點（parent node）:
以乙個點計算周圍節點時，這個點就是其它節點的父節點。當我們到達終點節點，你可以乙個乙個找出父節點直到起點節點。因為父節點總是帶考察表裡的小代價節點，這樣可以確保你找出最佳路線。
現在我們來看以下具體的運算方法：
1. 新增起點節點到待考察表
2. 主迴圈
a. 找到待考察表裡的最小代價的節點，設為當前節點。
b. 如果當前點是終點節點，你已經找到路徑了。跳到第四步。
c. 考察每乙個鄰節點（直角座標網格裡，有8個這樣的節點 ）對於每乙個鄰節點：
(1).如果是不能通過的節點，或者已經在帶考察表或已考察表中，跳過，繼續下一節點，否則繼續。
(2).計算它的代價
(3).把當前節點定義為這個點的父節點新增到待考察表
(4).新增當前節點到已考察表
3. 更新待考察表，重複第二步。
4. 你已經到達終點，建立路徑列表並新增終點節點
5. 新增終點節點的父節點到路徑列表
6. 重複新增父節點直到起點節點。路徑列表就由一組節點構成了最佳路徑
**比較多就不貼了，可以參考flash高階動畫教程第四章
附件為測試檔案，紅色為英雄，藍色為通路，黑色為障礙，綠色為測試過的節點，白色為實際路徑
RCP gef智慧型尋路演算法（A star）
本路由繼承自abstactrouter，引數只有editpart 編輯器內容控制器 gridlength 尋路用單元格大小 style floyd,floyd flat,four dir 字符集編碼為gbk，本文只做簡單的 解析，原始碼戳我 如果原始碼不全，可以聯絡本人。演算法實現主要有三 1 as...
演算法 Astar尋路演算法改進
早前寫了一篇 rcp gef智慧型尋路演算法 a star 出現了一點問題。在astar演算法中，預設尋路起點和終點都是n x n的方格，但如果用在路由上，就會出現問題。如果，需要連線的終點並不在方格的四角上，就產生了斜線。於是我們可以對終點附近的點重新做一點兒處理，原始碼如下所示 int size...
在Unity中實現Astar尋路演算法
在遊戲中，從一點到另一點的操作有時需要遊戲系統自動完成，在一些帶有rpg元素的遊戲中，敵人在發現玩家位置後會自動向玩家的位置移動。這些移動的路線是如何自動確定的？本文將介紹尋路演算法中的a 演算法，並在unity中用c 指令碼來實現尋路功能。現在有兩個點 起點a，和終點b，允許向周圍的八個方向移動，...