作者：Minke某廠搬磚戰(zhàn)斗策劃

首發(fā)知乎https://zhuanlan.zhihu.com/p/567528044

全文21000+字，參考圖&視頻140+，建議在PC端閱讀，建議配合上一篇數(shù)值篇一起食用。

內(nèi)容量很大，預(yù)估閱讀時間不確定，建議想認真看完全文的同學分課時閱讀，一次看完消化不了。

前言

距離上一篇講槍械數(shù)值的文章發(fā)布已經(jīng)過了8個月。

不過恰恰是因為隔了這么久，在武器表現(xiàn)層面上又有了些新的感受。

這半年做了上線項目的武器表現(xiàn)升級，動作、音效、動作品質(zhì)提升和相關(guān)客戶端邏輯；去新項目之后又從頭看了一遍更底層的東西，包含Control層面的靈敏度、輔助瞄準，制定一些前期美術(shù)規(guī)范之類的內(nèi)容，相對來說對武器表現(xiàn)，主要是打擊感，有了更全面的認知，這才敢來寫這一塊的相關(guān)內(nèi)容。

這一篇和數(shù)值篇一樣，可以理解為是反拆+經(jīng)驗分享，主要目的是幫助大家查漏補缺（提需求的時候翻一遍），或是建立對槍械設(shè)計的最基礎(chǔ)的認知，以后填問卷的時候除了說“動作僵硬打擊感差”，還可以說些更細致的內(nèi)容。

列舉的僅僅是我工作中做過或者拆解過的模塊，應(yīng)該列不全，也不會過于深入，只要正兒八經(jīng)做過射擊的戰(zhàn)斗策劃應(yīng)該都能覆蓋到，我只是做了一點點淺薄的整理工作，要轉(zhuǎn)發(fā)甚至是洗稿都隨意，畢竟射擊市場卷到現(xiàn)在，大家已經(jīng)不是在拼有沒有，而是做的怎么樣了，看手藝的事我還是有信心。

游戲交互的藝術(shù)博大精深，還需要諸君一起努力。

綱要：聊聊打擊感

我認為打擊感是一種交互的樂趣，核心組成部分是輸入（Control）與反饋（camera&character）

反饋有很多種，也許現(xiàn)在是視覺聽覺觸覺，隨著技術(shù)的發(fā)展還能期待更多的感觀刺激。

這句話需要注意的是，我特別強調(diào)了輸入：

在主機和PC平臺，我們的輸入行為都是通過手柄/鍵鼠這類機械硬件，他們提供的反饋更多是來自于我用的什么樣的設(shè)備，或是游戲內(nèi)鼠標/手柄速度的區(qū)別，可控空間不大。

但是在手機平臺，當玩家最基礎(chǔ)的位移和轉(zhuǎn)向都要通過虛擬搖桿來實現(xiàn)的時候，如何用虛擬搖桿還原出主機/PC平臺的操作，甚至比主機平臺更加跟手，是一切打擊感的基礎(chǔ)。

“玩家連人都瞄不準，后面的反饋再花里胡哨有什么用呢”。

大概包含的內(nèi)容

全文會以FPP射擊手游為主來講打擊感，看完的話應(yīng)該就能理解為什么大家都說“策劃什么都懂一點，什么都搞不明白”。

一、Control（手游）

控制層主要包含兩塊內(nèi)容，一塊是玩家自己的主動輸入，一塊是我們利用機制給到玩家的被動補償，目標都是提供及時、精準、符合預(yù)期的反饋，從而強化操控感和打擊感。

這里主要聊手游，在control層面，手游會比端游復(fù)雜很多。

1. 主動輸入

1.1 轉(zhuǎn)向（右搖桿）

手機上的轉(zhuǎn)向設(shè)計常見三種類型：固定加速、距離加速、速度加速。

• 固定加速：模擬手柄操作，轉(zhuǎn)向加速度是恒定的，轉(zhuǎn)向角度取決于滑動距離
• 距離加速：玩家滑屏距離越遠，轉(zhuǎn)向的加速度越快（這個好像只有CODM在用）
• 速度加速：玩家滑屏速度越快，轉(zhuǎn)向速度越快（射擊手游的主流靈敏度設(shè)計）

這里只聊速度加速的一些查漏補缺點。

1.1.1 輸入平滑的處理

由于滑屏的采樣和幀率掛鉤，如果在滑屏過程中出現(xiàn)丟幀，客戶端拿到的數(shù)據(jù)不平滑，滑屏速度的變化也會受到影響，導致轉(zhuǎn)向失控；即使不丟幀，如果直接使用采樣到的原始數(shù)據(jù)，速度變化的幅度也偏大，表現(xiàn)并不會太好。針對這種情況，我們需要取覆蓋面更廣的采樣數(shù)據(jù)，或是針對單個采樣做優(yōu)化，來實現(xiàn)曲線的平滑變化。

• 持續(xù)滑屏平滑處理：在玩家持續(xù)滑屏時，建議用當前幀和上一幀，幀數(shù)更高的情況下可以再取一幀，加權(quán)處理幀數(shù)間的速度變化，這樣在丟幀/幀數(shù)低的情況下，仍然能夠取得相對平滑的數(shù)據(jù)。
• 針對首幀的平滑處理：首幀滑屏由于缺少連續(xù)滑屏的數(shù)據(jù)做平滑，會做一個單位時間位移超過X個像素點時，對數(shù)據(jù)進行縮放的處理，避免首幀速度過快導致鏡頭失控。當玩家真的有高速滑屏需求時，后面的幀數(shù)會迅速跟上速度。（注意這里一定是達到某種高速狀態(tài)時再來做縮放，核心是避免誤觸或者數(shù)據(jù)誤差導致失控，而不是讓玩玩家低速卡手）

1.1.2 系統(tǒng)層防誤觸的平滑處理

IOS和安卓在系統(tǒng)層都有防誤觸設(shè)計，用于分辨滑屏和點擊，這里會導致兩個問題：

系統(tǒng)層防誤觸設(shè)計導致的輸入延遲

• 在系統(tǒng)層判定距離內(nèi)，即α時間段（此時假設(shè)3幀），這段時間內(nèi)玩家的物理上滑動屏幕并不會得到響應(yīng)
• 當系統(tǒng)層判定為滑屏，從而開始返回數(shù)據(jù)到客戶端時，首次上報的坐標位置和初始位置差距會偏大，玩家會發(fā)現(xiàn)鏡頭前幾幀沒反應(yīng)，第四幀突然出現(xiàn)一個大的跳動。

這里也需要做平滑處理，可以采用上面處理首幀的方式來做限定條件下的縮放，也可以針對IOS，直接不取第一幀的滑屏數(shù)據(jù)，看項目組對手感靈敏程度是否有強要求。

1.1.3 DPI換算

我們做靈敏度的最終目的是，希望能夠讓玩家形成肌肉記憶，從而在不同設(shè)備上實現(xiàn)無縫切換。

所以我們針對玩家輸入數(shù)據(jù)的單位，并不是像素點，而是需要歸一換算至具體的英寸。

即：

玩家以相同速度滑動一定的物理距離，在不同手機上的表現(xiàn)需要是一致的。

所以需要做的是確定一個標準DPI下的體驗后，不同機型根據(jù)DPI標準做一個比例縮放。

有的項目是用屏幕尺寸來直接定的標準，邏輯上是一樣的。

1.1.4 FOV換算(可選）

FOV 50-中速滑屏表現(xiàn)

FOV 90-中速滑屏表現(xiàn)

如上圖對比可以發(fā)現(xiàn)，轉(zhuǎn)動同樣的距離，因為鏡頭內(nèi)變化更大，F(xiàn)OV50會比FOV90看起來轉(zhuǎn)向的角度更大，所以可以嘗試針對場景fov的不同，新增一個縮放控制系數(shù)，使玩家在體感上滑動差異不會過大。

當然也可以像CODM一樣不做處理，除開玩家設(shè)置，改變場景FOV只有舉鏡行為，那么開鏡這種行為單獨去設(shè)置好玩家不同倍鏡的開鏡靈敏度，也能實現(xiàn)控制轉(zhuǎn)向的效果。

1.1.5 靈敏度曲線設(shè)計

經(jīng)過上文的一大堆處理之后，我們拿到了玩家的輸入數(shù)據(jù)，但如何將玩家的輸入數(shù)據(jù)映射成轉(zhuǎn)向度。

我們需要建立 單位時間移動距離（速度）和 鏡頭轉(zhuǎn)向角度 的關(guān)系。

這個曲線需要滿足以下幾個條件：

• 低速階段，能夠?qū)崿F(xiàn)小幅的精準移動
• 加速階段，能夠迅速識別玩家的快速滑屏意圖，轉(zhuǎn)向角度能夠迅速增加
• 高速階段，能夠?qū)撬俣冗M行收斂，避免玩家的鏡頭失控
• 需要有一個區(qū)間，控制玩家鏡頭移動的最大速度和最小速度

那么滿足這些條件的曲線其實已經(jīng)呼之欲出了。

常見的速度加速靈敏度映射曲線

曲線的調(diào)試需要跟戰(zhàn)斗體驗掛鉤，PVP游戲的轉(zhuǎn)向區(qū)間要求就肯定比PVE大，曲線也要朝這個方向調(diào)整。

在滿足預(yù)期轉(zhuǎn)向目標的情況下，覆蓋的滑屏速度范圍盡可能做大，這樣才能實現(xiàn)顆粒度更細的滑屏，避免稍微一起速就進入超速收斂區(qū)間的情況。

1.1.6 靈敏度調(diào)試的小工具

• 輸入工具：推薦蘋果系統(tǒng)的自定手勢，能夠完整復(fù)現(xiàn)滑屏操作，確保每次的輸入量完全一致

蘋果的自定手勢工具

• 監(jiān)測工具：需要在編輯器內(nèi)做一個調(diào)試工具，實時展示當前幀數(shù)滑屏距離和對應(yīng)轉(zhuǎn)向角度、總滑屏距離和轉(zhuǎn)向角度的工具，錄屏之后用能夠逐幀播放的播放器檢驗每幀的變化，這個每個項目都有自己的調(diào)試工具，我就不截圖了
• 評估工具：我的習慣是用總轉(zhuǎn)向角度和競品對比，確保整體的轉(zhuǎn)向角度差異不大，針對過程中變速數(shù)據(jù)，會用excel記錄數(shù)據(jù)做逐幀對比，觀察具體的差異點，但最快的評估工具仍然是負責策劃的手和腦子，最好的評估工具永遠是玩家CE

1.2 位移（左搖桿）

位移相對于轉(zhuǎn)向來說就不會有這么多的踩坑點，大多數(shù)設(shè)置市面上都有現(xiàn)成的參考，需要關(guān)注的內(nèi)容主要集中在兩塊：位移角度和位移距離。

1.2.1 位移角度

在數(shù)值篇提到的不同方向速度設(shè)置及數(shù)值的差異

左搖桿校正區(qū)/死區(qū)示意

奔跑觸發(fā)的角度示意

我們在數(shù)值篇的時候時候提到，我們向前的速度和向左右后的速度是不一致的，其中簡單提過擴大判定區(qū)域來幫助玩家前進的設(shè)計，這里做一下更細致的說明，左搖桿的區(qū)域大概分為以下幾塊：

• 紅色區(qū)塊：搖桿中心的死區(qū)，避免搖桿過于靈敏導致玩家無法實現(xiàn)靜止操作
• 淺紅色區(qū)塊：前后左右四方向校正區(qū)，玩家在這個角度之內(nèi)位移，移動方向為標準的前后左右
• 白色區(qū)塊：玩家向左前/右前/左后/右后位移的操作區(qū)間，這里的映射角度支持支持配置，例如此時留給玩家的物理操作區(qū)間為15——75度，可以將游戲內(nèi)虛擬操作區(qū)間也做成15——75度，也可以映射為30——60度/0——75度或其他角度
• 綠色區(qū)塊：支持進入跑步狀態(tài)的觸發(fā)角度，還可以做更細的奔跑保持角度之類的設(shè)計

這些區(qū)域的設(shè)計目的主要是兩點：

• 避免玩家一些誤操作/噪點操作，例如想靜止但是一直在走，想走直線但是一直在左右小偏移
• 降低玩家的操作門檻，手指的大小和靈活程度確實因人而異，許多區(qū)域需要做大做寬來讓玩家感到更跟手

1.2.2 位移距離

左搖桿觸發(fā)距離示意

實現(xiàn)玩家的精細移動，除了位移角度設(shè)計外，還需要做細致的位移距離處理，一般的位移距離劃分為以下幾塊：

• 紅線：上文提到的死區(qū)，玩家在這個范圍內(nèi)滑動，不會有任何效果
• 綠線：紅線到綠線的位置，玩家在這個范圍內(nèi)滑動，觸發(fā)行走行為；玩家滑動到綠線范圍以外，觸發(fā)奔跑行為
• 橙色圈&橙色底：虛擬搖桿圖示
• 藍線：當玩家滑動到藍線區(qū)域以外時，鎖定奔跑行為，此時松開手指玩家進入持續(xù)奔跑狀態(tài)

1.3 按鈕操作邏輯

1.3.1 點擊

點擊層面，遇到過的問題大概是以下幾個，圍繞著即時性和優(yōu)先級。

• 觸發(fā)邏輯：按下觸發(fā)，還是松手觸發(fā)，二者的感官差距極大，千萬要跟程序?qū)R，例如開鏡往往是按下觸發(fā)，而開火根據(jù)武器類型的不同，可以做按下觸發(fā)和松手觸發(fā)
• 優(yōu)先級邏輯：當多個按鈕疊在一起，同時被點擊時，優(yōu)先觸發(fā)哪一個，這里按鈕的層級需要規(guī)劃，一般來說會把開火作為第一優(yōu)先級
• 響應(yīng)即時性：這里跟局內(nèi)一般沒啥關(guān)系，順帶提一下。存在兩個坑，一是需要跟服務(wù)器交互的按鈕響應(yīng)速度過慢（例如早期版本CODM的大廳），一個是UI動畫做的很長導致按鈕的生效節(jié)點不明確（例如按鈕有一個超長時間輪廓閃光）

1.3.2 長按

長按更多的關(guān)注點在于，玩家按住期間能夠支持的操作，這部分提需求時也需要想明白。

• 長按期間是否支持轉(zhuǎn)向：這個功能放在開火鍵/技能鍵上很好理解，實現(xiàn)一邊開火一邊瞄準的功能，但是其他按鈕，例如跳躍、開鏡、下蹲等是否默認開啟，是需要增加相關(guān)開關(guān)做控制的
• 長按響應(yīng)即時性：長按觸發(fā)的按鈕，在按下的時刻就能持續(xù)響應(yīng)玩家的操作，這里需要注意的是如何應(yīng)對中途的打斷和打斷后的狀態(tài)，例如玩家按住開火后，子彈打空觸發(fā)換彈，開火鍵以怎樣的頻率去持續(xù)校驗，從而實現(xiàn)玩家不松手的情況下，換彈完畢后立即開火

這里再提一個有趣的BUG或者機制，CODM的按鈕因為組件不同，玩家按住下蹲鍵，之后將手指拖拽到開鏡鍵上，能夠連貫實現(xiàn)下蹲/滑鏟開鏡的操作；如果我們進一步細化考慮按住某個按鈕并且滑屏的情況下，是否能與其他按鈕有交互，也許會進一步優(yōu)化手感。

1.3.3 按鈕的融合

PC和主機平臺因為按鍵足夠多、相互分離且操作便利，加功能會很方便，例如槍械檢視、卡殼處理等等。

但手機平臺屏幕尺寸有限，玩家可以使用的手指也有限，所以會常見一些功能融合的按鈕，這些按鈕的邏輯也需要做精細設(shè)計并提供開關(guān)。

以最常見的一鍵開鏡開火為例，就會面臨先開鏡再開火，還是開鏡的同時開火？開火完畢后松開手指保持開鏡，還是自動落鏡等問題。

2. 被動補償

2.1 輔助瞄準

年初在寫數(shù)值篇的時候，還覺得AA這個東西需要藏著掖著，后來發(fā)現(xiàn)其實大家的功能都差不多，想拆隨時都拆的出來，甚至已經(jīng)有了現(xiàn)成的組件。

在代碼插件創(chuàng)建的Pro Aim Assist - 虛幻引擎商城

www.unrealengine.com/marketplace/zh-CN/product/pro-aim-assist-01

也是過了半年才明白，做出來是一回事，調(diào)好是另一回事，玩家不希望AA太強（APEXM測試/COD19手柄），更不希望AA太弱，我們需要做到的是“讓玩家覺得他自己很強”。

這里的調(diào)試邏輯和指導哲學，才是每個戰(zhàn)斗策劃的手藝所在。

所以這些東西是怎么實現(xiàn)的，真不重要了，可以簡單列一下。

2.1.1 吸附類

吸附定義可以概括為：槍械的準心在某些條件下，自動向目標靠近，輔助玩家射擊。

常見的吸附類AA包括開鏡吸附、開火吸附和磁力吸附，具體表現(xiàn)如下：

APEXM開鏡吸附

APEXM磁力吸附

開火吸附由于需要玩家開火，表現(xiàn)沒有開鏡和磁力這么直觀，可以理解為和開鏡吸附的邏輯一致，在開火的過程中逐漸把準心向目標身上靠。

吸附類的輔助瞄準的設(shè)計大概可以簡化為解決兩個問題：

目標選擇 和 吸附表現(xiàn)

A. 目標選擇：

• 目標處理：當準心周圍有多個目標時，是否以最近的目標為準；如何解決多個目標重疊時，玩家想打后面那個的問題
• 判定范圍：以膠囊體為生效范圍，還是在膠囊體外再增加一個判定框，進入判定框開始吸附；不同距離的判定框是否需要有大小差異；當準心指向膠囊體內(nèi)部以后，吸附是否持續(xù)生效
• 生效條件：只對敵方人體目標生效，或是同時對召喚物（靶場靶子）也生效；任何時候都生效，開鏡時生效，還是玩家有輸入甚至輸入達到一定閾值時才生效

B. 吸附表現(xiàn)：

• 方向：吸附的方向以人物中軸線為目標，還是以質(zhì)心為目標，還是以骨骼為目標
• 時間：吸附是配置固定時間，到時間就結(jié)束，還是沒有吸附到目標就持續(xù)吸附；是否需要根據(jù)距離單獨配置
• 速度：吸附的速度是固定的角速度，還是根據(jù)不同距離的吸附時間反算出來的插值速度
• 逃逸：當檢測到玩家的滑屏方向和吸附方向不一致時，需要取消吸附，需要考慮玩家是否在對抗吸附、玩家對抗的吸附的滑屏閾值、吸附消失的插值時間這些問題

2.1.2 阻尼類

定義：當玩家操作鏡頭劃過敵方目標時，滑屏靈敏度自動降低，使準心在目標身上停留更久，輔助玩家瞄準。

APEX端游阻尼

看上圖可以發(fā)現(xiàn)，鏡頭在滑動過敵方目標時，轉(zhuǎn)向靈敏度顯著下降（這圖確實看著容易頭暈）。

阻尼生效示意

阻尼的生效邏輯比較簡單，玩家的鏡頭劃過阻尼觸發(fā)范圍時，會乘上相關(guān)的阻尼系數(shù)（通常小于1），從而使轉(zhuǎn)向速度變慢。

• 橙圈：阻尼的生效范圍，支持不同距離配置不同的范圍
• 綠線：玩家的鏡頭朝向
• A點：阻尼系數(shù)為1，該點向左阻尼系數(shù)不生效
• B點/C點：阻尼系數(shù)為設(shè)定值，鏡頭劃過BC點（即膠囊體時），阻尼系數(shù)達到最大，支持不同距離配置不同的大小
• 灰色方塊：阻尼的插值區(qū)間，阻尼系數(shù)逐漸從1降低到設(shè)定值

2.1.3 修正類

無論是吸附類，亦或是阻尼類，都只是幫助玩家更好的瞄準目標，底線時玩家至少需要把準心放到目標身上。

接下來要看的修正類，才是真正的重量級。

定義：當玩家開火滿足一定條件時，對射出的子彈或是子彈軌跡進行修正，幫助玩家直接命中目標。

APEXM 子彈保底

命運2 子彈偏移

守望先鋒：歸來 彈線示意

APEXM的子彈保底和命運2的子彈偏移都是通過直接修改子彈的落點，來幫助玩家命中目標，不過實現(xiàn)上區(qū)別比較大。

守望先鋒則是通過直接修改子彈的碰撞體大小，將子彈判定從一條線，變成一個圓柱體（可以理解為毛妹沒能量時的柱子和有能量時的柱子），從而讓玩家更容易命中目標【這個不保真，聽小道消息說這樣做的】。

子彈保底（沒做過，我猜的）：

子彈保底是通過計數(shù)的形式來實現(xiàn)，當玩家命中目標的判定框N發(fā)子彈且沒有對目標造成傷害時，N+1發(fā)子彈會直接命中敵方目標

• 觸發(fā)范圍：膠囊體外新增一個判定框，支持隨距離的變化設(shè)置不同大小
• 觸發(fā)子彈數(shù)：支持可配置的子彈數(shù)量，不同槍型觸發(fā)條件不同
• 保底命中的實現(xiàn)：改子彈的軌跡或者改子彈碰撞的大小都可以實現(xiàn)，目標是讓玩家的這一發(fā)開火必定命中目標

子彈偏移：

關(guān)于子彈偏移，小黑盒的這篇文章講的很清楚，很感謝這個兄弟，這也是我坦誠分享的源動力之一。

https://api.xiaoheihe.cn/v3/bbs/app/api/web/share?link_id=54066776api.xiaoheihe.cn/v3/bbs/app/api/web/share?link_id=54066776

簡單來說：子彈偏移機制就是圍繞著屏幕中心發(fā)射多個判定圈，當不同的判定圈與目標碰撞體相接觸時，將子彈向碰撞體做不同程度的偏移。

子彈偏移示意

上圖是一個比較簡單的示意（雖然codm沒做這玩意）：

• 黃框：敵方目標高傷害碰撞盒
• 藍框：敵方目標標準傷害碰撞盒
• 紅圈：子彈基礎(chǔ)偏移圈，當紅圈與敵方目標碰撞盒重疊時，子彈會向紅圈內(nèi)，距離準心最近的碰撞盒位置偏移，協(xié)助命中目標，需要支持根據(jù)距離的變化，配置不同的偏移角度or偏移距離
• 黃圈：高傷部位偏移圈，當黃圈與敵方目標高傷害碰撞盒重疊時，會將子彈優(yōu)先偏移到高傷害的位置，需要支持根據(jù)距離的變化，配置不同的偏移角度or偏移距離

設(shè)計上很好理解，當玩家瞄的大差不差的時候，系統(tǒng)幫你偏一下， 偏移的程度還可以作為數(shù)值直接開放出來。

碰撞修改（小道消息，不保真）：

傳聞OW有子彈有兩套碰撞判定，一套是針對場景的，打一條射線，一套是針對目標的，打一個帶體積的圓柱。

雖然是傳聞，但實際上具有明顯的可行性，表現(xiàn)可以參考毛妹的柱子，一定是越粗越容易命中目標：

能量為0時柱子粗細

滿能量時柱子粗細

難點是否要為了這個輔助瞄準來做兩套碰撞體系，我技術(shù)力不夠，很難想象出具體的做法，不過確實也算是一種相對優(yōu)雅的輔助瞄準手段。

2.2 位移補償

如果做一個簡單的歸類，輔助瞄準是幫助玩家實現(xiàn)更精確的轉(zhuǎn)向，是在優(yōu)化右側(cè)虛擬搖桿的操作。

那么位移補償則是幫助玩家實現(xiàn)預(yù)期中的位移表現(xiàn)，優(yōu)化左側(cè)虛擬搖桿及相應(yīng)位移按鈕的操作。

2.2.1 移動優(yōu)化

在關(guān)卡設(shè)計中會有一個標準叫做通行流暢度，監(jiān)測玩家在這張地圖中的移動是否順暢，會不會感覺粘滯、卡頓。

這一塊其實算是關(guān)卡策劃的專業(yè)內(nèi)容，我不太懂，簡單列一些我見過的問題：地面凸起不合規(guī)范/未做行走落差處理，沒有針對過門做相應(yīng)的位移輔助，局內(nèi)障礙物的碰撞速度補償?shù)取?/p>

好消息是一份完整的3C Metrics文檔可以大幅優(yōu)化這些問題。

2.2.1.1 地面凸起/行走落差相關(guān)

在項目初期，3C的策劃會給一份3C Metrics文檔來限定局內(nèi)關(guān)卡的標準，包含人物高度/移速/跳躍高度之類的數(shù)據(jù)，其中就包括行走落差，指玩家不需要跳躍和攀爬，就可以行走通過的障礙物高度。

踩過的兩個小坑：

1.關(guān)卡的碰撞不一定需要和場景完全對齊：

行走落差一般是通過射線來做判定，也不會允許玩家攀上負角度的障礙物。

所以假設(shè)遇到這類具有設(shè)計感的負角度臺階/石頭，或是在地形比較復(fù)雜的情況下嘗試跨越90度臺階，都有可能造成一定的誤判。這里的建議是場景里的地形長這樣，但是相關(guān)的碰撞不一定要刷的一模一樣，給臺階的碰撞加一個坡度，大家的日子都會好過些。

特殊地形示意-負角度臺階

刷個帶坡度的完整碰撞

以這個負角度的臺階為例，如果碰撞真的刷成藍色和模型一摸一樣，大概會出現(xiàn)即使配置了很高的跨越高度，也會人物沒法直接走上去，需要點擊跳躍的問題。

這個時候如果多刷一個粉紅色區(qū)塊的碰撞，相關(guān)的行走和跨越表現(xiàn)就不會出錯了。

2.場景中的零碎物件也需要符合3C Metrics文檔：

為了避免關(guān)卡場景很空，我們往往會擺一些東西進去，什么桌子椅子箱子，花盆花臺欄桿，但這些物件在擺進去的時候就需要考慮到，這個東西是否能讓玩家直接走過去/翻過去，根據(jù)標準文檔來確定尺寸。

我自己有一個比較簡單的評估標準，來看某個物體到底應(yīng)該不應(yīng)該支持玩家行走通過：

當玩家鏡頭推平或處于常規(guī)角度（爆頭線/架槍位）時，出現(xiàn)在鏡頭中的物體需要翻越通過，沒有出現(xiàn)在鏡頭中的物體需要行走通過。

例如圖中的這個探照燈，早期版本是無法直接跨過去的，推動搖桿走到這里會頂住，玩家平視的情況下還看不見這個燈=。=好在后期修掉了這個BUG。

CODM突尼斯死亡探照燈

2.2.1.2 門的判定相關(guān)

在手游上精確的通過指定路線，對于大盤玩家來說一直是比較麻煩的事，和鍵盤按下WASD四個鍵相比，玩家的手指控制能力差異實在是過大了。

這意味著我們需要更寬的街道、更大的門來幫助玩家順暢通過，但即便做的再大，也會有玩家頂著門框就是不過區(qū)，這里提供一種過門輔助的手段：過門吸附。

過門輔助吸附框示意

CODM的過門輔助示意

吸附框的尺寸略大于門，確保玩家在門附近頂著墻的時候能夠被吸過去，從而順利通過窄門；

但這里需要注意的是，吸附框的寬度不宜過寬，最好需要玩家頂墻時再觸發(fā)，否則玩家無法實現(xiàn)利用門為掩體的peek操作，剛一探頭peek，人就直接被吸過去了。

2.2.1.3 頂墻/頂障礙物位移相關(guān)

拐角位移案例

頂墻/頂障礙物導致的位移速度異常，往往和位移的實現(xiàn)方式有關(guān)。

如圖所示，玩家的位移方向的移動速度，會拆解成X軸和Y軸的速度來實現(xiàn)，在沒有障礙物的情況下，X軸和Y軸的速度都是正常，玩家的移動不會有問題。

但假設(shè)玩家的位移朝向不變，此時頂住墻了，X軸提供的速度幾乎歸零，只有Y軸有速度時，玩家的移速就會偏慢。

而且由于玩家做搖桿指向的不精準，會經(jīng)常出現(xiàn)玩家認為自己在平行墻面移動，實際上靠墻遇到減速的情況。

（如果還是沒有理解這個問題，你可以現(xiàn)在放下手機或者站起來找一面墻，當你和墻面平行移動時，位移速度是正常的，但是當你與墻面夾角45度與墻親密接觸時，你的移動方向依然和墻面平行，但是速度會變慢不少）

和平精英頂墻處理

頂墻補償示意

這里就需要引入優(yōu)化方案：頂墻補償。

當玩家的碰撞體與墻壁/障礙物發(fā)生接觸，同時玩家的朝向和墻體/障礙物的夾角達到一定閾值條件時，提供一個垂直于障礙物法線方向的距離/速度補償，幫助玩家快速通過障礙物。

2.2.2 跳躍優(yōu)化

https://youtu.be/LrLHsbTK5bM?t=1904youtu.be/LrLHsbTK5bM?t=1904

跳躍這里，類似于平臺吸附之類的概念可能已經(jīng)見怪不怪了，這里貼一個《地平線：零之曙光》的分享。

是一套動畫驅(qū)動+程序驅(qū)動的系統(tǒng)。

大致流程是通過記錄玩家按下跳躍時的原始數(shù)據(jù)，預(yù)測跳躍軌跡，然后小幅調(diào)整速度和角度到指定落點。

位移距離調(diào)整

空中轉(zhuǎn)向調(diào)整

最終實現(xiàn)效果

• 白色弧線：最初數(shù)值計算出的跳躍軌跡
• 淺藍色弧線：校正后的跳躍軌跡
• 綠色大弧線：空中轉(zhuǎn)向的調(diào)整軌跡

這一套系統(tǒng)，比起大家目前常用的跳躍距離固定，全靠平臺上配吸附盒子強行吸到平臺的設(shè)計，最大的優(yōu)勢是實現(xiàn)了動畫系統(tǒng)的良好表現(xiàn)，再也沒有滑步?jīng)]有腳步懸空，配合Motion Matching的情況下不同跳躍距離能更有更流暢細致的動畫表現(xiàn)。

3A廠商的功力就體現(xiàn)在這些小小的細節(jié)上，不需要在通過各種手段做后續(xù)補償，而保證玩家一開始的落點就是精準的。

2.2.3 翻越優(yōu)化

翻越補償相關(guān)內(nèi)容

翻越的實現(xiàn)會比較麻煩，涉及到觸發(fā)距離、觸發(fā)角度、障礙物高度判斷/寬度判斷，障礙物上方/后方是否有足量空間，障礙物本身是否可翻，翻越過程中是否能開火/轉(zhuǎn)向等等細節(jié)。

絕大多數(shù)手游會把跳躍鍵和翻越鍵集成為一個按鍵，在障礙物附近時，需要玩家和障礙物的距離和朝向角度符合標準，按鈕才會從跳躍功能替換為翻越功能，如何更好的識別玩家的意圖，補償玩家的操作，主要的落腳點在于人物與障礙物的角度/距離和障礙物的判定上，同時還需要給判斷失誤的補償手段。

不過這樣做仍然會出現(xiàn)一定量級的誤判，如果需要更精細的操作顆粒度，推薦將跳躍和翻越拆開，徹底一勞永逸，否則補償和補償取消就是一個面多加水、水多加面的循環(huán)往復(fù)過程。

2.2.3.1 距離補償

距離補償

一般來說，翻越只有在玩家頂住障礙物時才支持觸發(fā)（例如PUBG端游早期），但這樣的體驗會是玩家快速奔跑——頂墻速度歸零——播放翻越動畫，感受上不連續(xù)，所以會額外做一個距離補償，當玩家所處的位置和障礙物的距離在一定閾值內(nèi)時，玩家點擊跳躍鍵，此時播放翻越動畫同時帶一個向前的位移，將玩家吸附到相應(yīng)的障礙物上完成翻越（如圖所示）。

在玩家跑動過程中可以將參數(shù)適當放大，來實現(xiàn)更好的跑動翻越效果。

2.2.3.2 角度補償

角度補償

玩家在翻越時，很難像翻越的圖示一樣完全垂直的面向障礙物，從機制上都會做一定的角度冗余，玩家沒有對準障礙物時仍然支持翻越，因為手游的操作精度更低，所以需要放大這個角度的限制。

2.2.3.3 障礙物吸附

過窗/翻越吸附

這里的處理方式很像是上面提到的過門輔助，主要的應(yīng)用場景是一些很小的窗戶（可以理解為沒有按照metrics文檔的后續(xù)補救），在翻越通過某些較小的門窗、偏窄的障礙物，可以放大吸附框（即上圖紅框），通過吸附校正的形式，幫助玩家更準確的完成翻越。

2.2.3.4 容錯機制

往后拉搖桿取消翻越

在做翻越補償?shù)臅r候，我們的目標永遠是幫助玩家更好的翻過去，但會忽略一個問題：如果玩家此時并不想翻，那么應(yīng)該怎么處理。

這個時候需要引入翻越取消的機制，常見的有翻越過程中點擊跳躍鍵，跳躍取消翻越，或是跟CODM和PUBGM一樣增加一個向后拉搖桿取消翻越。