活动基础框架设计

Posted 2020-10-13

活动系统的类型大概有，运营活动，常规活动，军团活动，开服活动，合服活动，活动是多样性的但又很多相同的地方值得我们抽象，下面来进行具体分析。

 

一、活动数据存储

没有完整的框架之前，多个同事开发不同活动，往往会自己建立存储空间进行数据的存放和管理；

所以我们需要创造一套数据管理框架，减少这块儿的设计和开发，并定制对应的操作规范。

这套数据结构需要有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、事件抽象

• 成长类事件配置
• 付费类事件配置
• 战斗类事件配置

这条描述最简单，但实现上比较繁琐。