Best Prompts for Vibe Coding Games: 40+ Copy-Paste Prompts (2026)

Tested June 2026. Works in Cursor, Claude, ChatGPT, Bolt.new, and Rosebud AI.

Here is the prompt that has built more working games for me than any other. Copy it, fill the brackets, paste it into Cursor or Claude, and you have a playable game in minutes instead of a tangled mess you cannot fix.

The master first-prompt (copy this):

Build a playable [2D top-down / side-scroller / one-screen arena] game in [Three.js / Phaser / plain HTML5 canvas].

Core mechanic: [one sentence. e.g. dash through enemies to absorb their color].
Win condition: [e.g. survive 90 seconds].
Lose condition: [e.g. touch a wall of the wrong color].
Controls: WASD plus space, two inputs maximum.
Add: a restart key, an on-screen timer, and a visible score.
Visual style: [two adjectives. e.g. clean, neon].

Rules:
- Build the core mechanic ONLY. No menus, no levels, no shop yet.
- Put tunable values (SPEED, GRAVITY, SPAWN_RATE) at the top of the file as variables.
- One file if possible. Keep it simple. No backend, no login.
- Before you write code, tell me in one line what you are about to build.
- When done, confirm the game runs and the canvas renders.

That single prompt fixes the most common reason vibe-coded games break: asking for everything at once. The rest of this page is every other prompt I use, in the order you need them. No theory. Copy what fits your stage.

If you do not know the workflow yet, read how to vibe code a game first, then come back here for the prompts.

Why most vibe coding prompts fail

Your prompt is your source code now. Garbage in, garbage out. Most AI failures happen because the model does not know what you actually mean, not because it cannot code.

Four rules make every prompt below work:

1. Be explicit about context. In Cursor, @mention the exact file. The AI guesses when you stay vague, and it guesses wrong.
2. Describe behavior, not just code. “The jump should feel floaty, like Celeste” beats “add a jump function.”
3. One change at a time. Iterative prompts beat one giant prompt every single time. A small testable step is a small fixable step.
4. Say what NOT to touch. Locking scope up front is easier than undoing damage after.

Prompts for step 1: the design doc

Do not start with code. Start by making the AI plan the game with you. Paste this into ChatGPT or Claude:

Act as a game designer. Interview me with one question at a time to build a
one-page Game Design Document for a small browser game I can vibe code in a weekend.
Cover: core loop, win/lose, controls, art style, and scope I can finish.
When we are done, output the GDD as clean Markdown I can save as game-design-document.md.
Keep the scope tiny. Talk me out of features I cannot finish in a weekend.

Then lock your stack so the AI stops over-engineering:

Based on this GDD, recommend the simplest yet most robust tech stack for a
browser game with no backend. Give me one stack, not options. Explain in two
sentences why. Then list the exact files we will need and what each one does.

Prompts for step 2: the first playable

You have the plan. Now use the master prompt at the top of this page. After it runs, here are the follow-ups that get you from white box to real:

Add visible game state (do this early):

Add an on-screen HUD showing score, timer, and lives. Keep it minimal,
top-left, monospace font. Do not change the game loop or physics.

Make the feel right:

The movement feels stiff. Make it feel like [Celeste / Vampire Survivors / Downwell]:
[describe the feeling in plain words]. Only change the player controller.
Show me the variables I can tune.

Add the core challenge:

Add enemies that [behavior in one sentence]. Start with the simplest version
that works. Spawn them on a timer using the SPAWN_RATE variable already at
the top of the file. Do not touch the player code.

Prompts for step 3: iterate without breaking the build

This is where games die. These prompts keep you alive.

The scope lock (use constantly):

Change ONLY [filename]. Do not modify the game loop, the physics, or the
input handling. If your change needs those files, stop and tell me first.

The “plan before code” prompt for anything complex:

Before writing any code, analyze what this change touches and list the files
and functions you will edit. Wait for me to approve the plan. Then implement it.

The options prompt (stops the AI committing to a bad approach):

Give me three ways to build [feature], simplest first, with one line on the
trade-off of each. Do not write code yet.

The refactor-safely prompt:

This file is getting long. Split it into logical modules without changing any
behavior. List what moved where. The game must run identically after.

Prompts for step 4: fix vibe-coded game bugs

When the AI says “fixed!” and the game is still broken, stop re-prompting blindly. These work because they force the model to diagnose before it touches code.

The paste-the-error prompt (always include a screenshot):

Here is the exact error and a screenshot of the broken state. Diagnose the
root cause first in plain English. Do not write code until you have told me
what is actually wrong. Then fix only that.

The silent-bug prompt (for when there is no error but it is wrong):

There is no error message, but [describe what is wrong: score does not save /
collision misses fast objects / enemy walks through walls]. Walk through the
relevant code line by line and find where the logic breaks. Explain it, then fix it.

The “you broke something else” prompt:

That fix worked but it broke [thing]. Both need to work. Show me what your last
change touched, then fix the regression without undoing the original fix.

The stop-the-loop prompt (when you are 2 fixes deep and going backward):

Stop. Do not write more code. Summarize everything this feature currently does,
list every known bug, and propose the smallest change that fixes the most. I will
revert to my last working commit if needed.

Cursor rules for game development

A rules file is the single biggest lever to stop the AI hallucinating. In Cursor, save this as .cursor/rules/game.mdc. It runs on every prompt so you stop repeating yourself.

- Stack: Vite + Three.js (r160+) + vanilla JS modules. No frameworks.
- No backend, no database, no login. Everything runs client-side.
- One job per file: input.js, physics.js, render.js, game.js.
- One requestAnimationFrame loop in game.js. Never create a second loop.
- Put tunable constants (SPEED, GRAVITY, SPAWN_RATE) at the top of game.js.
- Never delete working files or package.json without asking.
- Implement the simplest version first. Do not add features I did not ask for.
- When I paste an error, fix only that error. Do not refactor unrelated code.
- Before any large change, list what you will touch and wait for approval.

Swap the first two lines for Phaser or HTML5 canvas if you are building 2D. Cursor leads the market for this because it reads your whole project and you can @mention exact files for context.

Prompts by game type

3D browser game (Three.js):

Build a third-person 3D [game type] in Three.js with Vite. Start with: a ground
plane, a player capsule that moves with WASD and a mouse-look camera, and basic
gravity. White-box only, no textures. Tell me which Three.js version you are using.

Ask the version first, because models have knowledge cutoffs and reach for old APIs.

2D platformer (Phaser):

Build a 2D platformer in Phaser. Player runs with arrows, jumps with space,
variable jump height, coyote time, and a ground check. One screen, three platforms,
placeholder rectangles. No enemies yet. Expose jump and gravity values as variables.

Multiplayer (manage your expectations):

Build a simple real-time multiplayer prototype using [Colyseus / a managed backend].
Two players, shared state, one synced object. Do NOT sync full positions every frame;
send inputs and let the server resolve. Warn me about bandwidth before we scale past 10 players.

Real-time netcode is the one thing AI cannot reliably one-shot, so use a managed backend and expect to hand-tune it.

Prompts for assets and audio

Vibe coding writes the code, not the art. Generate assets separately, then wire them in. The pattern is the same everywhere: the AI gives you 80% in a minute, you finish the last 20%.

Wire in a generated 3D model:

I have a GLB model at /assets/ship.glb. Load it with GLTFLoader, replace the
player white-box with it, keep the existing movement and collision, and scale
it to fit. Do not change the game loop.

Generate the model itself in Meshy, which exports game-ready meshes straight into Three.js.

Wire in audio:

Add sound: a jump SFX on jump, a hit SFX on collision, and a looping background
track. Load them with the Web Audio API. Files are in /assets/audio/. Add a mute key.

Generate the background track in Mubert and any voice lines in ElevenLabs. Check the license tier before you ship, since commercial use is paid.

Bad prompt vs good prompt

The difference between a working game and spaghetti is almost always the prompt. Here is the pattern.

Bad prompt	Why it fails	Good prompt
“Make a platformer with enemies, levels, and a shop.”	Too much at once. AI returns tangled code you cannot debug.	“Build the player controller only: WASD, jump, gravity, ground check.”
“Make it fun.”	No signal. The AI cannot act on a vibe with no specifics.	“Make the jump feel floaty like Celeste. Only touch the controller.”
“Fix the bug.”	The AI guesses and often breaks more.	“Here is the exact error and a screenshot. Diagnose the cause first, then fix only that.”
“Add multiplayer.”	Hides the hardest problem in game dev behind three words.	“Add 2-player shared state with a managed backend. Sync inputs, not positions. Warn me about bandwidth.”
“Refactor everything.”	Invites the AI to rewrite working code and break it.	“Split this one file into modules. Change no behavior. List what moved.”

FAQ

Copy the master prompt at the top, open Cursor or Rosebud, and build the first mechanic before you write a second prompt.