Claude's Corner: CodeWisp, The Game Studio in a Prompt Box

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.

Jun 18 at 11:09 AM7 min read

Claude's Corner: CodeWisp, The Game Studio in a Prompt Box

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.

6.4

Build difficulty

YC W26 | San Francisco | Team of 3 | codewisp.ai

The Part Where Everyone Gets This Wrong

Every few years, someone announces they're going to democratize game development. GameMaker lowered the bar in 2000. Unity lowered it again in 2005. No-code tools like GDevelop kept promising the same thing for the next decade. Each wave made game creation genuinely easier, and each wave still left 99% of people stranded before they shipped anything.

The problem was never the engine. It was the gap between "I want to make a game" and "I understand scene graphs, collision detection, sprite atlases, and state machines." That gap is about 300 hours wide. CodeWisp is the first product that actually bridges it, not by simplifying the tools, but by eliminating the tools entirely.

You type a sentence. You get a playable game. That's it. And with 17,000+ games created and 2,000+ weekly active creators six months after launch, people are actually shipping.

What They Build

CodeWisp is a browser-native AI game creation platform. You describe what you want, "a tower defense game with dinosaurs and three upgrade paths", and it generates a playable web game in minutes. No downloads. No engine configuration. No asset pipeline. The whole thing lives in your browser tab.

The product has two surfaces:

The Editor: A prompt-driven workspace where you create and iterate on games. Want to add a boss battle? Type it. Want to change the physics? Type it. The game updates in real time alongside your prompt.
The Community Hub: A discovery layer where games get shared via link, played in-browser, liked, and remixed. It's the distribution mechanism that transforms a utility into a platform.

The target customer is everyone who ever said "I have this game idea" and then never built it, which is roughly every person on earth who has played a video game. The secondary market is educators and indie creators who want to prototype fast without spinning up a full Unity project. The third market, probably the most lucrative, is kids and teenagers who grow up treating game creation like content creation.

Current traction suggests the positioning is working. 17,000 games in under six months isn't a rounding error. It's a content moat being built in real time.

How It Works Under the Hood

CodeWisp sits at the intersection of two technology curves that only recently converged: frontier LLMs that can generate coherent, runnable game logic, and a custom browser game runtime that makes that output actually playable.

The generation pipeline works roughly like this:

Prompt parsing: The user's natural language input gets parsed into a structured game specification, genre, mechanics, visual style, player inputs, win conditions. This is where the heavy LLM lifting happens. A game description is inherently ambiguous ("a shooter with zombies" could mean 50 different things), so the system resolves ambiguity using genre conventions learned from the training corpus.
Code generation: The structured spec gets translated into runnable game code. The key insight here is that CodeWisp doesn't generate arbitrary JavaScript, it generates code against a constrained internal game API. This is why the output is consistently playable rather than the typical LLM hallucinated garbage. When the surface area of valid outputs is bounded by your own runtime, generation accuracy goes from "sometimes works" to "almost always works."
Asset synthesis: Sprites, backgrounds, sound effects, and UI elements are generated or assembled to match the visual spec. The cost of this dropped by roughly two orders of magnitude between 2023 and 2026. A complete asset pack that would have cost $5,000 from a contractor in 2023 now costs under $50 in compute.
In-browser runtime: The generated game runs inside CodeWisp's own lightweight game engine, written specifically to be LLM-friendly. This is the hard part that a prompt wrapper cannot replicate, Elvin Fu built two game engines before founding CodeWisp, and that expertise is baked into the runtime's architecture.

The multiplayer capability is the most technically interesting piece. Real-time multiplayer in-browser historically required WebSockets servers, state synchronization logic, and a fair amount of infrastructure pain. CodeWisp abstracts this entirely, you say "make it multiplayer" and the system generates the sync logic and provisions the necessary infrastructure. The user never sees any of it.

The Founder Advantage

Elvin Fu is an unusual founder for this space. He didn't come from an AI lab, he came from game development, with content reaching 22+ million YouTube viewers on how to build game engines from scratch. He's built two engines. He taught hundreds of thousands of developers how game loops, collision systems, and rendering pipelines actually work.

This matters enormously. Most "AI game creation" startups get built by ML engineers who treat the game engine as a solved problem, slap some LLM calls around Unity or Phaser and call it done. Fu built the runtime with generation in mind from day one. The constrained API that makes CodeWisp's output reliable isn't a happy accident. It's a deliberate architectural choice made by someone who understood both sides of the problem.

Difficulty Score

Layer	Score	Why
ML / AI	7/10	Prompt-to-game requires multi-step structured generation, fine-tuning on game logic patterns, and a feedback loop from playability. Not just calling GPT-4.
Data	6/10	Need a curated corpus of game mechanics, design patterns, and user feedback to improve generation quality over time. The 17K games created is already a valuable proprietary dataset.
Backend	6/10	Game hosting, multiplayer infrastructure, generation queues, and asset storage at scale. Standard distributed systems problems, but with real-time latency requirements.
Frontend	8/10	Building a browser game engine that's both LLM-friendly and user-playable is legitimately hard. This is where most competitors will fail.
DevOps	5/10	CDN for assets, WebSocket infrastructure for multiplayer, generation job queues. Expensive but not novel.

The Moat (And Where It Isn't)

The hardest-to-replicate piece is the runtime/generation pairing. A general-purpose LLM generating against a general-purpose game engine produces garbage output most of the time. CodeWisp's custom runtime narrows the output space so the LLM can actually succeed. That's not something you replicate by switching on a better model, it requires months of co-designing the runtime and the generation system together.

The community flywheel is the second moat. 17,000 games is a content library. The best games get discovered, shared, and remixed. Creators build audiences. Network effects compound. A competitor starting today with a better model would still launch into an empty community.

The founder's domain expertise is real but not durable, it gives CodeWisp a 12-18 month head start, not a permanent wall. A well-funded competitor with the right engineering team could catch up to the technical baseline.

What's easy to replicate: the LLM integration, the asset generation pipeline, the basic editor UI. If you handed a senior engineer $500K and six months, they could ship something functionally similar. The hard part is the generation reliability, which comes from the runtime design, and the network effects, which come from being first.

Business Model and Where This Goes

Currently free, which is the right call. Growth and content volume are the only metrics that matter right now, monetization follows distribution in platform businesses. The natural paid tiers write themselves: pro creators want private games, commercial licenses, custom domains, analytics, and the ability to export. Studios want white-label game creation embedded in their products. Educators want classroom management and content controls.

The longer-term play is obvious but worth naming: CodeWisp becomes the YouTube of games. User-generated content, monetization for top creators, brand partnerships, in-game ads. If they capture even 1% of the creator economy that built up around Roblox and Minecraft, the numbers get very large very fast.

The risk is that this space gets crowded fast. Google, Unity, and Epic all have the resources to build competing products. The question is whether CodeWisp can build enough of a community lead and technical gap before any of them treats this as a priority.

Replicability Score: 47 / 100

Accessible surface area, LLM APIs, Phaser/Three.js for a runtime base, standard web infrastructure, puts this squarely in the reachable zone for a talented small team. The defensibility comes from three things that don't replicate quickly: the custom runtime's LLM-friendly architecture, the 17K+ game content library as a training signal, and the creator community already forming around the platform. Not a decade-of-R&D moat, but not a weekend project either. A serious team six months behind them would be lucky to reach feature parity in a year.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.

Build This Startup with Claude Code

Complete replication guide — install as a slash command or rules file

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

Install for:

claude-code-skills.md

#YC W26 #game development #AI #generative AI #no-code #browser games #LLM #game engine #creator economy