Evilom
129 lines
6.3 KiB
Markdown
129 lines
6.3 KiB
Markdown
# 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 制作中, 确保代码是可以通过后续迭代正常上线的。 |