Evilom
2.7 KiB
2.7 KiB
UvZwwsHu5iXkShkNBMacFTrOnEf
Source: https://ocnmca6f1o0p.feishu.cn/wiki/UvZwwsHu5iXkShkNBMacFTrOnEf
工作内容概述
1、完成昨天想法的原型设计
今日核心
将昨日游戏设计从概念阶段推向可工程化阶段。不再依赖“边做边想”的感性堆砌，而是跑通了产品定位、系统拆解、单系统设计、最小原型验证的开发流程。
一、 边界锁定与系统工程拆解
明确产品边界
锁定“做什么”与“不做什么”
- 产品侧文档：锁定核心用户画像、单局 5 分钟的地铁通勤形态、核心情感体验。
- 工程侧文档：明确数据驱动的数值架构、硬性机制规约。
最小验证Demo
目前最小验证Demo规划共 24 个系统，今日已完成 6 个核心地基系统的设计（进度 25%）。后续 18 个系统将完全复用此底层路径。
- 第一层：底层基础设施
- 测试基础设施：规范后续每个模块的测试数据交付与自动化验证路径。
- 配置加载器：实现全量平衡数值与核心代码的彻底解耦。
- 核心概念规约：全局对齐服务于 5 大产品支柱的底层逻辑。
- 第二层：核心玩法骨架
- 战斗状态机：规范“备战阶段”与“战斗阶段”的切换契约与数据清理。
- 网格系统：定义 10×20 离散网格的格子语义、碰撞与建造判定。
- 打击感反馈库：统一暴击、屏幕震动、慢动作等表现层的特效应答入口。
二、 研发节奏复盘与关键判断
原型验证：用“假设破灭”精准定位问题
- 现象：傍晚最简原型跑出了“纯建塔就能赢”的失败信号。
- 对策：因前期已在文档中卡死“造路与拖延流”的差异化卖点，团队能够立刻判断这是核心机制失败，而非数值平衡问题。直接定向修复机制，避免了反复盲目调数值的返工成本。
独立开发工程化的 4 条避坑结论
- 不做清单比要做清单更能防膨胀：只要提案违反事先定义的“产品支柱、预算、承诺”，直接一票否决，无需每次重复讨论。
- 地基系统必须严格串行：配置加载器等底层没定死前，上层系统绝不开工。看似慢其实能省掉后期各系统数值各行其是的灾难性重构。
- 原型的目的是暴露问题，而非证明可行：最简原型的 5 个核心假设中当场失效 2 个。这种早期的“破灭”是最高效的排雷。
- 审稿是隐性判断的外化：通过创意总监审稿，逼着把“感觉这样好”的拍脑袋决定，翻译成可讨论的逻辑规则，沉淀为团队的长期研发资产。