Evilom
6.3 KiB
6.3 KiB
RBrcwhIgeiZJGukUxf0c8MXXnSf
Source: https://my.feishu.cn/wiki/RBrcwhIgeiZJGukUxf0c8MXXnSf
今日内容概述：
1. IAA 系统策划推进
2. 《元素合成守卫》系统设计与技术基线
一、IAA 系统策划推进
核心问题 调研重点
- 系统策划案进度推进从 4/20 继续到 20/20。
- 形成了多窗口并行的协作心得：
- 主窗口先压缩上下文，再开启多个子窗口继承。
- 每个子窗口必须明确“自己是谁、负责什么、不能改什么”。
- 子窗口按策划内容分组，一个窗口对应一个组，减少互相污染。
- 子窗口完成后及时关闭，主窗口负责汇总和更新索引。
- 明确了 concept(概念) 阶段的节奏判断：
- 先并行推进，再收敛成可交付策划案。
- 资源与工程准备也被纳入推进范围：
- 配合运维搭建 git 工程。
- 补齐对 Claude Code / Game Studio 的"文档驱动流程"的理解。
二、《元素合成守卫》系统设计与技术基线
1. 系统设计进度
定位 把 MVP 阶段的主要玩法系统继续整理、补齐和确认，推动方案从“分散草案”走向“整体可评审、可继续落地”的状态。
（1）已覆盖内容
- 元素守卫数据和配置
- 战场格子与路径
- 局内节奏
- 经济掉落和平衡
- 生命与漏怪
- 元素获取
- 元素合成
- 敌人波次
- 守卫放置
- 拖拽和触屏操作
- 伤害与状态效果
- 自动战斗
- 传奇种子引导
- 传奇融合
- 激励广告
- 动态压力与保底
- 主动技能
- 战斗界面反馈
- 音效、特效、镜头表现
- 结算与留存
（2）整体审查
完成了一轮跨系统检查，主要确认：
- 各系统之间有没有互相冲突
- 核心玩法链路是否完整
- 哪些系统边界还需要后续再收紧
- 哪些风险可以先接受，留到正式评审时处理 阶段性判断 当前设计可以继续往技术落地推进，但仍有几个提醒项需要后续跟进。
2. 关键架构决定
产品形态 围绕玩法系统的运行方式和数据边界，补齐了几份关键 ADR(架构决策记录)，作为后续实现时的统一规则。
（1）场景和模块怎么启动、怎么结束
规定游戏启动时谁先起来、各模块怎么拿到依赖、退出时怎么清理，避免以后系统乱接、乱找节点。
（2）系统之间怎么传消息
规定优先用清晰的信号连接来传事件，不搞一个到处都能发消息的大总线，避免后期排查困难。
（3）配置数据和运行时数据怎么分开
规定配置文件只读，真正局内变化的数据要复制出来单独管理，避免一场战斗里的改动污染基础配置。
（4）地图格子、占位和路径谁说了算
规定格子、占位、路径判断由统一服务负责，放置守卫和敌人移动都不能各算各的，保证结果稳定可复现。 判断 这些决定已经同步到架构登记表里，后续写代码时要按这些规则来。
3. 测试基础
整体链路 今天也推进了技术环境准备，为后续正式写功能代码建立最小测试骨架。 核心价值
- 建立了测试说明文档
- 建立了测试目录结构
- 准备了一个命令行跑测试的脚本
- 加了一个最小示例测试 第一个示例测试主要验证：复制出来的数据不会因为原始数据后续变化而被影响，对应前面的“配置数据和运行时数据要分开”的架构决定。
4. 当前风险与提醒
参考地址 本轮审查里发现的主要提醒项： 观察
- 传奇种子和传奇融合的边界还要再明确
- 广告奖励和经济系统之间的职责还要再收紧
- 音效、特效、镜头表现还需要结合性能预算继续确认
- 结算与留存里有些偏后期的内容需要控制范围 这意味着 当前可以继续推进，但后续正式评审时要重点看这些边界问题。 判断 本地还没有真正装好并启用测试工具，当前命令行环境里也还不能直接调用 Godot；需要等项目文件和测试插件就位后，才能真正跑测试。
三、方法论与流程沉淀
1. 概念阶段推进心得
定位 把这轮策划推进过程中沉淀出的协作方法固定下来，方便后续继续并行工作。
（1）多窗口协作
结果
- 主窗口先压缩上下文，再开多个继承窗口。
- 每个子窗口都要有明确身份和职责。
- 主窗口负责分组、协调、同步索引。
- 子窗口之间尽量避免互相污染。
- 完成后及时关闭，保持上下文干净。 结论 多窗口并行是 concept(概念) 阶段提效的关键手段，前提是分工、继承和同步规则足够清楚。
2. 文档驱动流程
产品形态 已经开始理解 Claude Code / Game Studio 风格的文档驱动流程，包括：
- GDD(game design document游戏设计文档) 驱动设计：每个机制都有独立设计文档
- ADR(架构决策记录) 驱动技术决策：重大技术选择写入架构记录
- 阶段门检查：通过正式评审再推进
- 生产状态文件：用于跨会话持续上下文
- 测试证据驱动完成：用验证结果确认完成状态
- 协作协议：Question -> Options -> Decision -> Draft -> Approval 判断 这套流程的核心价值是先把问题和边界说清楚，再进入实现，不让实现提前吞掉设计判断。
四、后续拟重点调研的开源通用 AI 编程助手
说明 本次两份草稿里没有新增具体的开源工具名单，先保留为后续调研位。 后续拟重点观察对象
- 支持多窗口协同的助手形态
- 支持文档驱动流程的工具链
- 支持测试和验证闭环的编程助手 后续比较维度
- 是否适合 concept 阶段快速并行推进
- 是否方便承接 GDD / ADR / 测试证据链
- 是否能帮助快速否定 demo 或收敛方案
五、下一步工作思考
后续推进方向
- 先把 Godot 项目和测试工具跑通，再继续往实际开发推进。
- 跑通第一个示例测试，确认测试环境可用。
- 在 demo 制作中, 确保代码是可以通过后续迭代正常上线的。