難度
中階
所需時間
2–8 小時建立 vertical slice
你需要準備
ChatGPT／Codex 桌面版 · Brainstorming skill · ImageGen · 瀏覽器測試或 Playwright · 選定的遊戲框架
開始之前
- 使用你有權使用的參考圖；不要複製未授權角色、商標、關卡、音樂或原始素材
- 先決定目標平台、控制方式、技術棧和最小可玩範圍
- 在獨立 repository 建立版本控制、測試指令、輸出目錄和資產來源紀錄
由一張遊戲截圖開始，最容易犯的錯是直接要求 Codex「做一個一模一樣的遊戲」。可靠流程應先把參考拆成玩法、視覺、介面、資產、技術和驗收六個層次，再決定哪些只作靈感、哪些要重新設計、哪些必須由人確認。影片展示了 Brainstorming skill、流程圖、設計文件、ImageGen 素材和長任務目標；本文把它整理成可複製、可驗收且較安全的原創原型方法。
\n
一、先處理權利和範圍：做「同類型原創」，不是像素複製
\n參考圖可用來討論俯視視角、格狀場地、敵人密度、HUD 區域、色彩對比和節奏，但不要直接複製角色、名稱、logo、關卡、圖示、音效或獨特介面。把需求改寫成可觀察和通用的設計語言：
\n| 不要只寫 | 改寫成 |
|---|---|
| 做成這款遊戲 | 俯視角單畫面生存遊戲；玩家在格狀場地閃避敵人並收集能量 |
| 角色要一樣 | 原創深海研究艇，圓形輪廓、青藍主色、三幀推進動畫 |
| UI 照抄 | 右側資訊欄顯示生命、分數、敵人與小地圖，重新設計比例和圖示 |
| 關卡相同 | 30×20 tiles、三種障礙、兩種收集物、90 秒一局 |
\n驗收起點：成品應在名稱、角色、素材、版面、音效和關卡內容上形成清楚的原創識別；參考圖只用來解釋抽象玩法與資訊層級。
二、把截圖拆成六層，不要讓模型自行猜完整規則
\n- 核心循環：玩家每 5–20 秒在做甚麼？移動、攻擊、收集、躲避、選升級？
- 狀態：生命、分數、時間、能量、敵人、波次和勝負怎樣更新？
- 空間：tile size、鏡頭、碰撞、邊界、障礙和出生點。
- 輸入：鍵盤、滑鼠、觸控、手掣；是否需要單手或無障礙操作。
- 視覺與音效：角色層級、背景、特效、UI、反饋和聲音 cue。
- 技術：瀏覽器或原生、引擎、目標 FPS、保存、部署和測試。
三、先審查 Brainstorming skill，再用它逐題確認設計
\nCodex 官方支援 agent skills：SKILL.md 內的 name、description 和指示決定何時使用，也可附 references、scripts 和 assets。影片使用 Superpowers 的第三方 brainstorming skill；現行版本的流程重點是先理解現有專案、逐題釐清、提出選項、呈現設計並取得批准，之後才寫計劃與實作。
安裝或使用前檢查
\n- skill 的版本、commit、license 和維護者。
- 是否強制建立 design doc、commit、worktree 或調用其他 skills。
- 是否會修改 repository、建立 task、啟動伺服器或呼叫網絡。
- 指示是否與目前專案的 AGENTS.md、團隊流程和權限衝突。
- 若只想借用提問結構，可把方法寫進一次性 prompt，毋須安裝整套 framework。
四、先畫工作流：每個階段都有輸入、輸出和返回路徑
\n
| 階段 | 輸入 | 輸出 | 人工關卡 |
|---|---|---|---|
| 分析 | 參考圖、目的、限制 | 觀察清單、風險、問題 | 確認可使用範圍 |
| Brainstorm | 分析和選項 | 批准的設計 | 確認玩法取捨 |
| 計劃 | 設計文件 | 任務、測試、里程碑 | 確認範圍和技術 |
| 素材 | asset bible | sprites、UI、背景、來源 | 風格與權利審查 |
| 實作 | 計劃、素材 | vertical slice | 可玩和可測試 |
| 驗收 | build、檢查表 | 問題、證據、版本 | 批准／返回正確階段 |
五、在 Codex 明確調用 skill，讓問題一次只解決一個決策
\n
建議問題次序
\n- 玩家在一局內的目標和最短核心循環。
- 目標平台、輸入方式和畫面比例。
- 單機／多人、保存、連線和帳戶需求。
- 勝利、失敗、重試和進度。
- 角色、敵人、障礙、道具和數值範圍。
- 視覺方向、原創識別和 asset bible。
- 引擎、框架、效能、部署和測試。
- vertical slice 包含與明確不包含的項目。
使用 brainstorming skill，只進行設計，不要建立程式或素材。
背景：我有一張俯視角遊戲參考圖，只抽取通用玩法與資訊層級。
目標：建立原創、單人、瀏覽器可玩的 90 秒 vertical slice。
請一次只問一個最重要的問題；每題提供 2–3 個互斥選項、取捨和你的建議。
把已確認答案持續整理成設計摘要，標出未決問題和權利風險。
等我批准完整設計後，才寫 DESIGN.md；不要開始實作。六、把答案寫成設計文件，不要只留在對話
\n
DESIGN.md 最小結構
\n# 遊戲一句話
## 玩家與使用情境
## 核心循環
## 規則、狀態與數值
## 控制、鏡頭與碰撞
## 勝利、失敗與重試
## 關卡與難度曲線
## UI、音效與回饋
## 原創美術方向與 asset bible
## 技術棧、資料和部署
## 無障礙、效能與瀏覽器支援
## Vertical slice 包含／不包含
## 驗收測試
## 未決問題、風險與權利接着另建 implementation plan，把設計拆成小而可測的任務：專案骨架 → 輸入與遊戲 loop → 碰撞 → 一種敵人 → 一種收集物 → HUD → 勝負 → 重試 → 音效 → 視覺替換 → 測試。每個任務寫明修改檔案、驗證命令和預期畫面。
\n七、先做 Asset Bible，再用 ImageGen 生成原創素材
\n影片把 GPT Image 2 放在素材階段。現行 Codex／ChatGPT 可透過 ImageGen 生成和編輯圖片；遊戲素材的關鍵不是「好看」，而是一致、可切、可對齊、可重複。
\n| 欄位 | 例子 | 驗收 |
|---|---|---|
| 視角 | 正上方 3/4 俯視 | 所有角色地面接觸點一致 |
| frame | 64×64，中心對齊 | 透明邊界和 anchor 固定 |
| 色盤 | 青藍、珊瑚橙、紫紅 | 與背景有足夠對比 |
| 動作 | idle 4、move 6、hit 3 | 每幀輪廓連續、不跳位 |
| 禁止 | 文字、logo、水印、陰影背景 | 逐格檢查 |
| 檔名 | player_move_e_01.png | 腳本可排序和載入 |
$imagegen
建立一個原創深海研究艇角色的單張遊戲 sprite。
用途：俯視角瀏覽器遊戲；不是任何現有遊戲角色。
視角：固定 3/4 俯視；艇首朝右；地面 anchor 在畫面中心下方。
尺寸：角色內容不超過 56×56，輸出 64×64 透明 PNG。
風格：清晰像素風輪廓，青藍機身、珊瑚橙訊號燈，最多 12 色。
限制：無文字、無 logo、無水印、無背景、無外投影。
只生成 idle 第一幀；確認身份和色盤後才生成其他動作。先鎖定一張角色基準，再用小幅編輯生成其他方向與動作；不要每次重新描述整個角色。輸出後用腳本統一 trim、padding、尺寸和透明通道，並以 contact sheet 檢查動畫連續性。
\n八、把「完成」寫成可驗收的 Goal／Definition of Done
\n
Vertical slice 完成條件示例
\n- 可由首頁按鍵進入一局，鍵盤和觸控至少一種可完整操作。
- 玩家可移動、碰撞、受傷、收集和觸發勝負；重新開始會正確重置所有狀態。
- 至少一種敵人、一種障礙、一種收集物和一個 90 秒難度曲線。
- HUD 數字與內部狀態一致；無遮擋、缺字或畫面溢出。
- 目標瀏覽器無阻斷 console error；載入和記憶體在預算內。
- 所有素材有來源、提示、license／權利紀錄，沒有沿用參考遊戲識別。
- README 提供安裝、啟動、測試、控制與已知限制。
九、先做 vertical slice，再擴展素材和系統
\n第一個 playable build 應使用簡單幾何圖形或少量臨時素材，驗證核心循環後才批量生成美術。否則你可能花大量時間製作一個玩法尚未成立的 sprite sheet。
\n- 建立固定 timestep 的 game loop 和 deterministic seed（如需要重現）。
- 完成輸入、玩家移動、邊界與碰撞。
- 加入一種敵人及出生／回收機制。
- 加入分數、生命、計時和勝負。
- 建立 reset，保證第二局沒有殘留 state。
- 加入臨時 HUD 和 debug overlay。
- 實際玩十局，調整速度、密度和反饋。
- 玩法通過後才替換正式資產、音效與效果。
十、實際遊玩驗收：畫面相似不是完成
\n
| 測試 | 操作 | 證據 |
|---|---|---|
| 輸入 | 長按、快速轉向、同時按鍵、失焦 | 錄影與事件日志 |
| 碰撞 | 角位、邊界、高速移動、重疊 | debug hitbox 截圖 |
| 狀態 | 受傷、勝利、失敗、重開、第二局 | state assertion |
| 難度 | 新手與熟手各玩十局 | 完成時間、傷害、失敗原因 |
| 效能 | 最大敵人和特效量 | FPS、frame time、memory |
| 介面 | 不同 viewport、縮放、鍵盤 | 跨尺寸截圖與可操作記錄 |
十一、可直接複製的端到端提示
\n目標：根據附上的參考畫面，建立一個原創的俯視角瀏覽器遊戲 vertical slice。
不可複製參考作品的名稱、角色、logo、關卡、UI、圖示、音效或素材。
階段 1 — 設計
使用 brainstorming skill，一次只問一個問題。
確認核心循環、控制、狀態、勝負、難度、原創美術、技術棧和範圍。
先輸出 DESIGN.md，等我批准；不要實作。
階段 2 — 計劃
把批准設計拆成小任務，列檔案、測試、依賴、里程碑和回復方案。
寫出 vertical slice 的 Definition of Done，等我批准。
階段 3 — 基線
先用幾何 placeholder 完成可玩 loop、碰撞、HUD、勝負和 reset。
啟動瀏覽器實際玩完整流程，修正 console error 和阻斷問題。
階段 4 — 素材
先建立 ASSET_BIBLE.md；用 ImageGen 製作一個原創基準角色。
確認後才生成其餘 sprites。保存提示、原圖、版本、尺寸和來源。
階段 5 — 驗收
用實際瀏覽器測試輸入、碰撞、狀態、第二局、效能和 viewport。
提供測試結果、截圖、已知限制、檔案路徑和未完成項。
只有所有 Definition of Done 通過，才標記完成。這種工作流的真正優勢，是把「AI 幫我做遊戲」改成一連串可批准、可追溯、可測試的決策。參考圖只負責啟發；Brainstorming 把模糊想法變成設計；ImageGen 產生受控原創資產；Codex 執行計劃；而實際遊玩和完成條件，才決定作品是否真的完成。
資料來源與引用
我們附上第一手及官方來源，方便你逐一核實。
常見問題
可否把一張現有遊戲截圖直接還原成相同遊戲？
技術上可以分析可觀察的佈局和互動，但商用或公開發布應建立原創角色、名稱、關卡、介面、音樂和素材，並避免造成來源或授權混淆。最安全做法是抽象出玩法類型和設計原則，而不是逐像素複製。
Brainstorming skill 是 Codex 內置功能嗎？
影片使用的是第三方 Superpowers 專案中的 brainstorming skill。Codex 官方支援 agent skills 格式，也有 build-skills 文件；第三方 skill 仍要審查 SKILL.md、scripts、來源、版本和工作流要求。
為甚麼要等設計批准後才開始寫程式？
遊戲涉及規則、狀態、控制、資產、音效、難度和技術棧；過早實作會把未決產品問題藏進程式。先批准最小設計可減少重寫，也令完成條件可以測試。
ImageGen 能一次生成完整 sprite sheet 嗎？
可以嘗試，但每格姿勢、尺寸和透明度可能不一致。較可靠做法是先鎖定角色 bible，再逐類生成或編輯，最後以腳本統一裁切、對齊、色盤、透明邊和 frame size，並人工檢查。
怎樣知道 vertical slice 已完成？
至少要可由開始進入遊戲、接受輸入、更新狀態、產生勝負、重新開始，且沒有阻斷錯誤。再按 FPS、載入、控制延遲、碰撞、UI 可讀性、鍵盤操作和目標瀏覽器驗收。
Codex 可以自己一直做到完成嗎？
可把長任務拆成目標和里程碑，但產品選擇、權利、成本、發布範圍和高風險操作仍需要人確認。每個里程碑都應有可見成果與測試，不要只根據 agent 的完成訊息。
本文遵循我們的 編輯準則.
關於作者
HK Learn AI 編輯部
HK Learn AI 編輯部負責研究、查證同編寫每一篇內容，並引用官方及第一手來源。
