活動系統的類型大概有，運營活動，常規活動，軍團活動，開服活動，合服活動，活動是多樣性的但又很多相同的地方值得我們抽象，下面來進行具體分析。
一、活動數據存儲
沒有完整的框架之前，多個同事開發不同活動，往往會自己建立存儲空間進行數據的存放和管理；
所以我們需要創造一套數據管理框架，減少這塊兒的設計和開發，並定製對應的操作規範。
這套數據結構需要有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、事件抽象
- 成長類事件配置
- 付費類事件配置
- 戰鬥類事件配置
這條描述最簡單，但實現上比較繁瑣。
