Brick breaker · mimo-v2.6-flash

Let me check the directory and the phaser library.

Let me write the game. Design: canvas 800x600, Phaser 3 arcade physics or manual movement. I'll use manual velocity updates with Phaser.Geom.Intersects or simple AABB collision, simpler and reliable.

Plan:
- Scene with UI text (score, lives, controls), bricks created from generated textures via Graphics.generateTexture.
- Paddle: rectangle image from generated texture, keyboard cursors + pointer.
- Ball: circle texture.
- Ball rests on paddle until launch (Space or Launch button — a visible button; can use Phaser text with interactive, or an HTML button overlaid. Phaser interactive text is fine, but "visible Launch control" — I'll do an HTML button overlay + Phaser text button. Simpler: HTML button positioned over canvas. Actually mixing is fine; I'll add a DOM button in the container styled, visible only when in launch state. But Phaser canvas might capture input... DOM button on top with higher z-index works.

Actually simpler and robust: add a visible HTML overlay button "Launch (Space)" that calls into the game via window function. Let's do that.

Physics: manual update. Ball position += velocity*dt scaled. Use Phaser's arcade physics? Manual gives precise control over paddle bounce angles.

Collision:
- Walls: left/right/top reflect.
- Paddle: if ball moving down and overlapping paddle rect, reflect up with angle based on hit offset.
- Bricks: loop through active bricks, AABB check with ball radius, remove brick, flip velocity (choose axis based on penetration depth), score++.

Ball below playfield: lose life.

Win: all bricks destroyed -> win state, show overlay, restart button.
Game Over: lives 0.

Restart: restore bricks, score, lives.

Let's set dimensions: width 800, height 600. Playfield bounds: use full canvas with HUD at top? Keep play area from y=60 (below HUD) to 600. Ball lost when y > 600 (below paddle line). Actually "ball falling below the paddle costs one life" — I'll say ball y > playfield bottom.

Bricks: 8 cols x 5 rows = 40 bricks. Brick 80x24 with gaps.

Graphics textures: generate 'paddle', 'ball', 'brick' textures with different colors? Generate brick textures per color row (5 colors) via Graphics.generateTexture.

Controls text: HTML panel below canvas or in-game text. I'll add HTML header with controls info plus in-game HUD text.

Mouse control: pointer.x moves paddle; clamp inside.

Also keyboard: left/right arrows, A/D.

Ball speed: 320 px/s base, increase slightly per brick? Keep constant for predictability, maybe cap.

dt: use delta from update, clamp to 0.033 to avoid tunneling. Ball speed 320, dt 0.033 → 10.6px per frame; brick height 24, ball radius 8 → 40px combined... fine. Use continuous-ish: check brick collision with ball circle vs rect.

Actually for direction choice on brick: compute overlap on x and y, reflect on the axis with smaller penetration.

Let me write code.

For the Launch button: HTML button visible when state === 'ready'. Also Space key. Restart button on win/over: HTML button too, plus R key.

Let me also make the paddle visible with rounded look: Graphics generateTexture with fillRoundedRect.

Ball bounce off paddle: reflect vy = -abs(vy), vx = speed * offset, vy = -sqrt(speed² - vx²) roughly; clamp vx.

Write the file.

Debug hooks: expose window.__game = {scene} for browser inspection? I can inspect via browser tool evaluate? The browser tool has "inspect" action which shows DOM/console. I can add temporary console.log statements or use window.__state. I'll expose a debug object with state (score, lives, ballPos, bricksRemaining, stateName) so I can verify via console inspection. Actually the inspect action probably shows DOM and console output. Let me expose window.__dbg and log key events: launch, life lost, brick hit with score.

Let's write it.

Ball launch: on launch, velocity set at angle -60..-120 degrees random, upward.

Resting: ball position = paddle.x, paddle.y - radius - 2.

States: 'ready', 'playing', 'lost' (brief), 'win', 'over'. On life lost: if lives>0 → state 'ready' after short delay (0.6s) or immediate. I'll do immediate with a brief pause of 500ms showing "Life lost".

Implement with a state machine and timers via this.time.delayedCall.

Now HTML layout: centered container, header title, HUD (score, lives, bricks), canvas, controls hint, launch/restart button.

Phaser config: width 800, height 600, parent 'game', backgroundColor '#0b1020', scale mode FIT? Use Phaser.Scale.FIT with autoCenter. Parent div sized 800x600 but responsive... Keep simple: scale: { mode: Phaser.Scale.FIT, autoCenter: Phaser.Scale.CENTER_BOTH, width:800, height:600 }.

Mouse control: on pointermove set targetX; paddle.x moves toward targetX quickly (or directly set). Direct set is fine and clamped.

Keyboard: velocity 520 px/s.

Now code the scene.

Bricks grid: cols 8, brickW 84, gap 6, margin left = (800 - (8*84 + 7*6))/2 = (800 - (672+42))/2 = (800-714)/2 = 43. rows 5, brickH 22, gap 8, top offset 90.

HUD at top y ~ 10-40 within the play area? Play area top wall at y=0? Let's have walls: left x=0, right x=800, top y=0. HUD text drawn at top over bricks area? Bricks start at 90 so HUD text at y 20-50 fits between top wall and bricks. Fine: score text top-left, lives top-right, controls text bottom? Bottom is below playfield... controls shown in HTML below canvas. Also a small in-canvas hint "SPACE / Launch button" during ready state.

Ball lost threshold: y > 600 + r.

Walls: ball x < r → x=r, vx=abs; x > 800-r → vx=-abs; y < r → y=r, vy=abs.

Let me write the full file now.

Brick texture colors: 5 rows with colors ['#ff5d73','#ffb347','#ffe66d','#7ef57e','#5ec8ff'].

Score: 10 points per brick * (rows - row) maybe? Requirement: increases score once per brick. Use fixed 10 points.

Expose debug: window.__dbg = () => ({state, score, lives, bricks: activeCount, ball:{x,y,vx,vy}, paddle:{x,left,right}}).

Also log events to console with prefix.

Write it.

Let me write index.html with a brick-breaker game in Phaser 3, using generated textures via Graphics.

Design: canvas 800x600. Bricks at top, paddle at bottom, ball. Physics: I'll do manual movement or use arcade physics. Simpler: use Phaser's arcade physics with static bodies for bricks and paddle/walls.

Let me write it carefully.

Key features:
- Paddle: left/right keys + pointer. Clamp within playfield.
- Ball rests on paddle; Space or Launch button starts it.
- Collisions: ball vs paddle (bounce with angle based on hit position), ball vs walls, ball vs bricks (destroy brick, score+1).
- Lives: 3; ball below paddle → lose life, return to launch state.
- Win when all bricks gone; Game Over at 0 lives; Restart button restores.

I'll use arcade physics. Bricks as static group with generated texture. Ball collides with bricks using callback that destroys the brick and increments score.

Physics: ball.body.bounce = 1, use collideWorldBounds. But bottom needs to not be world bound — set world bounds with checkCollision.down = false, and detect y > height manually.

Walls: left/right/top via world bounds checkCollision.

Ball speed: set velocity after launch, ensure not too vertical: clamp velocity angle.

Paddle as static image with physics body; ball vs paddle collide with processCollision, plus manual bounce angle.

Let's generate textures with Phaser Graphics: 
- ball: white circle radius 8
- paddle: rounded rect 120x18, use fillRoundedRect and generateTexture
- bricks: 64x24 rects with color; generate per-color texture.

UI: HTML overlay for controls text and buttons? Requirement says "Show the controls" — could be text in Phaser or HTML. I'll show HTML overlay for score/lives/state and a Launch button (visible Launch control) and Restart button. Buttons via HTML are easy to click in browser tool. Also Phaser text for score/lives.

Actually simpler: all HUD in Phaser text, plus HTML buttons for Launch/Restart positioned below canvas. Let me do a mix: top bar in Phaser showing Score, Lives, state message; HTML buttons under canvas for Launch and Restart, plus controls info.

Wait — mouse control of paddle: pointermove on the Phaser canvas sets paddle x. Phaser input.activePointer worldX.

Let's write code.

```js
class GameScene extends Phaser.Scene {
  constructor(){ super('game'); }
  create(){
    this.score=0; this.lives=3; this.state='ready'; // ready, playing, won, over
    this.W=this.sys.game.config.width; this.H=...;
    create textures
    create bricks group
    paddle = this.physics.add.staticImage(...)
    ball = this.physics.add.image(...).setCollideWorldBounds(true).setBounce(1)
    ball.body.setCircle(8)
    world bounds: this.physics.world.setBounds(0,0,W,H); ball.body.checkCollision.down=false after setCollideWorldBounds? setCollideWorldBounds sets all true; then set ball.body.checkCollision.down = false.
    collisions...
    keys
    text HUD
  }
}
```

Paddle movement: in update, if keys left/right, paddle.x += speed*dt; clamp. Also pointer: if pointer is down or moving over canvas, set paddle x = pointer.x (mouse move). I'll use "mouse over canvas" — use this.input.activePointer with this.input.mouse within canvas. Simpler: this.input.on('pointermove', p => { if state ready/playing paddle.x = clamp(p.x) }). But pointermove when mouse outside? Fine.

Actually if user uses keyboard after mouse, pointermove won't fire unless moving. Good.

Careful: pointer x coordinates are worldX. Since no camera scroll, fine.

Ball resting: while state==='ready', ball.setPosition(paddle.x, paddle.y - ballRadius - paddleHeight/2 - 2), ball.body.setVelocity(0,0) and body.enable = true but zero velocity.

Launch: give velocity random angle upward: vx = ±random 120-200, vy = -300... speed ~ 340.

Brick collision: 
```
this.physics.add.collider(this.ball, this.bricks, (ball, brick)=>{
  if(!brick.active) return;
  brick.disableBody(true,true);
  this.score++; updateHUD;
  if(this.bricks.countActive(true)===0) win
});
```
Arcade physics collider with group handles destroy via disableBody.

Paddle collision: collider(ball, paddle, callback) — default physics would reflect based on bodies. Ball bounce=1 so it should bounce off. But to control angle, in callback set velocity: 
```
const diff = ball.x - paddle.x;
const norm = Phaser.Math.Clamp(diff/(paddle.width/2), -1, 1);
const angle = norm * 60 * Math.DEG_TO_RAD; // max 60deg
const speed = current speed (or fixed)
ball.setVelocity(Math.sin(angle)*speed, -Math.abs(Math.cos(angle)*speed));
```
Also ensure minimum |vx| maybe.

Since collider callback runs after separation, setting velocity works.

Ball body circle: ball texture radius 8, setCircle(8).

Detect falling below: in update, if state==='playing' && ball.y > H + 20 → lose life.

Actually ball world bounds bottom check false means it keeps falling. Check ball.y > H (paddle at H-40). Let's check ball.y > H - 5? Paddle y = H - 40, paddle height 18, ball radius 8. Ball passes paddle when y > paddle.y. Use threshold: ball.y > H (fully offscreen) — but we want "below the paddle costs one life". Use ball.y > H - 10 maybe. I'll use ball.y > H (off screen) to be safe visually. Actually if ball misses paddle it will keep falling; losing life when y > H + 10 is fine.

On life lost: lives--, if lives<=0 → game over state; else reset to ready (ball on paddle).

Win state: stop ball (velocity 0), show "You Win! Press Restart".

Restart button: resets score, lives, bricks (recreate), state ready.

Also space key launches; space also could restart? Keep restart via button + 'R' key.

HUD text: score, lives, state message center ("Press Space or Launch", "You Win!", "Game Over").

Bricks: rows 5, cols 8. Width 800: margin 20, gap 6 → brick width = (800 - 2*20 - 7*6)/8 = (800-40-42)/8 = 718/8 = 89.75. Let's compute in code: brickW = 84, cols 8, gap 8, total = 8*84 + 7*8 = 672+56=728, offset = (800-728)/2 = 36. Good. Height 26, gap 8, start y = 70.

Texture for brick: generate per color: gfx.fillRoundedRect(0,0,84,26,4); generateTexture('brick'+i, 84,26).

Colors palette.

Paddle texture: 120x18 rounded, color 0x4fc3f7.

Background: dark. Add subtle starfield? Not needed.

Controls text at bottom or in HTML. I'll put HTML instructions below canvas, plus canvas HUD.

Let's also make the Launch button visible and enabled only in ready state, Restart visible always (or after win/over). I'll show Launch when ready, Restart when won/over. Actually keep Restart always visible for safety; Launch visible only in ready.

HTML layout: container with canvas area (Phaser game will be created in a div) + hud bar.

Phaser config: width 800, height 600, parent 'game', backgroundColor '#0b1020', physics arcade, scene.

Let me write the file.

Edge: prevent arrow keys/space from scrolling page: capture keyboard.

Ball speed constant: 330 px/s.

Ensure ball doesn't go horizontal: after paddle hit, vy at least -0.5*speed.

Also on launch, ensure |vy| significant.

Write code now.

For the pointer control: use `this.input.on('pointermove', ...)` but only when pointer within game area. Phaser gives pointer within game only if input events fire (they do when over canvas). Also handle pointer down for launch? Not required. Maybe clicking canvas launches too — nice but "visible Launch control" required; I'll also allow click on canvas to launch while ready. Might conflict? It's fine.

Hmm, careful: clicking the Launch HTML button — pointer events on canvas don't fire then.

Let's write.

Also physics body for paddle: static body. ball vs paddle collider.

I need to make sure ball doesn't tunnel bricks at speed 330 with brick height 26 — fine at 60fps (5.5px/frame).

Also prevent ball getting stuck in horizontal loop: if |vy| < 40 while playing, nudge. Add in update: if(Math.abs(ball.body.velocity.y) < 50) { recompute } — I'll adjust: set vy sign to direction and magnitude min 100.

Let me write the file now.

Code:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Brick Breaker</title>
<style>...</style>
</head>
<body>
<div id="wrap">
  <div id="game"></div>
  <div id="panel">
    <div id="controls">← → or move mouse ...</div>
    <button id="launchBtn">Launch (Space)</button>
    <button id="restartBtn">Restart (R)</button>
  </div>
</div>
<script src="phaser.min.js"></script>
<script>
...
</script>
</body>
</html>
```

Phaser will size the div. Game 800x600, scale mode FIT maybe. Keep simple: width 800 height 600, parent, no scale mode (canvas is 800x600).

HUD inside canvas: score top-left, lives top-right, message center.

Let's write final code.

For debugging/verification, expose `window.game` and scene reference for browser inspection? The browser tool can inspect DOM/console. I can add console.log on events and expose `window.__scene` for testing via inspect? The browser tool's "inspect" action — unclear capability (probably evaluates JS / shows DOM). I'll expose globals and log to console, then verify via inspect with console output.

Let me write it.

Let me write the game. I'll write index.html in one go.

Design: 800x600 game. Use Phaser 3 arcade physics or manual movement. Simpler: manual movement with update loop, no physics engine complexities. But bouncing off paddle — manual reflection is fine.

Let me use Phaser 3 with manual collision logic (no physics body) to have full control. Actually, Arcade physics with a static paddle and manual ball velocity is easy too, but ball-paddle bounce angle depends on hit position — easier manual.

Plan:
- Scene BootScene: generate textures using Graphics: paddle (rounded rect), ball (circle), brick (rect with highlight), background starfield maybe.
- MainScene: create bricks (grid), paddle, ball, score/lives text, launch control button (visible HTML button or Phaser text). Requirement: "Space or a visible Launch control starts it." I'll add a Phaser interactive text button "LAUNCH" plus keyboard. Maybe also an HTML button overlay — Phaser text button is fine as "visible".

Controls display: text at bottom "←/→ or Mouse to move • Space to launch • R to restart".

Ball resting on paddle: position ball above paddle, follow paddle.

Collision:
- walls: left/right/top reflect.
- paddle: if moving down and overlap and ball bottom >= paddle top, reflect with angle based on offset.
- bricks: check overlap ball rect vs brick rect; destroy brick, score++, reflect ball (determine side by penetration depth).

Lives: ball y > height + radius => lose life, reset to launch.

Win: all bricks destroyed -> win state, freeze ball, show "You Win!" and restart prompt.

Game Over: lives 0.

Restart: R key or Restart button; rebuild bricks, score 0, lives 3.

Graphics generation: use Phaser.GameObjects.Graphics to generateTexture.

Let me also add a subtle background via Graphics (grid lines) as texture.

Ball trail optional. Keep it manageable.

Mouse control: pointer move moves paddle x, clamped. Keyboard left/right also. Also allow click on canvas to launch? Space or Launch button.

Let's write it.

Implementation details:

```js
const W=800,H=600;
const PADDLE_W=110, PADDLE_H=16;
const BALL_R=8;
const BRICK_COLS=10, BRICK_ROWS=5, BRICK_W=64, BRICK_H=24, BRICK_PAD=6, BRICK_TOP=80, BRICK_LEFT = (W - (cols*(w)+pad*(cols-1)))/2
```
10*64 + 9*6 = 640+54=694, left = (800-694)/2=53. Good.

Ball speed 340 px/s, increase slightly with paddle hits? Keep constant ~360. Use delta-based movement to be framerate independent. But brick collision with substeps: move ball in small steps per frame (e.g., steps = ceil(speed*dt / 4)) to avoid tunneling.

I'll implement step-wise movement: divide frame movement into substeps of max 3px, check collisions each substep.

Collision helpers: AABB overlap of circle approximated by rect.

Paddle bounce: compute angle: offset = (ball.x - paddle.x)/(PADDLE_W/2) clamped [-1,1]; angle = offset * 60deg from vertical; speed preserved. vy negative.

Brick collision direction: compare overlap depths.

Sound: no audio assets allowed; could use WebAudio oscillator but not required. Skip, or simple beep via Phaser? Not required — skip to avoid complexity. Actually "Do not load image or audio assets" — generating beeps with WebAudio is allowed but optional. I'll add a tiny WebAudio blip? Keep simple: skip, or add simple oscillator beeps for bounce/brick/life. That's a nice touch and safe. I'll add a small beep function with try/catch, initialized on first user gesture.

Text: score top-left, lives top-right (draw hearts as small graphics or text "Lives: 3").

Win/lose overlay: centered text + "Press R or click Restart".

Buttons: Phaser text buttons with setInteractive, styled rounded rect background via Graphics texture "btn" scaled? Simpler: create a container with a Graphics-drawn button texture generated for a fixed size, then Text on top. I'll generate a button texture 180x44.

Actually use UI text objects: create a helper makeButton(scene,x,y,w,h,label,onClick).

I'll generate texture 'btn' 180x44 with rounded rect fill and border; use setDisplaySize? Scaling a texture is fine.

Let's write code carefully.

States: 'ready' (ball on paddle), 'playing', 'won', 'lost', 'paused'? Not needed.

Also "Restart restores all bricks, score, and lives" — R key or Restart button always available.

Touch/mouse: pointer moves paddle. Launch button clickable.

HTML overlay: I'll put a header above canvas? The canvas is 800x600; page background dark. Add a small legend under canvas? Requirement "Show the controls" — I'll show controls text inside the game (bottom) AND an HTML hint below. In-game text is enough but I'll add both.

Now writing.

Substep collision code:

```js
stepBall(dt){
  const dist = this.ballSpeed*dt;
  const steps = Math.max(1, Math.ceil(dist/3));
  const step = dist/steps;
  for(let i=0;i<steps;i++){
    this.ball.x += this.vx/this.ballSpeed*step;
    this.ball.y += this.vy/this.ballSpeed*step;
    this.handleCollisions();
    if(this.state!=='playing') break;
  }
}
```
where vx,vy are velocity components with magnitude ballSpeed.

handleCollisions: walls, paddle, bricks.

Wall: left if ball.x - R < 0 => x = R, vx = |vx|; right similar; top y = R, vy=|vy|.

Paddle: if vy>0 and circle-rect overlap:
```
const px=paddle.x-PADDLE_W/2 ... use bounds
if(ball.x+R>pl && ball.x-R<pr && ball.y+R>pt && ball.y-R<pb){
  ball.y = pt - R;
  const off = clamp((ball.x-paddle.x)/(PADDLE_W/2),-1,1);
  const ang = off * Math.PI/3; // up to 60deg
  vx = Math.sin(ang)*speed; vy = -Math.cos(ang)*speed;
}
```
Hmm with offset 1, vx=0.866*speed — fine, keeps speed constant.

Minimum |vy| ensured since cos(60°)=0.5 > 0. Good.

Bricks: loop bricks; if overlap, compute overlapX and overlapY, reflect along smaller, destroy, score++, speed maybe +2 up to cap.

After each brick destroyed check remaining==0 => win.

Prevent multiple brick hits per substep? It's fine; could break after first brick hit per substep.

Lose life: in update after stepping, if ball.y - R > H => lives--; if lives<=0 => game over else reset to ready.

Bricks creation: color per row from palette.

Now the "Launch control": a visible button in-game at bottom center during ready state: "LAUNCH (Space)". Hide during play.

Also HUD updates.

Let me write the file now.

For text fonts: use monospace/system fonts.

Also pause when ball goes out of bounds — handled.

Mouse control: `this.input.on('pointermove')` set paddle x = pointer.x clamped; also pointerdown on canvas could launch when ready (nice). And keyboard cursors.

Prevent paddle from leaving: clamp between R? paddle clamp 0..W with half width.

I'll write the file.

Regarding brick hit "increases score once": with substep break after one brick, and brick destroyed immediately, no double counting.

Also, when ball is inside brick region across multiple substeps, it's destroyed so fine.

Edge case: ball could hit two bricks in one substep (adjacent). Break after first => only one score per substep; the other brick will be hit next substep since ball still overlaps. Actually if ball overlaps two bricks and we reflect, direction changes, might escape. Acceptable.

Better: check all bricks in a substep but only destroy/score those overlapped, and determine reflection from the first. Multiple bricks in one substep should each be scored once (they are distinct bricks). Requirement: "Hitting a brick removes it and increases the score once" — per brick. So destroying multiple overlapping bricks at once is fine. I'll iterate all bricks, destroy each overlapped, count each once, and use first hit to compute reflection.

But careful: if reflection uses first brick's normal and subsequent bricks are behind... fine.

Let's also add subtle particle-ish effect: on brick destroy, spawn a few small rects tweened. Nice but optional — cheap to add with tweens. I'll add small flash.

Write the code.

Win check after all bricks cleared.

Now HTML/CSS: dark background, centered canvas container, title, footer instructions.

Phaser config: width 800, height 600, parent 'game', backgroundColor '#0b1020', scale mode FIT center.

Let me write it.

One thing: generating textures in create with graphics.generateTexture.

Textures needed: 'paddle' (PADDLE_W x PADDLE_H with gradient-ish: fill + top highlight), 'ball' (2R circle with highlight), 'brick' (BRICK_W x BRICK_H) — but brick colors per row; I can tint bricks with setTint or generate one white-ish brick texture and use setTint? Images from generated textures support setTint (tint multiplies). Generate brick texture as light gray with border highlight, then setTint(rowColor). That works since tint multiplies white-ish base... base is not pure white (border darker), tint multiplication gives darker overall. Fine.

Alternatively generate textures for each row color: brick0..brick4. That's clean: loop generateTexture with fillStyle color. I'll do that — generate 'brick'+i.

Background: I'll draw static graphics directly (grid lines) rather than texture.

Ball trail: keep last N positions and draw small circles with decreasing alpha in a Graphics each frame during playing. Nice, cheap. I'll include it.

Code the update loop:

```js
update(time, delta){
  const dt = Math.min(delta,50)/1000;
  // paddle
  let dir=0; if(left.isDown)dir-=1; if(right.isDown)dir+=1;
  if(dir!==0){ this.paddle.x += dir*PADDLE_SPEED*dt; this.pointerActive=false;}
  clamp;
  if(state==='ready'){ ball.setPosition(paddle.x, paddle.y - PADDLE_H/2 - BALL_R - 1); trail push }
  else if(state==='playing'){ substep move; check out of bounds; }
  trail update, graphics redraw
}
```

Pointer: set paddle.x directly on pointermove (and mark pointerActive so keys override next move — actually keys set dir and override; fine).

Trail: array of {x,y}; push each frame; draw up to 12 with alpha.

HUD texts: score, lives, state message.

Let me write now. Also include a visible HTML "Launch" button? Requirement says visible Launch control — in-game Phaser button qualifies. I'll also add an HTML button below the canvas wired via window.game event or custom event. Simpler: only in-game button + Space. I'll make in-game button clearly visible (center bottom during ready). Plus restart button visible always? I'll show restart button only in won/lost states plus a small "Restart" always at top? Let's have "RESTART" button top-right area? HUD lives top-right. I'll place restart button at top center-ish small. Keep: top bar: SCORE left, TITLE center, LIVES right. Buttons: LAUNCH appears center-bottom when ready; RESTART appears in won/lost states center-bottom. Also R key always restarts.

Hmm "Restart restores all bricks, score, and lives" — keyboard R suffices, but a visible button in end states is good. I'll also add a persistent small "R: Restart" hint in controls text.

Write the file.

For interactivity of buttons with keyboard space: add keyboard key SPACE (JustDown) -> launch if ready; R (JustDown) -> restart.

Also prevent page scroll on space: add keyboard.addCapture('SPACE,LEFT,RIGHT,UP,DOWN').

Let me write it.

Beep audio: implement `beep(freq, dur, type)` with AudioContext created lazily on first user input. Add small sound toggle? Skip toggle; keep sounds quiet. Actually risk: autoplay policy — created on user gesture (space/click) it works. If created later without gesture, it may be suspended; wrap in try/catch. Fine.

Now write.

Let me quickly write index.html with the game, then verify in browser briefly.

Plan: Phaser 3 game, 800x600 canvas. Use arcade physics or manual movement. Simpler: manual movement with update loop, but brick collision detection manually. Actually using arcade physics with group and overlap is straightforward.

Let me write it.

Key elements:
- Graphics-generated textures: paddle, ball, brick (or use rectangles via Graphics each frame — simpler to generate textures).
- Ball resting on paddle in "ready" state; Space or Launch button starts.
- Paddle moved with arrows/A/D or mouse.
- Lives, score, win/lose, restart button.

Implementation with Arcade physics:

```js
const config = { type: Phaser.AUTO, width: 800, height: 600, parent, physics: {default:'arcade'}, scene: Game };
```

In create: generate textures via this.textures.createGraphics or graphics.generateTexture.

Ball: circle radius 8, texture 'ball'.
Paddle: 120x18 rounded rect texture.
Brick: 64x24.

Bricks group: this.bricks = this.physics.add.staticGroup(); create bricks with texture per row color — generate multiple brick textures brick0..brick5.

Ball physics: body.setCollideWorldBounds(true), bounce 1. World bounds with bottom not colliding — actually set collideWorldBounds with custom check: use physics.world.setBounds(0,0,W,H) but ball falling below paddle costs life. So don't collide ball with bottom: set ball body.setBoundsRectangle? Simplest: check in update if ball.y > H+20 -> lose life.

Paddle: use physics static image or plain image with manual x control. Use a regular image and clamp x within [halfW, W-halfW].

Ball resting: while state==='ready', ball.setPosition(paddle.x, paddle.y - h/2 - ballR).

Launch: set velocity random angle upward.

Collisions:
- physics.add.collider(ball, paddle, hitPaddle) — set velocity based on hit offset: vx = offset * speed, vy = -|vy|.
- physics.add.overlap(ball, bricks, hitBrick) — brick.destroy(), score += 10. To make sure only one brick per hit, overlap handles it; each brick removed once since destroyed.

Actually with staticGroup overlap, ball passes through. To bounce off brick too, could reflect vy. Requirement: "Hitting a brick removes it and increases the score once." Bounce direction change required on contact — "Check that contact changes the ball direction" likely refers to paddle/wall. I'll also invert vy on brick hit for feel.

Prevent ball too horizontal: clamp in update, if |vy| < 60, push.

Also prevent infinite horizontal: clamp vy min.

UI: score, lives text, controls text, Launch button ( Phaser text with setInteractive ), Restart button on win/over.

States: 'ready', 'playing', 'win', 'over'.

Lives: 3. On fall: lives--, if 0 -> game over else back to ready.

Restart: reset bricks (recreate group), score 0, lives 3, state ready.

Mouse: pointermove sets paddle x = clamp(pointer.x). Also keyboard.

Space key launches.

Ball speed: 340.

Let's write file, then verify with browser.

Brick layout: 10 columns x 5 rows, brick 68x24 with gap... width 800, margin 30 each side -> 740 for 10 cols => 74 each, use brick width 66, spacing 74. Rows start y=60.

Let me write.

For brick textures colors: generate 5 colors.

Ball trail not needed.

Also need "visible Launch control" — a button text "Launch (Space)" that's clickable.

Write code carefully.

```js
class Game extends Phaser.Scene {
  constructor(){ super('game'); }
  create(){
    this.W = 800; this.H = 600;
    this.makeTextures();
    // walls visual via graphics
    this.add.graphics ... draw border.
    this.score=0; this.lives=3; this.state='ready';
    this.scoreText = this.add.text(...)
    this.livesText
    this.infoText
    this.paddle = this.add.image(this.W/2, 560, 'paddle');
    this.ball = this.physics.add.image(...,'ball');
    this.ball.body.setCircle(8);
    this.ball.setBounce(1);
    this.ball.setCollideWorldBounds(true); // with bottom? world bounds collide all sides
```

Problem: setCollideWorldBounds bounces off bottom too, preventing fall. Instead don't use collideWorldBounds; handle left/right/top bounce manually in update:

```js
if(b.x < r) { b.x=r; b.body.velocity.x = Math.abs(vx); }
```
Or use physics.world.checkBounds? Manual is fine.

Actually simpler: set world bounds and collideWorldBounds true, but set body bottom limit beyond screen: ball.body.setCollideWorldBounds(true) uses world bounds. We can do `this.physics.world.setBounds(0,0,W,H+400)`? Then bottom at H+400, ball falls off screen at H+... but we detect loss when y > H+20 before reaching. But paddle at 560, H=600. Detect y > 620 -> lose. World bottom 1000 so ball never bounces bottom in practice. But left/right/top bounce works. That works. However world.setBounds also affects... only bodies with collideWorldBounds. Good. But camera? setBounds only physics. Also should make ball not collide with bottom edge at H+400 — irrelevant.

Hmm but with world height 1000, other things fine.

Actually careful: when ball falls we destroy/reset it quickly at y>620. Fine.

Brick collision: physics.add.overlap(this.ball, this.bricks, (ball, brick)=>{...}).

Static group bricks with body; ball bounces? overlap doesn't bounce. I'll manually flip vy: this.ball.body.velocity.y *= -1 — but if ball hits side of brick, flipping y still ok-ish. Fine.

Also to avoid multiple flips per frame for adjacent bricks: after destroying a brick, ball moves; risk of hitting two bricks in one frame flipping twice = no change. Minor. To reduce: only flip if velocity changed... simpler: track lastBrickFlip time, flip only if time - last > 50ms? Eh. Alternatively flip y once per "collision event" using a flag reset each frame. I'll do: in hitBrick, if(!this._flippedThisFrame){ vel.y*=-1; this._flippedThisFrame=true; } and reset at start of update. Good.

Score once: destroy brick so no repeat.

Paddle hit: compute offset = (ball.x - paddle.x)/(paddleW/2), clamp -1..1; speed = 340; vx = offset*speed*0.75; vy = -sqrt(speed^2 - vx^2). Ensure |vy| >= 150: if too small, adjust.

Also enforce min upward: in update, if state playing and |vy|<120, scale.

Ensure ball always moves: if speed near 0.

Controls text: "←/→ or move mouse: move paddle · Space / Launch: start ball · P: pause? (not needed)".

Launch button: this.add.text(...).setInteractive().on('pointerdown', ()=>this.launch()).

Restart button appears on win/over: this.add.text('Play Again').setInteractive.

Reset function rebuilds bricks: bricks.clear(true,true) then create.

Let me now write the full file.

Mouse control: input.on('pointermove', p => if in scene paddle.x = clamp(p.x)). Also pointer active for touch: also handle pointerdown? pointerdown on canvas used by launch button; also could launch on pointer down on playfield. Keep simple: mouse move only, plus button.

Paddle clamp in update: keyboard also.

Write it.

Textures:
```js
makeTextures(){
  const g = this.make.graphics({add:false});
  // paddle
  g.clear(); g.fillStyle(0x4fc3f7); g.fillRoundedRect(0,0,120,18,9); g.generateTexture('paddle',120,18);
  g.clear(); g.fillStyle(0xffffff); g.fillCircle(8,8,8); g.generateTexture('ball',16,16);
  colors rows...
  for(i..){ g.clear(); g.fillStyle(c); g.fillRect(0,0,66,24); g.fillStyle(0xffffff,0.25); g.fillRect(0,0,66,4); g.generateTexture('brick'+i,66,24);}
  g.clear(); ... border? draw walls with graphics directly.
}
```
Note Phaser 3: this.make.graphics({add:false}) then generateTexture works; need g.destroy? fine.

Careful: graphics.generateTexture keys must not already exist on restart; guard with if(!this.textures.exists(...)).

Ball body: physics image with texture 16x16; setCircle(8,0,0).

Now the code.

Also "Show the controls" — text at bottom or top.

HUD layout: score top-left, lives top-right, controls at bottom (y=590?) paddle at 560... Put controls text at top y=8 under header? Let's put HUD bar at top: score (10,10), lives right (790,10) with setOrigin(1,0), controls at bottom center y=584, paddle y=552, bricks rows from y=70.

Wait ball falls below paddle at y>610 -> lose. Controls text at 584 visible always. OK.

Let me write.

Now verify in browser. Concerns:
1. collider with paddle — paddle is a regular image (no physics body). Need paddle to be a physics body. `this.add.image` has no body. I should use `this.physics.add.image` with immovable/static, or add body via this.physics.add.existing(paddle, true). Fix: use this.physics.add.existing(this.paddle, true) — static body. But then moving x needs body update: static body doesn't auto-move with image position unless we call body.updateFromGameObject(). Actually in Arcade, static bodies don't follow the game object. Simpler: make paddle a dynamic body with immovable=true, allowGravity=false, moves=false? If moves=false, body won't update position either... For dynamic bodies, position updates from gameObject in preUpdate if body.moves is true. Alternative: set paddle as dynamic, setImmovable(true), setAllowGravity(false), setVelocityX(0), and body.moves = true (default) — then body follows game object, and velocity 0 keeps it. But ball collision with immovable paddle: paddle dynamic immovable works with collider.

Actually simpler: keep paddle as physics image with moves default true, allowGravity false, immovable true, and never set velocity — body position syncs from game object each frame. Let's do that.

2. Also collider between ball and paddle — ball has bounce 1, ok.

3. Ball collideWorldBounds with world bottom at H+600 — fine; we detect y > PADDLE_Y+70 = 622 before that.

4. overlap with staticGroup: brick created via this.bricks.create gives static body; ok.

5. restart: bricks.clear(true,true) destroys children; overlap with group — the collider/overlap manager stores the group reference, and group children change; Arcade collider checks group children each tick? Collider uses groups's children at collision processing time — for groups, `collider` registers the group object and iterates children each update (it uses children arrays). Actually Arcade Collider handles GameObject arrays/groups by capturing `object2` as the group and calling `this.scene.physics.overlapRect` ... hmm. In Phaser 3, when you pass a Group to collider, it iterates current children each frame (it uses `object2.children` via `getChildren`?). I recall the collider processes based on children at the time... Let me check: Phaser's `Collider` stores objects; in update it calls `this.scene.physics.overlap(this.object1, this.object2, ...)`. World.collideObjects handles Group by iterating its current children. So restart works without re-registering. My extra re-registration creates duplicate overlap callbacks → double score! Because both handlers fire on the same brick: first destroys brick, second sees !brick.active returns. My guard `if (!brick || !brick.active) return;` protects. But destroy is async-ish; disableBody sets active false immediately. Safe. Still, cleaner to not re-register. I'll remove the re-registration line.

6. `angle` unused variable in launch — remove.

7. Ball resting: body.moves=false means body doesn't update from game object, so setPosition on the image won't move body → collider uses body position. Setting ball.position manually while body.moves false: body stays where it was. Problem! For resting, better to keep body.moves=true and setVelocity(0,0). Then body follows game object. Let's restBall: setVelocity(0,0), setPosition(...), body.moves = true always. And in endGame, setVelocity(0,0) keeps it still (body moves but velocity 0). Fine. So remove `body.moves=false` usage; keep velocity 0.

Wait: with body.moves true and velocity 0, ball won't fall (no gravity). Good.

8. Paddle body collision requires paddle body; if I keep paddle as plain image, collider will fail (collider requires bodies; Phaser will throw? It might log error "object1/body2 invalid"). Let's convert paddle to physics image.

Also paddle body for static? I'll use `this.paddle = this.physics.add.image(...)` then setImmovable(true), setAllowGravity(false), setVelocity(0,0). Dynamic body with moves true follows game object.

Hmm but when paddle moves fast (mouse), dynamic body follows game object each frame — yes, Arcade syncs body position from game object in `Body.preUpdate` when moves && !paused... Actually Body.preUpdate: if this.gameObject ... it updates position from game object only if `moves` is true? Let me recall Phaser 3 Body.preUpdate: 

```
if (this.moves) { ... this.position.x = gameObject.x - ...; }
```
Hmm, actually preUpdate does: `this.transform.x` sync — yes, for dynamic bodies with moves=true, the body follows the game object, then integration applies velocity. Good.

But careful: setImmovable(true) plus ball collider: paddle won't be pushed. Ball bounce: with bounce 1 ball reflects.

Also: does dynamic body with velocity 0 stay synced? yes.

9. `this.ball.body.setCollideWorldBounds(true)` and paddle collideWorldBounds true — paddle clamp manual anyway.

10. Potential issue: collider ball-paddle uses `this.paddle` body — ok now.

11. `this.make.graphics({add:false})` then g.destroy() — ok.

12. overlap callback signature (ball, brick) fine.

13. When win/over, ball may be behind overlay; fine.

14. On loseLife while ball below: restBall sets position on paddle.

Let me apply edits then test in browser.

Also remove the re-registration line in restart to avoid duplicate overlap.

Wait — restart with a new group: the overlap was registered with `this.bricks` group object which persists (we clear and repopulate the same group), so overlap still iterates the group. Good.

Now test in browser.

No body.moves references left (exit 1 from grep no match). Now run browser.

No curl. The browser tool probably loads file directly? Let's just use browser action reload/screenshot — the harness likely serves index.html itself.

Just use the browser tool with reload/screenshot on index.html (harness presumably serves cwd).

My hacky check fails. Just check syntax by extracting the inline script and using `new Function` without executing.

Now browser test. The browser tool runs index.html presumably from cwd. Let's reload and inspect.