用 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 不遮挡关键玩法元素。