原文：
遊戲開發中，較之控制物體移動，尋路演算法要複雜得多。例如：
物體初始位於地圖下方，目標是地圖頂部，如紅色線路所示，該物體向上走直至偵測到障礙，改變方向，繞了乙個大彎。而理想尋路系統需要類似藍色所示，通過搜尋更廣範圍以尋找更短路線。
灰色區域是凹陷形狀的障礙，可以通過凸包方式使得物體在凸包外移動。如下圖，虛擬障礙區域就是凸包區域（圖形學對凸包的解釋是剛好包圍乙個物體的凸多邊形，此處可引申為曲線）。
如果地圖較大路徑較長則使用尋路規劃，而對於區域性區域或短路徑使用改進的物體移動演算法。
將遊戲中的地圖轉化為計算機中的圖，每乙個方格是圖的頂點，而兩個相鄰方格之間是通過邊連線的，如圖所示：
大部分尋路演算法是應用於圖的，而非網格化的遊戲地圖。
dijkstra演算法簡而言之，就是從起始點開始訪問其相鄰節點，若該相鄰點之前未被檢測，並將該節點加入待檢查節點集合中，使用鬆弛演算法更新待檢查節點的路徑長度值。只要圖不存在負權值的邊，dijkstra演算法能夠確保找到最短路徑。在下圖中，粉色的方格為起始點，紫色的方格為目標點，青綠色的方格則為dijkstra演算法所掃瞄的節點。距離起始點越遠，顏色越淡。
貪心最好優先搜尋演算法對目標點的距離有乙個啟發值。對於待檢查節點集合，該演算法不是找距離起始點近的節點，而是選擇距離目標點近的節點。該演算法並不能保證尋找到最優路徑，卻能大大提高尋路速度，因其啟發式方法引導了路徑走向。舉例來說，如果目標節點在起始點的南方，那麼貪心最好優先搜尋演算法會將注意力集中在向南的路徑上。下圖中的黃色節點(顏色較淺節點)指示了具有高啟發值的節點（即到目標節點可能開銷較大的節點），而黑色(顏色較深節點)則是低啟發值的節點（即到目標節點的開銷較小的節點）。下圖說明相比於dijkstra演算法，貪心最好優先演算法能夠更加快速地尋路。
考慮前文中曾經提到的凹陷障礙物，dijkstra演算法仍然能夠尋找到最短路徑：
貪心最好優先演算法雖然做了較少的計算，但卻並不能找到一條較好的路徑。
問題在於最好優先搜尋演算法的貪心屬性。由於演算法僅考慮從目前節點到最終節點的開銷，而忽略之前路徑已經付出的開銷，因此即使在路徑可能錯誤的情況下仍然要移動物體。
2023年提出的a*演算法結合了貪心最好優先搜尋演算法和dijsktra演算法的優點。a*演算法不僅擁有啟發式演算法的快速，同時能夠保證生成確定的最短路徑。
下面我們主要討論a*演算法。a*十分靈活，能夠被應用於各種需要尋路的場景中。
與dijkstra演算法相似的是，a*演算法也能保證找到最短路徑。同時a*演算法也像貪心最好優先搜尋演算法一樣，使用一種啟發值對演算法進行引導。在剛才的簡單尋路問題中，它能夠像貪心最好優先搜尋演算法一樣快：
而在後面的具有凹陷障礙物的地圖中，a*演算法也能夠找到與dijkstra演算法所找到的相同的最短路徑。
該演算法的秘訣在於，它結合了dijkstra演算法使用的節點資訊（傾向於距離起點較近的節點），以及貪心最好優先搜尋演算法的資訊（傾向於距離目標較近的節點）。之後在討論a*演算法時，我們使用g(n)表示從起點到任意節點n的路徑花費，h(n)表示從節點n到目標節點路徑花費的啟發值。在上面的圖中，黃色體現了節點距離目標較遠，而青色體現了節點距離起點較遠。a*演算法在物體移動的同時平衡這兩者的值。定義f(n)=g(n)+h(n)，a*演算法將每次檢測具有最小f(n)值的節點。
A星尋路演算法介紹
你是否在做一款遊戲的時候想創造一些怪獸或者遊戲主角，讓它們移動到特定的位置，避開牆壁和障礙物呢？如果是的話，請看這篇教程，我們會展示如何使用a星尋路演算法來實現它！在網上已經有很多篇關於a星尋路演算法的文章，但是大部分都是提供給已經了解基本原理的高階開發者的。本篇教程將從最基本的原理講起。我們會一步...
A 尋路演算法
問題 由於遊戲中尋路出了個小問題 玩家尋路到乙個死角後在那邊不停的來回跑,就是無法越過障礙物,就研究了下a 尋路演算法以解決這個問題 研究了幾天,自己寫了個demo這裡給出總結 原理 a 演算法給出的是權值最優的路徑而不是最短路徑 權值有f g h來表示 啟發式函式如下 f p g p h p h值...
A 尋路演算法
a 演算法是靜態環境下求最短路徑的不二之選，由於是啟發式搜尋，比dijkstra 深搜廣搜要快的多啦。a 也算是我第一次接觸的移動機械人演算法，csdn上的科普文章也不少，但我作為乙個機械的小白，實現出來還是小有成就感滴。今天抽空和大家分享一下原始碼，開發環境win7 64 opengl vs201...