游戏开发：基础模块之活动系统设计方案

• 写一写游戏项目的基础模块的实现思路，之活动系统：

活动系统通常结合充值构建项目的商业化节奏，系统的设计方案：

定义不同类型用于区分活动，定义不同ID用于唯一标识一期特定类型的活动；

1. 排期配置管理

每个玩家节点开启单例的活动排期管理服务（activity_manager），负责管理活动排期相关的数据；

活动排期源数据通过配置和中央数据后台获取，由服务负责维护更新，对玩家提供查询获取接口；

schedule_cache = {
  activity_type = {
    activity_id = {
      bt,
      et,
      version,
    },
    ...
  },
  ...
}

---@description 重新构建排期缓存。缓存服务启动时构建，当配置更新时通知重新构建
local function onload(raw_schedule) end
---@description 获取当前进行中的活动排期信息
function getActInfo() end

玩家登录和跨天会请求服务获取最新的排期信息，与本地活动数据做校验，对应增删改活动；

btw，活动管理服务不单独进程的原因：

1）避免跨进程调用；玩家的代理服务跟活动管理应该是同生共死的，避免处理不可靠通信的复杂问题；

2）优化并发问题；单点服务总是需要考虑服务过载的问题；（量级：在线玩家数量（不可控） ==> 单台user承载的agent数量（可控））

优化设计：

排期热更问题：排期配置热更新完成需要触发服务内的缓存重新构建（可能有各种反查表），构建缓存可能有时序要求，时序问题可能造成缓存数据失效；

优化方案：sharetable支持预定义反查表；

2. 活动逻辑模块设计

玩家代理服务中：

设计玩家活动管理模块：

local activity_mgr = {}

-- 获取排期配置对本地活动做更新
function activity_mgr.check_update() end

-- 删除活动
function activity_mgr.delete_activity(type) end
-- 新增活动
function activity_mgr.accept_activity(type) end

-- 创建活动类型对象
function activity_mgr.new_activity_object(type) end

-- 充值接入
function activity_mgr.oncharge_finish(type) end

抽象活动基类，基于活动类型设计活动模版；

-- 一个通用的活动模块包括：管理接口、数据管理接口、充值接入

local activity_base = { type }

-- 增
function activity_base:can_accept() end
function activity_base:pre_accept() end
function activity_base:accept() end
-- 删
function activity_base:can_delete() end
function activity_base:pre_delete() end
function activity_base:delete() end
-- 改
function activity_base:onupdate() end -- virtual func
function activity_base:update() end

-- 数据管理
function activity_base:new_activity_data(schedule) end
function activity_base:del_activity_data() end
function activity_base:get_extra_data() end -- custom data
function activity_base:sync_activity_data()
  
-- 充值接入
function activity_base:create_charge_order(productId) end
function activity_base:oncharge_finish() end