遊戲尋路中 A* 演算法的改進
在眾多尋路演算法中,A* 的確是比較不錯的。但在遊戲尋路領域,A* 耗時過大,顯然需要改進。
改進
我的想法是預先將地圖按照一定的規則劃分為多個區域,這些區域彼此連通,並且計算好彼此連通的區域之間的來往的消耗(預計算部分,經檢測耗時極少)。
從幾千個正方形組成的障礙矩陣中構造出一張資料量大大減少的帶權連通圖。
每次尋路時自動檢測起始位置和終點分別在圖中的哪兩個節點,在很短時間內構造出一條最短路徑。
接著,計算進入以及離開每個區域的比較適合的點,再經過路徑平滑演算法,得到的路徑與傳統 A* 沒有明顯區別,但是中間節點減少,耗時大大減少。經過計算,耗時為傳統 A* 的 1/800 - 1/1000,取得相當顯著的效果。而且對於 A* 其他的改進措施,也可以用在該改進方法上,如雙向 A*,在較複雜的圖中可以明顯加快尋路速度。並且該尋路程式碼也可以放在非主執行緒中,影響更是可以忽略不計。
(改進 A* 路徑)
(傳統 A* 路徑)
在障礙圖中的資訊發生改變時,可以重新進行計算,得出新的帶權連通圖,並且廣播所有已經尋路完成但是還沒有達到終點的物體,使其修改路徑,耗時同樣在可接受範圍內。
總結
該 A* 改進演算法是典型的以空間換時間的演算法(雖然耗費的空間也很少,在遊戲領域可以忽略)
接下去我會繼續研究比如策略遊戲中一個群體單位尋路演算法的改進,因為他們無論起始點是否在同個區域,在帶權連通圖中總會經過相同的節點,這些計算完全可以快取下來,減輕後面計算的負載。
來源:indienova
原文:https://mp.weixin.qq.com/s/JD9bFJvirP-OBR-ZFGbukg
相關文章
- 演算法:塔防遊戲中的路徑尋找演算法遊戲
- 遊戲中的自動尋路-A*演算法(走斜線篇——帶DEBUG)遊戲演算法
- 一種高效的尋路演算法 - B*尋路演算法演算法
- 遊戲AI尋路——八叉樹+A*尋路遊戲AI
- 尋路之 A* 搜尋演算法演算法
- 粒子群演算法中對於學習因子的改進演算法
- Swift 4.1 中的 Codable 改進Swift
- 關於尋路演算法的一些思考(11):尋路演算法的其他應用演算法
- 尋寶路漫漫,從《金銀島》聊聊”尋寶“主題遊戲的代入感進階之路遊戲
- 演算法修養--A*尋路演算法演算法
- 改進飛碟(Hit UFO)遊戲遊戲
- 電商搜尋演算法技術的演進演算法
- 【譯】.NET 6 網路改進
- 課時4:改進我們的小遊戲遊戲
- 谷歌搜尋一年改進890多次 核心演算法一天一變谷歌演算法
- 演算法信仰的力量:改進演算法能提升多少效能?演算法
- 尋路演算法之A*演算法詳解演算法
- 負載均衡演算法需要改進負載演算法
- 關於尋路演算法的一些思考(9):尋路者的移動成本演算法
- 【翻譯】.NET 5中的效能改進
- 【譯】.NET 5 中的診斷改進
- 【譯】.NET 7 中的效能改進(五)
- 【譯】.NET 7 中的效能改進(六)
- 【譯】.NET 7 中的效能改進(一)
- 【譯】.NET 7 中的效能改進(二)
- 【譯】.NET 7 中的效能改進(七)
- 【譯】.NET 7 中的效能改進(八)
- 【譯】.NET 7 中的效能改進(九)
- 【譯】.NET 7 中的效能改進(十)
- 【譯】.NET 7 中的效能改進(三)
- 【譯】.NET 7 中的效能改進(四)
- 【譯】.NET 7 中的效能改進(十一)
- 【譯】.NET 7 中的效能改進(十二)
- 【譯】.NET 7 中的效能改進(十三)
- 你會如何改進這個演算法?演算法
- QT 驗證改進後Bresenham演算法QT演算法
- kmp字串匹配,A星尋路演算法KMP字串匹配演算法
- A*尋路演算法詳細解讀演算法