活动系统的类型大概有，运营活动，常规活动，军团活动，开服活动，合服活动，活动是多样性的但又很多相同的地方值得我们抽象，下面来进行具体分析。
一、活动数据存储
没有完整的框架之前，多个同事开发不同活动，往往会自己建立存储空间进行数据的存放和管理；
所以我们需要创造一套数据管理框架，减少这块儿的设计和开发，并定制对应的操作规范。
这套数据结构需要有3个对象池，活动对象，参与者，活动排名：
活动数据表 activity_table : key={server_id,activity_sid}, value=info
活动参与表 activity_join_table : key={role,activity_sid} ; value = info
活动排名表 activity_billboard : key = {server_id,activity_sid}; value = info
有了这3个对象，开发者就可以存放活动级别的数据，相对玩家级别的数据，以及扩展的排名容器的数据，已经基本满足80%的数据管理需求，创造火药的人，不知道后人想要的是炸弹还是烟花。
想一想，如果我们不抽象会怎么样，你需要建立以下可能存在的数据表，并且不断扩张。
报名表、充值达人表，钻石双倍表、夏日福利表、集字活动表、登录送礼表、日历积分表、消费返利表，等。
二、活动推动
根据我们语言特色，一个活动可以以一个进程的形式存在，进程字典维护状态，ets维护过程，定时落地。
1、活动的生命周期大概是这样：
前置状态（可以播放前置预告即将开启），开始状态，结束前置状态（结束预告），奖励结算状态，活动结束，清理数据。
这个设计很简单，定义配置，活动进程根据解析配置进行状态检测和变化（比如：这几个状态下产生的活动公告配置）。
2、玩家参与活动的细节：
参与活动有多样性，进程需要mfa解耦分流到业务模块，每个活动的参与数据不同数据结构初始化就会不同。
3、活动监控
活动会接收各种系统功能消息的消息，用以追踪玩家参与和完成情况。
如果活动业务模块直接接收消息，会造成后续获得业务重复监听的情况，所以我们需要抽象这个观察者。
抽象观察者的时候会发现观察者不只活动系统，还有成就系统，还有任务系统，还有变强推送系统，等。
所以，我们的观察者需要有相同的监听模式或接口，才能同时观察被观察对象的行为，才能实现复用。
现在你需要构建，观察者，被观察，以及被观察者的行为规范。
行为规范将会作为条件被不断组合复用，也可以交策划进行配置。
三、活动奖励
游戏中往往会有一套完整的奖励解析方案，活动可以直接使用，如果没有那也太不专业了。
活动的奖励形式通常有两种，
1、有根据参与情况进行大数据结算；
2、有参与活动会在活动奖励期间上线领取；
3、活动结束过期未兑换的活动物品转化；
在活动奖励的设计上没有技巧的发挥空间，形式不可能抽象，但内容可以配置。
四、活动排名
运营活动基本都会携带一个活动排行榜，可以在游戏的其他通用排行榜中抽象一个活动排行榜；
这个活动排行榜可以和活动自身索引关联并绑定，生命周期保持一致，并在活动框架中提供这个榜的操作接口。
基本就搞定了，但是你要是告诉我游戏中没有通用排行榜的结构，那就无法沟通了。
五、活动配置
活动是开发不完的，一定要把它拆出去，不然会发现你的团队不断有程序掉入坑里捞不起来。
活动配置，主要是用户展现、活动条件、活动奖励上发生变化。
1、用户展现抽象
- 活动基本信息展现（活动标题、活动介绍）
- 活动图标列表、进度条宝箱
- 活动任务展现
- 奖励展现
- 兑换/抽奖展现
这个需要图示，从图示中标记可以替换的地方。
2、活动规则抽象
- 累计充值活动
- 累计消费活动
- 消费返利活动
- 道具收集活动
- 比如兑换道具收集
- 比如技能书章节收集
- 比如武器碎片收集
- 抽奖消耗品收集
- 抽/兑奖类活动
- 参与抽奖的消耗品
- 限时销售活动
3、事件抽象
- 成长类事件配置
- 付费类事件配置
- 战斗类事件配置
这条描述最简单，但实现上比较繁琐。
