DEV Community: HTML5 Games Studio

Why your falling-blocks game feels unfair (and three small fixes)

HTML5 Games Studio — Fri, 13 Nov 2026 15:41:29 +0000

You can build a falling-blocks game that follows every rule and still have players call it unfair within a minute. The pieces fall, rows clear, the score goes up, but something feels off. They get five S pieces in a row. The long bar refuses to turn next to the wall. A piece freezes the instant it touches down, before they can slide it into the gap.

None of those are bugs. They're missing systems, and each one is only a few lines. I added all three to Block Drop, a falling-blocks game in a single HTML file of plain JavaScript and Canvas. Here's what they are and the code for each.

Fix 1: a shuffled bag instead of pure randomness

The obvious way to pick the next piece:

const types = ["I", "O", "T", "S", "Z", "J", "L"];
const next = types[Math.floor(Math.random() * types.length)];

Each piece has a 1-in-7 chance every time, which sounds fair. But true randomness clumps. Players will see the same piece three or four times in a row, and long droughts with no I piece. Over a session someone always hits a 30-piece drought and blames the game.

The fix is to deal from a bag: put all seven pieces in, shuffle, hand them out one at a time, and refill when it's empty.

let bag = [];

function takeFromBag() {
  if (!bag.length) {
    bag = Object.keys(SHAPES);                       // all seven pieces
    for (let i = bag.length - 1; i > 0; i--) {      // Fisher-Yates shuffle
      const j = Math.floor(Math.random() * (i + 1));
      [bag[i], bag[j]] = [bag[j], bag[i]];
    }
  }
  return bag.pop();
}

The order is still unpredictable, but every piece now shows up once per seven. The worst possible wait for any shape is 12 pieces: one at the very start of a bag, the next at the very end of the following one. Players stop noticing the randomiser at all, which is the goal.

Use a proper Fisher-Yates loop like the one above. The popular one-liner array.sort(() => Math.random() - 0.5) is biased: some orders come up noticeably more often than others.

Fix 2: wall kicks, so turning near a wall works

Rotation itself is easy if each piece is a small square grid of 1s and 0s. Turning it is just reading the grid in a different order:

function rotate(cells, dir) {
  const n = cells.length;
  return cells.map((row, y) => row.map((_, x) =>
    dir > 0 ? cells[n - 1 - x][y] : cells[x][n - 1 - y]));
}

The problem shows up at the edges. Push the long I piece against the left wall and turn it: the rotated shape sticks out past the wall, the collision check says no, and the turn is refused. To the player it looks like the game ignored them.

A wall kick says: if the turned piece doesn't fit where it is, try nudging it a little before giving up.

function tryRotate(dir) {
  const turned = rotate(piece.cells, dir);
  const kicks = [[0, 0], [-1, 0], [1, 0], [0, -1], [-2, 0], [2, 0]];
  for (const [kx, ky] of kicks) {
    if (!collides(turned, piece.x + kx, piece.y + ky)) {
      piece.cells = turned;
      piece.x += kx;
      piece.y += ky;
      return;
    }
  }
  // nothing fit: the turn is refused, which is now rare
}

The first entry, [0, 0], is "no nudge", so normal turns are unchanged. After that it tries one cell left, one right, one up, then two cells sideways for the long piece. The first position that fits wins.

This only works because there's a single collides(cells, x, y) function that answers "would this shape fit here?" for everything: moving, turning, gravity and the drop preview all ask it. With that in place, wall kicks are a loop over a list.

(Modern versions of the classic use a bigger kick table per piece and per rotation. The short list above covers the cases players actually hit, and it's easy to read.)

Fix 3: lock delay, so landing isn't instant death

The simplest landing rule: when the piece can't move down any more, freeze it into the board. It's correct, and it feels terrible. At higher speeds the piece touches down and locks in the same frame, and the player never gets to slide it under an overhang.

Lock delay gives a grace period. When the piece is resting on something, start a short timer instead of locking. Lock only when the timer runs out:

const LOCK_DELAY = 0.5;      // seconds of grace after touching down
const MAX_RESETS = 15;       // per row reached, to stop infinite stalling

function update(dt) {
  if (grounded()) {
    lockTimer += dt;
    if (lockTimer >= LOCK_DELAY) lock();
    return;
  }
  // ...normal gravity...
}

// Called after every successful move or turn
function moved() {
  if (grounded() && resets < MAX_RESETS) {
    lockTimer = 0;
    resets++;
  }
}

Every successful slide or turn while grounded restarts the half second, so the player can tuck a piece into place. The reset cap matters: without it, someone can spin a piece forever and never let the game advance. Block Drop allows 15 resets, and gives a fresh 15 only when the piece reaches a new lowest row, which is plenty for real play.

dt here is the time since the last frame in seconds, so the grace period is the same on a 60 Hz laptop and a 120 Hz phone. Counting frames instead would make the game twice as harsh on slower screens.

Bonus: the ghost piece is free

Once collides() exists, showing where the piece will land costs one small loop:

function dropDistance() {
  let d = 0;
  while (!collides(piece.cells, piece.x, piece.y + d + 1)) d++;
  return d;
}

Draw a faint copy of the piece dropDistance() rows down and players stop misjudging drops.

The full game

With a bag, wall kicks and lock delay, a falling-blocks game goes from technically working to feeling fair. Block Drop also has levels, line-clear scoring, held-key repeat and touch gestures, all in about 350 lines. You can play it and copy the MIT-licensed code from the falling-blocks game tutorial, which walks through the rest of the file.

And if you're making your own: give it its own name. "Tetris" is a trademark, which is why ours is called Block Drop.

Which of the three would you notice first if it were missing?

Why your canvas ball goes through bricks (and the two fixes that stop it)

HTML5 Games Studio — Fri, 13 Nov 2026 08:52:14 +0000

Every first brick breaker has the same two bugs. Sooner or later the ball goes straight through a brick, or through the paddle, as if it wasn't there. And when it does hit a brick near a corner, it bounces off in a direction that feels wrong.

Both come from how the ball moves. On screen it looks continuous, but in code it jumps from one position to the next, once per frame. Collisions are only checked at those positions, never in between.

I ran into both while building Brick Burst, a small Breakout-style game in a single HTML file with no library. Here are the two fixes, with the code.

Bug 1: the ball tunnels through thin objects

The usual first loop moves the ball by velocity × frameTime once per requestAnimationFrame:

function frame(now) {
  const dt = (now - last) / 1000;
  last = now;
  ball.x += ball.vx * dt;
  ball.y += ball.vy * dt;
  checkCollisions();
  draw();
  requestAnimationFrame(frame);
}

At 60 frames a second and 600 pixels a second, the ball moves 10 pixels per frame. If a brick is 20 pixels tall, that's fine. But frames aren't always 1/60 of a second. A slow frame, a background tab or a garbage-collection pause can make one dt five times longer, and then the ball moves 50 pixels in one jump. It can be above the paddle in one frame and below it in the next, without ever overlapping it.

Fix: fixed physics steps, sized to the ball

Separate the physics from the frame rate. Keep an accumulator of elapsed time and run the physics in small fixed steps until it's used up:

const STEP = 1 / 120;   // 120 physics steps a second
let acc = 0, last = performance.now();

function frame(now) {
  acc += Math.min((now - last) / 1000, 0.25);   // cap long pauses
  last = now;
  while (acc >= STEP) {
    update(STEP);
    acc -= STEP;
  }
  draw();
  requestAnimationFrame(frame);
}

Now the ball always moves by the same small amount per step, however uneven the frames are. The cap on acc stops a tab that was hidden for a minute from running thousands of steps when it comes back.

The step size isn't arbitrary. Here's the rule that makes simple overlap tests safe:

If the ball can't move further than its own radius in one step, it can't skip over anything thicker than its radius.

In Brick Burst the top speed is 620 units a second. At 120 steps a second that's 5.2 units per step, less than the ball's 7-unit radius. Bricks are 20 units tall and the paddle is 12, so the ball always overlaps them for at least one step on the way through. If you raise the top speed a lot, raise the step rate with it. Past a certain speed you need a swept test, a ray cast along the ball's path, but most casual games never get there.

Bug 2: the ball bounces off the wrong side of a brick

The tempting brick test checks the ball's bounding box against the brick and flips vy on a hit:

if (overlaps(ball, brick)) {
  ball.vy = -ball.vy;
  brick.hp--;
}

That works when the ball hits a brick from below. When it clips the side of a brick, it should bounce sideways, but this code sends it back down, which looks broken. There are two smaller problems too: a box test counts corner hits that a round ball would miss, and flipping the sign can leave the ball stuck inside a brick, flipping back and forth every step.

Fix: circle against rectangle, then pick the shallow side

First, a proper circle-versus-rectangle test. Clamp the ball's centre to the brick's edges to find the nearest point on the brick, then compare the distance to that point with the radius. Comparing squared distances saves a square root:

const clamp = (v, lo, hi) => Math.max(lo, Math.min(hi, v));

function circleHitsRect(ball, b) {
  const nx = clamp(ball.x, b.x, b.x + b.w);
  const ny = clamp(ball.y, b.y, b.y + b.h);
  const dx = ball.x - nx, dy = ball.y - ny;
  return dx * dx + dy * dy <= ball.r * ball.r;
}

Second, decide which side was hit by how deep the ball went in on each axis. If it's only a little inside horizontally but deep vertically, it came in from the left or right. Otherwise it came from the top or bottom:

function bounceOffBrick(ball, b) {
  const cx = b.x + b.w / 2, cy = b.y + b.h / 2;
  const overlapX = ball.r + b.w / 2 - Math.abs(ball.x - cx);
  const overlapY = ball.r + b.h / 2 - Math.abs(ball.y - cy);
  if (overlapX < overlapY) {
    ball.vx = ball.x < cx ? -Math.abs(ball.vx) : Math.abs(ball.vx);
  } else {
    ball.vy = ball.y < cy ? -Math.abs(ball.vy) : Math.abs(ball.vy);
  }
}

Notice that this sets the sign instead of flipping it. "Move away from the brick's centre" stays true even if the ball is still overlapping on the next step, so it can't get stuck. The same trick works for walls:

if (ball.x < ball.r) { ball.x = ball.r; ball.vx = Math.abs(ball.vx); }
if (ball.x > W - ball.r) { ball.x = W - ball.r; ball.vx = -Math.abs(ball.vx); }

One more detail: stop after the first brick you hit in a step. A ball that touches two bricks at once would otherwise bounce twice, cancel itself out and carry on through both.

for (const b of bricks) {
  if (!b.hp || !circleHitsRect(ball, b)) continue;
  bounceOffBrick(ball, b);
  b.hp--;
  break;
}

Bonus: aim from the paddle instead of mirroring

A paddle that just flips vy gives the player no control. Throw the ball at an angle that depends on where it lands: straight up from the centre, up to 60 degrees from the ends:

const MAX_ANGLE = 60 * Math.PI / 180;
const offset = (ball.x - paddleX) / (PADDLE_W / 2 + ball.r);   // -1 … 1
if (ball.vy > 0 && Math.abs(offset) <= 1 && touchingPaddle(ball)) {
  const angle = offset * MAX_ANGLE;
  ball.vx = Math.sin(angle) * ball.speed;
  ball.vy = -Math.cos(angle) * ball.speed;
}

Capping the angle at 60 degrees means the ball always climbs at least half its speed upwards, so it can never end up skimming sideways forever.

The full game

With fixed steps, a circle test and "set, don't flip" bounces, a brick breaker needs no physics engine at all. The complete game is about 250 lines in one file: responsive canvas scaling, touch and mouse controls, levels, lives and two-hit bricks. You can play it and copy the MIT-licensed code from our Breakout HTML5 code tutorial, which walks through the rest of the file.

If you want more of these, the same collection of free HTML game code has Pong, Snake, Tetris, 2048 and about twenty other classics, each as a single file you can open in a browser.

What was the first collision bug that got you? I'd like to hear it in the comments.