表盒厂家
免费服务热线

Free service

hotline

010-00000000
表盒厂家
热门搜索:
行业资讯
当前位置:首页 > 行业资讯

手游主玩法系统中被忽略的管理中枢机制

发布时间:2020-02-11 07:05:28 阅读: 来源:表盒厂家

所谓主玩法系统什么是游戏的主玩法系统?这个要追述到一些最近2年才从大佬们嘴中流行出来的系统分类:

核心玩法系统:一个游戏的亮点,无论在市场推广的时候还是在策划研发的时候,都是十分重视的系统,绝大多数手游的核心玩法系统表现为战斗系统。这个系统理论上会花最大量时间去设计开发,因为游戏的一切玩法理论上都是围绕着他延伸的。但是理论上始终是理论上,我们研发的是游戏产品,不是研发游戏。

主玩法系统:主玩法系统,其实就是大佬们嘴中所说的游戏“可玩性”,当然系统越多的游戏可以玩得东西就越多,数据理论上也会越好,这当然是没错的(请不要用BLZ反驳,大佬们认为这世界上是有奇迹的),“可玩性”故名思义就是可以玩得东西么。你不这么认为?我原来也不,只是我重新定义了“可玩性”这个词而已。那么什么主玩法系统呢?通俗易懂的说法就是:游戏中那些可有可无的玩法系统,没有这些系统游戏一样能玩,因此很多时候是被硬凑出来的,最常见的就是秦时明月的武将突破,突破以后仅仅提高了数字,假如游戏设计的时候不设计这块能不能玩?当然!甚至玩起来目标更清晰,游戏更伟大,但是不这么设计,渠道发行不买单阿——收费点少了,影响数据。所以我们在游戏中必须加上成千上万个主玩法系统。由于海量的存在,主玩法系统最终成了游戏研发过程中最花时间的部分,本贴的讨论目的实际上也就是为了简化这个过程。

其他系统:邮件、公会、好友之类的系统,即使是应用软件都会有的系统,没人认为开发这玩意儿存在什么问题,事实上也是再弱的团队一周内就能搞定这些玩意儿了。

被弄丢的管理中枢机制

明确了什么是主玩法系统之后,我们很快就能从脑袋里拿出很多很多已经设计好的主玩法系统来,并且在很多游戏中已经确实实现了。可是我们实际开发中通常犯了一个错误,就是把这些系统想复杂了,甚至每个系统去单独开发逻辑,虽然也并没多花多少时间,但是在调试、后期扩展的时候头疼不已。

最常见的头疼现象:策划设计了一个抽卡系统,一开始说了我们能抽到的都是武将和碎片,开发完了运营说话了,我们还能抽到体力,这时候就开始劳命伤财了,策划去扩展表项,至少得把MagicNumber的意义扩展了吧,程序则对应去实现代码,当然最头疼的不是实现本身,而是再啃一遍已经封存了的代码。

事实上我们可以尝试这样一个做法——先一句话描述一下你要开发的那些主玩法系统,会是如何?我简单的举几个例子:

抽卡系统:玩家按照规则支付一定的元宝,然后随机抽取,最后获得武将或者碎片。

签到系统:玩家每天可以签到一次,根据一定规则,最后获得当天可以获得的货币或者道具。

吃饭系统:玩家每天一定时间内,可以吃一次,最后获得一定数量的体力。

当我们说到这里的时候,你应该不难想到,之后深入要设计的无非就是抽卡得支付元宝规则、随机规则、签到的规则等规则,以及最后获得的东西的内容范围。没有经验的策划可能会在这里认为这样的设计就没有问题了,事实上这样的设计只是停留在玩家交流阶段,任何有经验的程序员都会问一个问题:“你最后获得的东西一定不会扩展了?比如抽卡一定只能抽到武将或碎片?”,这时候没有经验的策划甚至会拍胸脯保证。可事实上在这里,我们弄丢了一个核心的东西——我们需要的是一个管理中枢,由这个管理中枢来管理东西(我也不知道怎么称呼好了,thing恐怕是最合适的了)的获得。

假如我们按照上图这个逻辑来整理逻辑,你不难看出:

1,在我们需要获得任何东西的时候,我们都向管理中枢提出请求,当然中间可以插入(但不建议)一个额外的条件判断。

2,所谓的“分析请求”实际上就是这个管理中枢的核心工作。

3,分配各种东西给玩家对应的数据块。比如道具、比如体力,我们知道通常这些东西,包括我们所理解的道具本身都会产生不同的结构,比如武器和药丸和钥匙之类的,最终真的用同样的数据结构吗?如果不,我们是不是至少需要每个都有一个数组去记录?那么这些东西在策划填表的时候是否本身就该区分开?(至少某些表格的内容会有明显区别)

这个思路其实就是所谓的“管理中枢机制”的核心所在,他的好处在于一个更高的可扩展性,以及后期程序不用太大的去改动代码,简单的例子就是:

签到系统:最初策划的设计是,每天签到可以得到配表中的道具(扩展的什么连续多少天获得什么我们姑且不说,各家有各家的做法,但原理相同于每天签的东西),但是运营认为不够,除了道具我们还要能签到小弟,还能签出碎片。这时候我们传统的做法是做一个礼包之类,而礼包本身其实就是这个管理中枢,只是没有机制化的管理。

从我们的这个机制来看,签到系统是如何工作的?

我们对比传统做法和管理中枢机制,区别仅仅在于最后一步“发放奖励”的过程。但玄机也在这里,因为最后一步决定了一个可扩展性和策划表项的问题,当然这里的可扩展性仅仅只是可以给的东西的可扩展性。

我们先看下传统的表项会有什么数据?

1,id:还是有比较好。

2,时间:可能是用于几月几号,也可能是签到多少天,这个具体看策划设计的规则,但肯定有一个时间。

3,奖励道具id:奖励什么道具。

4,奖励道具个数:就给1个肯定满足不了需求吧。

那么现在问题来了,运营说话了,我们要签到给小弟,怎么办?做法2个:

1,增加一种道具叫做小弟,得到道具给小弟,聪明的做法。

2,傻瓜做法,增加表项:奖励类型,这个MagicNumber决定了奖励的是道具还是小弟,0=道具,1=小弟,自然的,原来的“奖励道具id”和"奖励道具个数“根据这个MagicNumber值不同也被赋予了不同的意义。

无论你怎么做,最后的结果是,程序必须去增加一个道具获得方式,改变读表的代码是少不了的工作,毕竟你表项改变了,至少某些数据的意义发生了变化。这样的扩展手法其实是不良的,那么看看我们的管理中枢机制是如何工作的?

还是先看一下表项有些什么数据?我们可以把它分为2个表,其中一个叫做东西表,这个东西表的用途不仅仅是在签到,她的数据一样可以用于抽签等其他系统:

1,id:别的数据挂过来的依据。

2,执行脚本:事实上对于策划来说,需要的只是填写一个String,甚至如果环境允许就直接在里面写函数了。程序在“分析请求”的时候要做的事情就是执行这个脚本。Array->Dynamic (Haxe),传入的数据是脚本参数,返回的是获得的东西,所以都采用Dynamic。

3,脚本参数:脚本需要的参数,Array,根据每个脚本需要去传。

我们尝试虚拟2条数据,一条是获得id=333的道具20个,一条是获得id=216的武将,如果武将已经存在则是她的灵魂碎片。则数据为:

thing[0]=[script="gain_item", param=[333,20]];

thing[1]=[script="gain_buddy", param=[216]];

我们在通过签到去挂向这个表,签到的表项为:

1,时间:同传统模式。

2,获取:int,也就是对应thing的id。

除了签到外,其他表一样可以索引thing的数据,比如我们需要一个抽签表,表项为:

1,thingId:对应到thing表的id。

2,出现加权:这个thing被抽取的概率。

3,必出多少

4,在多少次中:和3共用形成“1000次抽取中必出3个这东西”的效果,此处不作详细解释。

说到这里,你应该大概能看出这个机制的一个好处,但是这里还有一个疑问应该留在你心里——“一条是获得id=216的武将,如果武将已经存在则是她的灵魂碎片”这玩意儿应该如何去做?这里通常思路会犯一个错误:我们直接在脚本中判断:

if (iHaveBuddyById(216)==true){

giveSoulShard(216, il(ndom()*10));//错在这里

}else{

giveBuddy(216);

}

我们可以看到上面一段伪代码中,有一个严重的错误,就是当我们判断到已经有武将了,没有通过这个中枢机制就直接给了灵魂碎片,这形成了一个错误的逻辑交叉:

既然分析请求已经执行了脚本,那么要么就是给出武将要么就是给出碎片,因此在给出武将未果的情况下,应该重新提交一个请求给自己,那就是给出碎片的请求:

这样才是一个正确的执行流程,因为我们需要保证,游戏中给的任何东西都是走这个中枢机制的,为什么要这作,因为这里有一个真正的可扩展性存在,举一个简单的例子:

1,我们要设计成就了——获得过100个道具,请注意是获得过,而不是你的背包里实际有!那么你必须要有一个点去统计你获得过多少个道具。

2,我们要设计挑战了——获得杨过之后获得小龙女,然后获得尹志平,请注意,获得顺序必须是这样的,杨过-〉小龙女-〉尹志平,那么在这个流程上该干什么?你看出来了吗?

实际游戏开发中的使用感觉

其实说到这里你应该已经多少看出来了,这个机制用于游戏的绝大多数主玩法都没问题,因为所谓的主玩法无非就是玩家通过一定规则获得一定好处。而这个机制的关键就在于把好处抽象成一个东西,整体管理。

而在实际开发中,我们发现程序在完成了这个机制的coding之后,不需要对这个机制的代码在作什么改动,只需要在对应的系统中提供脚本接口和维护功能就可以了。但是这玩意儿有一个门槛,就是对于策划的抽象能力要求会略微高那么一点,如果用一个数字来形容的话,一般策划需要60以上,而玩这个机制的策划需要64以上。

公司变更

广州工商税务费用

筹划税务如何合理避税

广州代理记账会计公司

相关阅读