Files
dc-docs/output/feishu-docs/URutwqGDMibG2ekxaVxc0wn3nRe.md
T
2026-06-23 14:43:31 +08:00

122 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# URutwqGDMibG2ekxaVxc0wn3nRe
Source: https://my.feishu.cn/wiki/URutwqGDMibG2ekxaVxc0wn3nRe
#### **今日内容概述:**
今天主要围绕两条线展开:
##### 1. 继续从 Block Blast 反推创意验证机制
重点理解其如何通过统一北极星指标、假设驱动实验、AI 模拟器和失败知识沉淀,把大量不确定创意转化为可筛选、可比较、可学习的实验样本。
##### 2. 将“元素合成守卫”从初始玩法想法推进到可验证样本方向
通过 Claude Code 脑暴流程与 DeepSeek 扮演 IAA 游戏制作人角色配合,把“收集元素 → 合成变强 → 布阵防守 → 针对波次做策略调整”的粗想法,推进为首发设计、视觉方向、灰盒验证路线和项目内 GDD 体系。
整体上,今天的重点不是确认某个最终方案,而是进一步验证一个判断:AI 对我们的价值不应只停留在生成文本或提高单点效率,而应被用于压缩“创意直觉 → 可讨论方案 → 可验证样本”之间的距离。
## 一、从 Block Blast 看到的创意验证机制
**核心问题**
#### 创意自由如何避免方向失控
Block Blast 的团队机制值得关注的一点是,它并不是依赖少数核心策划提前判断什么一定正确,而是允许团队成员像产品经理一样提出想法。
这种机制能够成立,前提不是“所有想法都值得做”,而是团队有足够清晰的筛选与验证框架。大量想法可以被快速放入实验系统中接受检验,而不是停留在主观争论里。
#### 快速试错如何变成认知积累
Block Blast 的高成功率并不来自少犯错,而是来自让错误更便宜、更可复盘。大量实验失败后,如果只被遗忘,那失败仍然只是成本;如果记录原始假设、实验数据和事后分析,就能形成负面知识库。
这对超导体小组很关键。我们如果要跑很多低成本创意样本,就不能只保留成功案例,也需要把失败样本、否定原因和意外信号结构化保存。
**调研重点**
- 统一北极星指标:长期留存和健康游戏时长,尤其是 30 日留存,作为判断创意价值的核心坐标。
- 假设驱动:每个实验在启动前都需要说明影响的用户行为、验证指标、成功标准、失败标准和护栏指标。
- 失败沉淀:把无效路径、局部有效观察和非直观副作用沉淀下来,避免团队在下一轮重复试错。
## 二、Block AI Robot 的本质:把玩法试错变成可模拟问题
### 1. 虚拟玩家系统
**定位**
Block AI Robot 更像一个高保真的玩家行为预测引擎,而不是单纯追求最优解或最高分的游戏 AI。
#### (1)学习真实玩家行为
**结果**
它基于大量真实玩家行为数据,包括棋盘状态、方块组合、历史操作、失败节点、观看激励视频时机和完整会话路径,训练模型去预测玩家在不同局面下的选择、犹豫、受挫、继续或流失。
**结论**
游戏设计里真正难预测的,不是某个规则在数学上是否成立,而是玩家是否觉得有希望、有压力、有挫败感,以及是否愿意再来一局。
#### (2)真人 A/B 前的低成本筛选
**结果**
对于方块生成逻辑、难度曲线、失败率控制等核心玩法改动,可以先让虚拟玩家在沙盒环境中跑大量模拟对局,观察实验组和对照组在游戏时长、通过率、失败分布和激励视频触发等指标上的差异。
**阶段性判断**
AI 模拟不能替代最终验证,但可以减少明显错误方案直接暴露给真实用户的概率,也能提前发现非直观副作用。例如,一个看似降低失败率的改动,可能反而让玩家因为挑战不足而更快无聊。
### 2. 对超导体小组的启发
**产品形态**
当前阶段不一定需要立刻自研复杂模拟系统,但可以先用 AI 扮演不同角色,对玩法假设进行多轮质询、推演和筛选。
#### (1)短期:多角色 AI 质询
让 Claude Code 负责流程推进、问题拆解和结构化沉淀;让 DeepSeek 扮演带有明确产品偏好的 IAA 制作人角色,在关键选择上做取舍。
#### (2)长期:形成样本测试与负面知识库
如果持续做 IAA 游戏样本,就需要逐渐积累自己的测试脚本、模拟流程、验证记录和负面知识库,而不是每次都从零开始依赖主观判断。
**判断**
Block AI Robot 背后的关键不是“有一个很强的 AI 工具”,而是团队把玩法设计中的一部分不确定性,转化成了可计算、可模拟、可比较的问题。
## 三、当天实践:Claude Code 脑暴 + DeepSeek 制作人角色
### 1. “元素合成守卫”核心玩法收束
**产品地址**
当前主要沉淀在本地设计文档和 Godot 项目 GDD(游戏驱动文档) 中,尚未形成正式可试玩版本。
**试玩感受**
目前仍处于设计文档和灰盒规划阶段,MVP 还没形成。
#### (1)核心循环
**角色说明**
初始玩法被概括为四个核心动作:
一句话概括为:
收集元素 → 合成变强 → 布阵防守 → 针对波次做策略调整。
#### (2)首发方向
**判断**
玩法方向最终收束为“合成变强爽感”为主,辅以“日常小爽 + 终极爆点”的双层成长体系。
首发版重点验证:
- 5 分钟甜点、3 分钟钩子、7 分钟上限;
- 半自动操作:战斗自动,合成和放置由玩家控制;
- 线性升级 1→2→3→4;
- 传奇融合 火4 + 风4 + 传奇火种 = 炎龙守卫;
- 主动技能、系统托底、可选广告救急三层压力缓冲;
- 传奇火种获取漏斗、结算特写、下一局目标引导。
#### (3)首发与后续边界
**结论**
首发优先验证“合成爽感 + 传奇爆点 + 可控压力 + 变现点”,后续再扩展分享、更多词条、动态难度勋章、多传奇路线等内容。
已形成的文档包括:
- 元素合成守卫-首发设计文档.md
- 元素合成守卫-后续增强功能清单.md
- 元素合成守卫画面风格设计文档与实施计划
### 2. 画面风格与地图路线说明
**核心路线**
画面风格方向确定为“高饱和新国风幻想”:新国风五行符阵作为局内底盘,山海神兽作为传奇爆点;视觉情绪酷燃,交互表达极简。
**特点**
- 宣传片和爆点瞬间要服务“酷燃新国风”;
- 实际游玩要优先保证极简、清晰、买量效率;
- 首发 MVP 不应被正式美术拖慢,应先用颜色、数字、方块、圆形等占位资源跑通核心玩法。
**判断**
视觉方向已经较清晰,但当前最重要的是进入灰盒验证,而不是继续打磨视觉文档。
### 3. 战场路线与生产成本说明
**主要定位**
今天生成并整理了场景路线、塔位和怪物路径的 HTML 示意图,用于表达半环形路线、阵眼塔位、中央传奇阵心等布局概念。
**优势来源**
通过地图讨论,初步发现低成本地图生产公式:地图可拆为“可操作底色层 + 怪物路线层 + 边界遮罩层 + 少量塔位标记”。后续可以通过模板化方式降低多关卡生产成本。
**局限**
阵眼式软格子的表现优于硬格子,但如果每关都手工设计阵眼和路线,后续关卡生产成本会升高。因此需要尽早考虑模板化方案。
对竖屏合成塔防的路线判断是:不建议纯左到右,而应采用整体从上到下推进、局部横向蛇形路线,以兼顾竖屏空间利用和左右向角色素材复用。
### 4. Game Studios 项目推进
**观察**
今天完成 Claude-Code-Game-Studios 的初步上手流程,配置 Godot 4.6、GDScript、移动端 iOS/Android、Touch-first 输入和 Lean review mode。
随后将外部《元素合成守卫》设计文档整理进项目 GDD 体系,创建:
- design/gdd/game-concept.md
- design/gdd/systems-index.md
- design/gdd/element-guard-data-config-system.md
- design/gdd/battlefield-grid-path-system.md
- design/gdd/in-run-timing-system.md
**这意味着**
从概念导入到系统 GDD 的工作流已经初步跑通,证明外部设计文档可以逐步转化为项目内系统清单和可实现设计文档, 目前进度5/24。
**判断**
虽然 GDD 推进有效,但距离“可直接试玩”还需要进入 Godot 具体实现,包括场景、拖拽合成、怪物路线、塔位、攻击、波次、胜负条件等。
## 四、阶段性结论
### 1. AI 脑暴的价值不在于一次生成完美方案
**结论**
AI 更适合承担“把想法推到可讨论状态”的工作,而不是直接替代制作人给出最终答案。
一个初始想法如果只停留在一句话,很难判断是否有潜力;经过多轮追问后,它会逐渐暴露核心爽点、目标用户、变现方式、关卡节奏、失败风险和验证重点。此时人再介入判断,会比一开始凭直觉讨论更有效。
### 2. 多模型协作可以模拟轻量团队讨论
**结论**
Claude Code 和 DeepSeek 的组合,本质上是在模拟一个小型团队:一个负责流程和追问,一个负责产品判断和取舍。
这种方式对当前三人小组有现实价值。我们不可能为每个早期想法都组织完整评审,但可以用 AI 先跑一轮“虚拟评审”,把明显薄弱的问题提前暴露出来。
## 五、AI使用小技巧
**主要内容**
- 在claude code里的会话, 让他根据时间段来生成一份总结, 用于完善日报, 已形成skill, 方便后续复用
- 因为这次让AI做的工程比较大, AI在中间有很多追问不是我想关注的, 所以采用了 claude -c --dangerously-skip-permissions 的方式启动claude, 然后运行最新版本claude的功能 "/goal 一直批准写入,直到mvp可以试玩" 的方式来让claude跑今晚一整晚
## 六、下一步工作
**后续推进方向**
不继续扩写文档,先在 Godot 项目中实现第一张竖屏灰盒战场:上入口、纵向蛇形路线、两侧塔位、底部基地或合成区。
包括怪物沿路线移动、基地扣血、固定塔位放置守卫、守卫自动攻击、元素生成、同元素同等级合成、1 到 4 级成长差异、简单波次压力、灰盒版传奇融合与大范围清场。