A vibe coded game is usually a game made by telling an AI coding assistant what you want, running its output, and describing what should change next. You might ask for a moon that dodges asteroids, a memory grid, or a snake controlled by swipes. The assistant writes code; you decide whether the result behaves like the game you imagined.
The phrase does not describe a genre. A typing game and a puzzle can both be vibe coded. It also does not mean that AI draws every picture, invents every rule, or runs while you play. A browser game can be ordinary JavaScript that works without any AI service after it has been built.
Where the term came from
The phrase spread after a February 2025 post about vibe coding. It described an informal way of making software through requests and feedback, sometimes without closely reading the resulting code. That narrow meaning helps explain both the appeal and the risk: you can get a prototype moving before you understand its internals.
People now use the label more broadly for games made with substantial AI coding help. That can include careful work by someone who reads every change. Here, the useful question is what happened during the build. Which tool was used? What was the starting prompt? What needed fixing? The label alone cannot answer those questions.
Start with a small, testable rule
Choose one action the player repeats. Hold to climb and release to fall is enough for a first flying game. Write down the goal, what causes failure, and how a run restarts. Leave out online accounts, purchases, multiplayer, and a large story. Each extra system creates more ways for an apparently working prototype to fail.
A useful opening prompt names the screen, controls, scoring, and constraints. For example: make a single HTML browser game where a basket follows the pointer, green tokens add points, red blocks remove lives, and losing three lives shows a restart button. Ask for touch support explicitly. A phone cannot hover a mouse or press an arrow key.
Build, play, and report one problem
First, save the generated files in their own folder. Open the game through a local web server if it uses separate scripts or assets. Keep a copy of the first working version before requesting changes. A later reply can accidentally remove controls, change scoring, or leave a file reference pointing at something that does not exist.
Next, play a complete run. Do not stop at a moving title screen. Check that you can start, score, lose, and restart. Try holding a control, tapping quickly, resizing the window, and switching tabs. Record the exact sequence that fails. A report such as "after restarting twice, two tokens spawn at once" gives the assistant more to work with than "it feels broken".
Ask for one repair at a time and retest the same sequence afterward. If a fix breaks something else, return to the saved version and narrow the request. Once the basic loop works, tune speed, spacing, and feedback. Clear information about why you lost often matters more than another background effect.
Common limits and failure modes
Generated code can look plausible while handling time badly. A game may move faster on a screen with a higher refresh rate, or jump forward after a background tab wakes up. Collision boxes can disagree with the art. Restarting can create a second animation loop. A best-score feature can crash when browser storage is unavailable.
Touch input brings its own problems. Swiping might scroll the page instead of steering, buttons may be too close together, or the game may keep treating a finger as held after it leaves the screen. Test on an actual phone when possible. A narrow desktop window tells you about layout but cannot fully reproduce a touch device.
There are also design failures that do not produce console errors. A random obstacle can make a run impossible. A memory game can punish the player before explaining its rule. An idle game can reach a point where the next purchase takes hours. These need judgment and playtesting, not just a request to remove bugs.
How to judge a finished game
Look for a clear first action, visible feedback, and a fair explanation of failure. Can you tell which objects help you? Does the restart work without reloading the page? Can you read instructions on a phone? Can you use a keyboard where one is promised? Good games make those answers easy to find.
Check the surrounding site too. A small browser experiment should not require a surprise download or unrelated account. Creator credit and a source link help you understand where it came from, but they are not security certificates. Leave a site that asks for information you do not expect. Treat a tool badge as a build detail rather than a trust score.
Choosing a tool and keeping useful notes
This directory groups games by Claude, ChatGPT, Gemini, Grok, Cursor, and Codex when the maker records that credit. The important distinction for a first project is workflow: will you copy code from a conversation, or work with an assistant inside a folder of files? Choose a setup where you can inspect changes, keep working versions, and understand how to run the result.
Keep the opening prompt alongside a short change log. Record what you asked to repair, what actually changed, and what you tested. If two tools helped, say what each did. Do not invent an iteration count after the fact. Honest gaps in the record are more useful than a tidy story that suggests the first response was perfect.
Your first experiment
Pick a mechanic you can explain in one sentence, set a short time limit for the first build, and aim for one complete playable loop. Ask someone else to try it without coaching. Watch where they hesitate, then fix that moment before adding more features. Publish the prompt and the limitations with the game.
For concrete starting points, play Token Catcher and read its catch-and-dodge prompt, or try Context Window for a memory rule with a twist. Then browse all 10 originals and compare the written ideas with what you can actually play.