mcpbeat

Web Game Foundations

openai/web-game-foundations

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.

1k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
4915
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/openai/plugins --skill web-game-foundations

What comes with it

229 bytes besides the instruction
agents/openai.yaml

The instruction itself

9 sections, as written by the author

Web Game Foundations

Overview

Use 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.

Default 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.

Use This Skill When

  • the user has not settled the engine or renderer choice
  • the task is about boundaries, module shape, state ownership, or asset policy
  • multiple specialist skills need one shared architectural frame

Do Not Stay Here When

  • the runtime track is clearly Phaser
  • the runtime track is clearly vanilla Three.js
  • the runtime track is clearly React Three Fiber
  • the task is purely about shipped 3D assets

Once the stack is clear, hand off to the runtime or asset specialist skill.

Architecture Rules

  • Separate simulation from rendering.
  • Simulation owns entities, turns, timers, collisions, progression, and saveable state.
  • The renderer owns scene composition, animation playback, camera, particles, and input plumbing.
  • Keep input mapping explicit.
  • Define actions such as move, confirm, cancel, ability-1, and pause.
  • Map physical inputs to actions in one place.
  • Treat asset loading as a first-class system.
  • Use stable manifest keys.
  • Group by domain: characters, environment, UI, audio, FX.
  • For 3D content, standardize on GLB or glTF 2.0 unless the chosen engine ecosystem requires another format upstream.
  • Define save/debug/perf boundaries up front.
  • Save serializable simulation state, not renderer objects.
  • Keep debug overlays and perf probes easy to toggle.
  • Use DOM overlays for menus and HUD by default.
  • Canvas or WebGL should handle the playfield.
  • DOM should handle text-heavy HUD, menus, settings, and accessibility-sensitive controls.
  • In 3D, keep the persistent UI budget small so the scene stays readable and interactive.
  • Lock 3D runtime conventions early.
  • Choose consistent units, origins, pivots, and naming conventions.
  • Decide how collision proxies, LODs, and baked lighting data are authored before runtime integration starts.

Engine Selection

  • Default to Phaser for 2D games with sprites, tilemaps, top-down or side-view action, turn-based grids, and classic browser arcade flows.
  • Default to vanilla Three.js for explicit 3D scenes that want direct scene, camera, renderer, and loop control in plain TypeScript or Vite.
  • 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.
  • Use raw WebGL only for shader-heavy or renderer-first projects where engine abstractions would get in the way.
  • Keep Babylon.js and PlayCanvas as alternative-engine paths rather than the default code-generation target.

See ../../references/engine-selection.md for the default decision table.

Implementation Checklist

Define these before writing core code:

  • Player fantasy and primary verbs
  • Core loop and loss or reset states
  • Camera model
  • Input action map
  • Simulation modules
  • Renderer modules
  • Asset manifest layout
  • 3D asset format and optimization rules
  • HUD and menu surfaces
  • Save data boundary
  • Debug and perf surfaces

Anti-Patterns

  • Mixing gameplay rules directly into scene callbacks
  • Treating the renderer as the source of truth for game state
  • Putting all HUD and menu UI into the canvas by default
  • Letting asset filenames become the public API instead of manifest keys
  • Shipping unoptimized 3D assets straight from the DCC tool into the browser
  • Mixing camera-control state and menu or modal state without an explicit input boundary
  • Rebuilding architecture every time the game changes genre

References

  • Engine selection: ../../references/engine-selection.md
  • Phaser structure: ../../references/phaser-architecture.md
  • Three.js structure: ../../references/three-webgl-architecture.md
  • Three.js ecosystem stack: ../../references/threejs-stack.md
  • React Three Fiber stack: ../../references/react-three-fiber-stack.md
  • 3D asset shipping: ../../references/web-3d-asset-pipeline.md

How to use it

Copy the folder

Take openai/web-game-foundations from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.