平时游戏运营活动需求，看起来是蛮复杂的。其实本质上任务系统或者成就系统类似。

一般需求像这样：

1. 活动有开始时间和结束时间要求；

2. 活动给出的奖励也有开始时间和结束时间要求；

3. 完成活动需要做完几件事情(我们称作事件或者条件事件)；

4. 相比较任务和成就系统，这种活动条目很少。

分享一下我们的做法：

1. 独立实现一个活动服务器，存储的DB也是独立。这样的好处是，活动服务器和主逻辑服务器的完全分离的，DB数据可以随便清除，非常容易维护。

2. 主逻辑服务器，不断将事件通过网络协议的方式通知活动服务器；

3. 主逻辑服务器，通知事件后，活动服务器将可能返回已完成的活动条目。

主逻辑服务器，没有什么好说的，考虑活动的特点，我们只要无脑地将事件发给活动服务器。

活动服务器实现几个地方稍微讲究一下。

1. 每次收到玩家登录消息时，就将所有未接受的活动项，自动接受下来。这里注意的一点事，即使这个活动开始时间未到，我们也接受下来。

2. 收到事件通知时，要注意一下活动是否已经开始，和活动是否已经结束。1&2这样做的目的是，某个活动的开始的时候，玩家不用重新登录。这个是比较重要体验问题。

3. 完成活动后，给主逻辑服务器发奖励的话，须要判断一下，当前时间是否是奖励发放时间范围内。

举一个实际的例子：

2014.10.1~2014.10.7充值的玩家，在2014.10.5~20.10.7期间，能获得双倍掉落的奖励。

接受时间：2014.10.1~2014.10.7

事件：充值

奖励时间：2014.10.5~20.10.7

奖励内容：双倍掉落

1. 某个玩家登录时，活动服务器生成这个 活动任务 对象；

2. 这个玩家充值的时候，活动服务器收到这个充值事件，只要在2014.10.1~2014.10.7内，就判断该活动是否完成；

3. 玩家登录后，主逻辑服务器发一个空的通知事件，然后就收到双倍奖励内容，后面该干什么就干什么。

这类需求头脑保持清醒，看似眼花缭乱的需求，实现起来非常简洁。

运营活动需求实现