Update to Game Studio

{
  "name": "web-game-foundations",
  "description": "Set browser-game architecture before implementation. Use when the user needs engine choice, simulation and render boundaries, input model, asset organization, or save/debug/performance strategy.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 229
    }
  ],
  "skill_md_contents": "---\nname: web-game-foundations\ndescription: Set browser-game architecture before implementation. Use when the user needs engine choice, simulation and render boundaries, input model, asset organization, or save/debug/performance strategy.\n---\n\n# Web Game Foundations\n\n## Overview\n\nUse this skill to establish the non-negotiable architecture before implementation starts. Browser games degrade quickly when simulation, rendering, UI, asset loading, and input handling are mixed together.\n\nDefault rule: simulation state is owned outside the renderer, browser UI is not forced into the canvas unless there is a clear reason, and shipped 3D assets default to GLB or glTF 2.0 rather than ad hoc model formats.\n\n## Use This Skill When\n\n- the user has not settled the engine or renderer choice\n- the task is about boundaries, module shape, state ownership, or asset policy\n- multiple specialist skills need one shared architectural frame\n\n## Do Not Stay Here When\n\n- the runtime track is clearly Phaser\n- the runtime track is clearly vanilla Three.js\n- the runtime track is clearly React Three Fiber\n- the task is purely about shipped 3D assets\n\nOnce the stack is clear, hand off to the runtime or asset specialist skill.\n\n## Architecture Rules\n\n1. Separate simulation from rendering.\n   - Simulation owns entities, turns, timers, collisions, progression, and saveable state.\n   - The renderer owns scene composition, animation playback, camera, particles, and input plumbing.\n2. Keep input mapping explicit.\n   - Define actions such as `move`, `confirm`, `cancel`, `ability-1`, and `pause`.\n   - Map physical inputs to actions in one place.\n3. Treat asset loading as a first-class system.\n   - Use stable manifest keys.\n   - Group by domain: characters, environment, UI, audio, FX.\n   - For 3D content, standardize on GLB or glTF 2.0 unless the chosen engine ecosystem requires another format upstream.\n4. Define save/debug/perf boundaries up front.\n   - Save serializable simulation state, not renderer objects.\n   - Keep debug overlays and perf probes easy to toggle.\n5. Use DOM overlays for menus and HUD by default.\n   - Canvas or WebGL should handle the playfield.\n   - DOM should handle text-heavy HUD, menus, settings, and accessibility-sensitive controls.\n   - In 3D, keep the persistent UI budget small so the scene stays readable and interactive.\n6. Lock 3D runtime conventions early.\n   - Choose consistent units, origins, pivots, and naming conventions.\n   - Decide how collision proxies, LODs, and baked lighting data are authored before runtime integration starts.\n\n## Engine Selection\n\n- Default to Phaser for 2D games with sprites, tilemaps, top-down or side-view action, turn-based grids, and classic browser arcade flows.\n- Default to vanilla Three.js for explicit 3D scenes that want direct scene, camera, renderer, and loop control in plain TypeScript or Vite.\n- Default to React Three Fiber when the 3D scene lives inside a React application and needs declarative composition, shared app state, or React-first UI coordination.\n- Use raw WebGL only for shader-heavy or renderer-first projects where engine abstractions would get in the way.\n- Keep Babylon.js and PlayCanvas as alternative-engine paths rather than the default code-generation target.\n\nSee `../../references/engine-selection.md` for the default decision table.\n\n## Implementation Checklist\n\nDefine these before writing core code:\n\n- Player fantasy and primary verbs\n- Core loop and loss or reset states\n- Camera model\n- Input action map\n- Simulation modules\n- Renderer modules\n- Asset manifest layout\n- 3D asset format and optimization rules\n- HUD and menu surfaces\n- Save data boundary\n- Debug and perf surfaces\n\n## Anti-Patterns\n\n- Mixing gameplay rules directly into scene callbacks\n- Treating the renderer as the source of truth for game state\n- Putting all HUD and menu UI into the canvas by default\n- Letting asset filenames become the public API instead of manifest keys\n- Shipping unoptimized 3D assets straight from the DCC tool into the browser\n- Mixing camera-control state and menu or modal state without an explicit input boundary\n- Rebuilding architecture every time the game changes genre\n\n## References\n\n- Engine selection: `../../references/engine-selection.md`\n- Phaser structure: `../../references/phaser-architecture.md`\n- Three.js structure: `../../references/three-webgl-architecture.md`\n- Three.js ecosystem stack: `../../references/threejs-stack.md`\n- React Three Fiber stack: `../../references/react-three-fiber-stack.md`\n- 3D asset shipping: `../../references/web-3d-asset-pipeline.md`\n"
}