用 Codex 做瀏覽器遊戲
說明如何用 Codex 開發可玩的瀏覽器遊戲，並在 controls、timing、UI feel 和素材上持續驗證。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| 瀏覽器遊戲 | browser game | 跑在瀏覽器裡的網頁遊戲。 |
| 遊戲迴圈 | game loop | 渲染和更新的核心迴圈。 |
| 手感把關 | feel check | 玩法手感由人驗收。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你規劃用 Codex 做一個瀏覽器遊戲的開發任務序列。
你是 Codex 瀏覽器遊戲開發規劃顧問，幫我把一個瀏覽器遊戲的開發拆成可交給 Codex 的任務序列。
【角色】
你熟悉瀏覽器遊戲開發：先搭可玩迴圈、再調玩法和手感、處理渲染和效能，知道手感要人把關。
【輸入】
- 遊戲型別和玩法核心：___
- 技術堆疊（Canvas / WebGL / 框架）：___
- 目前進度：___
- 我的開發經驗：___
【工作流程】
1. 先搭最小可玩的遊戲迴圈
2. 拆出可交給 Codex 的功能任務
3. 標出手感、平衡需人驗收的部分
4. 給從實現到瀏覽器驗收的閉環
【輸出規範】
▌一、最小可玩迴圈
▌二、可交給 Codex 的功能任務
▌三、需人驗收的手感 / 平衡
▌四、瀏覽器驗收閉環
【硬約束】
- 先做出能玩的迴圈，不一上來追求完整
- 玩法手感由人把關，Codex 做實現
- 效能問題基於實測，不憑猜最佳化
- 改動在瀏覽器實際驗證、可回復
- 不確定的 API 標註需查官方文件遊戲開發是 Codex 不只生成程式碼、還要持續驗證體驗的典型場景。真正能玩的瀏覽器遊戲，需要概念設計、渲染層、前端 shell、素材、玩法迴圈，以及反覆調整 controls、timing 和 UI feel。
瀏覽器遊戲的第一目標是 first playable loop，不是完整後端、排行榜、賬號系統和素材大全。
Browser games
官方瀏覽器遊戲場景。
Image generation
用圖片輸入和生成輔助 concept art、sprites、backgrounds。
Figma to code
有視覺參考時，用結構化設計上下文推進 UI。
推薦流程
flowchart LR
Plan["PLAN.md"] --> Loop["core loop"]
Loop --> Play["live browser playtest"]
Play --> Tune["controls / timing / UI feel"]
Tune --> Assets["assets and prompts"]
Assets --> Verify["build / test / screenshot"]適合 Codex 的瀏覽器遊戲任務：
- 從零定義 game plan。
- 搭 first playable prototype。
- 迭代 controls、visuals、deployment。
- 生成 concept art、sprites、backgrounds、UI assets。
- 用 live browser 試玩並截圖驗證。
- 接入 OpenAI-powered features 前先核對目前官方 API 文件。
不適合第一輪就做：
- 完整多人後端。
- 複雜經濟系統。
- 大量付費素材管線。
- 賬號、支付、排行榜全套。
- 沒有玩法迴圈的視覺 demo。
起始提示詞
請在這個 repo 中規劃並構建一個 browser game。
先建立 PLAN.md，不要直接開始寫完整專案。
PLAN.md 需要包含：
- player goal
- main loop
- inputs and controls
- win and fail states
- progression or difficulty
- visual direction
- stack and hosting assumptions
- milestone order
第一階段只交付 first playable loop。
每完成一個小功能，執行 build/test，並用瀏覽器實際試玩。
素材 prompt 儲存到 .prompts/，工作記錄儲存到 .logs/。這個 prompt 的重點是先 plan，再 build。遊戲任務容易變長，過程記錄和素材 prompt 能讓後續迭代有依據。
技術堆疊選擇
只做 first playable prototype 時，優先選簡單前端堆疊：
- Next.js 或 Vite 負責 app shell。
- Phaser、PixiJS 或 Canvas/WebGL 層負責 game rendering。
- 靜態 JSON 或本地狀態儲存關卡和設定。
只有當遊戲確實需要 persistence、matchmaking、leaderboards 或 pub/sub 時，再考慮後端、資料庫和佇列。
不要讓 Codex 一開始就搭全堆疊模板。先把核心 loop、輸入、勝負條件和視覺反饋跑通。
用 AGENTS.md 固定執行方式
遊戲專案適合寫一份簡短 AGENTS.md：
## Browser game rules
- 以 PLAN.md 作為開發依據。
- 每次只實現一個 milestone。
- 完成 feature 後執行 build/test。
- 用瀏覽器試玩並檢查 controls、timing、UI overlap、win/fail state。
- 圖片素材 prompt 儲存到 .prompts/。
- 工作記錄儲存到 .logs/。
- 不新增後端，除非 PLAN.md 明確進入後端階段。AGENTS.md 的作用不是寫願景，而是讓 Codex 長時間工作時仍然遵守計劃、驗證結果並使用正確工具。
素材一致性
使用 image generation 時，讓 Codex 儲存每一批圖片的 prompt。後續繼續生成同風格 sprites、backgrounds 或 UI assets 時，複用這些 prompts 比重新描述風格更穩定。
素材 prompt 至少包含：
- art direction。
- camera angle。
- color language。
- UI style。
- resolution / aspect ratio。
- transparent background requirement。
不要把版權不清的素材直接混入可釋出專案。需要真實商用素材時，單獨做授權和來源記錄。
試玩和迭代
第一版完成後，不要只看程式碼。用瀏覽器實際試玩，檢查：
- controls 是否順手。
- timing 是否合理。
- UI 是否遮擋。
- game loop 是否閉合。
- win/fail state 是否可觸發。
- 視覺元素是否符合 plan。
- 移動端和桌面端是否都能操作。
如果畫面不對、操作不順、迴圈不閉合，就繼續迭代這些點。遊戲好壞不能只靠型別檢查證明。
驗收清單
PLAN.md清楚定義 first playable。- 第一階段沒有超範圍上後端或賬號系統。
- build/test 真實執行。
- 瀏覽器試玩有截圖或明確觀察結論。
- controls、timing、win/fail state 可驗證。
- 素材 prompt 被儲存，素材來源可追溯。
- UI 不遮擋關鍵玩法元素。