本文目的是對a*尋路演算法所生成的路徑進行一些人性化的調整,使其看起來不至於太機械化。關於a*演算法的原理與實現,讀者可以閱讀其他資料,這裡不再詳細闡述。
a*尋路演算法本質上是乙個有方向性的廣度優先搜尋演算法,它使用乙個估價函式,來估測可能的最短路徑,在每一次搜尋迭代完成後,選取其鄰接點中最優的乙個(即,距離終點最近的乙個點),作為下一次迭代的起點。如此反覆,直到找到終點。下面先列出估價函式的常規寫法:
設i點到起點的價值為s,到終點的估價為e,i點的總估價g等於s+e。s的值是確定的:
[cpp]view plain
copy
s = parent.s + 1(i點是其父節點的水平或垂直方向上的鄰接點)
或 s = parent.s + sqrt(2))(i點是其父節點斜方向上的鄰接點)
e點的值需要估算。精確一點的寫法:
[cpp]view plain
copy
水平距離:dx = abs(ix - ex)
垂直距離:dy = abs(iy - ey)
需要斜著走過的距離:v1 = min(dx, dy) * sqrt(2)
需要直線走過的距離:v2 = max(dx, dy) - min(dx, dy)
e = v1 + v2
粗略的寫法:
[cpp]view plain
copy
e = abs(ix - ex) + abs(iy - ey)
a*尋路得到的結果是最優的,但不是唯一的,這源於兩點之間最近的路線可能不只一條。那麼問題就產生了,兩條最佳路線距離都相等的情況下,哪一條會更好?
(紅色是障礙,白色可通行,黑色是搜尋路徑)
如上圖所示,是a* 8方向搜尋得到的兩條距離相等的路線,但是左圖的路線在中間位置發生了「拐彎」,要比右圖的路線多乙個「拐彎」。如果路線上拐彎太多,人物行走的過程中,會出現頻繁轉向,從而出現「抖動」現象。所以,我們判定右圖路線優於左圖路線。針對這一問題,我們可以通過修改估價函式,來選擇「拐彎」更少的路線。
拐彎的問題,可以簡化成先盡可能的向乙個方向走,然後再考慮轉向。進一步簡化成,點越接近起點或是終點,越優先考慮。我們給e加上乙個干擾值factor,
[cpp]view plain
copy
factor = min(abs(ix - sx), abs(ix - ex)) + min(abs(iy - sy), abs(iy - ey))
factor *= 0.01
factor的值不能過大,否則會造成搜尋結果不是最短距離,因此適當的給factor乘上乙個縮放係數。
a*尋路的效果是抄近道,走捷徑。但對於遊戲體驗來說,這並不完全是件好事,放著寬闊的馬路不走,非得走懸崖峭壁,一不小心就跌落萬丈深淵,或者卡在岩石邊上。那麼,我們該如何避免這些現象呢?
同樣,我們可以通過修改估計函式做到。
我們給每一塊可走區域都加上乙個干擾值,越靠近障礙的可走區域,其干擾值越大。干擾值計算方法:
[cpp]view plain
copy
factor = 0
for(x = -n; x <= n; ++x)
} } 我們甚至可以根據地表的材質來增加干擾值,比如山路和沼澤地帶明顯比馬路的干擾值大。
總之,我們可以調節估價函式來達到不同的效果。但是,也不能隨意修改,不良的估價函式,會增加搜尋成本。
軟體實習專案二 A Star演算法
實現的原理 建立next stemp函式,用來判斷0值下一步可以移動的方向 建立函式faction1,判斷移動後的方格是否為目標方格 建立函式faction2,判斷移動後的方格是否出現在open鍊錶和close鍊錶中 建立insert函式,將下一步未出現在open鍊錶和close鍊錶中的情況儲存在o...
演算法 Astar尋路演算法改進
早前寫了一篇 rcp gef智慧型尋路演算法 a star 出現了一點問題。在astar演算法中,預設尋路起點和終點都是n x n的方格,但如果用在路由上,就會出現問題。如果,需要連線的終點並不在方格的四角上,就產生了斜線。於是我們可以對終點附近的點重新做一點兒處理,原始碼如下所示 int size...
基於c 的A star演算法
資料 一 基礎原理 1 從起點開始,向周圍八個方向擴充套件。測試新擴充套件的點的路徑代價,路徑代價由已走的路徑和距離終點的期望加和而成。這個路徑代價是選擇路徑的標準。2 有兩個表open close。close 生成並且考察過的點,存在兩種點。一種是當前選擇的路徑,是最終想要的結果。另一種是考察但沒...