Understanding Brick Breaker Physics

Brick breakers do not simulate physics. They approximate a small, carefully chosen subset of it and deliberately break the rest, and the places where they break it are exactly the places that make the game good.

This article explains what is actually being calculated: how the ball moves, how collisions are detected and resolved, why corner hits look wrong, what tunnelling is and how it is prevented, and why the paddle is allowed to violate the laws of reflection. It is written for players who want to understand the system, not only for developers - though developers will find the implementation notes useful too.

The ball is a vector, not an object

The ball has a position (x, y) and a velocity (vx, vy). Every frame, the game adds the velocity - scaled by elapsed time - to the position. There is no mass, no momentum transfer and, in nearly all brick breakers, no gravity.

The magnitude of that velocity vector is the ball's speed, and it is treated as a separate quantity from direction. When a game 'changes the angle', it recalculates vx and vy from the new angle while keeping the magnitude fixed. This is why a shallow angle is not faster than a steep one, even though it crosses the screen more quickly - the distance travelled per second is identical, it is just distributed differently between the two axes.

Scaling by elapsed time rather than by frame count matters. If a game adds a fixed amount per frame, the ball travels twice as fast on a 120Hz display as on a 60Hz one. Time-scaled movement makes behaviour identical on any hardware, which is why the engine on this site does it that way.

Reflection off walls and bricks

Wall and brick collisions are genuine reflections, and they are simple because every surface is axis-aligned:

• Hit a horizontal surface (brick top or bottom, ceiling) → negate vy, keep vx.
• Hit a vertical surface (brick side, left or right wall) → negate vx, keep vy.

The angle of incidence equals the angle of reflection, which is genuinely physical and genuinely predictable. This is why bank shots off side walls can be planned geometrically, as described in how to control ball angles.

The hard part: which side did it hit?

Detecting that a circle overlaps a rectangle is easy. Determining which face it entered through is not, because by the time you test, the ball is already inside.

The standard solution is resolution by axis of least penetration. Compute how far the ball has entered the brick on each axis, then reflect on whichever axis has the smaller overlap, and push the ball back out by that amount.

The reasoning is that the ball must have entered through the face it is least deeply past. It is fast, requires no history, and is correct in the overwhelming majority of cases.

It fails in one situation, and that failure is the source of nearly every complaint about 'wrong' bounces.

Corner cases, literally

When the ball strikes almost exactly at a brick's corner, the horizontal and vertical penetration depths are nearly equal. A difference of a fraction of a pixel decides whether the game flips vx or vy - and those two outcomes send the ball in completely different directions.

This is not a bug and it is not randomness. It is a genuinely ambiguous geometric situation being resolved by a deterministic rule that happens to be very sensitive right at the boundary. The same approach shot repeated exactly would produce the same result every time.

More sophisticated engines use swept collision - solving for the exact time of impact along the ball's path rather than testing for overlap after the fact - which resolves corners correctly. It costs more computation and, for a brick breaker, most developers judge the trade not to be worth it. The practical player advice is simply: expect corner-adjacent contacts to be unpredictable, and do not build a plan that depends on one.

Tunnelling and sub-stepping

A ball travelling at 700 pixels per second moves about 11.7 pixels in a single frame at 60fps. A brick is often 20 pixels tall. That is fine. But if the ball reaches 1,400 pixels per second, or the frame rate drops to 30fps because the device is busy, it moves over 23 pixels - further than the brick is thick. The overlap test runs before and after the brick, never during, and the ball passes straight through.

That is tunnelling, and it is why some browser brick breakers occasionally let a fast ball escape through the floor or clip a brick.

The fix used in our engine is sub-stepping: break each frame's movement into steps no larger than a few pixels and run the full collision check after each step. A frame in which the ball should move 23 pixels becomes five checks of under 5 pixels each. The cost is a handful of extra tests per frame; the benefit is that collisions remain correct at any speed and any frame rate.

Why paddle collisions break physics deliberately

If the paddle were a physically correct surface, a ball arriving at 30 degrees from the left would leave at 30 degrees to the right, every time, regardless of where it landed. You would have no influence over direction at all, and the game would consist entirely of moving the paddle under the ball.

So brick breakers cheat. The paddle discards the incoming angle and assigns a new one from the contact point: centre for vertical, edges for shallow. This single unphysical rule is what makes the genre a game of aim rather than a game of chase.

Most implementations also add a small horizontal contribution from paddle movement. That one is actually a nod towards realism - a moving surface imparting tangential velocity - but it is applied as a tuned constant rather than a simulated friction model.

Two guard rails are usually applied on top. A minimum vertical velocity prevents the ball from becoming perfectly horizontal and bouncing between the side walls forever. A maximum speed prevents acceleration rules from producing a ball nobody can track.

Why the ball seems to speed up when it has not

Players regularly report that the ball got faster at a moment when, in the code, nothing changed. Four separate effects produce that impression, and distinguishing them is genuinely useful.

The angle got shallower. This is the big one. Speed is the magnitude of the velocity vector and does not change with direction, but a shallow ball crosses the screen horizontally much faster because more of its speed is in the horizontal component. It feels quicker because it is covering the width of the playfield in less time - and because you have less warning before it reaches a wall.

The wall thinned out. With fewer bricks, the ball spends more time travelling and less time rebounding. Longer, uninterrupted trajectories read as faster even at identical speed, and the return is less predictable because it has not been shaped by a brick on the way.

You were out of position. Perceived ball speed is really perceived time pressure, and time pressure is mostly a function of how far you have to travel. A player at the centre and a player at the edge experience the same ball very differently.

It actually did speed up. Some games raise the ball speed on every paddle return or at every level. Where that applies, the increase is real and cumulative, and it does not reset when you lose a life - which is why a run that has already gone on a long time feels harder than the same level did at the start.

Telling these apart matters because the corrections differ. A shallow angle is fixed by taking a centre contact. Being out of position is fixed by moving earlier. Genuine acceleration is managed by reducing paddle returns, which means keeping the ball in the brick field or above it.

Frame rate, input lag and what you actually feel

A brick breaker is a game about timing, so the path from your hand to the screen matters. Three things sit in that path.

Simulation rate. With time-scaled movement, the ball travels the same distance per second regardless of frame rate. A drop from 60 to 30 frames per second does not make the game faster - but it does halve how often the position is updated, which makes motion look steppier and makes fine paddle adjustments feel coarse. The physics stays correct; the feedback gets worse.

Collision resolution. Sub-stepping means correctness does not degrade at low frame rates, which is why a struggling phone will look choppy but will not let the ball through a brick. Games without sub-stepping fail in exactly the opposite way: they look fine and behave wrongly.

Input latency. This is where the real differences between control methods live. A mouse position is read on the same frame it changes. A touch drag carries the operating system's own touch processing delay on top, typically small but not zero. On-screen buttons add a further step because a press has to be recognised as a press before it becomes movement. None of these are large, and all of them are noticeable when the ball is fast.

The practical takeaway is not to chase hardware. It is that if the game feels unresponsive, closing other tabs is usually more effective than any change to how you play - and that if you are choosing an input for a serious high-score attempt, a mouse has the shortest and most consistent path of the four.

What brick breakers deliberately leave out

• Gravity. A brick breaker ball travels in straight lines. Adding gravity turns it into a different game - closer to pinball - because it destroys the predictability the aiming system depends on.
• Spin. Real ball spin would curve trajectories. Almost no brick breaker implements it, because a curved path is very hard to aim.
• Energy loss. The ball never slows from bouncing. Speed changes only through explicit game rules such as acceleration or capsules.
• Mass and momentum. The ball does not push bricks, and bricks do not resist. Contact is binary: the brick takes a hit, the ball reflects.

Games that add these become interesting for different reasons - physics-led brick breakers are a genuine sub-genre - but they trade away the precision that makes the classic formula work.

What this means for you as a player

1. Wall and brick rebounds are predictable. Learn to read them; they never lie.
2. Corner contacts are not predictable. Never build a plan that depends on one.
3. Paddle contacts are fully under your control. The contact point is the only thing that matters.
4. Speed and direction are separate. A shallow ball is not faster; it simply gives you less time before it reaches a wall.
5. The ball never slows down by itself. Any speed reduction has to come from a capsule or a game rule.

If you want to see all of this working in code, the HTML5 design article walks through the implementation used by every game on this site.

Conclusion

The physics of a brick breaker is a set of deliberate choices rather than a simulation. Reflection where predictability helps, a fabricated rule at the paddle where player agency matters, and guard rails to prevent degenerate states.

Understanding which parts are honest and which are invented tells you exactly where you can plan and where you should not.