|
|
GameRes发布，文/猴与花果山，转载请注明作者和出处
所谓主玩法系统什么是游戏的主玩法系统？这个要追述到一些最近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>->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);
}
我们可以看到上面一段伪代码中，有一个严重的错误，就是当我们判断到已经有武将了，没有通过这个中枢机制就直接给了灵魂碎片，这形成了一个错误的逻辑交叉：
既然分析请求已经执行了脚本，那么要么就是给出武将要么就是给出碎片，因此在给出武将未果的情况下，应该重新提交一个请求给自己，那就是给出碎片的请求：
这样才是一个正确的执行流程，因为我们需要保证，游戏中给的任何东西都是走这个中枢机制的，为什么要这作，因为这里有一个真正的可扩展性存在，举一个简单的例子：
1，我们要设计成就了——获得过100个道具，请注意是获得过，而不是你的背包里实际有！那么你必须要有一个点去统计你获得过多少个道具。
2，我们要设计挑战了——获得杨过之后获得小龙女，然后获得尹志平，请注意，获得顺序必须是这样的，杨过-〉小龙女-〉尹志平，那么在这个流程上该干什么？你看出来了吗？
实际游戏开发中的使用感觉
其实说到这里你应该已经多少看出来了，这个机制用于游戏的绝大多数主玩法都没问题，因为所谓的主玩法无非就是玩家通过一定规则获得一定好处。而这个机制的关键就在于把好处抽象成一个东西，整体管理。
而在实际开发中，我们发现程序在完成了这个机制的coding之后，不需要对这个机制的代码在作什么改动，只需要在对应的系统中提供脚本接口和维护功能就可以了。但是这玩意儿有一个门槛，就是对于策划的抽象能力要求会略微高那么一点，如果用一个数字来形容的话，一般策划需要60以上，而玩这个机制的策划需要64以上。
|
|
发表于 2014-7-11 10:47:43
发表于 2014-7-11 11:34:37
