數據 成長 系統 ble 推送 減少 結構 活動圖 類型

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

• 成長類事件配置
• 付費類事件配置
• 戰鬥類事件配置

這條描述最簡單，但實現上比較繁瑣。

活動基礎框架設計