客户端程序员视角下的任务系统设计

核心目标：设计稳定、高效、可维护的任务系统，确保数据规则与逻辑意图能够准确传播给所有协作者

一、什么是任务

广义理解

游戏是对世界的抽象，任务就是这个抽象世界里玩家出生、成长、发挥影响力过程中一个又一个的普世目标和存在意义。

• 一方面，玩家不得不完成它
• 另一方面，玩家完成它又会获得这个抽象世界的普世认可

狭义理解（RPG游戏）

RPG游戏是一个故事，任务就是故事中一条或多条故事线上的（时间、事件、状态）节点，用于：

• 驱动故事发展
• 记录玩家历程

任务系统的核心功能

基于从业经验归纳，任务系统本身及相关联系统对任务提出的核心要求：

二、任务的逻辑分类

基于当前游戏任务系统，从逻辑层面归纳以下分类：

分类说明

三、任务系统的关联系统

以下系统直接或间接与任务系统有关联：

关联系统详解

四、遇到的问题与困难

4.1 潜规则（最致命问题）

"来吧老哥，先这么搞，你加个默认规则不就行了么！"

"改一个字段不是还要全部刷数据么，单独加个判断特殊处理一下！"

"先跑起来！"

典型案例：任务目标显示规则

早期实现：

问题演化：

1. 早期只有 3-4 条目标类型
2. 项目发展后膨胀到 8-9 条目标类型
3. 需要自定义格式化字符串
4. 默认规则 + 自定义逻辑并行运行

最终爆发：

打包前夜报错 → 默认显示规则引用怪物包数据 → 怪物包没有名字定义 → 进不去游戏

根本原因：

• 怪物配置升级为怪物包配置时，使用自定义格式未暴露问题
• 使用默认规则时触发空引用错误

💡 教训：如果开始就按照最原子的逻辑实现，返工与Bug会少很多。

4.2 空白逻辑持续发挥余热

现象

• 2017年9月编写的逻辑，2019年4月仍未使用
• 大量空白字段被所有任务携带，但只有极个别任务使用

具体例子

带来的问题

1. 占用屏幕空间 - 打开配置表需要不断按右方向键寻找关键列
2. 代码冗余 - 仅接取条件判断就写了 200+ 行
3. 空引用错误 - 老数据缺少新条件项
4. Debug困难 - 配置同学、程序同学信息不完整

4.3 完全手动的跨表引用

典型案例：提交任务配置

任务配置表
    ↓ 配置完成提交NPC
提交服务配置
    ↓ 加到NPC服务组件
NPC服务组件
    ↓ 填到NPC表
NPC表

以上步骤缺一不可，否则分分钟报错。

高耦合问题

文本信息跨表混乱

风险：某系统元素改名 → 显示问题或额外工作量

4.4 导出数据与数据源不一致

分类一：导出落后于Excel

现象：游戏内表现与期望不一致，Excel数据源没问题，但导出数据有差别

多发场景：多人合作中，某人修改内容未及时同步导出数据

直接影响：打包节点报错，需等下一个包才能继续工作

分类二：数据结构演化未全刷表

原因：最后修改数据结构的同学对全刷表正确性没信心

背景： - 几千条数据 - 数个同学在一两个月版本迭代中陆续增删改 - 部分数据因功能、测试环境等改变而无效/过期

风险： - 承担巨大核对工作量 - 或承担出包后数据错误的责任风险

集合对应不合理

缺失：数据源中缺乏数据类别管理，导出数据没有一对一映射方式

4.5 链式依赖

典型案例

任务A完成条件 → 依赖成就B达成
成就B达成条件 → 依赖任务C/D/E/F...完成

难点

如何显示任务A的进度？

4.6 任务的多个接取时机

被动条件（轮询）

触发方式：NPC携带任务，玩家交互时轮询

主动触发

组合问题

案例：进入区域 + 只有夜晚才能接取

问题场景： 1. 玩家白天进入区域 2. 挂机等到晚上 3. 原本被动的接取条件需要考虑主动触发

风险：放开任意组合，补丁逻辑将非常复杂

4.7 断线以后的连续性

问题场景

任务完成条件：观看指定动画

正常流程：

进入区域 → 接取任务 → 播放动画 → 动画完成 → 完成任务

断线后问题： - 任务已在玩家身上 → 不会播放接取动画 - 没播放指定动画 → 无法完成需要观看动画的任务

死循环

解决方案

进入区域 → 接取任务
离开地图 → 放弃任务
任务接取 → 播放动画 → 动画完成 → 完成任务

原理： - 掉线 = 离开地图 → 放弃任务 - 上线 = 首次进入区域 → 重新接取 → 完整播放动画

遗留问题： - 其他控制动画的逻辑（区域） - 断线后的位置同步问题 - 逻辑冲突

五、优化设计方案

5.1 任务状态与转移条件

状态定义

状态说明

状态转移触发机制

注：省略"任务更新"时机，改为监听各个"条件更新"

5.2 任务之间的组织关系

树形结构

树形结构的优势

注意事项

• 需要完善的配表工具
• 否则配置相对吃力

5.3 条件系统设计

当前系统的条件数量

⚠️ 这些类型在可预见的将来还会不可控制地迅速膨胀

条件抽象方案对比

推荐方案：条件配置表 + 逻辑表达式

设计思路：

// 任务数据
{
    "2001": {
        "accept_condition": "(010001 and 010002) or 010003",
        "complete_condition": "xxxxxx"
    }
}

// 条件数据
{
    "010001": {"type": 1, "param_1": 10},
    "010002": {"type": 2, "param_1": 11, "param_2": 7},
    "010003": {"type": 0, "param_1": 5, "param_2": 1010101}
}

解析方式：

class Condition {
    virtual bool Match(param);
};

class AND : public Condition {
    virtual bool Match(param) {
        return left.Match(param) && right.Match(param);
    }
};

// 解析表达式树
Condition* condition = Parse("(010001 and 010002) or 010003");
if (condition->Match(param)) {
    // 状态转移
}

客户端与服务器的不对称性

示例：

"010004": {
    "type": 0,
    "param_1": 5,
    "param_2": 1010101,
    "ignore": "0x06"  // 服务器和客户端都忽略
}

5.4 条件的检查方式

检查方式对比

当前系统的检查方式分布

⚠️ 警告：混乱地不加定义地使用不同检查方式，会遇到解决不完的问题

5.5 条件计数（执行进度）

计数数据的存在位置

设计建议

• 明确定义哪些条件需要服务器计数
• 哪些条件客户端可以本地处理
• 状态变化可与其他类型条件复用

5.6 状态切换时的行为

建议整合的行为

整合发奖逻辑的优势

1. 逻辑表达更顺畅
2. 避免程序开天窗写特例
3. 支持任务分支逻辑 - 完成后走分支A - 失败后走分支B

5.7 相似功能的整合

对话系统

当前问题：

建议方案：

核心思想：

• 任务是玩家游戏进程的条件与状态转移链
• 对话引用玩家任务的完成状态
• 避免逻辑与表现混在一起

成就系统

当前问题：

• 成就与任务双向关联
• "完成任务A,B,C...时完成成就D"
• "完成成就D时完成任务E"
• 车轱辘逻辑，程序开天窗打补丁

建议方案：

成就是一系列特殊的任务：

显示：只是状态的包装，不应与逻辑冲突

动画播放

建议：归纳到任务状态切换时的行为

• 特定时间
• 特定区域
• 播放行为
• 包括动画完成传送等功能

断线问题：通过粒度更小的任务逻辑节点，保存动画播放进度

5.8 任务的显示与包装

任务标签（Tag）

设计目的：解决"它是什么也是什么"的多维度分类问题

{
    "id": 2001,
    "tag": ["Secondary", "Story", "Visable", "Night"],
    "comment": "玩家看得见的夜间才能完成的支线剧情任务"
},
{
    "id": 2002,
    "tag": ["Trophy", "Stage1"],
    "comment": "玩家在阶段1的成就任务"
}

对比：

剧情信息

建议：任务不应包含显示文本信息

进度文本与导航

当前配置问题：

{
    "id": 2001,
    "commit_npc": 10000,
    "commit_info": {"pos": "x,y,z", "map_id": 11},
    "commit_comment": "balabala",
    "complete_condition": [
        {
            "target_comment": "balabala",
            "target_param_xxx": 1,
            "target_info": {"pos": "x,y,z", "map_id": 11, ...}
        }
    ]
}

理想配置：

{
    "id": 2001,
    "comment": "balabala",
    "map_id": 11,
    "pos": "x,y,z",
    "npc_ids": [10001]
}

优势：

• 导航配置可给其他系统使用（资源收集导航）
• 通过任务树包装表现任务

六、总结

6.1 核心优化方向

6.2 关键原则

6.3 关于数据与视图

真实存储的数据与看到的数据不一定一致

• 数据库：3范式下的无冗余关系表
• 终端用户（策划）：关联过的视图表
• 进一步拓展：针对不同策划角色的专用视图
• 剧情策划：条件、文本、导航、奖励、父子节点
• 成就策划：简单条件与初始化接取
• 关卡策划：动画播放与进度记录时机