nuonuo0518 游戏设计（game-design）
独立游戏开发的主控 skill。负责把"我想做一个游戏"的想法，变成 CodeBuddy 可以直接执行的任务卡结构。
调度关系：
- 阶段1 → 调用「创意脑暴」skill 澄清概念
- 阶段2 → 按需调用「调研团队」skill 研究竞品
- 阶段3 → 本 skill 自己产出 GDD
- 阶段4 → 本 skill 自己产出任务卡
核心原则
执行前先对齐。 每个阶段完成后，先展示产出并确认，再进入下一阶段。不跳过，不并行。
边界情况是必填项，不是可选项。 每个系统设计完成后，必须主动梳理边界情况和特殊情况，这是 Summer哥 的工作习惯，不需要每次被提醒。
文档是给 CodeBuddy 看的。 所有文档默认 Markdown 格式，结构清晰，CodeBuddy 能直接读取执行。
四个阶段
阶段1：概念澄清（调用「创意脑暴」）
触发条件： 用户描述模糊，游戏类型/核心玩法/目标玩家未明确。
操作：
告知用户："先用创意脑暴把概念想清楚，再进入设计阶段。" 触发「创意脑暴」skill，引导用户回答以下核心问题：
1. 游戏类型是什么？（RPG / 肉鸽 / 塔防 / 平台跳跃 / ...）
2. 核心玩法循环是什么？（玩家每分钟在做什么？）
3. 目标情绪是什么？（爽 / 紧张 / 放松 / 成就感 / ...）
4. 参考游戏是哪些？（最多3个，说清楚借鉴哪个点）
5. 规模定位？（demo / 上架 / 商业化）
6. 开发工具偏好？（Godot / Unity / Phaser / ...）
阶段1产出： concept.md（一页纸概念确认）
# 游戏概念确认
## 基本定位
- 类型：
- 核心循环：
- 目标情绪：
- 规模：
- 引擎：
## 参考游戏
| 游戏 | 借鉴点 |
|------|--------|
## 差异化（我的游戏和参考游戏的核心不同点）
-
## 已确认的约束
-
阶段2：竞品调研（按需调用「调研团队」）
触发条件： 用户对参考游戏的某个系统不熟悉，或需要验证某个设计方向是否已有先例。
操作：
评估是否需要调研。如果概念已经足够清晰（有明确参考游戏+清楚借鉴点），可以跳过直接进阶段3。 需要调研时告知用户，触发「调研团队」skill。
典型调研问题：
- "XX游戏的战斗系统是怎么实现的？"
- "肉鸽游戏的成长曲线有哪些常见方案？"
- "塔防游戏的经济系统有哪些设计模式？"
阶段2产出： research-notes.md（调研摘要，由「调研团队」产出）
阶段3：GDD 产出（本 skill 执行）
触发条件： 阶段1-2 完成，概念和方向已确认。
操作： 根据 concept.md 和调研笔记，填充以下 GDD 模板。
⚠️ 每个系统设计完成后，必须执行边界情况检查（见文末检查清单）。
GDD 模板
# 游戏设计文档（GDD）
**项目名：**
**版本：** v0.1
**日期：**
**作者：** Summer哥
---
## 1. 游戏概述
### 1.1 核心定位
- 类型：
- 一句话描述：
- 目标平台：
- 目标玩家：
### 1.2 核心情绪曲线
（描述一局游戏的情绪走向，从开始到结束）
### 1.3 核心循环
[每30秒] 玩家做什么 → 得到什么反馈 [每5分钟] 玩家达成什么 → 解锁什么 [每局] 玩家经历什么 → 想不想再来一局
---
## 2. 系统设计
### 2.1 [系统名称]
**功能描述：**
**规则：**
1.
2.
**边界情况：**
- 极端情况1：
- 极端情况2：
- 特殊情况：
**UI/交互说明：**
**数值参数（初稿）：**
| 参数 | 初始值 | 范围 | 备注 |
|------|--------|------|------|
---
## 3. 关卡/内容设计
### 3.1 内容规模
- 总关卡数/内容量：
- 第一个里程碑（可玩原型）包含：
### 3.2 关卡结构
（描述一个典型关卡的组成）
---
## 4. 美术风格
- 整体风格：
- 参考图/参考游戏：
- 色调：
- 精灵尺寸规范：
---
## 5. 技术规格
- 引擎：
- 分辨率：
- 帧率目标：
- 存档方式：
---
## 6. 里程碑计划
| 里程碑 | 目标 | 包含内容 |
|--------|------|---------|
| M0：核心原型 | 核心循环跑通 | |
| M1：完整Demo | 完整一局体验 | |
| M2：内容完善 | 所有内容填充 | |
| M3：上架就绪 | 打磨+发布准备 | |
---
## 7. 待解决问题（OPEN_QUESTIONS）
（设计中不确定的问题，先记录，后续拍板）
| 问题 | 涉及系统 | 优先级 | 状态 |
|------|---------|--------|------|
阶段4：任务卡生成（本 skill 执行）
触发条件： GDD 阶段3完成并确认，准备进入开发。
操作： 根据 GDD 生成以下文件结构，直接交付给 CodeBuddy 使用。
输出目录结构：
<项目名>/
├── CODEBUDDY.md ← CodeBuddy 项目总控（必须首先读取）
├── tasks/
│ ├── 00_MASTER_PROMPT.md ← AI行为约束和项目上下文
│ ├── 01_CORE_LOOP.md ← 第一个可玩原型
│ ├── 02_COMBAT_FEEL.md ← 手感打磨（如适用）
│ ├── 03_CONTENT.md ← 内容填充
│ ├── 04_POLISH.md ← 打磨阶段
│ └── VALIDATION_CHECKLIST.md ← 验收清单
├── data/ ← 数值配置（只读，CodeBuddy 不修改）
├── docs/
│ ├── concept.md
│ ├── gdd.md
│ └── OPEN_QUESTIONS.md
└── README.md ← 项目总览和决策表
MASTER_PROMPT.md 模板：
# 00 MASTER PROMPT
你正在开发 [引擎] 项目《[项目名]》。每次新会话开始时必须先读取：
1. README.md
2. docs/gdd.md
3. data/*.json（如存在）
读完后告诉我你理解了哪些约束，然后开始执行。
## 强制规则
- 使用 [引擎] 和 [语言]
- 所有数值优先来自 data/ 目录的配置文件
- 先保证可运行，再逐步增强表现
- 不要一次性重写全部代码
- 每次提交说明：改了哪些文件 / 实现了什么 / 如何验证
- **不要擅自改核心设计方向**
- 发现设计问题时，写入 docs/OPEN_QUESTIONS.md，不要自行决策
## 当前项目状态
（每次更新）
## 已知约束
-
任务卡模板（每个任务卡的格式）：
# 任务 [N]：[名称]
## 目标
（一句话说清楚这个任务要达到什么）
## 范围（要做的）
- [ ] 具体任务1
- [ ] 具体任务2
## 不做（明确排除）
- 不在本轮范围的东西（防止 AI 顺手乱加）
## 验收标准
- 运行后看到什么 = 通过
- 什么情况 = 失败需要重做
## 依赖
- 依赖任务N完成后才能开始（如有）
边界情况检查清单
每个系统设计完成后，必须逐项检查：
□ 最小值边界：参数为0或负数时系统如何处理？
□ 最大值边界：参数达到上限时会发生什么？
□ 空状态：没有内容时界面/逻辑如何表现？
□ 并发/同时触发：两个事件同时发生时优先级是什么？
□ 玩家跳过：玩家可以跳过这个系统吗？跳过后有什么影响？
□ 异常中断：操作中途退出/断线/崩溃，数据如何处理？
□ 极端组合：最强配置+最弱配置各是什么，是否破坏平衡？
□ 新手路径：第一次接触这个系统的玩家会遇到什么困惑？
用户偏好
- 文档格式：Markdown，默认输出到
C:\Users\tiannuoxie\WorkBuddy\games\<项目名>\ - 边界情况：强制步骤，每个系统必做
- 任务卡粒度：默认阶段级（M0/M1...），需要细化时再拆
- 引擎：Godot 4（已确定）
- 发布平台：Steam 单机优先，后续视情况移植微信小游戏
- 服务器：不需要，单机本地存档，Steam 平台处理排行榜/成就/云存档
- 游戏类型：待确定，具备0-1战斗类游戏数值策划经验（TTK框架）
踩坑经验
（以下由 AI 在实际调用中自动积累）
（暂无，首次使用时记录）