思维的惯性
晚上在办公室晃荡，对面的同事在加班写代码。我凑上去看看在写什么。我向他了解了后明白了，大约是服务器上角色 buff 的实现吧。
BUFF 这个术语是现在网络游戏中非常常见的。给角色加一个 BUFF 通常意味着对虚拟角色的一些数值上的临时修正：例如，攻击力 +5 ，防御 -10% ，速度加倍，等等。
玩过魔兽世界的朋友应该很容易理解这些。通常游戏里的 BUFF 设定比我上述的例子更加的复杂。
这里不谈游戏设定，谈谈实现。
同事在做的实现框架，给 BUFF 留了几个接口，其中有两个吸引了我的目光。
一个叫做 start 一个 stop 。分别用于 BUFF 产生的时候需要处理的逻辑，和一个用于 BUFF 消失时处理的逻辑。这是一个很自然的设计。尤其在 C++ 程序编写的习惯里，就相当于一个构造过程，一个析构过程。
比如，一个攻击 +5 的 BUFF ，可以在 start 事件处理里修正攻击值（+5），然后在 stop 里做一次逆运算（-5）。
我突然有一种直觉，感觉这个设计不是特别合理。因为它要求程序员去实现一对互逆的逻辑。这段时间我对需要编写事物处理的成对可逆处理的设计特别反感。所以立刻就意识到了实际问题所在。
首先，许多逻辑上成立的可逆运算都是事实上有漏洞的。比如某些特定条件下的浮点加减运算就有可能不可逆（暂时没有去构造一个例子，但是我认为是可以构造出来的）；定点数的乘除运算就很容易导致不可逆。
还有更严重的，如果一个 BUFF 会把某个值设置成固定值（比如清 0 或设为 max），那么不借助缓存变量，这个效果就完全不可逆。
当然有经验的数值策划，会把公式里的乘法规则提取出来，安排合理的次序去计算。比如大多数游戏中，乘法加成系数都是先累加再一次乘起来的。（btw, 早期刚接触 diablo 的时候，我完全不能理解：为啥两个加 20% 的装备装到一起是 40% 的效果而不是 44% :D 也有游戏设计的更复杂一些，例如 Eve 里，就有所谓的叠加惩罚。哦，好象又写跑题了。）
我问了一下同事，诸如一些特殊情况如何处理的问题：比如玩家顶着 BUFF 断线，重新上线的数值恢复问题。还有如果在 BUFF 有效期间，人物升级或更换装备导致基本数值变更，怎么保证 BUFF 消失时的逆运算正确性……
这些自然可以找到方法在现在的框架下正确的处理。但前提是实现的人考虑完备，或是多记录一些中间数据。当两件有关联的操作（BUFF 出现和消失）在不同的代码中实现时，BUG 就有可能滋生。
接下来我又询问了一下别的项目的同事，咨询了一下类似的设计他们是如何实现的。居然，大家都用的相同的手段。看来，思维还真是有惯性啊。
我后来想到的解决方案其实很简单。取消 start / stop 接口，改提供一个 apply 。角色永远记录两套数值，一套基础数值，一套产生实际效果的临时数值。
每次状态改变（增加新的 BUFF、改变基础数值，或是改变装备等），都激发所有存在的 BUFF 的 apply 方法在基础数值上全部重新计算一遍，得到新的临时数值。这样有可能会增加一些计算量，但是系统设计会更简洁一点。
Comments
C++程序员多这么写吧，PythonJs等程序员第一反应大多应该都是apply而不是构造析构
Posted by: 正逍遥0716 | (36) July 21, 2017 07:56 PM
赞同base+offset的方法。
以前写过一个光栅画正方体，使用旋转矩阵在上次旋转后的矩阵上进行计算。结果由于浮点误差，还没过5秒（60FPS）正方体就旋转成了一个像四棱名锥的东西。所以后来的计算中都考虑过误差累计。
Posted by: lichsword | (35) August 10, 2012 12:55 PM
这个用装饰者模式啊
Posted by: Anonymous | (34) February 7, 2012 05:23 PM
嗯，现在我们服务器的属性计算就是由 加法段，乘法段 这些组成，每次改变都重新计算一遍。
已经有了这个设计之后，接受起来很容易自然，但是如果自己从头设计，肯定又不是这么容易自然了。
Posted by: 涛 | (33) December 1, 2011 12:23 AM
有的BUFF是增加值，有的BUFF是增加%比，所以需要分别记录值和%比值才可以逆。
Posted by: wago | (32) August 16, 2011 12:50 PM
我后来想到的解决方案其实很简单。取消 start / stop 接口，改提供一个 apply 。角色永远记录两套数值，一套基础数值，一套产生实际效果的临时数值。
每次状态改变（增加新的 BUFF、改变基础数值，或是改变装备等），都激发所有存在的 BUFF 的 apply 方法在基础数值上全部重新计算一遍，得到新的临时数值。这样有可能会增加一些计算量，但是系统设计会更简洁一点。
————————————————
这不就 是传奇的 做法
想不到阿 居然在这还能 看见传奇的 技术
Posted by: 王清 | (31) December 7, 2009 08:52 AM
我做类似系统时也是完全照着dnd做的。
Posted by: w2moon | (30) September 29, 2009 06:29 PM
单用加减想不出Bug基本不可能...
Posted by: venjet | (29) April 22, 2009 02:41 PM
如果buff又有加减又有乘除
那么运算的操作先后也要考虑一下
(a+b)*c != a*c+b (当c!=1)
Posted by: anonymouse | (28) March 9, 2009 10:38 AM
偶认为BUFF的设计实现都不应该牵涉数值部分，数值上的加成或者减益不是BUFF设计所需要考虑的部分，一个BUFF系统设计所需要考虑的接口包括：add,cancel, addwithtime, etc..
而对于一个Role的数值部分应该独立出来，这部分我赞同云风的策略:base value + runtime value。并且每个会引起数值变化的BUFF的状态变化都应该触发整个数值的重新计算。
Posted by: Anonymouse | (27) March 11, 2008 11:41 AM
如果色子的面都一样的话，掷色子应该等到的是一个随机分布，而均匀分布应该属于随机分布的最佳状态，色子是有可能掷出均匀分布的
Posted by: kingx | (26) January 18, 2008 05:00 PM
start和stop的接口，和你说的apply是两回事吧。根据我的理解，其实你的核心思想是每次数值变化时，不要在当前数值上做运算，而是从基本数值按照固定公式重新算一次，这样即便有误差，也是同一种误差，不会由于计算次序不同而导致结果的不同。这又和start和stop接口有什么关系呢？那只是buff在添加和消失的时候的两个接口事件罢了，总是需要在这样的时刻做数值运算的，只是运算的方法不同罢了
Posted by: Holimion | (25) December 9, 2007 08:18 PM
那叫正态分布
Posted by: nothanks | (24) December 5, 2007 03:40 PM
Diablo是一个伪D&D系统，或者说是缩水版的D&D系统。例如一件武器的攻击力是150-210，事实上攻击力不是均匀分布在这个区间的，而是……那叫什么分布呢？忘记了。
直接解释吧，在D&D里面，一把武器的攻击力是掷两次20面色子的数目加上8，那就是10-48，但绝对不是平均分布，这很容易理解。在Diablo的背后，所有区间值都是用这种方式表示的，因此都是非均匀分布的。
Posted by: Cat Chen | (23) November 24, 2007 11:24 PM
这应该算作用查询替代临时变量的重构手法。
赞成这种做法，原来的做法绝对一大漏洞源，这在wow bug中占有很大比重，比如几个战场bug。
Posted by: Anonymous | (22) November 20, 2007 04:50 PM
浮点加减法，若造成了指数的改变，运算很可能就不可逆了。
CSAPP解释得很清楚。
Posted by: Ricepig | (21) November 20, 2007 04:16 PM
你这样做的话所有的状态技能的数值变化必须满足交换率，即个个状态技能产生的各种攻防变化不能够因为加BUFF的先后顺序改变 。从玩家角度讲操作降低 ，但是相对竞技性较强的游戏未必是好事。。。
Posted by: ljc | (20) November 20, 2007 02:07 PM
原来如此，云风考虑得更多。在设计上来减少实现时出现错误的可能性。而程序员在具体编写代码时出错的可能性会更小。而对于非计算机专业的人员，则更有益处。我则将看法局限在了更为狭小的范围内。
Posted by: rockcarry | (19) November 19, 2007 07:26 PM
接口的设计反应着设计者对问题的理解和实现思路。我们承认殊途同归，但归不归的了跟行者和铺路人都有关系。
这也是我们在项目中选择不同语言工具、选择不同的指导策略的目的。对于分工合作的多人项目尤其如此。
我们不能要求每个人做每件事情都考虑到每个细节（虽然这是每个设计人员应该对自己做的要求），那么就只能把自己做的这一块实现的足够 robust 。
浮点计算不是问题，我们尽可以用一些更 robust 的库：比如
http://gmplib.org/
性能上的问题就是另一个要考虑的了。
一个有经验的游戏设计人员可以很快的意识到大数乘法会导致溢出，或是经验值上溢变成负数。这是他们的经验给他们的直觉，并非完全理解计算机的运算法则。
但是即使一个程序员，也很容易忽略浮点加减的误差问题。这就是构造一个好的例子提示这一点的意义：一个看似游戏实际运行中可能发生的事情，却因为计算机的内在工作规则导致跟实际不相符的结果。
我们更不能强求非程序员对这些有足够的敏感。
对于程序员，计算机没有变数，任何结果都可以被预知；但对于非程序人员或是经验不足者，可能连“让计算机产生一个 1 到 10 万的随机数”这件简单的事情上都会犯错误，或是需要一个详尽的解释应该怎么去做。
ps. 这是一个有趣的例子，游戏设计人员设计了一个 10 万分之一的凋落率。任务程序员写下代码。 QA 抱怨着凋落率不对。这是谁的错？
作为程序实现上的设计人员，就应该多想想：应该怎样做，可以避免让其他给游戏添砖加瓦的人犯错误，让他们尽量少犯错误。
Posted by: Cloud![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (18)
November 19, 2007 07:11 PM
浮点数加减法精度损失的例子很容易构造，一个绝对值很大的数加减一个绝对值很小的数，必然会有精度损失。这个道理很容易理解，也很直观。
Posted by: rockcarry | (17) November 19, 2007 06:07 PM
我的意思是想说
云风使用浮点数运算的例子来证明这句话：
“许多逻辑上成立的可逆运算都是事实上有漏洞的”
似乎不妥。
Posted by: rockcarry | (16) November 19, 2007 05:55 PM
的确像楼下所说，计算机浮点数的运算在理论上就是存在精度损失的。
但是构造加减法的例子比构造乘除的例子不直观的多
Posted by: nothanks | (15) November 19, 2007 05:50 PM
由于计算机的特点，浮点数的运算在理论上就是存在精度损失的。看来云风最近真的很忙，没时间对自己的文章反复斟酌。
Posted by: rockcarry | (14) November 19, 2007 05:38 PM
接口从 start/stop 改为 apply，本质上并没有什么改变，因为在 apply 以后仍然需要一种手段来回到 apply 以前的状态。接口的设计当然有好坏之分，但是在这里，云风所提的，只是个人的习惯问题。
start/stop 的接口定义，在语义上并没有要求数值公式运算的含义，在实现上完全也可以按照云风所说的办法进行，而且也应当按照云风的实现方法去做，否则可能会出现数值运算精度所带来的问题。
Posted by: rockcarry | (13) November 19, 2007 05:27 PM
计算机的缺陷不是由于二进制造成的，而是在于计算机是离散系统，并且存在字长的限制。计算机系统的离散性，导致了计算机无法精确的描述和表示连续的数值，从而导致运算精度的问题。而计算机字长的限制，则导致了计算机数据类型的数值范围的限制。
Posted by: rockcarry | (12) November 19, 2007 05:02 PM
似乎这个问题的关键不是接口的定义，而是在于接口的实现。
Posted by: rockcarry | (11) November 19, 2007 04:52 PM
为什么不做成buff链,最终数值计算总是从链条顶端(基本数值)向链条末尾进行,buff失效脱链或者新增或者变化后总是从顶端重新计算一次.类似directshow的filter流.
Posted by: Anonymous | (10) November 18, 2007 01:21 PM
可以尝试使用 float 类型，把 0.1251 加上 1000 再减去 1000 ，
结果是 0.125122 。
如果肯多花一些时间，应该还可以构造出更为有趣的的例子。
===========
我实验过是0.125100的？
Posted by: longtrue | (9) November 17, 2007 01:25 PM
这些公式的可逆性本来就没办法保证，谁叫2进制有这样的缺陷呢。存两份信息倒是可以解决但是内存却白白用了两份:（ ...
Posted by: arden | (8) November 17, 2007 09:11 AM
感觉有点像大唐豪侠!我也玩大唐的,说实在的设计不完美!大唐如果开发完整了,我想是一款很好的游戏!只是情节有点...努力吧.加油
Posted by: aynrsx | (7) November 17, 2007 12:00 AM
可以尝试使用 float 类型，把 0.1251 加上 1000 再减去 1000 ，
结果是 0.125122 。
如果肯多花一些时间，应该还可以构造出更为有趣的的例子。
Posted by: Cloud![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (6)
November 16, 2007 01:45 PM
加减运算不可逆的最可能情况就是加法时溢出的情况了吧
不过浮点加减法运算，为什么要强调浮点呢？
Posted by: mikeshi | (5) November 16, 2007 11:30 AM
的确用加减实现非常不科学。
Posted by: nothanks | (4) November 16, 2007 10:24 AM
cs项目是跟buff无关
如果有数值变动,那么角色从头到尾把数值刷一遍就好拉.
Posted by: xuxing | (3) November 16, 2007 10:09 AM
"某些特定条件下的浮点加减运算就有可能不可逆",这个能举个例子么,一直以为加减运算是可逆的呢~~~
Posted by: Anonymous | (2) November 16, 2007 09:18 AM
不要忘了顺序哦。
另外，buff过期的时间也是需要考虑的。
Posted by: mgwtest![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (1)
November 16, 2007 03:13 AM