Treat your game-generation prompt like a mini PRD. An 8-part skeleton plus a full worked example for getting AI to generate a playable browser game in one shot.
Ever told an AI "make me a Snake game" and gotten back something that runs — but has no feel, no difficulty, and doesn't respond to taps on your phone? The problem is almost never the model. It's that your prompt reads like a wish, not a spec.
This post is about how to actually write the prompt when you want an AI (Claude, GPT, and friends) to generate a playable browser game (H5) in one shot. The whole thing boils down to one idea:
Write your prompt like a mini product requirements doc (PRD), not a one-line wish.
"Make a match-3" hands too many decisions to the model's default imagination: How big is the board? Is a match three-in-a-row or four? Are there combos? How do you win or lose? How does it work on a phone? What's the art style?
The model has to guess. It gets one or two right and the rest wrong, and you end up with something that "technically runs but isn't playable." The time you spend on round after round of "no, what I meant was…" dwarfs the time it would have taken to say it clearly up front.
A good game prompt is really just you making those decisions for the model in advance.
The structure below is a PRD compressed into prompt form. Fill it in and you'll usually get a playable version on the first try.
Anchor what it is in a single sentence. The key is naming the core action the player performs every second (the core verb).
"A portrait-mode casual game: the player drags a slingshot to launch a bird and hits targets to score."
Drag, tap, swipe, snap — this verb defines your entire control scheme. Pin it down.
Describe the loop from start to score/end, step by step:
- Player sees an 8×8 letter grid with emoji clues above
- Player figures out the word each emoji represents and finds it in the grid
- Player presses the first letter and drags to the last to select it
- On a correct word it highlights green and the matching emoji gets a checkmark
- Find all words → level-complete screen
The more specific this is, the higher the output quality. The core loop is the game's heart — leave it vague and everything downstream collapses.
The most commonly skipped — and most fatal — section. Spell out PC and phone controls separately:
- PC: click and drag with the mouse
- Mobile: touch and drag with a finger
- Portrait / landscape
- Target resolution: responsive
Skip mobile and you'll likely get a game that "works on desktop but does nothing on a phone" — because the AI only wired up mousedown, never touchstart.
Be explicit about what winning is, what losing is, and how it ramps up:
- Win: clear all blocks
- Lose: blocks stack to the top
- Progression: denser grid and fewer power-ups each level; timed mode tracks a best score
A game with no clear goal isn't a game — it's a toy.
This is the line between pro and amateur. Don't ask the AI to build the whole game at once — define "what the first version must include":
First version must have: a single 8×8 grid, 5 words, drag-to-select, a highlighted selection path, a win screen + play-again. Not yet: leaderboard, skins, music, multiple difficulties.
Ask for a minimal version that plays through one complete round, then iterate. Ask for everything at once and the model tends to do each piece halfway.
Half of whether a game feels good is feedback. Name the moment-to-moment feedback you want:
- Style: clean, bright, rounded, suited to a portrait phone
- Highlighted-path animation on selection; celebratory particles on win
- A slight scale bump + sound effect on each match
Leave out the "juice" (impact, animation, sound, haptics) and the AI defaults to something that runs but feels lifeless.
This section decides whether the result runs the moment you drop it in a browser:
- Output a single HTML file with inline CSS and JS
- No services that need a backend; if a library is required, use a CDN and name it explicitly
- Persist with
localStorage- Responsive, with a proper mobile viewport
Skip these and you may get a project split across a dozen files, dependent on a build tool, wired to a backend that doesn't exist — undeployable.
Have the AI pull the key numbers into one config object:
Collect grid size, word count, colors, timer toggle, etc. into a single
gameConfigobject at the top for easy tweaking.
Then your second round of edits is just changing values — no re-reading the whole file.
① Two steps: PRD first, then code. For complex games, first have the AI produce a spec using the structure above; review it, fix a few things, then tell it to "implement this PRD." This one step blocks most directional rework.
② Use negative constraints to plug default pitfalls. Tell it what NOT to do: "don't use any service that needs an API key," "don't use fixed pixel widths that overflow on mobile," "don't split assets into external files."
③ Iterate with "locate + reproduce." When you hit a bug, don't just say "it's broken" — say under what action, what happens: "on mobile, tapping two blocks in quick succession, the selection state doesn't clear." The sharper the repro, the sharper the fix.
Make a single-HTML-file portrait casual puzzle game, "Emoji Word Hunt."
Core loop: an 8×8 letter grid with 5 emoji clues above; the player figures out the word each emoji stands for and finds it in the grid (horizontal / vertical / diagonal, forward or backward) by pressing the first letter and dragging to the last; a correct word highlights green and its emoji gets a checkmark; find all 5 to complete the level, show the time, and offer play-again.
Controls: PC mouse drag, mobile finger drag; portrait; responsive resolution.
First version must have: single grid of 5 words, drag-to-select, highlighted path, no penalty for mistakes, win screen + play-again button. Not yet: leaderboard, music, multiple difficulties.
Feel & art: bright and rounded, phone-friendly; highlighted-path animation on selection, celebratory particles on win; a slight scale bump when a word is found.
Technical constraints: single HTML, inline CSS/JS, no backend; persist with localStorage; responsive with a mobile viewport.
Editable parameters: collect grid size, word count and colors into a
gameConfigobject at the top.
Hand that to Claude and you'll most likely get a complete version that plays on a phone right away — instead of yet another "runs but isn't playable" draft.
The bar for AI-generated games has shifted from "can you write the code" to "can you describe the game clearly." And describing a game clearly is exactly the kind of thing you can structure and practice against a template.
Want real examples? Every AI-generated game page on PocketKit ships with the full prompt used to create it — copy it to reproduce, remix, or learn. Pick a few games you like and read them against the skeleton above; you'll find your footing faster.