[数值]究竟做到哪一步——从仿RO的属性加点扣点计算公

天之虹

想想这个问题还是应该发在综合区，涉及到流程的问题
当然也有大量的数值问题

宣传个人Blog
抛砖引玉，希望更多的朋友来批，也让我能结识更多朋友
http://blog.sina.com.cn/u/1224467617

※※※※※※※※※※※※※※※ 以下正文 ※※※※※※※※※※※※※※※※※※※※

今天在GameRes数值区闲逛了一下，看到一个问题如下：

角色每次升级获得素质点数，1级时获得2点，等级每增加5，所获得的素质点数多增加1（1-5级升级时获得2点，5-10级升级时获得3点，11-15级升级时获得4点）。素质点数可自由增加到各种素质（力量、活力、敏捷等）中去。每个素质提升1点需要2，素质每提升7级，所需要的素质点数就增加1（素质为1-7时，提升该素质所需素质点数是2；8-14时，提升该素质所需素质点数是3，以此类推）。已知角色初始是1级，初始技能点数为0，每个素质初始为1,问角色k级时，某一项素质最大可以加到多少？
如果每个素质的初始值不是1，而是9或其他值又该怎么计算？

一个很像RO数值的问题，在我用纸笔推算的过程中，从回帖中看到了三种算的方法

1、用Excel枚举，依靠Excel的计算功能，加加减减的算出，当然缺点也明显不过了，只能算到有限级，要算下去只能让Excel继续算下去，另一个是不够灵活，改变某些参数需要把表格重新算一次

2、一条简单的公式，引入原帖如下：
设k级时候,人物的素质可以加到j级
关系有 (2+2+(k/5)-1)*(k/5)/2*5+(k/5+2)*(k%5) = (2+2+(j/7)-1)*(j/7)/2*7+(j/7+2)*(j%7)
  注意这里 * 是乘法,/是除法取整, %是除取余 ,应该明白吧? 想化简式子的时候要小心哟~~
  然后就是代入k 求 J了, ^O^

然而缺点也明显，很多参数没有通用化，在修改参数的时候需要涉及到公式上的修改很多，修改起来繁琐、不容易、并且容易带来错误

3、就是如下在下重算了的流程和公式了：

函数列举如下：
Divide（A，B）＝A除以B后的浮点数
Round（A）＝把A去掉小数部分取整
StepSum（A，B，C）＝从A到B的公差为C的等差数列的求和Mod（A，B）＝AmodB

以下初始化过程：
素质点间隔差为5级间隔一次，即AddPlusStep＝5
素质点每次增加的公差为1，即PlusStep＝1
素质点等差数列的首项为2，即InitPlus＝2
加点所需点间隔差为7级间隔一次，即AttrCostStep＝7
加点每次增加的公差为1，即CostStep＝1
加点需要扣除的素质点的等差数列的首项为1，即InitCost＝1
已有可分配的素质点为0，即InitPlus＝0
已有的角色初始属性点为0，即InitAttr＝0

以下推算过程
Level级时获得的素质点LevelPlus＝InitPlus＋Round（Divide（Level，AddPlusStep））*PlusStep
Level级的可分配的素质点的总点数TotalPlus＝AddPlusStep*StepSum（InitPlus，（LevelPlus－PlusStep），PlusStep）＋Mod（Level，AddPlusStep）*LevelPlus

某项属性升到AttrPoint的时候所需要花费的点数AttrPointCost＝InitCost＋Round（Divide（AttrPoint，AddCostStep））*CostStep
某项属性升到AttrPoint的时候所需要花费的总点数TotalCost＝AddCostStep*StepSum（InitCost，（AttrPointCost－CostStep），CostStep）＋Mod（AttrPoint，AddCostStep）*AttrPointCost

两者之间存在等式：TotalPlus＝TotalCost

利用以上五条等式可以求出AttrPoint的数值，把该浮点数数值向下取整就可以得出当前等级的最大可能性的属性点数了


从以上一个例子可以看出一些很有趣的东西，到底数值公式要规划到哪一步。

第一种依赖Excel的方法，承认是最快而且是最方便、技术含量最低的，但是在项目管理中带来的问题是，表格往往最后下来只有当事人才能看懂，人走了以后或者过一段时间以后，数值表格就显得阅读异常困难了，维护也难

第二种诚然也不是好的方法，公式虽然有了，然而都是数字和符号，阅读起来依然存在问题，而且在逻辑上的层次也不算清晰

第三种显然涉及到技术含量、时间成本、人力的要素，然而对于后期维护和管理就很好，而且在项目管理上有出色的一个优点，前期规划规划到这种程度，在实际的数值计算中分下去让几个人一起算数值，并不是不可能的事情

无论是数值策划的主管还是主策还是项目经理——多数是前者吧——根据资源和项目要求，在第二和第三种方法中衡量取舍出合适的方法，对于项目数值的前期规划，能有不错的帮助作用。

crazysoul

只对"属性点分配"这方面来说,
我觉得"地牢围攻"的模式比较好玩有真实感.它是根据你使用最常使用的技能来自动分配属性倾向的(类似5星罗盘).
如你近战斗武器用得多,体力和力量值就越大.
远程武器用得多,则加敏捷和准确率等.
魔法用得多的,自然是加智慧那些了.
(特别建议:若持续使用相近技能而升级应该有个增量(类似加速度值),即"越用越熟手",而)
这样更接近真实世界的逻辑,使玩家更容易上手及掌握,而不用每次升级都要小心翼翼的计算来计算去(DIABLO式的公式模型固然是经典,但到最后能见到的也只是一大片的不同名字的工厂模具倒出来般的游戏人物,缺乏生气和个性),可以使玩家把心思放在游戏剧情和与其他玩家的互动上,而不是与电脑公式及冰冷的数字打交道.
    现在流行WEB2.0,我认为其核心思想是在于人与人间的互动(SNS),WEB只是个平台，一个交流的工具而已。而游戏也该如此,玩家通过游戏,最终得到的不应该是虚拟的华丽装备、电子货币，而是众多各式各样的不同区域的有真情实感的“人类”朋友，这才是最宝贵的财富。

水寒三尺

为什么真正有积累有沉淀的讨论和内容在这里总是被冷淡？
堕落！

zakarum

自己理解一下，如果没有错误的话，楼主想讨论的应该不是具体的数值计算和设计问题
而是策划文档的设计和管理问题
个人觉得，虽然第一种办法最容易，但并不代表其最低效率
为什么会只有制作者看得懂？原因是他没有在其中给出足够多的计算方法及数据信息，从而在换人维护之后造成沟通障碍
但是，难道第2、3种方法的顺利沟通，就不是建立在文档结构足够清晰，反映信息足够完整的前提下的吗？
第1种方法还节省了策划的制作难度成本，其实我是更倾向于第1种方法的

shengkz

只对"属性点分配"这方面来说,
我觉得"地牢围攻"的模式比较好玩有真实感.它是根据你使...

GasPoweredGames 神一般的创造，Chris Taylor是个天才！敢于颠覆传统 [em17]

天之虹

zakarum: Re:[数值]究竟做到哪一步——从仿RO的属性加点扣点计算公式谈起

自己理解一下，如果没有错误的话，楼主想讨论的应该不是具体的数值计算和设计问题
而是策划文档的设计和管...

嗯，正解
其实第一种方法在下并不认为不好，只是说仅仅做到这样不好
其实我做数值的时候当然离不开Excel，而且是主体的制作软件
但是问题在于如果用第一种方法，如何去规范得更好，让“前”与“后”的流程更加顺利而不像传统的问题那样

shengkz

我刚开始是单开一个概念文档，记录设计指导思路，但是计划永远赶不上变化，而且Excel不像word，不支持分档显示，干脆直接在表里面单划一栏，做备忘录

madmonkey

可拓展性才是最重要的.

否则只会拆东墙补西墙.

wdnight

现在确实还是以使用Excel的方法一为主，毕竟这个方法比较简捷，对策划来说，难度也较小，只要做足文档说明，还是比较便于其他人看懂的。。。
方法2似乎中庸了点，不多说了。。。
方法3对策划本身的能力要求还是比较高了，小弟接触这部分东西不久，今天看到这个方法真的感觉不错，学习之余，感谢一下。。。

shengkz

恩，蓝图和地基更重要。。。底层的规划不好，高层的一团浆糊