Where this came from

I taught my 9 year old about Claude Code by helping him vibe code a browser based game. He described what he wanted, I helped with the prompting and we ended up with something playable: Battlefield First Edition.

It was a great experience. He got to see his ideas turn into something real. I was the translator between what he imagined and what Claude Code needed to hear.

What if there was something purpose built for this? Not a general coding assistant that happens to be able to make games, but a platform designed specifically to turn descriptions into playable games.

I took a crack at building it in December 2025. The results weren’t quite there so I shelved it for a future date when the models (or my approach) might be better suited for it.

The concept

Makercade would be a browser based platform where you describe a game and watch it come to life.

The primary audience is kids ages 8 to 14, but the design should feel welcoming to anyone. A parent, teacher, or hobbyist adult should feel just as comfortable using it. The aesthetic should be approachable but not childish, sophisticated but not intimidating. A well-crafted tool, not a toy.

The emotional arc

The experience is designed around a progression of feelings that culminates in ownership and pride.

Anticipation. The user has described their game and initiated the build. Visual cues indicate activity without revealing exactly what’s coming.

First sign of life. Within seconds (ideally under 3), something visible appears. A colored canvas, a background, the game world taking shape. This immediate feedback validates that their input was received and magic is happening. Speed here is critical.

Recognition. Elements they specifically requested begin appearing. When their chosen character materializes on screen, there should be a moment of “That’s MY character!” The astronaut they requested, the space theme they described, the stars they wanted to collect.

Delight. The moment the game becomes interactive is the peak. When pressing arrow keys actually moves the sprite they imagined, the game transforms from something they’re watching to something they’re playing.

Ownership. The culmination: “I made this.” This isn’t a template they filled in or a tutorial they followed. This is a game that exists because of their imagination. The shareable URL, the ability to have friends and family play it, the option to remix and improve: these all reinforce that this creation belongs to them.

Creation modes

Different users have different comfort levels with open-ended creative tasks. Makercade offers multiple paths.

Guided mode

A wizard-style interface walks users through structured choices. At each step, visual cards present curated options while maintaining an escape hatch for custom input.

Game type selection. Large cards present archetypes: Platformer, Space Shooter, Maze Runner, Catch Game. Each includes a small preview showing what that type looks like. A “Something else…” option allows free-form description.

Character and world. “Who’s your hero?” accepts text with suggestion chips (astronaut, ninja, robot, animal). “Where does the game happen?” offers settings: space, underwater, forest, city, castle. Free-form input remains available: “Or describe it yourself…”

Goal and challenge. “How do you win?” presents options: reach the end, collect N things, survive for N seconds, defeat the boss. “What makes it hard?” offers: enemies, time limits, obstacles, puzzles, limited lives.

Make it yours. A final free-form area: “Anything else special about your game?” This captures unique ideas: “The platforms should float and bob up and down,” “My character should leave a rainbow trail,” “The enemies should be pizza slices.”

Freeform mode

A single large text area for users who know what they want. Placeholder text guides input: “Describe your game in as much detail as you want…” Hint chips suggest aspects to consider: characters, goal, obstacles, controls, setting. Example prompts demonstrate effective descriptions.

Remix mode

Start from an existing game and make it your own. This lowers the barrier significantly. Instead of imagining from scratch, iterate on something that already works.

Entry points: browsing a public gallery, pasting a game URL, clicking “Remix” on any published game. The builder opens with the original game’s configuration pre-populated. Users can modify any aspect: swap the character, change the setting, add new challenges. They can switch to freeform to describe broader changes: “Make this game underwater instead of space.”

Publishing creates a new game with its own URL while preserving attribution to the original. The original game is never modified. Remixing is always non-destructive.

Progressive disclosure

Even within guided mode, each step offers an escape hatch to more detailed input. When selecting a game type, “Something else” allows custom description. When picking a character, “Or describe your own” enables imagination beyond the offered options. Structured guidance should never become a cage.

Progressive game building

This is the heart of the experience. Rather than generating a complete game after a long wait, the platform builds in visible layers, creating an “unfolding” effect that maintains engagement and delivers emotional payoffs throughout.

Interface layout

A split-panel layout. Left panel shows the current configuration and build progress checklist with status for each layer (checkmark for complete, spinner for in-progress, empty circle for pending). Friendly messages describe what’s happening: “Creating your world…”, “Spawning your hero…”, “Adding movement…”

Right panel contains the live preview in a sandboxed frame. Updates in real-time as each layer completes. Becomes interactive once the movement layer is done. Users can play mid-build. Control hints appear: “Use arrow keys to move!”

The layers

Layer 0: Canvas and background. Target: under 2 seconds. Creates the game canvas with the theme’s background. The preview changes from empty to showing a colored, themed backdrop. Emotional beat: “Something is happening!”

Layer 1: Ground and platforms. Target: 2-3 seconds. Adds the physical structure. Ground plane, floating platforms, obstacles to navigate. Emotional beat: “The world exists.”

Layer 2: Player sprite (static). Target: 2-3 seconds. Adds the player’s character, positioned but not yet controllable. The hero appears! Emotional beat: “That’s ME!”

Layer 3: Player movement. Target: 3-4 seconds. Adds physics, controls, movement logic. The game becomes playable. Emotional beat: “I can play it!” This is the critical milestone.

Layer 4: Goal items. Target: 3-4 seconds. Adds collectibles, objectives, finish lines. Stars, coins, keys, flags appear. Emotional beat: “I see what I need to do.”

Layer 5: Obstacles and enemies. Target: 3-4 seconds. Adds challenge elements. Enemies with movement patterns, hazards, time pressure. Emotional beat: “Now it’s a real game.”

Layer 6: Win/lose conditions and UI. Target: 3-4 seconds. Adds game state management, score display, win/lose screens, restart. Emotional beat: “It’s complete.”

Layer 7: Polish. Target: 3-4 seconds. Visual and audio flourishes. Particle effects, sound effects, animations, screen shake. Emotional beat: “This feels professional.”

Graceful degradation

If later layers fail, the game should still be deliverable. After Layer 3, the user has a playable experience. Layer 4 failure means no collectibles but still playable as a movement sandbox. Layer 5 failure means no enemies but still completable. Layer 6 failure means no win condition but still explorable. Layer 7 failure means no polish but still functional.

Users always get something playable even when generation encounters difficulties.

Error handling

This is a critical differentiator. Unlike general-purpose AI coding tools that surface errors to users, Makercade makes technical failures invisible.

Users should never see stack traces, error codes, or debugging information. When something fails, the system fixes it automatically or simplifies gracefully. Users should feel like magic is happening, not like they’re fighting technology.

Tiered response

Tier 1: Silent self-healing. Generated code produces an error in the sandbox. The system automatically retries with error context. The user sees nothing, just a slightly longer “Building…” animation. Target: 80% of errors self-heal without user awareness.

Tier 2: Friendly difficulty acknowledgment. If automatic retry fails after 2-3 attempts, a friendly message appears. Not an error, but an acknowledgment: “Hmm, that’s tricky. Trying a different approach…” The system attempts simplified generation: reduced physics complexity, simpler collision, fewer simultaneous elements.

Tier 3: Graceful degradation with user choice. If simplification still fails, the user receives options rather than an error: “Having trouble with the jumping part. Want to try describing it differently, or should I skip it for now?” Options: “Try again with different words,” “Skip this part,” “Keep what we have.” The user maintains agency without needing to understand what went wrong.

Recovery by layer

Different layers have different recovery options based on criticality:

• Canvas: Must succeed. Retry until working or fail the entire build.
• Platforms: Simplify on failure: reduce platform count, use simpler shapes.
• Sprite: Fall back to default sprite if custom generation fails.
• Movement: Must succeed for playable game. Retry with simplified physics if needed.
• Goals/Enemies: Can be skipped. Game remains playable without these.
• Win/Lose: Simplify to basic version: “You win!” text on goal reach.
• Polish: Entirely optional. Skip without impact.

Publishing and sharing

Publishing is the culmination of the creative journey. It should feel satisfying. The resulting game should be effortlessly shareable.

Slug selection

Rather than assigning random identifiers, the URL becomes part of the creative process. The slug should be something creators are proud to share and can communicate verbally to friends and family.

The AI generates 4-5 contextually relevant suggestions based on the game’s content. For a space platformer with an astronaut collecting stars: “astro-star-collector,” “space-boy-adventure,” “cosmic-star-quest,” “jetpack-galaxy-run.”

A “More ideas” button generates additional suggestions. A text field allows completely custom slugs with real-time validation for availability and appropriateness.

Slug requirements: lowercase letters, numbers, and hyphens only. 2-4 words, maximum 40 characters. Globally unique. Must pass content filters. Should be easy to say aloud and remember.

The publish moment

When the user clicks “Publish,” a brief animation marks the moment. The confirmation screen presents the shareable URL prominently with one-click copy, an instantly generated QR code (print it, put it on the fridge, let grandma scan it), and a download option for the game as a standalone HTML file.

URL structure

Clean, memorable URLs:

• Home/Builder: makercade.games/
• Play a Game: makercade.games/play/[slug]
• Remix a Game: makercade.games/remix/[slug]
• Browse Gallery: makercade.games/gallery

No accounts required

The platform operates without user accounts, passwords, or authentication flows. This removes barriers and avoids complexity and privacy concerns, particularly for minors.

When a user publishes a game, the slug and metadata are stored in browser localStorage. The homepage shows a “My Games” section for games created on this device.

Limitations: game list is lost if browser data is cleared, games don’t sync across devices, incognito won’t persist. Mitigations: games themselves persist on the server regardless, users can bookmark URLs, users can remix their own games to “recover” them.

Published games are stored server-side: slug, title, configuration, generated HTML (complete playable game as a single file), parent slug (if remixed), timestamp, play count.

Content safety

As a platform serving a broad audience including children, content safety is paramount. Moderation must prevent inappropriate content without creating friction for legitimate creative expression.

Input moderation

All user text input passes through content filtering before processing. A blocklist catches obvious inappropriate terms. Substring matching catches attempts to embed inappropriate words. Context-aware AI moderation evaluates ambiguous cases.

Custom slugs receive additional scrutiny since they become public URLs. Inappropriate slugs are rejected with a generic “That name isn’t available” rather than explaining why.

Generation guardrails

The AI generation process includes system-level instructions to maintain age-appropriate content. Regardless of user input, generated games should never contain violence beyond cartoonish conflict, scary or disturbing imagery, inappropriate themes, or anything unsuitable for a general audience.

Output review

Generated game content is checked before publishing. If moderation flags content, the system silently regenerates rather than surfacing the issue.

Abuse prevention

Rate limiting prevents automated abuse. Pattern detection blocks repeated attempts to generate inappropriate content. Content takedown ability for published games that violate guidelines. Every published game includes a subtle but accessible “Report” option.

Accessibility

Games and the builder interface must be usable by people with disabilities:

• Full keyboard navigation for the builder
• Games playable with keyboard (arrow keys, space, enter)
• Sufficient color contrast (WCAG AA minimum)
• Screen reader announcements for key state changes
• No seizure-inducing flashing in generated games
• Respects prefers-reduced-motion for interface animations

The builder should be fully functional on desktop and tablet, simplified but usable on mobile. Games should be playable on all device sizes with touch controls for mobile.

Technical requirements

Games must be single-file HTML documents. All JavaScript embedded inline or loaded from public CDNs. All CSS embedded inline. Games run entirely client-side with no server dependencies after load. Games must function when downloaded and opened locally.

Performance targets:

• First layer visible within 3 seconds of build initiation
• Complete game generation within 30 seconds under normal conditions
• Game load time under 2 seconds
• Stable 30+ FPS during gameplay

Generated games run in sandboxed iframes. JavaScript errors are caught and reported to parent frame. No access to parent page DOM or data.

MVP scope

The minimum viable product focuses on proving the core loop: a user can describe a game and watch it come to life.

Includes:

• Single game type: Platformer only
• Guided mode only (three-phase wizard)
• Core layers: canvas, platforms, sprite, movement, collectibles
• Basic error recovery with silent retry
• Slug selection with AI suggestions and custom input
• Publish and share with downloadable HTML
• Basic remix: fork any published game into the builder
• Content moderation on inputs and slugs
• Generation logging for evaluation

Excludes (future phases):

• Additional game types (shooter, maze, catch)
• Freeform description mode
• Enemies and obstacles layer
• Polish layer (particles, sounds)
• Public gallery browsing
• Play count statistics display
• QR code generation
• Custom sprite upload

Success criteria:

• Complete the wizard in under 2 minutes
• First visual feedback within 3 seconds of build start
• Playable game within 20 seconds
• 90% of builds complete without user-visible errors
• Published games load and play correctly
• Remix flow successfully loads parent game configuration

Future possibilities

Beyond MVP, the platform could expand in several directions:

Expanded creation. Additional game types: space shooter, maze runner, catch game, endless runner. Freeform mode for advanced users. Complete layer stack with enemies and polish.

Community features. Public gallery with curated collections. Remix count and play count as social proof. Featured games and creator spotlights. Game jams and themed challenges.

Enhanced assets. Expanded sprite library. Sound effect library. Background music options. Custom sprite upload with moderation.

Platform expansion. Optional accounts for cross-device game management. Classroom and educator features. Mobile-optimized builder.

Open questions

Technical:

• Which game engine for generated games? Phaser is the likely candidate.
• Which AI model tier balances cost vs quality for generation?
• Hosting platform and caching strategy?
• How to structure generation templates for consistency?
• Log storage solution and retention policy?

Product:

• Exact rate limits to prevent abuse without blocking legitimate use?
• Content retention policy for published games?
• How to handle games that go viral (load spikes)?
• Can creators delete games? Tricky without authentication.
• Feedback mechanism implementation details?