流量型攻击：攻击者采用udp报文攻击服务器的游戏端口，影响正常玩家的速度还是上面的例子，流量型攻击相当于坏人直接把面馆的门给堵了。
CC攻击：攻击者攻击服务器的认证页面，登陆页面，游戏论坛等，这是一类比较高级的攻击了。这种情况相当于，坏人霸占了收银台结账，找服务员去点菜，导致正常的客人无法享受到服务。
假人攻击：模拟游戏登陆和创建角色过程，造成服务器人满为患，影响正常玩家。
还有对玩家的DDoS攻击：针对对战类游戏，攻击对方玩家的网络使其游戏掉线或者速度慢和对网关DDoS攻击:攻击游戏服务器的网关，游戏运行缓慢。
最后是连接攻击：频繁的攻击服务器，发垃圾报文，造成服务器忙于解码垃圾数据。
以上就是锐速云总结出来的游戏的常见攻击类型
攻击类型
普通-Normal (大部分近战单位)
穿刺-Pierce (大部分远程攻击单位)
攻城-Siege (攻城单位)
混乱-Chaos (一些野外生物，强力召唤单位)
魔法-Magic (大部分的魔法单位和空中单位)
魔法攻击对虚无形态的单位附加66%额外伤害。
英雄-Hero
武器类型
普通-Normal
远程-Missile
火炮-Artillery
一般是攻城型单位的武器类型，特点是在杀死单位时有暴尸的效果。
直接-Instant
不同于一般的远程武器，它的.特点是速度快，一般远程武器从发出“子弹”到“子弹”打到敌方单位都有可见的飞行路线，如女巫的攻击而直接类型的武器是没有的，火枪手和蒸汽坦克都是很好的例子。
溅射-Splash
对攻击目标附近的单位造成一定的伤害，有全伤害范围、1/2伤害范围、1/4伤害范围的说明。
特殊武器类型
Mbounce:Missile+bounce远程反弹 女猎手特有的攻击方式，女猎手虽然是普通攻击，但是是远程的。
Msplash:Missile+splash 远程溅射 很多高等级远程单位的攻击方式。
Aline:Artillery+line 火炮直线 投刃车特有攻击方式。注意的是，这是投刃车研究好穿刺剑刃后的武器类型，在那之前，他只是火炮类型，只能攻击一个单位。直线攻击的特点是当攻击一个目标时，目标附近有攻击者的敌对单位，就对这个单位造成同等的伤害。有点类似于反弹，但是反弹对第二个目标的伤害是有减成的。
Mline:Missile+line 远程直线 狮鹫骑士特有攻击方式。注意的是，这是狮鹫骑士研究好风暴战锤后的武器类型，在那之前，他只是远程类型，只能攻击一个单位。
护甲类型
无甲-Unarmored (大部分魔法单位)
一些无甲单位是出于平衡性的设定，比如女猎手、石像鬼、角鹰兽、风暴之鸦形态下的猛禽德鲁伊。
轻甲-Light (大部分空中单位)
中甲-Medium (大部分远程攻击单位和农民)
重甲-Heavy (大部分近战单位)
英雄-Hero
城甲-Fort (建筑)
魔兽争霸III: 冰封王座: 攻防表
转自：http://www.gameres.com/677620.html
攻击判定流程几乎是所有包含战斗玩法的游戏都无法绕过的一块内容，常见的攻击判定流程有瀑布算法、圆桌算法以及混合算法三种。本文简述了这三种判定流程的特征，以实例对比分析了瀑布算法与圆桌算法各自的优点，以期为后续其他战斗数值设计内容的论述提供一定的基础。
攻击判定流程概述
自此开始正文内容的叙述——让我们直接代入一个实例：
在一款游戏中，攻击方有命中率和暴击率两个攻击属性，而防守方有闪避率、招架率和格挡率三个防御属性。于是相应的，一次攻击有可能产生6种判定结果：未命中、普通命中、闪避、招架、格挡和暴击。当采用不同的判定流程进行攻击结算时，6种判定结果出现的频率会截然不同。
1. 瀑布算法
顾名思义，在瀑布算法中，各事件的判定顺序如同瀑布一般自上而下。如果“水流”在某个位置被截断，则后面的流程都将不再继续进行。据我所知，瀑布算法是大多数游戏所采用的攻击判定算法。
上述实例若采用瀑布算法，则会以如下方式进行判定：
先判定攻方是否命中
再判定是否被守方闪避
再判定是否被守方招架
再判断是否被守方格挡
最后判定该次攻击是否为暴击
瀑布算法流程图
由此我们可以得出：
瀑布算法特征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%
瀑布算法的判定结果分布
由此我们可以得出：
l 瀑布算法特征3：各事件出现的概率符合经典的概率计算方法
l 瀑布算法特征4：掷骰轮次越偏后的属性衰减程度越大，但不会出现无效的属性
2.圆桌算法
将所有可能出现的事件集合抽象成一个圆桌桌面，便是圆桌算法这一称呼的由来。圆桌算法的实质，是将所有可能发生的事件状态按优先级依次放上桌面，直至所有事件被放完或桌面被填满。圆桌算法正是史诗级巨作魔兽世界中所采用的算法。据笔者了解，使用该算法的游戏并不多见，但即便仅魔兽世界这一款，已足以使这种算法成为永恒的经典~
上述实例若采用圆桌算法，则会用一次掷骰判定该次攻击的结果。
圆桌算法流程图
圆桌算法的操作步骤可以归纳为：
（1）攻方角色的命中率决定圆桌桌面的大小
（2）将各个事件状态按优先级依次放上桌面，直至所有的事件均放置完或桌面被填满
（3）若桌面还未填满，则用普通命中填满空桌面
将先前设定的数值代入，6种判定结果将会按如下的概率分布：
实际未命中概率=10%
实际闪避概率=20%
实际招架概率=15%
实际格挡概率=30%
实际暴击概率=25%
实际普通命中概率=90%-实际闪避概率-实际招架概率-实际格挡概率-实际暴击概率=90%-20%-15%-30%-25%=0%
注：在上述计算中，优先级按如下排序：闪避>招架>格挡>暴击>普通命中
圆桌算法的判定结果分布
可以看出，由于普通命中的优先级最低，所以它被完全挤出了桌面。这意味着，若攻守双方以此数值模型进行对决，则攻击方的攻击结果中将不存在普通命中。
由此我们可以得出：
圆桌算法特征1：一次掷骰即得出该次攻击的判定结果
圆桌算法特征2：事件有优先级，圆桌放满后优先级低的事件将被挤出桌面。这意味着那部分溢出的属性将不再生效
圆桌算法特征3：圆桌内的各事件出现概率不会衰减，只要优先级低的属性没有被挤出圆桌，各种事件的实际发生概率就与面板属性数值吻合
3. 混合算法
这是一种先判定攻方事件，再判定守方事件的判定流程。笔者曾在一篇帖子中看到过这样判定流程，不确定是否有实际的游戏应用，故仅在此做一些简单的理论分析。
混合算法在单方事件的判定中采用圆桌算法，即：
攻方判定结果：普通命中OR未命中OR暴击
守方判定结果：闪避OR招架OR格挡OR被命中
混合算法流程图
注：上面这个图仅作示意之用，从流程图的角度来看可能不太严谨
将先前设定的数值代入，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%
混合算法的判定结果分布
由此我们可以得出：
混合算法特征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.不保证文中魔兽世界实例中的设定均与原作完全相符。但即便不相符，也不会影响圆桌理论的推
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）