魔兽服务端任务定制教程

      游戏剧情是由一个个任务衔接起来的，正如一串项链是由一颗颗珍珠串联而来，基础的自制任务其实通过数据库的操作就能完成，下面将通过一个示例展示这篇基础教程：需要软件：
数据库工具：Navicat 8或Truice或HeidiSQL（觉得哪个好用就用哪个）
本示例使用的工具是Navicat 8，基本方法是在N8里把quest_template表的字段值填好，当然也可以找一个相似的任务复制再修改，然后导出sql语句。
下面举例说明
拿自制的任务链“无法摆脱的梦魇”里的两个任务为例：

修改涉及到的表和字段值的释义：
quest_template –任务主体部分
creature_questrelation –给任务的npc相关
creature_involvedrelation –还任务的npc相关

重点说quest_template表：
任务“洛塔米诺斯的报答”：
ID=20038，不重复就行；
Method=2，这是个普通任务；
Level=82，影响任务经验奖励，人物满级后经验奖励换算金钱奖励。不是很重要，填82为了显得任务够难；
MinLevel=80，人物80级才能接；
ZoneOrSort=-4999，这是啥意思呢，看看quest_template里的负数对应QuestSort.dbc，-4999就是“巫妖王的陨落”，这个是我自己定义的；
Type=21，对应QuestInfo.dbc，21就是“传记”，会显示在任务列表中任务名称的后边；
RequiredClasses=384，字面意思是需求职业，对应ChrClasses.dbc，但这里可不是对应的ID，还要看ChrClasses.dbc。查一下发现原来真正的值是2^(ID-1)，384=2^(8-1)+2^(9-1)，所以是法师(8)和术士(9)的意思；
RequiredMinRepFaction=1098，是接受任务所需的最小阵营声望，对应Faction.dbc，1098就是黑锋骑士团啦；
RequiredMinRepValue=42000，就是上边阵营的声望值，42000就是崇拜；

以上三个字段合起来决定这个任务需要一个法师或者术士在黑锋骑士团崇拜之后才能看到接任务的感叹号。

PrevQuestId=20037，前置任务的ID，不做前边的任务就接不到这个任务；
NextQuestId，后续任务的ID，我这里没填，因为后续任务是一个对话直接完成的任务。也可填负值。
NextQuestIdChain，后续任务的ID，当前任务完成时后续任务的任务文本自动弹出。这里也没填，原因同上。还要注意，当前任务的交还人和后续任务的给予人不是一个人时会导致还任务时任务文本不自动关闭；
RewardXPId=7，对应QuestXp.dbc，任务等级82对应的横轴等于7的值才是经验值，就是28150；
Title=”洛塔米诺斯的报答”，任务名称；
Objectives=’击败辛达苟萨，拿她的肋骨给洛塔米诺斯。’，任务目标，显示在任务文本下方；
Details=’英雄，感谢你让玛伊得到安息，不幸中的万幸……’，任务文本，开展剧情的部分，这里可以自由发挥；
OfferRewardText=’请稍等，英雄，我马上为你制作必要的材料。’，任务完成时的文本；
RequestItemsText=’辛达苟萨的力量很强，要小心。’，没完成任务时和NPC对话的文本；
CompletedText=’带着辛达苟萨的肋骨去找洛塔米诺斯。’，任务完成时，在任务跟踪界面显示的提示信息；
RequiredItemId1=80110，任务需要的第一个物品的唯一标识，对应item_template表的entry。80110是我自制的物品“辛达苟萨的肋骨”；
RequiredItemCount1=1，任务需要的第一个物品的数量；

到这里为止，一个有前置任务，有人物等级、职业、某阵营声望值要求的，需求某物品的，只有经验奖励的任务主体就制作完了。

为啥不是任务而是任务主体呢，因为一个完整的任务需要给予者和交还者，也就是下边的语句：

这两张表的结构完全一样，id字段是npc唯一标识，对应creature_template的entry；quest字段就是任务的唯一标识，对应quest_template的id。

至此，一个由NPC给予，交还给NPC的完整任务才制作完成。
如果任务的给予者或交还者不是NPC，而是一个告示牌或者一个墓碑，那么就需要如下的表：
Gameobject_questrelation –给任务的对象相关
Gameobject_involvedrelation –还任务的对象相关
表结构和上边的两张表也是一样的。

任务的给予者可能是一个物品（item），那就需要在item_template表的startquest字段来指定quest的id了。
然后在creature_involvedrelation或Gameobject_involvedrelation表中指定交还者。

再说说后一个任务“死亡深处”:

能够看到有不少参数和前面那个任务一样，那我们就说不一样的：
ID=20039，这个必须不一样；
PrevQuestId=20038，说明不完成20038就看不到这个任务；
Flags=65536，标记，所有的核心表（quest_template,item_template,creature_template,gameobject_template等）都有的字段，很重要。65536就是对话直接完成的任务。
对于直接完成的任务，需要worldserver.conf中的Quests.IgnoreAutoComplete = 0来配合，如果Quests.IgnoreAutoComplete = 1，则所有此类任务都无法完成。
Flags紧接着还有个SpecialFlags，也很重要，比如重复任务要填1
RewardItemId1=80115，任务奖励的第一个物品。此处80115是我自制的物品“洛塔米诺斯的礼物”；
RewardItemCount1=1，任务奖励的第一个物品的数量。
Title=”死亡深处”，任务名称；
Objectives=’NULL’，任务目标为空，因为是对话直接完成的任务嘛；
Details=’NULL’，任务文本为空，原因同上；
OfferRewardText=’可以了英雄，现在离法杖的诞生只差一步之遥。$B$B去尽情的杀戮堡垒中的亡灵天灾…..’，对于对话直接完成的任务，这里可以看成是Details，这里就自己写剧情吧
RequestItemsText=’NULL’，为空，因为是对话直接完成的任务；
CompletedText=’NULL’，为空，原因同上。
RequiredItemId1为空，原因同上；
RequiredItemCount1为空，原因同上；

至此，一个有前置任务，对话直接完成，有人物等级、职业、某阵营声望值要求的，奖励经验、物品的任务主体就制作完成了。

可能存在的问题：
看完了以上这些，大家可以开始尝试制作任务了，但是不是严格按照以上来做就一定没问题？
并不是，我们还要考虑npc的阵营。比如联盟部落都能接的任务，npc就需要是中立的，或者对双方都是友善的。还有前边提到了Flags这个字段，我们碰到的大部分问题都是由它引起的。对于给予者或交还者是NPC的任务，必须涉及到creature_template表；是游戏对象的任务，必须涉及到gameobject_template表。这两张表都有自己的Flag字段，决定了这个NPC或游戏对象能否接任务和还任务。
举个例子：
我制作的两个位于冰冠堡垒的收集任务，任务给予人和交还人就是灰烬审判军和银色北伐军的军需官，脚本中有这么一句：

37687和38858就是两个军需官的唯一标识啦，取自creature_template表的entry。
看一看端自带的原版数据库就能知道，这俩NPC的npcflag=4224，在creature_template这个表里。
是不是有点头大，其实我们用到的不多，4224=4096+128，也就是说他们俩修装备+卖东西。
我在这个基础上加了3，就是让他们也能接任务、还任务，能对话。
可能有同学问了，接任务、还任务加2就够了，为啥还要加1能对话？
因为我实测的时候发现，由于这俩个npc的任务是重复任务，只加2的话，任务会覆盖掉交易界面，导致npc只能还任务了。再加1就会出现选择交易和任务的选择界面了。

对于阵营来说，Faction字段对应了Faction.dbc，规则上挺绕，我也没仔细研究。我觉得最快捷的方法就是找一个符合要求的NPC，抄他的Faction的值过来就行了。

最后：
以上这些就是用数据库制作任务最基本的内容，如果想让任务更有代入感、更有游戏性的话，就需要研究一下更多的细节了。比如与npc或游戏对象的互动，你给一块儿石头施加个魔法（RequiredSpellCast），NPC给你敬个礼（DetailsEmote），还有SmartAI触发等等，这些都是制作优秀任务不可或缺的部分。但这些怎么用、什么时候用，归根结底就是四个字，剧情需要。一切都是为剧情服务的，什么技巧都不用也可能是好任务，这就取决于剧情的整体构思和设计了。