-
游戏数值策划基本点
什么是游戏的数值?数值计划的工作内容是什么?数值计划应该如何提高自己?这些你所关心的问题都将逐一解答出来。游戏数值的基本概念游戏数值是感性世界的具象化。感性世界即我们可以感知到的世界,例如此刻有多少人在上课,国家产生了多少GDP,公民交了多少税等等,这些可感的世界可以具象化为数值。而游戏数值的一个重要作用,就是将游戏中的感性世界进行具象化。同时,游戏数值策划可以通过对游戏数值的监测,获取玩家的上线率、流失率等等,并通过分析数据决定下一步的游戏设计和内容制作。游戏数值还是玩家成长体验的控制与释放。它控制着玩家在游戏中的成长体验,例如游戏第一天能升多少级,能赚多少钱等等。以《火影忍者》手游为例,在做新手引导时,每一关的设计和排布都需要精心考虑,因为玩家类型多样,要想引导大跨度的人群理解游戏系统和玩法,就需要认真规划游戏中成长内容的分布及其开放顺序。游戏数值是藏于幕后的关键因素,它在幕后控制着游戏的整体表现,玩家看到的游戏世界背后其实是游戏数值的运作。数值策划的工作内容数值策划需要规划玩家成长的节奏,把控玩家的游戏体验。以《火影忍者》手游为例,我们需要规划玩家的极限成长速度、不同玩法的收益以及每种玩法的时长。成长速度、奖励分布和时长体验是制作游戏时的基础工作。数值策划的工作内容还包括设计公式和算法。《火影忍者》手游有一个叫做“极限挑战”的活动,内容是五个玩家为一组打副本,结束后根据每位玩家的得分进行排名,排名越高的人奖励越多。得分的规则有四点:第一是击杀所有怪物取得胜利,第二是战斗耗时越长分数越低,第三是复活次数越多分数越低,第四是表现最差的胜利得分高于表现最好的失败得分。表现最差的胜利指的是玩家杀光了所有怪物,但可能复活了很多次,耗时也很长。表现最好的失败指的是一位玩家无复活、低耗时杀光了大部分怪物,但可能因为掉线没有杀完所有怪物未取得胜利。因此整个公式可以设计成这样:在这一方面,公式的设计是服务于游戏内容的,要确保设计出的公式可以实现玩家公平公正的得分和排名。当公式和算法设计出来后,玩家就会有明确的驱动目标并且形成不同的玩法,简单来说就是要取得胜利,同时要尽量降低战斗时间,减少复活次数。数值策划还要考虑如何才能设计出更好的算法。下图为《魔兽世界》和《英雄联盟》的护甲计算公式。《魔兽世界》是长线成长的典型游戏,由于游戏时间长,玩家可以一直积累游戏数值。而《英雄联盟》是典型的单局成长,一局只有一小时左右,玩家的成长不会持续很长时间,因此在单局成长游戏中,就需要引入边际递减的设计,例如护甲的减伤值会随着护甲的增长递减,刚开始的增加幅度是最大的,当护甲值提高到一定程度后减伤值几乎不会发生变化,这就驱使玩家平衡发育,而不是单纯堆积护甲值。数学算法在游戏数值设计中只是工具,不是目标。设计游戏数值不需要使用过多高深的数学算法,因为过于复杂的乘方开方运算会极大地加重服务器的负担。另一方面,由于游戏世界中的规则是制作者设计的,制作者清楚游戏中一定会出现什么、一定不会出现什么,因而可以排除很多变量,使得公式的设计简化。更多时候,编写算法时要考虑如何设计公式更好地为游戏规则服务。游戏数值设计的核心内容在设计游戏数值时我们需要搭建体验模型,该模型决定了游戏给玩家提供怎样的体验。搭建体验模型总共有四个步骤:第一步是抽象化,将游戏行为拆分成关键节点,抽离游戏表象获得抽象化的规则。举例来说,《火影忍者》手游的极限挑战副本可能有攻城战、据点战等等不同类型的玩法,但其规则始终是通过战斗获取积分并以此进行排名的。还有一个例子也可以说明抽象化的过程,将大象放进冰箱抽象意义上只需要三步:打开冰箱,放入大象,关上冰箱。这一抽象化过程省略掉了冰箱是否够大等细节。第二步是设计公式和算法。公式和算法不仅仅涉及游戏规则,还规定着数值成长,例如战斗力、暴击率、格挡率、命中率如何成长。我们一般通过三种典型的曲线设计数值成长:导数递增曲线、导数递减曲线和导数恒定曲线。《英雄联盟》中免伤率的设计采用了导数递减曲线,而一般游戏中的经验值会采用导数递增曲线,而导数恒定曲线则一般用于装备数值的增长。在实际的游戏制作中,以上三种曲线经常是组合使用的,我们需要采用符合游戏体验的曲线,并加入若干参数加以修正,达到最终理想的效果。第三步是考虑边际和漏洞。我们在搭建体验模型时,要反复考虑设计中有没有缺陷和漏洞,这些缺陷和漏洞往往发生在极限条件下,尽管发生的概率极小,但我们也必须加以考虑和解决。例如玩家在某游戏中快速点击某一按钮时会造成游戏Bug,导致玩家可以无视次数限制去挑战某一副本,这就是在极限条件下会出现的缺陷和漏洞。如果《火影忍者》手游没有考虑到表现最好的失败和表现最差的胜利之间分数如何比较的情况,一旦出现这种情况,就会招来玩家的不满。第四步是设计游戏内的经济循环。游戏中的经济循环就是指玩家通过劳动获取成长,之后继续投入劳动的循环。我们需要关注游戏中产出什么、产出数量多少、如何消耗产出、消耗数量多少、玩家获得多少成长、如何释放获得的成长等问题。循环设计的优劣直接影响玩家是否能够持续地在游戏中投入时间。玩家除了要能够体验到成长,还需要渠道释放成长,例如在高居排行榜、PVP中无人匹敌、国战时以一当十等等。我们可以利用心流理论指导释放模式的设计。心流理论认为玩家在游戏中会经历四个心理阶段:无感、放松、焦虑和心流。无感是指游戏无需技巧、毫无难度,无法给玩家带来愉悦感。放松是指玩家游戏技能十分熟练,游戏难度低,游玩时放松的心理状态。焦虑是指游戏难度高,玩家游戏技能低时产生的焦虑情绪。心流是指玩家有高超的游戏技能,而且其技能和面对的高难度挑战匹配时产生的成就感与满足感。如果玩家能够经常产生心流的状态,他就会对游戏产生极大的兴趣。如何引导玩家进入心流的状态?在游戏开始时降低难度,引导玩家熟悉游戏,一段时间后提高游戏难度,引导玩家提高游戏技能,此时略微降低游戏难度,提高玩家的成就感,之后再次加大难度,如此循环往复,可以帮助玩家进入心流状态。如何学习游戏数值设计第一步,反推现有游戏的设定。反推一些经典游戏的公式和算法,在反推过程中思考设计理由和设计目的,得出结果后将自己推导出的公式代入到游戏中加以验证,例如试着打一个怪,看伤害是否和预期一致。第二步,透过游戏玩法思考设计目的。例如,极限挑战的玩法之一是时间越短得分越高,为什么要如此设计?游戏中的任何设计都有其目的。第三步,评价与反思。评价一款游戏公式和算法的设计,判断其在多大程度上能够实现设计目的。评价一款游戏设计的优点和缺点,思考如何改进其不足之处,这样的思考会为你提供宝贵的参考。第四步,积极实践。生活中经常思考商场打折促销活动背后的设计思路,熟练掌握Excel函数的使用方法,熟练掌握概率论的一些公式和数学中的常见曲线。游戏的数值设计的核心是玩家的游戏体验,游戏的过程是按照预定的规则享受整个过程,游戏的数值设计必须确保整个过程有良好的体验,逻辑是游戏数值的关键点,所有设计的制定都是以数据为基础的同时,还需要通过现象来抽象最核心的逻辑关系,数学在游戏的数值设计上只是工具,必须尽量用简单的数学运算来表现游戏规则。平时要好好考虑,接触各种各样的游戏,学习不同游戏的设计构想。
-
棋牌游戏开发-数值策划怎么做
如今棋牌游戏开发,策划是标配,一直活跃在低工资、低地位、低成长的“三低”打杂阶层,在这个阶层混迹的策划们都听说隔壁卡牌RPG游戏有个叫做数值策划的高大上牛逼职业,工资高地位高堪比程序员。众里寻他千百度,数值策划入门哪里有?一搜倒是挺多,讲的是什么?减法公式、除法公式、装备强化……和棋牌游戏没有一点关系。不过目前一些棋牌游戏开发公司开始招数值策划了,我觉得原因有二:一、很多小棋牌公司老板,在这个行业浸淫多年,多少听过什么数值策划牛、逻辑强、会数据、会挖坑、海量大数据分析等等,就想着自己也招一个这样的牛人,招来以后做什么,不甚明了。二、现在游戏行业竞争激烈,各种资源竞争激烈,人才资源也一样。不可否认,策划人才水平良莠不齐,需要一个特定的指标来衡量其能力,数值能力就是个比较客观能衡量的能力。棋牌游戏公司的策划以执行策划为多,工资不会开的很高,自然也吸引不了好的策划人才。但是棋牌游戏业务发展,公司对策划的要求也逐渐提高,对好的策划人才需求渐渴,而数值策划是策划工种内的佼佼者,自然也对其趋之若鹜了。在我看,棋牌游戏对数值策划的要求,不是对这个本身职位的要求,而是对策划能力的更深层次的要求。数值能力是任何策划都值得一生不断去提升的技能。做为一个学习者,目前我自己也很难提出一些很好的对于棋牌游戏策划的数值能力的心得和技巧。但是,学习的方法是有的,一些基础理论,门槛不高,通过持续的学习积累,是可以逐步提高自己的数值能力的:EXCEL或VBAEXCEL也是被各种数值策划教程推荐烂了的工具,那是必须会用。VBA一般用于验证自己的想法,但实际上只要算清楚了,VBA不是必须的,但VBA省时间,一般来说用VBA能解决的问题直接用EXCEL表就比较麻烦。概率论知识棋牌游戏平台,一般以金币作为虚拟货币,捕鱼、老虎机等等游戏都需要概率知识。了解什么是期望值、二项式定律,再深入一些就得用到微积分。大学时候的《概率论与数理统计》是最好的教材,嫌太枯燥可以看网易公开课可汗学院的数学基础入门视频。了解什么是赌徒谬误、大数定律、长尾理论等,这些都属于科普,都不太难。经济学知识经济学不一定都是枯燥的,不一定要看得懂《宏观经济学》、《微观经济学》才叫学习经济学,看一些大众娱乐向的《牛奶可乐经济学》、《魔鬼经济学》一样能提高经济学思维。关于数值策划相关的东西,可能再写三天三夜也说不完,但是就像我前面说的,“懂数值”不仅仅是策划装X用的,它是实实在在能顾解决问题的,是个“性价比”很高的学习对象。
-
【技术干货】为了避免办公室惨案,优秀的程序应该如何实现数值策划方案?
在游戏的战斗系统中,数值系统是很重要的模块之一。对策划来说,数值策划是一个非常重要的分类,关于数值从策划的角度介绍的比较多。但是对于程序来说,这可能是一块和需求比较密切,实现起来也没有特别复杂的工作,只是关于数值模块具体实现方法的讨论目前还比较少。最近我在对我们游戏的数值系统进行重构,一方面希望提高性能,另一方面支持策划配置更新和实时测试,减少沟通成本(主要是不想把自己变成实现策划想法的工具)。数值系统包括什么?我们可以把市面上绝大部分游戏的战斗抽象成这种模式:攻击者A使用技能I击中了受击者B,造成了伤害x。那么战斗其实就可以分为两个模块:技能流程模块/数值模块。技能流程[1]描述攻击者以什么样的表现攻击了受击者;数值模块负责根据攻击者A的属性/受击者B的属性以及技能I的信息,计算出来伤害值x;由上可知,数值系统我们可以分成三块:属性、技能信息和伤害计算。属性模块记录单位的属性值,包括血量上限、攻击力等。技能信息模块记录每个技能和伤害/治疗计算相关的信息,比如一个技能的伤害为:基础伤害+伤害比例*攻击者攻击力,基础伤害和伤害比例就是这个技能的技能信息。伤害计算模块是由计算规则构成。一个伤害值由攻击者属性/受击者属性和技能信息决定,那么使用这些信息,如何计算出来最终的伤害值,这个规则就是伤害计算模块。数值系统的实现过程中会遇到什么困难?若游戏数值需求比较简单,比如游戏只有攻击力和血量,所有的技能都是对目标造成百分之几攻击力的伤害值,其实这一块没有什么好说的,直接代码硬编码就行。但对于有的游戏,比如暗黑,玩家具有很多的属性种类,而这些属性对最终的伤害都可能产生影响。对于这种游戏,属性数量多,伤害计算流程复杂,往往会造成以下问题:1.性能问题属性之间往往是有依赖关系的,比如在DotA中,(力量型英雄)等级决定了力量,而力量又决定了攻击力、血量等。当等级上升时,这些属性都需要重新计算。其次,每次伤害也需要实时计算伤害值,对于数值复杂的游戏,每次计算要走一大坨流程逻辑,这可能是一个比较大的性能热点。在属性数量比较多、伤害计算流程复杂的情况下,数值计算就会成为性能热点。还有一个重要原因是我们使用的脚本语言python,计算成本相对C++更高。2.维护更新困难在游戏的开发过程中,数值系统往往会快速迭代。策划今天加了一个攻击属性,明天又要加一个防御属性,后天可能觉得伤害计算流程不够牛逼,再改改伤害计算流程。若策划每次修改都需要程序参与,一方面沟通成本会很高,另一方面,策划在他们文档里改了一些细节但没有告诉程序或者程序漏了,会导致代码和策划预期不同,且问题很难被发现。3.测试困难数值系统往往难以测试。比如QA在玩游戏的过程中,发现某一次伤害值不合理,但是qa也不知道哪里出了问题。只能去找策划让策划看一下相关的配表有没有问题,若策划没找到问题,只能再让程序去debug。一方面,有些情况又往往难以重现,也就无法debug;另一方面,这个debug过程设计程序策划qa三方,成本太高。4.无法做到离线分析从程序和qa的角度,保证游戏的数值系统正确性是必要的事情,也是相对简单的事情。但是,从策划的角度如何确保策划填的数值的合理性其实是一个很困难的事情。换句话说,策划如何知道他们填的数值、成长、伤害计算公式是符合他们预期的呢?这件事我们项目qa和我都考虑过,但是没有想到比较好的离线分析方案。我咨询了一些其他项目实现,比较常见的是在线分析方案,就是策划去配置几个玩家、怪物去互相攻击,看他们的属性、伤害、胜负关系和胜利时间是否符合预期。我们系统由于数值模块已经和游戏解藕,其实是能做到支持离线分析的。但策划对此的需求并不强烈也就没有推动,我们也没有做这块内容。整体解决方案这里,我先对我们游戏遇到的问题,总体介绍下我们的解决方案。2.1性能优化方案对于性能问题,下图是暗黑3截图,我们以下图的情况为例分析。在游戏里面,副本中往往是多只相同类型的怪物聚集在一起,并且具有相同的等级。因此,这么多怪物其实属性都是相同的。因此,我们可以让所有的属性相同的怪物,只计算一次属性值并且所有怪物共用。当玩家使用一个AOE同时打中多个相同属性的怪物时,其实我们可以只计算一次伤害,然后把伤害缓存下来,其他所有的伤害都不用再重新计算了。“注意,由于游戏中的伤害一般都会有随机性,这里缓存的是不随机的部分,然后每次伤害结算根据缓存信息计算最终伤害。比如,我们缓存暴击率,然后实时计算时确定是否暴击。此外,在我们游戏里策划设计了大概100个属性,并且绝大部分都会影响到最终的伤害计算。但是,这么多属性,大部分都是给玩家/BOSS设计的,而对于小怪,他们的属性少很多,伤害计算公式也就简单很多。因此,我们可以对小怪的属性进行简化,涉及小怪的伤害计算也就可以对应进行简化。对于性能问题,我们的方案总体来说用了两种方案:就是把能缓存的数值缓存起来,能共用的进行共用,以此减少计算量。对游戏中单位分类,分为小怪/非小怪。对于小怪,可以简化他们的属性和伤害计算。使用缓存方面,我们做了以下工作:引入属性树描述一类单位的属性值间的依赖/更新关系和计算公式。游戏中所有相同单位可以共用一棵属性树。具有相同属性的不同单位,可以使用共同的属性值。多个单位,若他们的技能信息相同,则他们共用相同的技能信息。引入伤害图描述伤害计算流程,游戏中只需要管理固定数量的伤害图。根据攻击者属性值/受击者属性值和技能信息,计算并缓存伤害值。以后,相同攻击者属性、受击者属性、技能信息的伤害不需要计算,直接拿cache。即使属性值变化,也不一定需要从新计算所有的伤害流程。只需要重新计算属性改变所影响到的伤害流程中的部分结果。对单位分类方面,我们区分了小怪和非小怪,然后做了以下工作:小怪和非小怪的属性数量不一样。将伤害计算区分,分为非小怪攻击非小怪、非小怪攻击小怪、小怪攻击非小怪和小怪攻击小怪。对于治疗数值的计算同样处理。因此我们游戏一共只管理了8个伤害计算图。此外,我们把数值系统和其他模块解藕后,用C++重新实现了一遍,也获得了较大的性能提升。性能优化结果:伤害计算所消耗的时间受cache命中率影响,python版本比较性能提高了6-10倍,C++版本比python版本又提升了3-5倍(由于数值公式计算还使用了callablepython对象,C++实现的提升比预期差了点)。相同单位共用属性值的提升效果和策划配置场景怪物的方式有关,在大量相同小怪聚集的地方,效率提升明显。目前,数值计算所造成的性能消耗不再是战斗逻辑的瓶颈,虽然还有一些优化空间,但是也不打算继续了。2.2数值系统的解藕和可配置化刚开始,我们的数值系统是和游戏中的其他模块耦合的。而且伤害值的计算是程序写死的,不利于程序的维护和策划对数值模块进行修改。为此,我对游戏中的数值系统首先进行解藕。将游戏的数值相关的内容都统一放到一个模块中封装起来,只留了有限的几个接口供其他模块使用。此外,为了性能优化,做的相关内容比如缓存等,其他模块也是不知道的,只有数值模块才了解内部逻辑。其他模块只能通过有限的几个接口,获得或改变某单位的属性值,或者根据攻击者受击者和技能,查询伤害值信息。另外,为了让策划可以自己修改属性和伤害计算流程,我们将这些信息都做成了可配置的。策划可以在单位表里填写单位的属性树,描述单位的属性值更新依赖和计算公式。对与伤害值计算流程,我们引入了伤害值计算流程图,策划可以定义流程图中的各个节点,以及各个节点所使用的计算公式,从而描述伤害值的计算流程。(后面会介绍配置文件什么样子)2.3数值系统的测试方案刚才已经介绍我们把数值模块从游戏中抽离出来,那么带来的另一个附加的好处就是这个系统可以一定程度脱离游戏独自运行。之前,数值系统无法测试就是因为无法获得每次伤害计算流程的中间结果。若我们可以从游戏中获得单位的属性值,然后在游戏外面计算伤害值并且把伤害计算的流程和中间都展示出来,策划和QA就能明确的了解数值系统的内部运行逻辑,哪里有问题也就一目了然。因此,我们的实习生做了一个数值系统的模拟工具。最核心的功能就是从游戏中抽取单位的属性值,然后把伤害计算的中间结果和最终结果都展示出来。属性树和属性值下面介绍我们游戏中关于属性树和属性值的实现。在我们游戏中,每类怪物/玩家控制单位都有一个自己的属性树(我们游戏也支持不同类型单位使用同一棵属性树,这里不扩展介绍)。这个属性树可能如下所示:一棵属性树从结构上来看,有的不同类型单位可能属性树的结构相同,但是不同的是,下层节点被上层节点影响的公式不同。比如,有的单位攻击力=4*力量,而有的单位攻击力=10*力量。我们把公式也保存在属性树中。每一个单位都持有自己的属性值(当然我们之前介绍过,通过一些方式若能确定两个单位的属性值相同,可以共享一个属性值。)属性值保存的就是当前单位的属性信息,可以把它通过简单的dict实现,key是一个属性名,value就是值。当一个属性发生了修改,比如等级升级或者装备增加了力量,那么就根据它的属性树结构,使用公式重新计算被它影响到的所有属性。为了性能考虑,我们游戏中所有相同类型的单位共用一棵属性树。对于同一场景相同属性的怪物,共用一份属性值。这样可以减少属性值更新所带来的计算量。伤害计算重构方案之前,我们伤害计算是夹杂在游戏战斗逻辑中的,和其他模块藕合在一起,程序维护苦难,策划也没法直接修改。后来,我们引入伤害计算流程图,策划配置伤害流程图,程序只需要读取就可以了。同时,伤害流程图的引入,也可以支持中间结果的缓存,对性能提升也有贡献。4.1伤害计算流程图一次伤害结算,是由攻击者属性、受击者属性以及技能参数确定的。我们引入伤害计算流程图来描述伤害计算的流程,以下图为例,下图是一个简单的伤害计算流程:伤害=技能伤害加成*攻击者攻击力-受击者防御力。伤害计算流程图举例该图中,技能的伤害加成属于技能信息,攻击者的攻击力属于攻击者属性,受击者防御力属于受击者属性。伤害计算流程图中存在两个节点:1.中间节点:技能加成*攻击力2.最终结点:最终伤害基于伤害计算流程图,我们可以定义每个节点(中间节点和最终结点)的描述规则,那么伤害计算流程就可以由各个节点的描述构成,伤害计算流程描述文件如下:伤害流程图配置文件4.2伤害计算性能优化我们在进行伤害计算时,若每次都计算一次,计算量往往是比较大的。因此,在上文我们说过,当同一个单位,使用相同的技能,多次中相同的另一个单位时,我们可以只计算一次,然后把结果缓存起来下次使用。可以再拓展一下,相同属性值的单位(可能是不同单位),使用相同的技能,击中相同属性值的单位(也可以是不同单位),只计算一次,把结果缓存下来。这时,若场景中成堆的小怪,往往能大幅度提高cache命中率。这时就出现了一个问题,若单位的属性、技能的参数变化特别频繁(而这是游戏的常态),缓存的伤害信息就无效了,又大幅度降低了命中率。(我们游戏大概能命中70%~80%,这个数字并不高)因此,我们基于伤害计算流程图结构,对中间结果进行cache。以之前的最终伤害=技能加成*攻击者攻击力-受击者防御力为例。我们第一次计算的时候,中间节点和最终结点都需要计算。当受击者防御力改变时,我们的中间节点“技能加成*攻击力”并不需要重新加算,只需要计算最终结果。对于真实游戏中的伤害计算流程,会存在比较多的这种中间节点,而缓存这种中间结果的方式也可以减少计算量。“测试发现,过多的引入中间节点引入(尤其在python中)会由于引入较多的函数调用和管理成本导致效率降低。因此中间结果需要以一定的经验设置,引入不常常变化的中间节点是比较好的方式,但是无节制的引入中间节点有可能造成最终结果计算效率的变低。技能的数值信息对于小怪使用的技能,一般不存在技能等级等动态信息,其实全游戏所有的相同类型小怪都共用同一个技能信息,也是完全可以的。而对于玩家,根据需求可以适当cache。比如我们游戏的技能信息被技能等级影响,这种情况如果技能等级最高5~10级的话,使用全局cache也是可以的。不幸的是,我们游戏技能等级最高100级,而且玩家技能信息可能会被各种符文影响修改,所以没法全局cache,只能每个玩家保存自己的技能信息,只要保证每次释放技能不要都去重新生成技能信息就好。伤害模拟分析工具前面介绍了我们把数值系统和游戏逻辑进行了解耦,并且把伤害计算流程改为可配置文件,因此我们的伤害计算可以做到离线计算。基于此,我们项目的实习生进一步开发了伤害模拟分析工具。此工具最重要的功能是从游戏中实时的抽取单位的属性信息和技能信息,通过工具可以选择计算攻击者单位使用某一个技能攻击收集者单位的伤害计算流程信息,包括计算过程的中间结果和最终结果。此外,我们还支持离线计算某类单位和另一类单位互相攻击的伤害结果分析等。可以供策划分析数值成长和数值平衡。总结总的来说,我们的数值系统的迭代主要是两个方向,第一个是使用cache,解决性能问题。第二个是解耦和可配置,从而进一步支持策划直接配置和实时测试。
-
游戏数值策划必看:个人数值设计规范
实现下文所需的功能,需要的知识:面向对象编程思想基础知识+数据库基础+精通EXCEL公式+熟悉VBA。树状多表引用结构多层树状表格关系结构:可以根据系统层级进行分类,首层应该只有一张表,决定游戏最核心的体验参数。末层应该有3张表。除了末层之外,都属于设计表。下面对上图中的四种表进行简单分类说明:设计表:储存基于各个层级的设计数据。设计数据应该只储存在相应层级,如果各个不同系统之间有强关联,应该用一个上级层级表来规划系统之间的关系和结构。数据表:和程序的接口,用于程序读取数据使用,但是也需要策划对该表的检测识别,查错等。数据表说明表:用于记录数据表的约定规范,该说明表应当保证数据表的可读性。枚举表:约定而成的枚举,用于储存基本的分类和结构,但不是设计数据。引用和数据管理规则基于数据库规范的数据管理。只做简单介绍,详细自行学习数据库范式。原子数据:应当要求设计表中所有数据都是原子性的,一个用于设计的单元格只储存一个数据,用于计算的过程组装数据则不需要适用,同样,末层数据表不需要适用。0冗余:同一个信息的数据应当采用引用,而不应该出现在2个地方,对于表格维护有灾难性后果,引用应当符合表格层级关系,下一层级只能引用上一层级数据,如果跨层引用,应当给每个层级都拷贝数据引用区域。主键关系:(适用于vlookup)查询关系只依赖于主键:对于range区域(矩阵),应该拥有唯一主键,并且查询关系只依赖主键,同数据库第二范式。同样目标为了明确数据关系,并且更容易配合excel函数lookup系列。巴斯-科德范式:每一个码都是完全函数依赖,任何非主属性不能对主键子集依赖,该范式对于数据表是否会出现空数据等情况有良好的改善,适用于大范围不同枚举类型的通用性公式。表结构设计表可读的分组表设计表中就应该拥有明确的分类规划,增加可读性并且明确数据影响范围。数据表主要有如下三类数据,分别为参数,曲线,矩阵。参数:决定游戏内某个部分关键数据,该数据是独立的。不受其他数据影响的。曲线:决定各类数据的趋势数据,该曲线应该部分由参数决定,如首尾数据,如积分数据,在各类成长系统,线性,离散的不同等级的部分都会用到。曲线常见应该是一个2列或者2行的数据区域。矩阵:最常用的数据区域,在excel里占用一个range。是设计表的一个子表。可以独立成为一张小表。该表格会决定各类枚举的设计分布,如不同职业属性。矩阵在过程中也常用于储存数据。计算过程:参数+曲线→计算后的曲线参数+矩阵→计算后的矩阵曲线+矩阵→计算后的矩阵计算规则:数据储存规则:区分原设计数据和计算数据,用不同的颜色区分,在调整数据时应该只修改原设计数据。数据计算规则:数据计算应该充分考虑各种极端情况以及报错情况,对报错情况进行标识处理,主要是有2个目的,1:暴露错误,不把错误带入下一层级计算。2:优化错误,使允许的错误不影响下一层级计算。数据表表格通用信息:表格名称,表格英文名称,表格类型;表格所属系统,表格所属模块;表格预留表头前空白区域储存这些信息,方便在各处整理归纳,以及跳转,目录等功能的实现。关系型数据表Excel的表格常规是普通二维表格,我们需要通过对字段的管理增加表格关系,从而把它改造成关系型数据表。主要的部分是对字段的规范以及自定义的外键部分。唯一识别码:每个字段在所有的表里应该拥有唯一识别码。常用的唯一识别码是:表格名_字段名。该名称应该是唯一的并且和表格中的每个字段意义对应,从而可以树立不同数据之间的关联关系。在有了关联关系之后,就可以对关系的检查以及跳转,大大增加了表格的可读性以及查错能力。主键:每张表格应该有唯一主键字段。对于主键的ID应该有一套完整的基于系统结构的ID规范,使ID出现时可以快速了解ID所代表的含义,可读性的ID对于程序报错时查错有非常好的指导意义。但是不要在主键的ID中隐藏信息和机制,如:用ID最后2位代表等级,省去了等级字段,并且还节约了等级遍历的操作。这种行为破坏了数据的原子性,可以在最终的数据表出现,但是任然不建议出现,尽可能的不要在设计表出现,对于数据的拆分组装回变成一个繁琐的工作。对于小型项目,节约程序成本而采用的ID带有大量信息的行为要客观看待,在工作量和可扩展性中做出平衡。外键:实现方法:规范化表头:规范化表头主要是为了实现字段的可读性,可识别性,同时可以提供字段之间的关系(外键),用于方便纠错和跳转。字段类型:主要是用于说明字段的作用,用来区分于其他字段,如:功能,数值,美术,音效,文案。字段说明:和字段外键共同使用,2边格式保持相同,主要是对字段外键的一种说明。字段外键:使用字段的唯一识别码,和字段的实际结构相同,用于识别原子数据的来源,方便查错和跳转。字段英文名:程序使用的,也是表内的唯一名称,是主要的字段标记。字段中文名:同字段英文名,在一般情况下,优先使用英文名。字段数据类型:用于程序识别的字段类型,可以是标准的数据类型:如INT,LONG,STRING,BOOL等,也可以是程序自定义的如Array,或者程序自定义的类。规范化名称管理在公式引用数据时,应该大量采用名称管理器。在大量的跨表的字母加数字的公式参数是几乎没有可读性的。灵活使用名称管理器可以解决公式可读性问题。一个好的名称管理器的命名规范应该符合以下几点:1.识别该名称是否为单一数值还是range区域。2.识别该名称准确位置。3.识别该名称的准确含义。4.在修改数值区域范围时不需要修改名称本身。常用的命名规范:1.全局参数名称:系统名称_参数名称,全局参数不能过多,才能用最简短的命名方法。2.局部参数名称:系统名称_模块名称_参数名称3.矩阵名称:系统名称_模块名称_矩阵内容_矩阵起始列名_矩阵大小注意:1.系统名称和模块名称应该和表格名称相关联。方便准确查找名称数据位置。对于采用了名称管理器的区域,应当用特殊颜色区分。2.名称区域在右边界和下边界预留两行和两列,方便插入数据不需要改变名称本身,同时也能继承以前的区域格式。表格纠错1.外键查找自动纠错,确保外键内容存在。2.填写枚举部分数据,采用数据验证部分,检测数据合法性。3.公式数据采用上面提到的错误处理方法,暴露错误或者处理错误。4.导出工具提供非法格式检测能力。表格自动化生成核心参数:提前准备用于宏观控制整个表的数值方向。资源枚举:文案美术音效枚举。属性结构:各种类型的属性结构提前设计。如:标准模型,职业标准模型,种族标准模型,模型关系。分级结构:对于分级的字段增加限制条件。如:等级成长模型,星级成长模型。设计计算方法:可计算属性=F(标记属性)。如,攻击=F(职业标准模型,职业,等级成长模型,等级,种族标准模型,种族)对于采用标准的设计方法的,末层数据表应该是可以通过VBA和公式进行自动生成的。减少大量的管理成本,可以将主要的经历用在数据本身的设计上。表格导出采用程序喜欢的导出格式即可,常用格式不多,并且通用,在此并不多说。采用vba可以实现一键导出,并且同步版本管理(SVN),以及服务器上传和服务器更新。对于快速纠错提供方便。一组数据的调试修改到表格自动化生产再导出到客户端和服务器部分应该可以在20秒内完成。快速看到数据反馈,你就拥有更多的设计和思考时间。仪表盘对于设计数据部分尽可能多采用图标结合的方式,提供更直观简洁的体验,目前没有找到特别好的报表工具等可视化插件,在此不多说,但是excel自带的表格和数据也可以提升很多设计体验。常用工具联动查看器。主要采用vlookup函数即可。需要将各类枚举还原成我们最熟悉的语言方便查看。图片部分采用index和Match函数来索引提前准备好的资源枚举。通过名称管理器赋值给图片,来显示即可。图片枚举可能需要批量的导入,可以采用选择性粘贴union编码实现,编码如下:可以加入相关参数控制图片大小。导出:各类格式导出方法,常用的如下:XML,JSON,CSN,TXT,LUA注意各种编码格式,注意utf-8和ansi的区分,注意有无BOM区分。附加功能:1.SVN提交,服务器提交,可以采用shell来调用SV和服务器的文件传输工具即可。2.邮件备份,访问指定的邮件接口,添加附加发送邮件即可。跳转:编注:涉及机密,此处不提供高清图这里需要用到字段结构标记以及关系型数据表中说到的外键。需要表格中有其他表格ID索引的数值都可以跳转过去。主要是对组装好的数据根据数据格式进行拆解成为原子数据,并且对原子数据的外键查找,在通过搜索找到对应的原子数据的位置,这样可以应用于大量的数据查看工作简化,如,查看英雄,查看技能,跳转到技能部分,查看buff,跳转到buff部分。目录:为表格指定的模块提供快速的打开隐藏功能,从而可以在一张表上管理大量的sheet而不会感到困难,可以通过表格的表头规范来自动生成目录部分。集成:对于及其常用的功能应该集成到一个通用的用户界面,如:工具箱。对于需要选择区域的常用功能,应该集成到右键部分,这样可以快速使用。第三者访问:表格功能中有大量与路径绑定的部分,对于路径管理需要有统一的入口,为了方便其他同事对表格的使用,应该提供各类路径设置的功能。不然表格更换机器和路径后功能则会失效。
-
3年数值转行前的分享:从六个方面谈数值策划核心
这篇文章我先叙述个人觉得的这行的职业状态(非行业),最后我会把这几年总结的数值知识,轮廓大致分享下,由于才疏学浅,新人觉得有用可以学习,大神如果觉得不对可以文后指出大家交流。