Professional game planning framework — produces industry-standard game design documents (GDD)
Applicable Scenarios
- GDD initialization and architecture design
- Integration of scattered design documents
- GDD completeness audit
- Feature Document writing
- Numerical balance design framework
Quick Commands
/game-planner gdd init # 初始化新專案 GDD
/game-planner gdd audit # 審計現有 GDD 完整性
/game-planner gdd consolidate # 整合散落的設計文件為單一 GDD
/game-planner feature [名稱] # 生成 Feature Document
/game-planner mechanic [名稱] # 設計遊戲機制
/game-planner balance [系統] # 數值平衡分析
Core Philosophy
The Modern Philosophy of GDD
Industry consensus:There is no single standard format, but there are common principles:
| Principle | Description |
|---|---|
| Living Document | A living document that is continuously updated, not a one-time product |
| Agile & Lightweight | Agile and lightweight, avoiding hundreds of pages that no one reads |
| Findable | Information can be found quickly |
| Visual | Games are a visual medium, and documents should also be visualized |
Two-Layer Architecture Design
┌─────────────────────────────────────────────────────────────┐
│ Master Document (主文件) │
│ ├── 執行摘要、願景、設計支柱 │
│ ├── 核心玩法概覽 │
│ └── 連結到各 Feature Documents │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Feature Documents (功能文件) │
│ ├── 戰鬥系統 │
│ ├── 角色系統 │
│ ├── 經濟系統 │
│ └── ... │
└─────────────────────────────────────────────────────────────┘
GDD Standard Structure
Required Sections of the Master Document
| Section | Content | Priority |
|---|---|---|
| 1. Executive Summary | One-page overview: game name, genre, platform, target audience, elevator pitch | P0 Required |
| 2. Design Pillars | 3-5 core design principles, the basis for all decisions | P0 Required |
| 3. Core Gameplay | Gameplay loop, win/loss conditions, controls | P0 Required |
| 4. Game Mechanics | Overview of each system (linked to Feature Doc) | P0 Required |
| 5. Narrative and Worldview | Story outline, setting summary | P1 Important |
| 6. Character Design | Overview of main characters | P1 Important |
| 7. Level Design | Level structure, progression design | P1 Important |
| 8. UI/UX Design | Interface flow, HUD design | P1 Important |
| 9. Music and Sound Effects | Audio style guidelines | P2 Supporting |
| 10. Business Model | Pricing, monetization strategy | P1 Important |
| 11. Development Plan | Milestones, schedule | P1 Important |
| 12. Risk Assessment | Potential risks and responses | P2 Supporting |
Feature Document Template
# [系統名稱] Feature Document
## 設計目標
> 這個系統要解決什麼問題？帶來什麼體驗？
## 核心機制
### 基礎規則
### 數值設計
### 特殊情況
## 玩家體驗
### 預期感受
### 風險與負面體驗
## 與其他系統的關係
### 依賴系統
### 影響系統
## 實作優先級 (LoQ)
| 層級 | 內容 | 狀態 |
|------|------|------|
| Core | 最小可玩版本 | |
| Expected | 玩家預期功能 | |
| Desired | 加分功能 | |
| Aspirational | 理想狀態 | |
## 變更記錄
| 版本 | 日期 | 變更 |
|------|------|------|
GDD Audit Checklist
┌─────────────────────────────────────────────────────────────┐
│ GDD 審計清單 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ▣ 執行摘要 │
│ □ 遊戲名稱與標語 │
│ □ 類型明確定義 │
│ □ 目標平台 │
│ □ 目標受眾 │
│ □ 電梯簡報（30秒版本） │
│ □ 獨特賣點 (USP) │
│ │
│ ▣ 設計支柱 │
│ □ 3-5 個核心設計原則 │
│ □ 每個支柱有清楚的「做/不做」範例 │
│ │
│ ▣ 核心玩法 │
│ □ 玩法循環圖 │
│ □ 勝利/失敗條件 │
│ □ 操作方式（每平台） │
│ □ 目標遊戲時長 │
│ │
│ ▣ 遊戲機制 │
│ □ 每個核心系統有 Feature Document │
│ □ 系統間的依賴關係明確 │
│ □ 數值設計有理論基礎 │
│ │
│ ▣ 一致性檢查 │
│ □ 術語統一（術語表存在） │
│ □ 版本號一致 │
│ □ 無相互矛盾的描述 │
│ □ 所有連結有效 │
│ │
└─────────────────────────────────────────────────────────────┘
Design Pillar Examples
What Are Design Pillars?
Design pillars are 3-5 core principles used to guide all design decisions.
Characteristics of Good Design Pillars：
- ✅ Can be used to reject features that do not fit
- ✅ All team members can use them to make decisions
- ✅ Unique to this project (not platitudes)
Bad Design Pillars：
- ❌ "It should be fun" — platitude
- ❌ "The visuals should be beautiful" — not measurable
- ❌ "Players will like it" — not actionable
Example: Dead Romance Design Pillars
### 1. 敘事與系統融合
> 玩家不應感覺在「切換遊戲類型」
- ✅ 對話選擇 = 獲得卡牌
- ✅ 羈絆等級 = 解鎖能力
- ❌ 分離的「劇情模式」和「戰鬥模式」
### 2. 短節奏循環
> 保持 Galgame 的敘事節奏
- ✅ 戰鬥 60-90 秒（3-5 回合）
- ✅ 對話節點 10-20 秒
- ❌ 5 分鐘以上的戰鬥
### 3. 選擇有重量
> 每個選擇都影響 Build 和劇情
- ✅ 對話選項有系統效果
- ✅ 選擇影響結局分歧
- ❌ 純裝飾性選項
### 4. 愛是雙面刃
> 世界觀的核心：愛讓你變強也變危險
- ✅ 羈絆越深 → 能力越強 → 敵人越多
- ✅ 情感值高 → 傷害高 → 可能失控
- ❌ 單純的「好感度 = 獎勵」
Numerical Design Framework
Basic Principles of Numerical Balance
| Principle | Description | Example |
|---|---|---|
| Symmetry | Resource inflow and outflow should be balanced | Gain X energy per turn, consume X-Y energy |
| Predictable | Players can estimate outcomes | Damage formula is clearly visible |
| Risk/Reward | High risk corresponds to high reward | Emotion value 9-10: Damage +50%, may lose control |
| Growth Curve | Avoid being flat or too steep | Bond level benefits increase progressively but have a cap |
Combat Numerical Template
預期每回合：
├── 資源收入：+X（基礎）+ Y（技能）
├── 資源支出：Z（打出 N 張牌）
├── 傷害輸出：A-B
└── 傷害承受：C-D
預期每場戰鬥（回合數 R）：
├── 總傷害輸出：(A-B) × R = ?
├── 總傷害承受：(C-D) × R = ?
└── 淨收益：資源剩餘、卡牌獲得
敵人設計依據：
├── 普通敵群：HP = 輸出 × 2（2 回合清場）
├── 精英單體：HP = 輸出 × 3-4
└── Boss：HP = 輸出 × 5-7（含多階段）
Document Integration Process
From scattered documents to a unified GDD
┌─────────────────────────────────────────────────────────────┐
│ Step 1: 盤點現有文件 │
│ ├── 列出所有設計相關文件 │
│ ├── 標記每個文件的主題和版本 │
│ └── 識別重複/矛盾的內容 │
├─────────────────────────────────────────────────────────────┤
│ Step 2: 定義權威來源 │
│ ├── 每個主題只有一個權威文件 │
│ ├── 其他文件標記為 deprecated 或合併 │
│ └── 建立術語對照表 │
├─────────────────────────────────────────────────────────────┤
│ Step 3: 建立主文件結構 │
│ ├── 創建 Master Document │
│ ├── 將大型系統拆為 Feature Documents │
│ └── 建立交叉引用連結 │
├─────────────────────────────────────────────────────────────┤
│ Step 4: 內容遷移與整合 │
│ ├── 按優先級整合內容 │
│ ├── 解決矛盾（優先採用最新/最完整版本） │
│ └── 刪除冗餘內容 │
├─────────────────────────────────────────────────────────────┤
│ Step 5: 驗證與清理 │
│ ├── 執行 GDD 審計清單 │
│ ├── 確認版本號一致 │
│ └── 更新所有交叉引用 │
└─────────────────────────────────────────────────────────────┘
Integration Decision Matrix
When contradictions are found, use this decision process:
發現矛盾內容
↓
哪個版本較新？
↓
├── 版本 A 較新 → 傾向採用 A
│
└── 不確定/同時 → 哪個更完整詳細？
↓
├── A 更完整 → 採用 A
│
└── 都不完整 → 重新設計
Sharp Edges
SE-1: GDD Overdesign
- Severity: high
- Scenario: The GDD becomes a hundreds-of-pages document that nobody reads
- Cause: Trying to define all details before development
- Symptoms:
- The team does not read the GDD
- Implementation is severely disconnected from the document
- Updating the GDD becomes a burden
- Solution:
- Adopt a two-layer structure (Master + Feature)
- Keep the Master Document to 10-20 pages
- Only systems in development need detailed Feature Docs
- Use links instead of copy-pasting
SE-2: Design Contradictions
- Severity: critical
- Scenario: The same mechanic has different descriptions in different documents
- Cause: Documents are scattered, with no authoritative source
- Symptoms:
- Developers do not know which version is correct
- Repeated confirmation is needed during implementation
- Everyone insists on their own view during discussions
- Solution:
- Designate an authoritative document for each topic
- Establish a glossary to enforce consistency
- Clearly mark outdated documents as deprecated
- Regularly audit consistency
SE-3: Lack of Design Pillars
- Severity: high
- Scenario: Features pile up but lack direction
- Cause: Core design principles have not been defined
- Symptoms:
- Each feature looks "good" on its own, but the whole lacks focus
- It is difficult to reject new feature requests
- Development priorities are difficult to decide
- Solution:
- Define 3-5 design pillars
- Each pillar has "do/don't" examples
- New features must answer "How does this enhance the core experience?"
Common Issues Checklist
| Issue | Symptom | Solution |
|---|---|---|
| Design Contradictions | The same mechanic has different descriptions in different documents | Designate an authoritative document and unify terminology |
| Lack of Pillars | Features pile up but lack direction | Define design pillars and cut features that do not fit |
| Over-engineering | The document is too long and no one reads it | Split into Feature Docs and keep the main document concise |
| Terminology confusion | The same concept has multiple names | Establish a glossary and enforce consistency |
| Isolated documents | Documents are scattered with no index | Establish a main document index |
Version control rules
版本號格式：vX.Y
X = 主版本（重大結構變更）
Y = 次版本（內容更新/修正）
更新規則：
- 新增章節/系統 → X +1
- 內容修正/補充 → Y +1
- 術語/格式統一 → Y +1
Reference resources
- Nuclino - GDD Template
- Game Design Skills - GDD Guide
- GitBook - How to Write a GDD
- Document360 - GDD Best Practices 2025
- Unity GDD Template
Related fields
- [[game-design]] - Game design theory and mechanics
- [[storytelling]] - Game narrative and script
- [[ui-ux-design]] - Game UI/UX