AzerothCore学习笔记·数据库06：conditions表——万能胶水串联逻辑

《道德经》里写“道生一一生二二生三三生万物。”conditions表就是这样一张表——十几个字段却把游戏里几乎所有条件判断收纳了进去。接任务要看前置任务买东西有等级要求进副本有完成进度限制……这些原本散落在几十个系统里的条件逻辑被它统一成了几种可组合的类型。这篇专门聊它。先看表结构conditions表只有十几个字段字段说什么SourceTypeOrReferenceId这个条件挂在谁身上任务物品NPCSourceGroup分组 IDSourceEntry具体条目 IDConditionTypeOrReference条件类型声望等级完成任务ConditionValue1~ConditionValue4条件参数NegativeCondition是否取反ErrorType/ErrorTextId条件不满足时给玩家的提示ScriptName数据表达不了时挂一段脚本两个核心字段SourceTypeOrReferenceId决定这个条件挂在什么身上SourceType挂在哪里典型场景1任务接任务的前置条件2对话某个选项只对特定种族显示3物品使用物品需要特定等级4法术施法需要特定条件5地图进入地图的条件14成就成就完成条件ConditionTypeOrReference决定判断什么ConditionType判断什么典型参数1玩家等级最小/最大等级2玩家职业职业掩码5已完成任务任务 ID8声望等级阵营 ID 最低声望29技能等级技能 ID 最小等级每种条件类型的 Value1~4 含义不同类型8声望时 Value1 是阵营ID类型1等级时 Value1 是最小等级。字段含义是动态的。一个具体例子假设有一个任务要求玩家等级 ≥ 20已完成前置任务ID132声望达到尊敬声望等级 4with 阵营ID72在conditions表里是三条记录都指向同一个任务IDSourceType1, SourceEntry133, ConditionType1, Value120, Value2255 SourceType1, SourceEntry133, ConditionType5, Value1132 SourceType1, SourceEntry133, ConditionType8, Value172, Value24三条是与的关系——全部满足条件才通过。有一条不满足任务 NPC 的对话框里不会出现这个任务ErrorTextId指向的提示文字会告诉玩家哪里不满足。为什么叫万能胶水没有这张表时任务系统要写一套条件判断等级、前置、声望物品系统要写一套使用条件、职业限制对话系统再写一套……代码里到处是重复的 if 判断。有了conditions表之后所有系统共用同一套读取逻辑——过滤SourceTypeX AND SourceEntry具体ID的记录用 ConditionType 判断满足什么条件。新增一种条件类型只需要加一个 ConditionType 定义所有系统自动支持。这就是万能胶水它不绑定任何特定业务任何表、任何记录都可以挂条件。代价可读性conditions表的代价很明显数据可读性极差。看一行数据光看字段值完全读不懂——必须结合代码里的 SourceType 和 ConditionType 常量定义才能还原出业务语义。这也是为什么 AzerothCore 的 dbdocs 系统对这张表格外重要。这个问题的根源在于通用设计牺牲了可读性。conditions 表的设计者选择了让所有系统共用同一张表代价是这这张表本身失去了具体的业务语义——它变成了一套条件 DSL需要查文档才能读懂。这在软件设计里是常见的权衡通用性和可读性往往不能兼得。条件判断 行为脚本conditions表负责能不能做smart_scripts表篇3 提过负责做了之后发生什么。两个表配合撑起了 AzerothCore 里绝大部分的游戏逻辑——这也是为什么 AzerothCore 里写 C 代码的机会不多大部分逻辑用这两张表就能配出来。条件判断和游戏行为两套数据驱动系统相互配合构成了 AzerothCore 的核心逻辑层。这套逻辑同样体现在 AzerothCore 的节日活动系统里——game_event系列表用叠加层的思路在不改任何基础数据的前提下让节日活动结束后世界自动恢复原状。