Let me review the code I wrote and make sure everything is solid. Let me think through it carefully.

The game is a side-scrolling platformer with:
- Procedurally generated textures (hero, ground, brick, coin, enemy, flag, cloud)
- Player with run/jump controls (arrow keys, WASD, space, touch)
- Platforms built from ground tiles and brick blocks
- Coins that bob up and down
- Enemies that patrol left/right
- Goal flag at the end
- Stomp mechanic (jump on enemies = kill, side hit = die)
- HUD showing coins, time, and distance to goal
- Death panel and win panel with restart

Let me think about any potential bugs:

1. The `pixelArt: true` option — I set this but the game scales via `Phaser.Scale.FIT`. With `image-rendering: pixelated` on the canvas and `pixelArt: true` on Phaser, the textures should stay crisp.

2. The camera shake on death — `this.cameras.main.shake(250, .012)` should work.

3. Coin bobbing tween — I'm tweening `y` on a static body. Tweens on a static body should still work because the position is still tracked. Actually, wait — when I call `this.coins.create(...)` on a staticGroup, it creates a static body. The texture/sprite itself can be tweened in position because Phaser's tweens work on game objects, not the physics body. But since it's static, when the player overlaps, the bounding box might not match the tweened position. Hmm, actually in Phaser, the physics body of a static object follows the game object position by default. So that should be fine.

4. Enemy patrol — I'm iterating over `this.enemies.children.iterate` and checking positions. This should work.

5. Death — I set `this.player.body.checkCollision.none = true` and then bounce. I need to make sure the player can fall off-screen. The world bounds are set to `0,0,WORLD,H` so the player will fall, and `this.player.y > H+50` triggers another die() call. But since I already set `this.dead = true`, the second call to `die()` would be blocked by the guard at the top. Let me check... yes, `if(this.dead||this.finished)return;` is in update but the `die()` method itself doesn't have a guard. Let me add one. Actually, since `this.dead=true` is set at the start, and update() checks for it, the second `die()` would just recreate the panel. Let me add a guard.

Actually wait, in `die()` I call `this.input.once('pointerdown', () => this.scene.restart())` after a 500ms delay. If the player falls off-screen and triggers a second `die()` call within 500ms, we'd register two restart listeners. The scene would restart twice which is a no-op. Not a huge deal but let me add a guard.

6. The ground tiles — I create them via `for(let i=0;i<w;i+=64)` but `addPlat(x,y,w)` adds at `x+i+32, y` with width `w`. So if `w=700`, that creates tiles at x+32, x+96, x+160, ..., up to x+672+32=704. Wait, `i` goes 0, 64, 128, ..., 640. So 11 tiles, last at x+640+32 = x+672. That's only 672 wide, not 700. Off by a bit but won't cause issues.

Actually, more importantly, `addBricks(x,y,n)` uses `i*48` which makes n bricks of width 48 each. Good.

7. Camera bounds — `this.cameras.main.setBounds(0,0,WORLD,H)`. The world is 6200 wide. The flag is at x=6050. The goal panel won't appear until the player reaches the flag, which requires scrolling all the way there. Good.

8. Touch — `touch.jump` needs to be reset after a jump. I do `touch.jump = false` after the jump. But what if the user is holding the jump button? They'd need to release and re-press. That's standard for platformer jump buttons. Good.

9. The `image-rendering: pixelated` style on the canvas will help with the chunky look when scaled.

Let me also check: do I need to disable the jump tween or anything for grounded jumps? No, the `if(jump && grounded)` handles that.

10. One potential issue: the player can jump indefinitely by holding jump if they keep landing and jumping. With `touch.jump = false` after each jump, the touch button needs to be re-pressed, which is correct. The keyboard inputs use `JustDown` which is also one-shot per press. Good.

11. The acceleration model — I set `setDragX(1200)` and apply `setAccelerationX(±1200)`. This means the player accelerates to about 320 max (the maxVelocity). Let me think... drag of 1200 with force of 1200 means equilibrium velocity of 1 px/frame = 60 px/sec. Hmm, that's slow. Wait, in Phaser, `setDragX` is per-frame in pixels and `setAccelerationX` is per-frame in pixels (essentially). So 1200 drag and 1200 acceleration = terminal velocity 1 px/frame. But wait, that's in pre-update which runs at 60Hz, so 1 px/frame = 60 px/sec. That's way too slow.

Actually, Phaser's arcade physics drag is applied as a velocity reduction per step. Let me check: in Phaser arcade physics, drag is multiplied by delta (in seconds), so 1200 drag with 1/60 second = 20. The acceleration is added to velocity. So:
- Initial v=0
- Accel adds 1200*delta = 1200/60 = 20 per step
- Drag subtracts 1200*delta = 20 per step (when v=0, this doesn't apply)
- So velocity grows by 20 per step
- After 16 steps, v = 320 (which is the max velocity)

OK so it does reach max velocity in about 16 frames = 0.27 seconds. That's snappy enough. Good.

12. The `setMaxVelocity(320, 650)` — horizontal max is 320 px/sec. With 32 px wide tiles, that's 10 tiles per second. Reasonable.

13. Gravity is `950` from `setGravityY(950)`. Jump velocity is `-485`. Peak height = 485^2 / (2*950) ≈ 124 pixels. Good for platforming.

14. The `cameras.main.setDeadzone(170, 90)` means the camera won't scroll until the player is 170px from the left edge of the camera view. Since camera is 960 wide, deadzone center is at x=480 from left, and the player needs to be at x=480-170=310 to start scrolling. Actually, the deadzone is the area inside which the camera doesn't follow. So the player needs to exit the deadzone for the camera to follow. With `lerp .09, .09`, the camera smoothly catches up.

15. The setOffset(5,2) and setSize(22,30) on the player body — the texture is 32x34. The body is 22x30 offset by (5,2). So the body covers most of the sprite. Good for collision.

Let me also verify the `cameras.main.startFollow` call. I have `startFollow(this.player, true, .09, .09, 0, 50)`. The last argument is the cameraOffsetY. So the camera is offset 50px down from the player. That means the player appears 50px higher on screen than dead center. That's fine — gives more visibility of the ground.

Actually wait, the cameraOffsetY positive means the camera is offset down, which means the player appears higher on screen. Hmm, let me think. If cameraOffsetY is 50, then the camera's viewport is positioned 50px lower in the world than following the player exactly. So when the player is at y=300, the camera shows y=250 to y=250+540=790. The player appears at the top of the screen. Hmm, that might be off. Let me check Phaser docs.

Actually, in Phaser, `cameraOffsetY` is the offset added to the target's position. If positive, the target appears lower in the camera view. Wait, no. Let me think again. The camera follows the target. If offsetY=50, the camera looks at (target.x, target.y+50). So the camera viewport top is at (target.x - W/2, target.y + 50 - H/2). The target appears at screen position (W/2, H/2 - 50). So the target appears 50px above center. That means the player appears in the upper portion of the screen, showing more of what's below. That's the standard platformer setup. Good.

Hmm, but with `setBounds(0,0,WORLD,H)`, the camera can't move above y=0. So at the start, the camera is at y=0, but the player is at y=360. With cameraOffsetY=50, the camera wants to be at y=360+50-270=140, but it can't go above 0, so it stays at 0. As the player moves down, the camera follows. OK, that should be fine.

Actually, I realize I should double-check this. The camera bounds mean the camera viewport's top-left can't go outside (0,0,WORLD,H). So when the player is high up, the camera stays at the top showing from y=0 to y=540. When the player drops to y=400, the camera might move down. Hmm, with the offset, the camera wants to center on (player.x, player.y+50). For the camera viewport to include y=0 to y=540 always, the center should be at y=270. So when player.y+50=270, player.y=220. When player.y < 220, camera stays at top. When player.y > 220, camera follows. This means the player is always visible in the lower portion of the screen when on the ground (since ground is at y=492, well below 220). Good.

Actually wait, I set the player to start at y=360, which is below 220. So the camera should follow. Let me trace: camera center y = 360+50 = 410. Camera top = 410-270 = 140. So the visible area is y=140 to y=680. The player at y=360 appears at screen y = 360-140 = 220, which is below center. Good.

But the bounds are (0,0,WORLD,H) = (0,0,6200,540). So camera top can't be less than 0. Camera top = max(0, 140) = 140. OK.

Hmm, but the camera also has a max y: camera top max = WORLD_H - H = 540-540 = 0. So the camera is always at top y=0 (since the world is only 540 tall). Wait, but the world height is H=540, and the camera viewport is H=540 tall. So the camera is always at y=0 in the world. The only scrolling is horizontal.

Hmm OK so my y offset doesn't actually do anything because the world is only 540 tall and the camera fills it. That's fine — the y offset is a no-op here.

Alright, I think the code is solid. Let me think about one more thing: the `pixelArt: true` config. In Phaser 3, this enables roundPixels and disables anti-aliasing. The CSS `image-rendering: pixelated` will also help when the canvas is scaled to fit the screen.

Let me also verify that `Phaser.Input.Keyboard.JustDown` works for the SPACE key. Yes, it should — `JustDown` is a static method that checks if a key was just pressed this frame.

One thing I want to double-check: the way I'm handling the death bounce. I set the player's velocity to (-0, -350) and disable collision. The player will fly up and then fall. The `update()` has `if(this.player.y > H+50) this.die()` which will trigger again. But `this.dead` is already true, so `die()` will run again. The panel will be shown twice and two `input.once` listeners will be registered. The scene will restart twice. The second restart is a no-op since the scene is already restarting. Should be fine, but let me add a guard to `die()` to prevent the double-call.

Actually, let me just add a guard. Let me update the code.

Also, one more thought: when the player wins, I set `this.player.body.enable = false`. But the player can still be moved by gravity/tweens? No, with `body.enable = false`, no physics applies. So the player just stays where they are. Good.

Let me also check: does the `tweens.add` on the coin work when the coin is in a static group? The tween modifies `coin.y`, which is a sprite property. The physics body of a static object follows the sprite's position. So the body will move with the sprite. But the static body doesn't actually move in terms of physics interactions — wait, actually it does, because the body position is synced to the sprite. Let me verify... in Phaser, for a static body, the position is the sprite's position. When you move the sprite, the body moves with it. So the coin's hitbox moves up and down. That's actually what we want — the coin is grabbable in its visual position.

OK I think the code is good. Let me also make sure there are no syntax errors. Let me re-read the file.

Actually, I realize I should test this. Let me check if there's a way to test it locally. The user said it runs fully sandboxed with no network, so I'll just trust the code and make sure it's syntactically correct.

Let me re-read the code carefully...

One issue: I have `if(this.player.y > H+50) this.die();` in update. But `H` is defined as 540 at the top of the IIFE. The world is 540 tall. So this triggers when the player falls below y=590. Since the world bounds are H=540 tall, the player would already be off the world. The `setCollideWorldBounds(true)` would prevent this normally, but the world has no floor, only the platforms. So the player can fall into gaps.

Actually wait, `setCollideWorldBounds(true)` only stops the player at the world boundary. The world bottom is y=540. The player is 34 tall, so the bottom of the player can't go below y=540+17=557. So `this.player.y > H+50 = 590` won't trigger if the world bounds are active.

Hmm, that's a problem. If the player falls into a gap, they hit the world bottom and stop. They can never trigger the death. But I disabled collision on death: `this.player.body.checkCollision.none = true`. So the second death won't apply collision and the player will fall.

Actually, let me re-read. The first `die()` sets `this.dead = true` and disables collision. Then the player keeps falling. But `setCollideWorldBounds(true)` — does disabling checkCollision also disable the world bounds check? I think yes, because `checkCollision` is the master switch.

Hmm, but the player would also be stopped by the world bounds until the checkCollision is disabled. Let me trace: player falls into a gap, no platform below, gravity pulls them down. They reach y=540-ish (world bottom minus half height). The `setCollideWorldBounds(true)` keeps them from going below. So they sit at the bottom of the world, can't move because `this.dead = true` blocks input updates. They never trigger the off-screen death.

That's a bug! Let me fix it. I need to either:
1. Remove `setCollideWorldBounds(true)` so the player can fall off
2. Or check if the player is on a platform and reset them

Let me go with option 1: remove `setCollideWorldBounds(true)` and rely on the off-screen detection. Or actually, the better solution is to keep world bounds but allow the player to fall through the bottom by checking if they're below the platforms.

Actually, the cleanest fix: don't set collideWorldBounds, and just check if player.y > 600 (well below the world) and trigger death. Let me update.

Actually wait, looking more carefully: `setCollideWorldBounds(true)` makes the player bounce off the world boundaries. The world is 6200 wide and 540 tall. So the player can't go outside (0,0,6200,540). If they fall into a gap, they hit y=540-17=523 and stop. They can't trigger the off-screen death.

I need to either:
- Remove `setCollideWorldBounds(true)` 
- Or use a different death trigger

The easiest is to remove `setCollideWorldBounds(true)`. But then the player could potentially go off the left edge too. Hmm.

Let me think... actually, the world bounds are at x=0 and x=6200. The player can still wrap around or get stuck. Without `setCollideWorldBounds`, the player would just fall off the bottom of the world when in a gap.

Let me just remove `setCollideWorldBounds(true)`. The left/right edges of the world aren't really an issue because the player starts at x=100 and the flag is at x=6050. The player would have to actively run left past the start to hit x=0. Even if they do, they just stop or fall — not a huge problem.

Actually, a better approach: keep `setCollideWorldBounds(true)` but make the world bottom below the visible area. I can set the world bounds to have a larger height. But then the camera would show empty space below the platforms.

Hmm. Or I can use a different approach: place a "kill plane" below the platforms that detects when the player falls past it. I can add a sensor or just check if `this.player.y > 540`.

Let me just remove `setCollideWorldBounds(true)` and add a check for `this.player.y > 600` to trigger death. Actually, since gravity will pull the player down past the bottom of the world, and there's no ground at y > 540, the player will just fall. The `if(this.player.y > H+50)` check will trigger when they fall far enough.

Let me update the code to remove `setCollideWorldBounds(true)`.

Actually, I realize the camera is at y=0 to y=540 (full height). The player at y > 540 is off-screen below. So `this.player.y > 600` would be 60px below the bottom of the screen. That gives the player time to fall and the player visually drops off-screen, which is a nice effect.

Let me make the fix.

Also, I want to add a guard to `die()` to prevent double-calling.

Let me also reconsider the enemy collision. The `hitEnemy` function:
- If player is falling (velocity.y > 90) and player's bottom is above enemy's center, it's a stomp
- Otherwise, it's damage

I think the logic is correct. Let me double-check: `e.body.center.y` is the center y of the enemy's body. `p.body.bottom` is the bottom of the player's body. If `p.body.bottom < e.body.center.y + 10`, that means the player's bottom is within 10px above the enemy's center. So the player is landing on top of the enemy. Combined with `p.body.velocity.y > 90` (player is moving downward), this is a stomp. Good.

Actually, `velocity.y > 90` means the player is moving downward at >90 px/sec. A jump lands at about 500+ px/sec initially and slows down. So 90 is a low threshold — even a slight downward motion counts. That might cause issues if the player is just walking on a platform above an enemy — the player isn't moving down, so velocity.y should be ~0. The `touched.down` flag would be true, and the player wouldn't be in the air. So the check `velocity.y > 90` would fail. Good.

But what if the player is on a moving platform or something? We don't have those, so it's fine.

OK let me make the fix.

Also one more thing — I want to add a small touch: when the player jumps, the camera could shake slightly. But that's not essential.

Let me also check: when the player collects all coins, the HUD says "COINS XX". The total is set from `this.coins.countActive()`. This is the initial count before any are collected. So the HUD will show the total possible. Good.

Wait, I display `COINS ${this.score}` and `TIME ${secs}`. I don't display the total. The user can infer it. That's fine.

Let me also make the level a bit more interesting. Actually, the current level is fine for a demo. Let me just fix the bugs.

Let me edit the file.

Now let me also verify the final file is correct and complete. Let me read it.

The file looks good. Let me verify it loads correctly by checking for any obvious issues. Let me think through one more time:

1. ✅ Single self-contained file
2. ✅ Phaser loaded as `<script src="phaser.min.js"></script>` (exact filename)
3. ✅ No external resources or network requests
4. ✅ All textures procedurally generated with `make.graphics`
5. ✅ Side-scrolling platformer with run/jump
6. ✅ Stomp enemies mechanic
7. ✅ Collect coins
8. ✅ Goal flag at the end
9. ✅ Classic Mario-style (brown goombas, golden coins, brick blocks, green flag, red-capped hero)

Player controls:
- Arrow keys / WASD to move
- Up arrow / W / Space to jump
- R to restart
- Touch controls (left/right/jump buttons) on mobile

Level features:
- 7 ground platforms with gaps
- 13 brick block clusters as platforms
- 16 coin groups (60+ coins total)
- 10 patrolling enemies
- Parallax mountains, clouds, shrubs
- Goal flag at x=6050 in a 6200-wide world
- HUD showing coins, time, and distance to goal

Death/win:
- Fall in a gap → die
- Touch enemy from side → die
- Jump on enemy → stomp (+2 score)
- Reach flag → win
- Both panels show restart option (R or tap)

I removed `setCollideWorldBounds(true)` and added `setCollideUp/Left/Right(false)` so the player can fall into gaps. The `if(this.player.y > H+50) this.die()` check handles off-screen death.

Let me also verify the texture generation works. The `make.graphics({add: false})` creates a graphics object that isn't added to the scene. Then `generateTexture(key, w, h)` creates a texture from it. Then `g.destroy()` cleans up. This is the standard Phaser pattern for procedural textures. Should work.

The `setMaxVelocity(320, 650)` — horizontal max 320 px/sec, vertical max 650 px/sec. The player can move 10 tiles per second horizontally. Reasonable.

The `setDragX(1200)` with `setAccelerationX(±1200)` — gives snappy movement that reaches max velocity in about 0.3 seconds. Good platformer feel.

The jump velocity is -485 with gravity 950, giving peak height of about 124px. The highest brick platforms are at y=235, which is 257px above the ground (y=492). So the player can't reach the highest coins in one jump from the ground. But they can use intermediate platforms to reach them. Let me check:
- Ground at y=492
- Lowest brick platform at y=390 (102px above ground) — reachable
- Medium at y=315 (177px above ground) — reachable from y=390 platform
- High at y=300 (192px above ground) — reachable
- Highest at y=235-260 (232-257px above ground) — needs to chain jumps from medium platforms

The level design seems playable. Good.

I think the code is complete. Let me do a final check that the file is at the right location.

Actually wait, I want to double-check one thing. The `pixelArt: true` config in Phaser 3 enables `roundPixels` on the game. This makes the player and other sprites snap to integer pixel positions, which gives a crisp pixelated look. Combined with `image-rendering: pixelated` in CSS, the game will look chunky and retro when scaled. Good.

Let me also verify the touch controls work. The `bindTouch` method adds pointer event listeners to the buttons. The buttons have `pointer-events: auto` so they can receive events even though the parent `#touch` has `pointer-events: none`. The buttons have `touch-action: none` to prevent the browser from handling touch gestures. The handlers set `touch[k] = true/false` based on pointer down/up. The `update()` reads `touch.left/right/jump` along with the keyboard state. Good.

I think the game is complete. Let me also make sure the file is saved correctly.