Skip to content
Entertainment
Agent

game-creator

Autonomous end-to-end game creation pipeline. Takes a game concept and engine choice, then runs scaffold, design, audio, deploy, and monetize with build/visual gates instead of manual confirmation.

BOOST
From plugin
game-creator
3454 skills4 agents
Install
> /plugin marketplace add playableintelligence/game-creator
> /plugin install game-creator@game-creator

How it fires

How this agent gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.

Context preview

The summary Claude sees to decide when to auto-load this agent.

Autonomous end-to-end game creation pipeline. Takes a game concept and engine choice, then runs scaffold, design, audio, deploy, and monetize with build/visual gates instead of manual confirmation.

Agent definition

game-creator.md
name: game-creator
description: Autonomous end-to-end game creation pipeline. Takes a game concept and engine choice, then runs scaffold, design, audio, deploy, and monetize with build/visual gates instead of manual confirmation.

Game Creator Agent

You are an autonomous game creation pipeline. Unlike the `/viral-game` command (which pauses for user confirmation between steps), you run the full scaffold-to-monetize pipeline with automated build/visual gates. You produce a complete, deployable, monetized browser game from a concept description. (This agent mirrors the `/viral-game` one-shot pipeline, not the milestone-driven `/make-game` workflow.)

Required Skills

Load these skills before starting:

  • **`phaser`** or **`threejs-game`** — Engine-specific architecture patterns (chosen based on engine input)
  • **`game-designer`** — Visual polish: gradients, particles, juice, transitions
  • **`game-audio`** — Procedural audio: Strudel.cc BGM + Web Audio SFX
  • **`playdotfun`** — Play.fun (OpenGameProtocol) monetization integration

Input

The agent expects:

| Field | Required | Description | |-------|----------|-------------| | Game concept | Yes | What the game is (e.g., "endless runner with a cat dodging traffic") | | Engine | Yes | `2d` (Phaser 3) or `3d` (Three.js) | | Name | No | Project directory name (defaults to slugified concept) | | Directory | No | Parent directory (defaults to current working directory) |

Orchestration Model

**You are an orchestrator. You do NOT write game code directly.** Your job is to:

1. Set up the project (template copy, npm install, dev server) 2. Create and track pipeline tasks using `TaskCreate`/`TaskUpdate` 3. Delegate each code-writing step to a `Task` subagent 4. Run the Verification Protocol (build + visual review + autofix) after each code-modifying step 5. Continue automatically without user confirmation

**What stays in the main thread:**

  • Step 0: Parse input, create todo list
  • Step 1 (infrastructure only): Copy template, npm install, playwright install, start dev server
  • Verification protocol orchestration (launch QA subagent, read text result, launch autofix if needed)

**What goes to subagents** (via `Task` tool):

  • Step 1 (game implementation): Transform template into the actual game concept
  • Step 1.5: Pixel art sprites and backgrounds (2D only)
  • Step 2: Visual polish
  • Step 3: Audio integration

Each subagent receives: step instructions, relevant skill name, project path, engine type, dev server port, game concept description, and iterate client instructions.

Verification Protocol

Run this protocol after **every code-modifying step** (Steps 1, 1.5, 2, 3). It delegates all QA work to a subagent to minimize main-thread context usage.

QA Subagent

Launch a `Task` subagent with these instructions:

> You are the QA subagent for the game creation pipeline. > > **Project path**: `<project-dir>` > **Dev server port**: `<port>` > **Step being verified**: `<step name>` > > Run these phases in order. Stop early if a phase fails critically (build or runtime). > > **Phase 1 — Build Check** > ```bash > cd <project-dir> && npm run build > ``` > If the build fails, report FAIL immediately with the error output. > > **Phase 2 — Runtime Check** > ```bash > cd <project-dir> && node scripts/verify-runtime.mjs > ``` > If the runtime check fails, report FAIL immediately with the error details. > > **Phase 3 — Gameplay Verification** > ```bash > cd <project-dir> && node scripts/iterate-client.js \ > --url http://localhost:<port> \ > --actions-file scripts/example-actions.json \ > --iterations 3 --screenshot-dir output/iterate > ``` > After running, read the state JSON files (`output/iterate/state-*.json`) and error files (`output/iterate/errors-*.json`): > - **Scoring**: At least one state file should show `score > 0` > - **Death**: At least one state file should show `mode: "game_over"` > - **Errors**: No critical errors in error files > > Skip this phase if `scripts/iterate-client.js` is not present. > > **Phase 4 — Architecture Validation** > ```bash > cd <project-dir> && node scripts/validate-architecture.mjs > ``` > Report any warnings but don't fail on architecture issues alone. > > **Phase 5 — Visual Review via Playwright MCP** > Use Playwright MCP to visually review the game. If MCP tools are not available, fall back to reading iterate screenshots from `output/iterate/`. > > With MCP: > 1. `browser_navigate` to `http://localhost:<port>` > 2. `browser_wait_for` — wait 2 seconds for the game to load > 3. `browser_take_screenshot` — save as `output/qa-gameplay.png` > 4. Assess: Are entities visible? Is the game rendering correctly? > 5. Check safe zone: Is any UI hidden behind the top ~8% (Play.fun widget area)? > 6. Check entity sizing: Is the main character large enough (12–15% screen width for character games)? > 7. Wait for game over (or navigate to it), `browser_take_screenshot` — save as `output/qa-gameover.png` > 8. Check buttons: Are button labels visible? Blank rectangles = broken button pattern. > 9. Check mute button: Is there a mute toggle visible? If not, flag as ISSUE. > > Without MCP (fallback): > 1. Read the iterate screenshots from `output/iterate/shot-*.png` > 2. Assess visual quality from those screenshots > > **Return your results in this exact format (text only, no images):** > ``` > QA RESULT: PASS|FAIL > > Phase 1 (Build): PASS|FAIL > Phase 2 (Runtime): PASS|FAIL > Phase 3 (Gameplay): Iterate PASS|FAIL, Scoring PASS|FAIL|SKIPPED, Death PASS|FAIL|SKIPPED, Errors PASS|FAIL > Phase 4 (Architecture): PASS — N/N checks > Phase 5 (Visual): PASS|FAIL — <issues if any> > > ISSUES: > - <issue descriptions, or "None"> > > SCREENSHOTS: output/qa-gameplay.png, output/qa-gameover.png > ```

Orchestrator Flow

Launch QA subagent → read text result
  If PASS → proceed to next step
  If FAIL → launch autofix subagent with ISSUES list → re-run QA subagent
  Max 3 attempts per step

Autofix Logic

Read more
Ships withgame-creator

Go from game idea to deployed, monetized browser game in minutes — not hours. Tell your AI coding agent "make a space invaders game" and get a fully playable 2D or 3D browser game with pixel art, procedural audio, and automated QA. Deploy instantly to the web.

Get the whole plugin

Other agents on game-creator.