Make Game (Full Pipeline)

Build a complete browser game from scratch, step by step. This command walks you through the entire pipeline — from an empty folder to a deployed, monetized game. No game development experience needed.

What you'll get:

A fully scaffolded game project with clean architecture

Pixel art sprites — recognizable characters, enemies, and items (optional, replaces geometric shapes)

Visual polish — gradients, particles, transitions, juice

A 50 FPS promo video — autonomous gameplay capture, mobile portrait, ready for social media

Chiptune music and retro sound effects (no audio files needed)

Live deployment to here.now with an instant public URL

Monetization via Play.fun — points tracking, leaderboards, wallet connect, and a play.fun URL to share on Moltbook

Redeploy with a single command (

npm run deploy

)

Quality assurance is built into every step

— each code-modifying step runs build verification, visual review via Playwright MCP, and autofixes any issues found.

Orchestration Model

You are an orchestrator. You do NOT write game code directly.

Your job is to:

Set up the project (template copy, npm install, dev server)

Create and track pipeline tasks using

TaskCreate

/

TaskUpdate

Delegate each code-writing step to a

Task

subagent

Run the Verification Protocol (build + visual review + autofix) after each code-modifying step

Report results to the user between steps

What stays in the main thread:

Step 0: Parse arguments, 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)

Step 4 (deploy): Interactive auth requires user back-and-forth

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

Step 2: Visual polish

Step 2.5: Promo video capture

Step 3: Audio integration

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

Verification Protocol

Run this protocol after

every code-modifying step

(Steps 1, 1.5, 2, 3). Step 2.5 (Promo Video) does not modify game code, so it skips QA. It delegates all QA work to a subagent to minimize main-thread context usage.

Playwright MCP Check (once, before first QA run)

Before the first QA run (after Step 1 infrastructure setup), check if Playwright MCP tools like

browser_navigate

are available. If not:

Run:

claude mcp add playwright npx @playwright/mcp@latest

Tell the user: "Playwright MCP has been added. Please restart Claude Code for it to take effect, then tell me to continue."

Wait for user to restart and confirm.

Do not proceed until MCP tools are available.

QA Subagent

Launch a

Task

subagent with these instructions:

You are the QA subagent for the game creation pipeline.

Project path

:

Dev server port

:

Step being verified

:

Run these phases in order. Stop early if a phase fails critically (build or runtime).

Phase 1 — Build Check

cd

<

project-dir

>

&&

npm

run build

If the build fails, report FAIL immediately with the error output.

Phase 2 — Runtime Check

cd

<

project-dir

>

&&

node

scripts/verify-runtime.mjs

If the runtime check fails, report FAIL immediately with the error details.

Phase 3 — Gameplay Verification

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"

. Mark as SKIPPED (not FAIL) if game_over is not reached — some games have multi-life systems or random hazard spawns that make death unreliable in short iterate runs. Death SKIPPED is acceptable and does not block the pipeline.

Errors

No critical errors in error files

Skip this phase if

scripts/iterate-client.js

is not present.

Phase 4 — Architecture Validation

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:

browser_navigate

to

http://localhost:

browser_wait_for

— wait 2 seconds for the game to load

browser_take_screenshot

— save as

output/qa-gameplay.png

Assess: Are entities visible? Is the game rendering correctly?

Check safe zone: Is any UI hidden behind the top ~8% (Play.fun widget area)?

Check entity sizing: Is the main character large enough (12–15% screen width for character games)?

Wait for game over (or navigate to it),

browser_take_screenshot

— save as

output/qa-gameover.png

Check buttons: Are button labels visible? Blank rectangles = broken button pattern.

Check mute button: Is there a mute toggle visible? If not, flag as ISSUE.

Screenshot timeout

If

browser_take_screenshot

hangs for more than 10 seconds (can happen with continuous WebGL animations), cancel and proceed with code review instead. Do not let a screenshot hang block the entire QA phase.

Note on iterate screenshots

The iterate-client uses

canvas.toDataURL()

which returns blank/black images when Phaser uses WebGL with

preserveDrawingBuffer: false

. Always prefer Playwright MCP viewport screenshots (

browser_take_screenshot

) over iterate screenshots for visual review.

Without MCP (fallback):

Read the iterate screenshots from

output/iterate/shot-*.png

(may be black if WebGL — this is expected)

Fall back to code review: read scene files and assess visual correctness from the code

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:

-

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

When the QA subagent reports FAIL:

Read

output/autofix-history.json

to see what fixes were already attempted. If a previous entry matches the same

issue

and

fix_attempted

with

result: "failure"

, instruct the subagent to try a different approach.

Launch a

fix subagent

via

Task

tool with:

The ISSUES list from the QA result

The phase that failed (build errors, runtime errors, gameplay issues, visual problems)

Any relevant failed attempts from

output/autofix-history.json

so the subagent knows what NOT to repeat

After each autofix attempt

, append an entry to

output/autofix-history.json

:

{

"step"

:

""

,

"issue"

:

""

,

"fix_attempted"

:

""

,

"result"

:

"success|failure"

,

"timestamp"

:

""

}

Re-run the QA subagent (all phases)

Up to

3 total attempts

per step (1 original + 2 retries)

If all 3 attempts fail, report the failure to the user and ask whether to skip or abort

Important

Always fix issues before proceeding to the next step. The autofix loop ensures each step produces working, visually correct output.

Instructions

Step 0: Initialize pipeline

Parse

$ARGUMENTS

to determine the game concept. Arguments can take two forms:

Form A: Direct specification

Engine

:

2d

(Phaser — side-scrollers, platformers, arcade) or

3d

(Three.js — first-person, third-person, open world). If not specified, ask the user.

Name

The game name in kebab-case. If not specified, ask the user what kind of game they want and suggest a name.

Form B: Tweet URL as game concept

If

$ARGUMENTS

contains a tweet URL (matching

x.com//status/

,

twitter.com//status/

,

fxtwitter.com//status/

, or

vxtwitter.com//status/

):

Fetch the tweet

using the

fetch-tweet

skill — convert the URL to

https://api.fxtwitter.com//status/

and fetch with

WebFetch

Default to 2D

(Phaser) — tweets describe ideas that map naturally to 2D arcade/casual games

Creatively abstract a game concept

from the tweet text. Your job is creative transformation — extract themes, dynamics, settings, or mechanics and reinterpret them as a game.

NEVER refuse to make a game from a tweet.

Every tweet contains something that can inspire a game:

News about weather → survival game, storm-dodging game

Sports result → arcade sports game

Political/legal news → strategy game, puzzle game, tower defense

Personal story → narrative adventure, platformer themed around the journey

Product announcement → tycoon game, builder game

Abstract thought → puzzle game, experimental art game

The transformation is the creative act. You are not recreating or trivializing the source — you are using it as a springboard for an original game concept.

Generate a game name

in kebab-case from the abstracted concept (not from literal tweet content)

Tell the user

what you extracted:

Found tweet from

@handle

:

"Tweet text..."

I'll build a 2D game based on this:

[your creative interpretation as a game concept]

Game name:

Sound good?

Wait for user confirmation before proceeding. The user can override the engine (to 3D) or the name at this point.

Celebrity Detection:

After determining the game concept, scan the concept description, tweet text, and any mentioned people for celebrity/public figure names. Check against:

character-library/manifest.json

(relative to plugin root) — exact slug match or name match

Common name recognition — politicians, tech CEOs, world leaders, entertainers

If celebrities are detected:

Set

hasCelebrities = true

and list detected names

Note in

progress.md

which characters are pre-built vs need building

2D

The Step 1.5 subagent will use photo-composite characters for these

3D

For each celebrity, try: (1) generate with Meshy AI —

"a cartoon caricature of , , low poly game character"

then rig for animation, (2) check

3d-character-library/manifest.json

for a pre-built match, (3) search Sketchfab with

find-3d-asset.mjs

, (4) fall back to best-matching library model. Meshy generation produces the best results for named personalities since it can capture specific visual features.

Meshy API Key (3D games only):

If the engine is 3D, check if

MESHY_API_KEY

is set in the environment. If not,

ask the user immediately in Step 0

— don't wait until Step 1.5:

I'll generate custom 3D models with Meshy AI for the best results. You can get a free API key in 30 seconds:

Sign up at

https://app.meshy.ai

Go to Settings → API Keys

Create a new API key

What is your Meshy API key? (Or type "skip" to use generic model libraries instead)

Store the key for all subsequent

meshy-generate.mjs

calls throughout the pipeline.

Create all pipeline tasks upfront using

TaskCreate

:

Scaffold game from template

Add assets: pixel art sprites (2D) or Meshy AI-generated GLB models + animated characters (3D)

Add visual polish (particles, transitions, juice)

Record promo video (autonomous 50 FPS capture)

Add audio (BGM + SFX)

Deploy to here.now

Monetize with Play.fun (register on OpenGameProtocol, add SDK, redeploy)

This gives the user full visibility into pipeline progress at all times. Quality assurance (build, runtime, visual review, autofix) is built into each step, not a separate task.

After creating tasks, create the

output/

directory in the project root and initialize

output/autofix-history.json

as an empty array

[]

. This file tracks all autofix attempts across the pipeline so fix subagents avoid repeating failed approaches.

Step 1: Scaffold the game

Mark task 1 as

in_progress

.

Main thread — infrastructure setup:

Locate the plugin's template directory. Check these paths in order until found:

The agent's plugin cache (e.g.

~/.claude/plugins/cache/local-plugins/game-creator/1.0.0/templates/

)

The

templates/

directory relative to this plugin's install location

Determine the target directory.

If the current working directory is the

game-creator

plugin repository (check for

CLAUDE.md

mentioning "game-creator" or

.claude-plugin/plugin.json

), create the game inside

examples/

(e.g.,

examples//

). Otherwise, create it in the current working directory (

/

).

Copy the entire template directory to the target:

2D: copy

templates/phaser-2d/

→

/

3D: copy

templates/threejs-3d/

→

/

Update

package.json

— set

"name"

to the game name

Update

<title>

in

index.html

to a human-readable version of the game name

Verify Node.js/npm availability

Run

node --version && npm --version

to confirm Node.js and npm are installed and accessible. If they fail (e.g., nvm lazy-loading), try sourcing nvm:

export NVM_DIR="$HOME/.nvm" && source "$NVM_DIR/nvm.sh"

then retry. If Node.js is not installed at all, tell the user they need to install it before continuing.

Run

npm install

in the new project directory

Install Playwright and Chromium

— Playwright is required for runtime verification and the iterate loop:

Check if Playwright is available:

npx playwright --version

If that fails, check

node_modules/.bin/playwright --version

If neither works, run

npm install -D @playwright/test

explicitly

Then install the browser binary:

npx playwright install chromium

Verify success; if it fails, warn and continue (build verification still works, but runtime/iterate checks will be skipped)

Verify template scripts exist

— The template ships with

scripts/verify-runtime.mjs

,

scripts/iterate-client.js

, and

scripts/example-actions.json

. Confirm they are present. The

verify

and

iterate

npm scripts are already in

package.json

from the template.

Start the dev server

— Before running

npm run dev

, check if the configured port (in

vite.config.js

) is already in use:

lsof -i : -t

. If occupied, update

vite.config.js

to use the next available port (try 3001, 3002, etc.). Then start the dev server in the background and confirm it responds. Keep it running throughout the pipeline. Note the actual port number — pass it to

scripts/verify-runtime.mjs

via the

PORT

env variable in subsequent runs.

Subagent — game implementation:

Launch a

Task

subagent with these instructions:

You are implementing Step 1 (Scaffold) of the game creation pipeline.

Project path

:

Engine

:

<2d|3d>

Game concept

:

Skill to load

:

phaser

(2D) or

threejs-game

(3D)

Core loop first

— implement in this order:

Input (touch + keyboard from the start — never keyboard-only)

Player movement / core mechanic

Fail condition (death, collision, timer)

Scoring

Restart flow (GameState.reset() → clean slate)

Keep scope small:

1 scene, 1 mechanic, 1 fail condition

. Wire spectacle EventBus hooks alongside the core loop — they are scaffolding, not polish.

Transform the template into the game concept:

Rename entities, scenes/systems, and events to match the concept

Implement core gameplay mechanics

Wire up EventBus events, GameState fields, and Constants values

Ensure all modules communicate only through EventBus

All magic numbers go in Constants.js

No title screen

— the template boots directly into gameplay. Do not create a MenuScene or title screen. Only add one if the user explicitly asks.

No in-game score HUD

— the Play.fun widget displays score in a deadzone at the top of the game. Do not create a UIScene or HUD overlay for score display.

Mobile-first input

Choose the best mobile input scheme for the game concept (tap zones, virtual joystick, gyroscope tilt, swipe). Implement touch + keyboard from the start — never keyboard-only. Use the unified analog InputSystem pattern (moveX/moveZ) so game logic is input-source-agnostic.

Force portrait for vertical games

For dodgers, runners, collectors, and endless fallers, set

FORCE_PORTRAIT = true

in Constants.js. This locks portrait layout on desktop (pillarboxed with black bars via

Scale.FIT + CENTER_BOTH

). Use fixed design dimensions (540×960), not conditional

_isPortrait ? 540 : 960

.

Visible touch indicators required

Always render semi-transparent arrow buttons (or direction indicators) on touch-capable devices. Use capability detection (

('ontouchstart' in window) || (navigator.maxTouchPoints > 0)

), NOT OS detection (

device.os.android || device.os.iOS

). Enable pointer events (pointerdown/pointermove/pointerup) on ALL devices — never gate behind

isMobile

. Use

TOUCH

constants from Constants.js for sizing.

Minimum 7–8% canvas width for collectibles/hazards

Items smaller than 7% of

GAME.WIDTH

become unrecognizable blobs on phone screens. Size attacks at ~9%, power-ups at ~7%, player character at 12–15%.

Wire spectacle events: emit

SPECTACLE_ENTRANCE

in

create()

,

SPECTACLE_ACTION

on every player input,

SPECTACLE_HIT

on score/destroy,

SPECTACLE_COMBO

on consecutive hits (pass

{ combo }

),

SPECTACLE_STREAK

at milestones (5, 10, 25 — pass

{ streak }

),

SPECTACLE_NEAR_MISS

on close calls

Visual identity — push the pose:

If the player character represents a real person or brand, build visual recognition into the entity from the start. Don't use generic circles/rectangles as placeholders — use descriptive colors, proportions, and features that communicate identity even before pixel art is added.

Named opponents/NPCs must have visual presence on screen — never text-only. At minimum use distinct colored shapes that suggest the brand. Better: simple character forms with recognizable features.

Collectibles and hazards must be visually self-explanatory. Avoid abstract concepts ("imagination blocks", "creativity sparks"). Use concrete objects players instantly recognize (polaroids, trophies, lightning bolts, money bags, etc.).

Think: "Could someone screenshot this and immediately know what the game is about?"

NEVER

use a single letter (C, G, O) as a character's visual identity

NEVER

differentiate two characters only by fill color — they must have distinct silhouettes and features

When a company is featured (OpenAI, Anthropic, xAI, etc.), use the CEO as the character: Altman for OpenAI, Amodei for Anthropic, Musk for xAI, Zuckerberg for Meta, Nadella for Microsoft, Pichai for Google, Huang for NVIDIA

Add entrance sequence in

create()

player starts off-screen, tweens into position with Bounce.easeOut , landing shake + particle burst Add combo tracking to GameState: combo (current streak, resets on miss), bestCombo (session high), both reset in reset() Ensure restart is clean — test mentally that 3 restarts in a row would work identically Add isMuted to GameState for mute support CRITICAL — Preserve the button pattern: The template's GameOverScene.js contains a working createButton() helper (Container + Graphics + Text). Do NOT rewrite this method. Keep it intact or copy it into any new scenes that need buttons. The correct z-order is: Graphics first (background), Text second (label), Container interactive. If you put Graphics on top of Text, the text becomes invisible. If you make the Graphics interactive instead of the Container, hover/press states break. Character & entity sizing: Character WIDTH from GAME.WIDTH * ratio , HEIGHT from WIDTH * SPRITE_ASPECT (where const SPRITE_ASPECT = 1.5 for 200×300 spritesheets). Never define character HEIGHT as GAME.HEIGHT * ratio — on mobile portrait, GAME.HEIGHT is much larger than GAME.WIDTH , squishing characters. For character-driven games (named personalities, mascots, famous figures): make the main character prominent — GAME.WIDTH * 0.12 to GAME.WIDTH * 0.15 (12–15% of screen width). Use caricature proportions (large head = 40–50% of sprite height, exaggerate distinguishing features) for personality games. Non-character entities (projectiles, collectibles, squares) can use GAME.WIDTH * ratio for both dimensions since they have no intrinsic aspect ratio to preserve. Play.fun safe zone: Import SAFE_ZONE from Constants.js . All UI text, buttons, and interactive elements (title text, score panels, restart buttons) must be positioned below SAFE_ZONE.TOP . The Play.fun SDK renders a 75px widget bar at the top of the viewport (z-index 9999). Use safeTop + usableH * ratio for proportional positioning within the usable area (where usableH = GAME.HEIGHT - SAFE_ZONE.TOP ). Generate game-specific test actions: After implementing the core loop, overwrite scripts/example-actions.json with actions tailored to this game. Requirements: Use the game's actual input keys (e.g., ArrowLeft/ArrowRight for dodger, space for flappy, w/a/s/d for top-down) Include enough gameplay to score at least 1 point Include a long idle period (60+ frames with no input) to let the fail condition trigger Total should be at least 150 frames of gameplay Example for a dodge game (arrow keys): [ { "buttons" : [ "ArrowRight" ] , "frames" : 20 } , { "buttons" : [ "ArrowLeft" ] , "frames" : 20 } , { "buttons" : [ "ArrowRight" ] , "frames" : 15 } , { "buttons" : [ ] , "frames" : 10 } , { "buttons" : [ "ArrowLeft" ] , "frames" : 20 } , { "buttons" : [ ] , "frames" : 80 } ] Example for a platformer (space to jump): [ { "buttons" : [ "space" ] , "frames" : 4 } , { "buttons" : [ ] , "frames" : 25 } , { "buttons" : [ "space" ] , "frames" : 4 } , { "buttons" : [ ] , "frames" : 25 } , { "buttons" : [ "space" ] , "frames" : 4 } , { "buttons" : [ ] , "frames" : 80 } ] Before returning, write /design-brief.md :

Design Brief

Concept

One-line game concept.

Core Mechanics

For each mechanic: - Name: what it does - State field: which GameState field it affects - Expected magnitude: how much/fast it should change (e.g., "reaches 50-70% of max within the round duration without player input")

Win/Lose Conditions

• How the player wins
• How the player loses
• Confirm both outcomes are realistically achievable with the current Constants.js values

Entity Interactions

For each visible entity (enemies, projectiles, collectibles, environmental objects): - Name: what it is - Visual identity: what it should LOOK like and why (reference real logos, people, objects — not abstract concepts) - Distinguishing feature: the ONE exaggerated feature visible at thumbnail size (e.g., "curly dark hair + glasses" for Amodei, "leather jacket" for Jensen Huang) - Real image asset: logo URL to download, or "pixel art" if no real image applies - Behavior: what it does (moves, falls, spawns, etc.) - Player interaction: how the player interacts with it (dodge, collect, tap, block, or "none — background/decoration") - AI/opponent interaction: how the opponent interacts with it, if applicable For named people: describe hair, glasses, facial hair, clothing. For companies: specify logo to download. NEVER use a letter or text label as visual identity.

Expression Map

For each personality character, map game events to expressions:

Player: [Name]