在网路游戏中做任务已经成为游戏很重要的一个核心功能和玩法，如何做好一个灵活可扩展的任务系统的架构与设计，今天来给大家分享一些我们的设计经验。接下来我把整个的任务系统分成以下6个模块:
任务配置表设计与管理;
游戏任务的解锁与生成;
任务完成判定;
任务完成后的奖励生成;
奖励的领取;
客户端的界面展示;
对于单机游戏而言，这6个模块都放在客户端直接处理，对于网路游戏而言，模块1~5实现在服务端，模块6实现在客户端。
任务配置表设计与管理
任务配置表主要是给策划来编辑游戏任务的具体内容,同时程序根据策划编辑的任务配置来生成游戏的任务,获取任务描述, 获取奖励描述, 任务完成判定，游戏奖励领取。对于程序而言，要充分的调研游戏任务系统的功能需求，并设计出管理代码+策划编辑游戏任务的工作方式。我们拿一个比较通用的任务配置表的需求来进行分析，将一个任务配置设计下列字段:
任务ID：唯一代表该任务类型的ID号;
任务解锁的条件: 解锁该任务的条件(这里有N种完全不同的规则)
任务的文字描述: 描述改任务的内容，主要用于客户端UI界面的显示;
任务完成达成的条件: 完成该任务要达成的条件(这里有N种不同的规则);
任务完成获得的奖励: 完成该任务可获的奖励(这里有N种不同的奖励规则);
任务奖励描述: 完成任务后可获得哪些奖励的文字描述，主要用户客户端UI展示;任务解锁条件，任务达成条件，任务奖励，不同任务都有不同的规则，那么这个如何设计呢？这里就需要充分的调查任务系统的需求,然后总结出规则，做一个规则描述表给策划，方便策划填写数据，同时方便程序按照规则解析条件表达式，例如解锁任务A，需要达到10等级。解锁任务B，需要收集10张卡, 这里解锁任务就有2种不同的规则，就需要定规则给策划填写,给程序解析，就可以生成一个这样的解锁条件表:
解锁方式ID 解锁条件描述, 解锁参数解析模板,如
10000 策划填写ulevel=10, 达到等级10后解锁, type=10000, ulevel=%d
20000 策划填写cards=10, 收集10张卡后解锁, type=20000, ucards = %d
…在策划的任务配置表里面就可以按照这个规则来填写，程序根据type类型来对应解析规则，解析解锁条件。如下:
任务ID 任务解锁条件 任务文字描述 任务完成条件, 达成奖励
10001 type=10000,ulevel=10 挖10个宝石, …
10002 type=10000,ulevel=20 挖10个水晶, …
10003 type=10000,uelvel=30 挖10个金币, …
20001 type=20000,ucards=10 合成初级战衣 …
20002 type=20000,ucards=20 合成中级战衣 …任务完成条件与达成奖励条件也可以按照解锁条件类似的方式来编写和制定规则。所以这里在设计的时候一定要充分的调研任务系统的需求,程序根据type类型来解析规则的参数获得对应的条件规则。
游戏任务的解锁与生成
任务配置表的设计完成后，策划就会给游戏编辑好任务配置表，在游戏运行中要给每个玩家来解锁对应的任务并生成任务，这个时候还需要有一个玩家任务表，这个表描述了所有玩家的所有任务，这个表的设计如下:
ID: 任务的唯一ID号
uid: 这个任务对应的玩家ID号
tid: 标识玩家正在进行的任务，根据tid可在任务配置表里面找到对应的任务和描述;
status: 当前任务的状态:
未解锁【0】
已解锁,待执行【1】
进行中【2】
已结束【3】
奖励未领取【4】
奖励已领取【5】
例如:
ID uid tid status
玩家A 10001 1
玩家B 10001 1
玩家C 20001 2
…玩家任务表定义好后，任务系统监听与任务解锁触发相关的游戏事件,比如玩家升级了,升级的同时通过事件订阅模块抛出一个事件出来，任务系统监听到这个事件后根据事件类型,玩家的游戏数据，以及策划编辑的任务配置表看是否有新任务被触发解锁(根据解锁规则表里面配置的判定)，如果有，就往任务表里面插入一条记录，这样该玩家解锁了某个任务。当玩家打开任务列表的时候，就从这个表里面检索出来属于这个玩家的所有正在进行中的任务。
任务进行中与任务完成判定
玩家解锁了任务以后，在任务表里面就有这个玩家所对应的任务记录了,状态也改成了正在进行中，当玩家触发一个游戏事件后抛出一个事件，任务系统监听对任务判定有影响的事件。当有这样的事件抛出后，就去看下是哪个玩家触发的，然后根据任务配置表中任务的完成判断条件规则进行判断，如果条件成立,修改任务的状态。
任务完成后的奖励生成
达到任务的判定条件后, 如果这个任务的类型是有奖励的，这个时候根据任务类型的描述配置表的奖励规则来生成对应的奖励。任务配置表里面有奖励的类型，以及奖励的数据，程序根据奖励规则表中奖励的类型来解析对应的奖励数据生成奖励。如果是直接给奖励，根据任务的奖励内容给玩家的数据加上对应的奖励即可，并通知前端来播放奖励动画。并标记任务已完成。如果奖励需要玩家自己去领取，可以将任务的状态改成”奖励未领取”,这样玩家拉去任务列表的时候，就可以根据这个”奖励未领取”状态来显示还有奖励可以领取,客户端显示领取按钮。
奖励的领取
奖励分为直接奖励与玩家主动领取的奖励，这个根据游戏的需求来就可以了，对于任务系统而言，如果是直接奖励，那么直接给玩家加上对应的数据属性就可以了，比如奖励金币，奖励宝石等，奖励的时候可以通知客户端，这样客户端可以播放一个奖励动画出来让玩家知道自己获得了奖励，如果奖励需要玩家主动领取，当玩家拉取任务列表的时候，可以根据任务的状态”奖励未领取”，把没有领取奖励的任务拉去下来，并展示一个”领取”按钮。当玩家点击领取的时候，服务器根据任务ID来获取任务数据，检查任务的状态是否为”奖励未领取”，如果是，再获取任务的ID号，根据任务的ID号获取具体的奖励数值，给对应的数值加上对应的奖励,并修改任务的状态未奖励已领取，并通知客户端展示动画。
客户端的界面展示
任务系统的后台逻辑设计好了以后，剩下的就是任务系统的界面展示。客户端登录以后向服务器拉取这个玩家的所有任务,一般状态包含”已解锁待执行”,”正在进行中”与”奖励未领取”的任务。拉取下来，客户端显示的时候还需要显示任务的描述和奖励描述等，所以需要把策划的任务配置表从服务端拉取下来，或者通过资源更新的方式来更新下来,这样我们就能根据任务的tid来从描述表里面获取任务描述与奖励描述，这样客户端就完整的展现出任务来了。当有”领取奖励”，”领取任务”按钮的时候，通过向服务端发送对应的请求来做对应的处理，服务端来更新任务的状态即可。
以上就从6个维度详细的描述了一个大型网络游戏的任务系统应该如何设计，关注我可以学习到更多的大型网路游戏的架构与设计相关知识分享。
