|
发表于 2013-6-28 08:12:20
|
显示全部楼层
头2个观点很赞同,大方向上的确如此,但是后2个我感觉有点偏激了,简单说说我的观点和一些现实中看到的情况的分析:
所有数值应该是算出来的没错,可是事实上这条目前很难落实,我们去很多地方和人合作的时候遇到过这样的问题,就是很多公司的数值策划(他们一定要这么分工,我不是很赞同,但公司是人家的),他会说很多大道理表达出自己的想法,想要做什么,我觉得思路很清晰,可是看到他们动手做的,我觉得他们的核心问题是没有一个方法。首先越简单越好我很认可,也是我一贯的准则——Keep it simple,他们也能接受这个说法,并且他们能从别的游戏中吸取好的公式,比如LoL\Diablo\WoW都使用的伤害公式,可是当需要加入自己游戏的一些需求后,就开始摸不着头脑了,我最近一次接触的公司的实际情况(很有代表性):
1,他们要求做一个掉落百分比,系统策划大谈特谈想要如何如何,数值策划却没法保证,我问了他们一个简单的问题,一个怪掉落1个A道具的概率是10%,那么10个这样的怪掉落且仅掉落1个A道具概率是多少,很可怕的是——他们没有思路,但是他们知道不是100%。因此他们都没法去分析我该如何设定这个具体的数。
2,我告诉他们这个做法很简单,那就是用二项分布去观察这个概率问题,你会发现很多有趣的现象,10个怪掉落且仅掉落1个A的概率未必比掉落更多个要高。他们虚心的接受了(但我看得出他们中很多人是迫于他们老大的威信压迫,打心底里不能接受,这就是国内策划另外一个可怕的问题——缺乏知识却不乐意学习,过于自大过于自我中心)。然而接受以后事情还没完,我发现了更可怕的事情——他们在凑概率。
3,从程序的称呼来说,这样的凑概率的做法叫做穷举,你知道的,密码是1到5位的0到9的数字,只要你有耐心且没有次数限制你一定能破,这个做法叫做穷举,而他们为了凑一个3%的效果就在不断穷举,高了往下,低了往上。不过说实话,我也没办法破这个,因此这个给我带来了新的思考——我们需要一种做法,能够主动地(或者说按顺序的)去实现设计需要,而不是定义了设计需要后反推。
4,于是回去后我这几天就在分析一个东西,虽然目前有了一点眉目,但是因为没有落实过,所以不好分享,但是我可以共享一下思路,简单的说那就是——柏林噪声。如果你是一个专业的游戏设计师,我认为你应该至少知道这个名词,柏林噪声的有趣之处就是把不同的平滑声波组合到一起产生一个新的声波,我们知道很多3D游戏的地图(陡坡之类)和一些特效的纹理都使用柏林噪声算出来的。
之所以我会选择柏林噪声,从思路出发,你可以看到柏林噪声和我们现实工作的很多相似处:
1,系统策划设计了一些需求,其实按照我们的工作方式是,我设计了系统因此得到了对应的需求,这些需求在开始的时候毫无规律可言,你可以把他们当作柏林噪声产生的第一阶段的那些随机产生的点——因为人的第一感觉(缺乏冷静思考和分析,但很直觉)的需求,往往就和随机数一样没有规律。
2,当这些需求达成之后,我们需要做的事如何平滑每个需求——“我需要1级到15级升级很快,15到30有点坎坷,然后30到45又很快”,“4到18级的时候新手引导给经验多,之后的任务经验开始逐渐减少,到44级来个兴奋点让经验大幅度提高”,关于这样的大纲性的需求我们听说了很多,也许是一些老板提出的,也许是一些“主策”或者系统策划提出的。因此我们的工作(如果你的公司细分了数值和系统策划的话)第一步就是平滑这些曲线,单独平滑每一个,因此这个例子中,你有2个曲线要去“平滑”(或者直接说就是去做插值之后微调),当你完成了这两个曲线图的时候,不妨给提出需求的人看(这很重要),他们虽然没能力或者精力去做这个事情,但是看到曲线是否和自己的Feeling对得上,还是能直接提出的,在这个阶段反复沟通达成一致,就好像原画在初始线稿阶段和策划沟通一样,方便简介,Feeling对这步就过了。
3,接下来我们要做的事情分析振幅和频率,这和标准的柏林噪声做法有一点出入,也是需要策划特殊处理的东西——那就是将波长平分(事实上你不保证波长相同也不是不行,但是会有很多麻烦),把这步做好以后你要做的还是和设计这个构思的人沟通,但是这次更多的是说服他们必须接受函数曲线的变形,不然就没法继续了。
4,把N段音波叠加,也就是N个平滑后的函数叠加,就能得到最终符合所有需求的函数,但是任何人看到这个函数也许都不太能接受,包括你自己,但事实是上柏林噪声函数就是这样的,接下来就是“人性化”工作,就是为噪声提供一个持续度和倍频,然后去产生柏林噪声结果,这不是否需要或者该不该做,我现在也不好说,柏林噪声函数在我举得例子中他的意义只是设计出了我在什么阶段的经验获得速率(最终你还是得还到另外一个公式去计算),但是有些问题,包括这个经验问题,也许还是需要通过分析一个持续度和倍频,来得到一个1维的柏林噪声,使得数据更理想化(主观上去评定),这个我现在不好说,如我所说没有实际应用到10个以上项目前我只发表想法不发表结论。
我找了资料并没有发现有人用柏林噪声的原理去思考无限要求下的数值设计,而事实上这样的需求在国内研发公司又是很常见的,源于设计人员受限较多,或者说提出限制的人真心是不懂行,但是我们还不得不这么去做。
其实这样的做法产生一个结果是数值看起来复杂了,但是你还是能够通过运用让他简单,我不能认同数值越复杂越好,我认为数值应该是让玩家能够猜到的,至少反推偶合率要高,这样才适合Hardcore玩家去进一步分析游戏,这种东西谈不上商业机密,因为这只是游戏的简单内容,我甚至认为这应该所有人在一起共享经验,互相交流,以创造出更好的数值设计流派,而不是各自按照格子的弯路走下去,走一条不归路,最后谁都不买谁的账。 |
|