temp-gameplay-discussion.md 4.5 KB
临时玩法讨论记录
本文档用于临时记录以下讨论内容：
- 贪吃蛇式玩法是否适配当前架构
- 超级玛丽拾金币式玩法是否适配当前架构
- 这些玩法是否需要大改现有系统
当前结论仅用于阶段讨论，不作为正式设计冻结文档。
1. 结论
当前这两类玩法都适合现有架构。
贪吃蛇式玩法：适合区域拾金币玩法：适合- 二者都不需要推翻现有主架构
- 主要工作会集中在：
- 新的
RulePlugin - 新的
modeState - 新的
map/hud presentation - 少量内容模型扩展
- 新的
也就是说，这两类玩法更像是在现有底座上继续长新玩法，而不是重做底层。
2. 为什么适合当前架构
当前系统已经拆出了以下关键层：
- 地图引擎
- 规则引擎
- telemetry 信息层
- map / hud presentation
- feedback 反馈层
- 真实 / 模拟传感输入
这意味着：
- 地图只负责显示和交互能力
- 规则层只负责玩法推进
- telemetry 只负责通用过程信息
- feedback 只负责声音、震动、动效等效果消费
因此后续新增玩法，原则上主要是“新增规则和表现”，而不是“重写地图页”。
3. 贪吃蛇式玩法分析
3.1 玩法本质
这类玩法通常包含：
- 玩家位置持续更新
- 轨迹形成蛇身
- 尾巴按规则增长或收缩
- 撞到自己、奖励点、危险区后触发状态变化
3.2 适配当前架构的原因
当前架构已经具备：
- 持续 GPS 输入
- 持续 telemetry 更新
- 规则事件驱动推进
- 地图轨迹绘制能力
- 统一反馈系统
因此它天然可以承载：
- 尾巴增长
- 尾巴裁切
- 自碰撞
- 收集奖励
- 危险区域
3.3 真正需要新增的内容
主要是玩法私有状态，而不是底层推翻：
snakeBodytailLengthtailWindowcollisionStatecollectibleState
这些都应放入该玩法自己的 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 - 更通用的内容模型
- 更清晰的玩法事件字典
建议后续逐步支持的通用对象类型：
controlcollectiblebonushazardtriggerzoneexit
建议后续逐步支持的通用事件：
item_collectedzone_enteredzone_leftself_collisioncombo_startedcombo_brokenarea_cleared
6. 当前判断标准
如果未来实现这些玩法时出现以下现象，说明架构边界可能需要重审：
- 必须大改
MapEngine - 必须大改
TelemetryRuntime - 必须让渲染器自己猜玩法规则
- 必须把玩法私有状态塞进全局 telemetry
如果没有出现这些情况，而主要只是新增：
RulePluginmodeStatepresentationfeedback
那就说明当前架构是适配的。
7. 当前阶段总判断
结论可以总结成一句话：
当前这套架构不仅适合传统定向和积分赛，也适合继续承载更游戏化的运动玩法。
像贪吃蛇式玩法和区域拾金币玩法，都更像是“新增玩法插件”，而不是“推翻现有底座”。