AzerothCore学习笔记·数据库10：任务系统——模板表与角色状态

任务系统是 World 库里最复杂的子系统之一。表面上任务就是接任务 → 做任务 → 交任务三步走。但 AzerothCore 背后有一套相当精细的数据设计涉及模板、状态、目标、奖励……每一步都有对应的表在支撑。这篇拆开来聊。两套核心quest_template 与角色任务状态任务系统的核心和物品、怪物一样也是模板与状态的分离。quest_templatequest_template_addon等系列表定义任务的模板——任务要求做什么、给什么奖励、前置条件是什么角色任务状态表character_queststatus系列表记录每个角色每个任务的当前进度这套分离解决了游戏运营中最核心的一个问题同一种任务全球几百万玩家的进度各不相同但任务内容本身是共享的。不需要为每个玩家的每个任务单独存一份完整的任务数据——只需要存角色 X 的任务 Y做到什么程度了。任务内容本身存一份模板全服共享。quest_template任务的内容定义quest_template是任务系统的核心模板表记录一个任务的所有内容定义字段说什么LogTitle/LogDescription任务标题和描述显示给玩家QuestType任务类型击杀型、收集型、对话型……QuestLevel建议等级RequiredNpcOrGo1~4目标 NPC 或游戏对象 ID最多4个RequiredItemCount1~6目标物品数量最多6种物品RequiredSpellCast1~3需要施放的法术某些任务要求先施放技能RewChoiceItemId1~6/RewChoiceItemCount1~6奖励物品选项玩家自选RewItemId1~4/RewItemCount1~4固定奖励物品RewMoneyMaxLevel根据角色等级给予的金币奖励上限一个任务最多支持 4 个目标对象、6 种目标物品、4 种固定奖励、6 种可选奖励——灵活性相当高。quest_template_addon表补充了模板的额外参数字段说什么MaxScalingLevel任务目标的最大缩放等级动态等级任务AllowableClasses/AllowableRaces职业/种族限制RequiredSkillId/RequiredSkillPoints所需技能等级SourceSpellid接任务时自动施放的法术通常是任务给予动画PrevQuestId/NextQuestId任务链的前置和后续BreadcrumbQuestId面包屑任务 ID引导玩家去接任务任务链Quest Chain的衔接靠的就是PrevQuestId和NextQuestId这两个字段。character_queststatus角色任务状态quest_template定义任务做什么character_queststatus系列表记录角色做到了哪一步。AzerothCore 里有 6 张任务状态表按重置周期分表名存什么重置周期character_queststatus基础任务状态不重置一次性任务character_queststatus_daily日常任务状态每日重置character_queststatus_weekly周常任务状态每周重置character_queststatus_monthly月常任务状态每月重置character_queststatus_seasonal节日/季节任务状态特定季节/节日重置character_queststatus_rewarded已领取奖励的任务记录永久保留这是 AzerothCore 里按时间维度拆表拆得最彻底的一组——每个重置周期一张表好处是重置操作只需要清空对应表不需要遍历整张任务状态大表。character_queststatus的核心字段character_guid, quest_id, status, explored, timerstatus任务状态0未接、1进行中、2已完成但未交、3已交领奖explored任务目标区域是否已探索部分任务要求先踩点timer限时任务的剩余时间具体的任务进度击杀了几只怪、收集了几件物品不存在这张表里——存不下那么多字段。这些数据存在别的地方。任务进度的实时记录说到任务进度有个容易忽略的细节AzerothCore 并不在数据库里实时记录当前击杀数。玩家的任务进度击杀怪物数量、收集物品数量主要存在角色属性快照表里——character_stats、character_achievement_progress、character_queststatus的 status 字段共同决定任务是否完成。更准确地说当玩家完成一个目标行为击杀怪物、获得物品服务器收到事件后实时检查相关任务的完成条件是否满足。满足则更新character_queststatus.status为已完成2。数据库里不需要存过程数据——只需要存结果状态。这个设计让任务检查逻辑集中在代码层而不是散落在数据库里优点是灵活缺点是调试困难出了问题不好查数据库。conditions 表与任务系统篇6专门聊过conditions表它在任务系统里扮演了关键角色。conditions表用SourceType1标记任务前置条件支持非常丰富的条件组合等级要求ConditionType1职业要求ConditionType2已完成前置任务ConditionType5声望要求ConditionType8技能等级要求ConditionType29特定物品持有ConditionType37有些任务要求持有某个物品才出现接任务之前玩家先过conditions表的条件检查。没满足条件任务不显示或者点击后提示条件不满足。满足了character_queststatus里新增一条记录任务正式开始。这意味着同一个任务在不同玩家眼里可能存在或不存在——取决于他们的角色状态是否满足条件。条件系统在玩家侧实现了千人千面的任务体验。任务奖励物品、经验、金币、声望quest_template里的奖励字段支撑了 AzerothCore 任务系统的激励层物品奖励4 种固定物品必给 6 种可选物品玩家选 1。可选奖励让玩家在同一任务上有一定自主选择权比如缺钱拿金币、缺装备拿装备。经验奖励早期版本 WoW 经验奖励直接写在quest_template里后来版本改用RewMoneyMaxLevel字段计算——等级越高的角色完成任务获得的金币越多经验相对减少。这是防止高等级玩家刷低等级任务刷金的手段。声望奖励quest_template通过reward_reputation_faction1/2和reward_reputation_rate字段控制任务完成后的声望变化。声望奖励是 WoW 经济系统的重要组成部分——某些阵营的高声望等级有独门配方或专属装备。任务文本的多语言支持quest_template_locale表存储了所有任务文本的多语言版本任务标题、描述、目标描述、完成提示。AzerothCore 在玩家登录时根据客户端语言设置加载对应语言的 locale 数据。quest_template表本身只存 key语言无关的模板数据locale 表存 value具体文本。这套多语言机制和item_template_locale、creature_template_locale是同一套模式——模板不绑定语言语言层独立叠加。任务系统设计的核心思路回头看任务系统的设计思路和其他子系统一脉相承模板与状态分离quest_template存共享内容character_queststatus系列表存个体状态状态按时间维度拆表不同重置周期的任务进不同表清空操作简单条件判断外置化conditions表承担所有任务可见性的判断任务模板本身不需要写条件逻辑奖励机制灵活组合固定奖励 可选奖励 声望 金币多维度激励理解了这套设计再去看 World 库里其他复杂系统——比如成就系统、成就进度系统——会发现它们用的是同一套思路模板定义内容条件控制可见性状态记录个体进度。系列一到这里就收尾了。四个核心库聊完模板模式、实例模式、条件系统、叠加层、状态机……这些反复出现的核心概念贯穿了整个 AzerothCore 的数据设计。系列二将从代码层深入聊这些系统的实现。