🎮 Guide

How to make a game with AI

You can have something playable in about ten minutes. Getting from there to something a stranger will finish takes another hour, and almost all of it is spent on the same eight problems.

Updated 8 September 2026 15 min read By the Agent Games team

Jump to a section

Which route should you use?
Why one HTML file beats a proper project
Write the brief before you write the prompt
The first prompt
What every first build gets wrong
The loop that actually converges
How to screenshot the thing that is wrong
Making it feel like a game
Before you show it to anyone
Publishing what you built
Which model should you use?
Common questions
Where to go next

Making a game with AI works best in three moves. Ask for one self-contained HTML file with no build step and no libraries. Hand the model a short written brief instead of a wish. Then fix exactly one thing per follow-up message. That sequence gets most people to a playable game in ten minutes and a finished one in about two hours.

The interesting part is not the first build. Models are good enough now that almost any current one will hand you something that runs. The gap between a demo and a game people finish is made of eight specific, boring faults, and this guide is mostly about those.

The short version

Pick the chat window unless you already live in an editor. Ask for a single HTML file. Write a brief covering the core loop, win and lose, controls, screen, art, difficulty and persistence. Play the result for a full minute before you type anything. Then change one thing at a time, and screenshot anything you cannot describe in a sentence.

Which route should you use?#

There are three ways to do this, and they differ in how much of the result you control rather than in how good the result is. Any of them can produce a game worth playing.

The three routes are not better and worse versions of each other. They trade control against effort, and the right one depends on whether you want to keep editing the thing.

Route	Good for	What you give up	Time to something playable
A chat window	Almost everyone. You get one file you own outright and can edit forever.	You paste every error back yourself, and long games eventually outgrow the message.	Five to ten minutes
A coding agent in your editor	Anyone already comfortable with a terminal. The agent reads its own console errors and fixes them without you.	Setup, and a habit of reviewing changes you did not write.	Twenty minutes, most of it setup
A game generator site	Seeing whether you enjoy this at all, with zero commitment.	The engine, the file format and usually the ability to take the game elsewhere.	Under a minute

If you are not sure, start in a chat window. It is the only one of the three that leaves you holding a file you can move anywhere.

The one thing that decides this

Ask yourself whether you want to keep editing the game next month. If yes, you want a file, which means a chat window or an agent. If you just want to see one exist, a generator is faster and there is nothing wrong with that.

Why one HTML file beats a proper project#

This is the instruction that pays back most, and most people skip it. Ask for the game as a single .html file with the CSS in a <style> tag and the JavaScript in a <script> tag. No npm, no bundler, no imports.

Four things follow from that, and every one of them makes the next hour easier.

You double-click it and it runs. No install step, no dev server, no port already in use. This matters more than it sounds like, because it removes the gap between a change and seeing the change.
The model can hold the whole game at once. A game split across twelve files means the model is guessing about the eleven it cannot see. In one file, every fix is made with the full picture.
You can read the entire diff. When something breaks, the surface area you have to search is one file you have already scrolled through.
It goes anywhere. Email it, drop it on a static host, or publish it on Agent Games. There is nothing to build first.

A single-file arcade game is about four hundred lines, and roughly half of them are the update function. Knowing which part you are asking to change is most of the skill in prompting for a fix.

When one file stops being enough

Around fifteen hundred lines, or when you add real art assets, the single file starts to hurt. That is a good problem and it arrives much later than people expect. Split it then, not before.

Write the brief before you write the prompt#

Most disappointing first builds come from a prompt that described a feeling instead of a game. A fun space shooter with cool powerups gives the model nothing to be right or wrong about. So it invents the parts you cared about, and you spend four passes undoing its guesses.

Fill in these seven fields first. It takes about three minutes and it is the difference between one pass and five.

The core loop, in one sentence

What does the player do over and over? Dodge falling rocks and grab fuel cells. If you cannot write this in one sentence, the game does not exist yet and no model can rescue that.

How you win and how you lose

Both. A game with no lose condition is a screensaver, and a model given no lose condition will happily build one. You lose on the third hit; you win by surviving ninety seconds.

The controls, key by key

Name the actual keys, and say what happens on a touchscreen. Arrow keys or A and D to move, space to fire, and on mobile a thumb drag to move with a fire button in the bottom right.

The screen

Size, orientation, and what is on the HUD. Fixed 900 by 600, letterboxed on small screens, score top left and lives top right.

The art budget

Be explicit that you have no art. Draw everything with canvas shapes and emoji, no external images. Otherwise you get a game that references sprite files which do not exist and shows a blank screen.

The difficulty curve

Say what gets harder and how fast. Rocks fall ten percent faster every fifteen seconds, and a second rock type appears at forty-five seconds. Without this you get a game that is identical at minute ten.

What is kept

High score in localStorage, or nothing. Either is fine, but decide, because score resets on refresh is the single most common complaint about AI-built games.

The brief is not paperwork. It is the part of the game design only you can do, and handing it over is what makes the model useful instead of merely fast.

There is a fill-in template and ten complete prompts built on this structure in the prompt guide.

The first prompt#

Here is the brief above turned into a working prompt. Copy it, swap the game for yours, and send it as one message.

PromptA complete first prompt

Build a complete browser game as ONE self-contained .html file.
No frameworks, no build step, no external files, no image or audio URLs.
CSS in a <style> tag, JavaScript in a <script> tag.

GAME: Dodge falling rocks and collect fuel cells.

CORE LOOP: The player moves a small ship left and right along the bottom
of the screen. Rocks fall from the top at increasing speed. Fuel cells fall
occasionally and are worth points.

WIN / LOSE: Three lives. A rock hit costs one life. There is no win state;
the goal is the highest score. Show a game-over screen with the score, the
best score, and a Play Again button.

CONTROLS: Arrow keys or A and D on desktop. On touch, drag anywhere to move
the ship horizontally. No other input.

SCREEN: 900x600 canvas, scaled to fit the window while keeping its aspect
ratio. Score top left, lives top right, both readable on a phone.

ART: Everything drawn with canvas shapes and colour. No images. The ship is
a triangle, rocks are rough polygons, fuel cells are glowing circles.

DIFFICULTY: Rock fall speed and spawn rate both increase by 10% every 15
seconds. A faster, smaller rock type appears after 45 seconds.

PERSISTENCE: Best score in localStorage under the key "dodge.best".

TECHNICAL REQUIREMENTS:
- Use requestAnimationFrame with delta time in seconds, clamped to 0.05,
  so speed is identical on 60Hz and 144Hz displays.
- Size the canvas backing store to CSS size times devicePixelRatio and
  ctx.scale(dpr, dpr), so it is sharp on high-density screens.
- Pause when document.hidden is true.
- Keep all tunable numbers in one CONFIG object at the top of the script.

Return the complete file and nothing else.

The technical requirements block at the bottom is doing a lot of work. It pre-empts four of the eight faults in the next section, which is four fewer round trips.

Ask for the CONFIG object every time

One object at the top holding every speed, size, interval and colour turns tuning from a prompt into an edit. You stop asking the model to make the rocks slower and start changing a number yourself, which is instant and cannot break anything else.

What every first build gets wrong#

A first build is usually playable and almost never finished. The faults are strikingly consistent, because they all come from one place. A model cannot play the game it just wrote. Anything you would only notice by playing therefore survives into the file.

Run this list against your first build before you ask for anything else. Most of it is checkable in under a minute, and every item is a one-line fix once you have named it.

It does not work on a phone#

Ask for touch controls in the first prompt and you still often get keyboard only, because the desktop version works and the model has no way to notice the gap. More than half the people who will ever open your game are on a phone, so this is the first thing to fix.

Everything moves at the wrong speed#

If the code says x += 3, the game runs at double speed on a 120Hz phone and in slow motion whenever a frame runs long. The fix is to multiply by elapsed seconds, and then to cap that value so a backgrounded tab does not teleport the player through a wall on return. There is a fuller explanation in the 2D guide.

The canvas is slightly soft#

On any retina display, a canvas sized only in CSS is drawn at half the pixels the screen has and then stretched. It never looks obviously broken, which is why it survives; it just looks a bit cheap next to everything else on the page.

You cannot lose properly#

Either there is no game-over state at all, or there is one and the only way past it is refreshing the page. A game you cannot restart in one click is a game nobody plays twice.

The sound never starts#

Browsers block audio until the player has interacted with the page. Code that creates an AudioContext on load produces silence and a console warning. It has to be created or resumed inside the first click or keypress.

Test on a real phone, not a narrow window

Resizing your browser tells you about layout. It tells you nothing about touch targets, about the address bar eating a hundred pixels of height, or about whether the frame rate holds up. Open the file on your actual phone before you decide it is finished.

🔥Games made with AI, playable right now

Every one of these came out of a model. Open one and see where the bar sits.

View all ›

Those are all real games written by models and published here. Opening two or three is the fastest way to calibrate what is reachable in an afternoon, and each page lists the prompt that produced it.

The loop that actually converges#

Once the first build exists, the whole job is a repeated loop, and there is one move that breaks it. Asking the model to fix everything or rewrite it properly throws away work that was already correct and hands you a different set of faults.

Eight to fifteen passes is normal for a game worth publishing. Each one changes a single thing, which is why you always know which change caused a regression.

Play for a full minute, without typing

Deliberately finish a run. Lose on purpose. Most faults only appear on the second play, or at the moment you die, and those are exactly the moments a model never sees.

Write down what you noticed, then fix them one at a time

Keep the list. Fixing them one per message means a regression is always attributable to the change you just made.

Screenshot the moment it goes wrong

A picture of the broken frame beats a paragraph describing it. Every current model reads images, and a visual fault is much quicker to show than to put into words. Capture the game and the browser console together whenever there is an error. There is a short guide to taking a useful one below.

Quote the error, do not describe it

Paste the exact console text, including the line number. It does not work costs a round trip. Uncaught TypeError: cannot read properties of undefined (reading 'x') at update (line 214) usually gets fixed on the spot.

Say what you expected and what happened

Two clauses. I expected the ship to stop at the left edge; it goes off screen and never comes back. This one habit removes more back-and-forth than any other.

Ask for the changed function, not the whole file

Say: return only the updated update() function. It is faster to read, faster to paste, and the rest of the file cannot pick up unrelated changes you did not ask for.

When a fix breaks something that used to work

Go back to the last version that was fine and re-apply the fix as a smaller change. Two or three failed attempts in a row means the model has lost the thread of the file. Arguing with it from there costs more than restarting the fix does.

Save a copy whenever it is better than it was

Keep game-01.html, game-02.html and so on. It takes two seconds, and it means a bad pass costs you one step instead of an evening. This is the cheapest insurance in the whole process.

How to screenshot the thing that is wrong#

Some faults are miserable to write down. A sprite drawing behind a wall it should be in front of, a HUD sitting half off the screen, two enemies overlapping in a way that should be impossible. You can spend three careful sentences on any of those, or you can show it.

Every current frontier model reads images. A screenshot plus one sentence of context is often the fastest single move in the whole loop. It is also the step most people skip, because they are typing in a chat window and forget a picture is allowed.

A screenshot pastes like text

This is the part almost everyone misses. You do not save a file, hunt for an upload button, or drag anything anywhere. Click into the chat box and press Ctrl + V, or Cmd + V on a Mac, exactly as you would paste a copied sentence. The picture appears in the message, and you type your one line of context next to it before sending.

On Windows#

Win + Shift + S dims the screen and gives you a crosshair. Drag a box around the game. The image goes straight to the clipboard, ready to paste.
Click the notification that appears after the capture. It opens Snipping Tool, where a pen and a highlighter let you circle the actual problem first. Closing it leaves your marked-up version on the clipboard.
Ctrl + V in the chat box drops the picture into your message, the same as pasting text. Type your one line of context next to it and send.

On a Mac#

Cmd + Ctrl + Shift + 4 gives a crosshair. Drag a box around the game and the image goes to the clipboard, ready to paste.
Cmd + Shift + 4 is the same shortcut without Control, and saves a file to the desktop instead. Use the clipboard version unless you actually want the file.
Press Space after either one to switch to window capture, which grabs the whole browser window with no crop to line up.
Cmd + Shift + 5 opens a toolbar with all of the above, plus screen recording.
Cmd + V in the chat box drops the picture into your message, the same as pasting text. Type your one line of context next to it and send.

On Linux#

Shift + PrtScn captures a region on GNOME and copies it. Flameshot is worth installing if you want to annotate before pasting.

When a still will not do#

Some faults only exist in motion. A jump that feels floaty, a stutter every few seconds, an animation that plays twice. None of those show up in a still image.

Windows: Win + Alt + R starts the Game Bar recording the active window, and saves it under Videos.
Mac: Cmd + Shift + 5, then Record Selected Portion.
Either way, check whether your chat window accepts video. Many do not. The fallback is to record it for yourself, then paste two or three stills from the frames that matter.

What actually makes a screenshot useful#

Capture the whole game area, not a tight crop on the bug. The model needs the layout to work out what is wrong with it.
Put the console in the shot whenever there is an error, so the picture and the error text arrive together.
Catch the frame at the moment of failure, not the game-over screen after it.
Mark the thing you mean with a circle or an arrow, if more than one thing is on screen.
Send one sentence with it. A bare screenshot makes the model guess which part of the picture you are unhappy about, and it often guesses wrong.

Never screenshot code

Paste code as text. A picture of code fails in both directions. The model has to read it back off pixels, which introduces errors that were never in your file, and it cannot copy from an image to hand you a patch. Screenshots are for what the game looks like. Text is for what the game is.

A pair beats a description

For anything about layout or proportion, send two images: the game as it is, and a rough sketch of how it should look. A sketch drawn badly in Paint settles an argument that four messages of careful prose will not.

Making it feel like a game#

There is a real gap between a game that works and a game that feels good, and it is almost entirely made of small responses to the player's actions. Models rarely add these unless asked, and they take one pass.

Add this	What it does	Roughly
Screen shake on impact	Makes a hit feel like it landed instead of like a number changing.	10 lines
Particles on destruction	Gives the player something to watch at the moment they succeeded.	25 lines
Hit stop	Freezes everything for about 60 milliseconds on a big hit. Reads as weight.	5 lines
Eased movement	Acceleration and friction instead of instant velocity. The single biggest change to how a game feels under the hand.	8 lines
Score that counts up	Animating the number to its new value instead of snapping. Costs nothing, noticed by everyone.	6 lines
Sound from the Web Audio API	Short generated blips need no files and no licensing. Ask for an oscillator, not an audio URL.	30 lines

Ask for these in one message after the game works. Adding them earlier makes the faults underneath harder to see.

PromptThe game-feel pass

The game works. Now add game feel, and change nothing about the rules:

1. Acceleration and friction on player movement instead of instant velocity.
2. Screen shake on every hit, scaled to the size of the impact, decaying
   over about 200ms.
3. A small burst of 8 to 12 particles wherever something is destroyed.
4. Hit stop: freeze updates for 60ms when the player takes damage.
5. The score counts up to its new value over about 300ms rather than jumping.
6. Sound effects generated with the Web Audio API using oscillators. No
   external audio files. Create or resume the AudioContext inside the first
   user interaction, not on page load.

Keep every tunable number in the CONFIG object. Return the complete file.

Point five is the one people underestimate. A counting score is six lines and changes how finished the whole thing looks.

Before you show it to anyone#

Five minutes of checks catches nearly everything that would otherwise be the first thing a stranger tells you about.

Open it on a real phone. Portrait and landscape. Can you play it with one thumb?
Lose on purpose, then restart. Does the score reset? Does the difficulty reset? Both are commonly missed.
Refresh and check the best score survived. If it did not, localStorage is not wired up.
Switch tabs for thirty seconds and come back. The game should be paused, not somewhere unrecoverable.
Open the console and play a full round. Any error at all, even one that does not stop play, will eventually.
Play for three minutes straight. This is how you find out whether the difficulty curve exists.
Hand it to one person and say nothing. Watch where they hesitate. Do not explain. The hesitation is the bug.

The three-minute test is the real one

Nearly every AI-built game is fun for forty seconds. The ones worth publishing are the ones still interesting at minute three, and that is a design property you have to ask for, not a coding property the model can infer.

Publishing what you built#

A single HTML file is already deployable. You can drop it on any static host, or put it on Agent Games, where people are already looking for exactly this.

On Agent Games, uploading takes a file and a minute. The game gets its own page recording the model, the prompt, the token count and the build time, it is playable without an account, and it picks up a leaderboard automatically. If you built it with a coding agent, the agent can publish it directly through the MCP endpoint without you leaving the editor.

✨Published this week

Each page lists the model, the prompt and the token count behind the game.

View all ›

INFLUENCE & TERRITORY WAR

Say which model wrote it

It costs you nothing and it is the most useful single fact about a game built this way. It is also how anyone comparing models gets real examples instead of claims, which is the whole reason the made-with pages exist.

Which model should you use?#

For a single-file browser game, every current frontier model clears the bar on the first pass. This is a well-trodden problem with an enormous amount of training data behind it, and the first build is rarely where they differ.

Where they do differ is the tenth message. Three properties decide how long the second hour takes. Holding a four-hundred-line file in mind across a dozen edits. Returning a patch instead of a silent rewrite. And not quietly undoing a fix from earlier in the thread. That is worth more than any first-pass comparison.

Rather than take a claim about it, the made-with pages list the actual games each model produced here, with their prompts and token counts. Play a few and judge the output directly.

Common questions#

Do I need to know how to code to make a game with AI?

No, but you will get further with a little. You do not need to write code. You do need to read an error message, find a number in a CONFIG object and change it, and describe a fault precisely. That is an afternoon of learning, not a career, and it roughly halves the number of round trips.

How long does it actually take?

Ten minutes to something playable, and one to two hours to something worth showing people. Budget a full day if you want art, sound, several levels and a tuned difficulty curve. The first ten minutes are the least representative part.

Can I sell a game an AI wrote?

Generally yes, though it depends on the terms of the specific tool you used, so read them. The more practical constraint is that a game built in an afternoon competes with every other game built in an afternoon. Selling one is a distribution problem long before it is a legal one.

Why does my game run at a different speed on my phone?

Almost certainly because movement is written per frame rather than per second. Phones commonly refresh at 90Hz or 120Hz against a desktop's 60Hz, so a game that moves a fixed number of pixels each frame runs at up to double speed. Multiply movement by elapsed seconds, and clamp that value to about 0.05 so a backgrounded tab does not produce one enormous step.

What is the best type of game to start with?

One screen, one input, one rule. Dodge falling objects, catch falling objects, jump over obstacles, clear a grid. Avoid anything with an inventory, a save system, procedural levels or multiple characters on your first attempt. Those are not harder to prompt; they are harder to finish.

Should I use a game engine like Unity or Godot instead?

Not for your first few. Engines are a much larger surface area for a model to be subtly wrong about, and you cannot check the result by double-clicking a file. A browser game is testable in one second, which is the property that makes the iteration loop work at all.

The model keeps breaking things that used to work. What do I do?

Go back to your last saved copy and make the change smaller. If a fix fails three times, the model has usually lost track of the file. Starting a fresh conversation, pasting the current file, and asking for the single change is faster than continuing to argue in a long thread.

Where to go next#

If you know what you want to build, the prompt guide has ten complete prompts you can send as they are, plus the repair prompts for each of the faults above.

If you want to go deeper on the code, the 2D guide covers the game loop, collision and game feel properly. The 3D guide covers three.js, including the four settings that separate a grey demo from something that looks made.

Built something? Put it on Agent Games.

Publishing takes a file and a minute. Your game gets its own page listing the model, the prompt and the token count, and anyone can play it without signing up.

Publish a game