Add config-driven game host updates
This commit is contained in:
@@ -1251,3 +1251,192 @@ GPS：
|
||||
|
||||
- 把已经证明有效的主链打磨稳
|
||||
- 再逐步扩展玩法和能力
|
||||
|
||||
# 21. 今日新增宿主层约定
|
||||
|
||||
今天这批调整的重点，不是新增某一个玩法，而是继续把宿主层的同步与展示链路收干净。它们的价值在于：
|
||||
|
||||
- 不只服务顺序赛或积分赛
|
||||
- 后续新玩法也能直接复用
|
||||
- 让“用户操作”和“程序状态变化”最终都汇到同一条同步链
|
||||
|
||||
## 21.1 配置入口元信息开始进入宿主快照
|
||||
|
||||
远程配置入口目前已经不再只服务地图与路线加载，也开始承载活动级元信息。
|
||||
|
||||
当前 [remoteMapConfig.ts](/D:/dev/cmr-mini/miniprogram/utils/remoteMapConfig.ts) 已经能从配置中解析并标准化这些字段：
|
||||
|
||||
- `app.id`
|
||||
- `app.title`
|
||||
- `schemaVersion`
|
||||
- `version`
|
||||
- `map.*`
|
||||
- `playfield.*`
|
||||
- `game.*`
|
||||
|
||||
其中：
|
||||
|
||||
- `configAppId`
|
||||
- `configSchemaVersion`
|
||||
- `configVersion`
|
||||
|
||||
已经进入 [MapEngine](/D:/dev/cmr-mini/miniprogram/engine/map/mapEngine.ts) 的宿主状态，并可以被上层面板消费。
|
||||
|
||||
这意味着配置入口开始具备“双重职责”：
|
||||
|
||||
- 一方面装配运行所需的地图、路线、玩法参数
|
||||
- 另一方面提供活动本身的识别信息和版本信息
|
||||
|
||||
这一步为后面配置文件完全成为游戏入口打下了基础。
|
||||
|
||||
## 21.2 统一状态提交管线继续强化
|
||||
|
||||
前面已经建立了：
|
||||
|
||||
- `event -> RulePlugin -> GameResult`
|
||||
|
||||
今天继续强化的是：
|
||||
|
||||
- `GameResult -> MapEngine.commitGameResult(...) -> 页面 / telemetry / feedback / renderer`
|
||||
|
||||
这条宿主管线的目标是：
|
||||
|
||||
- 不再靠某个功能里“顺手刷新一下状态”
|
||||
- 而是让所有玩法动作最终都走统一提交
|
||||
|
||||
当前这条统一提交链已经被用于：
|
||||
|
||||
- 开始对局
|
||||
- 打点
|
||||
- 跳点
|
||||
- 积分赛 focus 选点
|
||||
- GPS 更新后的规则推进
|
||||
- 切换配置后的定义加载
|
||||
|
||||
这一步的意义非常大，因为游戏过程中真正需要同步的状态越来越多，例如：
|
||||
|
||||
- 当前目标
|
||||
- 已完成 / 已跳过状态
|
||||
- HUD 文案
|
||||
- 打点与跳点按钮可用性
|
||||
- guidance 音效状态
|
||||
- 地图高亮
|
||||
- telemetry 目标距离
|
||||
- renderer 表现层
|
||||
|
||||
只要这些更新仍然能统一收敛到 `commitGameResult(...)` 这条链上，架构就还是健康的。
|
||||
|
||||
## 21.3 游戏信息面板成为新的宿主诊断出口
|
||||
|
||||
11 号按钮现在不再是临时调试入口，而是一个正式的“游戏信息面板”。
|
||||
|
||||
当前它由 [map.ts](/D:/dev/cmr-mini/miniprogram/pages/map/map.ts) 负责开关，由 [MapEngine](/D:/dev/cmr-mini/miniprogram/engine/map/mapEngine.ts) 提供快照数据，页面层只负责展示。
|
||||
|
||||
面板当前分成两部分：
|
||||
|
||||
- `Local`
|
||||
- `Global`
|
||||
|
||||
其中：
|
||||
|
||||
- `Local` 负责展示本地已知的实时状态
|
||||
- `Global` 目前还是占位，后面联网后再接全局赛事态
|
||||
|
||||
`Local` 当前已经可以展示：
|
||||
|
||||
- 比赛名称
|
||||
- 配置版本
|
||||
- Schema 版本
|
||||
- 活动 ID
|
||||
- 当前玩法
|
||||
- 当前状态
|
||||
- 当前目标
|
||||
- 进度
|
||||
- 分数
|
||||
- 打点与跳点规则
|
||||
- GPS、心率、里程、速度、卡路里等本地信息
|
||||
|
||||
这块的设计原则是：
|
||||
|
||||
- 页面不自己拼业务逻辑
|
||||
- 引擎只提供统一快照
|
||||
- 后面全局数据接入时，继续沿这套面板结构扩展
|
||||
|
||||
## 21.4 侧边按钮体系正式分成两类
|
||||
|
||||
今天还把地图页的侧边按钮体系收了一版，避免后面按钮越来越多后状态逻辑变乱。
|
||||
|
||||
当前已经明确分成两类：
|
||||
|
||||
### A. 三态功能按钮
|
||||
|
||||
适用于：
|
||||
|
||||
- `4 exit`
|
||||
- `11 info`
|
||||
- `16 skip`
|
||||
|
||||
它们统一使用三种状态：
|
||||
|
||||
- `muted`
|
||||
- `default`
|
||||
- `active`
|
||||
|
||||
这些按钮的视觉态不再由模板零散判断，而是由页面层统一派生。
|
||||
|
||||
当前 [map.ts](/D:/dev/cmr-mini/miniprogram/pages/map/map.ts) 中已经有：
|
||||
|
||||
- `SideActionButtonState`
|
||||
- `buildSideButtonState(...)`
|
||||
|
||||
输入的是主状态，例如：
|
||||
|
||||
- `showGameInfoPanel`
|
||||
- `skipButtonEnabled`
|
||||
- `gameSessionStatus`
|
||||
|
||||
输出的是最终按钮态，例如：
|
||||
|
||||
- `sideButton4Class`
|
||||
- `sideButton11Class`
|
||||
- `sideButton16Class`
|
||||
|
||||
这意味着：
|
||||
|
||||
- 有些状态虽然是用户点击触发的
|
||||
- 有些状态虽然是程序运行中更新的
|
||||
- 但最后按钮显示都统一走同一套派生逻辑
|
||||
|
||||
### B. 循环模式按钮
|
||||
|
||||
左上角那个按钮不属于三态功能按钮，而是单独的“模式切换器”。
|
||||
|
||||
当前它根据 `sideButtonMode` 循环切换不同图标：
|
||||
|
||||
- `btn_more1`
|
||||
- `btn_more2`
|
||||
- `btn_more3`
|
||||
|
||||
它的本质是：
|
||||
|
||||
- 点击后切换显示模式
|
||||
- 图标跟随当前模式变化
|
||||
|
||||
而不是普通意义上的启用/禁用/激活按钮
|
||||
|
||||
把这类按钮和普通功能按钮分开，是为了后面继续扩展侧边栏时不把状态语义搅乱。
|
||||
|
||||
## 21.5 当前阶段的判断
|
||||
|
||||
到今天这一步，可以比较明确地说：
|
||||
|
||||
- 统一提交管线已经有雏形
|
||||
- 游戏信息面板已经成为宿主状态对外展示窗口
|
||||
- 侧边按钮体系已经开始统一状态派生
|
||||
|
||||
这三件事都不是只服务某个玩法的补丁，而是在继续把“通用宿主层”做稳。
|
||||
|
||||
当前最重要的不是继续为了理论纯度大拆，而是：
|
||||
|
||||
- 先用这套底座承接后续配置字段和玩法细化
|
||||
- 一旦再次出现“某类状态总是漏同步”的真实问题，再继续沿统一提交链收口
|
||||
|
||||
Reference in New Issue
Block a user