phaser-gdd

Phaser 4 游戏设计文档生成器

为 Phaser 4 游戏生成一份全面的游戏设计文档（GDD）。GDD 将所有设计决策——机制、美术、音频、进度、技术限制——汇总到单个 Markdown 文件中，让整个团队（或独立开发者）在编写任何代码之前都能参考同一份文档。

GDD 结构（13 个章节）

每份生成的 GDD 都必须包含以下全部 13 个章节。如果用户尚未指定某个章节的细节，请根据游戏类型和规模提供合理的默认值，并使用 `` 标记假设，方便查找和修改。

---

章节 1 — 游戏概览

快速建立游戏的基本定位。

包含：

• 标题 — 暂定标题（可以是占位内容）。
• 标语 — 用一句有力的话展现游戏的吸引力。
• 类型 — 主要类型及其子类型（例如，“roguelike 平台游戏”）。
• 目标受众 — 年龄范围、玩家特征，以及休闲或硬核玩家定位。
• 电梯陈述 — 恰好用 2 句话说明玩家要做什么，以及这样做为何有趣。
• 独特卖点（USP） — 列出 3-5 条能让游戏脱颖而出的要点。
• 可比作品 — 列出用户或受众熟悉的 2-3 款现有游戏，并简要说明借鉴之处和差异。

---

章节 2 — 核心游戏循环

定义让玩家持续投入的可重复循环。

包含：

• 30 秒循环 — 最小的原子操作循环（例如，跳跃-落地-收集）。
• 5 分钟循环 — 中等长度的流程，例如完成一个关卡或一波挑战。
• 单次游玩循环 — 一次完整的游玩体验（休闲玩家为 15-30 分钟，硬核玩家为 60 分钟以上）。

用 ASCII 流程图展示每个循环：

[Action] --> [Feedback] --> [Reward] --> [Decision] --+
   ^                                                  |
   +--------------------------------------------------+

• 胜利条件 — 玩家必须达成什么目标才能“通关”游戏或关卡。
• 失败条件 — 什么情况会导致失败，以及接下来会发生什么（重玩关卡、失去一条命、游戏结束）。

---

章节 3 — 机制详解

详细说明玩家接触到的所有交互系统。

包含：

• 主要机制 — 1-3 个核心动词（例如，跳跃、射击、配对）。每项机制说明输入方式、物理行为和边缘情况。
• 次要机制 — 支持性系统（例如，物品栏、制作、对话）。说明它们如何与核心循环相互作用。
• 控制方案 — 按平台映射输入：

操作	键盘	触屏	游戏手柄
移动	WASD / 方向键	虚拟摇杆	左摇杆
跳跃	Space	轻触右侧	A 按钮

---

章节 4 — 进度系统

说明难度、内容和奖励如何随时间变化。

包含：

• 难度曲线 — 描述预期的难度提升方式（线性、指数、锯齿形），并提及具体里程碑。
• 解锁顺序 — 玩家何时获得哪些新能力、关卡或物品。
• 计分系统 — 分数的计算方式、连击倍率，以及是否设有排行榜。
• 可重玩设计 — 哪些内容会吸引玩家再次游玩（新游戏+、每日挑战、程序生成）。
• 预计游玩时长 — 首次通关和达成 100% 完成度所需的时间。

---

章节 5 — 关卡 / 世界设计

规划游戏的空间结构。

包含：

• 关卡数量 — 关卡、世界或区域的总数。
• 主题 — 每个世界的视觉和机制主题（例如，“世界 2 — 冰窟：地面湿滑，墙壁可破坏”）。
• 流程图 — 用 ASCII 图展示关卡进度和分支：

[Level 1] --> [Level 2] --> [Level 3]
                  |
                  +--> [Bonus Level A]

• 难度递增 — 说明敌人数量、速度、谜题复杂度或时间压力如何随关卡提升。

---

第 6 节 — 角色与实体

列出每个游戏对象，并提供与游戏玩法相关的详细信息。

包括：

• 玩家角色 — 基础属性（速度、生命值、跳跃高度）、能力、状态机（待机、跑步、跳跃、受伤、死亡）。
• 敌人类型 — 表格格式：

敌人	生命值	速度	行为	攻击	掉落物
史莱姆	1	40px/s	左右巡逻	接触伤害	金币（50%）

• NPC — 角色、对话触发条件、任务关联。
• 收集品与强化道具 — 效果、持续时间、稀有度、视觉指示。

---

第 7 节 — UI/UX 线框图

定义玩家会看到的每个画面。

包括：

• HUD 布局 — 游戏内叠加界面的 ASCII 线框图：

+---------------------------------------+
| [Lives: x3]          [Score: 00000]   |
|                                       |
|                                       |
|              GAME AREA                |
|                                       |
|                                       |
| [Item1] [Item2] [Item3]    [Pause]   |
+---------------------------------------+

• 菜单流程图 — 展示各画面之间导航关系的 ASCII 图：

[Title Screen] --> [Main Menu] --> [Play] --> [Level Select] --> [Game]
                       |                                           |
                       +--> [Settings]                     [Pause Menu]
                       +--> [Credits]                          |
                                                         [Game Over] --> [Main Menu]

• 画面模型 — 简要描述每个独特画面（标题、主菜单、设置、游戏结束、胜利）。
• 无障碍设计考量 — 色盲模式、字体大小选项、可重新映射的控制、屏幕阅读器提示。

---

第 8 节 — 美术指导

确立视觉风格和素材制作流程。

包括：

• 视觉风格 — 用 1-2 句话描述（例如：“采用 16 位像素艺术风格，并搭配现代光照效果”）。
• 调色板 — 提供 5-8 个带用途标签的十六进制颜色代码：

用途	十六进制	使用场景
主色	#3A86FF	玩家、UI 高亮
次要色	#FF006E	敌人、危险
背景	#1B1B2F	天空、菜单

• 分辨率与缩放 — 游戏分辨率（例如，800x600）、缩放模式（Phaser FIT、RESIZE 等）、像素完美标记。
• 动画指南 — 每种动画的帧数和 FPS（待机：4 帧 @ 8fps，跑步：6 帧 @ 12fps）。
• 素材清单及规格 — 所需素材一览表：

素材	类型	尺寸	帧数	格式
player_idle	精灵表	32x32	4	PNG
background_forest	静态图像	800x600	1	PNG

---

第 9 节 — 音频设计计划

定义声音景观。

包括：

• 各场景的音乐氛围 — 将每个场景/关卡与音乐氛围和速度对应起来的表格：

场景	氛围	速度	循环？
主菜单	神秘、引人入胜	90 BPM	是
关卡 1	欢快、充满冒险感	120 BPM	是
Boss 战	紧张、急迫	150 BPM	是
游戏结束	忧郁、沉思	70 BPM	否

• 音效清单 — 动作与声音的对应关系：

动作	声音描述	优先级
玩家跳跃	短促、轻盈的呼啸声	高
收集金币	明亮、逐渐升高的铃声	高
敌人受击	轻柔的闷响 + 啪叽声	中

• 格式要求 — 为确保跨浏览器兼容性，所有音频必须同时提供 MP3 和 OGG 格式。Phaser 会在运行时选择最佳格式。
• 音量层级 — 定义相对音量：音乐（0.4）、音效（0.7）、UI 声音（0.5）。说明它们之间的相互作用（重大事件发生时，音效会短暂降低音乐音量）。

---

第 10 节 — 技术要求

明确 Phaser 相关的技术决策。

包括：

• Phaser 版本 — 除非用户另有指定，否则使用 phaser（v4.2.1 stable）。
• 物理引擎 — 选择一种并说明理由：
  • Arcade — 简单的 AABB，最适合平台游戏和射击游戏。CPU 开销低。
  • Matter.js — 完整的刚体物理。适用于需要旋转、关节或复杂碰撞形状的游戏。
  • None — 适用于无需物理模拟的益智或卡牌游戏。
• 性能预算 — 目标帧率（60 FPS）、每帧最大绘制调用次数、同时存在的粒子数量上限、纹理图集尺寸限制。
• 浏览器/设备目标 — 最低浏览器版本、移动设备档次（例如，“必须能在 2020 年左右的中端 Android 设备上以 30+ FPS 运行”）。

---

第 11 节 — 平台目标与设备配置

指定游戏的运行平台，以及不同平台上的输入方式。

包括：

• 主要平台 — 桌面浏览器、移动浏览器、PWA、Electron、Capacitor/Cordova。
• 各平台的输入方式：

平台	主要输入方式	次要输入方式
桌面端	键盘 + 鼠标	游戏手柄
移动端	触控	陀螺仪（可选）
平板电脑	触控	蓝牙游戏手柄

• 部署方式 — 游戏的构建与分发方式（静态托管、itch.io、通过 Capacitor 上架应用商店等）。

---

第 12 节 — 盈利模式与发布计划（可选）

仅当用户希望讨论商业方面的内容时，才包含本节。在输出中将其标记为可选。

包括：

• 商业模式 — 免费、付费、免费增值、广告支持或捐赠模式。
• 里程碑 — 关键日期或阶段：

里程碑	目标日期	交付内容
原型	第 2 周	核心循环可玩
Alpha	第 6 周	所有关卡完成布局
Beta	第 10 周	功能完备，进行游戏测试
发布	第 14 周	完成润色并部署

• 分发 — 游戏的发布平台（itch.io、GitHub Pages、Steam、应用商店）。

---

第 13 节 — 验收标准

其他所有章节都描述设计意图。本节是机器唯一能够检查的部分，也是将 GDD 从文档转变为规格说明的关键。

编写每条标准时，确保它可观察、可量化，并且在游戏不符合要求时为假。“玩家应该感到强大”不是一条标准。“蓄力攻击造成基础伤害的 3 倍”才是。

直接从第 3 节（机制）、第 4 节（进度）和第 6 节（实体）推导标准——设计中凡是明确规定数字的地方，该数字都应成为一条标准。

标准	可观察状态	游戏测试断言
玩家可跳跃至 3 个图块（96px）高	player.y 在最高点的位置	player.y，atMost: spawnY - 96
基础敌人受到 3 次攻击后死亡	enemy.active	按攻击 ×3 次，然后检查 enemy.active，equals: false
分数在进入 GameOver 后保留	registry.get('score')	切换场景，然后检查 atLeast: 10
土狼时间为 100ms	离开平台边缘后仍可成功跳跃	走下边缘，等待 80ms，跳跃 → body.velocity.y < 0
第 5 波生成 12 个敌人	活跃敌人数量	设置波次，然后检查 enemies.countActive(true)，equals: 12
有 50 个实体时保持 60fps	game.loop.actualFps	生成 50 个实体，然后检查 atLeast: 55
在 3 秒内启动并进入菜单	t=3s 时的场景键	game.scene.isActive('MainMenuScene')，equals: true

将标准归类到必须满足这些标准的里程碑下：

### Vertical Slice
- [ ] Player spawns at level start and responds to left/right/jump within 1 frame
- [ ] Falling off the map triggers respawn at the last checkpoint within 500ms
- [ ] Collecting a coin increments score by 10 and plays the pickup sound

### Alpha
- [ ] All 8 levels load without console errors
- [ ] Enemy AI pathfinds around static geometry (no wall-clipping over 30s)

对确实属于主观判断的内容，应如实标记，而不要编造虚假的度量指标：

### Human review required (not automatable)
- Difficulty curve across levels 1-8 feels fair to a first-time player
- Art reads clearly against every background
- Audio mix is balanced at 50% volume

将这些内容与 GDD 一起保存到 docs/acceptance-criteria.md。phaser-playtest 技能会将每条可自动化的标准转化为场景断言，从而验证设计，而不只是陈述设计。

---

GDD 后续工作流

GDD 定稿后，引导用户开展后续工作：

1. 搭建项目骨架 — 使用 /phaser-new 生成符合 GDD 技术要求的基础项目结构。
2. 设计架构 — 使用 phaser-architect 技能/Agent，将 GDD 转化为技术架构：场景图、类层次结构、数据流和系统拆分。
3. 开始实现 — 使用 phaser-coder 技能/Agent，根据 GDD 开始编写场景、机制和实体的代码。
4. 验证运行情况 — 每完成一个垂直切片后，使用 /phaser-playtest。第 13 节中可自动化的验收标准会转化为游戏测试断言，以此检验设计，而不只是将其写下来。
5. 发布 — /phaser-release 会运行就绪度检查，并准备商店页面。
6. 根据玩家反馈迭代 — /phaser-feedback 会将玩家报告转化为失败的游戏测试场景，然后修复问题并添加回归测试。

如果用户在还没有明确概念时就来到了这里——只有一个类型，而没有核心创意，或者尚未根据可用时间评估项目范围——请先引导他们使用 /phaser-brainstorm。围绕范围尚未确定的想法编写 GDD，记录下来的将是一个无法完成的项目。

提醒用户：GDD 是一份持续更新的文档。随着游戏开发推进，应不断更新。

---

输出格式

生成的 GDD 必须是单个 Markdown 文档，并包含：

• 顶层标题 # Game Design Document: [Title]。
• 13 个章节分别使用 ## Section N — Name 标题。
• 所有流程图、线框图和关卡地图都使用 ASCII 图（不依赖外部图片）。
• 结构化数据（敌人、资源、音频、控制）使用表格。
• 对生成器推断而非用户提供的任何细节，在其旁边添加 `` 注释。

将文档保存到项目根目录下的 docs/GDD.md。如果项目目录不存在，则在聊天中完整输出 GDD。