遊戲設計 Game Design
創造有趣且令人沉浸的遊戲體驗
適用場景
- 遊戲概念設計與 GDD 撰寫
- 核心機制設計與迭代
- 數值系統設計與平衡
- 關卡設計與節奏控制
- 玩家體驗優化
MDA 框架
┌─────────────────────────────────────────────────────────────────┐
│ MDA Framework │
│ │
│ Mechanics → Dynamics → Aesthetics │
│ 機制（規則） 動態（行為） 美學（感受） │
│ │
│ 設計師角度 ─────────────────────────────→ 玩家角度 │
│ │
│ 例： │
│ 跳躍 + 平台 → 時機判斷挑戰 → 成就感、挑戰 │
│ 資源 + 交易 → 市場博弈 → 策略、社交 │
└─────────────────────────────────────────────────────────────────┘
核心知識
8 種美學體驗
| 美學 |
說明 |
遊戲範例 |
| Sensation |
感官刺激 |
音樂遊戲、VR |
| Fantasy |
幻想角色扮演 |
RPG、模擬人生 |
| Narrative |
故事體驗 |
視覺小說、冒險 |
| Challenge |
挑戰克服 |
Dark Souls |
| Fellowship |
社交互動 |
MMO、派對遊戲 |
| Discovery |
探索發現 |
開放世界 |
| Expression |
自我表達 |
Minecraft |
| Submission |
消遣放鬆 |
農場遊戲 |
核心循環
┌─────────────┐
│ 目標 │
└──────┬──────┘
↓
┌─────────────┐
│ 挑戰 │ ← 難度曲線
└──────┬──────┘
↓
┌─────────────┐
│ 行動 │ ← 玩家輸入
└──────┬──────┘
↓
┌─────────────┐
│ 反饋 │ ← 獎勵系統
└──────┬──────┘
↓
(重複)
GDD 大綱
# Game Design Document
## 1. 概述
- 遊戲名稱
- 類型、平台
- 目標受眾
- 核心體驗（一句話）
## 2. 核心機制
- 主要玩法
- 操作方式
- 核心循環
## 3. 進度系統
- 成長曲線
- 解鎖機制
- 長期目標
## 4. 數值系統
- 資源類型
- 平衡公式
- 經濟模型
## 5. 內容規劃
- 關卡設計
- 敵人/NPC
- 物品/裝備
最佳實踐
- 先好玩後完整 - 核心機制要先驗證有趣
- 快速原型 - 盡早做出可玩版本測試
- 玩家測試 - 觀察玩家行為，不要只聽意見
- 減法設計 - 刪掉不必要的功能
- 心流設計 - 挑戰與能力匹配
常見錯誤
| 錯誤 |
正確做法 |
| ❌ 堆砌功能 |
✅ 專注核心體驗 |
| ❌ 只聽玩家說什麼 |
✅ 觀察玩家做什麼 |
| ❌ 一開始就做完整 |
✅ 快速原型迭代 |
| ❌ 難度線性增加 |
✅ 波浪式難度曲線 |
Sharp Edges
SE-1: 經濟系統膨脹
SE-2: 功能堆砌 (Feature Creep)
- 嚴重度: high
- 情境: 遊戲功能越加越多，但核心體驗沒有變好
- 原因: 每個功能單獨看都「不錯」，但累積起來讓遊戲失焦
- 症狀:
- 玩家不知道「這遊戲在玩什麼」
- 教學時間過長
- 每個系統都很淺
- 開發進度不斷延遲
- 解決:
- 定義核心體驗（一句話能說明）
- 每個新功能要問「這如何增強核心體驗？」
- 學會說「不」或「以後再說」
- 減法設計：砍掉不必要的功能
SE-3: Pay-to-Win 設計
- 嚴重度: critical
- 情境: 付費玩家獲得明顯的競爭優勢，傷害免費玩家體驗
- 原因: 短期收入優先於長期留存
- 症狀:
- 免費玩家大量流失
- 玩家社群抱怨聲浪大
- 遊戲評價極低
- 只剩「鯨魚」在玩
- 解決:
- 付費內容限於外觀、便利性
- 付費加速但不能跳過
- 免費玩家也能獲得所有功能（只是較慢）
- 競技模式數值標準化
SE-4: 數值溢出風險
SE-5: 忽略玩家行為只聽玩家意見
- 嚴重度: medium
- 情境: 根據玩家問卷/論壇意見改設計，但結果更差
- 原因: 玩家說的和做的經常不一致
- 症狀:
- 玩家說「太難」但數據顯示通關率正常
- 玩家要求的功能加了但沒人用
- 改了玩家抱怨的地方但留存沒提升
- 解決:
- 觀察玩家「做什麼」比「說什麼」重要
- 用數據驗證假設（A/B 測試）
- 玩家測試時看行為不只看問卷
- 理解抱怨背後的真正問題
工具推薦
- Unity / Unreal - 遊戲引擎
- Machinations - 遊戲經濟模擬
- Figma - UI/UX 設計
- Notion - GDD 文檔管理
數值平衡設計
成長曲線公式
┌─────────────────────────────────────────────────────────────────┐
│ 常用成長公式 │
│ │
│ 線性： value = base + (level × growth) │
│ 指數： value = base × (multiplier ^ level) │
│ 對數： value = base × log(level + offset) │
│ S曲線： value = max / (1 + e^(-k(level - mid))) │
│ │
│ 推薦： │
│ • 玩家屬性：對數曲線（避免後期爆炸） │
│ • 升級經驗：指數曲線（延長遊戲壽命） │
│ • 解鎖內容：S曲線（控制節奏） │
└─────────────────────────────────────────────────────────────────┘
戰鬥數值框架
## 傷害計算範例
基礎傷害 = 攻擊力 × (100 / (100 + 防禦力))
DPS = (基礎傷害 × 暴擊加成) / 攻擊間隔
暴擊加成 = 1 + (暴擊率 × 暴擊倍率)
## 平衡檢查點
- [ ] TTK (Time To Kill) 合理嗎？
- [ ] 高低等級差距是否過大？
- [ ] 是否有數值溢出風險？
- [ ] 各職業/角色是否平衡？
經濟系統設計
| 資源類型 |
獲取難度 |
用途 |
範例 |
| 軟通貨 |
易 |
日常消耗 |
金幣 |
| 硬通貨 |
難 |
稀有物品 |
鑽石 |
| 體力 |
時間 |
限制遊玩 |
行動力 |
| 材料 |
中等 |
製造升級 |
素材 |
關卡設計原則
難度曲線
難度
↑
│ ___
│ / \ /‾‾‾
│ ___/ \____/
│ /
│__/
└──────────────────────→ 進度
波浪式難度：
• 每個高峰後有喘息空間
• 新機制引入後給練習時間
• Boss 前設置檢查點
關卡設計檢查清單
## 關卡設計 Checklist
### 教學設計
- [ ] 新機制有安全環境練習
- [ ] 複雜機制分步驟引入
- [ ] Show, don't tell
### 節奏控制
- [ ] 緊張與放鬆交替
- [ ] 探索與挑戰平衡
- [ ] 適當的檢查點
### 可讀性
- [ ] 路徑清晰可見
- [ ] 危險區域有視覺提示
- [ ] 目標明確
### 重玩性
- [ ] 可探索的秘密區域
- [ ] 多種通關路線
- [ ] 收集要素
玩家心理學
行為激勵
| 激勵類型 |
說明 |
應用 |
| 外在獎勵 |
物質回報 |
金幣、裝備、經驗 |
| 內在獎勵 |
成就感 |
挑戰克服、技能提升 |
| 社交獎勵 |
認同感 |
排行榜、成就展示 |
| 隨機獎勵 |
驚喜感 |
抽卡、掉落 |
玩家留存技巧
┌─────────────────────────────────────────────────────────────────┐
│ Hook Model │
│ │
│ Trigger → Action → Variable Reward → Investment │
│ 觸發 行動 變動獎勵 投入 │
│ ↑ │ │
│ └────────────────────────────────────┘ │
│ │
│ 範例（手遊）： │
│ 推播通知 → 登入遊戲 → 每日抽獎 → 累積天數 │
└─────────────────────────────────────────────────────────────────┘
遊戲原型測試
測試問卷
## 玩家測試問卷
### 基本體驗
1. 遊戲好玩嗎？（1-10）
2. 你會想繼續玩嗎？
3. 一句話描述這遊戲
### 核心機制
4. 操作直覺嗎？
5. 有什麼讓你困惑的地方？
6. 最喜歡的部分是？
7. 最不喜歡的部分是？
### 難度感受
8. 難度合適嗎？
9. 有卡關的地方嗎？
10. 有太簡單無聊的地方嗎？
觀察重點
| 觀察 |
可能問題 |
| 玩家停頓 |
不知道該做什麼 |
| 反覆嘗試 |
機制不直覺或太難 |
| 跳過教學 |
教學太囉嗦 |
| 快速離開 |
核心循環不吸引人 |
遊戲類型設計要點
動作遊戲 (Action)
┌─────────────────────────────────────────────────────────────────┐
│ 動作遊戲核心要素 │
│ │
│ ┌──────────────┐ │
│ │ 操作手感 │ ← 60fps、輸入延遲 < 100ms │
│ └──────┬───────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ 視覺/音效反饋│ ← 打擊感 = 頓幀 + 震動 + 特效 + 音效 │
│ └──────┬───────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ 敵人設計 │ ← 清晰的攻擊前搖、可讀性 │
│ └──────────────┘ │
│ │
│ 打擊感公式： │
│ • 攻擊命中 → 頓幀 2-4 幀 │
│ • 同時播放打擊音效 + 粒子特效 │
│ • 敵人播放受傷動畫 + 擊退 │
│ • 相機輕微震動（可選） │
└─────────────────────────────────────────────────────────────────┘
RPG 角色扮演
## RPG 系統設計清單
### 角色成長
- [ ] 等級系統（經驗值獲取平衡）
- [ ] 技能樹設計（有意義的選擇）
- [ ] 裝備系統（數值 vs 外觀）
- [ ] 職業/轉職系統
### 戰鬥系統
- [ ] 回合制 vs 即時制 vs ATB
- [ ] 屬性相剋系統
- [ ] 技能組合/連攜
- [ ] 狀態異常設計
### 世界觀
- [ ] 主線劇情結構
- [ ] 支線任務設計
- [ ] NPC 互動深度
- [ ] 探索獎勵機制
### 數值平衡
| 階段 | 玩家 HP | 敵人 HP | 戰鬥時長 |
|------|---------|---------|----------|
| 初期 | 100 | 30-50 | 10-30 秒 |
| 中期 | 500 | 200-400 | 30-60 秒 |
| 後期 | 2000 | 1000+ | 1-3 分鐘 |
| Boss | - | 玩家 5-10 倍 | 3-10 分鐘 |
解謎遊戲 (Puzzle)
┌─────────────────────────────────────────────────────────────────┐
│ 謎題設計原則 │
│ │
│ 1. 漸進式複雜度 │
│ 簡單 → 變體 → 組合 → 反轉 │
│ │
│ 2. 公平性 │
│ • 所有線索在謎題前已提供 │
│ • 解法符合邏輯，無需猜測 │
│ • 避免「pixel hunting」 │
│ │
│ 3. 「啊哈」時刻設計 │
│ 難度 = 資訊隱藏程度 × 邏輯步驟數 │
│ │
│ 4. 提示系統 │
│ ┌─────────────────────────────────────────────┐ │
│ │ 等級 1：方向性提示「注意那個角落」 │ │
│ │ 等級 2：具體提示「試著移動那個箱子」 │ │
│ │ 等級 3：直接解答「把箱子推到開關上」 │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Roguelike / Roguelite
## Roguelike 核心設計
### 隨機性平衡
| 元素 | 隨機程度 | 說明 |
|------|----------|------|
| 地圖佈局 | 高 | 程序生成 |
| 敵人配置 | 中 | 難度遞增 |
| 物品掉落 | 中-高 | Build 多樣性 |
| Boss 機制 | 低 | 可學習模式 |
| 核心機制 | 無 | 玩家可掌握 |
### Meta 進度設計
┌────────────────────────────────────────────────────┐
│ 單局內 │ 跨局（永久） │
├────────────────┼──────────────────────────────────┤
│ 獲得強化道具 │ 解鎖新角色/武器 │
│ 臨時能力提升 │ 永久屬性加成 │
│ 資源累積 │ 起始資源增加 │
│ 局內成長感 │ 長期目標 + 多樣性 │
└────────────────────────────────────────────────────┘
### Build 設計
• 每個道具獨立有用
• 道具組合產生協同效應 (Synergy)
• 極端 Build 應該可行但有風險
• 避免「必選」道具（所有選項都應有價值）
手機遊戲 (Mobile)
┌─────────────────────────────────────────────────────────────────┐
│ 手遊設計考量 │
│ │
│ 操作限制： │
│ • 單手可玩優先 │
│ • 虛擬搖桿避免太複雜 │
│ • 點擊優於滑動 │
│ │
│ 遊戲時長： │
│ • 單局 3-5 分鐘（碎片化） │
│ • 可隨時暫停/儲存 │
│ • 離線獎勵機制 │
│ │
│ 變現設計： │
│ ┌──────────────┬──────────────────────────────────┐ │
│ │ 模式 │ 說明 │ │
│ ├──────────────┼──────────────────────────────────┤ │
│ │ 付費買斷 │ Premium，一次付費 │ │
│ │ 內購 (IAP) │ 道具、外觀、VIP │ │
│ │ 廣告 │ 激勵廣告、插頁廣告 │ │
│ │ 訂閱 │ 月費會員特權 │ │
│ │ Battle Pass │ 賽季通行證 │ │
│ └──────────────┴──────────────────────────────────┘ │
│ │
│ 付費設計原則： │
│ ✓ 付費 ≠ 獲勝（Pay to Win 傷害留存） │
│ ✓ 免費玩家也要有良好體驗 │
│ ✓ 付費內容要有明確價值感 │
└─────────────────────────────────────────────────────────────────┘
敘事設計
互動敘事結構
┌─────────────────────────────────────────────────────────────────┐
│ 敘事結構類型 │
│ │
│ 1. 線性敘事 │
│ A → B → C → D → 結局 │
│ 優點：故事緊湊，開發成本低 │
│ 缺點：重玩價值低 │
│ │
│ 2. 分支敘事 │
│ ┌→ B1 ─→ C1 ─→ 結局 A │
│ A ───┼→ B2 ─→ C2 ─→ 結局 B │
│ └→ B3 ─────────→ 結局 C │
│ 優點：玩家有選擇感，重玩價值高 │
│ 缺點：內容開發量大 │
│ │
│ 3. 聚合式分支 │
│ ┌→ B1 ─┐ │
│ A ───┼→ B2 ─┼→ C → D → 結局 │
│ └→ B3 ─┘ │
│ 優點：有選擇感，但收斂到主線 │
│ 缺點：玩家可能感覺選擇無意義 │
│ │
│ 4. 開放世界敘事 │
│ 主線任務 + 多條支線並行 │
│ 玩家自由選擇順序 │
│ 世界狀態隨選擇改變 │
└─────────────────────────────────────────────────────────────────┘
對話系統設計
## 對話樹設計原則
### 玩家選項設計
✅ 好的選項：
- 性格鮮明（善良/中立/邪惡）
- 有明確後果（影響關係/劇情）
- 反映玩家意圖
❌ 避免：
- 三個選項說同樣的話
- 假選擇（結果都一樣）
- 選項文字與實際對話不符
### 對話節奏
• 單句對話 ≤ 2 行
• 重要資訊要有視覺強調
• 允許跳過但保留重要資訊
• NPC 個性要在對話中體現
### 變數追蹤
```yaml
# 對話系統需要追蹤的變數
player_choices:
helped_merchant: true
sided_with_rebels: false
relationship_values:
companion_a: 75 # -100 到 100
faction_b: -20
story_flags:
act1_completed: true
secret_discovered: false
---
## UI/UX 設計
### 遊戲 UI 原則
┌─────────────────────────────────────────────────────────────────┐
│ 遊戲 UI 層級 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Diegetic UI │ │
│ │ 存在於遊戲世界中（如：Dead Space 的背部血條） │ │
│ │ 優點：沉浸感強 │ │
│ │ 缺點：不易讀取 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Non-Diegetic UI (HUD) │ │
│ │ 純粹介面元素（如：血條、小地圖） │ │
│ │ 優點：資訊清晰 │ │
│ │ 缺點：可能影響沉浸 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Spatial UI │ │
│ │ 存在於 3D 空間但不屬於世界（如：敵人頭上的血條） │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 設計要點： │
│ • 重要資訊放在視覺焦點區域 │
│ • 動態元素要有動畫過渡 │
│ • 顏色要有高對比度（紅=危險、綠=安全） │
│ • 支援色盲模式 │
└─────────────────────────────────────────────────────────────────┘
### 新手引導設計
┌─────────────────────────────────────────────────────────────────┐
│ 教學設計金字塔 │
│ │
│ ┌─────────────┐ │
│ │ 強制教學 │ ← 只用於最核心機制 │
│ └──────┬──────┘ │
│ ┌───────┴───────┐ │
│ │ 提示引導 │ ← 視覺提示、箭頭 │
│ └───────┬───────┘ │
│ ┌───────────┴───────────┐ │
│ │ 環境引導 │ ← 關卡設計暗示 │
│ └───────────┬───────────┘ │
│ ┌───────────────┴───────────────┐ │
│ │ 自由探索 │ ← 玩家自行發現 │
│ └───────────────────────────────┘ │
│ │
│ 原則： │
│ • 能用關卡設計教的，不用 UI 教 │
│ • 能用 UI 教的，不用文字教 │
│ • 讓玩家「做」而不是「看」 │
│ • 失敗也是學習（但要給明確反饋） │
└─────────────────────────────────────────────────────────────────┘
---
## 多人遊戲設計
### 網路架構選擇
```markdown
## 網路模型比較
| 模型 | 說明 | 適用 | 延遲容忍 |
|------|------|------|----------|
| **P2P** | 玩家直連 | 格鬥、賽車 | 低 |
| **Client-Server** | 中央伺服器 | MMO、FPS | 中 |
| **Rollback** | 預測+回滾 | 格鬥遊戲 | 最低 |
| **Lockstep** | 同步輸入 | RTS | 中 |
## 常見問題處理
### 延遲補償
- 客戶端預測（本地先執行）
- 伺服器權威（Server Authoritative）
- 插值顯示（Interpolation）
- 命中判定回溯（Lag Compensation）
### 防作弊
□ 關鍵邏輯在伺服器端
□ 輸入驗證
□ 資料加密
□ 異常行為偵測
匹配系統設計
┌─────────────────────────────────────────────────────────────────┐
│ Elo / MMR 匹配系統 │
│ │
│ 基本公式： │
│ 新 Rating = 舊 Rating + K × (實際結果 - 預期結果) │
│ │
│ K 值選擇： │
│ • 新玩家：K = 32（快速調整） │
│ • 老玩家：K = 16（穩定） │
│ │
│ 匹配優先級： │
│ 1. Rating 相近（±100 以內） │
│ 2. 等待時間（>30秒放寬範圍） │
│ 3. 地理位置（延遲考量） │
│ │
│ 保護機制： │
│ • 新手保護（前 N 場不扣分） │
│ • 連敗保護（降低扣分） │
│ • 段位保護（不會掉出段位） │
└─────────────────────────────────────────────────────────────────┘
遊戲商業模式
營運指標
## 關鍵指標 (KPI)
### 用戶指標
| 指標 | 說明 | 健康值 |
|------|------|--------|
| **DAU/MAU** | 日活/月活比 | 20-30% |
| **D1/D7/D30** | 次日/7日/30日留存 | 40%/20%/10% |
| **Session** | 平均遊玩時長 | 因類型而異 |
| **Stickiness** | 黏著度 | DAU/MAU > 20% |
### 營收指標
| 指標 | 說明 | 計算 |
|------|------|------|
| **ARPU** | 平均每用戶收入 | 總收入/總用戶 |
| **ARPPU** | 付費用戶收入 | 總收入/付費用戶 |
| **LTV** | 用戶終身價值 | ARPU × 生命週期 |
| **Conversion** | 付費轉換率 | 付費用戶/總用戶 |
### 健康公式
LTV > CPI × 3（用戶終身價值 > 獲客成本 × 3）
Live Service 設計
┌─────────────────────────────────────────────────────────────────┐
│ 內容更新節奏 │
│ │
│ 週更新： │
│ • 每日任務刷新 │
│ • 週常活動 │
│ • 商店輪換 │
│ │
│ 月更新： │
│ • 新角色/武器 │
│ • 限時活動 │
│ • Battle Pass 賽季 │
│ │
│ 季更新： │
│ • 大型版本更新 │
│ • 新遊戲模式 │
│ • 主線劇情 │
│ │
│ 內容規劃表： │
│ ┌────┬────────┬────────┬────────┬────────┐ │
│ │週次│ 活動 │ 角色 │ 商店 │ 劇情 │ │
│ ├────┼────────┼────────┼────────┼────────┤ │
│ │ 1 │ 新春 │ 角色A │ 皮膚包 │ │ │
│ │ 2 │ │ │ 武器包 │ │ │
│ │ 3 │ 情人節 │ │ │ Ch.5 │ │
│ │ 4 │ │ 角色B │ │ │ │
│ └────┴────────┴────────┴────────┴────────┘ │
└─────────────────────────────────────────────────────────────────┘
AI 輔助遊戲設計
程序生成內容 (PCG)
## PCG 應用場景
| 元素 | 方法 | 範例 |
|------|------|------|
| **地圖** | Wave Function Collapse | Spelunky |
| **關卡** | 規則系統 + 隨機種子 | Diablo |
| **敵人配置** | 難度曲線 + 隨機選擇 | Left 4 Dead |
| **對話** | LLM 生成 | AI Dungeon |
| **任務** | 模板 + 變數替換 | Radiant Quests |
| **名字/描述** | Markov Chain / LLM | Dwarf Fortress |
## PCG 設計原則
1. 設定合理的約束（避免不可能的生成）
2. 保證最低品質（過濾不合理結果）
3. 保留手工設計的關鍵內容
4. 種子系統（可復現的隨機）
AI 驅動的 NPC
┌─────────────────────────────────────────────────────────────────┐
│ NPC AI 層級 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 行為樹 (Behavior Tree) │ │
│ │ 傳統 AI，可預測，適合敵人 AI │ │
│ │ │ │
│ │ Selector → Sequence → Action │ │
│ │ ↓ │ │
│ │ [攻擊] → [追擊] → [巡邏] │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 狀態機 (FSM) │ │
│ │ 簡單直覺，適合基礎 NPC │ │
│ │ │ │
│ │ [待機] ←──→ [警戒] ←──→ [攻擊] │ │
│ │ ↑ ↓ │ │
│ │ └──── [逃跑] ←┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ LLM 驅動 NPC（實驗性） │ │
│ │ 動態對話、個性化反應 │ │
│ │ 挑戰：成本、延遲、一致性 │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
遊戲開發流程
開發階段
┌─────────────────────────────────────────────────────────────────┐
│ 遊戲開發生命週期 │
│ │
│ 概念期 (Concept) 1-2 週 │
│ ├─ 遊戲概念文檔 │
│ ├─ 市場研究 │
│ └─ 可行性評估 │
│ │
│ 原型期 (Prototype) 2-4 週 │
│ ├─ 核心機制原型 │
│ ├─ 玩法驗證 │
│ └─ 技術風險評估 │
│ │
│ 前製期 (Pre-Production) 1-3 個月 │
│ ├─ GDD 完整化 │
│ ├─ 美術風格確定 │
│ ├─ 技術架構設計 │
│ └─ 垂直切片 (Vertical Slice) │
│ │
│ 製作期 (Production) 6-18 個月 │
│ ├─ 內容製作 │
│ ├─ 迭代優化 │
│ └─ Alpha/Beta 測試 │
│ │
│ 後製期 (Post-Production) 1-2 個月 │
│ ├─ 除錯 (Bug Fix) │
│ ├─ 優化 (Optimization) │
│ └─ 認證 (Certification) │
│ │
│ 上市後 (Live) 持續 │
│ ├─ 營運活動 │
│ ├─ 內容更新 │
│ └─ 社群維護 │
└─────────────────────────────────────────────────────────────────┘
敏捷遊戲開發
## Scrum 在遊戲開發的應用
### Sprint 週期
- 建議 2 週一個 Sprint
- 每個 Sprint 要有可玩的產出
### 每日站會
1. 昨天做了什麼
2. 今天要做什麼
3. 有什麼阻礙
### 遊戲開發特殊考量
| 挑戰 | 解決方案 |
|------|----------|
| 難以估計工時 | 使用故事點而非小時 |
| 創意需要探索 | 留出「Spike」時間 |
| 跨部門依賴 | 明確的交付物規格 |
| 玩法驗證 | 每 Sprint 內部測試 |
### DoD (Definition of Done)
□ 功能完成
□ 無已知 Bug
□ 通過 QA 測試
□ 程式碼審查
□ 文檔更新
相關資源
相關領域
- [[storytelling]] - 遊戲敘事與劇本
- [[visual-media]] - 遊戲美術與動畫
- [[ui-ux-design]] - 遊戲 UI/UX