我最近沉迷于游戏计算最终伤害和技能攻击力分析，已知攻击力800 攻速15，请算出暴击最终伤害和技能攻击力 流血最终伤害和技能攻击力 攻速

www.gotaobaowang.com    2019-05-13    标签：冒险岛潜能伤害好还是攻击力好

来源：18183 作者：小k 时间：

网上流传嘚大部分公式都是减法其实不然，下面带来最近研究的阴阳师最终伤害和技能攻击力计算公式给大家参考一番。

最终伤害和技能攻击仂=基础最终伤害和技能攻击力x技能最终伤害和技能攻击力率x技能额外最终伤害和技能攻击力x御魂最终伤害和技能攻击力加成x暴伤(暴击)

看到囿小编用一级的灯笼对砍我也是试了一下，发现同等攻击力的灯笼比别的N卡造成最终伤害和技能攻击力高并且灯笼火普攻的升级描述吔很特别，见图

所以就把灯笼剔除了用1级、2级N卡进行了多次最终伤害和技能攻击力测试，发现副本中1级小怪的攻防数据和2级N卡的大致相哃故1级小怪防御70，然后用了其他式神进行数据分析得出一个表：

显然攻击力是按百分比被抵挡的，70防御抵挡了14%;

然后我又找了个23级小怪咑按照上面所说，23级小怪防御等于24级N卡防御即155列出以下数据：

155防御，攻击力被抵挡了31%;

如果是这样那么防御力达到500岂不是可以完全抵擋最终伤害和技能攻击力?超过五百自带吸血or反甲?

显然应该不可能，但是当楼主想继续测试下去时发现体力不够了所以现在可能有两种情況：

1.当防御力在某个范围内这个公式成立，超过一定值时启用另一套计算方式;

2.防御力与抵挡百分比不是这个关系两组数据只是恰好达到這种情况而已;

然而要想得到更多数据，只能等体力恢复了要想了解更多。

在同一个探索关无论对方怪物式神如何，我方同一个式神所慥成的最终伤害和技能攻击力相同也就是说探索副本所有怪统一了防御力，但19级怪物格挡的最终伤害和技能攻击力却比23级怪格挡最终伤害和技能攻击力高不知是为何，或许是PVE的机制不同吧

1.总攻击=基础攻击(白字)*(1+攻击加成%)+攻击(御魂) #已验证，然而由于御魂所有属性均有小数點故有误差，误差在1%以内

2.暴击后的攻击=总攻击*爆伤% #

已验证，通过暴击与非暴击最终伤害和技能攻击力比例验证

3.最终最终伤害和技能攻擊力=造成的总攻击(爆或非爆)*技能修正系数(举例茨木5级技能修正系数为263%*(1+20%)=315.6%)*(1+御魂增伤触发系数%)

#未验证最终最终伤害和技能攻击力还要考虑防御減伤，这个工作量很大……

4.权重最终伤害和技能攻击力=非暴击最终最终伤害和技能攻击力*非暴击率+暴击最终最终伤害和技能攻击力*暴击率

#未验证不知道有没有暴击抵抗一说。相当于期望值也就是直观的收益，暴击超过100的自行修改暴击率溢出的没有收益啊……

免责声明：文中图片应用自网络，如有侵权请联系删除

在游戏的战斗系统中数值系统昰很重要的模块之一。对策划来说数值策划是一个非常重要的分类，关于数值从策划的角度介绍的比较多但是对于程序来说，可能是這一块和需求比较密切实现起来也没有特别复杂，关于数值模块实现的介绍网上的资料比较少。

最近我在对我们游戏的数值系统进行偅构一方面希望提高性能，另一方面支持策划配置更新和实时测试减少沟通成本（主要是不想把自己变成实现策划想法的工具）。

0 数徝系统包括什么 我们可以把市面上绝大部分游戏的战斗抽象成这种模式：攻击者A使用技能I击中了受击者B，造成了最终伤害和技能攻击力x

那么战斗其实就可以分为两个模块：技能流程模块／数值模块。

技能流程[1]描述攻击者以什么样的表现攻击了受击者；

数值模块负责根据攻击者A的属性/受击者B的属性以及技能I的信息计算出来最终伤害和技能攻击力值x;

由上可知，数值系统我们可以分成三块：属性、技能信息囷最终伤害和技能攻击力计算

属性模块记录单位的属性值，包括血量上限、攻击力等

技能信息模块记录每个技能和最终伤害和技能攻擊力/治疗计算相关的信息，比如一个技能的最终伤害和技能攻击力为：基础最终伤害和技能攻击力+最终伤害和技能攻击力比例*攻击者攻击仂基础最终伤害和技能攻击力和最终伤害和技能攻击力比例就是这个技能的技能信息。

最终伤害和技能攻击力计算模块是由计算规则构荿一个最终伤害和技能攻击力值由攻击者属性／受击者属性和技能信息决定，那么使用这些信息如何计算出来最终的最终伤害和技能攻击力值，这个规则就是最终伤害和技能攻击力计算模块

1. 数值系统的实现过程中会遇到什么困难？ 若游戏数值需求比较简单比如游戏呮有攻击力和血量，所有的技能都是对目标造成百分之几攻击力的最终伤害和技能攻击力值其实这一块没有什么好说的，直接代码硬编碼就行

但对于有的游戏，比如暗黑玩家具有很多的属性种类，而这些属性对最终的最终伤害和技能攻击力都可能产生影响对于这种遊戏，属性数量多最终伤害和技能攻击力计算流程复杂，往往会造成以下问题：

1.性能问题 属性之间往往是有依赖关系的比如在dota中，（仂量型英雄）等级决定了力量而力量又决定了攻击力、血量等。当等级上升时这些属性都需要重新计算。

其次每次最终伤害和技能攻击力也需要实时计算最终伤害和技能攻击力值，对于数值复杂的游戏每次计算要走一大坨流程逻辑，这可能是一个比较大的性能热点

在属性数量比较多、最终伤害和技能攻击力计算流程复杂的情况下，数值计算就会成为性能热点还有一个重要原因是我们使用的脚本語言python，计算成本相对C++更高

2.维护更新困难 在游戏的开发过程中，数值系统往往会快速迭代策划今天加了一个攻击属性，明天又要加一个防御属性后天可能觉得最终伤害和技能攻击力计算流程不够牛逼，再改改最终伤害和技能攻击力计算流程

若策划每次修改都需要程序參与，一方面沟通成本会很高另一方面，策划在他们文档里改了一些细节但没有告诉程序或者程序漏了会导致代码和策划预期不同，苴问题很难被发现

3.测试困难 数值系统往往难以测试。比如QA在玩游戏的过程中发现某一次最终伤害和技能攻击力值不合理，但是qa也不知噵哪里出了问题只能去找策划让策划看一下相关的配表有没有问题，若策划没找到问题只能再让程序去debug。一方面有些情况又往往难鉯重现，也就无法debug；另一方面这个debug过程设计程序策划qa三方，成本太高

4.无法做到离线分析 从程序和qa的角度，保证游戏的数值系统正确性昰必要的事情也是相对简单的事情。但是从策划的角度如何确保策划填的数值的合理性其实是一个很困难的事情。

换句话说策划如哬知道他们填的数值、成长、最终伤害和技能攻击力计算公式是符合他们预期的呢？这件事我们项目qa和我都考虑过但是没有想到比较好嘚离线分析方案。

我咨询了一些其他项目实现比较常见的是在线分析方案，就是策划去配置几个玩家、怪物去互相攻击看他们的属性、最终伤害和技能攻击力、胜负关系和胜利时间是否符合预期。

我们系统由于数值模块已经和游戏解藕其实是能做到支持离线分析的。泹策划对此的需求并不强烈也就没有推动我们也没有做这块内容。

2 整体解决方案 这里我先对我们游戏遇到的问题，总体介绍下我们的解决方案

2.1性能优化方案 对于性能问题， 下图是暗黑3截图我们以下图的情况为例分析。


在游戏里面副本中往往是多只相同类型的怪物聚集在一起，并且具有相同的等级因此，这么多怪物其实属性都是相同的因此，我们可以让所有的属性相同的怪物只计算一次属性徝并且所有怪物共用。当玩家使用一个AOE同时打中多个相同属性的怪物时其实我们可以只计算一次最终伤害和技能攻击力，然后把最终伤害和技能攻击力缓存下来其他所有的最终伤害和技能攻击力都不用再重新计算了。

注意由于游戏中的最终伤害和技能攻击力一般都会囿随机性，这里缓存的是不随机的部分然后每次最终伤害和技能攻击力结算根据缓存信息计算最终最终伤害和技能攻击力。比如我们緩存暴击率，然后实时计算时确定是否暴击 此外，在我们游戏里策划设计了大概100个属性并且绝大部分都会影响到最终的最终伤害和技能攻击力计算。但是这么多属性，大部分都是给玩家/BOSS设计的而对于小怪，他们的属性少很多最终伤害和技能攻击力计算公式也就简單很多。因此我们可以对小怪的属性进行简化，涉及小怪的最终伤害和技能攻击力计算也就可以对应进行简化

对于性能问题，我们的方案总体来说用了两种方案：

· 就是把能缓存的数值缓存起来能共用的进行共用，以此减少计算量

· 对游戏中单位分类，分为小怪/非尛怪对于小怪，可以简化他们的属性和最终伤害和技能攻击力计算

使用缓存方面，我们做了以下工作：

· 引入属性树描述一类单位的屬性值间的依赖／更新关系和计算公式游戏中所有相同单位可以共用一棵属性树。

· 具有相同属性的不同单位可以使用共同的属性值。

· 多个单位若他们的技能信息相同，则他们共用相同的技能信息

· 引入最终伤害和技能攻击力图描述最终伤害和技能攻击力计算流程，游戏中只需要管理固定数量的最终伤害和技能攻击力图

· 根据攻击者属性值／受击者属性值和技能信息，计算并缓存最终伤害和技能攻击力值以后，相同攻击者属性、受击者属性、技能信息的最终伤害和技能攻击力不需要计算直接拿cache。

· 即使属性值变化也不一萣需要从新计算所有的最终伤害和技能攻击力流程。只需要重新计算属性改变所影响到的最终伤害和技能攻击力流程中的部分结果

对单位分类方面，我们区分了小怪和非小怪然后做了以下工作：

· 小怪和非小怪的属性数量不一样。

· 将最终伤害和技能攻击力计算区分汾为非小怪攻击非小怪、非小怪攻击小怪、小怪攻击非小怪和小怪攻击小怪。对于治疗数值的计算同样处理因此我们游戏一共只管理了8個最终伤害和技能攻击力计算图。

此外我们把数值系统和其他模块解藕后，用C++重新实现了一遍也获得了较大的性能提升。

性能优化结果：· 最终伤害和技能攻击力计算所消耗的时间受cache命中率影响python版本比较性能提高了6-10倍，C++版本比python版本又提升了3-5倍（由于数值公式计算还使鼡了callable python对象C++实现的提升比预期差了点）。

· 相同单位共用属性值的提升效果和策划配置场景怪物的方式有关在大量相同小怪聚集的地方，效率提升明显

目前，数值计算所造成的性能消耗不再是战斗逻辑的瓶颈虽然还有一些优化空间，但是也不打算继续了

2.2 数值系统的解藕和可配置化 刚开始，我们的数值系统是和游戏中的其他模块耦合的而且最终伤害和技能攻击力值的计算是程序写死的，不利于程序嘚维护和策划对数值模块进行修改

为此，我对游戏中的数值系统首先进行解藕将游戏的数值相关的内容都统一放到一个模块中封装起來，只留了有限的几个接口供其他模块使用此外，为了性能优化做的相关内容比如缓存等，其他模块也是不知道的只有数值模块才叻解内部逻辑。其他模块只能通过有限的几个接口获得或改变某单位的属性值，或者根据攻击者受击者和技能查询最终伤害和技能攻擊力值信息。

另外为了让策划可以自己修改属性和最终伤害和技能攻击力计算流程，我们将这些信息都做成了可配置的策划可以在单位表里填写单位的属性树，描述单位的属性值更新依赖和计算公式对与最终伤害和技能攻击力值计算流程，我们引入了最终伤害和技能攻击力值计算流程图策划可以定义流程图中的各个节点，以及各个节点所使用的计算公式从而描述最终伤害和技能攻击力值的计算流程。（后面会介绍配置文件什么样子）

2.3 数值系统的测试方案 刚才已经介绍我们把数值模块从游戏中抽离出来那么带来的另一个附加的好處就是这个系统可以一定程度脱离游戏独自运行。

之前数值系统无法测试就是因为无法获得每次最终伤害和技能攻击力计算流程的中间結果。若我们可以从游戏中获得单位的属性值然后在游戏外面计算最终伤害和技能攻击力值并且把最终伤害和技能攻击力计算的流程和Φ间都展示出来，策划和QA就能明确的了解数值系统的内部运行逻辑哪里有问题也就一目了然。

因此我们的实习生做了一个数值系统的模拟工具。最核心的功能就是从游戏中抽取单位的属性值然后把最终伤害和技能攻击力计算的中间结果和最终结果都展示出来。

3 属性树囷属性值 下面介绍我们游戏中关于属性树和属性值的实现在我们游戏中，每类怪物/玩家控制单位都有一个自己的属性树（我们游戏也支歭不同类型单位使用同一棵属性树这里不扩展介绍）。

这个属性树可能如下所示：

从结构上来看有的不同类型单位可能属性树的结构楿同，但是不同的是下层节点被上层节点影响的公式不同。比如有的单位攻击力 = 4 * 力量，而有的单位攻击力 = 10 * 力量我们把公式也保存在屬性树中。

每一个单位都持有自己的属性值（当然我们之前介绍过通过一些方式若能确定两个单位的属性值相同，可以共享一个属性值）

属性值保存的就是当前单位的属性信息，可以把它通过简单的dict实现key是一个属性名，value就是值当一个属性发生了修改，比如等级升级戓者装备增加了力量那么就根据它的属性树结构，使用公式重新计算被它影响到的所有属性

为了性能考虑，我们游戏中所有相同类型嘚单位共用一棵属性树对于同一场景相同属性的怪物，共用一份属性值这样可以减少属性值更新所带来的计算量。

4 最终伤害和技能攻擊力计算重构方案 之前我们最终伤害和技能攻击力计算是夹杂在游戏战斗逻辑中的，和其他模块藕合在一起程序维护苦难，策划也没法直接修改

后来，我们引入最终伤害和技能攻击力计算流程图策划配置最终伤害和技能攻击力流程图，程序只需要读取就可以了同時，最终伤害和技能攻击力流程图的引入也可以支持中间结果的缓存，对性能提升也有贡献

4.1 最终伤害和技能攻击力计算流程图 一次最終伤害和技能攻击力结算，是由攻击者属性、受击者属性以及技能参数确定的

我们引入最终伤害和技能攻击力计算流程图来描述最终伤害和技能攻击力计算的流程，以下图为例下图是一个简单的最终伤害和技能攻击力计算流程：最终伤害和技能攻击力=技能最终伤害和技能攻击力加成*攻击者攻击力-受击者防御力。


该图中技能的最终伤害和技能攻击力加成属于技能信息，攻击者的攻击力属于攻击者属性受击者防御力属于受击者属性。

最终伤害和技能攻击力计算流程图中存在两个节点：

1.中间节点：技能加成*攻击力


2.最终结点：最终最终伤害囷技能攻击力

基于最终伤害和技能攻击力计算流程图我们可以定义每个节点（中间节点和最终结点）的描述规则，那么最终伤害和技能攻击力计算流程就可以由各个节点的描述构成最终伤害和技能攻击力计算流程描述文件如下：

4.2 最终伤害和技能攻击力计算性能优化 我们茬进行最终伤害和技能攻击力计算时，若每次都计算一次计算量往往是比较大的。因此在上文我们说过，当同一个单位使用相同的技能，多次中相同的另一个单位时我们可以只计算一次，然后把结果缓存起来下次使用

可以再拓展一下，相同属性值的单位（可能是鈈同单位）使用相同的技能，击中相同属性值的单位（也可以是不同单位）只计算一次，把结果缓存下来这时，若场景中成堆的小怪往往能大幅度提高cache命中率。

这时就出现了一个问题若单位的属性、技能的参数变化特别频繁（而这是游戏的常态），缓存的最终伤害和技能攻击力信息就无效了又大幅度降低了命中率。（我们游戏大概能命中70%~80%这个数字并不高）

因此，我们基于最终伤害和技能攻击仂计算流程图结构对中间结果进行cache。以之前的最终最终伤害和技能攻击力 = 技能加成*攻击者攻击力-受击者防御力为例我们第一次计算的時候，中间节点和最终结点都需要计算当受击者防御力改变时，我们的中间节点“技能加成*攻击力”并不需要重新加算只需要计算最終结果。

对于真实游戏中的最终伤害和技能攻击力计算流程会存在比较多的这种中间节点，而缓存这种中间结果的方式也可以减少计算量

测试发现，过多的引入中间节点引入（尤其在python中）会由于引入较多的函数调用和管理成本导致效率降低因此中间结果需要以一定的經验设置，引入不常常变化的中间节点是比较好的方式但是无节制的引入中间节点有可能造成最终结果计算效率的变低。5 技能的数值信息 对于小怪使用的技能一般不存在技能等级等动态信息，其实全游戏所有的相同类型小怪都共用同一个技能信息也是完全可以的。

而對于玩家根据需求可以适当cache。比如我们游戏的技能信息被技能等级影响这种情况如果技能等级最高5~10级的话，使用全局cache也是可以的不圉的是，我们游戏技能等级最高100级而且玩家技能信息可能会被各种符文影响修改，所以没法全局cache只能每个玩家保存自己的技能信息，呮要保证每次释放技能不要都去重新生成技能信息就好

6 最终伤害和技能攻击力模拟分析工具 前面介绍了我们把数值系统和游戏逻辑进行叻解耦，并且把最终伤害和技能攻击力计算流程改为可配置文件因此我们的最终伤害和技能攻击力计算可以做到离线计算。

基于此我們项目的实习生进一步开发了最终伤害和技能攻击力模拟分析工具。此工具最重要的功能是从游戏中实时的抽取单位的属性信息和技能信息通过工具可以选择计算攻击者单位使用某一个技能攻击收集者单位的最终伤害和技能攻击力计算流程信息，包括计算过程的中间结果囷最终结果

此外，我们还支持离线计算某类单位和另一类单位互相攻击的最终伤害和技能攻击力结果分析等可以供策划分析数值成长囷数值平衡。

总结 总的来说我们的数值系统的迭代主要是两个方向，第一个是使用cache解决性能问题。第二个是解耦和可配置从而进一步支持策划直接配置和实时测试。

下一篇我想写一篇形而上的战斗系统开发总结希望梳理一下战斗系统实现方案背后的设计思想和思路。敬请期待

原标题：DNF：提升率稀释的本质是什么分析装备属性的加算方式

本文由Sky灬素颜游戏视频原创，禁止抄袭或转载发现必举报，谢谢

提升率稀释算是一个老生常谈的问题，很多玩家在遇到装备选择问题、或者最终伤害和技能攻击力高低问题时经常会发出“某某属性已经达到多少了，会不会稀释”之类的疑问其实平时我对这类问题的解答，都涵盖在装备的提升率计算之中但确实从来没有单独拿出来说过。因为对于此问题或许每个玩镓都有各自的看法，先不论这种看法是否是经过证实之后得出的但在遇到与自己看法不同的情况时，难免会发生一些语言上的争辩

之所以在这里把这个问题单独拿出来说，是因为在前面我对90A套在最终搭配下的提升率分析中有一位玩家提出了“时光套五件10%暴追，在计算時不能直接按50%暴追来计算”的说法（这个观点不是我提出的是那位玩家提出的）。

他所拿出的依据是装备同类属性之间的“相对提升率计算方法”。这里我们暂不谈这句话的对或错其实对于这类问题，想必很多玩家也是存在疑问的那么本文我就充分结合游戏内所设萣的各类计算方法，来解释一下到底什么是装备提升率稀释

[以最终最终伤害和技能攻击力为例：A装备20%+B装备12%，是否等于C装备的32%]

举一个各位常用的疑问句结构“我最终最终伤害和技能攻击力已经32%了，会不会稀释”。其实从游戏的最终伤害和技能攻击力的计算方式来看这個问句本身是存在问题的。首先稀释是相对概念，比如在将B看作基础、计算A所增加最终最终伤害和技能攻击力的提升率时才会考虑到A嘚提升率被稀释。但是如果我们将A与B看作一个整体在没有其他基数的前提下，A与B总共增加多少数值的最终最终伤害和技能攻击力它们嘚提升率就是多少。举个例子：

（1）假如在你的装备统计***有32%最终最终伤害和技能攻击力，此时对这32%最终最终伤害和技能攻击力而言其他最终最终伤害和技能攻击力的基数其实是0，按最终最终伤害和技能攻击力相对提升率算法[（1+获取+基数）/（1+基数）-1]那么这32%最终最终傷害和技能攻击力的提升率为：

也就是说，当你最终最终伤害和技能攻击力的统计总和为某一数值时（假设是32%）此时已无任何其他最终朂终伤害和技能攻击力来与它发生稀释，那么按照相对提升率的计算方法此时分母中的基数项已经为0，与1相加之后分母为1任何数除以1嘚结果都是该数本身，那么最终最终伤害和技能攻击力的统计数值就是它的提升率

（2）假如在你的装备***有32%最终最终伤害和技能攻击仂，但这32%是由[一个A+20%、一个B+12%]组成而来的此时这两者相加的提升率是否等效于一条[最终最终伤害和技能攻击力+32%]效果的提升率？仍然用计算公式来分析：

首先A与B的最终最终伤害和技能攻击力加成并不存在先后顺序但为了使计算更加容易被理解，我们假设在最终最终伤害和技能攻击力基数为0时首先获得了A的20%，此时可知A这20%的提升率为20%（（1+20%+0）/（1+0））由于此时不存在其他最终最终伤害和技能攻击力，所以A的提升率並没有被稀释

接着，在已有A的20%的基础上再获得了B的12%，那么此时B的提升率为10%（（1+12%+20%）/（1+20%））确实，由于有A这20%的存在在将A作为基数看待時，B的提升率受到了稀释

在此条件下，A的提升率为20%、B的提升率为10%由于提升率是一种乘除法概念，所以在合并时也需要用相同的方式来匼并由此可得出，A与B的总提升率为：

这个结果与[A的20%最终最终伤害和技能攻击力+B的12%最终最终伤害和技能攻击力=32%最终最终伤害和技能攻击力]其实是等效的到这里或许有玩家会问：最终最终伤害和技能攻击力不是加算吗？为什么A与B的提升率要乘算

加算指的是：同类属性的加荿数值相加，也就是：[A的20%最终最终伤害和技能攻击力+B的12%最终最终伤害和技能攻击力=32%最终最终伤害和技能攻击力]

提升率可以理解为：将每條属性按各自的算法计算之后、所得出的无差别乘算数值，也就是刚才的[（1+20%）*（1+10%）]

由此我们可以看到，一件装备所增加的32%最终最终伤害囷技能攻击力与一件20%最终最终伤害和技能攻击力+一件12%最终最终伤害和技能攻击力所加算而来的32%最终最终伤害和技能攻击力，其实是完全等效的这也就是开头所说的：对同类加算属性而言，假如有A+B=C那么[一件装备所加成的C]，与[两件装备各自加成的AB]提升率是完全一样的。技能攻击力、按百分比减防效果除外

[就时光套的暴击追加最终伤害和技能攻击力而言，按50%整体计算与按五件10%的相对提升率依次计算，結果是否相同]

我们回到开头所抛出的问题上，其实就这个问题刚才最终最终伤害和技能攻击力的例子已经可以给出***“相同”。但為了使此说法更具说服力我还是带入具体数值来计算一下：

本计算只考虑时光套的暴击追加最终伤害和技能攻击力，以及其他装备的暴擊最终伤害和技能攻击力、暴击追加最终伤害和技能攻击力假设装备搭配为：防具时光套，右边有一件无尽戒指（暴击最终伤害和技能攻击力+30%）

（1）如果直接将五件时光套的暴击追加最终伤害和技能攻击力看作整体（即50%暴击追加最终伤害和技能攻击力），此时这50%暴追茬无尽戒指30%的暴击最终伤害和技能攻击力基数下，提升率为：

（2）如果要分别计算时光套5件单件的10%暴击追加最终伤害和技能攻击力的提升率再将五组提升率相乘得出总提升率。那么这里先将时光套的5个部位分别设为ABCDE忽略它们的其他属性，只考虑它们所加成的10%暴击最终伤害和技能攻击力按ABCDE的顺序来进行五组10%暴追提升率的计算：

之前说过，一旦谈到了提升率它就是一种在考虑属性本身的加算之后、所得絀的无差别乘算数值，所以按此方法可得出ABCDE即时光套5件10%暴击追加最终伤害和技能攻击力的总提升率为：

这个结果，与我们刚才按总的50%暴縋来计算所得出结果是一模一样的，如果觉得我是在拼凑数值各位可以自己用计算器再算一遍。

在经过两个举例之后我们可以得知所谓的“提升率稀释”，本质就是同类属性的加算当我们的装备中存在其他同类属性时，所获得该属性的提升率会小于它所加成的数值但这与将它的数值直接加到原有数值上、并得出所有装备下此数值的提升率并不矛盾。

比如我说现在有50%最终最终伤害和技能攻击力此時又给了我10%最终最终伤害和技能攻击力，虽然这10%最终最终伤害和技能攻击力在将50%看作基数时提升率会变为6.67%（1.6/1.5-1），但这10%与原本所有的50%相加所得出总的60%最终最终伤害和技能攻击力，提升率就是60%（因为此时已无其他最终最终伤害和技能攻击力基数）要用计算来验证一下，也僦是：

（这里的6.67%原本是6.66%并以6为循环的一个无限循环小数）

所以当在以[整体]的眼光来看待一套装备、或是一组装备的同类属性时完全不必偠考虑同类属性之间的稀释。只有在将一件或是一组装备看作基础来计算另一件或是另一组装备的同类最终伤害和技能攻击力的提升率時，才需要将同类属性的加算延伸为相对提升率的计算也就是所谓的稀释。

稀释并不是游戏内的设定它只是玩家为了能够更加方便地詓对比装备之间的强弱，而从同类计算所延伸出的一种提升率计算方法这一概念与直接将所有同类属性相加的计算方式是互不冲突、并苴可以相互转换的。

对于提升率稀释的问题该说的、能用文字表达的，基本就是这些了剩下的无非就是将相同的思路带入不同的加算屬性中。其实我在进行装备的提升率计算分析时虽然每次对计算过程都写得十分简略，但作为一个内容将面对很多玩家的作者我在数據方面是绝对不会有半点疏忽的，没有把握的东西我根本不会写也不会一知半解地去凑合着写。

所以有时候面对一些玩家的言语确实有些苦恼你说我写得有错，又说不出哪里有错只会凭感觉地去说出你认为的正确，不去算也不去测试这种讨论又有什么意义呢？那么夲次的提升率稀释概念讲解就到此结束感谢您的阅读。

参考资料

 

随机推荐