Menu
專業遊戲企劃框架，產出業界標準的遊戲設計文件 (GDD)
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
非技術領域專業知識集合，包含商業、金融、創意、專業服務、生活、方法論等 18 個領域
數位行銷策略、內容行銷與成效分析
產品管理：PRD撰寫、用戶故事、OKR設定、路線圖規劃
專案管理：敏捷開發、Scrum、甘特圖、風險管理、團隊協作
銷售技巧：B2B/B2C 銷售、客戶開發、電商營運、成交策略
商業策略：藍海策略、差異化、競爭優勢、價值創新、商業模式設計
| schema | 1.0 |
| name | game-planner |
| version | 1.0.0 |
| description | 專業遊戲企劃框架，產出業界標準的遊戲設計文件 (GDD) |
| domain | creative |
| triggers | {"keywords":{"primary":["GDD","遊戲企劃","遊戲設計文件","game design document","設計支柱","design pillars"],"secondary":["feature document","功能文件","GDD審計","文件整合","consolidate","遊戲機制設計"]},"context_boost":["企劃","文件","document","架構","設計"],"context_penalty":["程式","coding","美術","art"],"priority":"high"} |
| dependencies | {"domain-skills":["game-design","storytelling"]} |
| author | claude-domain-skills |
專業遊戲企劃框架 — 產出業界標準的遊戲設計文件 (GDD)
/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 [系統] # 數值平衡分析
業界共識：沒有單一標準格式，但有共同原則：
| 原則 | 說明 |
|---|---|
| Living Document | 持續更新的活文件，不是一次性產物 |
| Agile & Lightweight | 敏捷輕量，避免數百頁沒人看 |
| Findable | 資訊可被快速找到 |
| Visual | 遊戲是視覺媒體，文件也要視覺化 |
┌─────────────────────────────────────────────────────────────┐
│ Master Document (主文件) │
│ ├── 執行摘要、願景、設計支柱 │
│ ├── 核心玩法概覽 │
│ └── 連結到各 Feature Documents │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ Feature Documents (功能文件) │
│ ├── 戰鬥系統 │
│ ├── 角色系統 │
│ ├── 經濟系統 │
│ └── ... │
└─────────────────────────────────────────────────────────────┘
| 章節 | 內容 | 優先級 |
|---|---|---|
| 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
## 設計目標
> 這個系統要解決什麼問題？帶來什麼體驗？
## 核心機制
### 基礎規則
### 數值設計
### 特殊情況
## 玩家體驗
### 預期感受
### 風險與負面體驗
## 與其他系統的關係
### 依賴系統
### 影響系統
## 實作優先級 (LoQ)
| 層級 | 內容 | 狀態 |
|------|------|------|
| Core | 最小可玩版本 | |
| Expected | 玩家預期功能 | |
| Desired | 加分功能 | |
| Aspirational | 理想狀態 | |
## 變更記錄
| 版本 | 日期 | 變更 |
|------|------|------|
┌─────────────────────────────────────────────────────────────┐
│ GDD 審計清單 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ▣ 執行摘要 │
│ □ 遊戲名稱與標語 │
│ □ 類型明確定義 │
│ □ 目標平台 │
│ □ 目標受眾 │
│ □ 電梯簡報（30秒版本） │
│ □ 獨特賣點 (USP) │
│ │
│ ▣ 設計支柱 │
│ □ 3-5 個核心設計原則 │
│ □ 每個支柱有清楚的「做/不做」範例 │
│ │
│ ▣ 核心玩法 │
│ □ 玩法循環圖 │
│ □ 勝利/失敗條件 │
│ □ 操作方式（每平台） │
│ □ 目標遊戲時長 │
│ │
│ ▣ 遊戲機制 │
│ □ 每個核心系統有 Feature Document │
│ □ 系統間的依賴關係明確 │
│ □ 數值設計有理論基礎 │
│ │
│ ▣ 一致性檢查 │
│ □ 術語統一（術語表存在） │
│ □ 版本號一致 │
│ □ 無相互矛盾的描述 │
│ □ 所有連結有效 │
│ │
└─────────────────────────────────────────────────────────────┘
設計支柱是 3-5 個核心原則，用來指導所有設計決策。
好的設計支柱特徵：
壞的設計支柱：
### 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（含多階段）
┌─────────────────────────────────────────────────────────────┐
│ Step 1: 盤點現有文件 │
│ ├── 列出所有設計相關文件 │
│ ├── 標記每個文件的主題和版本 │
│ └── 識別重複/矛盾的內容 │
├─────────────────────────────────────────────────────────────┤
│ Step 2: 定義權威來源 │
│ ├── 每個主題只有一個權威文件 │
│ ├── 其他文件標記為 deprecated 或合併 │
│ └── 建立術語對照表 │
├─────────────────────────────────────────────────────────────┤
│ Step 3: 建立主文件結構 │
│ ├── 創建 Master Document │
│ ├── 將大型系統拆為 Feature Documents │
│ └── 建立交叉引用連結 │
├─────────────────────────────────────────────────────────────┤
│ Step 4: 內容遷移與整合 │
│ ├── 按優先級整合內容 │
│ ├── 解決矛盾（優先採用最新/最完整版本） │
│ └── 刪除冗餘內容 │
├─────────────────────────────────────────────────────────────┤
│ Step 5: 驗證與清理 │
│ ├── 執行 GDD 審計清單 │
│ ├── 確認版本號一致 │
│ └── 更新所有交叉引用 │
└─────────────────────────────────────────────────────────────┘
當發現矛盾時，使用此決策流程：
發現矛盾內容
↓
哪個版本較新？
↓
├── 版本 A 較新 → 傾向採用 A
│
└── 不確定/同時 → 哪個更完整詳細？
↓
├── A 更完整 → 採用 A
│
└── 都不完整 → 重新設計
| 問題 | 症狀 | 解決方案 |
|---|---|---|
| 設計矛盾 | 同一機制在不同文件有不同描述 | 指定權威文件，統一術語 |
| 缺乏支柱 | 功能堆疊但缺乏方向 | 定義設計支柱，砍掉不符的功能 |
| 過度設計 | 文件太長沒人看 | 拆分 Feature Doc，保持主文件精簡 |
| 術語混亂 | 同一概念多種叫法 | 建立術語表，強制統一 |
| 孤島文件 | 文件散落沒有索引 | 建立主文件索引 |
版本號格式：vX.Y
X = 主版本（重大結構變更）
Y = 次版本（內容更新/修正）
更新規則：
- 新增章節/系統 → X +1
- 內容修正/補充 → Y +1
- 術語/格式統一 → Y +1