MiniMax M3.1 Flash

Let me build a polished Breakout game in a single HTML file.

Key features:
- Canvas, paddle controlled by mouse + arrow keys
- Bounce angle depends on hit position on paddle
- 8 rows of bricks, some tough (2 hits) that crack after first hit
- Power-up bricks with visible icons (widen = 10s, multiball = 3 balls)
- Collision robust: use swept collision / substepping to prevent tunneling
- Particles on brick break
- 3 lives, score, game over & victory screens, restart

Let me design carefully.

Canvas size: internal 900x700 maybe. Responsive scaling via CSS with aspect ratio, and devicePixelRatio handling.

Physics: ball speed increases slightly over time / per hit. Use sub-stepping: move ball in small steps (e.g., max 4px per step) and check collisions each step.

Collision detection: ball is a circle radius r. Brick is an AABB. For each substep, compute new position, then check overlap with bricks. Resolve by determining which axis caused overlap using previous position, push out.

Standard robust approach:
- For each brick, find closest point on brick rect to ball center. If dist < r → collision.
- Determine penetration normal: if ball center inside rect, push out along minimal axis. Otherwise normal = (center - closest)/dist.
- Move ball out along normal by penetration, reflect velocity: v = v - 2(v·n)n.
- Also mark brick hit, count damage.

Paddle collision: circle vs paddle rect. If ball moving down and overlaps paddle top, reflect based on hit offset: angle = offset * maxAngle where offset = (ballX - paddleX)/(paddleW/2) clamped [-1,1]. maxAngle ~ 65deg. Set velocity direction with that angle from vertical.

Also side collisions with walls: left/right/top bounce.

Lives: lose a ball when it falls below bottom. Multi-ball: when one falls, others remain? Common: lives decrement when all balls are gone. I'll decrement a life when a ball falls but keep going if other balls remain? Simpler: lives decrement only when the last ball falls. Actually classic: each ball falling costs a life in single ball; with multiball, usually lives count down only when all balls are lost. I'll do: when ball falls and it was the last remaining ball → lose life.

Power-ups:
- "W" wide paddle: 10 seconds, visual timer bar above paddle.
- "M" multi-ball: 3 balls.
- Icon drawn on brick (a small symbol). Bricks "visibly carry a power-up icon" — draw the icon in the brick face.

Power-up drops: fall slowly, caught by paddle.

Screens: title/start overlay ("Click or press a key to start"), game over, victory. Restart button.

Since the sandbox takes a screenshot after 3 seconds without interaction, I should make the demo self-playing? The instruction says "Games must start in a self-playing demo mode (a simple AI plays) behind a 'Click or press a key to start' message". Hmm — that means an AI plays behind the overlay message so something meaningful is visible. But requirement says paddle controlled by mouse/keys. I could implement an AI auto-pilot that moves the paddle to track the ball, so the game plays itself in demo mode. Then clicking/pressing key starts actual play. That satisfies both.

But careful: "The iframe only receives keyboard events after the user clicks it". So mouse events also probably only after click? Actually mouse moves might not be delivered either until click? Typically mouse events are delivered. To be safe, demo mode with AI autopilot active until user interacts.

So: on load, game is in "attract/demo" state: overlay shows "Click or press a key to start", and AI paddle tracks the ball. When user clicks or presses key, switch to player control and hide overlay.

Also arrow keys should work after click — add keydown listener on window; it only receives keys after click which is fine.

Let me write the code.

Structure:

HTML:
- Header: title "BRICK BREAKER", score, lives, level info.
- Canvas with glow effects.
- Overlay div positioned absolutely over canvas for start/gameover/victory messages.

Actually I'll draw overlays on canvas for crispness? Using DOM overlay is easier for buttons and text. But DOM overlay text in canvas area — fine, styled nicely. I'll do DOM overlay with a button.

Let me set canvas internal resolution 960 x 720? With DPR scaling. Container max-width.

Let's define constants:
- W = 960, H = 720 world units.
- Canvas CSS: width 100%, aspect-ratio 4/3.

Paddle: width 130 (normal), 190 (wide), height 16, y = H - 60.
Ball radius 9, speed base 380 px/s, increases a bit per paddle hit up to 620.

Bricks: 8 rows × 12 columns? That's 96 bricks, maybe too many. Let's do 10 columns × 8 rows = 80 bricks. Bricks width: (960 - 2*margin - gaps)/cols. margin 40, gap 6 → usable 880 - 9*6=54 → 826/10 = 82.6 wide. Height 26, gap 6, rows 8 → 8*32=256 + top 90 → bottom ~346. Good, leaves space.

Tough bricks: some rows (e.g., rows 5-6 pattern) are tough (2 HP). Normal bricks 1 HP.

Crack visual: after first hit on tough brick, draw crack lines and darker color, plus a small damage indicator.

Score: normal brick 50, tough 100 (maybe 50 for first hit 100 for break). Power-up brick 150.

Victory: all bricks destroyed.

Particles: on break, spawn ~14 particles with color of brick, gravity, fade. Also small shake maybe.

Also ball trail effect.

Power-up icons: draw on the brick a small icon: for widen, draw arrows "«»" or a wide paddle symbol; for multi, three small circles. I'll draw distinct shapes.

Dropping power-ups: when power-up brick breaks, spawn a falling capsule with icon, speed ~150 px/s. Caught by paddle (overlap) → apply effect. If falls off bottom → lost.

Wider paddle for 10 seconds: track widenTimer, decrement, show timer bar.

Multi-ball: 3 balls — spawn 2 extra balls at slight angles.

Lives: 3 hearts display.

Also a "Level 1" label.

Let's implement collision robustly with substeps.

function update(dt):
  - if state !== 'playing' → still run demo mode? Demo mode: state = 'demo'. Let's have state variable 'demo' | 'playing' | 'gameover' | 'victory'. In demo, we still simulate the whole game with AI paddle. Actually simpler: always simulate; control mode determines who moves paddle.

In demo mode, the game can progress and possibly reach game over... That would be confusing if the demo reaches game over before user interacts (3 seconds screenshot - unlikely to lose 3 lives in 3s though). But over time the demo may reach victory which is fine/fun. But if demo loses all lives, show game over overlay. Hmm. Better: in demo mode, lives don't decrease (infinite), so demo continues forever, restarting the level if all bricks cleared? Actually in demo mode let's reset bricks when cleared and continue - "attract mode". Simpler: in demo mode, if all bricks destroyed, rebuild level (new level) and keep going; lives don't deplete.

When user starts (click/key), reset the game fresh: full lives 3, reset bricks, and switch to player control. That's clean.

Let's implement:

- resetGame() : builds bricks, score=0, lives=3, balls = [one ball], paddle normal, state='playing', hide overlay.
- demo mode: state='demo', builds level, lives=3 but don't decrement; AI paddle tracks ball.

At start, call initDemo().

Overlay content per state:
- demo: "BRICK BREAKER" title, "Click or press a key to start" and small hint about controls, plus a "Start" button.
- gameover: "GAME OVER", score, "Click or press R / button to restart".
- victory: "VICTORY!", score, restart.

Any click on canvas starts/restarts. Key press: space/enter starts; also arrow keys start? "press a key to start" – any key starts. But arrow keys also move paddle; start on any key is fine.

Careful: after game over, pressing arrow key restarts — fine.

Implementation of AI paddle in demo: target x = predicted ball x when it comes down; simple approach: target = ball.x + ball.vx * timeToReachPaddle, clamp. That works decently.

Let me now write the drawing code nicely:
- Background: dark gradient, subtle grid or starfield, vignette.
- Bricks: rounded rect with gradient, inner highlight, colored by row palette. Tough bricks: metallic gray-blue with border showing HP; cracked overlay with crack lines.
- Power-up bricks: have a glowing icon and a distinct sheen.
- Paddle: rounded rect with gradient and glow; wide state shows extra glow and a timer bar.
- Balls: white glowing circle with trail.
- Particles.

Let me write it.

Colors palette per row:
row0: #ff5f6d? Let's use a neon palette:
['#ff4d6d','#ff8a3d','#ffd93d','#4ddb8f','#38bdf8','#a78bfa','#f472b6','#facc15'] etc. 8 rows.

Ball physics details:

Ball object: {x,y,vx,vy,r,trail:[]}

Update ball movement with substeps:
const steps = Math.ceil(speed*dt / 3); each step moves dt/steps.

Per step:
  newX = x + vx*stepDt, newY = y + vy*stepDt
  // wall collisions
  if newX - r < 0 → x = r, vx = abs(vx)
  if newX + r > W → x = W-r, vx = -abs(vx)
  if newY - r < 0 → y = r, vy = abs(vy)
  // paddle collision: if vy>0 and ball bottom >= paddle.top and ball top <= paddle.bottom and x within paddle range expanded
  Then compute offset and set angle.
  // brick collisions: iterate bricks alive, check circle-rect overlap; resolve each (maybe break after first resolution to avoid multiple). I'll handle up to few.

Circle-rect collision resolution:
function collideBricks(ball):
  for each alive brick:
    const cx = clamp(ball.x, brick.x, brick.x+brick.w);
    const cy = clamp(ball.y, brick.y, brick.y+brick.h);
    let dx = ball.x-cx, dy = ball.y-cy;
    let dist = hypot;
    if (dist < ball.r) {
      if (dist > 0) { n = {dx/dist, dy/dist}; }
      else { // center inside brick: push out minimal axis
        const left = ball.x - brick.x, right = brick.x+brick.w - ball.x;
        const top = ball.y - brick.y, bottom = brick.y+brick.h - ball.y;
        const m = Math.min(left,right,top,bottom);
        if (m===left) n={-1,0} else if(m===right) n={1,0} else if(m===top) n={0,-1} else n={0,1};
      }
      // push out
      ball.x += n.x*(ball.r - dist + 0.01) ... careful when dist===0: penetration = ball.r.
      Actually penetration = ball.r - dist (for inside case dist=0 → penetration=r, push out along n).
      ball.x += n.x*penetration; ball.y += n.y*penetration;
      const dot = ball.vx*n.x + ball.vy*n.y;
      ball.vx -= 2*dot*n.x; ball.vy -= 2*dot*n.y;
      // small nudge to avoid sticking
      hit brick: brick.hp--; if hp<=0 break → particles, score, maybe drop powerup; else crack.
      return true (handled) — but we might want to continue checking other bricks in same step. I'll loop and handle all overlapping bricks but with a cap of e.g. 4 to avoid weirdness; after each resolution recompute ball position. Simpler: handle one brick per substep, and since substeps are ~3px, that's fine. But an overlap with two adjacent bricks could cause the ball to bounce back and forth. Standard: resolve the first collision and continue next substep. Fine.

Ball speed: maintain constant speed magnitude. After any reflection, renormalize to current speed.

speed = baseSpeed + brickBreaks*2, capped at 700. Also clamp ball's vy to avoid too horizontal: if |vy| < 0.25*speed → adjust.

Paddle bounce: offset = (ball.x - (paddle.x + paddle.w/2)) / (paddle.w/2); clamp [-1,1]; angle = offset * (60° in rad) → direction: vx = sin(angle)*speed, vy = -cos(angle)*speed. Ensure vy negative (upward).

Also paddle side collision: if ball hits the side of the paddle (coming from the side), reflect horizontally. Handle: if ball overlaps paddle region and vy>0 and ball.y+r > paddle.y and ball.y - r < paddle.y+paddle.h → top bounce. But if ball hits the left/right edge while moving sideways... For simplicity: treat any overlap with the top half region as a top bounce; edges get sharp angles. If the ball approaches from the side (|vx| dominant) and hits below paddle top, we could reflect vx. I'll add: if ball center is below paddle top and vy>0 but ball.x is outside paddle horizontal span (within a few px) → reflect vx only.

Actually a neat approach: check the ball's previous position. If previous bottom <= paddle.y (i.e., ball was above paddle) → top bounce. Else → side bounce.

Let me store ball.px, ball.py before moving.

Paddle moving fast could cause ball to pass through? Since we use continuous-ish steps of 3px and paddle is 16px tall, should be fine. But paddle movement itself could tunnel a ball into the paddle. To handle, when checking paddle collision, also test overlap with the swept paddle region (union of prev and current paddle x). I'll use paddlePrevX.

Power-up catching: capsule {x,y,w:26,h:26,type,vy:130}. Catch if overlaps paddle rect. Also if it reaches bottom, remove.

Now the UI/HUD: I'd rather draw score/lives on canvas (top bar) for a cohesive look, plus DOM header? Let's draw HUD inside canvas top area (score left, lives hearts right, level). But the bricks start at y=90, so top 0-80 is HUD area. Nice.

I'll draw HUD on canvas:
- Left: "SCORE" label + number.
- Center: title "BRICK BREAKER" small? maybe.
- Right: lives as heart shapes.

Also wide-paddle timer bar drawn above paddle when active.

Let me write the code now.

Canvas sizing: use ResizeObserver / window resize to set canvas.width = rect.width * dpr, and scale context by (rect.width/W). Set CSS width 100% with aspect-ratio 4/3 inside a container max-width 960px.

Simpler: canvas style width:100%; height:auto; aspect-ratio: 4/3. In JS, compute rect = canvas.getBoundingClientRect(); canvas.width = Math.round(rect.width*dpr); canvas.height = Math.round(rect.height*dpr); ctx.setTransform(dpr*rect.width/W, 0,0, dpr*rect.width/W, 0,0)? Since aspect ratio 4/3 matches W/H = 960/720 = 4/3, scale = rect.width/W and height scale = rect.height/H equal. I'll compute sx = rect.width/W, sy = rect.height/H, and use ctx.setTransform(sx*dpr,0,0,sy*dpr,0,0).

Handle resize by re-setting transform each frame (cheap) — just set at start of draw.

Let me write the full code.

```js
const W=960,H=720;
```

Brick layout:
const COLS=10, ROWS=8;
const TOP=96, LEFT=44, GAP=6;
const avail = W - 2*LEFT - GAP*(COLS-1); // 960-88-54=818
const bw = avail/COLS = 81.8
const bh = 26;

Brick generation: for each row r, col c: skip some cells for variety? Keep full grid for "at least 6 rows". Maybe leave a couple gaps in the middle row for a pattern. I'll keep all 80 bricks to guarantee victory achievable.

Types: 
- tough: rows 6 and 7 (bottom two) mostly tough, plus some in row 5.
Let me define: tough if r >= 5 (rows 5,6,7) → 30 tough bricks. Plus maybe some in row 4 random. Fine.

Power-up bricks: pick e.g. 6 bricks randomly (not on bottom row? bottom row fine). Types alternate widen/multiball.

Brick object: {x,y,w,h,hp,maxHp,color,row,col,type:'normal'|'tough'|'power', powerType:'wide'|'multi', cracked:false, flash:0}

Hit effect: flash timer to make brick flash white briefly.

Score: normal 50, tough first hit 25, tough break 100, power 150.

Let's now write the drawing of a brick:

function drawBrick(b):
  ctx.save();
  rounded rect path.
  fill: base color with vertical gradient (lighten top).
  if tough: use metallic palette color based on row: e.g. '#5b6b8c' fill with silver border. Let's give tough bricks their own color: '#8b93b0' gradient to '#4d5570' with a light border.
  if power: gradient of gold/green plus glow shadow.
  flash: overlay white alpha.
  cracked: draw crack lines (deterministic per brick using seed from col/row) in dark color, plus a couple of chips.
  if power: draw icon in center.
  restore.

Crack drawing: use a deterministic pseudo-random path based on (row*31+col*17).

Let me implement drawCracks(ctx, x,y,w,h, seed): draw 3 polylines from center outward.

Icon drawing:
- wide: draw a small wide paddle shape (rounded rect wide) with left/right arrows.
- multi: three circles.

Drop power-up: capsule with color matching, icon inside, glow.

Now particles: {x,y,vx,vy,life,maxLife,size,color}. Update: vy += 900*dt; x+=vx*dt; life-=dt; draw as square/circle with alpha.

Also screen shake on brick break (small). ctx.translate with random offsets; keep track of shake magnitude decaying.

Ball trail: store last N positions, draw with decreasing alpha and radius.

Now let's write the main loop:

let last = performance.now();
function frame(now){ dt = Math.min(0.033, (now-last)/1000); last=now; update(dt); draw(); requestAnimationFrame(frame);}

update:
 - if state==='demo' or 'playing': update paddle, balls, bricks, powerups, particles, ball timers.
 - In demo: if lives<3? keep lives at 3 (don't decrement) and if all balls lost → reset ball to paddle and continue.
 - In playing: ball loss → lives--, if lives<=0 → gameover overlay; else reset ball attached to paddle.

Ball attached state: ball.state = 'attached' when waiting for launch; position follows paddle; when playing, launched.

Simplify: when a life is lost, create attached ball at paddle center; it launches when player clicks or moves? Auto-launch after a short delay (0.8s) or on click/space. I'll auto-launch after 0.6s in playing mode, and immediately in demo mode.

Ball attached: if ball.ready true: ball.x = paddle.x + paddle.w/2; ball.y = paddle.y - r - 2.

Also implement "launch" with slight random angle.

Now input:
- mousemove on canvas → target paddle x = mouse.x - paddle.w/2 (in world coords). set mouseActive = true, and if state==='demo' startGame().
- keydown ArrowLeft/ArrowRight → control via keys; startGame on any key in demo.
- In playing, arrow keys move paddle with acceleration.

Paddle control: 
if mouseMoved recently (within 2s) use mouse target; else keyboard. Or combine: keyboard adds velocity, mouse sets position directly. I'll do: keys set paddle velocity; mouse sets paddle.x directly (and sets lastMouseTime). Update: if keyLeft/keyRight → paddle.x += dir * speed * dt, and ignore mouse until mouse moves again. Use flag mouseHasFocus set true on mousemove; arrow key sets it false.

Actually simpler and standard: use both — arrow keys move paddle, mouse moves paddle; whichever was last used wins.

Implementation:
let controlMode = 'mouse'; // or 'keys'
on mousemove: controlMode='mouse'; mouseTargetX = worldX - paddle.w/2
on keydown of arrows: controlMode='keys'
update: if controlMode==='mouse' → paddle.x += (mouseTargetX - paddle.x) * min(1, dt*18) (smooth) ; else keyboard.

Clamp paddle.x in [0, W-paddle.w].

Wide paddle changes width → keep center stable: when widening, paddle.x -= (newW-oldW)/2.

Now the demo AI: controlMode='ai'; target = predict. In demo we set paddle.x toward target.

Ball prediction: time to reach paddle y: t = (paddle.y - ball.y)/ball.vy if vy>0; predictedX = ball.x + ball.vx*t. target = predictedX - paddle.w/2.

If ball.vy <= 0 or attached → target = ball.x.

Now the overlays (DOM):
```html
<div id="overlay" class="overlay">
  <div class="panel">
    <h1 id="ovTitle">BRICK BREAKER</h1>
    <p id="ovMsg">Click or press a key to start</p>
    <button id="ovBtn">Start</button>
    <div class="hint">Move: Mouse or ← → · Space to launch</div>
  </div>
</div>
```
Overlay absolutely positioned over canvas within .stage wrapper.

Style: backdrop blur, dark panel, neon border.

Handle states: showOverlay(title,msg,btnLabel).

Also HUD drawn on canvas.

Let me also add sound? Could add simple WebAudio blips — optional but "polished". WebAudio might be blocked without user gesture; but demo mode runs before gesture → audio context suspended; after click it resumes. I'll add simple sounds with a lazily created AudioContext, guarded by try/catch. Keep it subtle. Actually risk of errors; I'll include carefully with try/catch and only resume on user gesture.

Let me include it—small function beep(freq, dur, type, gain).

Now write everything.

Also mobile: touch events to move paddle. Add touchstart/touchmove → controlMode='mouse' style. Nice for narrow screens.

Responsive: container max-width 960px, padding. At 375px width, canvas is ~343px wide, height 257px — small but fine. Maybe adjust: on narrow screens, use W smaller? Keep world coords; just scale.

Let me write the code.

Detailed code:

```js
const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');
const W = 960, H = 720;
```

resize function:
```js
function resize(){
  const rect = canvas.getBoundingClientRect();
  const dpr = Math.min(2, window.devicePixelRatio||1);
  canvas.width = Math.round(rect.width*dpr);
  canvas.height = Math.round(rect.height*dpr);
}
window.addEventListener('resize', resize);
```
And in draw: const sx = canvas.width/W, sy=canvas.height/H; ctx.setTransform(sx,0,0,sy,0,0).

Since canvas.width/dpr uses CSS pixels * dpr, canvas.width/W = (rect.width*dpr)/W which scales properly.

Initial: call resize after layout; also use ResizeObserver.

Now write the brick creation:

```js
function buildLevel(){
  bricks = [];
  const powerCells = new Set();
  // choose some power bricks deterministically-random
  ...
}
```
Use Math.random for variety but deterministic enough.

Let me pick power-up bricks: choose 7 random positions among rows 0..5 (avoid too many). Alternate wide/multi.

Brick colors by row: palette array of 8.

Let's write drawing helpers:

```js
function roundRect(ctx,x,y,w,h,r){ ... ctx.beginPath(); ... }
```

Let me write the final code now. I'll be careful about correctness.

Full script outline:

```js
// ---------- state ----------
let state='demo'; // demo | playing | gameover | victory
let score=0, lives=3, level=1;
let bricks=[], balls=[], powerups=[], particles=[], floaters=[];
let paddle;
let widenTimer=0;
let shake=0;
let bricksBroken=0;
let ballSpeed=400;
```

floaters: score popups "+50" floating text.

update(dt):
```
if(state==='gameover'||state==='victory'){ updateParticles(dt); return; }
// paddle
updatePaddle(dt);
// balls
for each ball: updateBall(ball,dt)
// powerups
// particles
// widen timer
```

updateBall:
```
if(ball.attached){ ball.x = paddle.x+paddle.w/2; ball.y=paddle.y-ball.r-1; ball.launchT-=dt; if(ball.launchT<=0){ attach=false; set direction up with slight random } return; }
```
Hmm attached ball needs launching. In playing mode, launch on space or automatically after 1s. Let's auto after 0.9s, and space launches immediately.

Ball movement with substeps:
```
const speed = Math.hypot(ball.vx, ball.vy) || ballSpeed;
const stepDist = Math.min(speed*dt, 8);
const steps = Math.max(1, Math.ceil(stepDist/3));
const sdt = dt/steps;
for(let s=0;s<steps;s++){
  ball.px=ball.x; ball.py=ball.y;
  ball.x+=ball.vx*sdt; ball.y+=ball.vy*sdt;
  // walls
  if(ball.x-ball.r<0){ball.x=ball.r; ball.vx=Math.abs(ball.vx);}
  if(ball.x+ball.r>W){ball.x=W-ball.r; ball.vx=-Math.abs(ball.vx);}
  if(ball.y-ball.r<0){ball.y=ball.r; ball.vy=Math.abs(ball.vy);}
  // paddle
  if(ball.vy>0 && checkPaddle(ball)) { /* handled inside */ }
  // bricks
  if(checkBricks(ball)) { /* bounce */ }
}
```
Careful: after reflecting, ball.vx/ball.vy magnitudes stay same.

checkPaddle: 
```
const py = paddle.y, ph = paddle.h;
const prevBottom = ball.py + ball.r;
const curBottom = ball.y + ball.r;
if(curBottom >= py && prevBottom <= py + ph + 2 && ball.vy>0){
   // check horizontal overlap with swept paddle
   const px1 = Math.min(paddle.prevX, paddle.x), px2 = Math.max(paddle.prevX+paddle.w, paddle.x+paddle.w);
   if(ball.x+ball.r >= px1 && ball.x-ball.r <= px2){
       // top bounce
       const off = clamp((ball.x - (paddle.x+paddle.w/2))/(paddle.w/2), -1, 1);
       const ang = off * MAX_ANGLE; // MAX_ANGLE = 1.05 rad (~60°)
       ball.vx = Math.sin(ang)*speed;
       ball.vy = -Math.cos(ang)*speed;
       ball.y = py - ball.r - 0.5;
       ball.hits++;
       maybe increase speed slightly
       sfx
   }
}
```
Wait: if ball comes from the side below paddle top, prevBottom <= py+ph+2 may be true while ball is below paddle. Let's refine: require ball.y < py + ph (ball center above paddle bottom) i.e. ball center is in the upper region. Combine: curBottom >= py && ball.y < py + ph && horizontal overlap. Then top bounce. Else if ball overlaps paddle rect entirely (side hit) → reflect vx.

I'll implement generic circle-vs-paddle-rect resolution:
```
function collidePaddle(ball){
  const rect = {x:paddle.x,y:paddle.y,w:paddle.w,h:paddle.h};
  const cx = clamp(ball.x, rect.x, rect.x+rect.w);
  const cy = clamp(ball.y, rect.y, rect.y+rect.h);
  let dx=ball.x-cx, dy=ball.y-cy;
  const dist=Math.hypot(dx,dy);
  if(dist>=ball.r) return false;
  // resolve
  if(dist>0.0001){ nx=dx/dist; ny=dy/dist; } else { inside → push up }
  ...
}
```
But that generic approach loses the "angle by offset" requirement. So: do the offset-based bounce when the hit is on the top surface (ball center above paddle center or prevBottom <= paddle.y+ small). Else generic side reflect.

Plan:
```
const prevBottom = ball.py + ball.r;
// top-face test
if(ball.vy>0 && prevBottom <= paddle.y + 2 && ball.y + ball.r >= paddle.y){
   const cx = clamp(ball.x, paddle.x, paddle.x+paddle.w);
   if(ball.x + ball.r >= paddle.x && ball.x - ball.r <= paddle.x + paddle.w){
      // could be corner hit: if ball.x < paddle.x or > paddle.x+paddle.w → side
   }
}
```
Hmm, corner case: ball hits the very edge of the paddle from above but x slightly outside → in classic breakout it deflects sideways. Let's handle: if the ball center is within [paddle.x - something, paddle.x+paddle.w + something] treat as top hit; the offset formula naturally gives a sharp angle near edges. If ball center is outside the paddle horizontally by more than radius → side collision handled by generic.

I'll do:
```
// determine collision using swept top test
const topPrev = ball.py + ball.r, topNow = ball.y + ball.r;
const overX = ball.x + ball.r > paddle.x && ball.x - ball.r < paddle.x + paddle.w;
const hitTop = ball.vy > 0 && topNow >= paddle.y && topPrev <= paddle.y + 6 && overX;
```
If hitTop: bounce with offset angle using ball.x clamped relative to paddle center. Also ensure ball doesn't get stuck: ball.y = paddle.y - ball.r - 0.5.
Else: generic circle-rect resolution for side/bottom hits (rare). For side hit, reflect vx and push out.

That should be robust enough given small substeps.

Edge case: paddle moves up? Paddle doesn't move vertically. Good.

Also ball could tunnel through the paddle top if it's fast and the paddle is thin (16px) but substeps of 3px handle it.

Now bricks collision: circle vs AABB as described. After resolving, the ball's speed magnitude preserved.

One more consideration: to prevent the ball from getting stuck between two adjacent bricks (bouncing repeatedly), we resolve only one brick per substep and add a tiny separation.

After resolving a brick hit with hp>0 (tough brick first hit), the ball bounces off; fine.

Score/floater and particles on break.

Check win: bricks.every(b=>b.hp<=0) → victory. Use bricksRemaining counter.

Let me also add brick flash and small screen shake on break.

Power-up drop: when power brick broken, spawn powerup at brick center.

Now, AI demo and player control.

Let me code the demo AI target:
```
function aiTarget(){
  // find the lowest descending ball
  let best=null;
  for(const b of balls){ if(b.attached) continue; if(!best || b.y>best.y) best=b; }
  if(!best) return paddle.x+paddle.w/2 - paddle.w/2;
  if(best.vy<=0) return best.x - paddle.w/2;
  const t = (paddle.y - best.y)/best.vy;
  let px = best.x + best.vx*t;
  return px - paddle.w/2;
}
```
Smooth follow.

Now the DOM overlay updates. Let me code:

```js
function showOverlay(title, sub, btn){
  overlay.style.display='flex';
  ovTitle.textContent=title; ovMsg.innerHTML=sub; ovBtn.textContent=btn;
}
function hideOverlay(){ overlay.style.display='none'; }
```

State transitions:
- init: state='demo'; reset level; showOverlay('BRICK BREAKER', 'Click or press a key to start', 'Start Game');
- startGame(): if state==='demo' → full reset (score=0,lives=3,level=1, rebuild level, ball attached). state='playing'; hideOverlay().
  if state==='gameover' or 'victory' → same reset, state='playing'.
- on click on canvas or button → startGame().
- on keydown: if state!=='playing' → startGame(); else if space → launch.

Careful: keydown of arrow keys while in gameover restarts — acceptable.

Also in 'demo' state, if the AI clears the level → rebuild the level (attract loop) and keep score? Reset score maybe. I'll just rebuild bricks and reset balls, keep state demo.

Also demo: lives never decrease; if all balls lost → respawn attached ball.

Now writing the actual code. Let me be thorough with visuals.

Background: 
- gradient from #0b1020 to #131a33.
- subtle animated starfield / floating particles? Keep light: draw a grid of faint dots, plus a few slowly drifting bokeh circles.
- Vignette overlay.

HUD (top of canvas, y 0..88):
- Left block: "SCORE" small caps gray, number big bold neon.
- Right: "LIVES" + hearts.
- Center: level chip "LEVEL 1" and maybe bricks remaining bar.
Also a thin separator line at y=88.

Let me draw hearts as small heart shapes with path.

Wide paddle indicator: a bar above paddle showing remaining time with label "WIDE".

Let me write the heart path:
```js
function drawHeart(x,y,s,color){
 ctx.save(); ctx.translate(x,y); ctx.scale(s/10,s/10);
 ctx.beginPath();
 ctx.moveTo(0,3);
 ctx.bezierCurveTo(-6,-3,-10,1,-10,5);
 ctx.bezierCurveTo(-10,10,-4,13,0,16);
 ctx.bezierCurveTo(4,13,10,10,10,5);
 ctx.bezierCurveTo(10,1,6,-3,0,3);
 ctx.closePath(); ctx.fillStyle=color; ctx.fill(); ctx.restore();
}
```
Heart points down (y down) → ok.

Now let me write the code fully.

Also add a subtle "ball glow" using shadowBlur.

I'll write everything now, then sanity check.

One more: "The ball must never pass through bricks or the paddle." Our substep approach with max 3px steps plus AABB checks ensures this as long as ball radius ≥ step size relative to brick size — brick height 26, width 81. Fine. But there's a corner case: ball tunneling exactly through a brick's corner if the movement per substep is 3px — the collision check uses the new center position only; if the ball passes through a thin edge in one substep... Ball radius 9, so a 3px step can't jump over the brick's 26px height. Safe.

Let me also handle the case where a brick hit occurs but the ball is inside the brick (dist==0) — push out along the minimal axis.

Code for hitBrick:
```js
function hitBrick(b, ball){
  b.flash = 0.15;
  if(b.hp>1){ b.hp--; b.cracked=true; score+=25; floater(b.x+b.w/2,b.y,'25'); sfx('tick'); }
  else {
    b.hp=0; bricksRemaining--;
    const pts = b.type==='power'?150: (b.type==='tough'?100:50);
    score+=pts; floater(...);
    spawnParticles(b);
    if(b.type==='power') spawnPowerup(b);
    shake=Math.min(12, shake+4);
    sfx('break');
    // speed up slightly
    ballSpeed = Math.min(700, ballSpeed+2);
  }
}
```

Note: after hp-- on tough brick, second hit gives full points.

Speed increase: base 400 → after 80 bricks maybe +160 → cap 700. But the ball speed is per ball; I'll keep a global ballSpeed and apply to all balls after each break: for each ball, scale velocity to ballSpeed.

Simpler: keep constant speed per ball set at creation; on break, multiply all balls' speeds by 1.004 and cap. I'll maintain `speedScale`.

Let's keep: let speed = 400; each break: speed = Math.min(700, speed+3). Then after any reflection, renormalize ball velocity to `speed`. Implement in a helper `normalizeSpeed(ball)`.

Multi-ball: when power-up caught, spawn 2 extra balls from the current ball's position with angles ±25° from current direction, and the current ball keeps going. Total 3 balls.

Track total balls: when a ball falls, remove it; if no balls remain → lose life.

Widen: paddle.w = 190 for 10s, then back to 130. Draw timer bar.

Now particles colors: use brick color; for tough brick break use its color.

Let me write the final HTML.

Also add: instructions row under canvas (small text) for desktop; and the HUD in canvas.

I'll write it now in full.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Neon Breakout</title>
<style>
 :root{ --bg:#070b16; }
 *{box-sizing:border-box}
 body{margin:0;min-height:100vh;background:radial-gradient(1200px 800px at 50% -10%,#1b2450 0%,#070b16 60%); color:#e8ecff; font-family:...; display:flex; flex-direction:column; align-items:center; padding:16px; }
 .wrap{width:100%;max-width:960px;}
 h1{...}
 .stage{position:relative; width:100%; aspect-ratio:4/3; border-radius:18px; overflow:hidden; box-shadow:0 20px 60px rgba(0,0,0,.6), 0 0 0 1px rgba(120,150,255,.15);}
 canvas{display:block;width:100%;height:100%; touch-action:none; cursor:none;}
 .overlay{position:absolute;inset:0;display:flex;align-items:center;justify-content:center; background:rgba(5,8,20,.62); backdrop-filter:blur(6px);}
 .panel{text-align:center;padding:28px 34px;border-radius:16px;background:rgba(12,18,40,.75);border:1px solid rgba(130,160,255,.25); box-shadow:0 0 40px rgba(60,90,255,.25); max-width:90%}
 .panel h2{font-size:clamp(24px,5vw,44px); margin:0 0 8px; letter-spacing:2px; background:linear-gradient(90deg,#7dd3fc,#a78bfa,#f472b6); -webkit-background-clip:text; color:transparent;}
 ...
</style>
```

Use system fonts to avoid external fonts: font-family: "Segoe UI", system-ui, -apple-system, sans-serif.

Now the canvas cursor:none so mouse control feels like the paddle follows. Maybe keep cursor crosshair. I'll use cursor:none but only when overlay hidden... keep simple: cursor:none.

Let me now produce the final code.

I need to double check the paddle control with mouse: mousemove on canvas gives clientX → world x = (clientX - rect.left) * W/rect.width.

Write it.

Also handle pointerdown on canvas → startGame() (and if playing, launch attached ball).

Let's write final code carefully.

```js
const overlay=document.getElementById('overlay');
const ovTitle=document.getElementById('ovTitle');
const ovMsg=document.getElementById('ovMsg');
const ovBtn=document.getElementById('ovBtn');
const ovStats=document.getElementById('ovStats');
```

showOverlay with optional stats text (final score).

Now write update functions.

Also add a "combo"? Not needed.

Let me write out the code.

```js
// ---------- Audio ----------
let actx=null;
function beep(freq,dur,type='sine',vol=0.06){
  try{
    if(!actx) actx = new (window.AudioContext||window.webkitAudioContext)();
    if(actx.state==='suspended') actx.resume();
    const o=actx.createOscillator(), g=actx.createGain();
    o.type=type; o.frequency.value=freq;
    g.gain.setValueAtTime(vol, actx.currentTime);
    g.gain.exponentialRampToValueAtTime(0.0001, actx.currentTime+dur);
    o.connect(g); g.connect(actx.destination);
    o.start(); o.stop(actx.currentTime+dur);
  }catch(e){}
}
```
This may produce many oscillators but fine. Maybe limit beep rate. OK.

Now full code writing.

For the brick "crack" visual, I'll draw jagged lines:

```js
function drawCracks(b){
  const seed=(b.row*7+b.col*13)%97;
  const rnd=(i)=> ((Math.sin(seed*12.9898+i*78.233)*43758.5453)%1+1)%1;
  ctx.save();
  ctx.strokeStyle='rgba(15,18,30,.85)'; ctx.lineWidth=1.6; ctx.lineCap='round';
  for(let k=0;k<3;k++){
    ctx.beginPath();
    let x=b.x+b.w*(0.2+0.6*rnd(k)), y=b.y+b.h*0.5;
    ctx.moveTo(x,y);
    for(let s=0;s<3;s++){
      x += (rnd(k*10+s)-0.5)*b.w*0.35;
      y += (rnd(k*20+s)-0.5)*b.h*0.9;
      ctx.lineTo(x,y);
    }
    ctx.stroke();
  }
  ctx.restore();
}
```

Now, the tough brick must "visibly crack after the first one" — done, plus change color slightly darker and maybe show a small "chip" corner.

Power-up brick icon drawing:
```js
function drawPowerIcon(x,y,type,size){
  ctx.save(); ctx.translate(x,y);
  if(type==='wide'){
    // wide paddle with arrows
    ctx.fillStyle='rgba(255,255,255,.95)';
    roundRect(ctx,-size*0.45,-size*0.16,size*0.9,size*0.32,size*0.12); ctx.fill();
    // arrows
    ctx.strokeStyle='#0b1020'; ctx.lineWidth=2; ...
  } else {
    // three balls
    ctx.fillStyle='rgba(255,255,255,.95)';
    for(let i=-1;i<=1;i++){ ctx.beginPath(); ctx.arc(i*size*0.32,0,size*0.18,0,Math.PI*2); ctx.fill(); }
  }
  ctx.restore();
}
```

Now write draw() fully.

Time to produce the answer. I'll write it carefully and completely.

For the wide-paddle timer bar: draw above paddle: rect width proportional to remaining/10 with gradient, label "WIDE".

Also for multi-ball active indicator: show a badge "×3" in HUD? Show small text near lives: "BALLS 3". I'll compute balls count and display.

Let me finalize the HUD layout:
- y=18: labels.
- Left at x=28: "SCORE" (12px, letter-spacing, color #7f8bb5) at y=30; value at y=64 font 34px bold.
- Right at x=W-28 (right aligned): "LIVES" label; hearts row under it.
- Center: "LEVEL 1" chip at x=W/2, y=30; bricks remaining bar: text "BRICKS 72" at y=56? Let's do center chip with level and a progress bar of bricks destroyed.

Fine.

Writing the final answer now.

For the demo, ensure a ball is present: initDemo creates a ball attached to the paddle with launchT=0.5, and the AI moves the paddle. When the ball is attached in demo mode, the AI target = paddle center → it stays. Then launches upward.

Also the demo needs a visible message: the overlay panel shows "Click or press a key to start" — yes, plus the game is visible behind the blurred overlay (backdrop-filter blur). The screenshot will show a blurred game with the message. Good enough — but the requirement says something meaningful visible. The overlay is semi-transparent so the game is visible. Maybe make the overlay less opaque (rgba(5,8,20,.5)) so the game is visible behind. Good.

Now, the demo AI paddle should actually play well enough to break bricks within 3 seconds — the ball takes ~1s to travel from paddle to bricks, then bounces. Within 3 seconds, a few bricks break. Good.

Let me write the code.

Also add slight randomness in AI to avoid perfect play? It's fine.

Final: write the code.

One more detail: `balls` array and `attached` ball. When the ball falls (y - r > H), remove it. If balls.length === 0 → life lost.

For multi-ball the lives decrement only when all balls are gone. Good.

Writing now.

Also: pointer events for mobile: 'pointermove' works for mouse and touch (touch requires touch-action:none, set). Use pointermove on the canvas.

I'll use canvas.addEventListener('pointermove', ...) and 'pointerdown'.

Let me write out everything.

const MAX_ANGLE = 1.15 rad (~66°).

Also ensure ball doesn't go too horizontal: after paddle bounce, |off| ≤1 → angle ≤66°, so vy = -cos(66°)*speed = -0.4*speed, fine.

Speed: base 420. min vertical component ensures not stuck.

Also cap the ball speed relative to canvas.

Let me write the code now, final.

I also want to ensure that after a brick collision, the ball doesn't get stuck in a repeating collision with the same brick: after resolving, add a small epsilon along the normal and the brick's hp decreased; for a tough brick with hp remaining, the next frame the ball may overlap again if it was pushed exactly to the surface... we push out by penetration+0.5 so it should be clear.

Hmm, one subtlety: if the ball's center is inside the brick (dist≈0 case) we push it out but the normal chosen may push it into the neighboring brick → ping-pong. With 26px tall bricks and the ball moving 3px per substep, it should resolve.

Write it.

For particles: also spawn a few on tough-brick first hit (small dust).

Let me write the final code text.

Also the floating score texts: array of {x,y,text,life,color}.

I'll now compose the answer.

Regarding `state` and startGame: also need to reset `controlMode='mouse'` maybe to 'keys'? Set to 'mouse' default so mouse works; if the user only uses keys, the first arrow keydown sets 'keys'. But initially the mouse target may be unset (0). If the user moves the mouse, fine. Set mouseTargetX = paddle.x initially.

Let me write.

Final code:

```js
// ============ INIT ============
buildLevel();
state='demo';
showOverlay('NEON BREAKOUT','Click or press a key to start<br><span class="sub">Move the paddle with your mouse or the ← → arrow keys</span>','Start Game');
```
Hmm the panel has separate elements; I'll set ovMsg.innerHTML with the hint and ovBtn.

Layout of panel:
```
<h2 id="ovTitle">NEON BREAKOUT</h2>
<p id="ovMsg">Click or press a key to start</p>
<p class="keys">Mouse or ← → to move · Space to launch</p>
<button id="ovBtn">Start Game</button>
<p id="ovStats" class="stats"></p>
```

OK writing the answer now. I'll be complete and careful.