/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 [系統]    # 數值平衡分析

核心理念

GDD 的現代哲學

業界共識：沒有單一標準格式，但有共同原則：

原則	說明
Living Document	持續更新的活文件，不是一次性產物
Agile & Lightweight	敏捷輕量，避免數百頁沒人看
Findable	資訊可被快速找到
Visual	遊戲是視覺媒體，文件也要視覺化

兩層架構設計

┌─────────────────────────────────────────────────────────────┐
│  Master Document (主文件)                                    │
│  ├── 執行摘要、願景、設計支柱                                │
│  ├── 核心玩法概覽                                           │
│  └── 連結到各 Feature Documents                             │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Feature Documents (功能文件)                                │
│  ├── 戰鬥系統                                               │
│  ├── 角色系統                                               │
│  ├── 經濟系統                                               │
│  └── ...                                                    │
└─────────────────────────────────────────────────────────────┘

GDD 標準結構

Master Document 必要章節

章節	內容	優先級
1. 執行摘要	一頁概覽：遊戲名、類型、平台、目標受眾、電梯簡報	P0 必要
2. 設計支柱	3-5 個核心設計原則，所有決策的依據	P0 必要
3. 核心玩法	玩法循環、勝負條件、操作方式	P0 必要
4. 遊戲機制	各系統概述（連結 Feature Doc）	P0 必要
5. 敘事與世界觀	故事大綱、設定概要	P1 重要
6. 角色設計	主要角色概覽	P1 重要
7. 關卡設計	關卡結構、進程設計	P1 重要
8. UI/UX 設計	介面流程、HUD 設計	P1 重要
9. 音樂音效	音頻風格指引	P2 輔助
10. 商業模式	定價、獲利策略	P1 重要
11. 開發計畫	里程碑、時程	P1 重要
12. 風險評估	潛在風險與應對	P2 輔助

Feature Document 模板

# [系統名稱] Feature Document

## 設計目標
> 這個系統要解決什麼問題？帶來什麼體驗？

## 核心機制
### 基礎規則
### 數值設計
### 特殊情況

## 玩家體驗
### 預期感受
### 風險與負面體驗

## 與其他系統的關係
### 依賴系統
### 影響系統

## 實作優先級 (LoQ)
| 層級 | 內容 | 狀態 |
|------|------|------|
| Core | 最小可玩版本 | |
| Expected | 玩家預期功能 | |
| Desired | 加分功能 | |
| Aspirational | 理想狀態 | |

## 變更記錄
| 版本 | 日期 | 變更 |
|------|------|------|

GDD 審計檢查清單

┌─────────────────────────────────────────────────────────────┐
│  GDD 審計清單                                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ▣ 執行摘要                                                 │
│    □ 遊戲名稱與標語                                         │
│    □ 類型明確定義                                           │
│    □ 目標平台                                               │
│    □ 目標受眾                                               │
│    □ 電梯簡報（30秒版本）                                   │
│    □ 獨特賣點 (USP)                                         │
│                                                             │
│  ▣ 設計支柱                                                 │
│    □ 3-5 個核心設計原則                                     │
│    □ 每個支柱有清楚的「做/不做」範例                        │
│                                                             │
│  ▣ 核心玩法                                                 │
│    □ 玩法循環圖                                             │
│    □ 勝利/失敗條件                                          │
│    □ 操作方式（每平台）                                     │
│    □ 目標遊戲時長                                           │
│                                                             │
│  ▣ 遊戲機制                                                 │
│    □ 每個核心系統有 Feature Document                        │
│    □ 系統間的依賴關係明確                                   │
│    □ 數值設計有理論基礎                                     │
│                                                             │
│  ▣ 一致性檢查                                               │
│    □ 術語統一（術語表存在）                                 │
│    □ 版本號一致                                             │
│    □ 無相互矛盾的描述                                       │
│    □ 所有連結有效                                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

設計支柱範例

什麼是設計支柱？

設計支柱是 3-5 個核心原則，用來指導所有設計決策。

好的設計支柱特徵：

✅ 可以用來拒絕不符的功能
✅ 團隊成員都能用它做決策
✅ 獨特於這個專案（不是廢話）

壞的設計支柱：

❌ 「要好玩」— 廢話
❌ 「畫面要漂亮」— 不可衡量
❌ 「玩家會喜歡」— 不可操作

範例：Dead Romance 設計支柱

### 1. 敘事與系統融合
> 玩家不應感覺在「切換遊戲類型」

- ✅ 對話選擇 = 獲得卡牌
- ✅ 羈絆等級 = 解鎖能力
- ❌ 分離的「劇情模式」和「戰鬥模式」

### 2. 短節奏循環
> 保持 Galgame 的敘事節奏

- ✅ 戰鬥 60-90 秒（3-5 回合）
- ✅ 對話節點 10-20 秒
- ❌ 5 分鐘以上的戰鬥

### 3. 選擇有重量
> 每個選擇都影響 Build 和劇情

- ✅ 對話選項有系統效果
- ✅ 選擇影響結局分歧
- ❌ 純裝飾性選項

### 4. 愛是雙面刃
> 世界觀的核心：愛讓你變強也變危險

- ✅ 羈絆越深 → 能力越強 → 敵人越多
- ✅ 情感值高 → 傷害高 → 可能失控
- ❌ 單純的「好感度 = 獎勵」

數值設計框架

數值平衡的基本原則

原則	說明	範例
對稱性	資源進出應平衡	每回合獲得 X 能量，消耗 X-Y 能量
可預測	玩家能估算結果	傷害公式清晰可見
風險/報酬	高風險對應高報酬	情感值 9-10：傷害 +50%，可能失控
成長曲線	避免平坦或過陡	羈絆等級效益遞增但有上限

戰鬥數值模板

預期每回合：
├── 資源收入：+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（含多階段）

文件整合流程

從散落文件到統一 GDD

┌─────────────────────────────────────────────────────────────┐
│  Step 1: 盤點現有文件                                        │
│  ├── 列出所有設計相關文件                                   │
│  ├── 標記每個文件的主題和版本                               │
│  └── 識別重複/矛盾的內容                                    │
├─────────────────────────────────────────────────────────────┤
│  Step 2: 定義權威來源                                        │
│  ├── 每個主題只有一個權威文件                               │
│  ├── 其他文件標記為 deprecated 或合併                       │
│  └── 建立術語對照表                                         │
├─────────────────────────────────────────────────────────────┤
│  Step 3: 建立主文件結構                                      │
│  ├── 創建 Master Document                                   │
│  ├── 將大型系統拆為 Feature Documents                       │
│  └── 建立交叉引用連結                                       │
├─────────────────────────────────────────────────────────────┤
│  Step 4: 內容遷移與整合                                      │
│  ├── 按優先級整合內容                                       │
│  ├── 解決矛盾（優先採用最新/最完整版本）                    │
│  └── 刪除冗餘內容                                           │
├─────────────────────────────────────────────────────────────┤
│  Step 5: 驗證與清理                                          │
│  ├── 執行 GDD 審計清單                                      │
│  ├── 確認版本號一致                                         │
│  └── 更新所有交叉引用                                       │
└─────────────────────────────────────────────────────────────┘

整合決策矩陣

當發現矛盾時，使用此決策流程：

發現矛盾內容
    ↓
哪個版本較新？
    ↓
    ├── 版本 A 較新 → 傾向採用 A
    │
    └── 不確定/同時 → 哪個更完整詳細？
                          ↓
                          ├── A 更完整 → 採用 A
                          │
                          └── 都不完整 → 重新設計

Sharp Edges

SE-1: GDD 過度設計

嚴重度: high
情境: GDD 變成數百頁沒人看的文件
原因: 試圖在開發前定義所有細節
症狀:
- 團隊不看 GDD
- 實作與文件嚴重脫節
- 更新 GDD 成為負擔
解決:
- 採用兩層架構（Master + Feature）
- Master Document 控制在 10-20 頁
- 只有開發中的系統需要詳細 Feature Doc
- 使用連結而非複製貼上

SE-2: 設計矛盾

嚴重度: critical
情境: 同一機制在不同文件有不同描述
原因: 文件散落，沒有權威來源
症狀:
- 開發者不知道哪個版本正確
- 實作時需要反覆確認
- 討論時各執一詞
解決:
- 指定每個主題的權威文件
- 建立術語表強制統一
- 過時文件明確標記 deprecated
- 定期審計一致性

SE-3: 缺乏設計支柱

嚴重度: high
情境: 功能堆疊但缺乏方向
原因: 沒有定義核心設計原則
症狀:
- 每個功能單獨看「不錯」但整體失焦
- 難以拒絕新功能請求
- 開發優先級難以決定
解決:
- 定義 3-5 個設計支柱
- 每個支柱有「做/不做」範例
- 新功能必須回答「這如何增強核心體驗？」

常見問題清單

問題	症狀	解決方案
設計矛盾	同一機制在不同文件有不同描述	指定權威文件，統一術語
缺乏支柱	功能堆疊但缺乏方向	定義設計支柱，砍掉不符的功能
過度設計	文件太長沒人看	拆分 Feature Doc，保持主文件精簡
術語混亂	同一概念多種叫法	建立術語表，強制統一
孤島文件	文件散落沒有索引	建立主文件索引

版本控制規則

版本號格式：vX.Y

X = 主版本（重大結構變更）
Y = 次版本（內容更新/修正）

更新規則：
- 新增章節/系統 → X +1
- 內容修正/補充 → Y +1
- 術語/格式統一 → Y +1

核心理念

GDD 的現代哲學

兩層架構設計

GDD 標準結構

Master Document 必要章節

Feature Document 模板

GDD 審計檢查清單

設計支柱範例

什麼是設計支柱？

範例：Dead Romance 設計支柱

數值設計框架

數值平衡的基本原則

戰鬥數值模板

文件整合流程

從散落文件到統一 GDD

整合決策矩陣

Sharp Edges

SE-1: GDD 過度設計

SE-2: 設計矛盾

SE-3: 缺乏設計支柱

常見問題清單

版本控制規則

參考資源

相關領域

game-planner

遊戲企劃 Game Planner

適用場景

快速指令