game-studio

por openai

Roteie trabalhos iniciais de jogos de navegador. Use quando o usuário precisar de seleção de pilha e planejamento de fluxo de trabalho entre design, implementação, assets e testes de jogabilidade antes de...

npx skills add https://github.com/openai/plugins --skill game-studio

Baixar ZIP GitHub

Game Studio

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 plugin is intentionally asymmetric:

2D is the strongest execution path in v1.
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.

Use This Skill When

the user is still choosing a stack
the request spans multiple domains such as runtime, UI, asset pipeline, and QA
the user says "help me build a game" without naming the implementation path

Do Not Stay Here When

the runtime is clearly plain Three.js
the runtime is clearly React Three Fiber
the task is clearly a shipped-asset problem
the task is clearly frontend-only or QA-only

Once the intent is clear, route to the most specific specialist skill and continue from there.

Routing Rules

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.
- Alternative engine: Babylon.js or PlayCanvas requests, usually as comparison or ecosystem fit questions.
- Shared: core loop design, frontend direction, save/debug/perf boundaries, browser QA.
Route to the specialist skills immediately after classification:
- Shared architecture and engine choice: ../web-game-foundations/SKILL.md
- Deep 2D implementation: ../phaser-2d-game/SKILL.md
- Vanilla Three.js implementation: ../three-webgl-game/SKILL.md
- React-hosted 3D implementation: ../react-three-fiber-game/SKILL.md
- 3D asset shipping and optimization: ../web-3d-asset-pipeline/SKILL.md
- HUD and menu direction: ../game-ui-frontend/SKILL.md
- 2D sprite generation and normalization: ../sprite-pipeline/SKILL.md
- Browser QA and visual review: ../game-playtest/SKILL.md
Keep one coherent plan across the routed skills. Do not let engine, UI, asset, and QA decisions drift apart.

Default Workflow

Lock the game fantasy and player verbs.
Define the core loop, failure states, progression, and target play session length.
Choose the implementation track:
- Default to Phaser for 2D browser games.
- Choose vanilla Three.js when the project is explicitly 3D and wants direct render-loop control in a plain TypeScript or Vite app.
- Choose React Three Fiber when the project already lives in React or wants declarative scene composition with shared React state.
- Choose raw WebGL only when the user explicitly wants a custom renderer or shader-first surface.
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 that preserves the playfield and keeps secondary panels collapsed.
Decide the asset workflow:
- 2D characters and effects: use sprite-pipeline.
- 3D models, textures, and shipping format: use web-3d-asset-pipeline.
Close with a playtest loop 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.
For mixed requests, preserve the plugin default: 2D Phaser first unless the user asks for something else.
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.