Game Planner

遊戲企劃 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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: miles990
• Source: miles990/claude-domain-skills
• License: MIT

Install and usage instructions live in the source repository linked above.