游戏开发技术论坛

 找回密码
 立即注册
搜索
查看: 21448|回复: 33

[原创] [技术交流] 几乎是全类型游戏任务机制设计中的“雾点”

  [复制链接]

98

主题

787

帖子

4478

积分

版主

Rank: 7Rank: 7Rank: 7

积分
4478
发表于 2013-8-26 09:05:06 | 显示全部楼层 |阅读模式
  在很多项目的任务设计这块中,其实存在了很多“雾点”,首先抛开那些“就是来混个工资、上面怎么说我怎么做”的消极思想(存在这些思想的人本不该来到这个行业,可是为了生计又找不到别的薪资还不错的工作选择了这个没有很好标准的行业,只能说行业有待排泄)我们可以看到,其实在设计任务系统(更确切地说是任务机制,因为你的思路会跟你走过所有的项目)的时候,我们会被逻辑中一些自己也很难弄清的东西所忽悠,加上一个“反正我有表弟表妹来填表”的惰性心理作怪,让我们设计出了糟糕的任务系统。那么我们就静下心来,仔细地穿过这些迷雾,看看其中我们到底是如何把这个系统作的如此的……有“局限性”又或者“让填表的人抓狂”也许是“功能太过紧张”。

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,这都是一门学问,当然这只是为了游戏做的好玩,这基本不会为你带来神仙道般的收入。


  如果我们在设计任务的时候能够抛开这些雾点,那么任务系统就会被做的更加丰富,但是系统也好,机制也好,那都只是工具,使用好工具才是好的策划的水平体现——“君子生非异也善假于物也”




46

主题

1586

帖子

3523

积分

论坛元老

【游戏哲学大师】

Rank: 8Rank: 8

积分
3523
QQ
发表于 2013-8-26 11:20:25 | 显示全部楼层
说真的,猴子,你很专业,但专业并不代表大众就能接受。

本人表示看的一头“雾水”。

1

主题

3

帖子

21

积分

新手上路

Rank: 1

积分
21
发表于 2013-8-26 12:39:51 | 显示全部楼层
u call me中怪物掉落物品怎么实现 打怪的action触发task(me)。。。

98

主题

787

帖子

4478

积分

版主

Rank: 7Rank: 7Rank: 7

积分
4478
 楼主| 发表于 2013-8-26 12:41:54 | 显示全部楼层
善与恶 发表于 2013-8-26 11:20
说真的,猴子,你很专业,但专业并不代表大众就能接受。

本人表示看的一头“雾水”。 ...

你不干这行不明白也很正常啊,不过如果你很感兴趣,可以先自学一些或者自己总结一套关于任务系统的设计,然后实际操作的时候就知道我这里说的是什么了。我觉得我只是在抛砖引玉,这个论坛活跃的还有个daofeng和一个yuki001看了也许会有点想法说说,我已经吞噬了一些他们曾经在别的帖中说的东西,感觉良好。
假如你还是一个初级策划,当你看到这些问题不知所云的时候,应该去找有经验的策划了解下详细,而不是去参与一些更符合自己口味的等级段的东西,那样对成长无益。别的团队最近“借”过来一个号称文案策划的,让她帮我们的武侠写世界观,她不是很乐意,反而对写另一个团队页游项目平淡如水的武侠剧情流水帐更感兴趣,的确那可以100%的发挥她的能力,但是人不能永远只原地踏步,我们老大找了很多相关剧情设计的好书,我和一些朋友都对这些知识爱不释手,而她却不屑于看,看了三页就丢了,因为她找到了和自己水平对路的东西后,就不思进取了,这其实是在自我淘汰。

98

主题

787

帖子

4478

积分

版主

Rank: 7Rank: 7Rank: 7

积分
4478
 楼主| 发表于 2013-8-26 12:46:08 | 显示全部楼层
iiiii 发表于 2013-8-26 12:39
u call me中怪物掉落物品怎么实现 打怪的action触发task(me)。。。

http://bbs.gameres.com/thread_213408_1_1.html
这个问题我在之前一个帖子是这么说的,不过这里还是要注意一个问题——掉落的Call仍然是由拾取后的道具管理系统来进行的(我说的掉落是传统的掉了东西你要捡起来凑数量的,但如果你说的是其它的玩法……)

4

主题

726

帖子

3422

积分

论坛元老

Rank: 8Rank: 8

积分
3422
发表于 2013-8-26 14:58:56 | 显示全部楼层
刚入行的新人表示一直在各种论坛苦苦摸索“思想”上的提高境界,但是没有真正的项目去实践。大公司门槛各种高(被完美的笔试题吓尿了),小公司各种看工作经验,我真是蛋疼啊。咋找个策划工作这么难?现在在一家公司做“换皮”我真是感觉在浪费生命,我想从头跟项目啊。。。。。。换皮学个毛线啊。。。。
  抱怨几句,回归正题。我觉得不是国人能力不足,是很多做游戏的人就是抱着应付的态度(可能他本人就是想混,可能是被大环境带动的),没有足够的爱。一款游戏是不是用心做的完全可以感觉的出来。我觉得只要稍微用点心的去做都不会只有千篇一律的“打怪”“寻人”。

0

主题

40

帖子

253

积分

中级会员

Rank: 3Rank: 3

积分
253
发表于 2013-8-26 15:05:55 | 显示全部楼层
在怪物死亡时进行回调,检查攻击者Call他们的任务系统,来检查是否完成了某个任务的某个条件。
这句话是否应该理解成,让某人使怪物死亡的事件触发一次对任务系统的检查,有符合的任务条件便进行刷新?
这样的话是否只有在游戏开发早期进行设计才会有效,如果怪物的机制早就确定了这样得设计会带来不小的修改吧。其实最早我向程序提出了这样的设计方案,被程序他们否决掉了。

98

主题

787

帖子

4478

积分

版主

Rank: 7Rank: 7Rank: 7

积分
4478
 楼主| 发表于 2013-8-26 15:20:52 | 显示全部楼层
dpfcz 发表于 2013-8-26 15:05
在怪物死亡时进行回调,检查攻击者Call他们的任务系统,来检查是否完成了某个任务的某个条件。
这句话是否 ...

我觉得……可能这么描述这个流程比较好理解些:
1,怪物死亡,并发出信号给所有符合和怪物接触的人(在WOW中就是击杀怪物的人)。
2,接受到信号的人处理这个信号。
我们用伪代码来进一步说明就是:
怪物mob下有一个列表记录和怪物接触的人(其实在WOW中,一般情况下就1人,一些共享掉落的怪物则会有很长的列表,只要你打了就在列表内,激战2则采用后者,只要你打过就在列表内),这个列表假设为killer:Array<Player>。
那么怪物的die()中就应该有
for (guy in killer){
   guy.increaseQuestFinish(mob.questSign);
}
通过这个发出信号给相关角色,而increaseQuestFinish执行的则是
if (this.currentQuest.exists(sign)){
    .....
}
类似这样的去处理掉这个任务进度的问题。但之前的游戏大多地做法则正好相反——
for (i in 0...guy.quests.length){
  for (j in 0...guy.quests.condition.length){
    ......
  }
}
这样的做法下就存在很严重的效率问题,即使你杀死的是一个根本和任务不相关的怪物,你也要去遍历一次,这就成了"I ask u"了,所以需要"u call me"来提高这件事情的效率,而"u call me"的思想其实并不仅仅用于杀怪,包括比如一个任务让你学蛙跳100次,你可以在每次蛙跳时Call一下,而不是因为任务系统的完成条件中带有蛙跳100次,所以总是在遍历。

这样的设计其实越早提出越好,当然所有的设计都是如此,但是在项目后期,其实要去改进就要看之前的代码构架了,一般来说如果用的是entity system的思路,会非常简单。当然很多时候程序员不乐意改也处于很多其他原因,所以逻辑层一般来说,我们这里策划自己动手。

0

主题

8

帖子

22

积分

注册会员

Rank: 2

积分
22
发表于 2013-8-26 15:39:26 | 显示全部楼层
真不错,赞一个!

0

主题

40

帖子

253

积分

中级会员

Rank: 3Rank: 3

积分
253
发表于 2013-8-26 15:58:06 | 显示全部楼层
猴与花果山 发表于 2013-8-26 15:20
我觉得……可能这么描述这个流程比较好理解些:
1,怪物死亡,并发出信号给所有符合和怪物接触的人(在WO ...

需要一个列表的衔接这样啊,这么说感觉清晰许多。
完善了列表的统计项目应该就可以实现很多类似GW2中的任务了吧。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

GMT+8, 2023-1-30 07:09

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

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