3A 級遊戲開發文件（GDD）技能
路徑約定：本文件中所有
scripts/、references/、assets/都相對於本 SKILL.md 所在目錄。 執行python scripts/new_gdd.py前先定位該目錄（Cursor/Codex 由install.ps1裝到<專案>/skills/game-dev/aaa-game-gdd/）。 如果不確定，先找到本 SKILL.md 的絕對路徑，再用絕對路徑呼叫腳本；在專案根目錄直接敲相對路徑會造成 file-not-found。
這個技能做什麼
把「我有個遊戲點子」變成「團隊照著文件直接開發就能做出可上架 Steam、對標 3A 的遊戲」的整套文件。核心交付物是一套結構化、量化、可驗收的中文 Markdown 文件（GDD），而不是一份泛泛而談的策劃案。
產出的每份文件必須滿足三條鐵律：
- 可開發：開發拿到文件不需要追問「具體做什麼、做多大、什麼標準」。一切可量化的東西都寫死數值（面數、幀數、時長、解析度、頻率、延遲、觸發條件）。
- 可驗收：每份資產、每個系統、每個場景都有 Definition of Done（完成定義）檢查表，做完能逐條打勾判定。
- 一致性：所有文件共享同一份願景支柱、美術聖經、命名規範、效能預算；文件之間互相引用編號，禁止互相矛盾。
文件地圖（references 按需讀取）
不要一次性讀完所有參考文件。先按下表確定使用者要做哪類文件，再只讀對應的那一篇。每篇 reference 的結構都是：解決什麼問題 → 何時寫 → 章節結構 → 每章怎麼寫（含量化標準）→ 好壞範例 → 完成定義檢查表。
| 文件 | 何時讀這篇 reference | 對應模板（assets/templates） |
|---|---|---|
| 00 文件體系總覽 | 新專案立項、需要確定文件清單與階段計劃 | README.md |
| 01 願景與 Pitch | 專案剛有想法、需要一頁紙講清遊戲、對外路演 | 01-vision-pitch.md |
| 02 美術聖經 | 定美術風格、統一團隊審美、出美術需求 | 02-art-bible.md |
| 03 場景與關卡 | 寫場景描述、關卡流程、動線、遭遇、環境敘事 | 03-scene-level.md、scene-sheet.md、level-sheet.md |
| 04 玩法系統 | 設計核心循環、戰鬥、養成、經濟、數值表 | 04-gameplay-systems.md、system-sheet.md |
| 05 劇情與台詞 | 寫故事大綱、章節 beat、分支、台詞腳本、配音 | 05-narrative-dialogue.md、dialogue-sheet.md |
| 06 交互與 UI/UX | 定操作、交互矩陣、遊戲手感、HUD、選單、可及性 | 06-interaction-uiux.md |
| 07 角色規格 | 主角/敵人/NPC 的設定、外觀、動作集、AI、數值 | 07-character-spec.md、character-sheet.md |
| 08 物品建模規格 | 道具/武器/環境資產的建模、貼圖、LOD、命名交付 | 08-prop-modeling.md、prop-sheet.md |
| 09 動畫規格 | 3D 骨骼動畫、動畫狀態機、過場、2D 幀動畫 | 09-animation-spec.md、animation-sheet.md |
| 10 音訊設計 | 音樂、音效、配音、動態音樂、總線響度 | 10-audio-spec.md |
| 11 技術與效能 | 引擎選型、渲染管線、幀率/記憶體/包體預算、平台 | 11-tech-performance.md |
| 12 3A 品質與 Steam 驗收 | 階段門禁、QA 計劃、Steam 商店與上架、3A 對標評分 | 12-steam-qa-checklist.md |
工作流程
流程 A：新專案（從想法到完整文件體系）
- 釐清最小必要資訊（一次性向使用者提問，不超過 4 個問題）：遊戲類型與核心玩法一句話、引擎（Unity/Unreal/Godot/未定）、平台與目標幀率（PC 60fps？Steam Deck？）、美術風格傾向。問完即可開工，不要為了資訊齊全反覆追問，未知項在文件中顯式標
【待確認】。 - 跑腳手架：
python scripts/new_gdd.py init --name "遊戲名" --out <輸出目錄> --engine <第一步確認的引擎>，生成整套 GDD 文件樹。--engine要用第 1 步問出來的答案，不要一律填 unity——它會真正決定文件裡的軸向、碰撞命名、導航與資料資產口徑。 - 按階段順序寫文件（見下「階段門禁」），每篇先讀對應 reference 再填對應模板。順序：01 願景 → 02 美術聖經 + 11 技術預算 → 04 核心玩法 → 07/08/09/06 規格類 → 03/05 內容類 → 12 驗收。
- 每個場景/角色/道具/動畫/對話/系統 用
scripts/new_gdd.py sheet生成獨立單頁文件，放在 GDD 對應子目錄，核心文件只放索引表，不要把幾百個資產堆進一個檔案。 - 過品質門禁：每個階段結束用
12-steam-qa-checklist.md的門禁表逐項檢查，不通關不進入下一階段。
流程 B：單份文件（使用者只需要某一類文件）
確認對象與用途 → 讀對應 reference → 複製對應模板填寫 → 用該篇末尾的「完成定義」自檢 → 交付。使用者只說「幫我寫個場景」時，先問場景名/在流程中的位置/核心事件（一次問完），然後直接產出完整 scene-sheet，不要只給空模板。
場景 vs 關卡：預設只產出使用者要的那一份。 references/03 說「場景是空間、關卡是時間，分開寫」，指的是兩者都要時的分工，不是要求每次寫場景都附帶一份關卡頁。
分工是硬的：
- 場景單頁（SC_）= 這個空間提供了什麼：地形、視線、掩體、高度差、脫身口、可躲藏點、對敵人的空間約束（§7），以及觸發區
TZ_（§4）。 - 關卡單頁（LV_）= 玩家按什麼順序經歷什麼：beat 表（含
EV_事件編號）、節奏、遭遇後果、檢查點。
因此：
- 使用者只要場景 → 只寫
scene-sheet.md，不寫順序；若確實不出關卡頁，才在 §7 的「經歷順序（簡）」補一行。 - 使用者要關卡流程、或場景有多階段節奏 → 再出
level-sheet.md，兩者用TZ_↔EV_互相引用。 - 不要因為 03 寫了「分開寫」就自作主張產出兩份文件，那只會讓一次簡單請求膨脹 2-3 倍。
填寫前先讀範文——每一類單頁都有完整範文，按你要寫的類型直接讀對應那份：
| 單頁類型 | 範文 | 最該參照什麼 |
|---|---|---|
| 場景（線性/恐怖） | assets/examples/SC_01_外科樓二層走廊_範例.md | §7 空間供給=視線遮蔽與「先目擊後接觸」；§10 偏感知與節奏 |
| 場景（開闊/BOSS） | assets/examples/SC_07_斷橋瞭望台_範例.md | §7 空間供給=距離可調 / 視線中斷 / 風險可賭；§10 偏戰鬥可解性 |
| 關卡 | assets/examples/LV_01_走廊初遇_範例.md | beat 表怎麼與 TZ_ 對帳；強度曲線與教學埋點怎麼不靠彈窗 |
| 角色（敵人） | assets/examples/EN_01_縫合者_範例.md | §6 狀態機+速度差為何要寫「跑得掉」；§7 戰鬥時長怎麼算出來 |
| 道具 | assets/examples/PR_017_缺輪輪椅_範例.md | §5 技術規格取值；§7 DoD 裡「有意不做」怎麼寫 |
| 動畫 | assets/examples/AN_EN01_Slash_01_範例.md | §2 三段式幀區間；§3 事件埋點（預告音是公平性底線） |
| 對話/過場 | assets/examples/DL_07_護士長錄音_範例.md | 台詞 ID/時長/字幕合規/中斷續播怎麼定義 |
| 系統 | assets/examples/SYS_04_抓取掙脫_範例.md | §4 參數表必須帶「設計意圖」；§5 邊界一個不漏 |
所有範文都要達到這個顆粒度（每一項都有具體數字、編號、可派工內容）。注意：範文裡的勾選項是完工後的驗證記錄（含實測面數、評審日期、被推翻的設計決定），不是開工前的填寫樣式；v0.1 階段該留空的就留空，不要編造「看起來像實測」的數字。§10 設計風險與待驗證假設 是唯一允許且應當沒有數字的一節。
流程 C：審校既有文件/想法
按 12-steam-qa-checklist.md 的「3A 十維評分表」逐維打分（1-10 分，附證據），列出阻斷上架的硬傷、缺失文件清單、按嚴重度排序的修改建議。評分必須引用文件原文或缺失項，禁止空泛評價。
階段門禁（Stage Gates）
| 階段 | 必須完成的文件 | 門禁（不過不進入下一階段） |
|---|---|---|
| 概念 | 01 願景、04 核心玩法骨架 | 核心樂趣有可玩紙面/灰盒原型驗證；3 條核心支柱全員認可 |
| 垂直切片 | 02、06、11 + 每類至少 1 個樣板單頁（場景/角色/道具/動畫/對話） | 10-15 分鐘流程達到最終品質預期；所有核心系統跑通；效能預算達標 |
| 量產 | 全部核心文件 + 全部資產單頁 | 每個資產單頁可直接派工；產能與里程碑可排程 |
| Alpha | 全部內容 | Feature Complete：可從頭通關，無佔位系統 |
| Beta | 同上 + 12 驗收表 | Content Complete；零 S/A 級 bug；通關全流程×3 配置檔 |
| RC/上架 | 12 中 Steam 清單全部打勾 | 商店頁、Deck 驗證、在地化、分級、存檔相容全部通過 |
腳手架腳本
# 初始化整套 GDD 文件樹（在輸出目錄下建 <遊戲名>_GDD/）
python scripts/new_gdd.py init --name "遊戲名" --out "D:/MyGame" --engine unity
# --engine：unity | unreal | godot | agnostic（預設）
# ★ 這不是裝飾：選擇後會真正寫入該引擎的交換格式/軸向/碰撞命名/導航/資料資產/LOD 口徑
# --genre：可選，遊戲類型描述，會寫入願景文件
# --dimension：3d（預設）| 2d（額外建 sprites/ tilesets/ 子目錄）
# 為單個對象生成單頁文件（自動放入對應子目錄）
python scripts/new_gdd.py sheet --type scene --name "廢棄醫院" --out "D:/MyGame/遊戲名_GDD"
# --type：scene | level | character | prop | animation | dialogue | system | sprite | tileset
# --subtype：character 用 player/enemy/npc（CH/EN/NPC）；prop 用 item/weapon（PR/WP）
# 例：sheet --type character --subtype enemy --name "縫合者" → characters/EN_01_縫合者.md
# 例：sheet --type sprite --name "HeroIdle" → sprites/SPR_01_HeroIdle.md
init 還支援 --dimension 2d：額外建立 sprites/、tilesets/ 子目錄（2D 專案用）。
腳本自動替換 {{GAME_NAME}}、{{DATE}}、{{ENGINE}} 佔位符。若腳本不可用，手動從 assets/templates/ 複製模板。
通用寫作規範
- 文件頭：每份文件開頭固定寫：文件編號、版本號、狀態（草稿/評審中/已鎖定）、最後更新日期、負責人、關聯文件編號。資產單頁還需寫引擎內資源命名（如
SM_Prop_HospitalWheelchair_01）。 - 量化優先：禁止「手感好」「畫面精美」「敵人很強」這類無法驗收的描述。要寫「按下攻擊到判定生效 8 幀（0.13s@60fps）」「敵人 HP 120、玩家滿強化 DPS 45，預期戰鬥時長 35-45s」。
- 不確定就標：未知數值寫
【待確認：原因/負責人/期限】，禁止編造數字後假裝確定；行業經驗值可直接採用並在文件中標註「行業預設值，首測後調」。 - 圖文要求：場景、關卡、UI 必須配佈局示意（ASCII 平面圖、Mermaid 流程/狀態圖、或引用概念圖編號）；狀態機、對話樹、選單流程用 Mermaid 畫出；參數與清單用表格承載。
- 每篇必須有 DoD：文末附完成定義檢查表（可打勾的
- [ ]），這是交付驗收的唯一依據。 - 語言：中文正文；專有名詞、引擎 API、資源命名保留英文；台詞腳本同時預留英文/其他語種欄位。
- 改文件走版本：鎖定後的文件修改要在文末變更記錄中記版本、日期、改了什麼。
交付要求
- 交付物是落在使用者專案目錄的 Markdown 檔案（腳手架目錄 + 填好的文件），不是聊天裡的大綱。
- 每次交付後提示使用者：下一步該寫哪份文件、哪些
【待確認】需要他決策。 - 文件品質以「一個新加入的外包美術/程式，只讀對應單頁就能獨立做出合格資產」為檢驗標準。