How to make a breakout game with AI
A brick breaking game is one ball and one decision: what the paddle does to the angle. Reflect like a mirror and the player is a spectator.
Jump to a section
Ask for bricks, a paddle and a ball, then specify how the paddle changes the angle. Where the ball struck, measured out from the paddle's centre, should decide the direction it leaves in. Say that in the prompt and the game has a skill in it. Leave it out and the ball does whatever it likes.
The obvious bounce is to flip the vertical speed and keep the horizontal speed. It is correct physics and it is a bad game. The ball returns on a fixed path, so moving the paddle only decides whether you survive, never where the ball goes. Worse, that path can settle into something almost level and stay there.
Four steps to a bounce you can aim#
Bricks, paddle, ball, lives and the angle rule all come in the first pass. The layout is the easy half.
It should fly off steeply sideways. If it comes back the way it arrived, the angle is still a mirror and nothing else matters yet.
Pick a brick, then aim at it with the paddle. Being able to miss on purpose is what tells you the control exists.
This is the part that goes wrong. If the ball crawls across the screen or the hunt drags, you need the guard and the ramp below.
Build a brick breaking game as ONE self-contained .html file. No
frameworks, no images, no audio files.
LAYOUT: a canvas holding a grid of coloured bricks across the top, solid
walls on the left, right and top, a paddle near the bottom and one ball.
The bottom edge is open, and letting the ball past costs a life.
PADDLE: follows the mouse and also the left and right arrow keys, kept
inside the walls. Draw a faint line down its centre while testing,
because that centre is the thing the player has to learn.
BOUNCE ANGLE. Treat this section as the point of the build. Do not just
negate the vertical speed when the ball meets the paddle. Work out how
far from the paddle's centre the ball landed, as a number running from
minus one at the left end to plus one at the right end. Multiply that
number by MAX_ANGLE to get an exit angle measured away from straight up.
Rebuild the velocity from that angle at the ball's current speed, always
pointing upwards. A hit on the centre leaves close to vertical. A hit on
either end leaves steeply sideways.
FLAT BALL GUARD: after every bounce of any kind, if the vertical part of
the velocity is smaller than MIN_VY, raise it to MIN_VY, keep its sign,
and reduce the horizontal part so the total speed is unchanged. The ball
must never travel almost level across the screen.
WALLS AND BRICKS: these reflect normally, on whichever axis was crossed.
Work out which side of a brick was hit from the overlap, so a ball
arriving from below does not reverse sideways. Destroying a brick scores
points, and clearing the grid wins the game.
SPEED RAMP: add SPEEDUP to the ball's speed on every brick destroyed, up
to MAX_SPEED. Put the speed back to BALL_SPEED when a life is lost.
PHONE: dragging anywhere on the canvas moves the paddle, with its centre
tracking the finger. Include canvas { touch-action: none; } in the
CSS so a drag cannot scroll the page.
TIMING: work out the seconds elapsed since the previous frame, limit
that figure to 0.05, and multiply every movement by it.
CONFIG: one object at the top of the script holding BALL_SPEED,
MAX_SPEED, SPEEDUP, MAX_ANGLE, MIN_VY, PADDLE_WIDTH, BRICK_ROWS and
LIVES, each with a one line comment. Begin with MAX_ANGLE at 60 degrees
and MIN_VY at a quarter of BALL_SPEED.MAX_ANGLE, SPEEDUP and PADDLE_WIDTH are the dials worth playing with, and MAX_ANGLE changes the game most. Keep the flat ball guard applied after every bounce rather than only at launch, because that is where a stalled run comes from. MIN_VY wants to stay a fraction of the speed, not a fixed number, or the ramp outgrows it.
The paddle is a dial, not a mirror#
Here is the whole mechanic. Take the ball's horizontal position, subtract the paddle's centre, and divide by half the paddle width. You now have a number between minus one and plus one describing where the hit landed. Turn that into an angle away from vertical and send the ball out along it.
Notice what this changes about the game. A player who wants the ball to go left moves the paddle so the ball lands on its left end. Clearing a stubborn column stops being luck. The paddle is doing two jobs at once, catching and aiming, and that overlap is what makes the genre worth playing.
Rebuild the velocity from the angle rather than nudging the horizontal part. Nudging keeps whatever direction the ball already had, so the offset becomes a small correction instead of the control. Build the vector fresh from the angle and the current speed, and the paddle's answer is the same every time.
Sixty degrees from vertical is a sensible place to start for the maximum. That is a starting point rather than a right answer. Lower feels safe and makes the far columns awkward to reach. Much higher sends the ball nearly sideways off the ends, which is exciting once and then annoying.
| Where it hits | Where it leaves | What the player learns |
|---|---|---|
| Dead centre | Close to straight up | A safe return that aims at nothing |
| Halfway out | Leaning clearly to that side | Reaching the columns either side |
| Near the end | Steeply sideways, at the cap | Aiming at a far corner on purpose |
| Past the end | No hit at all | The paddle has edges, and they count |
This is the only lesson the game has to teach, and it teaches itself in about four bounces if the centre line is visible.
The ball that gets stuck travelling flat#
A ball with a very small vertical speed drifts across the screen, hits a side wall, comes back, and takes an age to reach anything. Nothing is broken and the run is over, because the player is sitting still waiting. On a mirror bounce the ball can enter that state and never leave it.
The guard is short. After any bounce, compare the vertical speed against a floor value. If it is below, raise it to the floor and keep its direction. Then reduce the horizontal part so the total speed has not changed, or the ball quietly gains pace every time the guard fires.
- Apply it on every bounce. Walls and bricks can flatten the path just as a paddle can. A guard that only runs at launch misses the case that actually happens.
- Make the floor a fraction of the speed. A quarter of the current speed scales with the ramp. A fixed number stops mattering as soon as the ball is quick.
- Cap the angle too. The guard is the backstop. The angle cap is what stops the ball getting near flat in the first place.
- Leave the horizontal direction alone. The guard should change how steep the path is, never which way across the screen it is going.
Why a ball that speeds up saves the ending#
The start of a run is dense. Almost any return hits something, and bricks come down in handfuls. The end is the opposite. Two bricks remain in the corners and every bounce is a long trip across an empty board. The design problem is the same ball doing both jobs.
Add a small rise to the ball's speed on every brick destroyed. Early on the rise is swamped by how much there is to hit, so nobody notices. By the final bricks the ball is moving quickly, the trips are short, and a miss is a real risk. The ending tightens on its own.
Keep the rise small and give it a ceiling. Too steep and the middle of a run turns unplayable. With no ceiling the last brick arrives faster than anybody can track. Dropping back to the starting speed when a life is lost is also worth asking for, since inheriting the fast ball punishes the mistake twice.
Bricks, lives and what to leave out#
The rest of the build is quick, and the temptation is to spend your effort there. Power ups, multiple balls and brick types are all easier to write than the angle rule, and none of them helps if the bounce is still a mirror.
- Work out which side of a brick was hit. Compare the overlap on each axis and reverse the smaller one. Without this, a ball arriving from below sometimes reverses sideways and the path looks random.
- Keep the brick grid in an array. Rows, columns and colours as data near the top of the file. Changing a layout then means editing numbers rather than drawing code.
- Shrink the paddle before raising the speed. A narrower paddle raises difficulty and keeps the aiming intact. More speed eventually removes the aiming altogether.
- Three lives, and a ball you launch. Serving the ball from the paddle with a key press beats dropping it the instant a life starts.
- Leave power ups until last. A falling capsule that widens the paddle is fun, and it is also a second collision system to get wrong.
🧱Brick breaking games written by AI
Sonnet 5Common questions#
How do I control where the ball goes off the paddle?
Derive the exit angle from the hit position. Subtract the paddle centre from the ball's position, divide by half the paddle width, and multiply the result by a maximum angle. Rebuild the velocity from that angle at the ball's current speed, pointing upwards.
Why does my ball bounce the same way no matter where it lands?
The paddle is reflecting like a mirror, which usually means a single line negating the vertical speed. That is correct physics and a dull game. The paddle has to read the hit position and set the angle from it, so the player has something to aim with.
Why does the ball get stuck going almost sideways?
Its vertical speed has fallen close to nothing, so it crosses the screen and bounces between the side walls. Add a floor to the vertical speed, re-applied after every bounce, and take the difference out of the horizontal part so the overall speed holds.
What should the maximum bounce angle be?
Around sixty degrees from vertical is a reasonable start, not a correct value. Lower makes the outer columns hard to reach. Much higher sends the ball nearly level off the paddle ends, which is where the flat ball guard starts earning its place.
Should the ball get faster as bricks are destroyed?
Yes, by a small amount per brick with a ceiling on it. Early in a run the rise is hidden by how much there is to hit. By the final bricks it keeps the pace up, so a nearly empty board stays tense rather than becoming a wait.
Why does the ball sometimes pass through a brick?
It is moving further in one update than a brick is tall, so the overlap test never catches it. Keep the speed ceiling sensible, make bricks reasonably chunky, and if it persists, advance the ball in smaller slices within a frame.
Where to go next#
When you can pick a brick and hit it, the game is finished enough to share. Put it up and it gets a page recording the model and the prompt behind it. The brick breaking builds here are a short list, which makes a good one easy to notice.
The general method sits in how to make a game with AI. The ball passing through a brick is the same fault covered properly in the physics guide. Another arcade genre where one rule decides fairness is in the snake guide, and pasteable fixes are in the prompt guide.
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.
Read next