云风的 BLOG

和敌人等级相关很好理解，对手越强，吸收的越少。这样可以方便伤害公式的设计。

因为，一个人的物理抗击打能力和两个基础值有关，HP 的长度，和护甲伤害吸收率。（暂且不考虑回避率和特别技能伤害等的影响）

随着玩家等级的提高，基于成长性考虑，系统一定会让玩家的 HP 更长，护甲更厚。但是对应的伤害输出则只有一项数值。这样，要么以更快速度提升玩家的伤害输出能力，要么就要削弱面对高等级对手时的伤害减免能力了。

由于 wow 里各种人物之间有护甲差别（板甲、锁甲、皮甲等），为了平衡起见，不至于拉大高等级玩家见护甲差别优势，又保留护甲升级空间，暴雪选择了根据对手等级来削弱护甲能力的方式去做，这是最自然的选择。

至于 75% 吸收封顶，应该是受 D&D 规则影响。保留实力相差过大时，不至于让弱势方毫无还手之力的可能。（D&D 规则中，投出骰子 1 就一定 miss ，wow 同样也设定了这样的保底 miss 率）

重点来看看这个伤害吸收公式的框架，为何要采用一个倒数曲线来描述其变化呢？

我们来看常见的另一种涉及百分比变化的数值设定方法，那就是逐步累加百分率。很多游戏都有使用。（比如还是 wow 中，对致命一击率的设计）但是，对于宽泛的百分比变化，这样的设计是不太好做平衡的，因为价值很难直观凭估。

我们来看这个伤害吸收率，假定有一件装备可以增加 1% 的伤害吸收率。那么你如何评价其价值？跟许多玩家的数字直觉不同，在你的基础吸收率不同时，其价值可能截然不同。

举个极端的例子，假设对手的伤害是 100 点，而你原来毫无伤害吸收能力（护甲为 0%）。那么增加 1% 的伤害吸收率后，你就可以只承担 99 点的伤害。这种改善是微乎其微的。但是，如果你一开始有 98% 的伤害吸收率呢？那么再没有加这件护甲前，伤害是 2 点，一旦穿上后，吸收率增加到 99% ，就只会受到 1 点伤害了。护甲性能因此提高了足足 1 倍。

这就是 wow 把护甲值和伤害吸收率设计成倒数关系的缘故。

当玩家的 HP 固定长度，对手的伤害输出能力一定时，HP 的抗击打次数和对手单次伤害成正比。当对手的单次伤害被削弱一个百分比 d ，那么防御方的抗击打次数（或理解为存活时间）就提高了相同的百分比 d 。

经过公式换算过的护甲点数，1 次线性的描述了玩家抗击打能力的提升。这样，同样一件加 200 点护甲的装备，给任何人，任何职业，任何等级的人装备上，提升的防护能力就可以（在抵抗同一对手的攻击的时间长度这个意义上）保证一致。在此基础上，衡量护甲加成的点数的内在价值，就变得容易估算了。

OK 。如果要做护甲点数增加一定百分比，甚至翻倍这样的技能或职业设定怎样？wow 里的熊德就是这样的。如果这种技能多了，一定破坏平衡，理由正是上面分析过的。wow 这个护甲吸收伤害公式和数值增量的值密切相关，收益和增量成一次线性关系。百分比则会破坏这个平衡。

如果想做呢？比如有职业有技能是增加护甲点数百分比，天赋可以再增强这个百分比，饰品也可以对护甲点数以百分比增强？

好办，用幂函数曲线去拟合护甲点于吸收率的关系就好了，这就不展开讨论了。

这两天想写个战斗模拟器来调试战斗数值计算公式。本来想快速出个原型而不必等 client 细化后再做。想来想去，找不到特别快速的方法。考虑了一下做 web ajax 版的。前段时间玩过，感觉用以前写的代码改改也满好，做好了可以方便我们几个策划去试验。不过做起来还是满心烦。

C# 的版本倒是有同事弄了一个，觉得还是不太方便。另外有人说这几天想用 logo 做一个，我等着看效果吧。

这两天还有人在做 3d 粒子编辑器，也是想快速做出来。我提议说，界面的需求这么复杂，还是做个 web 接口的吧。3d engine 不必嵌入到过于复杂的软件应用中去。

其实我的意思是，写个超级简单的 httpd ，甚至不用支持完全。我们只需要听一个本地端口，只支持 GET 就好了。读入请求的第一行，看是 GET 开头的，就把 URL 那行文本读进来，当作控制指令分析就够了。足够满足基本的 ajax 应用。然后随便架个轻量成熟的 httpd 处理静态文件来描述控制界面。

我想顶多不超过 200 行 C 代码就可以搞定这个框架。

不过某人还是用 web service 做了一个 :) 看起来还是满 cool 。

今天折腾这些个东西到这么晚了，还在考虑要不要继续更新回忆录。但愿睡个好觉。