CodeWisp lets anyone create playable web games from a text prompt. Here's how they built a browser-native AI game engine — and why replicating it is harder than it looks.
TL;DR
CodeWisp lets anyone create playable browser games from a text prompt by pairing frontier LLMs with a custom constrained game runtime. Founded by a 2x game engine builder, they hit 17K+ games created in under six months. The moat is the runtime/generation co-design — not the AI calls, which anyone can replicate.
Build difficulty
Complete replication guide — install as a slash command or rules file
Claude's Corner# Build a CodeWisp Clone in 7 Steps
## Step 1: Design the Constrained Game Runtime
This is the most important step and most people skip it. Build a lightweight browser game engine with a tightly-scoped JavaScript API — not a general-purpose engine. Your API surface should cover: createSprite(config), addCollider(a, b, callback), setPhysics(options), createTile(map, config), addParticleSystem(config), syncMultiplayer(state). Keep it small. Every function you add is another thing the LLM has to get right.
**DB Schema (games table):**
```sql
CREATE TABLE games (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
slug TEXT UNIQUE NOT NULL,
title TEXT,
prompt TEXT NOT NULL,
game_spec JSONB NOT NULL,
generated_code TEXT NOT NULL,
asset_manifest JSONB,
is_public BOOLEAN DEFAULT true,
is_multiplayer BOOLEAN DEFAULT false,
play_count INTEGER DEFAULT 0,
like_count INTEGER DEFAULT 0,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
```
## Step 2: Build the Generation Pipeline
Use a two-pass LLM approach:
**Pass 1 — Spec extraction** (Claude claude-sonnet-4-6, structured output):
Define a strict JSON schema for genre, view, mechanics, player_input, win_condition, visual_theme, is_multiplayer. The model fills in the blanks from the user prompt. Ambiguity gets resolved using genre conventions.
**Pass 2 — Code generation** (Claude claude-opus-4-7, long context):
System prompt must include your entire runtime API reference. The model generates against YOUR API, not arbitrary game code. Include 3-5 few-shot examples of prompt to generated code pairs. This dramatically improves output reliability.
## Step 3: Asset Generation Service
Build an async asset pipeline:
- Sprites: Use Stable Diffusion XL or FLUX with a pixel-art LoRA for consistency
- Backgrounds: Generate at 1920x1080, tile as needed
- Sound effects: ElevenLabs Sound Effects API or AudioCraft
- Cache everything aggressively — same visual theme means same assets across games
```python
async def generate_assets(spec):
cache_key = hash_spec_for_assets(spec)
if cached := await redis.get(cache_key):
return cached
sprites = await generate_sprites(spec.visual_theme, spec.entities)
bg = await generate_background(spec.visual_theme, spec.view)
sfx = await generate_sfx(spec.mechanics)
manifest = AssetManifest(sprites=sprites, background=bg, sfx=sfx)
await redis.setex(cache_key, 86400, manifest.json())
return manifest
```
## Step 4: In-Browser Runtime
Build the runtime in TypeScript on top of Phaser 3 (battle-tested, MIT license). Wrap Phaser API with your constrained surface. The generated code receives a runtime object and calls only these methods. Sandbox with an iframe plus sandbox="allow-scripts" attribute. This prevents malicious generated code from escaping.
Key design rule: the LLM ONLY calls your wrapper methods — never raw Phaser, never raw DOM, never fetch. This is what makes output reliable.
## Step 5: Multiplayer Infrastructure
For multiplayer games, use PartyKit or Cloudflare Durable Objects. One Durable Object per game session. Spin up on first player join, tear down on last player leave. The generated multiplayer code calls runtime.syncMultiplayer() — the runtime handles the socket lifecycle invisibly.
Cost: effectively zero at small scale with Cloudflare DO pricing. Becomes relevant above ~10K concurrent sessions.
## Step 6: Editor UI and Community Layer
Editor: React + a simple textarea or Monaco Editor for the prompt input. Split view: prompt on left, live game iframe on right. Regeneration should be incremental — pass the existing game_spec plus new prompt as delta context to the LLM so it does not rewrite the whole game on every edit.
Community: Standard social primitives — user profiles, game cards, likes, comments, tags. Add a remix button that clones the game spec into a new editor session. This is the viral loop.
```sql
CREATE TABLE game_likes (
user_id UUID REFERENCES users(id),
game_id UUID REFERENCES games(id),
created_at TIMESTAMPTZ DEFAULT NOW(),
PRIMARY KEY (user_id, game_id)
);
CREATE TABLE game_remixes (
original_id UUID REFERENCES games(id),
remix_id UUID REFERENCES games(id),
PRIMARY KEY (original_id, remix_id)
);
```
## Step 7: Deploy and Scale
- Frontend + Editor: Vercel or Cloudflare Pages
- Generation API: Fly.io with GPU instances for asset generation, or Modal for serverless GPU
- Game hosting: Cloudflare R2 for static game bundles, served from Workers
- Multiplayer: Cloudflare Durable Objects (built-in, cheap, globally distributed)
- Database: Supabase (Postgres + auth + storage in one)
- Generation queue: Inngest or BullMQ for async generation jobs
Cost reality check at 1K daily active users: roughly $200-400/month in LLM API costs, $50-100 in compute, $20 in storage. Scale linearly until you need GPU capacity for asset generation, then switch to spot instances or a dedicated GPU cluster.Get the most important AI news daily.
