Back to Details

phaser-gdd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Phaser 4 Game Design Document Generator

Phaser 4 游戏设计文档生成器

Generate a comprehensive Game Design Document (GDD) for a Phaser 4 game. The GDD captures every design decision — mechanics, art, audio, progression, technical constraints — in a single Markdown file so the entire team (or solo dev) has a shared reference before any code is written.
为Phaser 4游戏生成一份全面的游戏设计文档（GDD）。该文档会将所有设计决策——机制、美术、音频、进度、技术限制——整合到单个Markdown文件中，以便整个团队（或独立开发者）在编写任何代码前拥有统一的参考依据。

GDD Structure (13 Sections)

GDD 结构（13个章节）

Every generated GDD must include all 13 sections below. If the user has not specified details for a section, provide sensible defaults based on the genre and scope, and mark assumptions with 
<!-- ASSUMPTION -->
so they are easy to find and revise.
生成的每份GDD都必须包含以下全部13个章节。如果用户未指定某章节的细节，请根据游戏类型和范围提供合理的默认值，并使用
<!-- ASSUMPTION -->
标记假设内容，以便于查找和修改。

Section 1 — Game Overview

章节1 — 游戏概述

Establish the identity of the game at a glance.
Include:
  • Title — Working title (can be placeholder).
  • Tagline — One punchy sentence that sells the hook.
  • Genre — Primary genre and any sub-genres (e.g., "roguelike platformer").
  • Target Audience — Age range, player profile, casual vs. hardcore.
  • Elevator Pitch — Exactly 2 sentences: what the player does and why it is fun.
  • Unique Selling Points (USPs) — 3-5 bullet points that differentiate the game.
  • Comparable Titles — 2-3 existing games the user or audience would recognize, with a brief note on what is borrowed and what is different.
快速确立游戏的定位。
包含：
  • 标题——暂定名称（可使用占位符）。
  • 标语——一句简洁有力的宣传语，突出游戏亮点。
  • 类型——主类型及子类型（例如："roguelike平台游戏"）。
  • 目标受众——年龄范围、玩家画像、休闲玩家还是硬核玩家。
  • 电梯游说——恰好2句话：玩家要做什么，以及游戏为何有趣。
  • 独特卖点（USPs）——3-5个项目符号点，说明游戏的差异化优势。
  • 参考竞品——2-3款用户或受众熟知的现有游戏，简要说明借鉴和创新之处。

Section 2 — Core Game Loop

章节2 — 核心游戏循环

Define the repeatable cycle that keeps the player engaged.
Include:
  • 30-Second Loop — The smallest atomic action cycle (e.g., jump-land-collect).
  • 5-Minute Loop — A medium arc such as completing a level or a wave.
  • Session Loop — What a full play session looks like (15-30 min for casual, 60+ for hardcore).
Present each loop as an ASCII flow diagram:
[Action] --> [Feedback] --> [Reward] --> [Decision] --+
   ^                                                  |
   +--------------------------------------------------+
  • Win Condition — What the player must achieve to "beat" the game or level.
  • Lose Condition — What causes failure and what happens next (restart level, lose life, game over).
定义让玩家保持投入的可重复循环。
包含：
  • 30秒循环——最小的原子动作循环（例如：跳跃-落地-收集）。
  • 5分钟循环——中等时长的流程，如完成一个关卡或一波敌人。
  • 会话循环——完整游戏会话的流程（休闲游戏15-30分钟，硬核游戏60分钟以上）。
将每个循环以ASCII流程图呈现：
[Action] --> [Feedback] --> [Reward] --> [Decision] --+
   ^                                                  |
   +--------------------------------------------------+
  • 胜利条件——玩家需要达成什么目标才能“通关”游戏或关卡。
  • 失败条件——导致失败的情况及后续结果（重启关卡、失去生命、游戏结束）。

Section 3 — Mechanics Deep Dive

章节3 — 机制深度解析

Detail every interactive system the player touches.
Include:
  • Primary Mechanics — The 1-3 core verbs (e.g., jump, shoot, match). For each: input, physics behavior, edge cases.
  • Secondary Mechanics — Supporting systems (e.g., inventory, crafting, dialogue). Describe how they feed back into the core loop.
  • Control Scheme — Map inputs per platform:
ActionKeyboardTouchGamepad
MoveWASD / ArrowsVirtual joystickLeft stick
JumpSpaceTap right sideA button
详细说明玩家接触到的每一个交互系统。
包含：
  • 核心机制——1-3个核心动作（例如：跳跃、射击、匹配）。针对每个动作说明：输入方式、物理行为、边缘情况。
  • 辅助机制——支撑系统（例如：背包、制作、对话）。说明它们如何反馈到核心循环中。
  • 控制方案——按平台映射输入方式：
动作键盘触屏游戏手柄
移动WASD / 方向键虚拟摇杆左摇杆
跳跃空格键点击右侧区域A键

Section 4 — Progression System

章节4 — 进度系统

Describe how difficulty, content, and rewards evolve over time.
Include:
  • Difficulty Curve — Describe the intended ramp (linear, exponential, sawtooth). Reference specific milestones.
  • Unlock Sequence — What new abilities, levels, or items the player earns and when.
  • Scoring System — How score is calculated, combo multipliers, leaderboards if any.
  • Replayability Hooks — What brings the player back (new game+, daily challenges, procedural generation).
  • Estimated Play Time — Time to first completion and time to 100% completion.
说明难度、内容和奖励如何随时间演变。
包含：
  • 难度曲线——描述预期的难度提升节奏（线性、指数型、锯齿型）。参考具体里程碑。
  • 解锁序列——玩家将获得哪些新能力、关卡或道具，以及解锁时机。
  • 计分系统——分数计算方式、 combo 乘数、是否包含排行榜。
  • 重玩吸引力——吸引玩家回归的元素（新游戏+、每日挑战、 procedural generation）。
  • 预估游玩时长——首次通关时长和100%完成时长。

Section 5 — Level / World Design

章节5 — 关卡/世界设计

Plan the spatial structure of the game.
Include:
  • Level Count — Total number of levels, worlds, or zones.
  • Themes — Visual and mechanical theme per world (e.g., "World 2 — Ice Caves: slippery surfaces, breakable walls").
  • Flow Maps — ASCII diagram showing level progression and branching:
[Level 1] --> [Level 2] --> [Level 3]
                  |
                  +--> [Bonus Level A]
  • Difficulty Scaling — How enemy count, speed, puzzle complexity, or time pressure increases per level.
规划游戏的空间结构。
包含：
  • 关卡数量——总关卡数、世界数或区域数。
  • 主题——每个世界的视觉和机制主题（例如："世界2——冰洞：地面湿滑、可破坏墙壁"）。
  • 流程地图——ASCII图表展示关卡进度和分支：
[Level 1] --> [Level 2] --> [Level 3]
                  |
                  +--> [Bonus Level A]
  • 难度缩放——每关的敌人数量、速度、谜题复杂度或时间压力如何提升。

Section 6 — Characters & Entities

章节6 — 角色与实体

Catalog every game object with gameplay-relevant detail.
Include:
  • Player Character — Base stats (speed, health, jump height), abilities, state machine (idle, run, jump, hurt, dead).
  • Enemy Types — Table format:
EnemyHPSpeedBehaviorAttackDrop
Slime140px/sPatrol left-rightContact damageCoin (50%)
  • NPCs — Role, dialogue triggers, quest associations.
  • Collectibles & Power-ups — Effect, duration, rarity, visual indicator.
记录所有与游戏玩法相关的游戏对象细节。
包含：
  • 玩家角色——基础属性（速度、生命值、跳跃高度）、能力、状态机（ idle、run、jump、hurt、dead）。
  • 敌人类型——表格形式：
敌人HP速度行为攻击方式掉落物
史莱姆140px/s左右巡逻接触伤害金币（50%概率）
  • NPC——角色定位、对话触发条件、关联任务。
  • 收集品与增益道具——效果、持续时间、稀有度、视觉标识。

Section 7 — UI/UX Wireframes

章节7 — UI/UX 线框图

Define every screen the player sees.
Include:
  • HUD Layout — ASCII wireframe of the in-game overlay:
+---------------------------------------+
| [Lives: x3]          [Score: 00000]   |
|                                       |
|                                       |
|              GAME AREA                |
|                                       |
|                                       |
| [Item1] [Item2] [Item3]    [Pause]   |
+---------------------------------------+
  • Menu Flow Diagram — ASCII showing navigation between screens:
[Title Screen] --> [Main Menu] --> [Play] --> [Level Select] --> [Game]
                       |                                           |
                       +--> [Settings]                     [Pause Menu]
                       +--> [Credits]                          |
                                                         [Game Over] --> [Main Menu]
  • Screen Mockups — Brief description of each unique screen (title, main menu, settings, game over, win).
  • Accessibility Considerations — Color-blind modes, font size options, remappable controls, screen reader hints.
定义玩家看到的每一个界面。
包含：
  • HUD布局——游戏内 overlay 的ASCII线框图：
+---------------------------------------+
| [生命: x3]          [分数: 00000]   |
|                                       |
|                                       |
|              游戏区域                |
|                                       |
|                                       |
| [道具1] [道具2] [道具3]    [暂停]   |
+---------------------------------------+
  • 菜单流程图——ASCII图表展示界面间的导航：
[标题界面] --> [主菜单] --> [开始游戏] --> [关卡选择] --> [游戏中]
                       |                                           |
                       +--> [设置]                     [暂停菜单]
                       +--> [ credits ]                          |
                                                         [游戏结束] --> [主菜单]
  • 界面原型说明——每个独特界面（标题、主菜单、设置、游戏结束、胜利）的简要描述。
  • 无障碍设计考量——色盲模式、字体大小选项、可自定义控制、屏幕阅读器提示。

Section 8 — Art Direction

章节8 — 美术风格指导

Establish the visual identity and asset pipeline.
Include:
  • Visual Style — Describe in 1-2 sentences (e.g., "16-bit pixel art with modern lighting effects").
  • Color Palette — 5-8 hex codes with role labels:
RoleHexUsage
Primary#3A86FFPlayer, UI highlights
Secondary#FF006EEnemies, danger
Background#1B1B2FSky, menus
  • Resolution & Scaling — Game resolution (e.g., 800x600), scale mode (Phaser 
    FIT
    , 
    RESIZE
    , etc.), pixel-perfect flag.
  • Animation Guidelines — Frame counts, FPS per animation type (idle: 4 frames @ 8fps, run: 6 frames @ 12fps).
  • Asset List with Specs — Table of every required asset:
AssetTypeSizeFramesFormat
player_idleSpritesheet32x324PNG
background_forestStatic800x6001PNG
确立视觉定位和资源管线。
包含：
  • 视觉风格——1-2句话描述（例如："带现代光影效果的16-bit像素艺术"）。
  • 调色板——5-8个十六进制代码及用途标签：
用途十六进制码使用场景
主色调#3A86FF玩家角色、UI高亮
辅助色#FF006E敌人、危险提示
背景色#1B1B2F天空、菜单
  • 分辨率与缩放——游戏分辨率（例如：800x600）、缩放模式（Phaser 
    FIT
    、
    RESIZE
    等）、像素完美开关。
  • 动画规范——帧数、每种动画类型的FPS（idle：4帧 @ 8fps，run：6帧 @ 12fps）。
  • 资源列表及规格——所有所需资源的表格：
资源类型尺寸帧数格式
player_idle精灵表32x324PNG
background_forest静态图800x6001PNG

Section 9 — Audio Design Plan

章节9 — 音频设计方案

Define the soundscape.
Include:
  • Music Mood per Scene — Table mapping each scene/level to a musical mood and tempo:
SceneMoodTempoLoop?
Main MenuMysterious, inviting90 BPMYes
Level 1Upbeat, adventurous120 BPMYes
Boss FightIntense, urgent150 BPMYes
Game OverSomber, reflective70 BPMNo
  • SFX List — Action-to-sound mapping:
ActionSound DescriptionPriority
Player jumpShort airy whooshHigh
Coin collectBright chime ascendingHigh
Enemy hitSoft thud + squishMedium
  • Format Requirements — All audio must be provided in both MP3 and OGG for cross-browser compatibility. Phaser will select the best format at runtime.
  • Volume Hierarchy — Define relative volume levels: Music (0.4), SFX (0.7), UI sounds (0.5). Describe how they interact (SFX duck music briefly on major events).
定义游戏的声效环境。
包含：
  • 场景音乐氛围——表格映射每个场景/关卡的音乐氛围和节奏：
场景氛围节奏是否循环
主菜单神秘、有吸引力90 BPM是
关卡1欢快、富有冒险感120 BPM是
Boss战紧张、急迫150 BPM是
游戏结束低沉、反思70 BPM否
  • 音效列表——动作与音效的对应关系：
动作音效描述优先级
玩家跳跃短促的风声高
收集金币明亮的升调铃声高
击中敌人轻柔的撞击+挤压声中
  • 格式要求——所有音频必须同时提供MP3和OGG格式，以实现跨浏览器兼容性。Phaser会在运行时选择最合适的格式。
  • 音量层级——定义相对音量：音乐（0.4）、音效（0.7）、UI音效（0.5）。说明它们的交互方式（重大事件时音效短暂压低音乐音量）。

Section 10 — Technical Requirements

章节10 — 技术要求

Pin down the Phaser-specific technical decisions.
Include:
  • Phaser Version — 
    phaser@beta
    (v4.0.0-rc.7) unless the user specifies otherwise.
  • Physics Engine — Choose one and justify:
    • Arcade — Simple AABB, best for platformers and shooters. Low CPU cost.
    • Matter.js — Full rigid-body physics. Use for games needing rotation, joints, or complex collision shapes.
    • None — For puzzle or card games with no physics simulation.
  • Performance Budgets — Target frame rate (60 FPS), max draw calls per frame, max simultaneous particles, texture atlas size limits.
  • Browser/Device Targets — Minimum browser versions, mobile device tier (e.g., "must run at 30+ FPS on 2020-era mid-range Android").
明确Phaser相关的技术决策。
包含：
  • Phaser版本——
    phaser@beta
    （v4.0.0-rc.7），除非用户另有指定。
  • 物理引擎——选择一个并说明理由：
    • Arcade——简单的AABB碰撞，最适合平台游戏和射击游戏。CPU消耗低。
    • Matter.js——完整的刚体物理。适用于需要旋转、关节或复杂碰撞形状的游戏。
    • 无——适用于无需物理模拟的解谜或卡牌游戏。
  • 性能预算——目标帧率（60 FPS）、每帧最大绘制调用数、最大同时粒子数、纹理图集大小限制。
  • 浏览器/设备目标——最低浏览器版本、移动设备等级（例如："必须在2020年款中端Android设备上以30+ FPS运行"）。

Section 11 — Platform Targets & Device Profiles

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

Specify where the game will run and how input differs.
Include:
  • Primary Platforms — Desktop browser, mobile browser, PWA, Electron, Capacitor/Cordova.
  • Input per Platform:
PlatformPrimary InputSecondary Input
DesktopKeyboard + MouseGamepad
MobileTouchGyroscope (optional)
TabletTouchBluetooth gamepad
  • Deployment Method — How the game is built and distributed (static hosting, itch.io, app store via Capacitor, etc.).
指定游戏的运行平台及输入方式差异。
包含：
  • 主要平台——桌面浏览器、移动浏览器、PWA、Electron、Capacitor/Cordova。
  • 各平台输入方式：
平台主要输入次要输入
桌面端键盘+鼠标游戏手柄
移动端触屏陀螺仪（可选）
平板触屏蓝牙游戏手柄
  • 部署方式——游戏的构建和分发方式（静态托管、itch.io、通过Capacitor发布到应用商店等）。

Section 12 — Monetization & Release Plan (Optional)

章节12 — 变现与发布计划（可选）

Include this section only if the user wants to discuss business aspects. Mark it optional in the output.
Include:
  • Business Model — Free, premium, freemium, ad-supported, or donation-ware.
  • Milestones — Key dates or phases:
MilestoneTarget DateDeliverable
PrototypeWeek 2Core loop playable
AlphaWeek 6All levels blocked out
BetaWeek 10Feature-complete, playtesting
LaunchWeek 14Polished, deployed
  • Distribution — Where the game will be published (itch.io, GitHub Pages, Steam, app stores).
仅当用户希望讨论商业相关内容时包含此章节。在输出中标记为可选。
包含：
  • 商业模式——免费、付费、免费增值、广告支持或捐赠制。
  • 里程碑——关键日期或阶段：
里程碑目标日期交付成果
原型第2周核心循环可玩
Alpha版第6周所有关卡框架搭建完成
Beta版第10周功能完整，可进行测试
发布第14周打磨完成并部署
  • 分发渠道——游戏发布平台（itch.io、GitHub Pages、Steam、应用商店）。

Section 13 — Acceptance Criteria

章节13 — 验收标准

Every other section describes intent. This one is the only part a machine can check, and it is what turns the GDD from a document into a specification.
Write each criterion so that it is observable, numeric, and false when the game is wrong. "The player should feel powerful" is not a criterion. "A charged attack deals 3× base damage" is.
Derive criteria directly from Sections 3 (Mechanics), 4 (Progression), and 6 (Entities) — anywhere the design commits to a number, that number is a criterion.
CriterionObservable statePlaytest assertion
Player jumps 3 tiles (96px) high
player.y
at apex
player.y
, 
atMost: spawnY - 96
Basic enemy dies in 3 hits
enemy.active
press attack ×3, then 
enemy.active
, 
equals: false
Score persists into GameOver
registry.get('score')
transition, then 
atLeast: 10
Coyote time is 100msjump succeeds after leaving ledgewalk off, wait 80ms, jump → 
body.velocity.y < 0
Wave 5 spawns 12 enemiesactive enemy countset wave, then 
enemies.countActive(true)
, 
equals: 12
Holds 60fps with 50 entities
game.loop.actualFps
spawn 50, then 
atLeast: 55
Boot reaches menu in under 3sscene key at t=3s
game.scene.isActive('MainMenuScene')
, 
equals: true
Group criteria under the milestone that must satisfy them:
markdown
undefined
其他所有章节描述的是设计意图，而本章节是唯一可被机器验证的部分，它将GDD从一份文档转化为一份规范。
每条标准都应具备可观测、可量化、错误时可判定为假的特性。“玩家应该感到强大”不是合格的标准，“蓄力攻击造成3倍基础伤害”才是。
直接从章节3（机制）、章节4（进度）和章节6（实体）中提取标准——任何设计中涉及具体数值的地方，该数值都可作为验收标准。
标准可观测状态测试断言
玩家跳跃高度为3格（96px）
player.y
达到最高点
player.y
, 
atMost: spawnY - 96
普通敌人被击中3次后死亡
enemy.active
攻击3次后，
enemy.active
, 
equals: false
分数保留到游戏结束界面
registry.get('score')
切换界面后，
atLeast: 10
coyote time 为100ms离开平台后跳跃仍成功走出平台，等待80ms后跳跃 → 
body.velocity.y < 0
第5波生成12个敌人活跃敌人数量设置为第5波后，
enemies.countActive(true)
, 
equals: 12
50个实体时保持60fps
game.loop.actualFps
生成50个实体后，
atLeast: 55
启动到菜单界面耗时少于3秒t=3s时的场景标识
game.scene.isActive('MainMenuScene')
, 
equals: true
将标准按需要满足的里程碑分组：
markdown
undefined

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
  • 玩家在关卡开始处生成，并能在1帧内响应左右移动/跳跃
  • 掉落地图后500ms内触发在最近 checkpoint 重生
  • 收集金币后分数增加10并播放拾取音效

Alpha

Alpha版

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

Mark anything genuinely subjective as such rather than inventing a fake metric:

```markdown
  • 所有8个关卡加载无控制台错误
  • 敌人AI能绕过静态障碍物（30秒内无穿墙）

将真正主观的内容标记出来，而非编造虚假指标：

```markdown

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

Save these to `docs/acceptance-criteria.md` alongside the GDD. The phaser-playtest
skill turns each automatable criterion into a scenario assertion, which is how the
design gets verified rather than merely stated.

---
  • 1-8关的难度曲线对首次玩家来说感觉合理
  • 美术元素在所有背景下都清晰可辨
  • 50%音量下音频混音平衡

将这些内容保存到项目根目录下的`docs/acceptance-criteria.md`，与GDD放在一起。phaser-playtest技能会将每个可自动化的标准转化为场景断言，以此验证设计而非仅作说明。

---

Post-GDD Workflow

GDD生成后工作流程

Once the GDD is finalized, guide the user to the next steps:
  1. Scaffold the project — Use 
    /phaser-new
    to generate the base project structure matching the GDD's technical requirements.
  2. Design the architecture — Use the phaser-architect skill/agent to translate the GDD into a technical architecture: scene graph, class hierarchy, data flow, and system decomposition.
  3. Start implementing — Use the phaser-coder skill/agent to begin coding scenes, mechanics, and entities as specified in the GDD.
Remind the user: the GDD is a living document. Update it as the game evolves during development.
GDD定稿后，引导用户进行下一步：
  1. 搭建项目框架——使用
    /phaser-new
    生成符合GDD技术要求的基础项目结构。
  2. 设计架构——使用phaser-architect技能/agent将GDD转化为技术架构：场景图、类层级、数据流和系统分解。
  3. 开始实现——使用phaser-coder技能/agent按照GDD中的说明开始编写场景、机制和实体代码。
提醒用户：GDD是一份动态文档。在开发过程中随着游戏的演进要及时更新。

Output Format

输出格式

The generated GDD must be a single Markdown document with:
  • A top-level 
    # Game Design Document: [Title]
    heading.
  • Each of the 13 sections as 
    ## Section N — Name
    headings.
  • ASCII diagrams for all flow charts, wireframes, and level maps (no external image dependencies).
  • Tables for structured data (enemies, assets, audio, controls).
  • <!-- ASSUMPTION -->
    comments next to any detail the generator inferred rather than received from the user.
Save the document to 
docs/GDD.md
in the project root. If no project directory exists, print the full GDD inline in the chat.
生成的GDD必须是单个Markdown文档，包含：
  • 顶级标题
    # 游戏设计文档: [标题]
    。
  • 13个章节分别以
    ## 章节N — 名称
    作为标题。
  • 所有流程图、线框图和关卡地图使用ASCII图表（无外部图片依赖）。
  • 结构化数据（敌人、资源、音频、控制）使用表格。
  • 对于生成器自行推断而非从用户处获取的细节，添加
    <!-- ASSUMPTION -->
    注释。
将文档保存到项目根目录下的
docs/GDD.md
。如果项目目录不存在，则在聊天中直接输出完整GDD。