游戏后台任务系统

前言：进入游戏首先看到的是新手引导任务。本篇就任务系统做一下总结，简述一下任务系统的设计。
一般而言，任务都是由行为事件触发机制，再借助条件系统判断来实现的，今天只聊聊任务本身。

设计目标

从功能看任务有新手引导任务，主支线任务，日常任务，成就任务，活动任务，团队任务这几种。不同的任务类型在实现上会有不小的差别，这个后面再讲。
任务系统的设计目标，主要是需要达到高效的获取任务进度的变化，任务完成及奖励的发放，任务的更新，消息的推送。

配置

任务一般会有接取条件，完成条件，完成奖励，周期性配置（比如日常），有些甚至还会有完成后行为，不一而足。
常见的配表方式有两种，一种是一个任务总表包罗万象，所有的配置项在一张表里展现。优点是表结构高度统一，缺点则是表格可读性差，格式存在冗余；还有一种是分模块使用不同的表格配置，服务器需要将不同的表结构读入，解析代码会多一点。我比较倾向第二种，互不干扰。

流程

角色发起或者系统接取任务后，由玩家行为或者系统事件触发一个行为，这个行为可能会造成任务进度增加或者任务直接完成。
任务进度增加或者任务完成时，通知客户端做展现。

数据部分：
最基本的任务数据包含任务ID、状态、进度。
同时，为了高效的处理事件系统传递过来的事件，还需要一个任务类型到已接取任务的映射关系map<cond_type, quest_list>。
特别
1 主支线任务的数量会非常大，如果达到K级别，使用任务ID来存储已完成的任务状态的话，会带来非常大的内存开销，这时可以使用bit位来记录已完成的主支线任务，而使用任务ID来记录进行中的任务。
2 固定周期的任务（比如日常，周常）不需要额外的记录，只需要固定时间的时候清理任务状态即可，而对于活动任务，则建议记录开始时间而非轮次，这是因为活动的周期可能并不是固定的，也许产品会做一些调整，可能会带来轮次的错乱，从而意外的重置了任务状态。

逻辑部分：
任务接取时，各任务模块注册任务到任务中心，当事件系统产生条件事件时，到任务中心查找对应的条件类型的任务列表，进行对应的操作。对于直接检查状态的任务，获取最新状态，与任务进度比对，如果有差异，则更新进度；对于任务开启计数的任务，则直接对进度进行更新。
进度如果产生变化，首先通知前端，然后继续判断是否达到目标值。
如果进度达到目标值，则修改任务状态，通知客户端，并从任务中心取消注册。如果有后处理逻辑（比如任务链），需要继续检查是否需要接取后置任务。
其他定时逻辑，任务的超时失败逻辑，周期性任务的接取和重置。

消息交互部分：
一般任务的数据量都是比较大的，登录时可以延迟发送任务详情数据，或者通过客户端主动拉取的方式来进行。
此外，一般任务的变化都是跟随在其他用户行为后面，为了降低客户端处理消息的压力，建议使用增量更新方式，只更新必须的、变化的数据。

特别：
对于周期性开启的任务，开启事件由系统发动，如果此时去开启角色的任务，会造成非常大的性能压力，并且此时可能角色并未加载。为了解决这个问题，建议做法是系统层面只进行标记或者状态的生成，而任务的触发接取等到实际角色加载的时候进行。