COC Like 遊戲中的尋路演算法

同樣是一篇老文章, 2013 年初我剛玩 coc 的時候寫給公司內部分享的。由於當時公司還沒有決定開手遊專案，但有意向做一款 coc like 的產品，並希望開發期間保密，所以相關技術文章都沒有公開。

coc 的地圖有 40x40 格，邊界還有兩格不可以放建築的格仔。所以整個地圖是 44x44 格的。但在做座標判定時，基於格仔是遠遠不夠的。coc 官方版本很可能是基於畫素級的精度的，和本文所述方法不一致，所以本文僅提出一種可行的資料結構，

地圖至少要基於網格頂點來建立座標系統。每個格仔由中心點以及四角為頂點，一共有 9 個座標點。也就是說，最小單位是半個格仔。座標系是 [0,88]

下面的示意圖是乙個格仔，以及 9 個座標點：

+--+--+
|  |  |
+--+--+
|  |  |
+--+--+

關於建築，除了表面上看到的佔據格仔的面積外，還有實際的尺寸。

比如礦，空間上佔 3x3 個格仔，但實體則可能是這樣的：

..+++..

.+###+.

+#####+

.+###+.

..+++..

也就是說，對於乙個 3x3 的建築來說，它佔據了 9 個座標點 # 。當步兵攻擊它的時候，需要站在周圍的一圈座標 + 上。實體不是方的，可以讓兵圍起來的時候大致成乙個八邊形，而不是方形。

對於 2x2 的建築，則是這樣的：

..+..

.+#+.

+###+

.+#+.

..+..

關於尋路：

coc 不同於 rts ，它基本上是運動的單位尋路去攻擊靜止建築。（部隊交火例外，這個先撇開不談）地形在破壞之前，大體上路線其實大體上是固定的。而建築也有限。加上地圖規模不大，這讓尋路模組也有了極大的優化空間。

我認為預處理可以極大的簡化計算。

我們可以針對每類建築設定一張尋路圖。以 3x3 的普通建築為例：

2100012

10###01

0#####0

10###01

2100012

這裡的 0,1,2 只是到建築的實際距離。我們只需要做一次全地圖填充，就可以寫入地圖上所有座標點到建築的最短距離。陸軍在移動時，只需要找到周圍 8 個座標中距離建築更近的乙個，移動過去即可。如果距離為 0 就可以展開進攻。注意，斜向移動並不會更快。

對於不同攻擊距離的單位，可以分別生成不同的圖表。這樣，弓箭手就會在剛好在射程最遠處就展開進攻了。

關於牆：

牆不是建築，除了炸彈骷髏，所有兵種都不以牆為尋路目的地。所以牆不需要生成上面的圖（炸彈骷髏的移動邏輯另做）。

牆對於尋路系統來說，只是乙個權值很高的障礙（可以跳躍後則忽略）。比如，乙個 3x3 建築圍了牆後該怎麼計算呢？（如下圖，我故意留了兩個口）。

####.

#ooo#

##.##

展現為座標點是這樣的。# 表示建築，x 表示牆，. 表示路。

...........

.******x...

.x.........

.x..###..x.

.x.#####.x.

.x..###..x.

.x.......x.

.***...***.

...........

如果我們認為通過牆的難度是 6 (就是說，拆牆好過走 6 個格仔。實際設定的值肯定比 6 大) ，那麼按同樣的方法標註前面的圖就好了。

ba987765456

a9876667345

98210001234

8710###0165

760#####066

760#####067

8710###0178

88210001288

79871117897

65432223456

如果在行軍路線上，下乙個目標點是牆，那麼就先攻擊牆就可以了。

總結一下，其實我們只需要為每類兵種，針對它所偏好攻擊的建築群生成一張路圖，標記了乙個士兵在地圖任何位置所需要做的動作：是向某個方向移動？還是站在原地開始攻擊。那麼士兵每到任何乙個新座標，他都可以通過查表 o(1) 時間得到要做的事情。

只有地形破壞後，路圖才需要重新計算。計算的時間複雜度是 o(n) 的，只跟地圖尺寸有關。我的試驗**可以在毫秒級完成重算。

ps. coc 應該不是採用這樣的演算法這可能和他們採用的地圖資料結構有關，因為它的士兵 ai 有明顯的遲鈍，大約 6 秒才會重算一次。但我認為上面的演算法更優不必追究 coc 的原版演算法是怎樣的。

對於炸彈人的邏輯，大致應該是尋找附近封閉空間中最近目標，炸毀路徑上的障礙。詳細演算法另開一篇。

COC Like 遊戲中的尋路演算法

遊戲中尋路的問題研究

android遊戲尋路演算法

遊戲開發 A 尋路演算法

COC Like 遊戲中的尋路演算法

遊戲中尋路的問題研究

android遊戲尋路演算法

遊戲開發 A 尋路演算法

相關推薦