Game Dev (Router)

移植自 OpenAI 官方 openai/plugins 的 game-studio 插件(MIT),Codex 结构已转为 Claude 单入口 skill:本文件是路由器,专科规则在 specialists/,深度资料在 references/,sprite 工具脚本在 scripts/。按需读文件,不要一次全读。

Overview

Use this skill as the umbrella entrypoint for browser-game work. Default to a 2D Phaser path unless the user explicitly asks for 3D, Three.js, React Three Fiber, shader-heavy rendering, or another WebGL-first direction.

This suite is intentionally asymmetric:

• 2D is the strongest execution path.
• 3D has one opinionated default ecosystem: vanilla Three.js for plain TypeScript or Vite apps, React Three Fiber for React-hosted 3D apps, and GLB or glTF 2.0 as the default shipping asset format.
• Shared architecture, UI, and playtest practices apply to both.

Routing Rules

1. Classify the request before designing or coding:
   • 2D default: Phaser, sprites, tilemaps, top-down, side-view, grid tactics, action platformers.
   • 3D + plain TS/Vite: imperative scene control, engine-like loops, non-React apps, direct Three.js work.
   • 3D + React: React-hosted product surfaces, declarative scene composition, shared React state, UI-heavy 3D apps.
   • 3D asset pipeline: GLB, glTF, texture packaging, compression, LOD, runtime asset size.
   • Shared: core loop design, frontend direction, save/debug/perf boundaries, browser QA.
2. Route to the specialist file immediately after classification:
   • Shared architecture and engine choice: specialists/web-game-foundations.md
   • Deep 2D implementation: specialists/phaser-2d-game.md
   • Vanilla Three.js implementation: specialists/three-webgl-game.md
   • React-hosted 3D implementation: specialists/react-three-fiber-game.md
   • 3D asset shipping and optimization: specialists/web-3d-asset-pipeline.md
   • HUD and menu direction: specialists/game-ui-frontend.md
   • 2D sprite generation and normalization: specialists/sprite-pipeline.md
   • Browser QA and visual review: specialists/game-playtest.md
3. Keep one coherent plan across the routed specialists. Do not let engine, UI, asset, and QA decisions drift apart.

平台分支:微信 / 抖音小游戏(本地补充,非上游内容)

目标平台是微信/抖音小游戏时,以下上游默认规则作废:

• "HUD/菜单默认走 DOM" → 小游戏运行时没有 DOM(裸 JS + canvas)。UI 全部 in-canvas:声明式方案优先用腾讯开源的 minigame-canvas-engine(MIT,XML + flex 子集,env 层自动适配 wx/tt/swan/浏览器,本机 clone 于 ~/workspace/minigame-canvas-engine),或引擎自带 UI 系统。
• 引擎选择偏移:重 UI 项目国内生态默认 Cocos Creator;坚持 code-first 时用 Phaser/Three + weapp-adapter 垫片,浏览器先行开发,platform shim 收敛 wx/tt API 差异。
• 开发验证:浏览器阶段用 Playwright 实测(小游戏真机没有这个能力),出包后 再在开发者工具核对垫片边角(音频/触摸/字体)。

Default Workflow

1. Lock the game fantasy and player verbs.
2. Define the core loop, failure states, progression, and target play session length.
3. Choose the implementation track (2D Phaser default; Three.js for explicit 3D in plain TS/Vite; R3F when living inside React; raw WebGL only for shader-first surfaces).
4. Define the UI surface early — browser games usually need a DOM HUD and menu layer even when the playfield is canvas or WebGL (小游戏平台见上方分支). For 3D starter scaffolds, default to a low-chrome HUD.
5. Decide the asset workflow: 2D characters and effects → specialists/sprite-pipeline.md; 3D models and shipping format → specialists/web-3d-asset-pipeline.md.
6. Close with a playtest loop (specialists/game-playtest.md) before calling the work production-ready.

Output Expectations

• For planning requests, return a game-specific plan with stack choice, gameplay loop, UI surface, asset workflow, and test approach.
• For implementation requests, keep the chosen stack obvious in the file structure and code boundaries.
• When the user asks about Babylon.js or PlayCanvas, compare them honestly but keep Three.js and R3F as the primary code-generation defaults unless the user explicitly chooses another engine.
• Do not claim the 3D track has equal depth to the Phaser track — the suite is 2D-first.

References(按需读)

Scripts(sprite 工具,python3 + Pillow)

• scripts/build_sprite_edit_canvas.py — 围绕种子帧搭透明参考画布
• scripts/normalize_sprite_strip.py — 序列帧归一化(统一缩放/锚点)
• scripts/render_sprite_preview_sheet.py — 渲染预览表