Menu
專業遊戲企劃框架，產出業界標準的遊戲設計文件 (GDD)
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
非技術領域專業知識集合，包含商業、金融、創意、專業服務、生活、方法論等 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