游戏中的数值设计
游戏中的数值设计，主要是三点：
- 归纳、抽象设计目的。
- 用数学表达设计目的。
- 优化及调整数值表现。
数学知识只要知道等差、等比、常用公式的函数图、概率论，就满足需求了。
一 归纳、抽象设计目的
很多时候，设计目的不是自己的看法，而是许多人的意见汇总（也有可能主要来源于老板、超级人民币战士等）。这些意见：
- 可能是零散的（不成系统）；
- 可能对立（不同人提出的意见之间的冲突）；
- 可能矛盾（可能一个意见自身就是有冲突的）；
- 可能是感性的（如仅仅是提出了某种心情描述）；
- 可能是模糊的（提出者自己都无法描述自己想要什么）；
- 可能是错误的（提出者因为一些原因，描述出错，甚至是沟通有误差）；
- 可能是指向性的（仅仅提供方向），等等。
将这些意见融合，加上完善的思考，形成完整的体系是最重要的。很多时候，数值被同事质疑，往往是这一步没做到位，而不是数学不行。
如何归纳设计目的
1 罗列意见，并标注设计目的
很多时候意见矛盾的背后，有相同的设计目的。
2 归纳意见列表
- 将相同的意见合并。
- 将复杂的意见拆分（标准如：主语只能有一个，动词只能有一个）。
- 将相近的意见区分。
- 将矛盾的意见根据设计目的进行进一步分析是否真的矛盾。
- 将上面内容整理，逐条考虑设计目的合理性。
- 在合理性之后，考虑每条是否都有优化空间。
- 将矛盾的意见根据设计目的的优先级进行筛选。
- 将列表向意见提出人进行征询确认。
3 用自然语言抽象意见列表
如：
一些战斗表现的意见可能可以抽象成：
随着攻击方攻击的线性增长，防御方受到的伤害线性增加；
随着防御方防御的线性增长，防御方受到的伤害线性减少。
类似这样描述，后面公式就可以写成 攻击方.攻击 - 防御方.防御 = 伤害
抽象是为了理清公式设计的目的和步骤，如同代码的伪代码步骤。对于新手，这步帮助会比较大。
4 检查复杂度
这里要先插入一段关于复杂度的说明。当一个系统的设计目的意见列表形成后，就好像生活中一件事情可以有很多做法、次序一样，抽象的方法也有很多种。
原则上来说，单纯最简的方法是不存在的。设计目的既定，那么必然有那么多约束需要进行（一个目的要实现，至少需要一个甚至多个规则去约束它）。这些约束可能分布在多个模块当中，比如：
战斗的设计目的：随着角色的成长，战斗的回合数保持不变。
那么做法可能有：
1. 成长线性，伤害用减法 A - B = C
2. 成长线性，伤害用乘法 A * A / ( A + B ) = C (这个公式 A / (A + B)的意思是让B按比例去削弱A)
做法2的乍看上去，复杂度比较高。
但实际上做法1有几个问题：
1. B大于A后，C小于0，伤害小于0自然是没办法接受的。所以公式需要加一层逻辑判断。
2. 需要在角色成长模块约束B成长和基值的结果要小于A。 所以复杂度实际上移动一部分到角色成长模块当中。
也就是说，从MMO角度来说，做法2的复杂度远大于做法1。
所以当做公式之前，抽象意见列表时，需要着重考虑复杂度。
二 用数学表达设计目的
下面3个是按次序执行的。一般情况下不应作省略。
1 用数学图形表述模块
比如一个满级的角色，他的总数值当中，有多少比例是装备带来的，多少比例是自身成长带来的，多少比例是预留给状态的。
饼状图可以较好的表述模块的设计目的。
2 用数学曲线表述成长
记忆一般公式的曲线，比如： y = a + level * k 是一条直线。
在实际需要的时候，一般套用类似的公式原型，并修改参数即可。
3 用数学公式表达
如何抽象公式很难有个最优的做法，需要根据设计目的去实际操作。
但设计完数学公式后，记得检查各种极端情况。
三 优化及调整数值表现
测！测！！测！！！大量的测试，是优化的前提。
测到问题，在改之前，需要先将上面的步骤过一次，如果有意见或者设计目的的更改，需要立即更新，才能进行修改。
所以文档以及文档历史需要尽可能的完善、详尽，比如包括谁在什么时候提出了什么样的意见，据此抽象了什么样的规则，相应做出了哪些更改。这样实际工作能够救你很多次，也能节省很多时间！
