游戏数值公式的表象与本质
周末、睡的比较晚，起的也比较晚。总的来说比平常睡眠时间长一些，所以到了这周一的第一个小时，我还是全无睡意。随便写点什么，关于游戏的，关于游戏设计方面的东西。
鉴于我在游戏设计领域还没有什么建树，远不如游戏程序设计方面有发言权。甚至对游戏设计说三道四的话，还不如在软件开发上乱侃几句有分量。在下充其量也就是个没吃过猪肉天天能见着猪跑的家伙，如果有猪肉已经吃腻味的方家读到这里，请一笑了之，别跟我一般见识。
本来在本文成文前打的腹稿中想举出些实际的例子来，可是发现怎么都会或多或少的得罪圈子内的策划朋友。罢了，只说些空话好了，算我做了半个月游戏数值，闲暇时发的点牢骚。
从为我们的游戏设定角色基础属性，以及设计战斗伤害的计算公式开始。
计算机里的一切问题都是数学问题。
这句话可能不太确切，但是目前一切利用计算机解决的问题，都必须先表达成数学形式，我想没有太多人会有意见。计算机游戏本质上也是一段交给计算机运行的程序，必须先转化成数学形式。这个转换过程无论是交给游戏策划来做还是给程序员来做，都无可避免。
转换的过程必然有损于原始设计初衷；策划做的时候往往不太能掌握数学语言，有失准确；而程序员总是刻板的追求形式上的统一，而失去细节（神韵？）。大多数人都趋向于游戏的表象而忽略本质，这不单是某一个人或某一类人常犯的错误。
扯点时间久远点的例子。我们知道中国人比古希腊人更早发现了勾股定理，但是西方人依旧把直角三角形直角边的平方和等于斜边的平方称为毕达哥拉斯定理。
杨辉三角形为每个程序员所熟知（大部分编程入门教材上都会用这个做编程习题），但是数学上，我们用的更多的对应名词是牛顿二项式定理，虽然中国人早了至少 300 年发现它。
抛开民族自豪感这些东西，当我们仔细比较上面两个例子中前后两者对同一数学定理的见解，我们会发现，它们其实是表象和本质的差别。只有我们用演绎的方法证明理解数学定理时，才能看透本质，并做出推广。摆脱事物的表象，用符号工具单纯的研究他们之间的关系，正是我们许多人思维中缺失的能力。
在我很小的时候，读数学科普读物。曾经嘲笑过毕达哥拉斯因为不能理解无理数而杀死他的学生；也没觉得负数是一个了不起的发现，而欧洲的数学家到 16 世界还不承认它。
直到中学时，接触到复数的概念，才觉得数学的神奇。然后回过头来思考，为什么一个小的数字减一个大的数字的结果是负数？负数到底是什么？问这些个问题时，我才明白，绝对不能轻视古人。看清事物的数学本质是件多么不容易的事情。明白自己其实什么都不懂只是一个开始。
扯远了，还是谈游戏。
拿魔兽世界（后面全简写作 wow ）举例说事，恐怕是唯一不容易遭人非议的了。我们注意到， wow 之前有很多网络游戏，甚至暴雪之前也有一款很接近现代网游的游戏—— diablo 的 battle net 版，都采用了一种让玩家展现个性化角色的设计。那就是随着升级，为角色自由分配属性点，再由属性点影响角色的能力。
我可以举出长长的例子证明这一点，甚至电脑 RPG 的鼻祖，D&D ，也是有自由加点的设定的。虽然 D&D 里玩家可以加的点很少，暴雪在 diablo 里加强了这个设计。
为什么在这么多已有的网游中，大家都沿袭了这个设定，把它作为提供玩家个性化的必要手段时，暴雪绝然抛弃了它，把个性化转移到了天赋系统中。是为了创新吗？我不是暴雪的游戏设计师，我没有答案。但我们知道，暴雪从来不是一个以创新为名的游戏制作公司。而天赋树从外观上看，就是 diablo 中技能树的延续。
熟悉 wow 的玩家可能会说，是为了平衡。没错，但这是表象。我们需要进一步看清本质。
前段试玩了一个新出的网游，工作需要。可能是我已经厌倦了 wow ，对 wow like 的东西更提不起精神来。我试图说服自己，我觉得这个游戏比 wow 还无趣，是因为早先年打 wow 打累了。一丁点不如 wow 的地方都会被放大来看，甚至比 wow 做的好的，也会被忽略掉。
在公式化的游戏进程里，我玩到了游戏设计者“体贴”玩家的地方，比如升级飞快，轻松的接交任务等等。但是让我能理解，又觉得不可理喻的地方是，游戏依然保留着“传统”MMORPG 的设定，那就是每次升级都可以自由分配属性点。
亲身体验后，更加坚定了我的想法：自由分配属性点在大多数游戏中是一个极其鸡肋的设定。
或许是大部分游戏设计师认为，我们要提供给玩家一些自由度，而用户接受了自由加点这个设定，那么这就是一个廉价稳定的方案，我们也要提供它，没什么坏处，不是吗？
其实，大多数用户根本不知道他们真的需要什么，只是服务提供商对他们反复强化一些东西，这些东西反过来才成了必须品。在软件行业中，这样的例子比比皆是。“不要听用户的”是我去年听到的深合我意的一个声音。当然，千万不要曲解这句话。我从来没有否认过，用户调查，市场分析，等等这些对于游戏开发的重要性。
作为游戏设计人，我们到底想提供给用户多少自由度，怎样的自由度，这些都必须在设计时考虑在内。我们不是神，可以创造出简洁的自然法则构建出如此复杂的世界，任其发展。而且上百亿年了，其中的智能生物都无法完全了解这些规则。
说回属性点自由分配的设计，看似自由，比如一个小角色从1 级到满级可能得到上十点甚至上百点自由分配组合在 4 到 6 个不同的属性上。实际上，真正有用的组合方式寥寥无几。有天真的设计师，指望玩家可以摸索出超出自己想象的自由属性点组合方案吗？如果真的出现了，那么对游戏平衡一定是一个灾难。
如果你有信心对你没有预料到的东西做出合理的判断（不至于引起灾难），那么只有一种可能，那就是你做出了数值背后更深层次的规律的探索。可惜，大部分设计师没有这么做。
总结一下。如果你给了玩家一些自由度，让他们自由组合一些东西，达到个性化的目的，那么在设计阶段，作为设计师的你，就一定要全面列出所有的组合可能，并一一对其审视。
几十上百个的属性点自由分配的组合方案，从绝对数字上说实在是太大了。没有人会一一排到纸上演算。实际上也没有这个必要，因为大多数组合间是有规律的，不至于把量变堆积为质变。大量的组合方案在对玩家来说都是无意义的，没有人会那么组合，除非他犯错误，否则一定能找到一个达到他期望目的（PvP PvE 或者别的目的）的更优解。
从我信奉的 KISS 哲学上看，允许这么多理论上的属性点组合方案本身就是一个错误。如果我们希望玩家有 10 种个性化方案，就应该用最少的元素提供出 10 种这个数量级的变化规则。而不是提供上千种，让玩家从中选出 10 种。网络游戏中，提供自由度而存在的规则和设定不是为了考验玩家的智力（有时连智力都不需要，只需要机械性的忍受力）而存在的。
我相信很多人在接触一款新游戏时，都有过和我一样的迷茫：不知道升级后点该怎么加，只是无谓的犹豫不决，或是干脆一古脑把点全加在最需要的方面（比如物理攻击职业把点全堆在力量上）。
再来看看，大家沿袭最多的 MMO 系统，还是暴雪的——装备系统。很多玩家迷恋于装备上 +20 力量，+10 敏捷这些属性点加成。
我想大家在开发网游的时候，也自然而然的把这个系统做进产品里去了吧。
提一个问题：为了暴雪在做的时候，不把 +20 点力量直接写成 + XXX 点伤害力呢？这样玩家不就可以直接知道这个东西对他有什么好处了。
在 diablo 的年代，属性点意味着高级技能学习的先决条件；而 wow 中，同样的属性点，对于不同职业的实际效果反应是不一样的。比如敏捷可以增加盗贼的攻击力，而对战士则没有这样的效果。即使是同样依赖力量增加战斗力的职业，一点力量意味的伤害力的增强也是不同的。
所以，本质上，wow 中属性点到实际伤害计算公式中参量的变换，是为同一装备对不同职业的效能差异服务的。如果 wow 中，每个职业都用他们各自专有的装备，互不影响，那么，属性点的设计就是多余的。至少没有必要展现给玩家看，只让它作为设计战斗公式时的辅助工具就够了。
几年前，我曾经跟一个同事争论过一些游戏数值设定的方法。我坚持认为，一切都是数学公式，我们在设计时完全可以用 A B C D E 代替我们想要的东西，甚至一些公式也不用先定好具体函数是什么，而只需要根据最终的需要反过来推导。反正最终都是一些初等函数的变换，不可能跳出大框价。
但是很多设计师总期望先从现实中或是小说设定中找到对应物，非搞清楚为什么力量影响攻击力，根骨导致 HP 总量更长。那些名词到底是什么更为重要。以此可以展开更多的想象。
我说的名词还包括，“法师”、“战士”、“盗贼”、“牧师”这些……
最近我自己在做数值设定了，亲身感受后，果然合适的名词的确能辅助设计。没错，我们总需要借助一些更有意义的词来在头脑中建立起概念。但是，最终我也发现，一旦能克服对这些名词的依赖，纯数学的构建出基本的关系，无偏袒的，只为了数字上的平衡和变化去设计整体的框架。后期再根据需要找到合适的词并套入系统，以此展开细节上的联想，效果可能更好。更能帮助我们跳出玩过的前人的总总游戏的框架，找到新的东西。
不知不觉写了两个多小时，实在是太晚了。好象又什么都没写，等以后有闲了再补充一些实质性的东西吧。btw, 今天吃过晚饭后，在夜市上淘到一套对折的《说文解字注》。家里原有一本，是父亲的藏书。读中学时拿出来看，不小心弄丢了。这次撞见，挺高兴的买了下来。说是对折，但价钱还是今非昔比咯。
Comments
Posted by: 代码罐头 | (33) November 2, 2010 11:13 AM
Posted by: romeo | (32) October 14, 2010 12:33 PM
Posted by: Tone | (31) March 24, 2010 01:18 AM
Posted by: abc881858 | (30) March 5, 2010 12:30 PM
Posted by: seky | (29) January 24, 2010 02:09 PM
Posted by: houmingyuan | (28) October 9, 2009 09:22 PM
Posted by: xikema | (27) April 18, 2009 08:46 PM
Posted by: johnny | (26) March 4, 2009 11:07 AM
Posted by: 猫之魂 | (25) August 23, 2008 11:45 PM
Posted by: 慕 | (24) August 9, 2008 10:12 PM
Posted by: arnan | (23) May 6, 2008 04:22 PM
Posted by: JackH | (22) May 6, 2008 10:19 AM
Posted by: 大树 | (21) May 4, 2008 03:32 PM
Posted by: 羽扬 | (20) May 2, 2008 12:39 AM
Posted by: Cloud![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (19)
May 1, 2008 10:14 PM
Posted by: nothanks | (18) April 30, 2008 09:49 PM
Posted by: sjinny | (17) April 30, 2008 05:13 PM
Posted by: Cloud![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (16)
April 30, 2008 12:56 AM
Posted by: Rosemaria | (15) April 29, 2008 08:26 PM
Posted by: sjinny | (14) April 29, 2008 08:22 PM
Posted by: nothanks | (13) April 29, 2008 08:11 PM
Posted by: cat14991 | (12) April 29, 2008 03:37 PM
Posted by: ablmf | (11) April 28, 2008 09:55 PM
Posted by: shellex | (10) April 28, 2008 06:41 PM
Posted by: sbilly | (9) April 28, 2008 04:10 PM
Posted by: Zhe![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (8)
April 28, 2008 03:51 PM
Posted by: Maya | (7) April 28, 2008 12:31 PM
Posted by: 辰玉 | (6) April 28, 2008 11:34 AM
Posted by: ot512 | (5) April 28, 2008 10:43 AM
Posted by: feng jun | (4) April 28, 2008 08:40 AM
Posted by: wenziding | (3) April 28, 2008 07:59 AM
Posted by: Felix Wong![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (2)
April 28, 2008 04:50 AM
Posted by: pass86 | (1) April 28, 2008 02:53 AM