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

善与恶

猴与花果山 发表于 2013-8-26 12:41
你不干这行不明白也很正常啊，不过如果你很感兴趣，可以先自学一些或者自己总结一套关于任务系统的设计， ...

嘿嘿~ 俺是个随性之人。

闲云野鹤适合我。按部就班我可受不了。

老孙来也

猴哥，如果更新一个任务配置，就同时更新物品表、任务表、buff表、NPC表，配表压力好大啊，我没理解文章吗？

猴与花果山

老孙来也 发表于 2013-8-26 18:47
猴哥，如果更新一个任务配置，就同时更新物品表、任务表、buff表、NPC表，配表压力好大啊，我没理解文章吗 ...

http://bbs.gameres.com/thread_213225_1_1.html
你可以先看下这个，其实Tag机制的核心意义就是不需要动到很多表，甚至能起到预判断的作用。程序中有一种优化思路叫四叉树，Tag机制可以理解为四叉树林，只要你用起来够Magic的话。
我就举一种Tag机制的灵活运用开拓一下思路好了。
一个怪物击杀的QuestTag（暂且叫这个，反正就是杀死时影响任务变化的），一个火焰歌不林，如果你填写：goblin_humanoids_area03_schoolfire，那么你可以让程序用“_"作为分割标记来看，用伪and运算和任务的条件的tag标志产生关系：
比如有个任务叫消灭火源，他的任务目标是杀死区域内100个带火特性的生物，你只需要把这个条件的Tag定义为schoolfire，那么(schoolfire and goblin_humanoids_area03_schoolfire)肯定是==schoolfire的，两者都有schoolfire，那么这个哥不林就在这个任务的击杀范围内了。
此时你心添加了一个任务叫做屠夫，条件之一是杀死这个区域内的人形生物20个，只需要将这个条件的标志定义为"humanoids"，哥布林一样在范围内。此时你又设计了一个消灭区域3内所有哥布林的任务，它的条件之一是"goblin_area03"，那么这个哥布林仍然是符合范围的，但是另外一个哥布林（goblin_humanoids_schoolwater）就不符合条数少的那个，因为他而事实上你在填哥布林的时候并没有想过有这么多任务。
类似于这样的感觉，之所以说Tag是树林，不是树，因为你还可以利用它的Stirng特性研究出很多很多Magic的用法，其实关键在于怎么用，这个需要一定抽象能力。但是有一点可以肯定——Tag机制可以解决很多需要预先就想好的问题，但是代价是，你要记住自己已经有的分类。
不过这种抽象问题真的很难描述就对了，我只能尽可能的举例以做到尽可能说清楚……

firstfish

猴与花果山 发表于 2013-8-26 12:41
你不干这行不明白也很正常啊，不过如果你很感兴趣，可以先自学一些或者自己总结一套关于任务系统的设计， ...

这话和这例子说的太对了。沉湎于过去的成就或已有的功绩，只会逐渐落后，最后沦为只会“一年经验用了十年”的员工，而不是积累了十年经验的员工。

kk3987986

先问一句，猴子你到底是工作什么的。。
文章内容做为一个非业内人士感觉还有些价值，不过我对你的buff系统一直不是很赞成，因为虽然系统化了但有些内容也复杂化了。一个随使用次数改变对话，直接用一个+1不就好了嘛？

Yuki001

猴子的任务系统说的太好了.这样的机制非常灵活.没什么好挑刺的,只能补充说明下自己的理解了.
前面说的第一点核心思想,"You call me, I don't call you",其实是反向依赖,也就是回调机制.我们可以看下为什么需要用这个机制.就拿任务系统和道具系统的依赖来说

1.理论上,任务系统的判断条件依赖于道具系统中的道具.所以出来的依赖链就是
任务系统 ------- 依赖/检查 ------> 道具系统

2.任务系统对道具系统的依赖细节,更多的集中在onChange之上,而不是在get接口上,而且依赖的很多细节是道具系统的主动接口无法提供的.为了获得灵活和完整的功能,这时候就可以利用onChange的回调机制,将依赖反转
任务系统 <-------- 依赖/onChange回调 ------ 道具系统

3.但是道具系统在逻辑上,是不依赖于任务系统的,所以这个依赖反转需要将中间的依赖过程解耦.所以我们可以引人解耦中间机制
任务系统 --------> 中间机制 <------ 道具系统
解耦的中间机制有很多种,信号机制是一种,事件总线机制也是一种,加入中间层也是一种.一般如果写在代码里面,就会使用简单的信号或者事件机制.如果要支持外界配置.一般会用脚本或者做一个中间层机制.如果做脚本就会比较复杂了.

4.猴子这里选择的中间层系统是Tag机制,这套机制的优点很明显,就是支持使用表格配置,可利用字符串本身来进行逻辑功能.也可利用Tag本身作为变量计数,那结果就是
任务系统 --------> Tag 机制 <------- 道具系统

这样的话,道具系统的实现表中,就会加入一个或者多个Tag字段,标明这个道具的Tag,其中某一个Tag字段的含义是,道具入背包,TagA + 1
然后任务系统,一个任务目标会配几个Tag和对应的参数,例如 TagA,5,TagB,3,那么这个任务的完成条件就是 TagA >=5 and TagB >= 3,在TagA或者TagB改变的时候触发检查.或者直接提升任务进度.

建立了Tag机制之后,很多系统的依赖都可以通过Tag系统做中间层解决,例如任务系统和NPC系统,任务系统和怪物系统,成就系统和道具系统等等.所以猴子说利用Tag机制可以去掉很多表的依赖,做一个功能不需要动太多表.

另外第2点里面的例子,其实也可以通过Tag来做,把Tag看成一个变量,在道具表中配置一个丢弃触发Tag字段,道具丢弃时,TagDec + 1, 任务系统中配置任务失败条件 丢弃TagDec >= 3 判断失败.可以直接通过Tag中间层协调道具和任务系统来完成.不需要通过中间层的Buff系统来计数和执行逻辑.

ayasong

看见好帖都要留名。感谢作者！

pilipala

我宁可用触发器来干
虽然效率低

当然，最好的游戏可能是没有任务的游戏……

沙漏

恕我知识浅显，这里太多英文了，有些真心看不懂……有的倒是明白，爱。。。

meigo

感觉把简单的问题解决方案用复杂的语言表达出来了。