Let me build a top-down alien shooter using Phaser. Let me first check the working directory and the phaser.min.js file.

Let me build the game. I'll create a single index.html with Phaser loaded locally.

Let me design the game:
- Top-down alien shooter
- WASD movement
- Aim with mouse, fire with click (or hold)
- Waves of advancing aliens
- Health, score, increasing difficulty
- Procedural graphics only (Phaser Graphics.generateTexture or drawing)

Let me build this carefully with Phaser 3.

Phaser 3.80.1. Good. Let me build the game.

I'll create a top-down alien shooter. Design:

- Black/dark space background with grid
- Player: a triangle ship drawn procedurally
- Movement: WASD
- Aim: mouse, fire on click/hold (with cooldown)
- Bullets: small glowing dots
- Aliens: procedural creatures, advance toward player
- Waves: each wave more aliens, faster, more health
- Health bar, score display, wave display
- Particle effects for explosions (procedural)
- Procedural sound via WebAudio (no external assets - is WebAudio allowed? "no external image or audio assets" - procedural sound is fine, generated at runtime). Let me add simple WebAudio beeps.

Let me use Phaser graphics for textures via generateTexture.

I'll write the full file now.

Let me verify the file is well-formed and test for any obvious issues. Let me do a quick syntax check by opening it in node-like context. Actually, I can't run a browser. Let me just verify the structure and check for obvious issues by reading parts.

Let me double-check a few concerns:
1. `this.physics.world.isPaused = true` — actually the proper way to pause physics is `this.physics.world.pause()` and `resume()`. Setting isPaused directly may not work. Let me use the proper API.
2. The `emitParticleAt` with config object — in Phaser 3.80, the API is `emitParticleAt(x, y, config)`. Actually `emitParticleAt(x, y)` exists; passing config might not be supported. Let me check.

Actually in Phaser 3.80, `emitParticleAt(x, y, config)` — the ParticleEmitter has `emitParticleAt(x, y, config)` where config is an object with overrides. Let me verify. Actually I recall `emitParticleAt(x, y)` and `emitParticle(count, x, y)`. The config-based emission is `emitParticleAt(x, y, config)` was added. Let me check.

Actually safer: use `createEmitter` style or use the simpler approach. But emitParticleAt with config override is supported in 3.60+. Let me keep but it's risky.

Let me reconsider. The cleaner approach in Phaser 3.80 is to create particle emitters and call `emitParticleAt`. The signature: `emitParticleAt(x, y, config)`. Yes this exists in 3.60+. The config object overrides emitter config for that emission. Good.

But I created `this.fx = this.add.particles('spark')` which returns a ParticleEmitterManager, then call `emitParticleAt` on it. Wait — `this.add.particles('spark')` returns a `ParticleEmitterManager`, NOT an emitter. To emit, you need an emitter created via `manager.createEmitter(config)` or `manager.emitParticleAt`. 

Actually, `ParticleEmitterManager.emitParticleAt` exists? Let me think. The manager has `emitParticleAt(x, y, count, config)`? Hmm. Actually in Phaser 3, `this.add.particles(key)` returns a `ParticleEmitterManager`. The manager does have `emitParticleAt(x, y, count, config)` method that creates a one-shot. Let me check.

Actually the ParticleEmitterManager does NOT have emitParticleAt directly; that's on the emitter. But there's a method on the manager... Let me be safe and create emitters.

Actually, I recall in Phaser 3.60+, `this.add.particles(x, y, texture, config)` returns an emitter directly (new API). And `this.add.particles(texture)` (old API) returns manager. This changed between versions.

To be safe, let me create proper emitters with createEmitter and use emitParticleAt on them. Let me restructure to create emitters.

Let me check the Phaser 3.80 API. In 3.60+, `this.add.particles(texture, config)` returns a ParticleEmitter directly. The old `this.add.particles('key').createEmitter(config)` still works too.

The safest cross-version approach: use `manager.createEmitter({...})` to get an emitter, then call `emitter.emitParticleAt(x, y, config)`.

Actually `emitParticleAt(x, y, config)` on an emitter — let me verify the signature. In Phaser 3, `emitParticleAt(x, y, count)` and `emitParticle(count, x, y)`. There's also the ability to pass config? Hmm, I'm not 100% sure emitParticleAt takes a config object.

Given uncertainty, let me switch to the robust approach: create emitter(s) once with a default config, and to vary color per emission use `emitter.setConfig` or just create separate emitters, OR use `emitParticle` with explicit particles.

Simplest robust approach: Create emitters with `explode` capability and use `emitter.explode(count, x, y)`. The `explode` method bursts particles at a position. For color variation, set emitter config with `tint` array before calling, or create multiple emitters.

But calling explode changes nothing about tint at call time. To get per-event tint, I'd need to set emitter tint each time. That's fine — `emitter.tint` can be set. Actually `setTint`? 

Let me simplify drastically: Use a small number of permanent emitters with set configs, and just call `.explode(n, x, y)` for bursts. For tint variation, I'll accept single-tint per emitter, or create a couple of emitters.

Let me restructure:
- sparkEmitter: small white sparks, used for hits/explosions, single tint but I can change `emitter.tint` before each explode? In Phaser, emitter has `tint` property (array or single). Setting `emitter.tint = 0x...` then explode should work since tint is sampled at emission. Actually for an array of tints, the emitter picks random. For per-call color, set `emitter.tint` to the desired value(s).

Hmm, but `emitter.tint` expects... Let me check. In Phaser emitter config, `tint` can be a number, array of numbers, or array of interleaved [tint, alpha]. Setting `emitter.tint = value` may not be the public API; there's `emitter.setTint(value)`.

Actually, I think the cleanest is to define the emitter with `{ tint: [...] }` and for varied explosions use multiple emitters (sparkFx, alienFx, bossFx). 

This is getting complicated. Let me just test it actually works. But I can't run a browser here. Let me verify by checking the Phaser source for emitParticleAt signature.

Let me grep the minified file.

So `createEmitter` is removed in this version (3.80). That means the new API is `this.add.particles(texture, config)` returning an emitter directly. And `emitParticleAt` exists. Let me check the signature of emitParticleAt.

So `emitParticleAt(t, e, i)` → `emitParticle(i, t, e)` where in their minified vars: t=x, e=y, i=count. So `emitParticleAt(x, y, count)`. It does NOT take a config object. My usage `emitParticleAt(x, y, {config})` would pass an object as count → `emitParticle(obj, x, y)`. That likely breaks.

So I need to fix the particle calls. The robust approach: create emitters with `this.add.particles('spark', config)` (new API returns emitter), then use `emitter.emitParticleAt(x, y, count)` and configure the emitter's properties (tint, speed, scale, lifespan) set at creation or via setters.

But I want different tint/quantity per event. With the new API, I can set emitter properties dynamically. ParticleEmitter has setters: `setScale`, `setSpeed`, `setLifespan`, `setTint`, `setBlendMode`, etc. And `setFrequency` for continuous vs `explode()` for bursts.

The cleanest: Create a couple of emitters with default config, and before each burst, set the relevant properties then call `emitter.explode(count, x, y)` or `emitter.emitParticleAt(x, y, count)`.

Actually `explode(count, x, y)` exists on the emitter and does a one-shot burst using current emitter config. Let me verify.

No `explode` found (it may be minified differently). Let me check the new-particle API. In Phaser 3.60+, the emitter has `explode(count, x, y)`. Let me grep more loosely.

So `explode` exists. `setLifespan` and `setSpeed` do NOT exist as named (maybe minified into different names, but the public method names should be preserved). Wait — setLifespan and setSpeed are not found but setAlpha, setBlendMode, setFrequency, setQuantity, setTint are. Hmm. Actually `setLifespan` and `setSpeed` should exist in the ParticleEmitter. Let me search more carefully — they may be there but grep pattern failed. Let me search.

Found:
- `setParticleLifespan`
- `setParticleScale`
- `setParticleSpeed`
- `setScale`

But for emit-at-pos with overrides, the simplest robust approach: use `explode(count, x, y)` on an emitter created with `this.add.particles('spark', config)`.

Let me check `explode` signature.

So `explode(count, x, y)`. It emits `count` particles at position (e,i)=(x,y). The config used is the emitter's current config. Good.

Now, my current code uses `this.fx.emitParticleAt(x, y, { config })`. The new API: `this.add.particles('spark')` — wait, in 3.60+ `this.add.particles(texture, config)` returns an emitter. Without config, does it return emitter or manager? Let me check the GameObjectCreator / ParticleEmitterManager.

Actually in 3.60+, `this.add.particles(texture, config)` creates a `ParticleEmitter` (the manager was removed/merged). Calling `this.add.particles('spark')` without config returns a ParticleEmitter with default config. Then `emitter.emitParticleAt(x, y, count)` and `emitter.explode(count, x, y)`.

But my code passes a config object as the third arg to emitParticleAt, which is interpreted as count. That's wrong.

I need to rework all particle calls. The cleanest: create emitters with sensible default config at startup, and for varied effects, set properties before exploding. But many of my calls have different tint/scale/lifespan per call. 

Option A: Create multiple emitters, one per "kind" of effect, each preconfigured. Simpler and reliable.
- muzzleFx: white, short
- hitFx: yellow/orange
- explosionFx: multi-tint (tint array)
- smokeFx: blue-grey
- bossFx: red/orange

But tint arrays and `explode` — does explode support per-particle tint from emitter config? Yes, if emitter config has `tint: [array]`, it samples random tints per particle. And `setTint` can change it. 

Let me restructure: create emitters at create time with configs, and just call `emitter.explode(count, x, y)` for bursts, and for continuous engine trail use `emitter.emitParticle(...)` or set frequency and position.

Actually for the engine trail, simpler: use `explode(1, bx, by)` occasionally. Fine.

Let me also reconsider: passing config per-call IS supported via `emitParticle(count, x, y, config)`? Let me check the emitParticle signature.

So `emitParticle(count, x, y)` — no config arg. So config-per-call is NOT supported in this API. I must preconfigure emitters and use setters / multiple emitters.

Plan: Rewrite the particle system. I'll create several emitters at create time:

```js
this.muzzleFx = this.add.particles('spark', {
  speed: { min: 40, max: 140 }, scale: { start: 0.8, end: 0 }, lifespan: 160, tint: 0xffffff, blendMode: 'ADD'
});
this.hitFx = this.add.particles('spark', {
  speed: { min: 40, max: 180 }, scale: { start: 0.7, end: 0 }, lifespan: 220, tint: 0xffdd66, blendMode: 'ADD'
});
this.bossHitFx = this.add.particles('spark', { tint: 0xff6688, ... });
this.explosionFx = this.add.particles('spark', {
  speed: { min: 80, max: 280 }, scale: { start: 1.2, end: 0 }, lifespan: 500,
  tint: [0x66ccff, 0xffffff, 0xff66cc], blendMode: 'ADD'
});
this.bossExplosionFx = ... tint [0xff2244,0xffaa00,0xffffff]
this.smokeFx = this.add.particles('smoke', { speed:{min:-20,max:20}, scale:{start:1.2,end:0}, lifespan:600, tint:0x446688 });
this.healFx = tint green; rapidFx orange; spreadFx blue; playerHurtFx red; deathFx big.
this.engineTrailFx = smoke tint blue.
```

Each created with `this.add.particles(texture, config)`. But note: creating an emitter with a config sets it to "flowing" (emitting) by default if frequency set? Actually when you create an emitter with config, it starts emitting at `frequency`. If I don't want continuous emission, I should not set frequency (defaults to 0 = continuous every frame) — that would emit constantly. Hmm.

Actually default frequency is 0 which means "emit every frame" (flow). To make it burst-only, set `frequency: -1`. With frequency -1, the emitter is "manual" — emit only via explode/emitParticle. 

So each emitter config should include `frequency: -1` to prevent auto-emission, then I control via `explode(count, x, y)`.

Wait, but explode sets frequency=-1 internally. Actually explode: `this.frequency=-1`. So calling explode puts it in manual mode. But if I create with default and never set frequency, before first explode it may emit every frame at origin (0,0)? Emitters without a `setPosition` emit at emitter's x,y which defaults to 0,0. And if frequency is 0 (flow), it emits every frame. That would create particles at top-left constantly — bad.

So set `frequency: -1` in every emitter config to be safe. Then call `explode(count, x, y)` for bursts. For the engine trail (continuous-ish), I'll just call `explode(1, bx, by)` occasionally.

Let me rewrite. Also need `atLimit` — emitters have `maxParticles` default 0 (unlimited)? There's a default `quantity` etc. Should be fine.

Also `blendMode: 'ADD'` — supported in config. Good for neon glow.

Let me rewrite the particle portions of the file. I'll restructure:

In create():
```js
const fxCommon = {
  frequency: -1, blendMode: 'ADD',
};
this.muzzleFx = this.add.particles('spark', { ...fxCommon, speed:{min:40,max:140}, scale:{start:0.8,end:0}, lifespan:160, tint:0xffffff });
this.hitFx = this.add.particles('spark', { ...fxCommon, speed:{min:40,max:180}, scale:{start:0.7,end:0}, lifespan:220, tint:0xffdd66 });
this.bossHitFx = this.add.particles('spark', { ...fxCommon, speed:{min:40,max:180}, scale:{start:0.7,end:0}, lifespan:220, tint:0xff6688 });
this.explosionFx = this.add.particles('spark', { ...fxCommon, speed:{min:80,max:280}, scale:{start:1.2,end:0}, lifespan:500, tint:[0x66ccff,0xffffff,0xff66cc] });
this.bossExplosionFx = this.add.particles('spark', { ...fxCommon, speed:{min:80,max:280}, scale:{start:1.6,end:0}, lifespan:700, tint:[0xff2244,0xffaa00,0xffffff] });
this.smokeFx = this.add.particles('smoke', { frequency:-1, speed:{min:-20,max:20}, scale:{start:1.2,end:0}, lifespan:600, tint:0x446688 });
this.engineFx = this.add.particles('smoke', { frequency:-1, blendMode:'ADD', speed:{min:-10,max:10}, scale:{start:0.6,end:0}, lifespan:250, tint:0x66ccff, alpha:{start:0.5,end:0} });
this.healFx = this.add.particles('spark', { ...fxCommon, scale:{start:1,end:0}, lifespan:400, tint:0x33ff66 });
this.rapidFx = this.add.particles('spark', { ...fxCommon, scale:{start:1,end:0}, lifespan:400, tint:0xffaa22 });
this.spreadFx = this.add.particles('spark', { ...fxCommon, scale:{start:1,end:0}, lifespan:400, tint:0x22aaff });
this.hurtFx = this.add.particles('spark', { ...fxCommon, scale:{start:1,end:0}, lifespan:300, tint:0xff3366 });
this.deathFx = this.add.particles('spark', { ...fxCommon, speed:{min:60,max:320}, scale:{start:1.6,end:0}, lifespan:700, tint:[0xff3366,0xffaa00,0xffffff] });
```

Then replace all `this.fx.emitParticleAt(x, y, {config})` with appropriate `this.XXXfx.explode(count, x, y)`.

Note: in 3.60+, is the texture passed correctly? `this.add.particles('spark', config)` — yes texture first arg. But careful: the second arg is config. Some versions: `this.add.particles(x, y, texture, config)`. Both signatures exist. Using `this.add.particles(texture, config)` works. Good.

Let me also reconsider `this.cameras.main.flash(80, 255, 40, 40)` — signature is flash(duration, red, green, blue, callback, callbackContext, force). Good.

Now `emitter.explode(count, x, y)` returns particle or array. Fine.

Also, I need to double check: does creating many emitters (12) cause issues? No.

Let me also verify `this.add.particles` returns emitter and `.explode` is available on it. The explode method we found is on the emitter class. Good.

Let me now also reconsider the `setScale` calls and the `scale: { start, end }` config — valid. `tint: [array]` — valid, samples randomly. `blendMode: 'ADD'` — valid string. `alpha: { start, end }` — valid.

Now let me rewrite the relevant sections. I'll replace:

1. The particle creation block in create().
2. engine trail block in update.
3. fireBullet muzzle flash.
4. damageAlien hit fx.
5. killAlien explosions (boss & normal) and smoke.
6. collectPowerup fxs.
7. alienTouchPlayer hurt fx.
8. hurtPlayer (no fx there).
9. endGame death fx.

Let me also remove `this.fx` and `this.smokeFx` old single references.

Let me do the edits. I'll rewrite the create() particle section and all emit calls. Given many changes, I'll do targeted edits.

First, replace the particle setup in create().

Now let me also fix the physics pause. I used `this.physics.world.isPaused = true`. The proper API is `this.physics.world.pause()` and `resume()`. Setting isPaused might not be a property. Let me check. Actually `ArcadePhysics` world has `pause()` and `resume()` methods. Let me use those. Also, pausing physics won't pause the update loop (tweens, timers). My `this.paused` flag returns early in update so that's fine. But timers (`this.time.delayedCall`) will keep running. For pause to be meaningful, I should also pause the scene's timers/tweens. Simplest: use `this.scene.pause()`? No — that pauses the whole scene update which is what I want, but then I can't unpause easily... Actually scene.pause() pauses update but the scene is still running. To resume, scene.resume(). But input won't fire when paused. Hmm, the P key handler is registered; when scene paused, input still works at game level? The keyboard event is on the scene's input. When paused, scene input is disabled by default. 

Simplest robust pause: keep my manual `this.paused` flag approach but also pause physics and stop tweens/timers effect. Since update returns early when paused, and I set physics paused, the aliens won't move. Timers (delayedCall for wave breaks etc.) would still tick. That's a minor issue. Let me also stop the scene's time. Actually `this.time` — I can't easily pause. 

Better: use `this.scene.pause()` and a separate "UI" scene for pause overlay, but that's more complex. 

Given simplicity, I'll keep the manual flag + pause arcade physics. Let me change isPaused assignment to pause()/resume(). Let me check arcade world pause.

`isPaused` is a property on the world (read-only getter likely). Let me check. There's `world.paused` property. The world has `pause()` which sets `paused=true`. Let me use `this.physics.world.pause()` and `resume()`. Let me also check resume.

That isPaused is for a different object (video). The physics world uses `pause()` and `resume()` and has a `paused` flag. Let me just use those. Update the togglePause.

Now let me verify there are no remaining references to `this.fx.emitParticleAt` or `this.fx.` or `this.smokeFx.emitParticleAt`.

No more references. Now let me sanity-check the whole file by reading key parts and also validate the JS syntax using node to parse the script portion. Let me extract the inline script and run node --check on it (after stripping the Phaser dependency). Actually node can't check since it references `window`, `Phaser`, `document` etc. but `node --check` only checks syntax, not runtime references. Let me extract the script content and run node --check.

Actually, simplest: use node to parse the whole file's JS by extracting between <script> tags. Let me just do a syntax check by using node's vm or just `node --check` on a file containing the JS.

Syntax is OK. Now let me do a final review of a couple of potential runtime issues:

1. `this.add.particles('spark', config)` returning emitter with `.explode` — confirmed explode exists. But does `this.add.particles(texture, config)` create an emitter that's added to display list and starts with `frequency: -1` (no auto-emission)? With frequency -1, no auto. Good.

2. The `setCollideWorldBounds` — player won't leave screen. Good. But aliens spawn outside world bounds (x=-30 etc.) and move in. With world bounds collision, aliens created outside bounds might immediately collide and bounce. Actually `setCollideWorldBounds` is only set on player; aliens don't have it, so they can move freely in. But the physics world bounds collision only applies to bodies with `collideWorldBounds` true. Aliens don't, so they pass through. Good. But wait — does the physics world wrap/stop bodies outside? No, only if collideWorldBounds. Good.

3. Enemy bullets & bullets cleanup by position — fine.

4. The `physics.add.group()` creates a group; `create(x,y,key)` adds a sprite with arcade body. Good.

5. Body circles: `a.body.setCircle(13, 3, 3)` — setCircle(radius, offsetX, offsetY). For 32x32 texture, circle radius 13 centered → offset = (32-26)/2 = 3. Good. For boss 80x80 radius 34 → offset (80-68)/2=6. Good. Player 40x40 radius 14 → offset 6. Good. Bullet 12x12 radius 5 → offset 1. Good.

6. `a.setTintFill(0xffffff)` then `clearTint()` — valid.

7. `cameras.main.flash` and `shake` — valid.

8. The wave break logic: after spawnQueue empty and aliveAlienCount<=0, set _waveBreak then start next wave. But aliveAlienCount decremented in killAlien. Initially at startWave, aliveAlienCount not reset to include the new spawns until they're spawned. Actually I increment aliveAlienCount in spawnAlien. So before first alien spawns, aliveAlienCount is 0 from previous wave. The completion check `!waveSpawning && aliveAlienCount<=0` — waveSpawning is true while queue has items OR I set it false when queue empty. Let me trace: startWave sets waveSpawning=true, spawnQueue=list. In update, while waveSpawning && queue.length, spawn. When queue becomes empty, I set `this.waveSpawning = false`. Then the completion check runs: `!waveSpawning && aliveAlienCount<=0`. But at the moment queue empties, aliveAlienCount = number spawned so far (all of them, since all queued were spawned). So it won't immediately trigger next wave — good. It triggers when all killed. Good.

But there's a subtle issue: when startWave called, I don't reset aliveAlienCount. If there were leftover aliens (shouldn't be), count persists. Fine.

Also the boss wave: boss counts as 1 alien in aliveAlienCount. Good.

9. The `aliensPerWave` var set but unused — harmless.

10. `this.input.on('pointerdown', ...)` sets firing=true; pointerup false. Also SPACE fires. Good. But note: clicking also triggers on the canvas; the pointer is active. Fine. There's a potential issue: pointerdown only fires when clicking within canvas. Since canvas is centered/fitted, fine.

11. `Phaser.Scale.FIT` with parent container — good, scales to fit window while maintaining aspect.

12. The overlay/hint divs are positioned over everything with pointer-events:none — won't block input. Good.

13. `make.graphics({ x:0, y:0, add:false })` — valid signature: `scene.make.graphics(config)`. Returns a Graphics not added to display list. Good.

14. generateTexture destroys? No, need to call g.destroy() at end. I do. Good.

15. Tint array for emitter config `tint: [0x66ccff, 0xffffff, 0xff66cc]` — valid; emitter picks random per particle. Good.

16. `blendMode: 'ADD'` string — Phaser supports string blend modes in particle config. Good.

17. `alpha: { start: 0.5, end: 0 }` — valid.

18. Potential issue: creating 12 particle emitters each potentially reserving particle pool — fine.

19. `this.engineFx.explode(1, bx, by)` — explode(1, x, y). Good.

20. In drawPowerBadge I use `this.hudGfx.arc(...)` — Graphics.arc exists. Good.

21. The `setRoundPixels(false)` call — fine.

22. Score text color update via setColor — valid.

23. One concern: `this.physics.add.overlap(this.player, this.aliens, this.alienTouchPlayer, ...)` — player-alien overlap. When alien spawns at edge and moves in, before spawnT reaches 1 it has velocity 0; once it enters and touches player, alienTouchPlayer checks spawnT<1 returns early. Good.

24. When non-boss alien touches player, I call killAlien(alien) which decrements aliveAlienCount and may drop powerup. Good. But killAlien also calls alien.destroy() and the overlap callback may run again — Phaser handles destroyed bodies. Fine.

25. After endGame, update returns early due to gameOver check (the `if (this.gameOver) return;` is AFTER star update and pause check). Actually the structure: update(time,delta){ if paused return; stars update; if gameOver return; ...}. So stars keep moving after game over — fine, nice effect.

26. When game over, aliens keep moving (physics still running) since I only set gameOver flag and update returns early, not pausing physics. That's fine aesthetically, or I could pause. Leaving it is okay. Actually player is hidden and aliens will pile where player was — minor. Acceptable.

27. Restart via R: `this.input.keyboard.on('keydown-R', () => this.scene.restart())`. scene.restart restarts the scene, re-running create. Good. But I should make sure physics world isn't left paused. On restart, new create runs, physics is fresh. Good.

28. Pause during game over: togglePause returns early if gameOver. Good.

29. `this.time.delayedCall(600, () => this.startWave())` at end of create — first wave after 600ms. Good.

30. `Sound.resume()` on pointerdown to unlock audio context. Good.

One more: in `startWave`, `this.showBanner` uses a tween with yoyo + holdTime. The tween targets `alpha`. With yoyo true and holdTime 700, alpha goes 0->1, holds 700ms, then 1->0. That works. But the initial setAlpha(0) then tween to 1. Good.

I think the game is solid. Let me do a final read of the full file to confirm no leftover issues, particularly the create() particle block and any stray references.

Everything looks consistent. The game is complete. Let me write a quick summary to the user.

Actually, let me reconsider one thing: `this.add.particles('spark', config)` — in Phaser 3.60+, the signature is `this.add.particles(x, y, texture, config)` OR `this.add.particles(texture, config)`. Let me verify that the 2-arg form with (string, object) is interpreted as (texture, config) and not (x, config). Since first arg is a string 'spark', it can't be x (number). Phaser's method likely detects. Let me quickly verify the add.particles signature in this build.

Let me search for the particles factory method differently. In Phaser 3.60+, GameObjectCreator/Factory has `particles`. Let me find the factory registration.

The minified build makes it hard to find. Let me check the GameObjectFactory particles method by searching for "particles" registrations with arguments handling both texture and (x,y,texture,config). Actually, the well-documented Phaser 3.60+ API: `this.add.particles(x, y, texture, config)` OR `this.add.particles(texture, config)`. The factory method is smart: if first arg is a string, it's treated as texture. Actually let me check the official signature more carefully.

In Phaser 3.60.0+:
`this.add.particles(x, y, texture, config)` — but also accepts `this.add.particles(texture, config)`.

Looking at the source, the factory `particles` does:
```js
particles: function (x, y, texture, config) {
  return this.create(x, y, texture, config);
}
```
And `create` handles arg shifting. Actually the GameObjectFactory.create checks types. The ParticleEmitter constructor signature is `(scene, x, y, texture, frames, config)`. The factory `create` method handles the optional x,y.

Hmm, but does `this.add.particles('spark', {...})` work? With factory.create, the argument handling: create(x, y, key, frame, ...) — it detects if x is a string (key) and shifts. Let me recall the actual factory `create` logic. Phaser's GameObjectFactory.create handles type-based arg detection: if typeof x === 'string', it treats x as the texture key and shifts args. So `this.add.particles('spark', config)` → particles('spark', config) → factory.create with... 

Wait, `particles` factory function is `(x, y, texture, config)`. If I call `this.add.particles('spark', configObj)`, then x='spark', y=configObj, texture=undefined, config=undefined. Then it calls `this.create('spark', configObj, undefined, undefined, ...)` for a ParticleEmitter. The create method has arg normalization? Actually the create method for factory: `create(x, y, texture, frame, config, ...)`. 

Hmm, this is getting uncertain. The safest is to use the explicit full signature: `this.add.particles(0, 0, 'spark', config)`. This definitely works (x=0, y=0, texture='spark', config). The emitter position 0,0 with frequency -1 means no emission at origin anyway. And I use explode(count, x, y) which overrides position. So position 0,0 is fine.

Let me change all `this.add.particles('texture', config)` to `this.add.particles(0, 0, 'texture', config)` to be safe. Actually wait — does `explode(count, x, y)` emit at x,y regardless of emitter position? Yes, explode passes x,y to emitParticle which uses them. The emitter's own x/y is the default/follow offset only when no position given. So 0,0 is fine.

Actually, let me reconsider. The newer `this.add.particles(texture, config)` form IS documented as supported since 3.60. From Phaser docs: "If you wish to create a Particle Emitter, you can do so using the new Game Object approach: this.add.particles(x, y, texture, config)." And there's also a note that x,y optional.

But to be 100% safe given I can't test in browser, using the full 4-arg form is guaranteed. Let me update all particle creations to use the 4-arg form.

Actually, let me check the ParticleEmitter factory more concretely. Let me find 'particles' in factory by looking for the pattern that registers it.

There are two `particles` registrations:
1. The GameObjectCreator version (`make.particles`): `(function(t,e){...var i=r(t,"key",null), n=o(t,"config",null)...})` — takes a config object.
2. The GameObjectFactory version (`add.particles`): `(function(t,e,i,s){return void 0!==t&&"string"==typeof t&&console.warn(...)...`

Let me see the full factory version. It starts with `function(t,e,i,s)` — so it's `add.particles(x, y, texture, config)` (4 args: t=x, e=y, i=texture, s=config). The warning fires if `typeof t === 'string'` (i.e., if first arg is string). So `this.add.particles('spark', config)` would TRIGGER THE WARNING and likely fail because it expects x,y,texture,config!

So I MUST use the 4-arg form: `this.add.particles(0, 0, 'spark', config)`. Let me see the rest of that factory function to confirm.

Confirmed. `add.particles(x, y, texture, config)` → constructs `new n(this.scene, x, y, texture, config)` (ParticleEmitter) and adds to displayList. The first arg `t` being a string triggers a warning (old API compatibility). So I must use `this.add.particles(0, 0, 'spark', config)`.

Let me update all particle emitter creations to use the 4-arg form. I'll do a sed-like replacement. There are 11 `this.add.particles(...)` calls. Each is `this.add.particles('TEX', { ... })`. I need `this.add.particles(0, 0, 'TEX', { ... })`.

Let me do targeted edits. Since the pattern `this.add.particles('spark', { ...FX` etc. varies, I'll edit each. Actually all 11 lines follow `this.add.particles('X', {`. Let me replace each uniquely. The textures used: 'spark' (multiple) and 'smoke' (two). The variable names are unique per line so I can match on the variable name.

Let me do edits matching `this.VARNAME   = this.add.particles(` → insert `0, 0, `.

I'll match each line by its left-hand variable name and the texture.

All good. Now let me verify the `explode` method on the ParticleEmitter created via `new n(this.scene, x, y, texture, config)` — n is the ParticleEmitter class. It should have explode. Confirmed earlier. Good.

Let me also double check: when config has `frequency: -1`, the emitter won't auto-emit. Good. The FX const spreads `frequency: -1` and `blendMode: 'ADD'` into each spark emitter config. Good.

One concern: `...FX` spread includes `frequency:-1` and `blendMode:'ADD'`. But the ParticleEmitter config expects keys like `frequency`, `blendMode` — yes those are valid config keys.

Now, another subtle concern: `scale: { start: X, end: 0 }` — valid particle config (scaleX/scaleY use same). Good.

`tint: [array]` — valid.

I think we're good. Let me also verify the `make.graphics` call signature is fine: `scene.make.graphics({ x:0, y:0, add:false })`. The make.graphics config accepts these. Good. Actually the default add:false for make. Fine.

Let me verify the whole file once more for any remaining `createEmitter` or `.fx.` references and confirm file size.

Wait, grep -c 'this.add.particles' = 12 but I have 11 emitters... let me recount. Actually there might be a leftover. Let me check. Actually I count 11 lines in the grep output above (331-342 = 12 lines). Lines 331-342 inclusive = 12 lines. Let me recount the emitters: muzzle, hit, bossHit, explosion, bossExplosion, smoke, engine, heal, rapid, spread, hurt, death = 12 emitters. Yes 12. Good.

Everything checks out. The game is complete and self-contained. Let me give a final summary to the user.