|
|
在很多项目的任务设计这块中，其实存在了很多“雾点”，首先抛开那些“就是来混个工资、上面怎么说我怎么做”的消极思想（存在这些思想的人本不该来到这个行业，可是为了生计又找不到别的薪资还不错的工作选择了这个没有很好标准的行业，只能说行业有待排泄）我们可以看到，其实在设计任务系统（更确切地说是任务机制，因为你的思路会跟你走过所有的项目）的时候，我们会被逻辑中一些自己也很难弄清的东西所忽悠，加上一个“反正我有表弟表妹来填表”的惰性心理作怪，让我们设计出了糟糕的任务系统。那么我们就静下心来，仔细地穿过这些迷雾，看看其中我们到底是如何把这个系统作的如此的……有“局限性”又或者“让填表的人抓狂”也许是“功能太过紧张”。
1，设计任务机制的基本思想"You call me, I don't call you"。
"I call you, you don't call me"是一种很好的程序构架思维，这种思维方式的核心在于——假设我是一个系统，另外一个系统需要我提供相关数据的时候，仅仅由它主动来访问我，而我从不向他提供任何帮助。这样的单向交互思路看似很死板，但是因为避免了“交叉传递”，以至于整个过程的逻辑思维都是清晰的，不会产生很多“带有Magic效果的渣滓”（这个在程序中很忌讳），基于这个原理，我们看到了unity的component机制和我们正在使用的一套entity system机制。
这个思维方式的精髓，我们可以拿来用到游戏中可以说是最难设计（因为总是随游戏变化，非常Specialize）的任务系统，但是需要的是把思维逆转过来——"You call me, I don't call you"。我们不难发现，很多时候我们策划设计了一个任务系统，他的完成条件千奇百怪，我们实现杀怪任务、实现道具检查任务都很常见，事实上如果加以归纳，你不难看出，只是在一些特殊的“活动”中，寻找到了Call的点，通知任务系统，我的某项任务进度发生了变化。和我曾经说过的buff机制非常相似——这也是一种类似dispatch的机制。因此我们应该对这个思路进一步的探索，以至于制作出更多的任务条件来，比如要求合成某个药水，假如我们只是简单的去在背包道具发生变化或者任务接受的两个时间点去判断背包的情况，那么我们就同时犯了2个错误：
错误1：我买了或者通过别的办法获得了这瓶药水，而本身并非制造出来的，任务一样算是完成了。为了弥补这样的逻辑漏洞，我们要么在药水的来源上加以限制，要么在设计任务时候动足脑筋。可是事实上我本来想做的只是一个引导类型的任务，玩家15级了，可以接触到生产系统了，我只实现告诉他生产一瓶药水来恢复自己生命值是游戏中的一个恢复生命的手段……
错误2："You and me call him"，这是最常见的逻辑错误，我任务系统和你生产系统一起去寻找了道具系统，为的仅仅是完成某个任务的条件。虽然也许效果达到了，可是背后付出的代价却太过惨痛，假如我们又来了个任务要求尝试A材料、B材料、C材料之间22合成……任务条件1：A和B合成；任务条件2：B和C合成；任务条件3：C和A合成；任务条件4：随意选择一个合成物吃下。这样一个任务的实现，你打算如何？
所以我们在设计任务系统的时候，必须做好一个规划，形成"You call me"，而很多资深策划在设计的时候思想中的确清晰的想到了"You call me"，这是什么样的感觉呢——同样是杀怪任务：
初级策划的想法：通过任务系统去监视玩家和怪物交战，从而获得杀怪信息，由此判断“我”（任务条件）是否被达成。
资深策划的想法：在怪物死亡时进行回调，检查攻击者Call他们的任务系统，来检查是否完成了某个任务的某个条件。
乍一看2者的想法没什么很大的区别，但事实上到了动手层，这两者是相反的做法，前者包含了上面说的2大错误，而后者思路更为清晰，但是我们事实上很少看到一个任务系统的表项是这样的，没错，这里就是问题的关键，我们的策划虽然归纳了这样一套思路，却缺少一个很好的让人填表的环境，举个实际点的例子：
任务条件：击杀20个哥不林。
很简单的一个任务设计中存在了一个很典型的表项设计问题——请问：什么叫哥布林？在我的地图上有20多个品种的哥不林，冰霜哥不林、烤肉哥不林、茶杯哥不林等等等等，他们都算吗？还有他们的等级不同，区域A有16-18级的面包哥不林，区域C有22-24级的面包哥不林，他们也都算吗？
实施上解决这个问题的核心是，我之前曾经在某个建表思路相关的帖子中说到的那个手法——Tag。这是一个需要抽象的手法，Tag最简单但实际上有悖于任务系统的做法就是给小怪本身添加了一个Tag，我们给B区域的蛋糕哥不林（16-18级）和轮胎哥不林（15-17级）标上同一个Tag叫做“B区哥布林”然后任务目标设计为“击杀B区哥布林20个”。在这里的确Tag帮你完成了麻烦的表项，但是你应该进一步的把思路逆转过来——
我应该给每一个任务目标一个Tag，在触发回调的时候执行“提高对应Tag的任务条件进度”。
假如我们有20个任务关于收集巧可力蛋糕的任务，玩家有幸同时接收到了3个：
1）帮助林克哥哥准备行李，任务条件：收集回力标1个；收集2个巧克力蛋糕；收集奇怪的帽子1个。
2）料理妈妈的好帮手：任务条件：亲手烹制3个巧克力蛋糕；交给料理妈妈3个巧克力蛋糕。
3）买通贪吃的兽人守卫：任务条件：准备3份巧克力蛋糕；准备3份环山魔暴龙肉；准备3份奇拉烤虫皮。
如果你把任务1的条件2、任务2的条件2和任务3的条件1设为同一个Tag：“Collect Chocolate Cake"，那么在道具(item)进入背包的时候触发一个动作——IncreaseQuestFinish("Collect Chocolate Cake", item.stackCount)，由这个函数作为回调实现道具管理系统Call任务系统，效果会比反过来检查带有"CCC”标签的道具获得好很多，至少你会少很多次遍历，并且我们要解决的问题不仅仅是获得道具的时候，我们有很多的回调点要去做类似的事情。
2，“万事结束难”，什么样的情况下我的任务结束了？
事实上当你在设计一个任务的时候，尤其是一个沙箱型游戏的任务的时候，最难得事情之一是结束掉某个任务，举个例子来说：
任务要求玩家和张无鸡（这就不触犯搜狐畅游了）一起去后山为姬小福（连举个例子都怕侵犯人家权益阿，风口浪尖嘛）采集车前草或者别的什么东西10颗。整个后山只有12颗车前草可供采集。假如玩家丢掉了3颗以上的车前草，那么任务事实上已经失败告终了，这时候策划为了避免这样的“软死机”（程序运作正常，但是玩家由于某些情况无法正常继续游戏了）会想出很多种牵强的解决方案，例如：
1）车前草不能丢弃，当玩家不小心把车前草吃了的时候问题又发生了，于是游戏中有了2种车前草，名字都叫车前草……
2）车前草会刷，这个感觉比起强硬的手段来说更加舒服点，至少这样避免了软死机又不是很影响玩家的体验，但是不幸的是，玩家不去为了Boss身后那5颗被他看着的车前草去挑战Boss了，而是坐在原地等一颗刷新，于是策划们又聪明的想到了只有Boss身后的会刷新。
为什么我们设计一个任务都必须要先发生一些极端的边际问题后才想到修改呢？假如产品上线了才发生这样的问题你知道后果多么严重吗？这里我就要再次强调设计思路——"You call me I don't call you"，如果按照传统的乱Call做法，你会发现你根本没法去做出这样的任务结束判定：
a)我们判定道具低于一定数量了任务失败吗？那么我还有3颗没有采集，我身上有9颗，我丢掉一颗算失败吗？
b)我们判断如果地图上的车前草+我身上的不足10颗了判定任务失败——"天哪，你真高！"
c)再丢弃道具的时候记录一下我已经丢了几个了，或者获得时候我记录一下我获得过几个，这是一个很好的思路，但是重要的是你如何去执行？
没错，你会选择c的做法，在采集到任何一棵车前草的时候用buff的层数（玩家不可见）去记录我采集了多少个车前草，因此你不难发现，好的做法是：
当我们采集车前草的时候会获得1层Buff，而Buff在Occur时（如果你不明白我说什么，可以看下我之前说过的Buff机制）的工作是检查当前层数和背包内的车前草数量是否符合差距在3以内，如果层数-车前草数量>3，那么由Buff的Occur通知任务系统——任务失败了。
可见有效的整理了思路和利用了机制，完全可以把一些很困难，困难到不得不用特殊处理去解决的问题解决好。
3，设计与执行——策划与程序思维的逆向矛盾。
也许有人觉得我们说的这个机制概念太过程序化，适合程序员，但事实上正好想反，这样一套机制的思路，对于程序员来说是很难接受的，因为其中充满了Magic的东西，比如Tag，比如回调点和调用事件。这就是一个策划和一个程序员最大的界限——程序员尽量避免Magic的东西，因为这样会让代码几乎无人能维护，时间长了包括他/她自己都搞不定；但是策划会合理的使用Magic的东西，这就是两种本质的抽象方向区别。
在实际研发过程中，这种"You call me"的任务机制，对于程序员的开发来说是非常清晰的——
Step1：在写功能的时候注意回调点。
Step2：提供3个接口来提高任务进度、降低任务进度、直接完成或者失败某个任务。
Step3：调试并确保可用。
实际上，在任何一个回调点，它们本身都不关心任务数据，就比如谈话的时候，策划可以在NPC表中加入和某个NPC谈话时“增加Tag为[找NPC说话, 威胁NPC]的任务条件进度1”就行了，至于角色是否正在执行任务，如果正在执行，那么就+1，不再执行自然循环结束没有执行到，而循环重要检查的只是每个任务的每个条件是否是这样的Tag，根本不用去解析任务条件的所谓类型。
但是对于策划，这是一个有困难的工作，事实上并不是很大的困难，只是对于抽象能力有一定的要求——我从不认为没有抽象能力的人有资格成为游戏策划。策划需要比较多的逻辑抽象，比如当我们要设计一个任务：
调制阿拉伯神油：老汤姆最近总说自己身体状况不是很好，至少他的妻子认为这是一个愚蠢的借口，他们的夫妻关系一度非常紧张，作为一位天使，你应该想法协调他们，恩，我有个好办法，我记得年轻的时候人家常说一种叫阿拉伯神油的东西，很适合老汤姆现在的需要，你可以帮他弄点，不过这玩意儿，怎么调制来着的？我有点忘了，好像要辣椒？还要皮鞋？或许还有些巧克力？哦，对还有汽油？阿呀不对不对，总之只要2样东西搅和在一起加热就行了。
玩家获得4种道具，之后如果将辣椒和汽油组合就能获得阿拉伯神油（现实中配方并非如此，我先声明——如果你照做后果自负），但是玩家尝试过程中也许会失败几次。因此我们制作这样的任务的时候，就需要在每次Craft时候去执行：
1）给玩家添加一个记录尝试次数的Buff，通过这个Buff的层数，改变完成任务时候任务给于者说的话，当然你也可以给不同的buff，根据buff组合说出更有趣的话。
2）当Craft出神油的时候触发任务进度提高。
看起来整个任务要做的事情少了，但是其实要抽象的东西会多很多，也包括如何合理的分配Tag，这都是一门学问，当然这只是为了游戏做的好玩，这基本不会为你带来神仙道般的收入。
如果我们在设计任务的时候能够抛开这些雾点，那么任务系统就会被做的更加丰富，但是系统也好，机制也好，那都只是工具，使用好工具才是好的策划的水平体现——“君子生非异也善假于物也”
|
|
[复制链接]
发表于 2013-8-26 09:05:06
发表于 2013-8-26 11:20:25
楼主