游戏开发技术论坛

 找回密码
 立即注册
搜索
查看: 12616|回复: 9

[讨论] [技术交流]手游主玩法系统中被忽略的管理中枢机制

[复制链接]

98

主题

787

帖子

4478

积分

版主

Rank: 7Rank: 7Rank: 7

积分
4478
发表于 2014-7-11 10:47:43 | 显示全部楼层 |阅读模式
GameRes发布,文/猴与花果山,转载请注明作者和出处


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

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

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

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

被弄丢的管理中枢机制

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

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

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

抽卡系统:玩家按照规则支付一定的元宝,然后随机抽取,最后获得武将或者碎片。
签到系统:玩家每天可以签到一次,根据一定规则,最后获得当天可以获得的货币或者道具。
吃饭系统:玩家每天一定时间内,可以吃一次,最后获得一定数量的体力。

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


thing0.png

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

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

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

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

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

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

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

thing1.png

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

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

  1,id:还是有比较好。

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

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

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

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

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

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

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

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

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

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

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

  我们尝试虚拟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, Math.ceil(Math.random()*10));//错在这里
}else{
   giveBuddy(216);
}


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

thing2.png

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

thing3.png

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

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

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

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

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

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




102

主题

2443

帖子

7639

积分

论坛元老

Rank: 8Rank: 8

积分
7639
发表于 2014-7-11 11:34:37 来自手机 | 显示全部楼层
不太理解楼主的东西有什么特别之处……

0

主题

13

帖子

52

积分

注册会员

Rank: 2

积分
52
QQ
发表于 2014-7-11 14:04:56 | 显示全部楼层
其实是设计模式问题。

0

主题

114

帖子

753

积分

高级会员

Rank: 4

积分
753
发表于 2014-7-14 08:40:46 | 显示全部楼层
是指所有奖励发放调用统一接口么?
方便做监听和调整?

0

主题

52

帖子

919

积分

高级会员

Rank: 4

积分
919
发表于 2014-7-15 10:25:05 | 显示全部楼层
你这个只适合服务端这么弄,前端展示的地方这样做是不行的

3

主题

73

帖子

1065

积分

金牌会员

Rank: 6Rank: 6

积分
1065
QQ
发表于 2014-7-15 17:12:18 | 显示全部楼层
跟策划扯技术,跟技术扯策划

0

主题

196

帖子

1104

积分

金牌会员

Rank: 6Rank: 6

积分
1104
发表于 2014-7-15 17:21:08 | 显示全部楼层
本帖最后由 andrewzhi 于 2014-7-15 17:25 编辑

哪有这么啰嗦的  你把所有资源都道具化不就成了么?用这么深奥么?很简单的事情被楼主复杂化了

0

主题

26

帖子

535

积分

高级会员

Rank: 4

积分
535
发表于 2014-7-16 12:36:49 | 显示全部楼层
本帖最后由 pig345 于 2014-7-16 12:42 编辑

现在手游追求 快速山寨,在这种团队里面,很容易发生这样的情况。

因为盲目求快、策划们来不及也不会考虑:
1)能否实现(被抄袭的原版都实现过了你还不能实现?!)
2)将来的扩展性如何
更不会做
3)进一步深入的逻辑结构上的设计。

程序们也整天苦逼地忙编码,加班还完不成呢,谁管你扩展性!

传统开发过程中很重要的一个步骤:需求分析、框架结构设计 自然地被忽略了。

0

主题

9

帖子

116

积分

注册会员

Rank: 2

积分
116
发表于 2014-8-7 20:26:31 | 显示全部楼层
好比有一扇门,每次物品获得都要经过这扇门并记录,所有的记录就形成了一个顺序的列表喽

1

主题

13

帖子

115

积分

注册会员

Rank: 2

积分
115
发表于 2014-8-30 22:40:03 | 显示全部楼层
其实这个应该是你们程序做的事情,抽象接口,所有物品继承公共接口,获取的时候通过统一的方式进行获取。无论你吧他理解成什么都没有关系,本质上在表里面是一样的。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2023-1-30 05:29

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表