深入游戏任务系统细节

之前的任务系统篇，感觉还缺了点什么，是的，亿点点细节，策划们花样繁多的任务条件设计，后端程序在实现的时候，真的是有非常多要注意的地方，一不小心就是一个BUG。
为了凸显任务系统的细节，需要一些具体详细的任务用做范例。

上需求

• 成就任务

任务1条件	任务2条件	任务3条件
累计消耗10k金币	累计消耗100k金币	累计消耗1000k金币
当前拥有10件装备	当前拥有20件装备	当前拥有30件装备
强化1件稀有装备到20级	强化2件稀有装备到20级	强化5件稀有装备到20级
收集10种不同的家具	收集20种不同的家具	收集30种不同的家具
3星通关副本10次	3星通关副本20次	3星通关副本30次

• 每日任务

任务条件
强化2次装备
商店消费2次
队伍中包含至少2个战士角色通关任意困难副本3次

需求分析

在需求分析之前，我们需要默念后端心法：数据量越少越好，计算量越少越好。
成就任务一眼看去数量多，而且很多是相同性质，一个系列的任务，并且一个系列的任务并不需要同时显示。我们并不需要一次性创建好所有成就任务的数据，保证数据尽量晚创建，对于一个系列的任务，未完成的只需保留一条数据，已完成并且已经领取奖励的，最多保留一条数据，未领取奖励的任务需要全部保留。任务进度依次继承。这样同时存在的成就任务的数据量就可以接受了。
每日任务，每天更新，数量一般固定，在数据量上无需优化。
计算量上如何优化？任务系统一般会涉及到游戏的方方面面，每个子系统的任务触发条件一定会有所重合，我们把所有的任务，集中起来，在同一个接口中一起触发。
一起触发有如下好处：

1. 性能好，在任务系统庞大，数量多时，集中触发能将性能影响降到最低
2. 单元测试只需详尽测试 触发任务的接口，更加稳定。如果分开多个接口触发，对于抽卡，关卡胜利等涉及多方面的业务中，可能会由于任务触发出现bug导致各种问题。
3. 扩展性好，新增一种类型的任务，会很容易集成进来，写业务可以非常快速的完成，节约开发时间。

一起触发 对任务id有一些要求

1. 最好所有任务的id都不重复
2. 如果任务id有重复，那么需要在触发列表中额外存储任务类型字段

不同类型的任务在触发时，计算量也有区别。比如 “当前拥有10件装备” 这个成就任务，当装备可以分解，数量在业务上有可能减少时，我们需要遍历统计当前的所有装备数量，明显是O(n)算法了。所以我们需要警惕 当前拥有 这种语义的任务，尽量让策划少配置，或者转换为累计型任务。

任务细节

1. 强化装备到x级，当装备可以一次性升级n次，n>1时，我们传入的触发数据需要包含升级前的等级old_lv和升级后的等级new_lv
2. 收集x件不同家具，注意不同这个语义，在触发统计时，需要小心区分
3. 累计消耗x金币，注意累计消耗语义，是从接取任务时开始计算，接取任务前的累计都不计算在内。
4. 当前拥有x件装备，当前拥有 这个语义，需要重点注意，不仅计算量大，而且在策划新增任务时，为了规避累计语义对玩家造成的误解，策划一般会优先使用。
5. 队伍中包含至少2个战士角色通关，注意包含语义，包含语义在定义数据结构时，和其他条件不太一样，在配置表中需要额外支持。

支持策划新增任务

策划在配置表中新增任务时，如何自动检测并接取？我目前的做法是，玩家登陆时遍历一遍所有任务，如果有已解锁未接取任务，判定为新增任务并自动接取。这里要遍历一遍配置表的所有任务，耗时较长，暂时没有好的优化方案。

总结

1. 所有任务集中触发，设立触发列表，加载所有已接取未完成任务。
2. 玩家数据量越少越好，任务数据尽量晚创建
3. 触发计算量越少越好，引导策划少配置统计型任务
4. 支持策划在配置表中新增任务
5. 支持继承前置任务进度