210 lines
4.5 KiB
Markdown
210 lines
4.5 KiB
Markdown
# 临时玩法讨论记录
|
|
|
|
本文档用于临时记录以下讨论内容：
|
|
|
|
- 贪吃蛇式玩法是否适配当前架构
|
|
- 超级玛丽拾金币式玩法是否适配当前架构
|
|
- 这些玩法是否需要大改现有系统
|
|
|
|
当前结论仅用于阶段讨论，不作为正式设计冻结文档。
|
|
|
|
---
|
|
|
|
## 1. 结论
|
|
|
|
当前这两类玩法都适合现有架构。
|
|
|
|
- `贪吃蛇式玩法`：适合
|
|
- `区域拾金币玩法`：适合
|
|
- 二者都不需要推翻现有主架构
|
|
- 主要工作会集中在：
|
|
- 新的 `RulePlugin`
|
|
- 新的 `modeState`
|
|
- 新的 `map/hud presentation`
|
|
- 少量内容模型扩展
|
|
|
|
也就是说，这两类玩法更像是在现有底座上继续长新玩法，而不是重做底层。
|
|
|
|
---
|
|
|
|
## 2. 为什么适合当前架构
|
|
|
|
当前系统已经拆出了以下关键层：
|
|
|
|
- 地图引擎
|
|
- 规则引擎
|
|
- telemetry 信息层
|
|
- map / hud presentation
|
|
- feedback 反馈层
|
|
- 真实 / 模拟传感输入
|
|
|
|
这意味着：
|
|
|
|
- 地图只负责显示和交互能力
|
|
- 规则层只负责玩法推进
|
|
- telemetry 只负责通用过程信息
|
|
- feedback 只负责声音、震动、动效等效果消费
|
|
|
|
因此后续新增玩法，原则上主要是“新增规则和表现”，而不是“重写地图页”。
|
|
|
|
---
|
|
|
|
## 3. 贪吃蛇式玩法分析
|
|
|
|
### 3.1 玩法本质
|
|
|
|
这类玩法通常包含：
|
|
|
|
- 玩家位置持续更新
|
|
- 轨迹形成蛇身
|
|
- 尾巴按规则增长或收缩
|
|
- 撞到自己、奖励点、危险区后触发状态变化
|
|
|
|
### 3.2 适配当前架构的原因
|
|
|
|
当前架构已经具备：
|
|
|
|
- 持续 GPS 输入
|
|
- 持续 telemetry 更新
|
|
- 规则事件驱动推进
|
|
- 地图轨迹绘制能力
|
|
- 统一反馈系统
|
|
|
|
因此它天然可以承载：
|
|
|
|
- 尾巴增长
|
|
- 尾巴裁切
|
|
- 自碰撞
|
|
- 收集奖励
|
|
- 危险区域
|
|
|
|
### 3.3 真正需要新增的内容
|
|
|
|
主要是玩法私有状态，而不是底层推翻：
|
|
|
|
- `snakeBody`
|
|
- `tailLength`
|
|
- `tailWindow`
|
|
- `collisionState`
|
|
- `collectibleState`
|
|
|
|
这些都应放入该玩法自己的 `modeState`。
|
|
|
|
### 3.4 对当前架构的压力点
|
|
|
|
这类玩法会推动当前系统继续增强：
|
|
|
|
- `modeState` 承载更复杂连续状态
|
|
- `MapPresentation` 支持蛇身/危险区/奖励点等更多图元
|
|
- 规则层处理持续碰撞判定
|
|
|
|
但这些属于增强，不属于重构。
|
|
|
|
---
|
|
|
|
## 4. 区域拾金币玩法分析
|
|
|
|
### 4.1 玩法本质
|
|
|
|
这类玩法通常包含：
|
|
|
|
- 玩家在某片区域内自由移动
|
|
- 经过或进入范围后收集金币
|
|
- 有时间限制、连击或区域目标
|
|
- 可附带终点或出口点
|
|
|
|
### 4.2 适配当前架构的原因
|
|
|
|
它本质上非常接近：
|
|
|
|
- 自由收集
|
|
- 多目标高亮
|
|
- 局部 HUD 提示
|
|
|
|
而这些当前在 `score-o` 里已经有相当基础。
|
|
|
|
因此它可以看作：
|
|
|
|
- `score-o` 的泛化版
|
|
- 或“自由收集类玩法”的一个子类
|
|
|
|
### 4.3 真正需要新增的内容
|
|
|
|
这类玩法一般需要：
|
|
|
|
- 新点位类型：`coin / pickup / bonus`
|
|
- 新 HUD 信息：已收集数、剩余金币、区域完成度
|
|
- 新表现：金币图标、收集动效、区域边界
|
|
|
|
### 4.4 对当前架构的压力点
|
|
|
|
这类玩法比蛇尾玩法对底座压力更小。
|
|
|
|
它主要会推动：
|
|
|
|
- 内容模型从“控制点”继续泛化
|
|
- `MapPresentation` 支持更多点位类型
|
|
- HUD 能容纳玩法专属信息
|
|
|
|
但依然不需要大改主架构。
|
|
|
|
---
|
|
|
|
## 5. 需要补强的底座点
|
|
|
|
如果未来真的开发这两类玩法，最值得继续补强的是：
|
|
|
|
- 更明确的 `modeState` 规范
|
|
- 更强的 `MapPresentation`
|
|
- 更通用的内容模型
|
|
- 更清晰的玩法事件字典
|
|
|
|
建议后续逐步支持的通用对象类型：
|
|
|
|
- `control`
|
|
- `collectible`
|
|
- `bonus`
|
|
- `hazard`
|
|
- `trigger`
|
|
- `zone`
|
|
- `exit`
|
|
|
|
建议后续逐步支持的通用事件：
|
|
|
|
- `item_collected`
|
|
- `zone_entered`
|
|
- `zone_left`
|
|
- `self_collision`
|
|
- `combo_started`
|
|
- `combo_broken`
|
|
- `area_cleared`
|
|
|
|
---
|
|
|
|
## 6. 当前判断标准
|
|
|
|
如果未来实现这些玩法时出现以下现象，说明架构边界可能需要重审：
|
|
|
|
- 必须大改 `MapEngine`
|
|
- 必须大改 `TelemetryRuntime`
|
|
- 必须让渲染器自己猜玩法规则
|
|
- 必须把玩法私有状态塞进全局 telemetry
|
|
|
|
如果没有出现这些情况，而主要只是新增：
|
|
|
|
- `RulePlugin`
|
|
- `modeState`
|
|
- `presentation`
|
|
- `feedback`
|
|
|
|
那就说明当前架构是适配的。
|
|
|
|
---
|
|
|
|
## 7. 当前阶段总判断
|
|
|
|
结论可以总结成一句话：
|
|
|
|
当前这套架构不仅适合传统定向和积分赛，也适合继续承载更游戏化的运动玩法。
|
|
像贪吃蛇式玩法和区域拾金币玩法，都更像是“新增玩法插件”，而不是“推翻现有底座”。
|