Codex Plugin Deep Dive

Game Studio 插件详解

这是一个面向浏览器游戏开发的 Codex 工作流插件。它不会替代 Phaser、Three.js 或 Blender，而是把 Codex 的判断、代码生成、资源处理和测试流程组织成一套更像游戏团队的工作方式。

一句话结论

不是引擎

它不直接运行游戏

真正的运行时仍然是你的项目代码，例如 Phaser、Three.js、React、Vite、Rapier、Playwright 等。

是工作流

它告诉 Codex 怎么做游戏任务

包括选栈、拆架构、生成代码、处理 sprite、优化 GLB、设计 HUD、做浏览器测试。

有偏好

它不是完全中立的工具箱

插件明确写了：v1 里 2D 是最强路径；3D 有 opinionated 默认生态。

你可以把它理解成三层

1. 总入口

game-studio 判断任务属于 2D、3D、UI、资源、测试还是架构。

2. 专项技能

转给 Phaser、Three.js、R3F、资源管线、UI 或 playtest skill。

3. 参考文档

按需读取 starter、架构、性能、资源格式、测试清单等文档。

4. 本地执行

Codex 在你的仓库里改代码、跑命令、生成资源或启动浏览器测试。

5. 验证闭环

通过截图、Playwright、资源检查或运行时反馈确认是否真的可玩。

适合它处理的问题

很适合

  • “帮我做一个浏览器小游戏原型”
  • “这个游戏用 Phaser 还是 Three.js”
  • “给我搭 2D 游戏目录和核心循环”
  • “把 3D 场景接入 GLB、物理和 HUD”
  • “帮我做 sprite 动画生成和归一化流程”
  • “帮我 playtest 一下这个 browser game”

不该期待它直接完成

  • 它不是 Unity/Unreal 插件。
  • 它不是可视化关卡编辑器。
  • 它不会自动替你购买、下载或授权第三方素材。
  • 它不是独立部署平台。
  • 它不会绕过浏览器、GPU、资源授权或项目依赖的真实限制。

功能地图

模块 解决什么问题 默认技术判断 典型输出
game-studio 总入口、任务分类、技术路线选择 2D 默认 Phaser；3D 默认 Three.js / R3F 游戏计划、栈选择、后续 skill 路由
web-game-foundations 建立游戏工程边界 simulation 不放进 renderer；UI 默认 DOM overlay 模块划分、输入映射、资源策略、存档边界
phaser-2d-game 实现 2D 浏览器游戏 Phaser + TypeScript + Vite + DOM HUD scene、system、asset manifest、HUD 结构
three-webgl-game 实现非 React 3D 浏览器游戏 Three.js + GLB/glTF + Rapier + SpectorJS renderer、camera、loader、physics、diagnostics
react-three-fiber-game 在 React app 里做 3D 游戏或交互场景 @react-three/fiber + drei + rapier + DOM overlays Canvas scene root、React 状态边界、3D UI 协调
game-ui-frontend 设计 HUD、菜单、overlay、响应式游戏 UI 游戏世界在 canvas/WebGL，文字密集 UI 放 DOM HUD 层级、主题变量、菜单/抽屉/提示布局
sprite-pipeline 生成并归一化 2D sprite 动画 从一个确认 seed frame 生成整条 strip，避免逐帧漂移 edit canvas、raw strip、固定帧、preview sheet
web-3d-asset-pipeline 准备 Web 端可出货 3D 资源 GLB/glTF 2.0，glTF Transform，KTX2/BasisU 等 清理后的模型、压缩资源、LOD、碰撞代理
game-playtest 从玩家视角测试浏览器游戏 优先 browser automation + 截图检查 启动验证、输入验证、截图、严重度排序问题列表

它覆盖的工作面

设计与规划

确定游戏 fantasy、player verbs、核心循环、失败状态、游玩时长、技术路线。

core loop progression failure state

工程实现

按 Phaser、Three.js、R3F 的边界生成代码，并避免把玩法规则塞进渲染层。

simulation renderer input

资源管线

2D 处理 sprite strip；3D 处理 GLB/glTF、贴图、压缩、LOD、碰撞体。

sprites GLB KTX2

游戏 UI

让 HUD、菜单、设置、提示既可读又不遮挡核心画面，尤其关注 3D 视野。

HUD overlay responsive

测试与验收

通过启动、输入、场景切换、截图、UI 层和渲染层检查判断是否真的能玩。

Playwright screenshots SpectorJS

性能与调试

关注 WebGL context、draw calls、贴图大小、后处理成本、资源加载卡顿。

GPU post-processing asset size

交互式路由图

点一个任务类型，看插件会把 Codex 往哪个 skill 路由。

默认技术选择

2D 游戏

默认走 Phaser。原因是 Phaser 对 sprite、tilemap、scene、camera、timing 支持成熟，同时不强迫你把 gameplay rules 写死在框架里。

普通 3D 游戏

默认走 vanilla Three.js。适合需要直接控制 scene、camera、renderer、loop、loader、physics 的项目。

React 里的 3D

默认走 React Three Fiber。适合 3D scene 要和 React app 的状态、菜单、设置、编辑器或产品壳共存。

资源问题

2D sprite 走 sprite-pipeline；3D 模型和贴图走 web-3d-asset-pipeline。运行时代码和资源出货是分开的。

重要边界

插件说明里明确写了它是 asymmetric：v1 里 2D 是最强执行路径；3D 有明确推荐生态，但不声称和 2D 深度完全一样。

一次完整游戏任务通常怎么跑

需求归类

先判断是规划、2D、3D、UI、资源、测试，还是混合任务。

确定核心循环

锁定玩家做什么、为什么失败、如何进步、单局多长。

划清工程边界

simulation、renderer、input、asset、UI、save、debug 分开。

实现最小可玩

先搭可启动、可输入、可反馈的核心体验，再补 UI 和资源。

浏览器验证

启动、截图、操作、检查 HUD 和 canvas/WebGL 是否真的正确。

三个典型任务例子

例 1

“做一个 2D 战棋原型”

入口先确认回合、格子、行动点、胜负条件；然后走 phaser-2d-game，把规则系统和 Phaser scene 分开。

例 2

“做一个 3D 探索 demo”

如果不是 React app，走 three-webgl-game；使用 GLB、camera rig、Rapier 物理、低遮挡 DOM HUD。

例 3

“优化角色模型上 Web”

不从运行时代码开始，直接走 web-3d-asset-pipeline；检查 pivot、scale、材质复用、贴图大小、压缩和碰撞代理。

质量门槛

领域 插件强调的验收点
2D sprite 比例稳定、帧大小不漂、动作在游戏尺寸下可读、透明背景保留、预览正确。
3D scene 第一屏可玩、HUD 不像后台面板、camera 控制明确、depth 和 silhouette 可读。
UI 关键信息优先，中心和下中部 playfield 尽量清空，长文本放抽屉或暂停界面。
资源 GLB/glTF 作为运行时契约；不要让 runtime 弥补上游 asset 的 pivot、scale、材质错误。
测试 canvas/WebGL 必须看截图；不能只靠 DOM 断言判断游戏画面正确。

它在本机是怎么组织的

.codex-plugin/plugin.json 插件元数据：名称、版本、描述、作者、能力、图标、skills 入口。
skills/*/SKILL.md 核心实现：每个 skill 是一份 Codex 工作说明，决定什么时候使用、怎么路由、怎么输出。
references/*.md 补充知识库：engine selection、Phaser 架构、Three.js starter、GLB loading、Rapier、性能和 playtest 清单。
scripts/*.py 实际可运行脚本：目前集中在 2D sprite edit canvas、strip normalization、preview sheet。
assets/* 插件展示用图标和 logo，不是游戏素材库。

它和普通提示词有什么区别

普通提示词

每次都靠你把要求讲清楚。上下文不足时，模型可能按泛泛的 Web app 或 demo 方式做。

Game Studio 插件

提前把游戏开发里的默认边界写进本地 skill：比如 simulation 不放 renderer、HUD 默认 DOM、3D 资源默认 GLB/glTF、playtest 必须看截图。

运行时心智模型

用户请求 → Codex 匹配 Game Studio skill → 读取 SKILL.md → 必要时读取 references/scripts → 在当前仓库执行代码修改或测试 → 汇报结果

所以它不是一个后台服务，也不是一个 npm 包。它更像一套安装在 Codex 里的“游戏开发操作手册 + 局部工具脚本”。

本机文件证据

证据 说明
/Users/songliu/.codex/plugins/cache/openai-curated/game-studio/63976030/.codex-plugin/plugin.json 声明插件名为 game-studio，版本 0.1.0，能力是 Interactive 和 Write，skills 目录是 ./skills/。
skills/game-studio/SKILL.md 总入口。写明这是 browser-game umbrella entrypoint，并且默认 2D Phaser，3D 使用 vanilla Three.js 或 React Three Fiber。
skills/phaser-2d-game/SKILL.md 2D 主路径。推荐 Phaser、TypeScript、Vite、DOM HUD；强调 gameplay state 不放在 Phaser scenes。
skills/three-webgl-game/SKILL.md 非 React 3D 路径。推荐 Three.js、GLB/glTF、Rapier、SpectorJS、DOM overlays。
skills/sprite-pipeline/SKILL.md 2D sprite 管线。引用三个 Python 脚本，用于 edit canvas、normalize、preview sheet。
references/ 包含 engine-selection、threejs-stack、react-three-fiber-starter、playtest-checklist、webgl-debugging-and-performance 等参考文件。

插件关键词

games phaser threejs react-three-fiber gltf rapier webgl sprites playtest

一句话复盘

如果你让 Codex “用 Game Studio 做游戏”，真正发生的不是打开某个游戏编辑器，而是 Codex 按这些本地 skill 的规则，在你的仓库里选择技术路线、改代码、处理资源、跑浏览器验证。