作者：余田

首發(fā)“魚塘游戲制作工坊”公眾號(hào)

一、前言

溫馨提示，全文5k字，閱讀需要一定程序基礎(chǔ)，歡迎大家關(guān)注后慢慢閱讀——

上一篇探討了物理玩法中的操控和移動(dòng)實(shí)現(xiàn)，本篇進(jìn)行下一步，研究一下如何實(shí)現(xiàn)同屏大數(shù)量單位的移動(dòng)和控制，大數(shù)量是指幾千數(shù)量級(jí)，且要支持物理影響這些單位。

我們的難點(diǎn)如下：

• 難點(diǎn)1，數(shù)量級(jí)要足夠大，手機(jī)支持?jǐn)?shù)千到上萬級(jí)別
• 難點(diǎn)2，這些單位還要可以受物理影響，有物理效果
• 難點(diǎn)3，不想要基于代理的方式來簡化，也就是每個(gè)單位有獨(dú)立邏輯
• 難點(diǎn)4，基于組裝，目標(biāo)多變，并不固定，并且會(huì)有多目標(biāo)

當(dāng)然，從設(shè)計(jì)目的出發(fā)，我們也有一些簡化問題的機(jī)會(huì)點(diǎn)：

• 機(jī)會(huì)點(diǎn)1，限定2D平面上的多單位，不是3D
• 機(jī)會(huì)點(diǎn)2，不需要過于精確的尋路結(jié)果，不追求最短距離的尋路最優(yōu)解
• 機(jī)會(huì)點(diǎn)3，底層不需要基于物理，只要和玩家操控的物理底層能夠銜接，表現(xiàn)有物理的感受即可
• 機(jī)會(huì)點(diǎn)4，不追求精確避障，可以接受偶爾重疊

接下來，我們先來簡單總結(jié)一下現(xiàn)有的實(shí)現(xiàn)方式都有哪些：

1.基于NavMesh + 局部避障的思路

這是最容易想到的思路，unity本身就支持，比較成熟，優(yōu)點(diǎn)是尋路的質(zhì)量比較好，缺點(diǎn)就是性能要求比較高，適合幾百數(shù)量級(jí)的實(shí)體，不符合我們的需求。

2.VO / RVO / ORCA：基于速度空間的避障（Velocity Obstacle）

這個(gè)三個(gè)方法一脈相承，主要用于避障，和一般基于位置進(jìn)行避障的思路不同，簡單來說，這一系列方法的核心就是：如果我現(xiàn)在選這個(gè)速度，未來一小段時(shí)間會(huì)不會(huì)撞到別人？把所有“會(huì)撞的速度”圈成一個(gè)區(qū)域，然后在區(qū)域外選一個(gè)盡可能接近期望速度的安全速度。

這一類方法雖然避障效果很好，但對(duì)于數(shù)學(xué)計(jì)算有一定要求，因此從性能上考慮也不是最佳的選型，研究了一下也pass了，unity里也有現(xiàn)成的實(shí)現(xiàn)，大家想要學(xué)習(xí)，可以上git搜，鏈接在這https://github.com/Nebukam/com.nebukam.orca?tab=readme-ov-file

3.流場尋路（Flow Field）

傳統(tǒng)尋路（A* / NavMesh）是：對(duì)每一個(gè)單位，從起點(diǎn)到終點(diǎn)求一條離散路徑（拐點(diǎn)列表），單位沿路徑走。

Flow Field 則是以“目標(biāo)點(diǎn)”為源頭，在整個(gè)地圖上鋪一張“勢能場”，每個(gè)格子都存一個(gè)“朝目標(biāo)前進(jìn)的最佳方向”。單位只需要：

1. 找到自己所在格子
2. 讀取這個(gè)格子的“方向向量”
3. 朝這個(gè)方向加速/移動(dòng)

換個(gè)形象的比喻，把目標(biāo)點(diǎn)看成一個(gè)低洼水坑，整張地圖做一次“地勢計(jì)算”，每個(gè)格子有一個(gè)“高度”（離坑有多遠(yuǎn)）。單位就是水滴，只要沿著坡度下降方向走，就會(huì)自然流進(jìn)水坑。

流場尋路關(guān)鍵特點(diǎn)：

• “路徑”不是存在于每個(gè)單位身上，而是存在于“地圖格子”上；
• “路徑規(guī)劃”是一次全局計(jì)算，之后所有單位都廉價(jià)復(fù)用；

理論上O（1），復(fù)雜度跟單位數(shù)量無關(guān)，只跟流場構(gòu)建成本有關(guān)，配合一些優(yōu)化流場計(jì)算的手段，可以實(shí)現(xiàn)極大數(shù)量的單位共同運(yùn)動(dòng)。

缺點(diǎn)也很明顯，需要目標(biāo)盡量固定且少量，需要地圖盡量固定，因?yàn)椤暗貏荨币蛔?，就得更新流場地圖。所以很適合塔防之類的游戲，我們游戲主角到處移動(dòng)，未來還考慮多人聯(lián)機(jī)，因此不太適合。但流場尋路確實(shí)很優(yōu)雅，某些場景可以考慮混合使用。

4.Steering + 射線 + 空間分區(qū)避障

由于前面說的，我們不追求完全最優(yōu)解的尋路，且未來需要結(jié)合物理，對(duì)性能要求更高，所以最后這是最適合我們的一個(gè)方案，足夠簡單高性能，也可以很好地拓展。

整體思路是每個(gè)單位不做復(fù)雜的尋路，而是：

• 每個(gè)單位只知道：想去的“目標(biāo)方向”（一般就是指向玩家，或者任意目標(biāo)位置）
• 前面有沒有墻/障礙（射線檢測）
• 如果前方是通的 → 篤定往前沖
• 如果前方有障礙 → 在附近扇形范圍內(nèi)“試探”幾個(gè)方向，找一個(gè)能通過的方向
• 加一點(diǎn)點(diǎn)“單位間排斥力”，避免全擠成一團(tuán)

二、移動(dòng)具體實(shí)現(xiàn)思路

以“單個(gè)單位”為例，每一幀大致流程是：

• 計(jì)算“理想前進(jìn)方向”
• 用射線檢測這條方向是否被障礙擋住
• 如果被擋，扇形范圍內(nèi)尋找替代方向
• 在避障方向基礎(chǔ)上，疊加“和周圍單位保持距離”的偏移
• 在最終方向上做平滑處理，并加一點(diǎn)點(diǎn)隨機(jī)擾動(dòng)防止卡死
• 通過剛體/位移沿這個(gè)方向移動(dòng)

整個(gè)過程只決定“方向”，移動(dòng)本身依然交給剛體物理和碰撞系統(tǒng)處理 [來源]。

下面把每一步展開講。

第一步：理想方向——它本來想往哪兒走？

先只考慮“目標(biāo)”，不考慮障礙和友方。目標(biāo)可以是玩家位置、某個(gè)路徑點(diǎn)、玩家周圍的某個(gè)隨機(jī)點(diǎn)等。理想前進(jìn)方向就是：從自己指向目標(biāo)的單位向量。這一方向是后面所有計(jì)算的“基準(zhǔn)”，避障和群體行為都只是對(duì)這個(gè)基準(zhǔn)做修正。如圖：

第二步：射線檢測——這條路通不通？

有了理想方向之后，下一步是判斷：“如果沿著這個(gè)方向往前走，近期內(nèi)會(huì)不會(huì)撞到墻或障礙？”

方法很簡單，從單位中心以及單位的邊緣，如果是圓形碰撞器，就是對(duì)應(yīng)方向間隔半徑的兩條射線（可以再略大一點(diǎn)，留點(diǎn)余裕比較好），沿理想方向發(fā)射三條射線，這樣可以檢測出去往目標(biāo)的路徑上有沒有能擋住自己這個(gè)體積物體的障礙。射線注意只檢測“墻/障礙”所在的 Layer，優(yōu)化性能。如圖：

如果射線前方?jīng)]有命中任何障礙，這一幀就可以直接沿理想方向移動(dòng)，不需要額外繞路。如果射線撞到了障礙，說明正前方有墻或阻擋，進(jìn)入“扇形掃描”階段：

第三步：扇形掃描 + 記住繞哪邊——選出“次優(yōu)方向”

當(dāng)前方被擋住時(shí)，單位不會(huì)立刻停下，而是在理想方向附近的一個(gè)扇形區(qū)域里，嘗試若干個(gè)稍微偏左、偏右的方向，這個(gè)范圍和精度可配，決定了掃描的精度和性能代價(jià)，例如配置了120度范圍，每10度發(fā)一個(gè)射線。順序就是從理想方向開始左右擴(kuò)散來試探，如圖：

每試一個(gè)方向，都像第二步一樣用射線檢測前方是否有障礙，一旦找到“前方一段距離內(nèi)都沒有障礙”的那個(gè)方向，就把它作為本幀的避障方向。

這里，為避免單位在某些墻角來回左右搖擺，可以給每個(gè)單位記錄一個(gè)“上次繞障偏向”（例如優(yōu)先偏右），下一次再遇到障礙時(shí)，優(yōu)先從這一側(cè)開始掃描，這樣就能避免在墻角附近“一會(huì)兒想從左繞、一會(huì)兒又改從右繞”，導(dǎo)致方向抖動(dòng)。

如果扇形范圍內(nèi)所有候選方向都被判定為“前方有障礙”，則進(jìn)入下一步：

第四步：墻滑動(dòng)——被擋住時(shí)別硬頂，沿墻溜過去

當(dāng)理想方向被障礙擋住時(shí)，可以沿著墻的邊緣走，既然正對(duì)著墻走不通，那就沿著墻面切線方向滑過去，只要不是封閉空間，總能走出去。

具體做法：

障礙碰撞檢測時(shí)能得到一個(gè)法線方向（即墻面朝向單位的那一側(cè)）

把當(dāng)前想走的方向拆解成兩部分：

1. 垂直墻面的分量（正頂著墻）
2. 平行墻面的分量（沿著墻滑）

去掉“垂直墻面、撞墻那一部分”，只保留沿墻的方向

效果上看就是：

單位不會(huì)呆呆地頂在墻上不動(dòng)，而是自動(dòng)“貼著墻邊擦過去”。

第五步：多單位避讓，空間分區(qū)方法

這一步是防止單位間重疊，肯定不能用碰撞器，性能消耗過大，同時(shí)也不能直接兩兩檢測距離，那樣的復(fù)雜度就是 O(N2)，這里就要用到一個(gè)比較通用的方法：空間分區(qū)。

空間分區(qū)的核心思路就是把地圖劃分成網(wǎng)格，每個(gè)單位每幀通過自己的坐標(biāo)，加入自身所屬網(wǎng)格，每個(gè)網(wǎng)格里的單位，只關(guān)心自身所在格子和附近網(wǎng)格的單位，例如附近八格，如此，每次計(jì)算量就大大縮小。然后對(duì)過于靠近自己的鄰居，施加一個(gè)推開的傾向，可以越近，力度越大。

這一步的結(jié)果是得到一個(gè)“分離向量”：它代表“為了不擠到別人，應(yīng)該稍微偏移的方向”。

第六步：方向融合 + 平滑 + 隨機(jī)擾動(dòng)——最終行走方向

到這一步為止，我們手里已經(jīng)有幾種方向信息：

• 理想前進(jìn)方向（只考慮目標(biāo)）
• 避障/繞墻后的方向（考慮了墻和障礙）
• 來自鄰居的分離方向（防止擠成一團(tuán)）

現(xiàn)在要把它們合成一個(gè)最終移動(dòng)方向，并做好“防抖動(dòng)”處理：

這里可以進(jìn)行一個(gè)加權(quán)處理，權(quán)重更高的是“避障方向”，因?yàn)椴蛔矇κ堑拙€?！胺蛛x方向”是其次，讓單位輕微遠(yuǎn)離鄰居。兩者合成就是當(dāng)前的新方向，但是不能直接應(yīng)用，因?yàn)楹屠硐肭斑M(jìn)方向間，會(huì)有一個(gè)跳變，就會(huì)很奇怪地抖動(dòng)。為了自然，可以記住一個(gè)“當(dāng)前移動(dòng)方向”，每幀向新的目標(biāo)方向緩慢靠近，可以用各種插值方法，不贅述。

最后得出一個(gè)行走方向后，再給一個(gè)小的隨機(jī)擾動(dòng)，來打破一些極端情況下的僵局，例如兩堵墻對(duì)稱，單位在其中尬住。

第七步：生效移動(dòng)

最終方向確定后，真正的移動(dòng)可以交給物理系統(tǒng)，也可以直接賦位置，我們選擇后者，因?yàn)楦⌒阅?，完全不讓多單位參與unity的物理，都由我們自己計(jì)算，也為后面的性能深度優(yōu)化做鋪墊。

三、加入物理影響

整體架構(gòu)

整體思路是用虛擬的力，來統(tǒng)一銜接物理和非物理部分，對(duì)于多單位來說，所有的物理效果，都通過抽象的“力場 ForceData”來實(shí)現(xiàn)。我們以兩個(gè)典型的物理效果，爆炸沖擊波，以及黑洞引力來舉例：

• 所有爆炸、黑洞等效果，不再直接去改單位，而是統(tǒng)一抽象成力場
• 場景中所有力場由一個(gè)ForceManager集中管理和更新
• 每個(gè)單位自己持有“受力狀態(tài)”（外力速度、是否擊暈等），每幀由 ForceManager 計(jì)算它應(yīng)該受到多少外力

這樣一來：

• 技能/道具只負(fù)責(zé)“創(chuàng)建某種力場”（比如在某點(diǎn)創(chuàng)建一個(gè)爆炸力場）
• ForceManager 負(fù)責(zé)“這個(gè)力場到底對(duì)哪些單位、造成多大力”
• 單位只需要把“自己的受力結(jié)果”加進(jìn)最終移動(dòng)速度即可

架構(gòu)干凈、可擴(kuò)展，也便于以后加新類型的力如風(fēng)場、磁場等，力的數(shù)據(jù)結(jié)構(gòu)統(tǒng)一抽象成 ForceData后，也可以為后續(xù)ECS的深度優(yōu)化做準(zhǔn)備。

力場 ForceData

ForceData 主要字段包括：

• 位置：力場中心（如爆炸點(diǎn)、黑洞中心）
• 類型：爆炸、吸引（黑洞）、定向推力（沖擊波）、漩渦……
• 半徑：影響范圍
• 強(qiáng)度：力的基礎(chǔ)大小
• 持續(xù)時(shí)間：是瞬時(shí)爆炸還是持續(xù)吸引
• 時(shí)間進(jìn)度：已經(jīng)過了多久，用來做時(shí)間上的衰減
• 距離衰減指數(shù)：力隨距離衰減的曲線（線性、平方等）
• 是否影響“可控單位”：可以控制某些力只作用于怪物，不影響玩家

單位

而每個(gè)單位自己，還會(huì)有一份“受力狀態(tài)”：

• externalVelocity：由外力產(chǎn)生的速度（和自身移動(dòng)速度區(qū)分開）
• stunTime：當(dāng)前剩余的擊暈時(shí)間
• mass：質(zhì)量，用來控制“同樣爆炸，對(duì)重單位擊飛更小，對(duì)輕單位更大”

力場管理器ForceManager

ForceManager 是整個(gè)系統(tǒng)的“中樞”：

• 內(nèi)部維護(hù)一個(gè)活動(dòng)力場列表：所有仍在生效的爆炸、黑洞等等

每幀會(huì)做兩件事：

• 更新所有力場的時(shí)間進(jìn)度，過期的自動(dòng)移除
• 提供接口給單位/UnitManager：計(jì)算某個(gè)單位當(dāng)前受到的總外力

力場的創(chuàng)建非常簡單：

• 爆炸：在某點(diǎn)創(chuàng)建一個(gè)“爆炸型力場”，半徑 + 強(qiáng)度 + 持續(xù)時(shí)間很短
• 黑洞：在某點(diǎn)創(chuàng)建一個(gè)“吸引型力場”，半徑大、持續(xù)時(shí)間長

然后計(jì)算單位受力時(shí)的邏輯，遍歷所有活動(dòng)力場，對(duì)每個(gè)力場：

• 算出單位與力場中心的距離
• 如果超出半徑 → 這個(gè)力場對(duì)該單位無效，跳過
• 在半徑內(nèi) → 按距離衰減、時(shí)間衰減計(jì)算出當(dāng)前力的大小
• 根據(jù)力場類型，決定方向，爆炸就是從中心向外，黑洞就是指向中心
• 把所有力場對(duì)該單位的力向量相加，得到總外力，這樣外力是線性可疊加的，多個(gè)爆炸疊在一起會(huì)更猛，一個(gè)爆炸疊加一個(gè)黑洞會(huì)產(chǎn)生復(fù)雜但可預(yù)期的效果。

拿到 ForceManager 給出的“總外力”之后，單位要做的事只有三步：

步驟一：把力轉(zhuǎn)換成外力速度（擊飛）

• 力 → 沖量 → 速度變化：力越大、單位越輕，速度變化越大
• 把這一部分速度寫入 externalVelocity 中
• 為避免數(shù)值過大，給外力速度設(shè)一個(gè)最大值上限（比如 maxExternalSpeed）

步驟二：判斷是否進(jìn)入擊暈/失控狀態(tài)

• 擊暈單位不能進(jìn)行自主移動(dòng)（不能追玩家、不能執(zhí)行 AI 行走）
• 只剩下“外力產(chǎn)生的慣性速度”和模擬阻力在起作用
• 擊暈時(shí)間隨著時(shí)間減小，到 0 后恢復(fù)正?？刂?/li>
• 擊暈狀態(tài)可以防止出現(xiàn)炸飛還在移動(dòng)的情況，可以讓被動(dòng)的運(yùn)動(dòng)更加自然。

步驟三：外力速度的自然衰減（模擬阻力）

• 每一幀，都對(duì) externalVelocity 施加一個(gè)全局阻力系數(shù)
• 當(dāng)外力速度很?。ń?0）時(shí)，直接歸零，避免永遠(yuǎn)留著一個(gè)極小的殘余值

與原有移動(dòng) / 避障系統(tǒng)的融合

如果單位處于擊暈狀態(tài)，直接用externalVelocity。如果單位處于正常狀態(tài)，則根據(jù)之前計(jì)算出來的移動(dòng)速度向量，和externalVelocity進(jìn)行相加。

四、總結(jié)和性能優(yōu)化

性能優(yōu)化總體有幾個(gè)非常通用的思路，不同工程其實(shí)差不多。

1. 通過四叉樹八叉樹等空間分區(qū)方法，讓多單位間的查詢，從 O(N2) 到 O(N)
2. 通過多線程和數(shù)據(jù)管理來優(yōu)化，unity里可以用DOTS，甚至放GPU去做復(fù)雜的并行計(jì)算
3. 分幀，平滑每幀的消耗
4. LOD思路，重要的單位算細(xì)一點(diǎn)，不重要的粗一點(diǎn)，屏幕外看不到的，更粗糙等等
5. 能近似就近似，復(fù)雜運(yùn)算簡化，例如這個(gè)工程里就會(huì)用到的距離的平方來判斷距離，減少開方，復(fù)雜函數(shù)讀表等等技巧

對(duì)于我們上述的基本實(shí)現(xiàn)，還沒進(jìn)行任何優(yōu)化，可以支持2000個(gè)單位60幀率運(yùn)行，而且是在編輯器下，這還遠(yuǎn)遠(yuǎn)沒到我們的要求，通過profiler分析（忘記截圖了），不出所料，最耗性能的是射線檢測部分。那我們先進(jìn)行一波射線檢測放JobSystem多線程處理的快速優(yōu)化，一通改造代碼，性能提升很明顯，可以做到5000個(gè)單位，帶物理效果，100幀左右。最終結(jié)果如下:

到這里，初步驗(yàn)證方案的可行性已經(jīng)通過，可以給程序去實(shí)現(xiàn)了，就不再深入優(yōu)化了，我只是個(gè)可憐的小策劃，理論上按我之前經(jīng)驗(yàn)，全套用ECS實(shí)現(xiàn)，再加上各種優(yōu)化，最終能支持?jǐn)?shù)萬個(gè)單位同屏，考慮到最后效果復(fù)雜之后，縮到幾千個(gè)也足夠用了。