Top-down alien shooter · laguna-s-2.1

Let me start by understanding the environment and the Phaser library available.

Let me check the Phaser version and a bit about its API.

Let me check what version of Phaser this is by searching for version info more specifically.

This is Phaser 3.80.1. Good, that's a recent version with full API support. Now let me build the game.

Let me plan the structure:

1. **Game config**: Top-down shooter, using Arcade physics
2. **Player**: 
   - WASD movement
   - Aim toward mouse pointer
   - Fire with left mouse button
   - Display controls on screen
3. **Aliens**: 
   - First wave advancing toward player
   - Damaged by player shots
   - Contact damages player
4. **HUD**: Health, score, wave number
5. **Waves**: Increase difficulty after clearing
6. **Game over**: At zero health, show game over with Restart
7. **Graphics**: All procedural via Phaser Graphics or generated textures

Let me think about the implementation:

**Scene structure:**
- `BootScene` - maybe just one main scene
- `GameScene` - main gameplay
- `GameOverScene` - game over state

Actually, I'll keep it simpler with a single scene that manages game states, or use multiple scenes. Let me use a single scene for simplicity, but Phaser scenes make state management cleaner. Actually let me use a single GameScene that handles everything including game over and restart.

Let me think about the design:

**Player:**
- Position in center of arena
- Sprites: player ship/tank (procedural graphics)
- Movement: WASD - I'll use cursor keys mapping W->up, A->left, S->down, D->right
- Aiming: rotate a weapon/aim indicator toward mouse pointer
- Firing: left mouse button, create projectile traveling toward pointer

For aiming toward mouse pointer, I'll use `this.input.activePointer` to get the angle, and rotate the player's weapon, then fire projectiles along that angle.

**Aliens:**
- Spawned around the edges of the arena
- Move toward player using physics velocity
- Health bars or visual damage feedback

**Projectiles:**
- Travel toward pointer
- On hit with alien, damage alien, with visual feedback (particles or tint flash)

**Waves:**
- Wave 1: some number of aliens
- After clearing, wave +1, increase count or speed

**Game over:**
- When health reaches 0
- Show overlay with Restart button

**Graphics (procedural):**
- Player: a generated texture (circle or triangle shape)
- Aliens: another generated texture
- Projectiles: small circle
- Explosions: particle emitter or graphics

Let me use `generateTexture` / graphics to create textures, or use `this.add.graphics` and `generateTexture`.

Actually, the cleanest approach in Phaser 3 is to use `this.add.graphics().generateTexture()` to create sprites from procedural drawings.

Let me write the code.

For WASD input in Phaser 3, I'll create input keys:
```js
this.cursors = this.input.keyboard.addKeys({
    up: 'W',
    down: 'S',
    left: 'A',
    right: 'D'
});
```

For firing with mouse:
```js
this.input.on('pointerdown', (pointer) => {
    if (pointer.leftButtonDown()) {
        this.fire();
    }
});
```

For aiming toward mouse:
```js
const pointer = this.input.activePointer;
const angle = Phaser.Math.Angle.Between(player.x, player.y, pointer.worldX, pointer.worldY);
weapon.rotation = angle;
```

Let me think about the arena. Top-down view. I'll create a defined arena area with walls maybe, or just an open arena where aliens come from all sides. Let me make a bounded arena.

Let me design:
- Arena: 1000 x 800 (within the game width/height)
- Player starts at center
- Aliens spawn at random edges and move toward player

Let me define the game config:
```js
const config = {
    type: Phaser.AUTO,
    width: 1000,
    height: 800,
    backgroundColor: '#1a1a2e',
    parent: 'game',
    physics: {
        default: 'arcade',
        arcade: {
            debug: false,
            gravity: { y: 0 }
        }
    },
    scene: [GameScene]
};
```

Now let me write the full code. Let me be careful about Phaser 3.80.1 API.

Key considerations:
- `generateTexture` from graphics
- Tween for damage flash
- Particle emitter for explosions (or just use graphics-based explosions)
- Text objects for HUD

Let me think about player movement with WASD - I want smooth movement. I'll use velocity on the arcade body.

Aiming: The player should aim toward mouse. I'll have the player sprite rotate its "gun" (a separate sprite or the player itself rotates). Let me have a tank-like player where the body faces the direction of movement and a gun turret aims at the mouse.

Actually, simpler: the player is a ship that rotates to aim at the mouse. Movement is WASD (strafe or forward). Let me make it a top-down shooter where the player can move in any direction (like a twin-stick-ish but with mouse aim).

Let me keep it classic: player moves with WASD (4-direction or 8-direction), and a weapon/gun aims toward mouse and fires.

Let me make the player a tank:
- Body that moves with WASD
- Turret that rotates toward mouse
- Fire from turret

Let me write the procedural textures:

Player tank (procedural):
- Draw a rectangle/tank body
- Draw a turret line

Player ship (procedural):
- Draw a triangle pointing up
- Draw a gun

Let me go with a spaceship aesthetic since the task says "alien shooter".

Player ship: a triangular ship with a gun turret that aims at mouse.

Let me now write everything.

For damage feedback:
- When an alien is hit, flash tint or create explosion
- When player is hit, flash red

For explosions, I'll use a particle emitter or just animate a growing circle that fades. Particles might be simpler with `this.add.particles`. Let me use a particle emitter with a generated texture.

Actually, let me keep it lean but functional. Let me use:
- Damage flash (tint) for hits
- A simple explosion effect using graphics that expands and fades, or particles

Let me write the code now. I'll create the full index.html.

Let me think about the structure more carefully to make it robust:

```js
class GameScene extends Phaser.Scene {
    constructor() {
        super({ key: 'GameScene' });
    }
    
    preload() {
        // Generate textures procedurally
    }
    
    create() {
        // Setup player, input, HUD, first wave
        this.setupGame();
    }
    
    setupGame() {
        this.player = ...;
        this.score = 0;
        this.health = 3;
        this.wave = 1;
        this.aliens = [];
        this.projectiles = ...;
        this.spawnWave();
    }
    
    spawnWave() {
        const count = ...;
        // spawn aliens
    }
    
    update() {
        // handle movement, aiming, firing
    }
}
```

For game over, I'll add an overlay within the same scene rather than switching scenes, since restart is easier. Actually, switching to a GameOverScene and back is also clean. But to keep restart restoring everything, I'll manage game state within the scene. Let me use an overlay approach: when health <= 0, pause gameplay and show a game over overlay with a Restart button.

Actually, the cleanest with Phaser is to have separate scenes. But restart "restores health, score, and the first wave" — I can just re-initialize the game state. Let me use a single scene with a game state flag. When game over, set `this.isGameOver = true` and show overlay. On restart, reset state.

Let me write it.

For the procedural textures, I'll generate them in `create` or `preload`. I can use graphics to generate textures. Let me use `this.add.graphics()` then `.generateTexture('name', w, h)`. Note that `generateTexture` requires the graphics to be added. Actually in Phaser 3, you can do:

```js
const gfx = this.make.graphics({ x: 0, y: 0, add: false });
gfx.fillStyle(0xff0000);
gfx.fillCircle(16, 16, 16);
gfx.generateTexture('player', 32, 32);
```

Then use `this.add.image(x, y, 'player')`.

Wait, `generateTexture` on a Graphics object — yes, in Phaser 3, Graphics objects have a `generateTexture` method. Let me confirm. Yes: `graphics.generateTexture(key, width, height)`.

Let me write all the textures:
- `player_ship`: triangle ship
- `alien_ship`: different colored shape
- `projectile`: small circle
- `explosion`: particle texture (a circle)

For the explosion, I'll use a particle emitter:
```js
this.explosions = this.add.particles('explosion').createEmitter({...});
```

Let me set up the player as a sprite with an Arcade body. I'll use a main player sprite and a separate turret sprite, or just draw the gun on the player sprite and rotate only part... Actually simpler: player sprite + a child turret sprite for aiming.

Let me create two textures:
- `player_base`: the ship body
- `player_turret`: the gun (a rectangle) that rotates toward mouse

And combine them as two sprites (turret as child or separate). Firing happens at the turret tip.

Let me write the code:

```js
// Player
this.player = this.physics.add.sprite(centerX, centerY, 'player_base');
this.player.setDamping(true);
this.player.setDrag(500);
this.player.body.setMaxVelocity(250);

this.turret = this.physics.add.sprite(centerX, centerY, 'player_turret');
this.turret.setOrigin(0.5, 0.8); // pivot at back
```

Hmm, let me make the turret a separate sprite that follows the player and rotates. Let me set origin so it pivots at the player center.

Let me set turret width/height. The turret is a rectangle; I'll set its origin to (0.5, 1) so it pivots at its top-middle (where it attaches to the ship). Then position it at the player center, rotate toward mouse. To find the muzzle position, I use `turret.getRight()` or compute based on rotation.

Actually, let me compute the muzzle point with trig:
```js
const angle = turret.rotation;
const len = turret.width; // length of gun
const muzzleX = turret.x + Math.cos(angle) * len;
const muzzleY = turret.y + Math.sin(angle) * len;
```

Wait, with origin (0.5, 1), the turret's local origin is at top-center. The rotation happens around that point, so the turret extends from the pivot point. Let me just compute muzzle from the pivot (which is at turret.x, turret.y since origin.x=0.5 doesn't shift x, and origin.y=1 shifts the visual up so pivot is at the top). Actually with origin (0.5, 1), the sprite's transform origin is at top-center, so turret.x/turret.y is at the top-center pivot. The gun extends downward from there. Hmm, that means rotation would swing it around top-center.

Let me instead make the turret anchor at the center of the player. I'll make the turret texture a rectangle extending to the right, set origin to (0, 0.5) so it pivots at its left-middle (the center of the player). Then position the turret at the player center. Rotating it swings the gun around the player center. The muzzle is at the right edge: `turret.x + length * cos(angle)`.

Let me create the turret texture as a horizontal rectangle, e.g., width 30, height 8, with origin (0, 0.5). After positioning at player center and rotating toward mouse, muzzle:
```js
const angle = turret.rotation - Math.PI/2 ... 
```

Hmm wait, let me reconsider. The turret texture extends right from origin. If origin is (0,0.5), the left edge is at the pivot (player center). The gun points right by default (angle 0). I rotate so it points at mouse. Then muzzle at angle `turret.rotation` from pivot. Good.

Actually, let me simplify: I'll make the player able to rotate the whole ship toward the mouse for aiming, and move with WASD. That's simpler — no separate turret. The ship points in the direction of the mouse (like a ship that always aims at pointer). Movement is WASD in world directions (strafe). Firing from the front.

Hmm, but that's mixing — ship rotates to aim but moves with WASD in world space. That works for a top-down shooter. Let me do that: the player ship rotates to face the mouse pointer, and WASD moves it. Left mouse fires forward.

But wait — "aim toward the mouse pointer" with WASD movement. A common approach is twin-stick where WASD moves and mouse aims a separate turret. But rotating the whole ship to aim is also fine and simpler visually. Let me go with the separate turret approach for better visuals — it looks more like a shooter. Actually, let me reconsider the complexity/time budget. I have 15 minutes. Let me go with the simpler whole-ship rotation to aim, since it's robust and looks fine.

Hmm, but if the ship rotates to face the mouse, then WASD movement relative to world is fine. Let me think: player clicks/shot toward mouse, ship rotates to face mouse, fires from front. Movement W=up, A=left, S=down, D=right in world space. This is clean.

Actually, let me do the turret approach but keep it robust. It gives a nicer "tank" feel. Let me think about what's most reliable...

Let me go with whole-ship rotation for aiming. Simpler and reliable. The ship points toward the mouse. Fire from the front tip.

Let me reconsider: the requirement says "aim toward the mouse pointer, and fire with the left mouse button." So the aiming is toward the mouse. If I rotate the whole ship, that satisfies it. Good.

But there's a subtlety: if the ship rotates toward the mouse while moving with WASD, the player might feel disoriented, but it's a classic style. Fine.

Actually, you know what, let me do the turret approach — it's more polished and I can handle it. Let me create:
- `player_ship`: triangle pointing up (the hull)
- `player_gun`: a barrel (rectangle) that I attach and rotate

Hmm, attaching two sprites and keeping turret muzzle position... Let me just do whole-ship rotation. It's the most reliable under time pressure. Decision made: whole ship rotates to aim at mouse.

Wait, actually, let me reconsider once more. With whole-ship rotation toward mouse, the firing is from the nose. That's fine. Let me compute the nose/muzzle position:
```js
const radians = player.rotation; // if I set player.rotation = angle to mouse
const muzzleX = player.x + Math.cos(radians) * (player.width/2);
const muzzleY = player.y + Math.sin(radians) * (player.height/2);
```
If the ship triangle points up (angle -PI/2 default), I need to handle the default facing. Let me make the ship triangle point "up" and set a base rotation offset. Hmm, this gets fiddly.

Let me make the player ship texture a triangle pointing to the right (angle 0 in Phaser means pointing right for a triangle drawn at angle 0... actually texture orientation). Let me draw the triangle pointing right. Then `player.rotation` = angle to mouse directly (Phaser rotation 0 = right). Muzzle at `player.x + cos(rotation) * (width/2)`.

OK let me just draw a right-pointing triangle for the player. Good.

Let me now also think: the ship rotates to face mouse, but movement is WASD (world directions). When rotated, moving "W" goes up regardless of ship facing. That's fine.

Let me write the code now. Let me draft it fully.

```html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Alien Shooter</title>
<style>
  html,body { margin:0; padding:0; height:100%; overflow:hidden; background:#000; }
  #game { width:100%; height:100%; }
  .hud { ... }
</style>
</head>
<body>
<script src="phaser.min.js"></script>
<script>
// game code
</script>
</body>
</html>
```

Let me write the full JavaScript. I'll structure with classes/scene.

Let me carefully implement:

```js
const config = {
    type: Phaser.AUTO,
    width: 1000,
    height: 800,
    backgroundColor: '#0d0d1a',
    parent: 'game',
    physics: {
        default: 'arcade',
        arcade: {
            debug: false,
            gravity: { y: 0 }
        }
    },
    scene: {
        init: init,
        preload: preload,
        create: create,
        update: update
    }
};

let game;
let player, turret, cursors, pointer;
let playerBullets;
let aliens;
let alienBullets; // maybe not needed
let score = 0, health = 3, wave = 1;
let scoreText, healthText, waveText;
let gameOver = false;
let waveTextTween;
let explosions;
let fireCooldown = 0;

function init() {}
function preload() {}
function create() {
    // generate textures
    ...
    // setup input
    ...
    // setup player
    ...
    // setup hud
    ...
    // spawn first wave
    ...
}
function update(time, delta) {
    if (gameOver) return;
    updatePlayer();
    updateAiming();
    updateBullets();
    updateAliens();
}
```

Let me think about whether to use functions or class scene. Functions are fine.

Let me think about the textures generation:

```js
function generateTextures() {
    // Player ship (triangle pointing right)
    let gfx = this.add.graphics({x:0,y:0}).setVisible(false);
    // actually use make.graphics to avoid adding to display
    gfx = this.make.graphics({x:0,y:0, add:false});
    gfx.fillStyle(0x4a9fff);
    gfx.fillCircle(...);
    ...
}
```

Let me use `this.make.graphics({ add: false })`.

Wait, `generateTexture` — does `this.make.graphics` produce a Graphics that has `generateTexture`? In Phaser 3, yes, the GameObject Graphics has `.generateTexture()`. Let me confirm the method signature. `graphics.generateTexture({ key, width, height })` or `graphics.generateTexture(key, width, height)`. Both forms work. Let me use the object form to be safe? Actually the array form `generateTexture(key, width, height)` is standard. Let me use positional.

Let me draw:

**Player ship:** A filled triangle + a cockpit. Use beginPath/fill.
```js
gfx.fillStyle(0x4a9fff);
gfx.beginPath();
gfx.moveTo(24, 0);
gfx.lineTo(-16, 10);
gfx.lineTo(-16, -10);
gfx.closePath();
gfx.fill();
```
This makes a right-pointing triangle with the tip at (24,0). Width ~40, height ~20. Good.

**Player gun:** Actually if I rotate the whole ship to aim, no separate gun needed. The nose is at (24,0) relative, so muzzle = ship.x + cos(rotation)*24.

Hmm, but the triangle tip-to-center distance — let me set origin so rotation is centered at the triangle's center. The triangle spans x from -16 to 24, center at (4, 0). Let me set origin to center: I'll make the texture 40x24 and draw with the geometric center. Let me recompute: triangle points (24,0), (-16,10), (-16,-10). Bounding box: x[-16,24], y[-10,10]. Center (4,0). To center origin, I'd set the sprite origin to (4/40, 0.5) = (0.1, 0.5). That's messy.

Simpler: draw the triangle symmetric around origin. Tip at (16,0), base at (-16, ±10). Then texture 32x20 with default origin (0.5,0.5) centered at (0,0) local. Wait the sprite's local (0,0) in display is center with origin 0.5. The texture's center is (16, 16) if texture is 32 wide... no. Let me just make the texture and set origin to (0.5,0.5) (default), so the sprite's position is at the texture center. Draw triangle symmetric around the texture center.

Texture 32x24. Center at (16, 12). Draw triangle with tip at (28, 12) (right-ish), and base from (6, 4) to (6, 20). Hmm let me just make a simpler ship: a triangle pointing right, symmetric around center (16,12):
- tip (28, 12)
- left base (6, 2) — wait symmetric: (6, 6) and (6, 18)
Let me do: tip (28,12), bottom-left (6,18), top-left (6,6). That's a right-pointing triangle, center-ish. The geometric center of this triangle: avg x = (28+6+6)/3 = 13.33, avg y = (12+18+6)/3 = 12. Close enough to (16,12) but not exact. For rotation it doesn't need to be perfect.

Actually, to keep rotation nice, let me center the triangle exactly. Let me make a symmetric triangle around origin conceptually:
Points relative to center: tip (14, 0), left ( -8, -6), right? no. Triangle: tip (14,0), base-left (-8,-6), base-right(-8,6)? That's pointing right. Symmetric about x-axis. Center at origin (0,0). 

In texture space with texture 28x12, center at (14,6). Tip at (14+14, 6) = (28,6)? Let me just draw in texture coordinates centered. Texture 32x16, center (16,8). Draw:
- tip: (30, 8)
- base left: (6, 4)
- base right: (6, 12)
This triangle's centroid: ((30+6+6)/3, (8+4+12)/3) = (14, 8). Texture center (16,8). Close. Good enough; rotation pivot = sprite center = texture center (16,8). The ship will rotate around (16,8) which is slightly off the visual centroid but fine.

The muzzle (nose) is at x=30, y=8 in texture = (30-16, 8-8) = (14, 0) relative to center. So with origin (0.5,0.5), the nose is at distance 14 from center along the facing direction. When rotation = angle to mouse, muzzle world = player.x + cos(angle)*14, player.y + sin(angle)*14. 

For a triangle pointing right at rotation 0, the nose points right. Phaser rotation 0 points right. So `player.rotation = angleToMouse` makes the nose point at the mouse. 

Let me set the player ship: after creating `player = physics.add.sprite(...)`. Then `player.setOrigin(0.5,0.5)`. rotation via `angle = Phaser.Math.Rad = ...`.

**Alien ship:** A different shape, e.g., a circle or a squid-like blob. Let me draw a greenish alien: a circle with a couple of points. Or simpler: an orange/green asymmetric shape. Let me draw a filled circle with spikes. Keep simple: a circle of radius ~14 with a dark outline, color green. Muzzle not needed (they don't aim, they advance toward player).

Actually aliens just advance toward the player, no aiming needed. Let me give them a distinct look — a purple blob with points.

```js
gfx.fillStyle(0xa020f0);
gfx.fillCircle(16, 16, 14);
```
Texture 32x32. Simple circle alien. Add an outline:
```js
gfx.lineStyle(2, 0x551a8c);
gfx.strokeCircle(16,16,14);
```

Hmm, let me give aliens a bit more character: a circle with a couple of triangular spikes on top. But keep it simple for time. A circle is fine.

Let me make aliens look like a classic alien gray with big eyes... that's a lot of detail. Let me do a simple alien: green circle with two small black dots for eyes. Actually, let me make a stylized alien: a circle with 4 triangular points around (like a star). Keep simple.

Let me draw the alien as a filled orange circle with a darker outline. Distinct from player (blue). Good enough.

**Projectile:** small white circle, radius 4.
```js
gfx.fillStyle(0xffff88);
gfx.fillCircle(8,8,4);
```
Texture 16x16.

**Explosion particle:** a white circle, used for particle emitter.
```js
gfx.fillStyle(0xffcc00);
gfx.fillCircle(8,8,6);
```

Now, the player bullets: I'll use an Arcade group / physics group for bullets. Bullets travel at fixed speed toward the aiming direction. They collide with aliens.

```js
playerBullets = this.physics.add.group({
    defaultKey: 'projectile',
    maxSize: 50,
    runChildUpdate: false
});
```
Hmm, `defaultKey` requires the texture to be loaded. Since I generate textures in create, the key exists. Let me create bullets with `this.physics.get(...)`.

Actually, simpler: manage bullets as an array of sprites in an Arcade physics group, and handle overlap with aliens.

Let me use:
```js
this.projectiles = this.physics.add.group({
    defaultKey: 'projectile',
    maxSize: 30
});
this.physics.add.collider(this.projectiles, this.aliens, hitAlien, null, this);
```

Wait, collider vs overlap. For hitscan-like, use overlap. I'll use overlap so projectiles pass through (or destroy on hit). Let me use overlap and destroy both.

Actually, a projectile hitting an alien should destroy the projectile and damage the alien. Use overlap.

```js
this.physics.add.overlap(this.projectiles, this.aliens, onBulletAlien, null, this);
```

For aliens advancing: I set each alien's velocity toward the player each frame, or use `moveTo`. Using `body.velocity` set toward player each update is robust. But if I set velocity each frame, it overrides. For advancing aliens, let me compute direction from alien to player and set velocity magnitude based on alien's base speed.

But simpler: I'll give each alien a fixed speed and use `arcade.overlap` with player for contact damage, and set velocity toward player each frame or at spawn. Setting velocity at spawn toward current player position works, but the player moves. For a real "advance toward player," updating each frame is better. But updating each frame for many aliens is fine.

Hmm, but if I set velocity toward player each frame, the aliens home in perfectly. That's the "advance toward the player" behavior. Let me do that but maybe with some noise for variety. Keep simple: each frame, for each alien, compute angle to player and set velocity. Use a small random offset so they don't all move identically? For visual variety, yes. Let me add a tiny random wander.

Actually let me keep it deterministic and simple: aliens move toward player at their speed each frame.

Let me store alien health: each alien is a sprite; I'll track health on the sprite: `alien.health = 2`, `alien.maxHealth = 2`. On hit, decrement; if 0, destroy and spawn explosion + score.

Wave configuration:
- wave 1: e.g., 8 aliens, speed 60
- each wave: increase count by 3 and speed by 10
```js
const alienCount = 8 + (wave - 1) * 3;
const alienSpeed = 50 + (wave - 1) * 15;
```

Health display: health as hearts or a number. Let me show a bar or hearts. Hearts: draw 3 heart icons. Or a numeric health with a bar. Let me do a health bar + numeric.

Let me keep HUD simple: Text showing "SCORE: 0", "WAVE: 1", and a health bar (or hearts text "HEALTH: ♥♥♥"). Use HTML/CSS overlay? I could overlay HTML elements for HUD, but Phaser text is fine and keeps it in-canvas. Let me use Phaser text + a graphics health bar.

Let me show health as 3 hearts (using text characters ♡/♥) or a red bar.

I'll draw a health bar at top-left and text for score/wave at top.

Let me also add a control hint overlay (HTML or canvas text). The requirement: "Display the controls on screen." I'll add text: "MOVE: WASD  AIM: MOUSE  FIRE: LEFT CLICK" at the bottom or top.

Let me put controls text at the bottom-center.

Game over overlay: a semi-transparent rectangle + "GAME OVER" text + "SCORE: X" + "RESTART" button (a text or graphics button).

For the restart button, I'll make it a Phaser text with interactive (setInteractive + on('pointerdown')). On click, reset game state.

Let me implement the game-over as an overlay within the scene (not a separate scene). When health <= 0:
- set gameOver = true
- stop alien movement
- show overlay graphics/text

On restart:
- reset health, score, wave
- destroy all aliens, projectiles, player
- hide overlay
- recreate player, spawn wave 1
- set gameOver = false

Let me write a `resetGame()` function.

Now let me think about timing/cooldown for firing. Add a fire rate (e.g., 200ms between shots) for balance. Use fireCooldown timer.

Let me write the updatePlayer:
```js
function updatePlayer() {
    const speed = 200;
    player.body.setAcceleration(0);
    if (cursors.left.isDown) player.body.setVelocityX(-speed);
    ... hmm, setVelocity vs acceleration
}
```
Using `setVelocity` directly with WASD: if both up and left, the velocity would be applied twice (setVelocityX then setVelocityY), fine since they're separate axes. But `setVelocityX` and `setVelocityY` — if I set each based on key, diagonal movement has magnitude sqrt(2)*speed unless I cap. With `setMaxVelocity`, arcade caps the magnitude. Let me use setAcceleration with drag for smooth movement, or just setVelocity and clamp.

Let me use a clean approach:
```js
const moveSpeed = 200;
player.body.setVelocity(0);
if (cursors.left.isDown) player.body.velocity.x -= moveSpeed;
if (cursors.right.isDown) player.body.velocity.x += moveSpeed;
if (cursors.up.isDown) player.body.velocity.y -= moveSpeed;
if (cursors.down.isDown) player.body.velocity.y += moveDown;
```
This caps each axis to moveSpeed, and diagonal = sqrt(2)*moveSpeed but maxVelocity caps it. Set `player.body.setMaxVelocity(moveSpeed)`. Good. Actually maxVelocity caps total magnitude, so diagonal would be capped at moveSpeed, meaning slower diagonal. Acceptable. Or set maxVelocity = moveSpeed * 1.4 to allow full diagonal. Let me set maxVelocity = moveSpeed. Fine.

Let me use `this.input.keyboard.addKeys` for WASD. Need to avoid conflict with default W/A/S/D? There's no default. Fine. Also prevent browser context menu on right-click? Not needed since only left click.

For aiming:
```js
const pointer = this.input.activePointer;
const angle = Phaser.Math.Angle.Between(player.x, player.y, pointer.worldX, pointer.worldY);
player.rotation = angle;
```
But this is in update(), and activePointer.worldX is the pointer position in world. Good. However, if the pointer is at the player position, angle is undefined → set to 0. `Angle.Between` returns 0 if same? Actually returns NaN if equal. Let me guard: if pointer.equals... just set rotation only when not at same position. Or default 0. `Phaser.Math.Angle.Between` handles equal by returning 0 I think; but to be safe, check distance.

Actually `Angle.Between(x1,y1,x2,y2)` computes atan2(dy,dx). If dx=dy=0, atan2(0,0)=0. So returns 0. Good, no NaN.

For firing:
```js
this.input.on('pointerdown', (ptr) => {
    if (ptr.leftButtonDown() && !gameOver) {
        fireProjectile();
    }
});
```
But this fires on mousedown; holding might repeatedly fire? pointerdown fires once per press typically (on the down event). Actually the 'pointerdown' event fires once per button press. To allow rapid fire, I'll handle in update() checking if pointer.isDown and cooldown elapsed. Let me do firing in update for control:

```js
if (this.input.activePointer.isDown && this.input.activePointer.leftButton().isDown) {
    if (fireCooldown <= 0) {
        fireProjectile();
        fireCooldown = 200;
    }
}
if (fireCooldown > 0) fireCooldown -= delta;
```

Hmm `leftButton()` returns a Button object with isDown. Actually `pointer.leftButton` is deprecated? In Phaser 3, `pointer.leftButtonDown()` is a method returning boolean whether left button was pressed this frame? No. Let me use `this.input.activePointer.leftButtonDown()` — actually the method is `pointer.leftButton` (property) deprecated, use `this.input.manager` ... Let me just use: in the pointerdown listener with `if (pointer.leftButtonDown())`. Actually `leftButtonDown()` checks if the left button is currently held down at the time of the event. The 'pointerdown' event already indicates a down. Let me just use pointerdown event and check it's left button.

Simplest robust: use pointerdown event, fire once per click, no cooldown needed (or short). But that limits fire rate to click speed. For an arcade shooter, a fire rate cooldown controlled in update is better. Let me do:

In update:
```js
const ptr = this.input.activePointer;
if (ptr.isDown && fireCooldown <= 0) {
    // left button check
    if (ptr.leftButtonDown()) {
        fireProjectile();
        fireCooldown = 180;
    }
}
```

`ptr.leftButtonDown()` — In Phaser 3.80, the method `leftButtonDown()` exists on Pointer and returns true if the left button is currently down. Let me verify the API. Phaser.Pointer has methods: `leftButtonDown()`, `rightButtonDown()`, `middleButtonDown()`. Yes these exist (deprecated alias `leftButton` but `leftButtonDown()` method works). Good.

Actually, I recall `leftButtonDown()` checks the button state. Let me use it.

Let me handle fire by listening to pointerdown AND holding with cooldown. I'll do cooldown in update using activePointer.isDown + leftButtonDown().

Hmm, but `isDown` is true for any button. Combine with leftButtonDown(). Good.

Let me write fireProjectile:
```js
function fireProjectile() {
    const angle = player.rotation;
    const muzzleX = player.x + Math.cos(angle) * 16;
    const muzzleY = player.y + Math.sin(angle) * 16;
    const speed = 500;
    const proj = this.physics.get(muzzleX, muzzleY, 'projectile');
    proj.setVelocity(Math.cos(angle) * speed, Math.sin(angle) * speed);
    proj.setLife?. ; 
    proj.setRotation(angle);
    // destroy when out of bounds
    proj.body.onWorldBounds = ... 
    // add to group for overlap handling
    this.projectiles.add(proj);
}
```

`this.physics.get(x, y, key)` creates an ArcadeSprite that's not in worldbounds check. Let me create via `this.physics.add.existing`? Simpler: use the group's get method:
```js
const proj = this.projectiles.get(muzzleX, muzzleY, 'projectile');
if (proj) {
    proj.enableBody(...);
    ...
}
```
Group.get returns an existing unused body or creates new up to maxSize. Let me use a standard approach with a bullet group.

Actually, the cleanest: create a projectile as `this.physics.add.sprite(muzzleX, muzzleY, 'projectile')` and manage a list to clean up. For collision, use `overlap` with the aliens group. Let me use a physics group for projectiles and a group for aliens.

Let me use:
```js
this.projectiles = this.physics.add.group({
    defaultKey: 'projectile',
    maxSize: 100,
    createCallback: function() { ... }  // no texture needed since defaultKey
});
```
Hmm, with `defaultKey` in create config, `group.get(x,y)` creates a sprite with that texture. Let me verify: `this.physics.add.group({ defaultKey: 'key', maxSize: n })` then `group.get(x, y)` returns a sprite using defaultKey. Yes.

Actually, I recall the Arcade Physics group `get` signature: `group.get(x, y, key, frame)` or with config `defaultKey`. If defaultKey set, `group.get(x,y)` works. Let me use that.

For cleanup, set `proj.body.setAllowGravity(false)` (gravity is 0 anyway), and check world bounds to destroy:
```js
proj.body.onWorldBounds = true;
proj.body.outOfBoundsKill = true;  // hmm outOfBoundsKill requires worldbounds check
```
Setting `worldBounds` on the physics world. Let me set `this.physics.world.setBoundsCollision(true, true, true, true)` and world size. Default world size = game size, so projectiles leaving screen get killed if outOfBoundsKill. Let me set on each proj: `proj.body.setCollideWorldBounds(false); proj.body.outOfBoundsKill = true;` Wait, outOfBoundsKill destroys the sprite when it goes out of world bounds. Need `this.physics.world.on('worldbounds', ...)` or the body's own check. outOfBoundsKill works via the body checking each frame against world bounds. Let me set `this.projectiles` children or each projectile: `proj.body.outOfBoundsKill = true;` Actually that property exists on Arcade.Body. Good. Also need to make sure world bounds exist (they do by default = game dimensions).

Hmm, but projectiles might also be destroyed on hit. I'll destroy on hit too.

Let me also give projectiles a `setTexture` and a lifespan as fallback.

Let me set projectile lifespan:
```js
proj.setDepth(5);
proj.body.setAllowGravity(false);
proj.body.outOfBoundsKill = true;
proj.body.checkWorldBounds = true;
```
Good.

Now alien spawning:
```js
function spawnWave() {
    const count = 8 + (wave-1)*3;
    const speed = 50 + (wave-1)*15;
    for (let i=0;i<count;i++){
        // spawn at a random edge
        const side = Phaser.Math.Between(0,3);
        let x, y;
        const margin = 30;
        if (side===0) { x = -margin; y = Phaser.Math.FloatBetween(0.1,0.9)*arenaHeight; }
        ... 
    }
}
```
Let me spawn around the arena perimeter. Use the game dimensions as arena. Spawn at edges (top/bottom/left/right) outside or at edges.

Let me define arena bounds = game bounds (0,0,1000,800). Spawn at edges:
```js
const side = Phaser.Math.Between(0,3);
let px, py;
if (side === 0) { px = -20; py = random(0, arenaHeight); }
else if (side===1) { px = arenaWidth+20; py=random(0,arenaHeight); }
else if (side===2) { px = random(0, arenaWidth); py = -20; }
else { px = random(0, arenaWidth); py = arenaHeight+20; }
```

Alien creation:
```js
const alien = this.aliens.get(px, py, 'alien');
alien.setActive(true).setVisible(true).setDepth(2);
alien.body.setMaxVelocity(speed);
// but velocity set in update
alien.spawnSpeed = speed;
alien.health = 2;
alien.maxHealth = 2;
```

Aliens group:
```js
this.aliens = this.physics.add.group({
    defaultKey: 'alien',
    defaultFrame: 0,
    maxSize: 60,
    runChildUpdate: true, // if I want per-child update
});
```
Hmm, if I use runChildUpdate, each child's update is called. But I prefer to update aliens in my own loop (iterate the group.getChildren() or an array). Let me NOT use runChildUpdate and instead store aliens in an array and update manually. Actually, using the group's getChildren is fine. Let me keep an array `alienList` for easy iteration, and the physics group for collisions.

Let me maintain:
```js
this.aliens = this.physics.add.group();  // physics group
this.alienList = [];
```
On spawn, push to both. On destroy, splice from list.

Alien update each frame:
```js
for (const alien of this.alienList) {
    if (!alien.active) continue;
    const angle = Phaser.Math.Angle.Between(alien.x, alien.y, player.x, player.y);
    alien.body.setVelocity(Math.cos(angle)*alien.spawnSpeed, Math.sin(angle)*alien.spawnSpeed);
    alien.rotation = angle + Math.PI/2; // point downward? rotate ship
}
```
Actually alien rotation doesn't matter much; let me not rotate aliens, keep them upright/constant. Or rotate to face player for nicety. Let me rotate them to face the player too (minus PI to flip). Eh, keep simple: rotate to face movement direction. For the circle alien, rotation doesn't matter. Let me skip alien rotation.

Alien contact damage to player: overlap player & aliens → player takes damage. I'll use `overlap` (not collide) so they pass through and damage. Use a cooldown to avoid insta-kill.

```js
this.physics.add.overlap(this.player, this.aliens, onPlayerHit, null, this);
```
```js
function onPlayerHit(player, alien) {
    if (this.damageCooldown > 0) return;
    takeDamage(1);
    this.damageCooldown = 1000; // 1 sec invincibility
}
```
In update, decrement damageCooldown by delta.

Bullet hit:
```js
this.physics.add.overlap(this.projectiles, this.aliens, onBulletHit, null, this);
function onBulletHit(proj, alien) {
    proj.destroy(); // or disable
    alien.health -= 1;
    if (alien.health <= 0) {
        destroyAlien(alien);
        addScore(100);
        createExplosion(alien.x, alien.y);
        checkWaveComplete();
    } else {
        // damage feedback: tint flash
        alien.setTintFill(0xff5555);
        this.tweens.add({ targets: alien, tint: 0xffffff, duration: 150 });
    }
}
```

Hmm, `setTintFill` then tween tint won't easily revert to original. Let me use a flash tween on a different approach: tween `alien.alpha` or use `clearTint` after. Let me do:
```js
alien.setTintFill(0xff5555);
this.tweens.add({
    targets: alien,
    duration: 150,
    onComplete: () => alien.clearTint()
});
```
That works.

`destroyAlien`: remove from alienList, destroy sprite, check if wave cleared.
```js
function destroyAlien(alien) {
    const idx = this.alienList.indexOf(alien);
    if (idx >= 0) this.alienList.splice(idx, 1);
    alien.disableBody(true, true); // or destroy
    alien.destroy();
}
```
Actually with `this.aliens.get` reusing, `disableBody(true,true)` recycles. But if I destroy, fine. Since I track alienList separately, let me destroy the sprite. But `this.aliens` group would still reference? destroy removes. Let me just `alien.destroy()`.

Wait, can't call alien.destroy() on a physics sprite safely? Yes, destroying a physics-enabled sprite works; the body is removed.

Wave complete check:
```js
function checkWaveComplete() {
    // slight delay before next wave to allow last alien to die
    if (this.alienList.length === 0) {
        this.time.delayedCall(800, startNextWave, [], this);
    }
}
```
But careful: don't trigger multiple times. Use a flag `this.waveComplete`. Or check length===0 in update. Let me use the overlap approach but ensure single trigger:
```js
let nextWaveTimer = 0;
in update: if (alienList.length===0 && wave>0 && !gameOver) {
   nextWaveTimer += delta;
   if (nextWaveTimer > 800) { nextWaveTimer = 0; startNextWave(); }
}
```
Cleaner. Let me use a timer variable.

startNextWave:
```js
function startNextWave() {
    wave++;
    waveText.setText('WAVE: ' + wave);
    showWavePrompt();
    spawnWave();
}
```
Show a "WAVE 2!" popup.

Now health and game over:
```js
function takeDamage(n) {
    health -= n;
    updateHealthUI();
    if (health <= 0) endGame();
    else player flash red.
}
```
Player flash: tint red, tween back.

endGame:
```js
function endGame() {
    gameOver = true;
    // stop aliens: remove velocities? they keep moving but game over screen covers
    this.physics.pause();
    // or stop alien updates
    showGameOver();
}
```
Actually, let me not pause physics fully (so we can still... no, game over, pause). Let me set `this.physics.pause()` and show overlay. On restart, resume.

Wait, if I pause physics, the player can't move, good (game over). On restart, `this.physics.resume()`.

Health UI: I'll draw hearts as text or a bar. Let me do 3 hearts using a graphics bar or text "♥♥♥" / "♡♡♡" partially. Simpler: a red bar with numeric. Let me do a health bar: a rounded rect filled red, width proportional to health/maxHealth. And a numeric overlay.

Let me do hearts: a row of heart icons. On damage, empty one heart (color change). Let me just draw 3 heart sprites via a graphics texture and toggle tint. Simpler: text hearts with colors. Hmm. Let me draw a health bar at top-left.

Let me implement a health bar with `this.add.graphics` or a sprite. I'll use a graphics object `healthBar` redrawn each time. Actually a sprite fill via `this.add.tileSprite`? Overcomplicated. Let me use text-based: `healthText.setText('HEALTH: ' + health)` plus a colored bar. Let me do a simple bar via `this.add.rectangle` for background and `this.add.rectangle` for fill, scaling width.

Let me create:
```js
this.healthBarBg = this.add.rectangle(10, 10, 120, 18, 0x333333).setOrigin(0,0);
this.healthBarFill = this.add.rectangle(10, 10, 120, 18, 0xff4444).setOrigin(0,0);
this.healthText = this.add.text(10, 32, 'SCORE: 0', { fontSize: 18 });;
```
Update fill width: `this.healthBarFill.width = 120 * (health/maxHealth);`

Score text, wave text similarly.

Let me lay out HUD:
- Top-left: health bar + health text
- Top: score, wave
- Bottom-center: controls hint

Let me finalize positions.

Controls hint text: "MOVE: WASD   AIM: MOUSE   FIRE: LEFT CLICK" at bottom center, y=770, fontSize 16, fill #aaa.

Now let me write the explosion effect. Use particle emitter:
```js
this.explosionParticles = this.add.particles('explosion').createEmitter({
    x: 0, y: 0,
    speed: { min: 50, max: 200 },
    angle: { min: 0, max: 360 },
    scale: { start: 0.6, end: 0 },
    alpha: { start: 1, end: 0 },
    lifespan: 400,
    quantity: 8,
    on: false,
    depth: 3
});
```
Then `createExplosion(x,y)`: `this.explosionParticles.setPosition(x,y).explode(12, ...);` Actually emitter.explode. Let me set `this.explosionParticles.explode({x,y})`... The `emit` options. Let me use:
```js
this.explosionParticles.setPosition(x, y);
this.explosionParticles.explode(10);
```
Hmm but explode at set position. Setting position then explode works. Good. Need to ensure particles render. Good.

Wait — particle texture 'explosion' must be a generated texture. I generate it. Fine.

Now, depth/layers: player depth higher than aliens, bullets higher, UI top. Set depths.

Let me also add a starfield background for nicer look. Procedural: draw small white dots on a canvas/texture. `this.add.tileSprite`? Let me generate a starfield texture:
```js
const gfx = this.make.graphics({add:false});
gfx.fillStyle(0xffffff);
for (let i=0;i<200;i++){ gfx.fillRect(rand*width, rand*height, 1.5, 1.5); }
gfx.generateTexture('starfield', width, height);
this.add.image(width/2, height/2, 'starfield');
```
Nice touch, low cost.

Now, let me handle the player's initial position: center of arena (500, 400).

Player starting health: 3. Score 0, wave 1.

Edge: ensure player can't move outside arena. Set player body collideWorldBounds:
```js
player.setCollideWorldBounds(true);
```
But arcade collideWorldBounds may need the world bounds set to arena. Default world bounds = game size (1000x800). Good, matches. Set collideWorldBounds true on player so it stops at edges. Aliens can move freely (they come from edges; if collideWorldBounds, they'd stop at edge — I don't want them blocked at edges necessarily; but they approach from outside. Let me not set collideWorldBounds on aliens so they can wander. Actually they spawn at edges and move toward center; they won't hit edges. Fine.

But bullets: world bounds kill them. Good.

Let me set world bounds: `this.physics.world.setBounds(0,0,1000,800)`.

Now let me also make sure the player aiming uses pointer in world. Since camera doesn't move (fixed top-down), worldX = pointer.x. Fine. I'll use `this.input.activePointer.worldX/worldY`.

Let me also handle the case where the game is over and pointer down — ignore.

Now restart:
```js
this.restartButton = this.add.text(...).setInteractive().on('pointerdown', restartGame);
```
restartGame:
```js
function restartGame() {
    // clean up aliens and bullets
    this.alienList.forEach(a => a.destroy());
    this.alienList = [];
    this.aliens.clear(true);
    this.projectiles.clear(true);
    // reset state
    health = 3; score = 0; wave = 1;
    gameOver = false;
    damageCooldown = 0; nextWaveTimer = 0; fireCooldown = 0;
    // reset UI
    updateHealthUI(); showScore(); showWave();
    hideGameOver();
    this.physics.resume();
    spawnWave();
}
```

Hmm `this.aliens.clear(true)` removes from world. But I already destroyed sprites. Let me just clear the groups.

Let me be careful: I destroyed alien sprites; the groups may still reference them. Let me use `this.aliens.clear(true,true)` which removes children. Actually let me just `this.aliens.runChildUpdate = false` and clear.

Simpler: keep references in arrays and destroy directly; groups not strictly needed for storage but needed for physics overlap. Let me use the groups for overlap and just `destroy()` sprites + `group.clear(true)` to remove. Actually when you destroy a sprite that's in a group, the group's internal list still has a reference; clearing the group afterwards removes them. Let me do `this.aliens.clear(true)` after destroying, or just clear without destroying (clear(true) destroys children). `Group.clear(true, true)` destroys children and removes from world. Let me just call clear(true) at restart which destroys them. Then I don't need to manually destroy. But I track alienList for win-check; I'll rebuild it in spawnWave.

So restart:
```js
this.aliens.clear(true,true);  // destroys all alien sprites
this.projectiles.clear(true,true);
this.alienList = [];
```
Then reset state and spawnWave.

But `this.physics.resume()` — after pause, physics resumes. Good.

Game over overlay creation: create once, toggle visibility. Let me create overlay in create() as a hidden container: a black rectangle (semi-transparent) covering screen + GAME OVER text + final score + RESTART button. Set `setVisible(false)`. On endGame: set visible true. On restart: set visible false.

Let me make the overlay a Group/Container. Simpler: individual objects with a flag. Let me create a graphics rect + texts, store references, toggle `visible`. Or set alpha tween. Let me just set `setVisible`.

Let me now also show wave prompt text that tweens in/out:
```js
function showWavePrompt() {
    const t = this.add.text(600, 400, 'WAVE ' + wave, { fontSize: 64, fill: '#fff' }).setOrigin(0.5);
    t.alpha = 0;
    this.tweens.add({
        targets: t, alpha: 1, y: 350, duration: 500,
        repeat: 1, yoyo: true,
        onComplete: () => t.destroy()
    });
}
```

Now let me write the whole thing. Let me also be mindful of `leftButtonDown` and firing while pointer is down outside the canvas — pointer.isDown only when over canvas. Fine.

One concern: using `this.input.activePointer` in update for firing with cooldown. When the user clicks, isDown becomes true; fires once (next fireCooldown resets). When they release and click again, fires. Good. Holding fires every cooldown. Good.

Let me also ensure the player ship's aiming rotation only happens when pointer is over the game canvas (mouse). If no mouse, activePointer is at last position; rotation might stay. Fine. For touch, same. Good.

Let me write it now.

Let me also add a small detail: player shoot sound? No audio assets allowed and "generated textures" — audio not requested, skip.

Let me consider performance: waves up to maybe wave 5–10; alien count grows. 30+ aliens with per-frame velocity is fine.

Let me cap wave at some difficulty but unlimited is okay; the task says harder waves. Let me cap alien count at e.g. 40 and speed at 200 to keep manageable, but the requirement is just "increasing enemy count or speed." Fine.

Let me now also double check Phaser 3.80 API details:
- `this.make.graphics({add:false})` ✓
- `graphics.generateTexture(key, width, height)` ✓
- `this.physics.add.group({defaultKey, maxSize})` ✓
- `this.physics.add.overlap(a, b, cb, process, ctx)` ✓
- `this.physics.get(x,y,key)` — this is `this.physics.world` ... actually `this.physics.add.sprite` or group.get. For getting a sprite from the pool: `group.get(x, y, key)`. ✓
- `Phaser.Math.Angle.Between` ✓
- `this.add.particles(key).createEmitter(config)` ✓
- `this.tweens.add({...})` ✓
- `this.time.delayedCall(ms, cb, args, scope)` ✓
- `this.input.activePointer` ✓
- `pointer.leftButtonDown()` ✓ (exists in 3.x)
- `sprite.setCollideWorldBounds(true)` ✓
- `body.setVelocity(x,y)` ✓
- `body.setMaxVelocity(v)` ✓
- Arcade world bounds default = game size; `this.physics.world.setBounds(0,0,w,h)` ✓
- `this.add.rectangle(x,y,w,h,fill)` ✓
- `this.add.text(x,y,str,style)` ✓
- `sprite.setDepth(n)` ✓
- `this.add.image(x,y,key)` ✓

For the player ship sprite with physics: `this.physics.add.sprite(x,y,key)`. ✓

Let me make sure to set player body size appropriately (the triangle is 32x16, but Arcade body default = full texture size, that's fine for collisions).

Now let me write the complete code.

For the controls display requirement, I'll also add a small on-screen legend that's always visible.

Let me also think about "living player" — yes.

Let me write the file now. I'll be thorough.

Let me draft the JavaScript carefully:

```js
(() => {
  const W = 1000, H = 800;
  const config = {
    type: Phaser.AUTO,
    width: W,
    height: H,
    backgroundColor: '#0b0c1a',
    parent: 'game',
    physics: {
      default: 'arcade',
      arcade: {
        debug: false,
        gravity: { y: 0 },
        x: W, y: H,
        // bounds
      }
    },
    scene: { preload, create, update }
  };
  const game = new Phaser.Game(config);

  let player, cursors, projectiles, aliens, explosionParticles;
  let alienList = [];
  let score = 0, health = 3, maxHealth = 3, wave = 1;
  let scoreText, waveText, healthBarFill, healthValueText;
  let gameOver = false;
  let fireCooldown = 0;
  let damageCooldown = 0;
  let nextWaveTimer = 0;

  const SPEED = 200;
  const FIRE_RATE = 180;
  const INVULN = 1000;
  const BULLET_SPEED = 560;

  function preload() {}

  function create() {
    this.physics.world.setBounds(0, 0, W, H);
    genTextures(this);
    drawBackground(this);
    buildPlayer(this);
    buildBullets(this);
    buildAliens(this);
    buildUI(this);
    spawnWave(this);
    // input
    cursors = this.input.keyboard.addKeys({ up:'W',down:'S',left:'A',right:'D' });
  }

  function update(time, delta) {
    if (gameOver) return;
    updatePlayer(delta);
    updateAiming();
    updateFiring(delta);
    updateAliens();
    updateWaveCheck(delta);
  }
  ...
})();
```

Hmm, using `this` as scene inside functions — I need to bind. Let me use the scene object via closures carefully. Since `create` and `update` are called with `this` = scene, I can define them as methods receiving scene. But I'm using module-level `let` for state and `this` inside. Let me reference `this` inside create/update. But my helper functions like spawnWave(this) need the scene. Let me pass scene explicitly.

Let me restructure to use `this` directly inside create/update and store scene on module-level? Cleaner: define everything inside the scene using regular function declarations won't have `this`. Let me use arrow functions inside create? update is called by Phaser with scene as `this`. Inside update I can use `this`. Let me write update as a function and use `this` — but top-level function `update` when used as scene.update, Phaser calls it with scene as context. Actually scene methods defined in the config object: Phaser calls them with `this` = scene. So I can use `this` inside. But my helper functions defined at module scope don't have `this`=scene. So inside update I'll do `const self = this;` and pass self to helpers, or inline.

Let me just use module-level scene variable set in create: `scene = this;` then use `scene` everywhere. But update is called with this=scene; I can rely on the module `scene`. Let me do:

```js
let scene;
function create() {
  scene = this;
  ...
}
function update(time, delta) {
  if (scene) { ... do stuff using scene ... }
}
```

That works. Let me use `scene` global.

Actually cleaner: keep state on `scene` object via properties. But module-level lets are fine.

Let me write the full file now. I'll write carefully.

For texture generation, I'll create a helper using `scene.make.graphics({x:0,y:0, add:false})`.

Potential issue: `generateTexture` on a `make.graphics` created with add:false — does it work? The Graphics object has generateTexture regardless of add. Yes. Good.

Let me write all textures:

```js
function genTextures(sc) {
  let g = sc.make.graphics({x:0,y:0,add:false});

  // player ship
  g.fillStyle(0x4a9fff);
  g.beginPath();
  g.moveTo(28,8);
  g.lineTo(4,2);
  g.lineTo(4,14);
  g.closePath();
  g.fill();
  g.lineStyle(2,0x99ccff);
  g.strokePath... 
  g.generateTexture('player',32,16);

  // alien
  g.clear();
  g.fillStyle(0xff5e5b);
  g.fillCircle(16,16,14);
  g.lineStyle(2,0xaa3330);
  g.strokeCircle(16,16,14);
  g.generateTexture('alien',32,32);

  // projectile
  g.clear();
  g.fillStyle(0xffff99);
  g.fillCircle(8,8,5);
  g.generateTexture('projectile',16,16);

  // explosion particle
  g.clear();
  g.fillStyle(0xffdd66);
  g.fillCircle(8,8,7);
  g.generateTexture('explosion',16,16);
}
```

Wait, `strokePath` for the player ship path — after fillPath, strokePath strokes the same path. Should work. But the line might be thick (2). Fine.

Actually calling g.clear() between generates — note generateTexture captures current graphics. After generating 'player', I clear() before drawing alien. Good. But the Graphics object's pipeline state: clear resets. Should be fine.

Let me double check `g.beginPath()` / `moveTo` etc. on Phaser CanvasRenderingContext wrapper Graphics — Phaser.Graphics supports beginPath, moveTo, lineTo, arc, fill, stroke, fillCircle, strokeCircle, fillRect, etc. In Phaser 3, the Graphics object wraps a canvas 2D context and exposes these methods. `beginPath`, `moveTo`, `lineTo`, `closePath`, `fill`, `stroke` are available. `strokePath` is available too. Good.

Let me simplify player ship to just a filled triangle with no stroke to avoid complications:
```js
g.fillStyle(0x4a9fff);
g.beginPath();
g.moveTo(28,8); g.lineTo(4,2); g.lineTo(4,14); g.closePath();
g.fill();
```
Add a cockpit highlight manually:
```js
g.fillStyle(0xa8d0ff);
g.fillRect(10,5,8,6);
```
Fine.

Now buildPlayer:
```js
function buildPlayer(sc) {
  player = sc.physics.add.sprite(W/2, H/2, 'player');
  player.setOrigin(0.5,0.5);
  player.setDepth(10);
  player.setCollideWorldBounds(true);
  player.body.setDamping(true);
  player.body.setDrag(600);
  player.body.setMaxVelocity(SPEED);
  player.body.setSize(32,16);
  // glow? skip
}
```

Wait, `setDamping(true)` with arcade body — arcade damping requires `body.setDamping(true)`. Velocity drag works. With drag 600, setVelocity and release → decelerates. But I set velocity directly each frame (not acceleration); drag would slow diagonal... Actually with setVelocity each frame and drag, movement feels okay. Let me skip damping/drag and just setVelocity directly with setMaxVelocity. Simpler, predictable:
```js
player.body.setAllowGravity(false); // unnecessary with gravity 0
player.body.setMaxVelocity(SPEED);
```
In update:
```js
player.body.setVelocity(0,0);
if (cursors.left.isDown) player.body.velocity.x -= SPEED;
if (cursors.right.isDown) player.body.velocity.x += SPEED;
if (cursors.up.isDown) player.body.velocity.y -= SPEED;
if (cursors.down.isDown) player.body.velocity.y += SPEED;
```
With setMaxVelocity(SPEED), diagonal caps to SPEED magnitude (so diagonal slightly slower but fine). Actually setMaxVelocity caps the magnitude, so diagonal = SPEED. Good, consistent.

Hmm wait, setVelocity(0,0) then add — the resulting velocity is at most SPEED per axis, and maxVelocity caps hypotenuse to SPEED. So diagonal length = min(sqrt(2)*SPEED, SPEED) = SPEED. Good.

Aiming:
```js
function updateAiming() {
  const p = scene.input.activePointer;
  const angle = Phaser.Math.Angle.Between(player.x, player.y, p.worldX, p.worldY);
  player.rotation = angle;
}
```

Firing:
```js
function updateFiring(delta) {
  const p = scene.input.activePointer;
  if (p.isDown && p.leftButtonDown() && fireCooldown <= 0) {
    fireProjectile();
    fireCooldown = FIRE_RATE;
  }
  if (fireCooldown > 0) fireCooldown -= delta;
}
```

fireProjectile:
```js
function fireProjectile() {
  const angle = player.rotation;
  const mx = player.x + Math.cos(angle)*18;
  const my = player.y + Math.sin(angle)*18;
  const proj = projectiles.get(mx, my, 'projectile');
  if (proj) {
    proj.setActive(true).setVisible(true);
    proj.setRotation(angle);
    proj.setVelocity(Math.cos(angle)*BULLET_SPEED, Math.sin(angle)*BULLET_SPEED);
    proj.body.setAllowGravity(false);
    proj.body.setCollideWorldBounds(false);
    proj.body.checkWorldBounds = true;
    proj.body.outOfBoundsKill = true;
    proj.setDepth(8);
  }
}
```
`projectiles.get` returns a recycled sprite or creates new. Need `on: true` for physics body. Group.get by default creates with body enabled? With `defaultKey` set, `get(x,y)` returns an ArcadeSprite enabled. Yes. Let me ensure `defaultKey: 'projectile'` in group config.

buildBullets:
```js
projectiles = sc.physics.add.group({
  defaultKey: 'projectile',
  maxSize: 60
});
sc.physics.add.overlap(projectiles, aliens, onBulletHit, null, sc);
```

buildAliens:
```js
aliens = sc.physics.add.group();
```
I'll also add overlap for player-alien and projectile-alien. Player-alien overlap:
```js
sc.physics.add.overlap(player, aliens, onPlayerHit, null, sc);
```
But I also need projectile-alien overlap. With two overlap calls referencing same groups, fine.

Wait, order of creation: I create aliens group, then overlaps. Need aliens group defined before overlaps call onBulletHit (callback reference) — fine, callbacks are just functions.

Let me set in create order: physics world bounds, textures, background, player, bullets group, aliens group, overlaps, UI, spawnWave.

onBulletHit callback: signature (proj, alien). Both are sprites (physics). Works.

Let me write onBulletHit:
```js
function onBulletHit(proj, alien) {
  if (!alien || !alien.health) return;
  proj.destroy();
  alien.health -= 1;
  if (alien.health <= 0) {
    scor... 
    destroyAlien(alien);
  } else {
    alien.setTintFill(0xff8888);
    scene.tweens.add({ targets: alien, duration: 150, onComplete: () => alien.clearTint() });
  }
}
```
Wait, proj.destroy() but proj is from a group pool; destroying is okay (it removes). Actually with Arcade group, better to use `proj.disableBody(true,true)` to recycle. But destroy is simpler and works. Let me destroy. But destroying a pool member means it's removed from group; get() will create new up to maxSize. Fine.

Hmm, but `projectiles.clear(true)` at restart destroys remaining. Fine.

destroyAlien:
```js
function destroyAlien(alien) {
  const i = alienList.indexOf(alien);
  if (i>=0) alienList.splice(i,1);
  alien.destroy();
  explosion at alien;
  addScore(100);
}
```
But addScore and explosion need scene. Call within.

Wait, `onBulletHit` is passed as callback with scope `sc`. Inside I reference module-level `scene`. I'll use `scene`. Let me make scope sc = scene. Fine.

Let me make all callbacks use module `scene`.

spawnWave:
```js
function spawnWave() {
  const count = Math.min(12 + (wave-1)*3, 40);
  const speed = Math.min(60 + (wave-1)*18, 220);
  for (let i=0;i<count;i++){
    const side = Phaser.Math.Between(0,3);
    let x,y;
    const margin = 24;
    const pad = 40;
    if (side===0){ x = -margin; y = Phaser.Math.FloatBetween(pad, H-pad);}
    else if (side===1){ x = W+margin; y = Phaser.Math.FloatBetween(pad, H-pad);}
    else if (side===2){ x = Phaser.Math.FloatBetween(pad, W-pad); y = -margin;}
    else { x = Phaser.Math.FloatBetween(pad, W-pad); y = H+margin;}
    const alien = aliens.get(x,y,'alien');
    alien.setActive(true).setVisible(true).setDepth(5);
    alien.health = 2 + Math.floor(wave/3); // a bit more health on later waves
    alien.moveSpeed = speed;
    alien.body.setAllowGravity(false);
    alien.body.setCollideWorldBounds(false);
    alien.body.setCircle(14); // match texture? setCircle for circle collisions
    alienList.push(alien);
  }
  // show wave prompt
  showWavePrompt();
}
```
`alien.moveSpeed` stores speed. `alien.health` stores hp. Set body circle for circular collision (matches circle texture). Good.

updateAliens:
```js
function updateAliens() {
  for (const a of alienList) {
    if (!a.active) continue;
    const angle = Phaser.Math.Angle.Between(a.x, a.y, player.x, player.y);
    a.body.setVelocity(Math.cos(angle)*a.moveSpeed, Math.sin(angle)*a.moveSpeed);
  }
}
```
Set velocity each frame toward player. Good. They home in.

onPlayerHit:
```js
function onPlayerHit(playerSprite, alien) {
  if (damageCooldown > 0) return;
  takeDamage(1);
}
```
overlap player & aliens each frame triggers — with invincibility 1s, won't spam.

takeDamage:
```js
function takeDamage(n=1) {
  health -= n;
  damageCooldown = INVULN;
  updateHealthUI();
  player.setTintFill(0xff0000);
  scene.tweens.add({ targets: player, duration: 300, onComplete: () => player.clearTint() });
  if (health <= 0) endGame();
}
```

updateHealthUI:
```js
function updateHealthUI() {
  const pct = Math.max(health,0)/maxHealth;
  healthBarFill.width = 160 * pct;
  healthBarFill.fillColor = health <= 1 ? 0xff5555 : 0xff4444;
}
```
Hmm healthBarFill is a rectangle; changing width works. fillColor property exists. Good.

endGame:
```js
function endGame() {
  gameOver = true;
  scene.physics.pause();
  showGameOver();
}
```

updateWaveCheck:
```js
function updateWaveCheck(delta) {
  if (alienList.length === 0) {
    nextWaveTimer += delta;
    if (nextWaveTimer >= 900) {
      nextWaveTimer = 0;
      wave++;
      waveText.setText('WAVE: '+wave);
      spawnWave();
    }
  } else {
    nextWaveTimer = 0;
  }
}
```
Wait, but initially after spawnWave, alienList has entries; fine. After killing all, count to 900ms then wave++ and spawn. Good. But the very first wave: spawnWave sets aliens, alienList >0. Good.

Edge: spawnWave uses `aliens.get(x,y,'alien')`. If aliens group has maxSize? I didn't set maxSize for aliens → unlimited. Good. Projectiles maxSize 60. Fine.

showGameOver / hide:
```js
function showGameOver() {
  overlay.setVisible(true);
  finalScoreText.setText('SCORE: '+score);
}
```
I'll create overlay objects once.

Let me create UI in buildUI:
```js
function buildUI(sc) {
  const bx=16, by=12;
  sc.add.rectangle(bx, by, 180, 24, 0x222233).setOrigin(0,0).setDepth(20);
  healthBarFill = sc.add.rectangle(bx, by, 160, 20, 0xff4444).setOrigin(0,0).setDepth(21);
  sc.add.text(bx, by-22, 'HEALTH', {fontSize:'14px',fill:'#aaa'}).setDepth(20);

  scoreText = sc.add.text(W-180, 12, 'SCORE: 0', {fontSize:'20px',fill:'#fff',stroke:'#000',strokeThickness:2}).setDepth(20);
  scoreText.setOrigin(1,0);
  waveText = sc.add.text(W-180, 36, 'WAVE: 1', {...}).setDepth(20);
  waveText.setOrigin(1,0);

  controlsText = sc.add.text(W/2, H-24, 'MOVE: WASD   AIM: MOUSE   FIRE: LEFT CLICK', {fontSize:'16px',fill:'#bbb',stroke:'#000',strokeThickness:2}).setOrigin(0.5).setDepth(20);

  // overlay
  const ov = sc.add.rectangle(W/2,H/2,W,H,0x000000,0.7).setDepth(30);
  const title = sc.add.text(W/2,H/2-80,'GAME OVER',{fontSize:'48px',fill:'#fff'}).setOrigin(0.5).setDepth(31);
  finalScoreText = sc.add.text(W/2,H/2+0,'SCORE: 0',{fontSize:'24px',fill:'#fff'}).setOrigin(0.5).setDepth(31);
  restartBtn = sc.add.text(W/2,H/2+60,'RESTART',{fontSize:'28px',fill:'#fff',backgroundColor:'#333'}).setOrigin(0.5).setInteractive({pixelHited...}).on('pointerover',()=>restartBtn.setStyle({fill:'#ff0'})).on('pointerout',()=>restartBtn.setStyle({fill:'#fff'})).on('pointerdown',restartGame).setDepth(31);
  overlay = sc.add.container(0,0, [ov,title,finalScoreText,restartBtn]); // container to toggle
  overlay.setVisible(false);
}
```
Hmm using a Container for the overlay is convenient. But children of container — setVisible on container hides all. Good. But interactive on restartBtn inside container — pointer events still work when container visible. Should work.

Actually, mixing container and direct adds: finalScoreText referenced outside but added to container. For setVisible(false) on container hides children. Good. But the container's children include the texts; toggling container visibility works.

But `restartBtn` is added to container; I set interactive before adding. The pointerover/out handlers reference restartBtn. Fine.

Let me set `ov` as a rectangle with alpha via color alpha: `sc.add.rectangle(x,y,w,h,fill,alpha)`. Phaser rectangle supports fill color int and alpha. Good. `0x000000,0.75`.

Let me make overlay a simple approach without container, just set each child visible. But container is cleaner. Let me use container.

Wait, `setInteractive` on a Text — Phaser Text supports setInteractive with default handler. Good.

restartGame:
```js
function restartGame() {
  if (!gameOver) return;
  aliens.clear(true,true);
  projectiles.clear(true,true);
  alienList = [];
  // reset
  health=3; score=0; wave=1; gameOver=false;
  damageCooldown=0; nextWaveTimer=0; fireCooldown=0;
  updateHealthUI();
  scoreText.setText('SCORE: 0');
  waveText.setText('WAVE: 1');
  overlay.setVisible(false);
  scene.physics.resume();
  // rebuild player health? player still exists
  player.body.setVelocity(0,0);
  player.setPosition(W/2,H/2);
  spawnWave();
}
```
But the player sprite persists. Good. Just reset position. Also clearTint.

Also after physics.pause(), the player body is paused; resume() re-enables. On restart, player should be controllable. Good.

One issue: after endGame, I call scene.physics.pause(). But bullets/alive still paused. On restart resume. Good. But I also might want to disable firing when game over — update returns early if gameOver. Good.

Let me also add a small "ready" after restart? Optional. Keep simple.

Now the starfield background:
```js
function drawBackground(sc) {
  const g = sc.make.graphics({x:0,y:0,add:false});
  g.fillStyle(0xffffff);
  for(let i=0;i<160;i++){
    const x=Math.random()*W, y=Math.random()*H;
    const r=Math.random()*1.2;
    g.fillRect(x,y,r+0.3, r+0.3);
  }
  g.generateTexture('starfield',W,H);
  sc.add.image(W/2,H/2,'starfield').setDepth(0);
  // dark overlay tint
}
```

Explosion particles:
```js
function makeExplosion(sc) {
  explosionParticles = sc.add.particles('explosion').createEmitter({
    x:0,y:0, speed:{min:60,max:180}, angle:{min:0,max:360}, scale:{start:0.5,end:0}, alpha:{start:1,end:0}, lifespan:450, quantity:6, on:false, depth:3
  });
}
```
createExplosion:
```js
function createExplosion(x,y) {
  explosionParticles.setPosition(x,y);
  explosionParticles.explode(10);
}
```

addScore:
```js
function addScore(n) {
  score += n;
  scoreText.setText('SCORE: '+score);
}
```

Now, the `scene` global needs to be set in create. But update uses module-level `scene`. Let me set `scene` in create and also reset references in restart.

Let me also ensure `cursors` defined.

Let me also handle the possibility that `projectiles.get` returns a sprite but if it's a recycled previously-destroyed... fine.

Edge: `proj.body.checkWorldBounds = true; proj.body.outOfBoundsKill = true;` — these need the physics world to have bounds enabled. `scene.physics.world.setBounds(0,0,W,H)` enables them. Good.

Now, the player sprite rotation with aiming: `player.rotation = angle` — rotation in radians, default origin 0.5. The triangle points right at rotation 0 → aims at mouse (angle measured from +x axis right). Good. But our triangle texture tip at x=28 in 32-width texture, center at 16 → offset 12 from center. So muzzle distance = 12. I used 18 earlier; let me use 12 (or 14). Let me compute: tip relative center = 28-16=12. So `Math.cos(angle)*12`. Let me set 12. Hmm but I want the projectile to spawn at the nose. Use 12. But also slight vertical? Triangle center y=8, tip y=8 (symmetric), so no vertical offset. Good. Use 12.

Actually let me make tip bigger / ship longer for clearer aiming. Let me make player texture 40x20, tip at x=36, center 20 → offset 16. Eh, keep 14 offset. Fine. I'll set muzzle offset 14.

Let me finalize textures sizes.

Let me also reconsider: does `player.rotation` affect the aiming when mouse is at player position (angle 0)? Then rotation resets to 0 (pointing right). Minor. Acceptable.

Also `Angle.Between` uses world position of pointer; since camera unmoved, worldX pointer.x. Good.

Let me also make sure firing works when moving — yes, independent.

Now potential bug: I add overlaps `sc.physics.add.overlap(projectiles, aliens, onBulletHit, null, sc)` but `aliens`/`projectiles` are module-level set in buildBullets/buildAliens called in create before adding overlaps. Order in create: textures, background, player, bullets(group), aliens(group), then overlaps. Let me ensure buildAliens before overlaps. I'll call buildAliens then add overlaps.

Let me write overlaps inside create after groups.

Let me also double-check: `scene.physics.add.overlap` with scope sc — onBulletHit receives (proj, alien). Good.

Now `scene.physics.add.overlap(player, aliens, onPlayerHit, null, scene)` — onPlayerHit(player, alien). Good.

Let me write the final file. I'll also add a subtle vignette? Not necessary.

Let me also add a frame rate cap / fixed step? Default fine.

Let me write it all now. I'll be careful with Phaser API names.

Let me reconsider `setTintFill` then `clearTint` via tween onComplete. The tween targets alien and animates tint; but tint is a number property; tweening tint works (Phaser tweens can tween tint). Actually tint tweening may need to be enabled; Phaser supports tweening tint. Alternatively tween alpha for flash. Let me tween alpha 1→0.4→1 for flash (simpler, no color reset needed):
```js
alien.setAlpha(0.4);
scene.tweens.add({ targets: alien, alpha:1, duration:150 });
```
But if hit again during tween, fine. Let me use alpha flash for damage feedback — clean.

For player flash, same: tween alpha.

Let me use alpha flash.

Now, `destroyAlien` calls `alien.destroy()`. But the alien is in the `aliens` group and overlap list. Destroying removes it from physics and display. The group still references; next `aliens.get` reuses? No, destroyed is gone. For recycling we'd disableBody. Since I don't set maxSize on aliens, get creates new each time. Destroy is fine but no recycling → could leak. For a game with ~40 aliens per wave, destroy is fine performance-wise. But to be tidy, let me recycle: `alien.disableBody(true,true)` and remove from alienList. But disabled bodies still exist in group; `get` reuses them. Overlap checks ignore non-active bodies? Overlap checks all children; disabled body (x=-500) won't overlap. Actually disableBody(true,true) moves it off and deactivates; get() will reuse. Let me use disableBody to recycle. But then alienList has the inactive one; I splice it out so it's not updated. Good.

Hmm, but if recycled and reused, the health property resets in spawnWave. Good.

Let me use:
```js
function destroyAlien(alien) {
  const i = alienList.indexOf(alien);
  if (i>=0) alienList.splice(i,1);
  alien.disableBody(true, true); // recycle
  createExplosion(alien.x, alien.y);
  addScore(100);
}
```
But disableBody moves it off-screen; the explosion at old position (alien.x,y before disable? disableBody sets active false and moves to -10000). I call createExplosion before disable? Let me capture x,y first. Order: record x,y, disableBody, then createExplosion at recorded coords. Actually createExplosion uses emitter; fine.

Wait, `disableBody(true,true)` sets the body inactive and the sprite at (-1000,-1000)? The first param `disable` and second `hide`. Let me record position first:
```js
const x=alien.x, y=alien.y;
alien.disableBody(true,true);
createExplosion(x,y);
addScore(100);
```

But onBulletHit sets `alien.health -= 1` then maybe destroy. For recycling, on destroy we disableBody. But note: `alien.health` is a custom property; when recycled and re-spawned, we set health again. Good.

Also need to ensure recycled (inactive) aliens aren't in alienList (we removed). And not updated. Good.

But there's a subtlety: overlap callbacks might fire for inactive/dead? `overlap` checks active bodies; disabled bodies are inactive and excluded. Good.

However, when I `clear(true,true)` at restart, it destroys all children (including recycled ones) and empties group. Good.

Let me also make projectiles recycle similarly. In onBulletHit: `proj.disableBody(true,true)`. And set outOfBoundsKill recycles too. Let me use disableBody(true,true) for proj. But disabled proj still in group; get reuses. Fine. Let me use that.

Actually for bullets, outOfBoundsKill with checkWorldBounds — Phaser's `outOfBoundsKill` when body goes out of bounds calls `body.enable = false; body.setVelocity(0)` and hides. It doesn't fully disable for reuse; but next get reuses it. Hmm, outOfBoundsKill may just disable. Let me instead manually manage bullet life: in a group update or check in update loop. Simpler: set a `bulletTime`/lifespan by destroying after travel distance, or check `proj.body.onWorldBounds` and destroy. Let me just let bullets travel; they go off screen quickly. Use `outOfBoundsKill` is okay. Let me set `proj.setVelocity(...)` and a `scene.time.delayedCall` to disable after 2s? That adds timers. Simpler: rely on outOfBoundsKill.

Let me set on proj: `proj.body.setAllowGravity(false); proj.body.setCollideWorldBounds(true); proj.body.onWorldBounds=true; proj.body.outOfBoundsKill=true;` Wait, outOfBoundsKill requires the worldbounds event. With checkWorldBounds the body fires 'worldbounds' callback when leaving, and outOfBoundsKill destroys. Hmm, actually outOfBoundsKill destroys the sprite when it leaves the world. For a recycled group, destroyed can't be reused. Conflict with recycling. 

To avoid complexity, let me NOT use a pool group recycling for bullets; just create sprites and destroy them. Use `scene.physics.add.group` without maxSize, create bullets, destroy on hit or out-of-bounds. For out-of-bounds, add `proj.body.setCollideWorldBounds(true)`? That would bounce them off screen (bad). Instead, manually check in update: `if (!proj.body.onScreen()) proj.destroy()` where onScreen? There's no body.onScreen; there's `body.isOnScreen` / GameObject `onScreen` (camera). Let me use `this.cameras.main.worldToScreen`... overcomplicated.

Simplest: give bullets a short lifespan using `scene.time.delayedCall(1500, ()=>{ if(proj&&proj.body && proj.body.enabled) proj.destroy(); })`. Or set `proj.body.velocity` large so they exit quickly and destroy on hit only; for cleanup, in update check distance from spawn > 1200 → destroy. Let me track with a property `proj.birth = scene.time.now` and in update destroy if older than 2s. Eh.

Let me just use the Arcade group `defaultKey` with `runChildUpdate: false` and rely on outOfBoundsKill destroy. Since bullets are cheap, destroying and creating is fine. No recycling needed. `projectiles.get` in a group with defaultKey but `runChildUpdate false` — actually get still recycles if maxSize set; without maxSize, get creates new. Since I don't need recycling for bullets (cheap), let me just create bullets directly:
```js
const proj = scene.physics.add.sprite(mx,my,'projectile');
```
and destroy on hit / out of bounds. For out of bounds, set:
```js
proj.body.setAllowGravity(false);
proj.setDepth(8);
proj.setRotation(angle);
proj.setVelocity(...);
// destroy when far
scene.time.delayedCall(1600, () => { if(proj && proj.active) proj.destroy(); });
```
That handles cleanup. Simpler and robust. Let me do that; no pool.

onBulletHit: `proj.destroy()`; destroyAlien on alien.

Overlap bullets & aliens: `scene.physics.add.overlap` — both groups? If projectiles is created via add.sprite (not a group), I need to add them to a group to overlap, OR use a group. Let me make a projectiles group (no maxSize) and add bullets to it via `projectiles.add(proj)`. Then overlaps work.

```js
projectiles = scene.physics.add.group({ defaultKey: 'projectile' });  // maxSize = 0? undefined default 10k?
```
Actually Arcade group maxChildren default is 10000? If not set, effectively unlimited? Let me not set maxSize; set large. Hmm, group.get recycles if maxSize >0. Let me just create sprites and add to an empty group manually:
```js
projectiles = scene.physics.add.group();
const proj = scene.physics.add.sprite(mx,my,'projectile');
proj.body.setAllowGravity(false);
projectiles.add(proj);
```
`add` appends to group (doesn't reuse). Overlap with group works. Destroy on hit removes sprite; group still references dead? add() keeps object; when destroyed, the object's `alive` false; overlap skips destroyed? Overlap iterates group children; a destroyed sprite is removed from the scene but still in group list; `body` might be null. Hmm. To avoid issues, let me `remove(proj)` from group on destroy, or use `group.kill(proj)` to recycle. 

Ugh, recycling again. Let me just use the pool properly: `projectiles = scene.physics.add.group({ defaultKey:'projectile', maxSize:50, runChildUpdate:false })`. For cleanup use `proj.setVelocity` and let me add a custom update via `runChildUpdate: true` and a childUpdate that kills off-screen. That is robust:
```js
projectiles = scene.physics.add.group({
  defaultKey: 'projectile',
  maxSize: 50,
  runChildUpdate: true
});
```
And add a custom class/method? Arcade group childUpdate calls a method named by config? Actually `runChildUpdate` calls `sprite.update()` if it exists on the child. By default sprites have empty update. I can add an update method on the projectile sprite:
```js
proj.update = function() {
  if (!this.body || !this.body.onScreen && ...) {}
}
```
Hmm there's no `body.onScreen`. There's `Phaser.GameObjects.GameObject` `onScreen(camera)`. But in childUpdate, `this` is the child sprite; can call `this.onScreen(scene.cameras.main)`. If not on screen, kill. Let me do:
```js
proj.update = function() {
  if (!this.body || !this.body.enabled) return;
  if (this.body.x < -50 || this.body.x > W+50 || this.body.y < -50 || this.body.y > H+50) {
    this.body.enable = false; // kill
    this.setVisible(false);
  }
};
```
Wait, killing in pool: set `this.body.enable=false` and visible false; next `projectiles.get` will reuse (get reuses the first disabled). Actually `get` reuses objects whose body is not enabled? The pool's `get` returns the first non-active/deactive member. Setting `body.enable=false` makes it available for reuse on next get. Let me use `this.setActive(false)` and `body.enable=false`? Hmm.

Let me simplify and not over-engineer. I'll NOT use runChildUpdate. I'll kill bullets:
- on hit: destroy.
- in update(): iterate projectiles.getChildren(), destroy those with body.x out of bounds.

But destroyed sprite in group list → next getChildren includes it with alive false; in overlap it might cause issues. Let me instead use `disableBody` to remove from active and reuse, not destroy.

OK let me commit to the pool with disableBody recycling for bullets, and a manual cleanup in update:

```js
function fireProjectile() {
  const proj = projectiles.get(mx, my, 'projectile');
  if (!proj) return;
  proj.setActive(true).setVisible(true);
  proj.body.enable = true;
  proj.body.setAllowGravity(false);
  proj.setVelocity(...);
  proj.setRotation(angle);
  proj.body.checkWorldBounds = true;
  proj.body.setCollideWorldBounds(true); // so it bounces? no
  proj.body.onWorldBounds = true;
  proj.body.outOfBoundsKill = true;
}
```

Hmm outOfBoundsKill destroys the sprite (calls destroy), which removes from group and can't recycle. Not ideal.

Let me reconsider: simplest reliable is bullets destroy on hit, and a lifespan timer destroys them otherwise. Use `scene.time.delayedCall`. No pool recycling; group maxSize=0 (unlimited) created manually. Overlap iterates the group's active children; destroyed ones (body null) — overlap uses `body`? Arcade overlap checks each child has a body; if destroyed, body is null → it may error. To avoid, when destroying, also remove from group: `projectiles.remove(proj)` then `proj.destroy()`. Or `projectiles.killAndHide(proj)`? killAndHide sets inactive and moves off; but we want gone. 

You know, the cleanest: maintain bullets in a plain array `projectilesList` of sprites (physics.add.sprite). Overlap via checking each bullet against aliens manually is more work. 

Let me use a physics group and rely on Phaser's overlap ignoring destroyed. Does Arcade overlap skip destroyed sprites? When a sprite is destroyed, `sprite.body` is set to null? Actually destroying an ArcadeSprite calls `destroy()` which removes body from physics world. The group's `getChildren` would still list it, but its body is null. Arcade overlap's `_overlap` checks `if (!gameObject.body) return;`? Let me not risk it.

Decision: Use a group with recycling via `disableBody(true, true)` (which hides and moves off, keeps body active=false so overlap skips inactive bodies — Arcade overlap does check `body.active`/`body.enable`). For cleanup of off-screen, use a custom childUpdate via runChildUpdate calling a function. Actually, let me use `scene.physics.add.group({ defaultKey:'projectile', maxSize:60, runChildUpdate: true })` with each child having an `update` method that recycles it when off-screen.

But ArcadeSprite's update isn't called automatically even with runChildUpdate? `runChildUpdate` makes the group call `child.update()` each step for children that exist. So I set `proj.update = function() { recycle if off-screen }`. The function checks bounds and calls `this.body.enable=false; this.setActive(false); this.setVisible(false);` to make it reusable. Hmm but then `get` reuses disabled ones. Actually `get` reuses the first body that is not active. Setting `setActive(false)` + `setVisible(false)` + `body.enable=false` should make it reusable via `get`. Let me verify Phaser Arcade physics group `get` reuses: it iterates children and returns the first one that is `!child.active` (for get's `getFirstDead` logic). `setActive(false)` makes it the target. Then `get` returns it, and we re-enable. Good.

But the off-screen recycle via update: when a bullet goes off-screen, I recycle it. Combined with hit (onBulletHit recycles proj too). 

Let me also handle onBulletHit recycle: `proj.setActive(false); proj.setVisible(false); proj.body.enable=false;` instead of destroy. This keeps it in the pool. Good. And alien recycle via disableBody.

For aliens, similar: I'll use the aliens group and `disableBody(true,true)` on death, no runChildUpdate (aliens have no child update needed). getChildren for alienList is separate; I manage alienList manually.

Actually for aliens I push the sprite into alienList; on death I splice and disableBody. Overlap checks `aliens` group children; disabled bodies skipped. Good.

Let me write onBulletHit and destroyAlien to recycle.

Let me also double check `Phaser.Math.Angle.Between` import — it's a static method on Phaser.Math. Fine.

Let me also ensure `scene.input.activePointer` valid before first interaction — yes, it's the mouse position (starts at (0,0) or center?). It's an existing Pointer object; `.worldX` returns the position. Initially at (0,0)? The activePointer for mouse starts at (0,0) until moved. So initial rotation points to (0,0) = top-left. That's fine; as soon as mouse moves it updates.

Hmm, but `.leftButtonDown()` requires a button event; activePointer.leftButtonDown() returns the current button state. Fine.

Let me write the code now fully. I'll also add a small "crosshair" aiming reticle? Optional. A line from player nose to pointer could help visualize aim. Let me add a graphics line updated in update showing aim direction. Actually player ship already points to mouse, which is the aim indicator. Good enough.

Let me also add a muzzle flash on fire: briefly tint or spawn a small rect. Optional. Let me add a small white quad at muzzle for 100ms. Eh, keep it minimal but add a muzzle flash rect that tweens alpha → 0. Nice feedback. Let me add.

I'll add a `spawnMuzzleFlash(x,y,angle)`.

OK, let me also think about the "visible feedback" requirement: projectile hit produces visible feedback. The alien flash (alpha) + explosion particles + score number popup suffice. I'll add a floating damage/score text that tweens up. Let me add a floating "+100" text at kill.

Let me write everything now.

Let me also cap delta usage; fine.

Let me write the final index.html.

I realize I should double-check that `generateTexture` works on `make.graphics` with `add:false`. In Phaser 3, `make.graphics` creates a Graphics without adding to display list. Graphics objects have `generateTexture`. However, there's a known requirement: `generateTexture` works on any Graphics. Good.

Also, generating a texture and then using it in `physics.add.sprite` (Arcade) works as long as the texture is in the Texture Manager. `generateTexture` registers it. Good.

One more: `scene.make.graphics` vs `scene.add.graphics`. Both produce a Graphics. `make` doesn't add to display list, so I must call it on the scene. `scene.make.graphics({x,y, add:false})`. Good.

Let me write the file. I'll also wrap in a boot: `window.onload = ()=> new Phaser.Game(config)`. Or just new Phaser.Game after defining. Since script is at end of body after phaser.min.js, `window.Phaser` available. Let me create game on load.

Let me write it.

Actually, the parent 'game' div — I need a container element with id 'game' for Phaser to inject into. Let me add `<div id="game"></div>` in body, or let Phaser create? Phaser needs the parent element to exist. Let me add the div.

Let me finalize HTML structure:
```html
<body>
<div id="game" style="width:100%;height:100%"></div>
<script src="phaser.min.js"></script>
<script> ... game ... </script>
</body>
```
CSS sets html,body full.

Let me write now. I'll be careful and complete.

Let me also reconsider the player aiming rotation interfering with movement feel: ship rotates to mouse. When moving up while aiming up, ship points up, fine. When strafing, ship points away from travel direction — that's okay (like many shooters).

I think it's fine. Let me write.

Actually, let me reconsider: maybe a turret-over-tank where hull moves and turret aims is nicer, but I'll keep ship-rotation to reduce risk. Final decision made.

Let me write the code.

For floating score text:
```js
function floatText(x,y,msg,color){
  const t = scene.add.text(x,y,msg,{fontSize:'16px',fill:color,stroke:'#000',strokeThickness:2}).setDepth(8);
  scene.tweens.add({ targets:t, y: y-40, alpha:0, duration:900, onComplete:()=>t.destroy() });
}
```

Now let me write the file via write tool.

Let me also ensure I handle `scene.physics` references consistently: I'll capture `scene` in create.

Let me write.

Potential issue: In `restartGame`, after `aliens.clear(true,true)` then `projectiles.clear(true,true)`, the `alienList` is reset and groups cleared. But the player sprite still exists; I reset its position. Then spawnWave repopulates. Overlap callbacks were set once in create and still reference the same groups (now cleared and refilled) — overlap config holds references to the group objects, so refilling works. Good.

But `scene.physics.pause()` then `resume()` — overlaps continue to fire after resume. Good.

Also after game over, `update` returns early, so player/alien logic stops. Good. On restart, gameOver=false, update runs.

Let me also make sure firing stops when game over (update returns early). Good.

Let me write the complete file now.

Let me reconsider the wave prompt tween using yoyo repeat 1 — that tweens alpha 0→1→0 and y moves. Fine.

Let me also add a "WAVE X" display that lingers. Keep pop-up.

Now, about difficulty pacing: wave 1 = 12 aliens? Maybe 10. Let me do 8 + (wave-1)*4. And speed 55 + (wave-1)*20. Good.

Let me set alien health = 1 for early, 2 later. Let me do `alien.health = wave>=4?2:1`. Keep simple. Actually let me keep health=1 always for simplicity, but increase count and speed for difficulty. The requirement only needs count or speed increase. Let me keep health=1 and scale count/speed. Simpler and the damage flash + explosion is enough feedback. But to make later waves "harder," more aliens + faster. Good.

Wait, but contact damage should be meaningful. With health=3, player, and aliens doing 1 damage per hit with 1s invuln, player can survive ~3 hits. Fine.

Let me set player maxHealth=3.

Let me finalize and write.

Let me also make the player ship slightly larger / more visible. Texture 40x24.

Let me write textures with these sizes:
- player: 40x24, tip at x=36, center x=20 → offset 16. y symmetric center 12.
  Triangle tip (36,12), left base (6,4), right? base at (6,20). So points (36,12),(6,4),(6,20). Centroid x=(36+6+6)/3=16, y=(12+4+20)/3=12. center(20,12). Slight x offset but fine.
- alien: 32x32 circle r14 centered (16,16).
- projectile: 12x12 circle r5 (center 6,6). Let me do 14x14 r6.
- explosion: 16x16 r7.

Muzzle offset 16 for player.

Let me write.

Actually, let me reduce risk with `fillCircle` stroke for alien: `g.strokeCircle(16,16,14)` after fill — fine.

Now writing.

Let me also add world bounds so bullets stop. Already.

Let me also set `scene.cameras.main.setBackgroundColor('#0b0c1a')` — config backgroundColor handles it. Fine.

Let me write the file. I'll make it a complete HTML.

Let me write the JS with functions referencing module-level `scene`, `player`, `projectiles`, `aliens`, `alienList`, `explosionParticles`, and UI vars.

Let me write now.

I need to double check `Phaser.Math.FloatBetween` exists — yes, `Phaser.Math.FloatBetween(min, max)`. Good. `Phaser.Math.Between(min,max)` integer. Good.

Also `this.input.activePointer.leftButtonDown()` — In Phaser 3, Pointer has `leftButtonDown()` method (returns bool whether left button is down). Yes.

Let me write.

For the muzzle flash:
```js
function muzzleFlash(x,y){
  const m = scene.add.rectangle(x,y,10,4,0xffffaa).setDepth(9);
  scene.tweens.add({targets:m, alpha:0, scale:1.6, duration:120, onComplete:()=>m.destroy()});
}
```

OK writing the file now.

Let me also think about whether `scene.input.keyboard.addKeys` works and returns keys with `.isDown`. Yes.

Let me also make sure the game doesn't break if `projectiles.get` returns a used sprite that has stale velocity — I set velocity each fire. Good.

Let me also ensure `proj.body.enable` resets when get reuses: `get` calls `enableBody` automatically, setting body.enable=true. Actually get returns the object and enables its body if `customClass`? Standard get enables body. Good. Then I set velocity etc.

Alright, writing.

Let me write the complete HTML file.

Now let me run the application in the browser using the browser tool and inspect. Let me reload/inspect.

There are issues:
1. `ParticleEmitterManager was removed in Phaser 3.60. See documentation for details`
2. `createEmitter removed. See ParticleEmitter docs for info`

In Phaser 3.60+, the particles API changed. `scene.add.particles(key)` returns a `ParticleEmitterManager` which was removed. The new way is `scene.add.particles({ key, ... })` or `scene.add.particles().createEmitter`? Let me check.

Actually in Phaser 3.60+, `scene.add.particles(key)` still returns a ParticleEmitterManager I think, but the warning says it was removed. Hmm.

Wait, the error "createEmitter removed" — maybe `scene.add.particles('explosion')` is now deprecated; the new API: `scene.make.particles`? Let me recall. In Phaser 3.60, the Particles module was refactored. `this.add.particles(key)` returns a ParticleEmitterManager. Actually the warning "ParticleEmitterManager was removed in Phaser 3.60" suggests that in this build, `add.particles` returns something else.

Let me check the Phaser 3.80 particles API. In 3.80, `this.add.particles(texture)` returns a `ParticleEmitterManager`. Hmm but the warning says removed. Let me look at the docs.

Actually, in Phaser 3.80, the recommended way to create a particle emitter is:
```js
this.add.particles(key).createEmitter(config);
```
But the warning indicates that's old. The new API (3.60+) changed particles so that `this.add.particles(key)` returns a ParticleEmitterManager still? Let me check.

Let me search the phaser min for "createEmitter" and "ParticleEmitterManager".

Actually, the error is "createEmitter removed." This is because in 3.60+, calling `createEmitter` on the manager with the old style is removed? Or maybe `add.particles` now returns a ParticleEmitter (not manager) and you call `.setConfig`?

Let me inspect phaser docs. I recall: In Phaser 3.60, the Particle system was reworked. `this.add.particles(key)` returns a `ParticleEmitterManager`. The method to add a config... hmm.

Let me just grep the phaser.min.js to understand the API. Let me check the docs folder.

Let me read the Phaser docs about particles. Actually, let me grep the source for "createEmitter" and "ParticleEmitterManager".

So `add.particles(key)` — when key is a string, it warns "ParticleEmitterManager was removed in Phaser 3.60". Let me look more carefully. The warning triggers when the first arg is a string. So passing a string key is the old API. The new API probably expects a config object or different.

Let me look at how `add.particles` is defined.

Let me look at the phaser docs in the pi-coding-agent docs directory, and the examples directory for particles usage. Actually, let me look at the Phaser 3.80 API for particles. The key change: in 3.60+, `add.particles` expects no string-arg; instead:

```js
this.add.particles({ key: 'particle' }).createEmitter({...});
```

Wait, the warning says "ParticleEmitterManager was removed in Phaser 3.60". So the function `add.particles(t)` where t is a string triggers the warning and then does `this.displayList.add(new n(...))` — returns a new ParticleEmitter (n). Hmm the code: `return void 0!==t&&"string"==typeof t&&console.warn(...), this.displayList.add(new n(this.scene,t,e,i,s))`. So `add.particles(key, x, y, width, height)` creates a new `n` which is... a ParticleEmitterManager? But it warns that ParticleEmitterManager was removed.

So in 3.80, `add.particles` creates a ParticleEmitterManager but warns if you pass a string. The recommended approach: don't pass a string directly? But we need a texture key.

Hmm, the warning is just a warning; the error is "createEmitter removed." So after `add.particles('explosion')` returns a manager, calling `.createEmitter` on it is removed/renamed.

Let me check the new API. In Phaser 3.60, the particles were refactored: `this.add.particles(key)` returns a `ParticleEmitterManager`, and you call `manager.createEmitter(config)`. Wait but the error says createEmitter removed.

Let me grep for the emitter creation method name in this build.

So `createEmitter` is removed and throws. I need the new API. Let me find how to create emitters in 3.80. Let me search for `emit` and `ParticleEmitter` usage / the manager creation.

In Phaser 3.60+, you create a particle system via:
```js
this.add.particles('key'); // returns ParticleEmitterManager
```
Hmm but createEmitter throws. Wait, that can't be right — the manager must have some method to add an emitter. Let me look at what `add.particles` returns and what methods it has. Let me look at the actual module.

Let me find the ParticleEmitterManager class definition and its methods.

The `add.particles(t)` returns `new n(...)` where `n = s` and `s = i(29747)`. So `add.particles` returns an instance from module 29747. Let me look at module 29747 — likely the new ParticleEmitterManager or a unified emitter. The warning says ParticleEmitterManager was removed. So module 29747 is something new. Let me check its methods.

Let me search for what's exported/defined around 29747. Actually, let me just search for "emit" method and how emitters are created in the new API. The new API in Phaser 3.60: 

```js
let particles = this.add.particles('key'); // returns ParticleEmitterManager
let emitter = particles.createEmitter({...});
```

But createEmitter throws here. So maybe the new way is different. Let me look at how the docs/examples use it in 3.80. Let me check the phaser examples in the pi docs.

Actually, let me reconsider. In Phaser 3.60+, the ParticleEmitterManager was indeed replaced. The `this.add.particles(key)` now returns a `ParticleEmitterManager`? No — the warning explicitly says ParticleEmitterManager was removed. So `add.particles(key)` with a string returns a new object of class from module 29747, which warns. 

Let me look at module 29747 definition.

That's not it. Let me search differently. The `n` is `s` and `s = i(29747)` only after reassignment. Actually in the add.particles code: `var s=i(29747),n=s,r=s;`. So n = s = whatever module 29747 exports. Module 29747: `t.exports=function(){}}`? That looks like a placeholder. Hmm, the awk found `29747:t=>{t.exports=function(){}}` which is a stub. That can't be the emitter manager.

Wait, maybe module 29747 is the actual emitter manager but defined elsewhere. The `t=>{t.exports=function(){}}` might be a different module numbering due to how I split. Let me search for the real particle manager name and methods.

Let me grep for `emit` method and `ParticleEmitter` and methods like `setConfig`, `managerFromGameObject`, etc. Actually, let me look at Phaser 3.80 docs approach. 

In Phaser 3.80, the particles API:
```js
const emitter = this.add.particles(0xff0000);  // color instead of texture?
```
Hmm. Actually the new API lets you pass a color or a config. Let me recall the refactor.

Actually, I think in 3.60+, the way is:
```js
this.add.particles('textureKey');  // returns ParticleEmitterManager
this.add.particles('textureKey').createEmitter(config);
```
But createEmitter throws. So that's not it.

Let me check the docs file in the pi package: docs/sdk.md or search for "particles". Let me look at the phaser docs that ship with pi. The docs mention phaser... no, those are pi docs.

Let me instead grep for how `add` registers `particles` and the class with `emit`.

Hmm, the `particles:function` isn't found with that pattern. Let me search for the add.particles registration more broadly and the methods of the returned object. Let me grep for `createEmitter` is a throw. Let me search for what methods the particles manager exposes — maybe `addEmitter`?

So the new ParticleEmitter is created via a config object. The `add.particles(key)` returns a manager (module 29747). The manager has methods. Let me find what methods the manager has. Let me search for the manager class definition and its methods like createEmitter replacement. Let me search for `ParticleEmitterManager` string and the class.

Actually, let me reconsider. There are events EXPLODE, START, STOP, COMPLETE. So the manager has `.explode()` etc. The error was specifically `createEmitter` removed on the manager. So maybe in 3.80, you create an emitter via `this.add.particles().createEmitter`? No it throws.

Wait — maybe the issue: `add.particles('explosion')` with a string triggers the warning AND returns a manager, but then `createEmitter` on THIS build is removed because the manager auto-creates emitters from config. Actually let me re-read: `createEmitter:function(){throw new Error("createEmitter removed...")}`. This `createEmitter` method exists on the manager and throws. So the manager no longer supports createEmitter.

Hmm, but how do you create an emitter then? Let me look at the Phaser 3.80 docs: The new API (3.60+) for particles is:

```js
const particles = this.add.particles('particleKey');
const emitter = particles.createEmitter({ ... });
```

No, that's the old. Let me check the actual Phaser 3.80 source/docs. 

Actually, I recall now: In Phaser 3.60, the Particle system was refactored so that `this.add.particles(key)` returns a `ParticleEmitterManager`, and `createEmitter(config)` still exists but the *string-based* constructor `new ParticleEmitterManager(scene, textureKey, ...)` was removed. The warning "ParticleEmitterManager was removed" is misleading/wrong, or refers to the class being internal.

But here createEmitter throws. So in THIS build (3.80.1), createEmitter genuinely throws. That's the actual current API behavior. So the migration: use `particles.addEmitter(config)` or pass config directly to `add.particles(config)`.

Let me find the new method. Let me search for methods on the manager: maybe `addEmitter`. Let me grep.

No `addEmitter`. Let me look at the manager's definition. The manager is module 29747 — but I found it's a stub `t.exports=function(){}`. That means `add.particles` returns `new n` where n = s = module 29747. If module 29747 is `function(){}`, then `new n(...)` returns an empty object. That can't be.

Wait, re-read: `var s=i(29747),n=s,r=s; ... this.displayList.add(new n(this.scene,t,e,i,s))`. So `n` is the class. But module 29747 exports `function(){}` (stub)? But then `new n` would be useless. Unless I misparsed. The awk found `29747:t=>{t.exports=function(){}}` — maybe that's a different module 29747 from a later chunk? Module IDs in webpack are unique. Hmm, but maybe the regex caught a different 29747 occurrence. 

Actually wait — there might be TWO different things. Let me re-examine. `s=i(29747)` at the add.particles registration. Let me look at the real definition of module 29747.

Actually, this is getting too deep. Let me just consult the official Phaser 3.80 docs which ship in the pi package? No, phaser docs aren't in pi package. 

Let me think about the actual Phaser 3.60+ particles API from memory and verify by checking the build. The Phaser 3.60 changelog: "Particle Emitter Manager has been replaced. The new ParticleEmitterManager class..." Hmm.

Actually, I recall the real change in 3.60: `this.add.particles(key)` returns a `ParticleEmitterManager`, and `createEmitter` still works. But this build throws on createEmitter. So either my memory is wrong or this is a custom build.

Let me actually test in the browser console what `add.particles` returns and its methods. Let me open the browser and inspect. Actually, let me write a tiny test. But the browser tool runs index.html. I can add a temporary debug. Or I can check via the devtools console using the inspect action. Let me use the browser inspect to get console access? The inspect action returns DOM/console but not interactive console.

Better: let me just probe the phaser module to find the manager class methods. Let me search for the class that has `explode` method (since EXPLODE event and emitter.explode exist). The emitter itself has `.explode()`. So maybe `add.particles(key)` returns the emitter directly (not a manager)? Then `.explode()` works and `.createEmitter` doesn't. Let me check: the warning is when passing string to `add.particles`. Maybe the string form returns a ParticleEmitterManager, but the NEW recommended is `this.add.particles()` with no key returns a manager, and `manager.addEmitter(config)`... but addEmitter wasn't found.

Let me look again. The build shows `createEmitter:function(){throw...}`. Let me find what the manager actually is. Let me look at the registration of `add.particles` more fully.

Let me find where `add.particles` is defined — it's likely registered as `particles: function(...)`. Let me search for `"particles"` near where methods are assigned. Actually, the GameObjectFactory. Let me look at the broader context around `new n(this.scene,t,e,i,s)` and what `n` is and what class is at module 29747.

Let me directly look at the phaser.min around "ParticleEmitterManager was removed" and the surrounding class.

Actually, the cleanest path: just consult the Phaser 3.80 documentation online knowledge. I'm fairly confident the modern API (3.60+) is:

```js
const emitter = this.add.particles('textureKey').createEmitter(config);
```

But this build throws on createEmitter. Hmm. Let me reconsider — maybe `createEmitter` throws because of how I'm calling it? No, it unconditionally throws.

Wait, maybe the change is: `this.add.particles()` (no args) returns a ParticleEmitterManager; you then set textures via `emitter.setTexture` or pass config. And `createEmitter` is removed in favor of passing the config to the manager constructor: `this.add.particles({ ...config, texture: 'key' })` returns... 

Let me actually inspect: I'll write a tiny scratch HTML that loads phaser and prints `Object.getOwnPropertyNames` of `add.particles('x')` and its prototype. Let me do that with the browser tool by making a temp file and reloading, checking console.

Actually simpler: let me search the phaser min for the manager's method names by locating the class that has `explode` as a method (not the event constant).

Wait, I removed index.html with `rm -f index.html`? No, I wrote probe.html to /tmp/job-KL683o/probe.html. Then I ran `rm -f index.html`? No, the command was `rm -f index.html && cp index.html.bak index.html`. index.html.bak doesn't exist, so the cp fails and index.html is removed! Let me restore it.

Actually the command was: `rm -f index.html && cp index.html.bak index.html 2>/dev/null; ls`. This removes index.html! Bad. Let me rewrite index.html. But first let me run the probe to understand the API. Let me run probe.html in the browser. But the browser runs index.html by default? The browser action probably loads index.html. Let me check how to load probe. I'll temporarily make probe the index? The browser tool reloads "index.html" presumably. Let me instead just rename.

Actually, I need to restore index.html quickly. Let me rewrite it (I have the content). But first, let me run the probe to learn the API. Let me copy probe to index.html temporarily to inspect console.

Let me make index.html = probe content temporarily, run browser reload/inspect, capture methods, then rewrite the real index.html.

`Phaser.Utils.Object.GetObjectKeys` doesn't exist in this build. Let me use a simpler probe: just log the methods via `Object.getOwnPropertyNames(man)` and `Object.getOwnPropertyNames(Object.getPrototypeOf(man))`, and test `createEmitter` and maybe `addEmitter`/`setEmitter`/`start`. Let me fix the probe.

Now I understand. The `add.particles('dot')` returns the emitter itself (a ParticleEmitter, not a manager). It has `setConfig(config)` method. So in Phaser 3.80, the new API is:

```js
const emitter = this.add.particles('key');
emitter.setConfig({ x:100, y:100, speed:{min,max}, lifespan, quantity, ... });
emitter.explode(count); 
```

Wait, but the warning "ParticleEmitterManager was removed" — that's just because we pass a string texture key; it warns but still returns an emitter pre-configured with that texture. Actually the OWN properties list includes `texture`, `frame`, `frames`, etc. So `add.particles('dot')` returns an emitter with the texture set. Good. So it IS an emitter, not a manager. The warning is just noise (misleading). 

So the API:
- `emitter = this.add.particles('textureKey')` → returns a ParticleEmitter with texture set.
- Configure via `setConfig({...})`.
- Methods: `explode(count, x, y)`, `start()`, `stop()`, etc. The emitter has `.explode()`, `.start()`, `.stop()`, `.setConfig()`.

Let me verify: the METHODS list includes `setConfig`, and earlier we saw event constants EXPLODE etc. And `emitter.explode` exists (used in my original code `explosionParticles.explode(14)`). But I created it via `createEmitter` which throws.

So fix: replace `this.add.particles('explosion').createEmitter({config})` with passing a config object to `add.particles` OR calling `setConfig`.

Let me check: does `add.particles(configObject)` work? The warning triggers when first arg is a string. If I pass an object/config, no warning, returns emitter. Let me test `add.particles({texture:'dot', x:100, y:100, speed:50, lifespan:500})` returns emitter with config applied? Let me probe quickly. Actually safer: `this.add.particles('dot')` then `emitter.setConfig({...})`.

But for the explosion emitter that's reused (setPosition then explode), I need an emitter with on:false. `setConfig` can set `on:false`. Let me test `setConfig` with on:false and explode.

Actually, let me reconsider my design. The original code:
```js
explosionParticles = sc.add.particles('explosion').createEmitter({x:0,y:0,...,on:false,depth:4});
explosionParticles.setPosition(x,y);
explosionParticles.explode(14);
```
New version:
```js
explosionParticles = sc.add.particles('explosion');  // emitter with texture
explosionParticles.setConfig({ x:0,y:0, speed:{min:60,max:220}, angle:{min:0,max:360}, scale:{start:0.55,end:0}, alpha:{start:1,end:0}, lifespan:500, quantity:8, on:false, depth:4 });
```
Then `setPosition` and `explode(14)`.

But does `explode` work on a `on:false` emitter? `explode(count, x, y)` emits immediately regardless of on state. Should work.

For the createSpark, I do `sc.add.particles('explosion').createEmitter({x,y,on:false,...})` then `p.explode(3)` and `scene.time.delayedCall(300, ()=>p.destroy())`. New: `const p = sc.add.particles('explosion'); p.setConfig({...}); p.explode(3); ... p.destroy();` But does emitter have destroy? It's a GameObject; yes destroy exists. Good.

Let me test the full new approach with a probe to be sure setConfig + explode + setPosition works. Let me update probe.

Actually, let me just verify `explosionParticles.setPosition` exists — it's a component. The METHODS list includes setPosition, setConfig, setDepth, etc. And there's `explode` likely (event constant but also a method). Let me verify explode is a method. Earlier constants: EXPLODE is an event. The method `explode()` — let me grep. My original code called `explosionParticles.explode(14)` and it didn't throw at runtime because createEmitter threw first. Let me verify explode exists as method on the emitter.

Let me just rewrite the game with the new API and test. Let me probe setConfig+explode quickly to be safe.

The new API works: `setConfig`, `explode`, `destroy`, `start` all available. The warning about ParticleEmitterManager is harmless (just passed a string texture). 

Now let me rewrite the real index.html with the fixed particles API. Let me also reconsider the `createSpark` function — instead of creating/destroying emitters repeatedly, I could reuse one emitter, but creating a temporary one is fine.

Let me also reconsider: the `explosionParticles.explode(14)` — when called multiple times, it emits 14 more at current position. Good.

One concern: `em.setConfig` with `on:false` — does `explode` still work regardless? Yes, explode is one-shot. Good. The probe's explode worked (no error). And it didn't throw. Good.

Now let me rewrite the full game. Let me also double check a couple of potential issues:

1. `cursors.left.isDown` — for custom keys W/A/S/D, addKeys returns Key objects with isDown. Good.

2. `player.body.setCircle(0)` then `player.body.setSize(40,24)` — setCircle(0) might create a 0 radius circle; then setSize makes a rect. Actually mixing circle and setSize is odd. Let me just use setSize(40,24). Remove setCircle. The player texture is 40x24; body matches. Good. Set offset 0.

3. For aliens, `alien.body.setCircle(14); alien.body.setOffset(2,2);` — matches circle texture (32x32, circle r14 centered at 16,16; body circle at 14 centered, offset 2 so the circle center aligns). Fine.

4. `projectiles.createCallback` — in Phaser 3.80 Arcade group, the createCallback is invoked when a child is created via the factory (get). But does setConfig of createCallback work when assigned after group creation? Arcade group createCallback is called from `get` → `create` (createCallback). When I assign `projectiles.createCallback = function(child){...}` after `add.group(...)`, does it apply to future created children? The group's createCallback is a property used during create. If I assign to it after construction, and `get` calls `this.createCallback` internally (not a captured closure), it should work. Let me verify: Arcade physics group `createCallback` is an instance property; `get` calls `this.createCallback`. Assigning it should take effect. But to be safe, I can pass it in the config: `sc.physics.add.group({ defaultKey:'projectile', maxSize:60, runChildUpdate:true, createCallback: fn })`. However, createCallback's `this` is the group, and the child is passed. But the config createCallback is bound? Let me just pass via config. But the function references module-level `projectiles`? circular. Let me define inline.

Actually, there's a subtlety: in Phaser 3, when you provide `createCallback` in the group config, it's called with the child as argument. Let me pass it in config. But the child (projectile) needs `body.setAllowGravity(false)` etc. Also `runChildUpdate:true` will call `child.update()` each frame — but does Arcade group runChildUpdate call update on ArcadeSprite? It calls the child's `update` method if it exists. ArcadeSprite doesn't have a custom update by default. If I assign `proj.update = fn`, the group's update loop (if runChildUpdate) calls `child.update()`. Let me verify runChildUpdate works for ArcadeSprite. The group's `update` (called each scene step if `runChildUpdate` or `runChildUpdate` configured) iterates children and calls `child.update()`. Actually the Scene update loop calls `group.update()`? No — Arcade groups with `runChildUpdate:true` are automatically updated because the scene's update loop iterates `scene.children`? Hmm.

Actually, in Phaser, the Arcade Physics group's children are updated by the scene's update loop only if the group's `runChildUpdate` is true? Let me recall: There's a mechanism where the scene update calls `this.children.each` for groups with `runChildUpdate`. Actually, I think the group's `update` method is invoked by the scene's update loop if the group is a `Group` (not necessarily physics). For physics groups, there's `scene.physics.world` updating bodies. The `runChildUpdate` flag makes the group call each child's `update()`.

Hmm, I'm not 100% sure the child `update` will be called. Let me avoid relying on it. Instead, I'll handle bullet cleanup in my own update loop by iterating `projectiles.getChildren()` and disabling off-screen ones. That's more reliable.

So remove `runChildUpdate` and `createCallback` complexity. Let me set projectile properties via a helper when firing (already done). And in update, after firing, the bullets exist; I'll iterate children and recycle off-screen ones.

Let me restructure:
- projectiles group (no runChildUpdate): `sc.physics.add.group({ defaultKey:'projectile', maxSize:60 })`.
- In fireProjectile, configure the got sprite.
- In updateOverlappedBullets, iterate children; for inactive/disabled bodies, recycle via disableBody or remove.

Actually, when a bullet is hit by alien overlap, I call `proj.disableBody(true,true)`. That sets body inactive. The child remains in group. `get` reuses inactive children. Good. So I don't even need the manual cleanup if bullets are recycled on hit. But bullets that fly off-screen without hitting need cleanup. Without runChildUpdate, they won't auto-recycle. So I need manual cleanup for off-screen bullets. Let me iterate children in update and disable off-screen ones (reuse via get). When I `disableBody(true,true)`, the body becomes inactive and `get` will reuse it. But I should NOT `destroy` (so it stays in pool). DisableBody is enough.

But wait: if I `disableBody(true,true)` an off-screen bullet, then `projectiles.get` next fire reuses it. Good. But the group's getChildren() will still list it; in overlap, disabled bodies are skipped. Good. So in updateOverlappedBullets, I can remove the manual destroy and just leave disabled ones; new fires reuse. But disabled ones accumulate in getChildren until reused. With maxSize 60, fine. Let me just rely on get() reusing.

Actually there's a catch: `disableBody(true, true)` — the second param `hide` sets visible false; the first `disable` sets body inactive. `get` reuses children whose `body` ... actually `get` reuses the first child that is `!active`. Arcade group `get` checks `child.active === false` to recycle. `disableBody` sets `active`? Let me check: `body.disable?` The body has `enable` property; `setActive`? Hmm. The group's `get` reuses children where `!child.active`. When we `disableBody`, does it set child.active=false? I think `disableBody(true, true)` also deactivates. Actually, let me check: GameObject `setActive(false)`. The body method `disableBody(disableGameObject, hideGameObject)` — if disableGameObject is true, calls `this.gameObject.setActive(false)`? Let me verify. In Arcade.Body.disableBody: `if (disableGameObject) { this.gameObject.setActive(false); }`. Hmm, actually I'm not fully sure. Let me check the source behavior by testing, OR avoid the uncertainty.

Alternative simpler approach: For bullets, just `destroy()` them on hit and on exit, and create new sprites each fire (no pool). Since bullets are cheap (max ~60 alive), creating/destroying is fine. Overlap with a plain group: when children are destroyed, `getChildren()` includes them but with `body===null`; Arcade overlap iterates `getChildren()` and accesses `child.body` — if null, the overlap's per-body processing skips bodies that are destroyed? Let me check: Arcade overlap `overlap` → `computeEsc` → for each pair, checks `if (!body1 || !body2) return;`. Actually `overlap` uses the body manager which maintains active bodies; destroyed sprites are removed from the physics world, so they won't be in the body lists. So overlap won't see them. So destroying bullets is safe — overlap iterates physics body lists, not group children, for actual collision pairs. Wait, Arcade overlap iterates `this.bodies` (the body tree) entries, not the group's children directly. So destroyed bodies are gone from the body manager. Safe.

Hmm, but the group's `get` with a destroyed child — `get` checks `child.active`? If destroyed, child.active=false (destroyed sets active false). `get` would try to reuse it but its key... Actually for a non-pooled (maxsize 0 / no reuse), `get` creates new. If maxSize set, get recycles dead ones — but a destroyed (not disabled) sprite can't be reused (it's gone). `Group.get` when reusing: it does `child = this.getFirstDead(); if (child) { reset it }`. getFirstDead returns children with alive=false but not destroyed. A destroyed sprite is removed from the group entirely? When you call `sprite.destroy()`, and it's in a group, Phaser removes it from the group? No — destroy on a GameObject dispatches 'destroy' and the parent removes it. The Group has an `onChildRemove` / `onDestroy` that removes from its `children` list? Group adds a listener for 'destroy' on children to remove them. Yes! Arcade Group listens to child destroy and removes from children list. So destroyed sprites are removed from the group. So no stale references.

Therefore, using destroy() for bullets is clean IF the group listens to child destroy. Group does. Let me confirm Phaser Group removes destroyed children: Yes, `Group#destroy` and the child removal via `on('destroy', ...)`. Actually Group has `_remove` on child destroy? I recall the GameObject's `destroy` calls `parent.remove` if parent is a Container; but Group is not a Container in the scene graph sense but has `children` list (a List). When a child is destroyed, the List's `onChildDestroy` removes it. Phaser's List class listens for the child's onDestroy. So yes.

OK so approach: bullets group with maxSize (say 0 = unlimited? or 80). On hit: `proj.destroy()`. On exit (manual check in update): `proj.destroy()`. Overlap iterates body manager, ignoring destroyed. Clean.

But maxSize with destroy: if maxSize is set, get recycles only non-destroyed dead ones; since destroyed are removed from group, get creates new ones when at maxSize and none dead. Actually if maxSize reached and all alive, get returns null (no creation). With destroy removing children, the count stays low. Let me set maxSize to 80 to be safe, and if get returns null (rare), skip firing. Or set no maxSize (maxsize=0? In Phaser, group maxsize default... Group default maxSize is 0 meaning unlimited? Actually default is 0 = unlimited). Let me set `maxSize: 0`? The Arcade group `maxSize` default 0 means unlimited? I think 0 = unlimited for groups. Let me just not set maxSize → unlimited. Then get always creates. But get without maxSize... `Group.get` with no maxSize creates new if none available. Good, unlimited bullets (but destroyed removes). Fine. Memory: max ~60 bullets at a time anyway due to exit-kill. Good.

Hmm wait, if I use the pool with defaultKey and maxSize unset, does `get` still create new sprites? Yes, Group.get creates a new child if none available, using defaultKey. Good.

So let me drop createCallback and runChildUpdate; configure bullets in fireProjectile; clean up off-screen in update by iterating getChildren and destroying those out of bounds; on hit, disableBody? No, destroy. Let me use destroy for bullets.

But `disableBody` for reuse recycling is more efficient than destroy+create. But destroy is simpler and safe. Given small counts, destroy is fine. Let me use destroy.

Wait, but there's the `outOfBoundsKill` / checkWorldBounds approach which auto-handles exit without manual iteration. Let me use that: set `proj.body.checkWorldBounds = true; proj.body.onWorldBounds = true;` and add a worldbounds callback to destroy. The physics world emits 'worldbounds' event with the body. I can do:
```js
scene.physics.world.on('worldbounds', (body) => {
  if (body.gameObject && body.gameObject.destroy) body.gameObject.destroy();
});
```
But this global handler handles all worldbounds exits including potentially others. Only bullets use it. But the player has collideWorldBounds (setCollideWorldBounds) so player doesn't trigger exits. Aliens don't. So the worldbounds handler only affects bullets. Good. But I must set `body.onWorldBounds = true` on bullets and ensure world bounds exist (setBounds done). 

Actually, when a bullet hits the world bound, the 'worldbounds' event fires with the body. I destroy the bullet. Clean. Let me use this — no manual iteration needed. Remove updateOverlappedBullets.

But careful: `scene.physics.world.on('worldbounds', ...)` — the callback receives (body, gameObject, ...). Let me destroy `gameObject`. Good.

But there's a subtle issue: if a bullet goes out of bounds and also overlaps an alien same frame, both handlers run. Destroying twice is safe (second call no-op). Fine.

For alien recycling on death: I'll destroy aliens too (not disableBody) for simplicity. When an alien is destroyed, it's removed from the group and body manager. The overlap still works for remaining aliens. The `aliens` group is used in overlap; destroyed removed. Good. So killAlien just `alien.destroy()` and splice from alienList. No reuse, but fine.

But wait, `aliens.get` with no maxSize — if I destroy aliens, get creates new. Good. No maxSize set → unlimited. Good.

Hmm, but earlier I set `aliens.get(x,y,'alien')` — get with a key argument creates a sprite with that key. Good. Works without defaultKey.

So let me simplify groups:
- `projectiles = sc.physics.add.group()` (no defaultKey needed if I create via get with key). Actually `group.get(x,y,'projectile')` works without defaultKey. Let me keep a defaultKey for cleanliness but it's optional.
- `aliens = sc.physics.add.group()`.

Let me rewrite with destroy-based cleanup and the worldbounds handler.

Let me also reconsider `runChildUpdate` removal: then nothing auto-updates bullets except physics velocity (set at fire). Good. Bullets fly; worldbounds kills them. 

Now let me also reconsider the player body: `player.setCollideWorldBounds(true)` — with world bounds set, player bounces/stops at edges. By default collideWorldBounds sets velocity to 0 on impact (no bounce). Good, player stops at walls. 

Edge: `player.body.setSize(40,24)` default offset fine.

Now let me also handle: when the player rotates to aim, the ship sprite rotates but the body (circle/rect) stays same orientation (Arcade bodies are axis-aligned rects; rotation doesn't affect body). So collisions are with the bbox regardless of facing. That means the player can be hit even if visually facing away. Acceptable for this game. Alternatively use a circle body. Let me keep rect. Fine.

Actually for a shooter where the ship aims with mouse, an axis-aligned hitbox is fine.

Let me also double-check `Phaser.Math.Angle.Between` returns radians and `sprite.rotation` expects radians. Yes.

Now, the muzzle offset 16: for a 40-wide triangle tip at x=36, center 20 → offset 16. Good. So `Math.cos(angle)*16`, `Math.cos(angle)*16`. Good. Earlier I wrote 16. Good.

Now let me also verify the `tweens` damage flash using alpha doesn't conflict with the damage flash for aliens (alpha 0.4 then tween to 1). Good.

Let me also fix: in `killAlien` and `destroyAlien` I used disableBody earlier; switch to destroy + splice.

Let me also ensure `onBulletHit`'s early return: `proj.disableBody` → change to `proj.destroy()`. And check alien active/body. Let me rewrite onBulletHit:
```js
function onBulletHit(proj, alien) {
  if (!alien || !alien.body || !alien.body.enabled) { if(proj) proj.destroy(); return; }
  proj.destroy();
  alien.health = (alien.health||1)-1;
  if (alien.health<=0){ killAlien(alien); addScore(100, alien.x, alien.y); createExplosion(alien.x, alien.y); }
  else { alien.setAlpha(0.4); scene.tweens.add({targets:alien, alpha:1, duration:140}); createSpark(alien.x, alien.y); }
}
```

killAlien:
```js
function killAlien(alien){
  const i=alienList.indexOf(alien); if(i>=0) alienList.splice(i,1);
  alien.destroy();
}
```

createSpark: make a temporary emitter:
```js
function createSpark(x,y){
  const p = scene.add.particles('explosion');
  p.setConfig({x, y, speed:{min:40,max:100}, angle:{min:0,max:360}, scale:0.3, alpha:{start:0.8,end:0}, lifespan:220, quantity:3, on:false, depth:5});
  p.explode(3);
  scene.time.delayedCall(300, ()=>p.destroy(), null, scene);
}
```

Wait, setConfig x,y as numbers (fixed position) — fine, emitter at fixed pos. But spark should be at x,y. setConfig {x,y} sets emitter position. Good. Then explode(3). The emitter is on:false but explode works. Then destroy after 300ms. Good.

For explosionParticles (reused): setConfig at creation with x:0,y:0, then setPosition(x,y) then explode(14). Good.

Now, the worldbounds handler:
```js
scene.physics.world.on('worldbounds', (body) => {
  if (body.gameObject) body.gameObject.destroy();
});
```
But this fires for the player too if it ever exits bounds — player has collideWorldBounds so it can't exit. Good. Only bullets. But to be safe, check it's a projectile? I can tag bullets: `proj.isBullet = true;` and in handler only destroy if body.gameObject.isBullet. Let me add the tag to be safe.

Now let me also double check `proj.body.onWorldBounds = true` and `proj.body.checkWorldBounds = true`. Setting `body.checkWorldBounds=true` makes the body check world bounds each frame; if it was already out, hmm. And `onWorldBounds=true` triggers the world event. Need to ensure world bounds exist. `scene.physics.world.setBounds(0,0,W,H)` done. Good.

Now, one concern: `proj.body.setAllowGravity(false)` — gravity is 0 globally, but fine to set.

Let me also reconsider whether `scene.physics.add.overlap(projectiles, aliens, onBulletHit, null, sc)` works with the scope being `sc`. Phaser calls callback as `callback.call(scope, ...args)`. So inside onBulletHit, `this` = sc = scene. But I use module-level `scene` not `this`. Fine. But I pass `sc` as scope — okay.

Actually, Phaser overlap callback: `callback.call(callbackScope, object1, object2)`. So onBulletHit gets (proj, alien) with this=scene. Good.

Now `onPlayerHit(playerSprite, alien)` similar.

Now let me reconsider `updatePlayer` — using setVelocity each frame and clamping. The `cursors` keys default isUp until created; after create they exist. Good.

Also need to disable default browser selection? WASD might scroll the page if it contains those? WASD on a div won't scroll typically. But W/S could scroll vertically. The game canvas captures focus? The #game div isn't focusable. Keyboard events target window. WASD won't preventDefault, so W/S might scroll the page. To prevent, add `window.addEventListener('keydown', e=>{ if(['W','A','S','D',' '].includes(e.key)) e.preventDefault(); })` and set `html{height:100%;overflow:hidden}`. Let me add overflow:hidden and a keydown handler. Actually the tip div is HTML; the canvas is in #game. The page is 1000x800, viewport 1200x800 — no scroll needed horizontally. Vertical: 800 < 800? viewport height 800, game 800, no scroll. But W/S might still try. Let me add preventDefault for WASD and set `html,body{height:100%;overflow:hidden}`. I already have overflow:hidden. Good enough; plus a keydown preventer for safety.

Let me also set `scene.input.setKeyboard ? keyboard` — Phaser keyboard is on window. preventDefault via `cursors` — Key objects have `preventDefault`? Each Key has setPreventDefault? Not by default. Let me add a raw listener. But adding `input.keyboard.addKeys` — the keys will have default behavior unless I set. Let me just add `window` keydown preventer for WASD and Space and Arrow keys to stop scrolling.

Hmm, but the browser tool's viewport — scrolling isn't a big concern since height fits. Let me add overflow:hidden (done) and a small keydown guard. Fine.

Let me also ensure left-button firing only, not right-click context menu. Since firing uses `leftButtonDown()`, right-click won't fire. Context menu on right-click might popup; let me `scene.input.on('pointerdown',...)`? I'm using isDown+leftButtonDown. Right-click: leftButtonDown false → no fire. Good. Also add `document.body.oncontextmenu = ()=>false` to prevent menu. Let me add.

Now let me rewrite the full index.html with these fixes.

Also, `overlay.getAt(4)` — I built overlay container with children [ov,title,finalScoreText,hint,restartBtn] (5 items, indices 0-4). getAt(4) = restartBtn, not hint! The hint is at index 3. Let me fix the index or store hint reference. In endGame I do `overlay.getAt(4)` expecting hint. Let me instead keep references to title, finalScoreText, hint as variables and not rely on getAt. Let me make them module-level.

Let me store `goTitle, goScore, goHint, goBtn`. And overlay container holds them. On visibility toggle, container.setVisible toggles all. To update text, use the refs.

Let me rewrite.

Also `overlay = sc.add.container(0,0,[...])` — container at (0,0) with children positioned abs. setVisible(false) hides container and children. Good. But interactive on restartBtn inside a hidden container — when container visible again, button interactive. Should work because the button is a child with its own input. Actually, children of a Container are added to the display list and input? Container children's input is managed; setInteractive on the text should work when container is visible. Let me verify—Container children do support input. Should be fine.

Alternatively, avoid container and just toggle each object's setVisible. That's more reliable for input. Let me do that: keep refs and toggle each. Let me not use a container; build discrete objects and a `setOverlayVisible(b)`.

Let me restructure overlay as a function toggling arrays.

Let me write:
```js
let overlayObjs = [];
function buildUI(sc){
  ... 
  const ov = sc.add.rectangle(...);
  goTitle = sc.add.text(...);
  goScore = sc.add.text(...);
  goHint = sc.add.text(...);
  goBtn = ...interactive...
  overlayObjs = [ov,goTitle,goScore,goHint,goBtn];
  setOverlay(false);
}
function setOverlay(on){ overlayObjs.forEach(o=>o.setVisible(on)); }
```
Cleaner. Let me do that.

Now write final file.

Let me also reconsider: the `tip` HTML div shows controls always. Good, satisfies "Display the controls on screen." Also I have an in-canvas controlsText that duplicates; the HTML div is enough but both is fine. Actually having HTML controls div overlay is good (always visible). Let me keep the HTML div and remove the in-canvas controlsText to avoid clutter? The HTML div is fine. But the in-canvas text is also fine. Let me keep the HTML tip only, and remove controlsText to simplify. Actually I'll keep HTML tip; remove the redundant canvas text. Let me remove controlsText.

Hmm, but the canvas might be the only thing styled. The HTML tip with #game positioned fixed fills. Let me keep the HTML tip. Remove controlsText variable.

Now let me also double-check: `this.add.particles('explosion')` triggers the warning "ParticleEmitterManager was removed" because arg is a string. That's just a console warning, not an error. The emitter still works. To avoid the warning, I could pass a config object: `this.add.particles({ texture:'explosion' })`? Let me test — does `add.particles(configObject)` return an emitter with the texture? The warning fires only when first arg is a string. To be clean, let me pass an object: `sc.add.particles({texture:'explosion'})`. Let me verify this returns an emitter. Actually, the new API: `this.add.particles(textureKey, x?, ...)?` Hmm. Let me just pass config object: `sc.add.particles({ texture:'explosion', x:0, y:0, ... })` then it's configured. But I already call setConfig separately. Let me try `sc.add.particles({texture:'explosion'})` and then setConfig. 

Let me quickly verify in probe whether `add.particles({texture:'dot'})` works without warning and returns emitter. Actually to save time, the warning is harmless; I'll keep passing the string. The game works. The warning clutters console but that's fine. But to be clean and avoid any chance the warning implies non-functional, the probe proved explode worked with string. So keep string. Fine. I'll keep string. The console warning is acceptable.

Actually, let me avoid the warning to keep the console clean for inspection. Let me pass the texture in setConfig instead: create emitter with `sc.add.particles()` (no arg, returns emitter with no texture?) then setConfig({texture:'explosion',...}). Hmm does add.particles() with no arg work? It would create an emitter with no texture; then setConfig texture. Let me test. Actually, simpler: keep the string; the warning is cosmetic. I'll keep it. Moving on.

Wait — there's a risk: in Phaser 3.80, passing a string to add.particles returns a ParticleEmitter that's pre-loaded with... the warning says ParticleEmitterManager was removed. But the probe showed it returns an object with texture set and setConfig/explode working. So functionally fine. Keep string.

Let me now also verify there are no other removed APIs I'm using: `scene.make.graphics({add:false})` and `generateTexture` — used in probe and original, works. `scene.add.particles` works (probe). `scene.physics.add.group` works. Good.

Now let me write the final, cleaned index.html.

Let me also reconsider the bullet worldbounds destruction timing: with BULLET_SPEED 620 and arena ~1000, a bullet crosses in <2s, exits quickly. Fine.

Let me also ensure bullets can actually overlap aliens. With Arcade overlap, both must have bodies. Bullets have bodies (sprite). Aliens have bodies. Good. Overlap doesn't require velocity collision, just proximity. Good.

Also `scene.physics.add.overlap(projectiles, aliens, onBulletHit, null, sc)` — overlap is checked continuously. Good.

Now, one concern: I set `proj.body.onWorldBounds = true` and `checkWorldBounds = true` at fire. With world bounds event, destroyed on exit. But also if bullet hits alien, I destroy it in onBulletHit. Good.

Let me also make sure bullets are destroyed when the scene is reset (restart): `projectiles.clear(true,true)` destroys all. Good.

Now, about `scene.physics.pause()` at game over then `resume()` — bodies remain; on resume, velocities persist. The player's velocity might be nonzero; on restart I setPosition and setVelocity(0,0). Good. Aliens: after pause, aliens exist but gameOver; on restart I clear aliens group. Good.

But when game over, there might still be aliens moving? physics.pause() freezes; fine. Overlay shows. Good.

Edge: After game over, `update` returns early, so aliens don't home. Fine.

Now, restart flow also needs to reset `player`'s position and the player shouldn't be mid-rotation. Fine.

Let me also double check: the `tip` HTML div is always shown even during game over (overlay covers center). Fine.

Let me write the final file now.

Also reconsider: `cursors = scene.input.keyboard.addKeys({...})` — keys W/A/S/D. These default preventDefault? No. So W/S could scroll. With body overflow:hidden and height 100%, no scrollbar, so no scroll. Fine. I'll also add `document.body.style.userSelect='none'`? Not needed.

Let me write final.

Let me reconsider the player ship aiming when mouse is at the player: angle 0 → points right. Minor cosmetic. Acceptable. Actually, to avoid the ship snapping weirdly when not moving mouse, it's fine.

One more: The player rotation uses `scene.input.activePointer.worldX`. For a stationary camera, worldX === pointer.x. Good.

Also need to ensure the player sprite's origin is (0.5,0.5) so rotation is around center. Default is 0.5. Set explicitly. Good.

Let me write.

Also, the `render` function empty — fine, remove to avoid confusion. Keep update only.

Let me write final index.html.

Let me also add a small "crosshair" dot at pointer for aim feedback? Optional. The ship pointing at mouse is enough. Skip.

Let me also make aliens slightly different sizes/colors for variety using tint. I can tint each alien with a random greenish hue. `alien.setTint(Phaser.Math.Between(0x55aa55, 0x88dd88))`? setTint with a color. Let me randomize tint for variety. Keep simple: one color. Actually variety is nice but let me keep the alien texture greenish-red. Fine.

Now, difficulty: waves increase count and speed. Good. Also alien health stays 1. Good enough. Maybe increase health on wave 4. Let me keep health=1 for reliability (so bullets kill in 1 hit → clear feedback). Later waves: more aliens + faster. Good.

Actually, to make later waves meaningfully harder (not just more), maybe aliens shoot back? Not required. Keep simple. More + faster satisfies "increasing enemy count or speed."

Let me finalize. Let me also bump the first wave count to ~10 for a meaningful opening, speed 60.

Let me write the file.

Let me reconsider the worldbounds handler registration — I'll add it in create. Also it might fire repeatedly while a bullet sits out of bounds before being destroyed; but we destroy it immediately, so fine.

Let me also ensure `scene.physics.world` exists before on('worldbounds'). In create, after setting bounds. Good.

Writing now.

For the health bar fill color change on low health — I set fillColor property. Phaser Rectangle fillColor is settable. Good.

Let me also handle `healthBarFill` width going negative on death — health clamped. In endGame, health 0 → pct 0 → width 0. Fine. Overlay appears.

Let me write final.

Let me reconsider: When player takes damage and health becomes 0, endGame called, physics paused. But takeDamage also tweens player alpha back to 1 — fine. And the red damage flash (tint? I used alpha, not tint). I used setAlpha(0.4) then tween alpha 1. That's a flash to 40% alpha (dim). Not very "red" but visible feedback. The requirement wants visible feedback for projectile hits (done) and player contact (the alpha flash + spark). Good enough. Maybe make player flash red via tint? Let me use both: setTintFill(0xff0000) then clearTint tween. But tint on a sprite with the blue texture → red overlay. Tween tint back. Let me do tint flash for player to be clearer:
```js
player.setTintFill(0xff0000);
scene.tweens.add({targets: player, duration:250, onComplete:()=>player.clearTint()});
```
And remove the alpha flash for player. Keep spark. Good.

For aliens, keep alpha flash (0.4→1). Good.

Let me finalize.

Now writing the real file.

Let me reload and inspect the game to verify it works.

`alien.body.clearVelocity is not a function` — `clearVelocity` isn't a method on Arcade.Body in this build? Actually Arcade.Body has `setVelocity(0,0)` or `velocity.set(0,0)`. `clearVelocity` might not exist. Let me use `alien.body.setVelocity(0,0)`. Let me fix.

Also the ParticleEmitterManager warning is harmless (string texture).

Let me fix `clearVelocity` → `setVelocity(0,0)`.

`alienList is not defined` — because in the IIFE, `alienList` is used in spawnWave but I declared it? Let me check. I declared `let score, health, wave` and `let goTitle...` but did I declare `alienList`? Looking back at my final file: I have `let overlayObjs = [];` but I forgot to declare `alienList`. In the first draft I had `let alienList = [];`. In the rewrite I removed it! Let me check. In the final write, the state declarations:

```
let scene, player, projectiles, aliens, explosionParticles;
let cursors, scoreText, waveText, healthBarFill;
let score = 0, health = MAX_HEALTH, wave = 1;
let gameOver = false, fireCooldown = 0, damageCooldown = 0, nextWaveTimer = 0;
let goTitle, goScore, goHint, goBtn;
let overlayObjs = [];
```

No `alienList`! I reference `alienList` in spawnWave (`alienList.push`) and killAlien (`alienList.indexOf`) and updateAliens and restartGame (`alienList = []`). Need to declare `let alienList = [];`. Let me add it.

No errors now. The only warnings are the harmless "ParticleEmitterManager was removed" (because we pass a string texture) and the GL driver warning (cosmetic). The game loaded without errors.

Let me now inspect the DOM to verify UI renders. Let me also do a screenshot to see the initial state.

Let me check the console/DOM output. The dom is just the tip text (HTML). Let me inspect the canvas via screenshot to verify the player, aliens, HUD.

Let me do a screenshot.

The screenshot didn't return an image (images: "model does not support images"). So the browser tool doesn't support images/screenshots in this environment. I'll rely on DOM and console inspection plus interactive testing via click/drag/key.

Let me verify behavior interactively:
1. Test movement: press W/A/S/D keys.
2. Test aiming: move mouse.
3. Test firing: click.

Let me simulate key presses and a click, then inspect console for errors.

Let me press 'W' key to move up, then click to fire.

Let me use the browser 'key' and 'click' actions. The viewport is 1200x800. Game is 1000x800, centered? parent div fills 1000x800. Click at e.g. (600,400) center.

Let me first do a key press 'W'.

Key press registered without error. Let me test firing by clicking near the center where aliens approach. Let me click at a point where aliens are (around the edges). Actually let me click somewhere to fire. Click at (800, 400) to fire toward right.

Let me click to fire and then check console for errors. Then wait a bit (no sleep tool, but I can do another action). Let me click a few times to simulate firing at aliens, then maybe movement keys to dodge.

Let me also test that firing works and hits produce no errors.

Firing works without errors. Let me move the player with WASD to confirm movement updates position and that I can dodge. Let me press a combination: A and S to move left-down. Actually I can press multiple keys sequentially. Let me press 'A' then 'S'. 

Actually, let me verify the player can move and that the game continues. The key actions are working. Let me also try to actually kill aliens by clicking on them. Since aliens approach from edges, clicking near center-right where aliens come. Let me click a few times to fire many projectiles and let them travel, then check.

Actually, the verification I can do here is limited (no screenshots, no direct game-state inspection beyond console). The behavior is working without errors. Let me do a bit more interaction: press movement keys and fire to confirm no errors under sustained use, and verify the HUD initial values.

Let me verify the initial HUD. The DOM shows the tip text. The canvas renders HUD but I can't see it (no images). Let me check the canvas DOM content via inspect.

Let me inspect the DOM to confirm canvas and elements exist.

The dom field only shows the tip text, meaning the #game canvas children may not be serializable in this tool. The console shows the game booted twice (two Phaser logs) — that's because the previous probe? No, I overwrote index.html with the real game. But the console shows two Phaser boot logs (two rows). That's because reload might retain previous console? Actually each reload adds console entries. The inspect might be showing cumulative. The two "Phaser v3.80.1" logs and two "ParticleEmitterManager" warnings suggest the page ran twice (maybe a previous iframe state). Not a big concern.

The dom field only shows the tip text — likely the canvas/webgl content isn't captured by the dom inspector (canvas is a single element, its children are WebGL). That's expected.

Let me do a more thorough interaction test: press WASD keys, move the player, fire a burst, and let time pass to see aliens advance. Since I can't see the frame, let me do a drag to simulate aiming while moving, then fire.

Let me press D (move right) and then click to fire, then S. Let me also try to actually hit aliens by clicking toward an edge where they spawn.

Actually, the key behaviors I need to confirm:
1. Movement works (W pressed OK).
2. Aiming: mouse moves (click action moves the pointer to 820,400, which the next fire used).
3. Firing produces projectiles (no errors).
4. Aliens advance (no errors).
5. Hits produce feedback (no errors — but I haven't confirmed a hit).

Since I can't visually confirm hits, let me try to deliberately kill some aliens by clicking near where they'd be. But they move toward center; clicking near center where they converge might hit them. Let me fire several clicks near center.

Let me do a few clicks near (600,400) and (550,400) rapidly to spray, then move away (WASD) to test player damage avoidance? Actually contact with aliens damages player; if I stay in center, aliens gather and damage. Let me move the player to a corner to test movement and survive.

This is getting into extended testing. Given time constraints (~4 min left), the core functionality is verified error-free. Let me do one combined interaction: drag the mouse across the canvas (simulating aim) while holding and clicking to fire, then press WASD. Let me do a drag then a key.

Let me do a drag from center to right (aim) then click.

Actually, let me just press all four movement keys once and fire a couple more clicks to confirm sustained no-error behavior. Then I'll finalize.

Let me press 'A', 'S', 'D' (movement), and click a couple times.

Movement and aiming work. Let me try to actually hit an alien by clicking near where they converge (center area). Let me click a few times near center to try to get a kill and confirm hit feedback. Let me click at (600, 400) multiple times — but fire rate cooldown 170ms. Let me click a couple times at different center points.

Actually, let me click near an edge where aliens spawn, e.g., top edge around (600, 50). Clicking there fires a projectile from player toward that point; if an alien spawns there, it might hit. Let me click a few times toward top-right area.

Actually, to verify kill + score + explosion feedback, let me click several times toward center-right where aliens from right spawn converge. Aliens move toward center, so at center-right there will be aliens. Let me click around (700, 400), (750, 400), (700, 380). The pointer click also sets aim. Let me do clicks.

Let me click at (720, 390).

No errors. I can't visually confirm hits without screenshots. Let me add a temporary console log to confirm hit/score works? That would require editing and reloading, costing time. Given I have ~3-4 minutes left, let me add a small console.log to onBulletHit and addScore to confirm in console that hits register. Actually, let me add a one-time confirmation log when a bullet hits or score changes, reload, fire, and check.

Actually, modifying to add logs is reasonable verification. Let me add a console.log in onBulletHit when an alien is killed, and in takeDamage. Then reload, fire at aliens, check console.

But adding logs and reloading costs ~30s. Worth it to confirm the core hit→feedback→score→wave logic.

Let me add minimal logs.

Wait, I added `if (health <= 0) return;` in takeDamage but that's before subtracting. That guard is wrong — takeDamage is only called from onPlayerHit which is fine. Actually if health already 0, endGame called once. The guard prevents double. But it's placed before the damage — if health is already 0 we'd return without doing anything, which is fine. But the log shows health before subtract. Let me keep it. Actually the guard `if (health <= 0) return;` means if already dead, ignore. Good. But note: endGame sets gameOver and pauses; update returns; onPlayerHit won't be called again since physics paused. Fine.

Now reload and fire to confirm logs appear. Let me reload then fire several shots at center where aliens converge.

Good, fresh load, only one Phaser boot, no errors. Now let me fire several shots toward center where aliens converge to try to get kills. Let me click a burst at the center area, e.g., a few clicks around (620, 380), (640, 400), (600, 420). The fire rate is 170ms. Let me click a few times.

The click at (640,380) — but that's the player center area. The player is at center (500,400). Clicking at (640,380) aims the ship toward that point and fires a projectile along that direction. Aliens approach from edges toward center, so around center there should be aliens. But one shot may miss. Let me fire more shots toward the edges where aliens come from. Let me click at top-right (800, 100) and bottom-right (800, 700) etc. to hit aliens as they emerge.

Actually, aliens spawn at edges and move toward center. So they pass through the center region. A shot from center toward an edge will travel along the direction; aliens come from the edge moving toward center, so they'd be hit along that line near center. One shot might hit one. Let me fire a few toward different edges.

Let me click at (900, 400) [right], (100, 400)[left], (500, 50)[top], (500,750)[bottom] — but the player stays at center. Each click fires one projectile toward that point. Let me do several clicks.

Let me click at (880, 400) rightward.

No kill log yet. The aliens are at the edges moving toward center, so my center shots might miss until they reach center. Let me move the player toward an edge to intercept, or fire toward the top edge where aliens spawn. Let me click at (500, 60) to fire upward toward the top edge where aliens emerge.

Actually, let me move the player toward the top edge so I can intercept aliens coming from top, then fire. But if I move away from center, the player is harder to protect. Let me instead fire multiple shots toward the top-right quadrant where aliens pass. Let me click at (700, 60).

Actually, the most reliable: move player to a corner and let aliens come, then they'll contact the player (taking damage) — but that tests damage. Or, to test kills, I should spray bullets across the arena. Let me click at several edge points rapidly. Fire rate 170ms though. Let me click a few different directions.

Let me click at (700, 80) top area.

Now I see `[dmg] player hit 3` — the player took damage from alien contact. So alien advancement and contact damage work. The player was hit (health 3 → 2, but log says "player hit 3" because I logged health before subtract — it logged 3, meaning the hit occurred). Good, this confirms aliens advance toward the player and contact damages.

Now let me confirm a kill. I haven't seen a kill log. Let me fire more toward where aliens are. The player got hit, meaning aliens reached center. They move fast and converge. Let me move the player to a corner to avoid immediate death and then sweep-fire. Actually, the player is at center taking damage. Let me move player away (WASD) and fire in bursts.

Actually, let me reconsider: the player got hit quickly because all 8 aliens converge on center and the player is there. With invincibility 900ms, the player can survive a few hits (3 health). I saw one hit. If I don't move, more hits come. Let me move the player to a corner and spray.

Let me move with D (right) and S (down) to the bottom-right corner, then fire toward the top-left where aliens come from center... actually aliens come from all edges. Moving to a corner reduces exposure from one side.

Let me instead test a kill: move player to top-right corner (D,U) and sweep fire across the arena. Let me press D and W to move to top-right.

Actually I want to verify kills + score + wave progression + game over + restart. That's a lot to verify interactively without visuals. The logs confirm: movement works, firing works, aiming works, aliens advance, contact damage works. The kill→explosion→score→wave→gameover→restart logic is implemented and error-free at the code level (no runtime errors thrown).

Let me try to get at least one kill log to confirm the hit-detection and score pipeline. Let me move the player to a corner and spray toward the center where aliens gather. Let me press 'D' and 'W' to move to top-right corner, then click toward center-left.

Let me press W then D.

The player is taking hits repeatedly (invincibility should prevent rapid re-hit, but each click/key triggers update). I see only one dmg log so far because of invincibility 900ms. Let me now move player near top-right corner and spray-fire toward the left side where aliens come. Let me click toward (100, 80) to fire across the arena. Let me click several points.

Actually, the player got hit once more possibly. Let me just fire several shots across the arena to get kills. Let me click at (100, 100) top-left area, then (150, 400) left, then (900, 100) top-right. These fire across the arena where aliens pass.

Let me click a few times. The fire rate is 170ms so clicks are debounced.

No kill log yet. The aliens are fairly small targets (radius 12) and bullets small (radius 5), and the player is now near top-right corner firing toward top-left. The aliens come from edges. Let me click toward the bottom-left and other edges. Actually, let me click toward the center where aliens converge heavily — that's the densest. But the player is now at top-right, so firing toward center. Let me click at center (500, 400) — but the player is at top-right (≈950, 90), so clicking center fires toward center-bottom-left, passing through where aliens gather. Let me click at (500,400) and a few around center.

Let me click center a few times.

Actually wait — the player might already be dead. I saw "[dmg] player hit 3" only once. With invincibility 900ms, and time elapsed maybe ~2s, another hit could occur. Let me check if game over happened — no GAME OVER log. So player still alive (took 1 hit, health now 2). 

Let me fire toward center. Click at (500, 400).

The player got hit again (a second `[dmg] player hit 3`? No, only one dmg log shown). Wait, the console now shows two "ParticleEmitterManager" warnings (one from initial, one... actually there were two — probably from the second Phaser boot). And one `[dmg] player hit 3`. 

The player is at top-right corner but still taking hits because aliens converge on the player's actual position (top-right), so they home to where the player moved. That's expected behavior. The player is being mobbed. 

I'm spending too much time trying to confirm a kill without visual feedback. The hit-detection logic is straightforward and error-free. The logs confirm: movement, aiming, firing, alien advancement, and contact damage all work. The kill/score/explosion pipeline is implemented identically with the same overlap mechanism (which is working for player-alien), so bullet-alien overlap will work too.

Let me do one more thing: to definitively confirm a kill, let me move the player to a safe corner and wait, letting aliens cluster, then fire into the cluster. But I can't "wait." Let me instead move player to bottom-left corner (A+S) and spray toward top-right center where aliens come from multiple edges.

Actually, the issue is aliens home directly to the player wherever they are. So they'll surround the player. To get kills, I need to fire where they are. Since they converge on the player, firing from the player toward incoming groups should hit. The bullets travel toward mouse; if I click near an alien cluster that's approaching the player, bullets should hit.

Let me move the player back toward center-bottom and fire toward the top. Let me press S and D to go to bottom-right, then click toward top center (500, 60) to fire upward through the convergence zone.

Hmm, this is taking too long. Let me take a more direct approach: temporarily increase bullet size/speed via a debug to guarantee hits? No, that changes the build.

Alternative: add a console log showing number of aliens alive and bullets per frame, to confirm they exist and are near each other. Let me add a log in update showing alienList.length and a sampled bullet/alien position proximity. Actually simpler: log when bullet-alien overlap is checked... but overlap only fires callback on actual overlap.

Let me add a periodic log (every ~500ms via time) of distance between nearest bullet and nearest alien, to see they're colliding. That's heavy. 

Better: Let me just trust the overlap mechanism (same one that produced the player-hit log) and confirm the kill pipeline by temporarily lowering alien health to make kills easier? No.

Actually, the cleanest confirmation: move player to a corner, let aliens cluster around the player (they home to player), then fire into the cluster (click at the player position so bullets spawn at player and aliens are surrounding the player → immediate overlap). When the player is surrounded and I fire, bullets spawn at the player nose and aliens are right on top of the player, so they should overlap immediately → kills.

But firing when surrounded: the player nose is at player.x+cos*16. Aliens are around player. A bullet fired toward a cluster should hit one. Let me move player to center (back to center) — but center is where damage is high. Hmm.

Actually currently the player is near top-right and being hit. The aliens are around the player. If I now fire toward the player's own position (click near player), bullets spawn at player nose and aliens are surrounding → overlap. Let me click right at the player's current location. The player is at top-right (≈950,90). Let me click at (940, 80) — near player. Bullets spawn at player nose pointing that direction, and aliens are surrounding the player → immediate hit.

Wait, clicking near the player: angle ~ same as player position, bullets fire outward from player along that angle. Aliens surround player, so a bullet going outward might pass through an alien that's just outside. Should hit. Let me click at (960, 100) and a few spots around the player.

Actually, simpler and guaranteed: fire straight along a direction where an alien just contacted the player (the contact means an alien is at the player). Let me click just beyond the player in some direction so the bullet travels through the cluster. Let me click at (1000, 200) etc.

Let me just click a burst at points just outside the player: (950, 50), (1000, 90), (980, 200). These fire bullets that immediately intersect the surrounding aliens.

Hmm, I'm overthinking. Let me just click rapidly several times around the player's area to spray. Let me click at (960, 70), (1000, 120), (920, 150).

Actually the player keeps getting hit and may die soon (health 2 after first hit; a second hit → health 1; third → death). If the player dies, I can test game over + restart! That actually verifies more behavior. Let me let the player die by not moving (stay cornered) — but the player is already cornered and being hit. Let me just wait by doing nothing / a couple more actions to register hits and trigger game over.

Currently at the top-right corner being hit. Health was 3, took 1 hit → 2. If I let aliens keep contacting (invincibility 900ms), after more time another hit → 1, another → 0 → game over. Let me trigger more time passage by doing harmless actions (key presses) to advance frames and register hits.

Let me press 'S' (move down) a couple times to advance time, and check for game-over log.

Actually I realize I haven't confirmed a kill which is the main gap. Let me do a focused spray into the cluster. Let me click at the player's location (around 960, 80) a few times rapidly to shoot into surrounding aliens.

Let me click (970, 90).

Still no kill log. The bullets might be missing because the player is surrounded and firing toward (970,90) means angle points up-right, but aliens might be more to the sides. Let me add a temporary debug that logs the minimum distance between any bullet and any alien each second, so I can see if they ever get close. Actually, let me add a periodic log of alienList.length and whether any bullet overlaps.

Actually, a simpler diagnostic: temporarily make bullets bigger and longer-lived and slower so they definitely hit. But that changes the shipped game.

Alternative: Let me add a debug log in the overlap process/overlap callback region. The onBulletHit is only called on actual overlap. Since I have a player-alien hit log working (same mechanism), the bullet-alien overlap should fire too if they overlap. The lack of kills suggests bullets miss aliens (small targets, spread shots). 

Let me add a periodic (every ~1s) console log of: number of bullets alive, number of aliens, and the minimum distance between any bullet and any alien. This will tell me if they get close. If min distance is large, bullets miss; if ~0, overlap should fire. Let me add via time.addEvent looping.

Actually, the overlap IS a continuous check. If bullets and aliens overlap at all, onBulletHit fires. Since it's not firing, the bullets genuinely aren't touching aliens. The alien hitboxes are circle r12, bullets circle r5 (well, bodies). The player got hit, meaning alien reached the player center. 

The issue: bullets travel fast (620px/s) and aliens also move (55-230/s toward player). From center-firing at corner aliens... The player is at top-right being surrounded; aliens are at the player. If I fire toward the cluster, bullets should hit. But clicking (970,90) when player is at ~(960,80): angle is toward (970,90) which is slightly up-right from player. Bullets fire up-right and immediately exit toward the top-right corner edge. The aliens surrounding the player are in all directions; firing up-right might pass between them.

Let me instead fire toward the player itself — but the pointer at the player gives angle 0 (or undefined) and bullet spawns at nose. If I click exactly at player.x,player.y, angle is 0 (right). Hmm.

Let me fire in multiple directions by clicking at points directly adjacent to the player in each direction: that sprays bullets in all directions, likely hitting surrounding aliens. Let me click (960, 60) [just above player], (980, 80)[right], (940, 100)[below-left], (920, 90)[left]. Let me do these clicks.

But fire rate 170ms between shots. Let me click several.

Actually, let me reconsider — maybe the overlap isn't working for bullets because I didn't enable something. Let me verify the bullet-alien overlap by adding a debug log in the overlap *process* or just trust. Let me add a periodic distance log to be sure they get close.

Let me add a time event logging min bullet-alien distance every 1s. This is a quick edit.

Actually, simpler diagnostic: temporarily set alien health to 1 and add a log in onBulletHit that logs "attempt" even when the alien check fails. But the function only called on overlap.

Let me add `scene.events.on('step')` or `time.addEvent`. Let me add a 1s loop logging counts and min distance.

Let me add this debug code in create.

Fresh load, only one Phaser boot, no errors. Let me wait a moment for the debug timer (1s) to fire. Let me do an action to advance time — press a key.

The debug log hasn't appeared yet (it fires at 1s; the key press was quick). Let me do a few more actions to advance time: click to fire several shots and wait. Let me click a burst at center and then check the debug log. Let me click at (500,400), (800,400), (200,400), (500,200), (500,600) to spray across the arena, then do a key press to let the 1s timer fire.

Now I see `[dbg] aliens=8 bullets=0`. So there are 8 aliens (wave 1 count = 8 + 0 = 8). Good. But bullets=0 — meaning no bullets are alive at the 1-second mark. That suggests bullets are being destroyed immediately, OR they exit the screen before 1s (unlikely—speed 620, arena 1000, so ~1.6s to cross). bullets=0 at 1s is suspicious.

Wait, maybe bullets are being destroyed by the worldbounds handler incorrectly, or they're not being created. Let me check: maybe `projectiles.get` returns null or the bullet is created but immediately destroyed.

Possible issue: `proj.body.checkWorldBounds = true; proj.body.onWorldBounds = true;` combined with `setCollideWorldBounds(false)` — but the bullet spawns at the player near center. It shouldn't be out of bounds immediately. But wait — the bullet's body might be considered out of bounds at creation if... no.

Actually, maybe `projectiles.get` with `defaultKey:'projectile'` is returning a sprite, but `proj.body.enable` is false by default for recycled? No, first call creates new.

Hmm, bullets=0 after 1s. Possibly the worldbounds handler destroyed them because `body.gameObject.isBullet` — I set isBullet on proj. But maybe the bullet's body goes out of bounds quickly? Speed 620. From center toward (500,200) goes up; it travels ~ to y=0 in (400)/620 ≈ 0.65s, then exits top (y<0) → worldbounds destroys it. So by 1s, the bullet that fired at ~0.3s ago has exited. But I fired multiple shots; bullets fired at different times. At 1s mark, some bullets should still be in flight (fired recently). Unless all bullets fired earlier and exited.

Actually, the first shot was at the initial load + key press. The 1s timer fired around 1s after create. Shots fired at ~0.8s (after the W key and click). A bullet fired at 0.8s toward (500,200) from center (500,400) going up: reaches y=0 at (400/620)=0.65s after fire → exits at ~1.45s. So at 1s it'd still be alive. But bullets=0. 

Maybe the issue: `leftButtonDown()` / `isDown` — maybe my firing condition `p.isDown && p.leftButtonDown()` isn't firing because after the click the pointer's leftButtonDown() might be false during update? The 'click' action in the browser tool — does it register as a mouse down+up that the Pointer sees as isDown? Possibly the click is a quick tap; by the time update runs next frame, isDown might be false. So maybe only some clicks register as down. But I did several clicks.

Actually, more concerning: bullets=0 always means maybe NO bullets were created, OR they're all destroyed. Let me add a log in fireProjectile to confirm bullets are created, and a log on worldbounds destroy. Let me also log min dist when bullets exist.

Actually, the simplest: maybe the overlap bullet-alien worked but bullets got killed, OR bullets never spawned. Let me add logs: in fireProjectile log "fired", and when worldbounds destroys log "out of bounds".

But wait — there's a subtlety. The click action might trigger pointerdown which fires the projectiles via my update-loop? No — I fire in update() based on isDown. The click tool simulates a click (mousedown+mouseup). During the frames where the pointer is down, isDown true → fire. But the click is fast, maybe 1 frame. With fire rate 170ms, only one bullet per click. Fine.

But bullets=0 at 1s. Let me check if bullets are being created at all. Let me add a log in fireProjectile.

Actually, maybe the problem: `projectiles.get(mx, my, 'projectile')` — the group has defaultKey 'projectile'. get with explicit key should work. But maybe get returns an object but `proj.body.enable` is false and the bullet is created but... it should still exist.

Let me add logs. Let me modify fireProjectile to log creation and velocity, and the worldbounds handler to log.

Actually, I suspect the worldbounds handler might be firing for the player or aliens too, destroying them. But I guard `body.gameObject.isBullet`. Player doesn't have isBullet. Aliens don't. So only bullets. But if a bullet is destroyed by worldbounds quickly, and I'm not firing often, bullets=0 at sample time is plausible if the last bullet exited. But I fired several clicks; the most recent bullet is alive ~up to 1.6s. At 1s sample, the bullet fired at 0.9s (toward up) exits at 1.55s, so alive at 1s. Unless that click didn't register.

Let me just add logs to fireProjectile and re-test. This is essential to confirm firing works. Let me add a log.

Actually, let me reconsider the firing condition. `p.isDown && p.leftButtonDown()`. In Phaser 3.80, `Pointer.leftButtonDown()` returns whether the left button is currently down. But there's nuance: `leftButtonDown()` checks if the left button was pressed AND is still down? Let me check the Phaser docs: `Pointer.leftButtonDown()` returns true if the left mouse button is currently down (i.e., the button state includes left). Actually I think `leftButtonDown()` returns whether the left button is down at this moment. Hmm, but there's also the consideration that `leftButtonDown()` may return true only on the frame the button went down? No — `isDown` is the press state.

Wait, actually I recall `leftButtonDown()` in Phaser returns `true` if the left button is currently held. Let me verify by checking the phaser min. Let me grep for leftButtonDown definition.

Let me add a log in fireProjectile and a log of activePointer.isDown each frame. Let me do a quick edit.

Actually, let me reconsider — maybe bullets ARE created but immediately disabled because `proj.body.enable` ... no. Or the overlap destroyed them all? No.

Let me add a log in fireProjectile: `console.log('[fire]')`. And log in worldbounds destroy: `console.log('[oobounds]')`.

Let me edit.

Now let me fire and see logs. The key: the click tool may not register as a held-down mouse for multiple frames. Let me click and then immediately press a key to let update run while the pointer is down. Let me click at (500,400) then press 'W'.

No "[fire]" log! So the bullet is NOT being created. The click didn't register as a held-down left button during the update loop. This is the problem: the browser 'click' action likely sends a mousedown+mouseup event pair, but the Phaser Pointer's `isDown`/`leftButtonDown()` state during the game's update loop may not reflect it.

Why? Because the game loop (update) runs on animation frames, while the click event is processed by the browser. The Phaser Pointer updates its state from DOM events. The 'pointerdown' DOM event sets isDown true; 'pointerup' sets false. If the click is a quick tap, the down and up happen between frames, so by the next update isDown is already false → no fire. That's why firing in update via isDown misses quick clicks.

The requirement: "fire with the left mouse button." A single click should fire. So I should fire on 'pointerdown' event (left button), not on the held isDown in update. Let me switch to a 'pointerdown' listener.

But rapid fire on held mouse also desirable. Let me do BOTH: fire on pointerdown (immediate) AND continue firing while held via update, with the cooldown preventing spam. The pointerdown event reliably catches clicks.

Let me add:
```js
scene.input.on('pointerdown', (ptr) => {
  if (ptr.leftButtonDown() && !gameOver) {
    if (fireCooldown <= 0) { fireProjectile(); fireCooldown = FIRE_RATE; }
  }
});
```
But `leftButtonDown()` on pointerdown — at pointerdown, the button that triggered is down, and leftButtonDown returns true for left. Actually there's `pointer.button` — for left button, button===0. Let me check `ptr.leftButtonDown()`. In Phaser, on 'pointerdown', the Pointer's leftButtonDown() returns true because the left button is down. Good. But there's a subtlety: leftButtonDown() returns true if the left button is currently in the down state. On a left click down event, it's true.

Alternatively use `ptr.button === Phaser.Input.Keyboard.Constants... ` no. Use `ptr.leftButtonDown()`.

Hmm, but actually there's a known gotcha: `leftButtonDown()` returns true only if the left button is down AND it was the button that initiated? Let me just check `ptr.button === 0` (left button). On pointerdown, `ptr.button` is 0 for left click. That's reliable.

Let me use a flag: on pointerdown with left button, set a `wantFire = true` and let update fire (to respect cooldown via delta). Or fire directly in the handler with cooldown check. Let me fire directly in handler with cooldown check, and also keep update-based for sustained fire. Actually if I fire in handler, held mouse will trigger many pointerdown? No — pointerdown fires once per press. For sustained fire, I need isDown in update. But isDown misses quick clicks AND quick taps fire once — good. For sustained fire, the update isDown path fires repeatedly by cooldown. But the isDown path missed the click because the click released before an update frame. So sustained fire via isDown works only when held across frames (which it would be if held long enough). The problem was only quick single clicks not registering because the down→up happened between frames.

So the fix: handle pointerdown to catch clicks/taps immediately. Let me fire in the pointerdown handler. For sustained fire while holding, also keep the update isDown check (it will fire every cooldown while held across frames). Both together give click + hold fire. Good.

Let me implement pointerdown firing. Remove reliance on isDown-only.

Let me also reconsider: the `update` firing loop uses `p.isDown && p.leftButtonDown()`. For held mouse across frames, this fires every cooldown. Good. For a quick click, pointerdown handler fires. Good.

Let me edit create to add pointerdown handler, and keep updateFiring as is (it handles hold). Actually, with pointerdown handler, I might double-fire? The pointerdown fires once; then update's isDown may also fire the same frame (if still down that frame). The cooldown prevents double. Fine.

Let me add the pointerdown listener in create.

Let me edit.

Now also, the updateFiring still handles hold. But for a quick click, the pointerdown handler now fires. Let me also make sure the pointerdown doesn't fire when gameOver. It checks !gameOver. Good.

Now reload, click to fire (should log [fire]), then let a bullet reach aliens and confirm [hit] kill. Let me also move player out of danger to survive to get kills. Actually let me first confirm bullets fire now.

Let me reload and click at (500,400) then check console for [fire].

But clicking at the player center: the pointerdown at (500,400) fires immediately → fireProjectile with angle 0 (right, since pointer at player). bullet goes right. That confirms firing. Let me click off to the side to aim at aliens.

Let me reload first.

Hmm, still no [fire] log! The click at (820,400) should have fired via pointerdown. But no log. 

Wait — maybe the pointerdown event handler isn't being triggered because the canvas doesn't have focus/input? In Phaser, `scene.input` listens to DOM events on the canvas. The canvas should receive clicks. But maybe the browser tool's 'click' action doesn't dispatch a proper pointerdown event into the iframe's canvas? Or maybe the click registers but `ptr.button === 0` check... 

Wait, maybe the issue: the `key` action worked (W key registered as movement? we saw dmg from aliens). And earlier clicks didn't fire either. The pointerdown handler might not be firing because the click tool simulates a click but Phaser's input may need the canvas to be focused. Actually Phaser auto-attaches listeners to the canvas. The click should trigger pointerdown.

But earlier (before this fix), the update-based firing also produced no [fire] logs even on click. And movement via keyboard worked (alien contact happened because player... wait, did player move? The W key — did it move the player? The player got hit because aliens converged, independent of movement).

Hmm, maybe the click tool doesn't actually dispatch mouse events to the canvas in this sandbox. Earlier clicks registered aim changes? I can't tell since no visual.

Wait — actually the earlier "[dmg] player hit 3" happened because I clicked toward center and aliens were there. That was alien contact, not bullet hits.

Let me reconsider: the click action — does it dispatch a real mousedown on the canvas? The 'key' action worked for keyboard input (Phaser keyboard listeners caught W). So keyboard works. For mouse, maybe the click tool only sends a synthetic click at the iframe level, not focused on the canvas.

Let me test the pointerdown by adding a raw DOM listener to see if clicks reach the page at all. Actually, let me instead test firing via a keyboard key, since keyboard input clearly works! I can bind firing to a keyboard key (e.g., left mouse alternative: space or X). The requirement says "fire with the left mouse button," but adding a keyboard fallback for testing is fine. Actually, the requirement is specifically left mouse button. But maybe the click tool doesn't simulate pointerdown into the canvas.

Let me verify whether clicks reach the canvas by adding a DOM-level click listener that logs. Let me add `document.getElementById('game').onmousedown = ()=>console.log('[dommousedown]')` and the canvas. Actually the canvas is the #game div's child. Let me add a raw listener.

Alternatively, maybe the pointerdown IS firing but `fireProjectile` errors? No error in console. But no [fire] log means the handler didn't run or fireCooldown>0. fireCooldown=0 at start. So handler didn't run → pointerdown not received by Phaser.

Let me add a raw DOM mousedown listener to confirm whether clicks reach the canvas element. Let me also bind a keyboard key (e.g., 'SPACE' or 'X') to fire, as a reliable test path AND potentially as a fallback control (but requirement says mouse). I'll add keyboard firing for testing, then decide whether to keep.

Actually, the cleanest test: bind firing to a keyboard key temporarily to verify the bullet-alien hit pipeline. But I must keep mouse firing for the requirement. Let me check if clicks reach the canvas.

Let me add a DOM listener.

Now it works! `[phposdown] btn=0` and `[fire] fired projectile` and `[dommousedown]`. So the pointerdown handler fired this time. The earlier failure was likely a timing issue (the handler was being registered after the click, or the click happened before input was set up). Now it works.

So mouse firing works now. Let me confirm a kill. The player got hit earlier by standing still. Now the player is at center (fresh load) being approached. Let me move the player to a corner, then fire into the alien cluster, to confirm [hit] kill and score.

Actually, the player is at center and aliens are approaching. If I fire toward the aliens (they come from edges), my bullets travel outward toward the edges but aliens come inward — they'd meet in the middle. Let me click toward an edge where aliens emerge, e.g., (820, 400) fired a rightward bullet; aliens from the right edge are moving left → they'd meet that bullet in the right half. Should hit!

But I need a kill confirmation. Let me fire several shots toward edges and wait for the 1s debug log to show min distance and hopefully kills.

Let me click at (900, 120) [top-right], (120, 700)[bottom-left], (900,700)[bottom-right] to spray, then wait for debug log.

Actually, let me click toward the right edge region (820,400) and top edge and wait. Let me click a burst then press a key to advance to the debug timer.

Let me click at (900, 400), (850, 80), (950, 300).

Interesting! After firing, the debug still shows `bullets=0` even right after firing. So the bullets are being destroyed very quickly — likely by the worldbounds handler immediately, OR the projectiles aren't being added to the world properly.

Wait, but `[fire] fired projectile` logged, meaning fireProjectile ran. Then immediately the debug timer (1s) shows bullets=0. The time between firing and the debug log could be <1s. But the bullet should be alive (traveling) for ~1.5s. Unless it's being destroyed instantly.

Hypothesis: `proj.body.checkWorldBounds = true; proj.body.onWorldBounds = true;` with the world bounds — but the bullet spawns at player (500,400) inside bounds. Why would it immediately go out of bounds? It wouldn't on spawn. But maybe `checkWorldBounds` triggers on spawn if the body is considered out of bounds due to the body's bounds vs world bounds... no.

Wait — maybe the issue: the bullet is created but `projectiles.get` returns a sprite whose body is disabled/inactive (recycled), and even though I set `proj.body.enable = true`, maybe the body isn't actually enabled for physics update/overlap. The debug counts `b.body && b.body.enabled` — if body.enable is false, it's not counted. But I set `proj.body.enable = true` in fireProjectile. Hmm.

Actually, wait — maybe the bullets ARE being created and moving, but the debug timer fires 1s later and by then... no, bullets live ~1.5s. Unless the bullet's velocity is huge or it's destroyed by worldbounds.

Let me reconsider: `proj.body.onWorldBounds = true` — the worldbounds event fires when the body crosses the world boundary. But there's a known Phaser behavior: setting `onWorldBounds = true` makes the body dispatch the event, but does it also auto-destroy? No, the handler destroys. The bullet should travel inside.

Let me check: maybe `proj.body.checkWorldBounds = true` plus the body being initially out of bounds? No.

Alternative hypothesis: the bullet spawns but is immediately destroyed by overlap with an alien? No, that would log [hit].

Let me add a log in fireProjectile AFTER creation confirming the bullet object and its active/body state, and log when destroyed (override destroy or log in worldbounds). Actually [oob] log didn't appear. So bullets aren't being destroyed by worldbounds. So they're just... not active? The debug counts `b.body.enabled` — maybe after `get`, the body.enable is false and my `proj.body.enable = true` sets it, but then in the same tick the body is enabled. The debug at 1s shows bullets=0 meaning getChildren returns sprites with enabled=false OR empty.

Wait — could `projectiles.get` be returning null? If so, fireProjectile returns early after `[fire]` log? No, the `[fire]` log is before the early return check? Let me check order: in fireProjectile, `const proj = projectiles.get(...); if (!proj) return; proj.setActive... `. The `[fire] fired projectile` log is in the caller (updateFiring / pointerdown), printed BEFORE fireProjectile. So [fire] logged doesn't guarantee proj created. Let me add a log inside fireProjectile after creating proj.

Actually, the debug timer shows bullets=0 consistently even right after [fire]. So either get returns null, or proj.body.enable ends up false, or proj is destroyed.

Let me reconsider the group config: `projectiles = sc.physics.add.group({ defaultKey: 'projectile' });` — no maxSize. `projectiles.get(mx,my,'projectile')`. For a group without maxSize, `get` uses `getFirstDead` to reuse a dead member; if none, creates a new one with the key. The created ArcadeSprite should have an enabled body. Good.

But wait — there might be an issue: `projectiles.getChildren()` returns children including ones with `active=false` (recycled). My filter `b.active && b.body && b.body.enabled`. After firing, proj is active and enabled. So it should count. Unless get returns a recycled previously-destroyed... 

Hold on. Let me reconsider the worldbounds handler. The bullet spawns at player (center). But the bullet's body — I set `proj.body.checkWorldBounds = true`. On the FIRST physics step after creation, Arcade checks world bounds. The body at (500,400) is inside. So no. Unless the player is actually NOT at center. The player moved? In this fresh load, I didn't move the player. Player at (500,400). Bullet spawns there, goes right (toward 900,400). Travels to x=1000 then exits → worldbounds destroys. Time to exit: (1000-500)/620 ≈ 0.8s. So a bullet fired at t=0.5s is alive until t=1.3s. The debug at 1s should show bullets>=1. But shows 0.

So the bullet is being destroyed before 1s, OR never enabled. Since [oob] didn't log, it's not worldbounds. 

Let me add diagnostics inside fireProjectile: log proj presence and `proj.body.enabled` after setting. And add a destroy log by wrapping: `const origDestroy = proj.destroy; proj.destroy = function(){ console.log('[projdestroy]'); return origDestroy.call(this); };`. Let me add these to find why bullets=0.

Actually, maybe the simplest explanation: the bullets are being destroyed by the overlap with aliens because the player is AT center and aliens are AT center (they converge). When I fire toward (900,400), bullet goes right. But there might be an alien right at the player (touching), so when the bullet spawns at the player nose, it overlaps an alien immediately → onBulletHit → proj destroyed → alien killed. That would show bullet briefly then 0. But we'd see [hit] log. We haven't seen [hit]. So not that.

Wait, maybe the overlap isn't firing because of a scope issue or the bullets are destroyed by something else.

Let me add: log in fireProjectile after get, and a destroy override. Let me also log proj.body.enabled and position.

Let me edit fireProjectile.

Hmm, the read shows lines starting without indentation? It shows 4-space indent. Wait the content shows `    const mx` with 4 spaces. But my edit oldText used the same. Let me check — the grep showed line 285-286. The read shows the same. Why did my edit fail? Probably because the actual file content has different whitespace or the line `if (!proj) return;` — let me look. Actually the issue: my oldText included a newline and indentation. Let me just do the edit with the exact text from the read.

The read shows exactly:
```
    const proj = projectiles.get(mx, my, 'projectile');
    if (!proj) return;
```
with 4-space indentation. My oldText had no leading spaces? Let me redo with exact indentation (4 spaces).

`[fire] proj=ok` — the projectile is created. Now let me check if it gets destroyed. Let me wait for the debug timer and the destroy log. Let me click again a couple times and then press a key to advance the debug timer.

Still no `[projdestroy]` and `bullets=0` even though bullets were just fired. The debug timer fires ~1s after create, but the bullets were fired recently; they should be alive. Unless the bullets are being destroyed instantly without my overridden destroy logging... my override console.logs '[projdestroy]'. We see no [projdestroy]. And bullets=0.

So the bullets are being removed WITHOUT calling my `proj.destroy()`. How? 

Possibilities:
1. The bullet body is enabled=false in the debug filter. My filter: `b.active && b.body && b.body.enabled`. If `proj.body.enable` is set true but the body becomes disabled some other way (e.g., worldbounds `onWorldBounds` without destroy? No).
2. `scene.physics.pause()`? No, game not over.
3. The projectile's body `enable` is being set false by `outOfBoundsKill`? I set checkWorldBounds and onWorldBounds. When body goes out of bounds, the worldbounds event fires and my handler destroys it — but that would log [projdestroy]. Not logging. Unless the handler's guard `body.gameObject.isBullet` — I set isBullet. Hmm but the handler logs '[oob]' first then destroys. We see no [oob] either!

Wait, earlier I removed the [oob] log in the last edit? Let me check — in the edit I added `[dommousedown]` and `[phposdown]` back, and the worldbounds handler: let me check current state. In the previous edit I changed the handler to:
```
scene.physics.world.on('worldbounds', body => {
  if (body && body.gameObject && body.gameObject.isBullet) { console.log('[oob]'); body.gameObject.destroy(); }
});
```
Wait, that edit? Let me recall. The edit that added [oob] and [dommousedown] — yes I added `console.log('[oob]')` in the handler and a `[dommousedown]` DOM listener. Then I added `[phposdown] btn=`. So the handler logs [oob] when an isBullet body goes out of bounds. We don't see [oob]. So bullets never exit bounds (makes sense, they're alive). But debug shows bullets=0.

So bullets are alive (not destroyed, not out of bounds) but `getChildren()` filter returns 0. Why? Maybe `b.body.enable` is false! Even though I set `proj.body.enable = true`. 

Wait — maybe `projectiles.get` returns a recycled sprite from the pool whose body was previously disabled, and `setActive(true)` + my code... but I set `proj.body.enable = true`. Unless `get` returns the sprite with body.enable staying false because Arcade group.get doesn't re-enable? Actually `Group.get` → `getFirstDead()` → uses `child.body` ... hmm. Actually for an Arcade Physics group, `get` calls `getFirstAvailable` which returns a child where `body && body.enable === false` (dead) and resets it via `child.body.enable = true; child.body.reset(...);`. Wait, Arcade group's get does `enableBody` on the returned child? Let me recall: `ArcadePhysicsGroup.get` extends `Group.get`; in `get`, if a dead child is reused via `getFirstAvailable`? Actually `Group.get` uses `getFirstAvailable` to find a dead one and calls `child.body.enable`... hmm.

Actually for a fresh group with no dead children, `get` creates a new ArcadeSprite (via `scene.add.existing` + `physics.add.existing`), which has an enabled body. So `proj.body.enable` should be true.

But the debug filter `b.body.enabled` — note it's `enabled` (property) not `enable`? Arcade.Body has both `enable` and `enabled`? The property is `body.enable` (boolean) AND there's a getter `enabled`? Let me recall: Arcade.Body has `this.enable = true` and there might be a `enabled` getter. Actually I think it's `body.enable`. The debug uses `b.body.enabled`. If `enabled` isn't a property, `b.body.enabled` is undefined → falsy → filtered out! That would explain bullets=0 in the debug! 

So the debug filter is wrong (using `enabled` instead of `enable`), not the actual game. The bullets might actually be alive and active. So bullets=0 is a debug artifact.

But then why no kills? The bullets exist and move; aliens exist; overlap should fire. But no [hit] log. So either bullets don't reach aliens, or overlap not configured right.

Wait, but the player is at center surrounded by aliens (player got hit before? Actually in this fresh load, I haven't let the player get hit yet). At t=0 the player is at center; aliens are at edges moving toward center. I fired toward (900,400) rightward and (500,120) upward. The bullets travel outward; aliens travel inward. They should meet in the middle and overlap → [hit]. But no [hit].

Hmm. Unless the overlap isn't firing due to a config issue. Let me reconsider the overlap: `sc.physics.add.overlap(projectiles, aliens, onBulletHit, null, sc)`. Both are groups. This should check overlap each frame.

Wait — maybe the issue is the bullet body is circular-ish? Projectile body: I didn't set body shape; default Arcade body is a rectangle sized to texture (14x14). Alien body: I set `alien.body.setCircle(12)`. The rectangle bullet vs circle alien — overlap works with mixed shapes (Arcade handles AABB overlap for overlap checks? Actually Arcade overlap checks body.getBounds overlap or distance for circles). Should work.

Let me reconsider whether bullets actually exist (the debug filter bug). Let me fix the debug filter to use `body.enable` and re-log, and also log when overlap processes. Actually, let me directly add an overlap debug: in `onBulletHit`, it would log [hit] or [projdestroy]. We saw neither.

Alternative: maybe `projectiles.get` returns null in some cases and proj created but... no, proj=ok logged.

Let me fix the debug filter and also log proj.body.enable and position per bullet each debug tick. And add an overlap process callback that logs. Actually, let me make onBulletHit log even the "near miss" — no.

Let me reconsider: maybe the bullets are destroyed by the worldbounds handler silently because `body.gameObject.isBullet` is set but the handler... no, [oob] would log.

Wait — actually maybe bullets ARE being destroyed but my `proj.destroy` override doesn't catch it because the body's outOfBoundsKill path... I'm not using outOfBoundsKill. I'm using a worldbounds handler. Hmm.

Let me step back and simplify: the debug filter bug (`enabled` vs `enable`) likely makes debug show 0 even though bullets exist. So bullets exist and move for ~1.5s. The lack of [hit] suggests overlap isn't triggering. 

Possible real issue: The overlap callback `onBulletHit` — when it fires, it logs nothing on the "not killed" path. But it should log [hit] kill only when health<=0. For health=1 aliens, the first hit kills → logs [hit]. So a kill should log [hit]. We see no [hit]. So overlap between bullets and aliens isn't firing at all.

Why might overlap not fire? One reason: the bullet's body `checkWorldBounds`/`collideWorldBounds` — no. Another: maybe `projectiles` group getChildren returns sprites but they're not in the physics world's body list because `proj.body.enable` is false. If `proj.body.enable` is false (disabled), the body won't participate in overlap checks! 

That's it. If after `get`, the body.enable is false (because get reuses a disabled dead body but doesn't re-enable, OR a newly created body is fine)... For a fresh group, the first get creates a new sprite with body.enable=true. So that's fine.

But wait — I set `proj.body.enable = true` in fireProjectile after get. But if get returned a recycled body (from a previous fire that exited), I set enable=true again. Should be fine.

Hmm. Let me reconsider: maybe the overlap is firing but the bullet and alien don't actually overlap because the bullet is tiny and alien moves. But with 8 aliens converging on center and bullets crossing center, surely some overlap.

Let me add a more thorough debug: log, every debug tick, the positions of all bullets and all aliens so I can see if they coincide. And log overlap by adding a processCallback that always returns true and logs.

Actually, simpler: let me just remove the debug filter bug and log bullet count with `body.enable`. And log positions of first bullet/alien. Let me also lower FIRE_RATE? No.

Hold on, let me reconsider the `updateFiring` hold-firing and the pointerdown firing BOTH might create multiple. Not the issue.

Let me reconsider: maybe the problem is that `scene.physics.add.overlap(projectiles, aliens, ...)` was called in buildGroups BEFORE `alienList`/aliens populated, but that's fine; overlap is registered.

But wait: I call `sc.physics.add.overlap(projectiles, aliens, onBulletHit, null, sc)` and `sc.physics.add.overlap(player, aliens, onPlayerHit, null, sc)`. The player-alien overlap DID fire (we got [dmg] earlier)? Actually in THIS session we haven't seen [dmg] again. In the first session we did. So player-alien overlap works. But bullet-alien overlap doesn't? They're parallel calls. Odd.

Actually wait, did we ever see [dmg] in THIS debug session? Earlier session yes. In this session (with debug), we haven't seen [dmg] because the player hasn't been hit yet (fresh load, player at center, aliens approaching but not yet reached center in this short time).

So player-alien contact hasn't happened yet in this session. So I can't conclude player-alien overlap works either in this build. But in the first session (no debug, fresh code) it worked.

Hmm. Let me reconsider whether the overlap config is correct. `scene.physics.add.overlap(object1, object2, callback, processCallback, callbackScope)`. I pass `onBulletHit, null, sc`. That's the standard signature: (obj1, obj2, callback, processCallback=null, scope). Good.

Let me check: maybe the bullet's body is a 'None' body / not a physics body because `projectiles.get` returns a sprite but the physics body wasn't added? When using a physics group with `defaultKey`, `get` adds physics. Should be fine.

Let me actually log in the debug the bullet's `body.enable`, `body.x`, and an alien's `body.enable`, `body.x`, and min distance. Fix the filter. Let me update the debug callback to log bullet enable and positions.

Let me also add an overlap debug: a processCallback that logs "processed overlap". Actually, let me add a separate `scene.physics.world.collide` test? No.

Let me just enhance the debug log and reload.

Actually — I bet the real issue is simpler: the debug timer fires at 1s intervals, but I've only waited ~1.5s total. The first debug [dbg] fired once (aliens=8 bullets=0) — that 0 is likely the `enabled` bug. Let me fix the filter to `body.enable` and also log `proj.body.enable` and positions. Let me update.

Let me find the debug callback and the onBulletHit and fix them. Let me view the debug timer region.