a*尋路演算法是遊戲開發中使用得比較多的尋路演算法，主要用在rgp遊戲中主角或者怪物的尋路，其尋路的效率也是比較高，但是如果乙個地圖比較大或者怪物比較多的時候，同時使用尋路演算法會導致遊戲出現卡頓現象，在大部分遊戲中，角色或者怪物尋路，並不需要找最短的那條路徑，在效能允許的情況下，找一條次優或者其它的路徑也可以，這樣可能更適合遊戲，所以，我們需要根據遊戲的特點，去優化尋路演算法，優化ａ*的尋路，我能想到的暫時只有以下幾種(僅適用於基於網格的尋路）：
1.修改尋路估值函式
a*尋路演算法的核心部分是其對目標路徑的估值函式，估值函式的好壞直接影響尋路演算法的效率，如果把估值函式去掉，那麼a*演算法和dijktra演算法一樣了，目前a*演算法有很多其它的變異,正常的a*尋路的估值函式(h)是從當前點到目標點的x差值絕對值ｘ，y差值的絕對值之和y，我們可以根據自己遊戲中地圖的特點，在x和y上分別乘以乙個係數，可以加大估值函式在整個路徑中的權重，但是最終得到的路徑可能不是最短的，演算法的效率卻可以提公升很多．
２.加快插入結點到openlist中的效率
在a*的每一次尋路過程中，每找到乙個新的路點都需要將其插入到openlist中，為了使openlist保持有序，所以插入元素時，最壞的情況需要遍歷整個openlist列表，因為插入操作比較頻繁，所以加快每一次的插入操作，能加快整體的尋路速度．a*尋路每一次都是查詢周圍４個或者８個鄰居節點，再將符合條件的鄰居節點插入到openlist中，由於當前節點和鄰居節點的f(g+h)值是比較接近的，如果鄰居節點已經在openlist列表中，是否可以從鄰居節點開始查詢當前節點的插入點，答案是肯定的，在插入時，如果有鄰居節點已經在openlist中，可以找出鄰居節點中小於當前節點的最大節點的位置進入插入查詢，這樣可以減少遍歷節點的個數．如果當前節點已經在openlist中，並且當前路徑的f值比openlist中的f值更小，則直接更新當前節點的資訊(h,f,parent)即可,這樣就不用再進行重新排序，但是最終的路徑可能也不是最短的．
３.儲存鄰居節點的引用，減小尋路判斷次數
在進入遊戲載入地圖時，將每個節點的鄰居節點的引用儲存到乙個陣列中，在尋中過程中直接遍歷陣列即可取出鄰居節點，不需要進行更多的判斷
迷宮尋路（A星尋路演算法）
題目 假設我們有乙個7 5大小的迷宮，如下圖所示，綠色格仔表示起點，紅色的格仔表示終點，中間的3個深灰色格仔表示障礙物。請找到一條從起點到終點最短的路徑。解題思路 需要引入兩個集合和乙個公式，如下 具體步驟 把起點放入openlist 檢查openlist中是否有值，如果沒有則無法到達終點，結束尋路...
A 尋路演算法
問題 由於遊戲中尋路出了個小問題 玩家尋路到乙個死角後在那邊不停的來回跑,就是無法越過障礙物,就研究了下a 尋路演算法以解決這個問題 研究了幾天,自己寫了個demo這裡給出總結 原理 a 演算法給出的是權值最優的路徑而不是最短路徑 權值有f g h來表示 啟發式函式如下 f p g p h p h值...
A 尋路演算法
a 演算法是靜態環境下求最短路徑的不二之選，由於是啟發式搜尋，比dijkstra 深搜廣搜要快的多啦。a 也算是我第一次接觸的移動機械人演算法，csdn上的科普文章也不少，但我作為乙個機械的小白，實現出來還是小有成就感滴。今天抽空和大家分享一下原始碼，開發環境win7 64 opengl vs201...