phaser-2d-game
Implement 2D browser games with Phaser. Use when the user wants a Phaser, TypeScript, and Vite stack for scenes, gameplay systems, cameras, sprite animation, and DOM-overlay HUD patterns.
Best use case
phaser-2d-game is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Implement 2D browser games with Phaser. Use when the user wants a Phaser, TypeScript, and Vite stack for scenes, gameplay systems, cameras, sprite animation, and DOM-overlay HUD patterns.
Teams using phaser-2d-game should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/phaser-2d-game/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How phaser-2d-game Compares
| Feature / Agent | phaser-2d-game | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Implement 2D browser games with Phaser. Use when the user wants a Phaser, TypeScript, and Vite stack for scenes, gameplay systems, cameras, sprite animation, and DOM-overlay HUD patterns.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Phaser 2D Game ## Overview Use this skill for the main execution path in this plugin. Phaser is the default stack for 2D browser games here because it handles rendering, timing, sprites, cameras, and scene orchestration well without forcing gameplay rules into the framework. Preferred stack: - Phaser - TypeScript - Vite - DOM-based HUD or menus layered over the game canvas ## Architecture 1. Keep gameplay state outside Phaser scenes. - Systems own rules, turn order, movement, combat, inventory, objectives, and progression. - Phaser scenes adapt system state into sprites, camera motion, animation playback, and effects. 2. Make scenes thin. - Boot and asset preload - Menu or shell scene - Gameplay scene - Optional overlay or debug scene 3. Keep renderer-facing objects disposable. - Sprite containers, emitters, tweens, and camera rigs are view state, not source of truth. 4. Favor stable asset manifest keys over direct file-path references throughout gameplay code. ## Implementation Guidance - Use one integration boundary where the scene reads simulation state and emits input actions back. - Prefer deterministic system updates over scene-local mutation. - Treat HUD and menus as DOM when text, status density, or responsiveness matter. - Keep animation state derived from gameplay state rather than ad hoc sprite flags. ## 2D Modes Covered Well - Turn-based grids and tactics - Top-down exploration - Side-view action platformers - Character-action combat with sprite animation - Lightweight management or deck-driven battle scenes ## Camera and Presentation - Choose the camera model early: locked, follow, room-based, or tactical-pan. - Keep camera logic separate from game rules. - Use restrained screen shake, hit-stop, and parallax. Effects should improve readability, not obscure it. ## UI Integration - Use DOM overlays for HUD, command menus, settings, and narrative panels. - Keep the canvas responsible for the world, combat readability, and motion. - Avoid shoving dense text or complex settings UIs into Phaser unless the project explicitly needs an in-canvas presentation. ## Asset Organization - `characters/` - `environment/` - `ui/` - `fx/` - `audio/` - `data/` Keep manifest keys human-readable and stable. ## Default Directory Shape See `../../references/phaser-architecture.md` for a concrete module split. ## Anti-Patterns - Game rules inside `update()` loops without a system boundary - Scene-to-scene state passed through mutable global objects - HUD text rendered in the game canvas just because it is convenient - Asset paths embedded everywhere instead of a manifest layer - Overusing generic React dashboard patterns for game UI ## References - Shared architecture: `../web-game-foundations/SKILL.md` - Frontend direction: `../game-ui-frontend/SKILL.md` - Sprite workflow: `../sprite-pipeline/SKILL.md` - Phaser structure: `../../references/phaser-architecture.md`
Related Skills
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.
three-webgl-game
Implement browser-game runtimes with plain Three.js. Use when the user wants imperative scene control in TypeScript or Vite with GLB assets, loaders, physics, and low-level WebGL debugging.
react-three-fiber-game
Build React-hosted 3D browser games with React Three Fiber. Use when the user wants pmndrs-based scene composition, shared React state, and 3D HUD integration inside a React app.
game-ui-frontend
Design UI surfaces for browser games. Use when the user asks for HUDs, menus, overlays, responsive layouts, or visual direction that must protect the playfield.
game-studio
Route early browser-game work. Use when the user needs stack selection and workflow planning across design, implementation, assets, and playtesting before moving to a specialist skill.
game-playtest
Run browser-game playtests and frontend QA. Use when the user asks for smoke tests, screenshot-based verification, browser automation, HUD or overlay review, or structured issue-finding in a browser game.
workflow
Vercel Workflow DevKit (WDK) expert guidance. Use when building durable workflows, long-running tasks, API routes or agents that need pause/resume, retries, step-based execution, or crash-safe orchestration with Vercel Workflow.
verification
Full-story verification — infers what the user is building, then verifies the complete flow end-to-end: browser → API → data → response. Triggers on dev server start and 'why isn't this working' signals.
vercel-storage
Vercel storage expert guidance — Blob, Edge Config, and Marketplace storage (Neon Postgres, Upstash Redis). Use when choosing, configuring, or using data storage with Vercel applications.
vercel-services
Vercel Services — deploy multiple services within a single Vercel project. Use for monorepo layouts or when combining a backend (Python, Go) with a frontend (Next.js, Vite) in one deployment.
vercel-sandbox
Vercel Sandbox guidance — ephemeral Firecracker microVMs for running untrusted code safely. Supports AI agents, code generation, and experimentation. Use when executing user-generated or AI-generated code in isolation.
vercel-queues
Vercel Queues guidance (public beta) — durable event streaming with topics, consumer groups, retries, and delayed delivery. $0.60/1M ops. Powers Workflow DevKit. Use when building async processing, fan-out patterns, or event-driven architectures.