轉自：http://www.gameres.com/677620.html
攻擊判定流程幾乎是所有包含戰斗玩法的游戲都無法繞過的一塊內容，常見的攻擊判定流程有瀑布算法、圓桌算法以及混合算法三種。本文簡述了這三種判定流程的特征，以實例對比分析了瀑布算法與圓桌算法各自的優點，以期為后續其他戰斗數值設計內容的論述提供一定的基礎。
攻擊判定流程概述
自此開始正文內容的敘述——讓我們直接代入一個實例：
在一款游戲中，攻擊方有命中率和暴擊率兩個攻擊屬性，而防守方有閃避率、招架率和格擋率三個防御屬性。於是相應的，一次攻擊有可能產生6種判定結果：未命中、普通命中、閃避、招架、格擋和暴擊。當采用不同的判定流程進行攻擊結算時，6種判定結果出現的頻率會截然不同。
1. 瀑布算法
顧名思義，在瀑布算法中，各事件的判定順序如同瀑布一般自上而下。如果“水流”在某個位置被截斷，則后面的流程都將不再繼續進行。據我所知，瀑布算法是大多數游戲所采用的攻擊判定算法。
上述實例若采用瀑布算法，則會以如下方式進行判定：
- 先判定攻方是否命中
- 再判定是否被守方閃避
- 再判定是否被守方招架
- 再判斷是否被守方格擋
- 最后判定該次攻擊是否為暴擊
<ignore_js_op>
瀑布算法流程圖
由此我們可以得出：
瀑布算法特征1：多次擲骰，一次擲骰只判定單個事件的發生與否
瀑布算法特征2：后置判定依賴於前置判定的通過
注：有的游戲會將命中和閃避合並在一次擲骰中判定，這意味着將攻方命中率與守方閃避率合並計算出實際擊中概率后再進行擲骰判定，仍是瀑布算法
我們再代入一些具體的數值，設攻守雙方角色的面板屬性如下：
攻方命中率=90%
攻方暴擊率=25%
守方閃避率=20%
守方招架率=15%
守方格擋率=30%
按照上述的流程判定，6種判定結果將會按如下的概率分布：
實際未命中概率=1-命中率=1-90%=10%
實際閃避概率=命中率*閃避率=90%*20%=18%
實際招架概率=命中率*（1-閃避率）*招架率=90%*(1-20%）*15%=10.8%
實際格擋概率=命中率*（1-閃避率）*（1-招架率）*格擋率=90%*(1-20%)*(1-15%)*30%=18.36%
實際暴擊概率=命中率*（1-閃避率）*（1-招架率）*（1-格擋率）*暴擊率=90%*(1-20%)*(1-15%)*(1-30%)*25%=10.71%
實際普通命中概率=命中率*（1-閃避率）*（1-招架率）*（1-格擋率）*（1-暴擊率）=90%*(1-20%)*(1-15%)*(1-30%)*(1-25%)=32.13%
<ignore_js_op>
瀑布算法的判定結果分布
由此我們可以得出：
l 瀑布算法特征3：各事件出現的概率符合經典的概率計算方法
l 瀑布算法特征4：擲骰輪次越偏后的屬性衰減程度越大，但不會出現無效的屬性
2.圓桌算法
將所有可能出現的事件集合抽象成一個圓桌桌面，便是圓桌算法這一稱呼的由來。圓桌算法的實質，是將所有可能發生的事件狀態按優先級依次放上桌面，直至所有事件被放完或桌面被填滿。圓桌算法正是史詩級巨作魔獸世界中所采用的算法。據筆者了解，使用該算法的游戲並不多見，但即便僅魔獸世界這一款，已足以使這種算法成為永恆的經典~
上述實例若采用圓桌算法，則會用一次擲骰判定該次攻擊的結果。
<ignore_js_op>
圓桌算法流程圖
圓桌算法的操作步驟可以歸納為：
（1）攻方角色的命中率決定圓桌桌面的大小
（2）將各個事件狀態按優先級依次放上桌面，直至所有的事件均放置完或桌面被填滿
（3）若桌面還未填滿，則用普通命中填滿空桌面
將先前設定的數值代入，6種判定結果將會按如下的概率分布：
實際未命中概率=10%
實際閃避概率=20%
實際招架概率=15%
實際格擋概率=30%
實際暴擊概率=25%
實際普通命中概率=90%-實際閃避概率-實際招架概率-實際格擋概率-實際暴擊概率=90%-20%-15%-30%-25%=0%
注：在上述計算中，優先級按如下排序：閃避>招架>格擋>暴擊>普通命中
<ignore_js_op>
圓桌算法的判定結果分布
可以看出，由於普通命中的優先級最低，所以它被完全擠出了桌面。這意味着，若攻守雙方以此數值模型進行對決，則攻擊方的攻擊結果中將不存在普通命中。
由此我們可以得出：
圓桌算法特征1：一次擲骰即得出該次攻擊的判定結果
圓桌算法特征2：事件有優先級，圓桌放滿后優先級低的事件將被擠出桌面。這意味着那部分溢出的屬性將不再生效
圓桌算法特征3：圓桌內的各事件出現概率不會衰減，只要優先級低的屬性沒有被擠出圓桌，各種事件的實際發生概率就與面板屬性數值吻合
3. 混合算法
這是一種先判定攻方事件，再判定守方事件的判定流程。筆者曾在一篇帖子中看到過這樣判定流程，不確定是否有實際的游戲應用，故僅在此做一些簡單的理論分析。
混合算法在單方事件的判定中采用圓桌算法，即：
攻方判定結果：普通命中OR未命中OR暴擊
守方判定結果：閃避OR招架OR格擋OR被命中
<ignore_js_op>
混合算法流程圖
注：上面這個圖僅作示意之用，從流程圖的角度來看可能不太嚴謹
將先前設定的數值代入，6種判定結果將會按如下的概率分布：
實際未命中概率=10%
實際閃避概率=攻方命中率*閃避率=90%*20%=18%
實際招架概率=攻方命中率*招架率=90%*15%=13.5%
實際格擋概率=攻方命中率*格擋率=90%*30%=27%
實際暴擊概率=攻方暴擊率*敵方被命中概率=25%*(1-20%-15%-30%)=8.75%
實際普通命中概率=攻方普通命中概率*敵方被命中概率=(90%-25%)*(1-20%-15%-30%)=22.75%
<ignore_js_op>
混合算法的判定結果分布
由此我們可以得出：
混合算法特征1：先判定攻方事件，再判定守方事件，共進行兩次擲骰
混合算法特征2：先在單方事件的判定中采用圓桌算法，再用瀑布算法串聯攻守雙方事件
混合算法特征3：會產生並發動作，例如暴擊被閃避等
注：這也正是實際暴擊率較低原因所在
瀑布算法與圓桌算法的特性對比
在上一塊內容的鋪墊之下，我們不妨繼續以魔獸世界中的攻擊判定流程設計實例作為切入點，對比分析一下圓桌算法與瀑布算法各自的特性。
（1）面板屬性傳遞信息的直觀性
瀑布：由於各屬性在判定流程上的生效時間有先后之分，所以各屬性的實際效用與面板顯示的不符。
圓桌：由於屬性的判定沒有先后之分，只要沒有屬性被擠出圓桌，則所有屬性的實際效用與面板顯示的相當。
這里可以看出圓桌算法的優點：
屬性的實際效用與面板顯示相符顯然更易於普通玩家的理解，便於玩家掌握自身的戰力情況。
（2）屬性的價值
瀑布：擲骰輪次越偏后的屬性衰減程度越大，但所有的屬性均會生效。
圓桌：只要沒有屬性被擠出圓桌，則不存在屬性效用的衰減。
這里可以看出圓桌算法的優點：
由於不存在判定流程上的先后，所以各屬性的實際價值會比較接近，一般不會出現玩家堆了某個判定流程靠后的屬性結果很廢的情況。
同樣也可以看出其缺點：
一旦有屬性溢出，則該部分屬性的效用為0，完全沒有價值。
（3）相同面板數值下的生存能力
圓桌：在面板數值相同的情況下，魔獸世界用圓桌算法大大提高了坦克角色的生存能力，使得他們可以應對來自首領怪的超高攻擊，匹配大型團隊副本的玩法設計。
瀑布算法下，免傷概率=18%+10.8%+18.36%=47.16%
圓桌算法下，免傷概率=20%+15%+30%=65%
傳統的概率為相乘關系，圓桌為相加關系，后者的概率總和要大的多
並且，當防御職業將三維堆至一個閾值（70%）后，配合技能可達100%的免傷覆蓋，將命中和暴擊全部擠出桌面，從而衍生出特定的玩法（70級年代伊利丹的剪切技能）。
瀑布：相同的面板數值在瀑布算法的框架下，免傷概率相較於圓桌算法要低得多。換言之，角色達到相同的有效生命值，所需的免傷屬性要高得多。
這里可以看出：
在圓桌算法的框架之下，屬性投放若是脫離了控制超過了閾值，將對平衡性產生較大的沖擊（70級的盜賊單刷格魯爾——當然在暴雪光環的作用下，玩家會認為這是精妙的設計~）。
在國產游戲收入導向的大環境下，設計者是否能頂住收入壓力，嚴守屬性投放的極值不越界，是值得慎思的問題。采用瀑布算法，能有更大的數值空間用於能力投放，更為適合現階段的市場環境。
（4）運算量
瀑布：多次擲骰
圓桌：單次擲骰
顯而易見：
擲骰次數越多，運算量越大。圓桌相較於瀑布，有着相對較小的運算量。簡單即是美。
注：除魔獸世界外，《冒險與挖礦》的技能施放也采用了圓桌算法，大大簡化了技能施放的判定流程。可以想象一下，一次攻擊至多發動一個技能。而每一次攻擊，一個隊伍中有幾十個角色的技能施放需要判定，如果采用瀑布算法，將產生多大的運算量。
思考與總結
對戰斗數值的研究，應該基於理論推導而歸於實踐應用。畢竟游戲數值設計不是做數學研究，其本質應是一種體驗設計。最后希望交流的是筆者個人對於這兩種算法的一些理解。
（1）不同的攻擊判定流程會向玩家傳達不同的戰斗感受
究其本質，不同的攻擊判定流程，影響着一場戰斗中的各種攻擊判定結果將以何種概率分布出現。
假設在一款游戲中，閃避率的投放上限是30%，暴擊率的投放上限是40%，命中率的投放上限是100%。瀑布算法下，出現閃避、暴擊和普通命中的概率是30%、28%和42%；圓桌算法下，則為30%、40%和30%。這兩種不同的概率分布，必然會帶給玩家不同的戰斗體驗，但在缺少其他條件的情況下，並不能判斷孰優孰劣。
使戰斗體驗匹配游戲的核心玩法，使屬性投放的極限值能滿足游戲的商業化需要，是設計攻擊判定流程時首先要考慮的。
注：甚至於部分競技游戲強調公平性，將暴擊做成了偽隨機。
使用瀑布算法，則不應該設計種類繁多的事件狀態
若是仿照魔獸世界的做法設計一連串的事件狀態（未命中、閃避、招架、格擋、暴擊、普通命中、偏斜、碾壓），非但運算繁雜，而且后置判定的屬性衰減幅度較大，效果極不明顯。這種隱晦的設計將不易傳達，同時還會影響玩家的游戲感受（某個判定流程靠后的屬性堆得很高結果卻沒用）。
使用圓桌算法，則應該嚴守屬性投放的上限，防止平衡崩壞的情況發生
需要澄清的是，並不是說使用瀑布算法就可以無限投放數值，而是說，相較於瀑布算法，圓桌算法的屬性投放上限會低很多（免傷概率的相加與相乘）
（2）不同的攻擊判定流程將影響有效生命EHP和有效攻擊EDPS的表達式
幾乎每個數值策划都會將角色的屬性轉化為EHP和EDPS以衡量其的戰斗能力，但曾見過不少人對所有的游戲都用統一的EHP、EDPS表達式進行分析模擬。這種偏差較大的模擬方式必然會影響體驗設計的精准性。在不同的攻擊判定流程之下，EHP與EDPS有着截然不同的表達式，舉例說明如下。
瀑布算法下：
若命中閃避分兩次判定：
EHP=HP/(1-免傷率)/(1-閃避率)/(1-招架率)
EDPS=DPS*命中率*[1+暴擊率*(暴擊傷害倍率-1)]
若命中閃避合並判定：
EHP=HP/(1-免傷率)/(命中率-閃避率)/(1-招架率)
EDPS=DPS*(1+暴擊率*(暴擊傷害倍率-1))
圓桌算法下：
EHP=HP/(1-免傷率)/(1-閃避率-招架率)
EDPS=DPS*[命中率-敵方閃避率-敵方招架率+暴擊率*(暴擊傷害倍率-1)]
注：閃避、招架>暴擊>普通命中，且各狀態發生概率之和未超過圓桌大小
混合算法下：
EHP=HP/(1-免傷率)/(1-閃避率-招架率)
EDPS=DPS*[命中率+暴擊率*(暴擊傷害倍率-1)]
可能有人會覺得：模擬得這么准又有什么卵用，數值平衡最后還不是靠調？誠然，在數值設計領域，確實有名言曰：數值平衡是調出來的。但在筆者看來，調節應該建立在正確的理論推導的基礎之上。依靠調節來掩蓋數值模型的錯誤設計，是本末倒置的行為。即便達到了所謂的平衡，也不過是扭曲的平衡，會為后續版本的迭代埋下隱患。
寫在最后
市面上的大多數游戲，都不會設計復雜繁多的攻擊事件，且基本采用瀑布算法。如此看來，攻擊判定流程的設計十分簡單。那么為什么要大費周章地將簡單問題復雜化呢？
愛因斯坦曾說過：Everythingmust be made as simple as possible, but not one bit simpler——凡事應該力求簡單，但不能過於簡單。從了解一種數值設計方法到理解如此設計的目的，從模仿成功游戲的數值設計到理解其設計的內在意義，這是每個數值策划成長的必經之路。
從全盤照搬一種數值體系到能夠融會貫通並根據實際情況靈活運用，這是一條並不好走的路。知其然，也應知其所以然——這是一個入行一年有余的新人的一點感悟。
免責申明：
1.筆者無法保證本文所用詞匯的普適性，能力所限，請多包涵~
2.不保證文中魔獸世界實例中的設定均與原作完全相符。但即便不相符，也不會影響圓桌理論的推演。