game-planner
SKILL.md
遊戲企劃 Game Planner
專業遊戲企劃框架 — 產出業界標準的遊戲設計文件 (GDD)
適用場景
- GDD 初始化與架構設計
- 散落設計文件整合
- GDD 完整性審計
- Feature Document 撰寫
- 數值平衡設計框架
快速指令
/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
參考資源
- Nuclino - GDD Template
- Game Design Skills - GDD Guide
- GitBook - How to Write a GDD
- Document360 - GDD Best Practices 2025
- Unity GDD Template
相關領域
- [[game-design]] - 遊戲設計理論與機制
- [[storytelling]] - 遊戲敘事與劇本
- [[ui-ux-design]] - 遊戲 UI/UX