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 的現代哲學

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

兩層架構設計

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

GDD 標準結構

Master Document 必要章節

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（基礎）+ 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 個設計支柱
  • 每個支柱有「做/不做」範例
  • 新功能必須回答「這如何增強核心體驗？」

常見問題清單

版本控制規則

版本號格式：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