The user wants me to build a tile-based platformer game in the style of Dangerous Dave, all in a single self-contained HTML file. Let me think about what Dangerous Dave was:

- A side-scrolling platformer by John Romero
- Tile-based levels
- Player can run, jump, shoot
- Collect trophies/treasure
- Avoid hazards like fire, water, spikes
- Enemies to avoid or shoot
- Exit door to complete the level

Features I need to build:
1. Tile-based level with a canvas
2. Player character with running and jumping
3. Trophies to collect
4. Exit door that requires trophy collection
5. Hazards: fire (animated), water
6. Simple enemies that patrol
7. Procedural graphics - all drawn with canvas API, no external assets
8. Side-scrolling camera that follows the player

Let me design the level:

- Ground tiles (brown/earth)
- Platform tiles
- Water (blue, kills player)
- Fire (animated orange/red, kills player)
- Trophy (golden cup)
- Exit door
- Player (sprite drawn with canvas)
- Enemies (simple creatures that patrol)

Level design: I'll create a level that's wider than the screen, spanning maybe 50-60 tiles wide and 15-20 tiles tall. The player starts on the left, needs to navigate right, collect a trophy, avoid hazards, and reach the exit.

Let me code this up:

Tile types:
- 0: empty (sky/background)
- 1: dirt/ground
- 2: grass top
- 3: platform (stone/brick)
- 4: water
- 5: fire
- 6: trophy
- 7: exit door
- 8: enemy spawn point
- 9: player spawn

I'll draw everything procedurally:
- Ground: brown blocks with darker outlines
- Grass: green on top of dirt
- Platforms: gray stone blocks
- Water: blue with wave animation
- Fire: orange/red flickering animation
- Trophy: golden cup shape
- Exit: door shape (brown rectangle with handle)
- Player: small character sprite (like Dave - blue pants, red shirt maybe?)
- Enemies: red/green simple creatures

Camera: follows the player horizontally, with some vertical tracking.

Physics: gravity, collision detection with tiles.

Let me build this step by step.

I'll make the level roughly 80 tiles wide and 20 tiles tall. Each tile is 32x32 pixels.

Let me design a good level:

Row 0-15: mostly empty (sky)
Row 16-17: ground with some gaps (water/fire pits)
Row 10-14: some platforms
Various hazards and enemies scattered throughout

Actually, let me think about this more carefully. The canvas will be maybe 800x500 or so. With 32px tiles, that's 25x15 visible tiles. The level should be wider.

Let me design a level that's 100 tiles wide and 20 tiles tall. Tile size 32px.

I'll create the level as a 2D array.

Let me create a fun level with:
- Starting area on the left
- Some platforms to jump on
- Water pits to jump over
- Fire hazards
- Enemies patrolling on platforms
- Trophy somewhere in the middle-right
- Exit at the far right

Now let me code it all up in a single HTML file.

For the player drawing, I'll make a small character:
- Head: circle
- Body: rectangle
- Legs: two small rectangles
- Arms: small rectangles

For enemies, I'll draw simple creatures:
- Body: oval
- Eyes: two dots
- Legs or feet

For fire animation, I'll use a particle-like effect or just change colors over time.

For water, I'll animate with slight color changes or wave patterns.

Let me write the complete code now.

Key mechanics:
- Gravity
- Jumping (space or up arrow)
- Left/right movement
- Collision detection with solid tiles
- Death on touching water or fire
- Death on touching enemies (or maybe player can jump on them?)
- Trophy collection
- Exit only opens after trophy collected

Let me make it so the player can jump on enemies to defeat them (like Mario), and touching them from the side kills the player. Or simpler: touching enemies kills you. Actually for Dangerous Dave style, let me just make enemies kill on contact - the player avoids them or shoots them. But since we don't have shooting mechanics (that would be complex), let me make it so you either avoid enemies or jump on them.

Actually, let me keep it simple: touching enemies kills you. Avoid them. Jump over them.

Now let me code the full game:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Dangerous Dave - Platformer</title>
<style>
/* styles */
</style>
</head>
<body>
<canvas id="game"></canvas>
<script>
// All JS
</script>
</body>
</html>
```

Let me flesh this out completely. I want to be thorough about the game mechanics.

Tile size: 32px
Canvas: I'll make it responsive - maybe 800x500 or 960x640

Actually let me go with a canvas that fits nicely. Let's say 800x480 internal, and scale to fit.

Level dimensions: 120 tiles wide, 20 tiles tall.

Let me design the level array carefully. I'll code it as a string for easier visualization and parse it.

Actually, let me just use a 2D array literal. That's simpler.

Level design (each character represents a tile type):
- ' ' = empty
- 'G' = ground (dirt with grass top)
- 'D' = dirt (underground)
- 'P' = platform (stone)
- 'W' = water
- 'F' = fire
- 'T' = trophy
- 'E' = exit
- 'S' = player spawn
- 'M' = enemy (monster)

For ground tiles, I'll have a "grass" tile on top and "dirt" below. But for simplicity, I'll just define the ground and handle grass rendering in code (grass is at the surface where tile above is empty).

Let me simplify the tile types for the level array:
- 0: air
- 1: ground (dirt)
- 2: platform (brick/stone)
- 3: water
- 4: fire
- 5: trophy
- 6: exit
- 7: enemy

Player spawn is separate.

Now let me carefully design a fun level. I want:
- Player starts at left
- Some platforms and gaps
- A water section
- A fire section  
- Trophy in the middle
- Exit at the right end
- Enemies scattered on platforms

Let me build a level that's 100 tiles wide, 20 tiles tall.

Here's my level concept:
- Ground from row 16-19 (4 rows of dirt)
- Row 15 is the surface (grass)
- Some gaps in the ground for pits
- Water in some pits
- Fire on some surfaces
- Platforms floating above ground level (rows 10-14)
- Trophy around column 60
- Exit at column 95
- Enemies on various platforms

Let me code this up now. I'll create the level programmatically rather than as a literal to save space and make it more interesting.

Actually, I'll use a level array built programmatically for the most part, with specific placements for interesting features.

Let me write the complete code now. I want to make sure the game feels good:
- Smooth movement
- Good jump arc
- Proper collision detection
- Nice camera
- Death animation/respawn
- Win condition
- Score tracking maybe

OK let me just write it all out now. This will be a substantial file.

I need to think about the collision detection. For a tile-based platformer:
- Check if the player's bounding box overlaps any solid tiles
- Handle horizontal and vertical movement separately
- For vertical: if falling and hitting a solid tile from above, land on it
- For horizontal: if moving and hitting a solid tile, stop

Player size: slightly smaller than a tile, like 24x30 pixels (allows some leeway in 32px tiles).

Actually, let me make the player 28x30 or so, centered in the tile position, to allow some forgiveness when jumping through gaps.

Let me think about the pixel coordinates:
- Player position: (px, py) in pixels
- Player velocity: (vx, vy) in pixels/frame
- Convert to tile coordinates for collision checking

Collision check:
- Check the 4 corners of the player's bounding box
- Or check the tiles the player overlaps

Let me use AABB collision with the tile grid:
- Player rect: (px, py, pw, ph)
- For each tile that the player overlaps, check if it's solid

Movement:
1. Apply horizontal velocity
2. Check horizontal collisions, resolve
3. Apply gravity to vertical velocity
4. Apply vertical velocity
5. Check vertical collisions, resolve
6. If landing on ground, reset vertical velocity, set grounded flag

This is the standard platformer physics approach.

Let me also add:
- Jump buffer (allow jumping slightly before landing)
- Coyote time (allow jumping slightly after leaving edge)
- Variable jump height (hold jump for higher, release for lower)

These will make the game feel much better.

OK, I think I've planned enough. Let me write the complete code now.

I'll structure it as:
1. Constants and configuration
2. Level data
3. Game state
4. Player class
5. Enemy class  
6. Particle effects (for fire, water splashes, etc.)
7. Input handling
8. Game loop (update + render)
9. Rendering functions
10. UI (score, lives, messages)

Let me go with:
- 3 lives
- Score for collecting trophy
- Death resets to start (or checkpoint)
- Game over after all lives lost
- Win screen

For the procedural graphics, I'll draw:
- Ground: brown blocks with darker grid lines
- Grass: green strip on top of ground tiles that have air above
- Platforms: gray stone with mortar lines
- Water: blue with animated shimmer
- Fire: orange/red with animated flame tips
- Trophy: a golden cup/trophy shape
- Exit: a door frame
- Player: a small humanoid figure
- Enemies: small monster shapes

Let me also add background elements like distant mountains or clouds (parallax-ish).

Now let me code it all up. This is going to be a big file but should be a complete, fun game.

One more thing - the camera. I want it to smoothly follow the player:
- Camera x = player.x - canvas.width/2 + player.width/2
- Clamp camera to level bounds
- Some vertical following too but less aggressive
- Maybe look-ahead based on player velocity

Smooth camera: lerp towards target position.

OK, time to write the code. I'll aim for around 800-1000 lines of well-structured code.

Let me think about what the level actually looks like more concretely. I'll build it as an array.

For 100x20 tiles, that's 2000 entries. I can build it programmatically.

Ground: rows 16-19 are ground for the whole width, with some gaps.
Gaps: columns 15-18 (water), columns 35-38 (water), columns 55-58 (fire pit), columns 75-78 (water).
Platforms at various heights.
Hazards placed deliberately.
Trophy at a challenging but reachable location.
Exit at the far right.

Let me define this more precisely in code. I'll create the level array with loops.

Actually, to make the level more interesting with better visual design, let me create it with some variation in ground height, platforms at different heights, etc.

Here's my plan for the level (100 wide, 20 tall, 0-indexed):

Ground mostly at rows 16-19:
- Columns 0-14: solid ground
- Columns 15-18: water pit (water at row 19, air above, maybe a platform to jump across)
- Columns 19-34: solid ground (with fire at row 15 on column 25)
- Columns 35-38: water pit
- Columns 39-54: solid ground  
- Columns 55-58: fire pit (lava)
- Columns 59-74: solid ground (with trophy around column 65, on a raised platform or on the ground)
- Columns 75-78: water pit
- Columns 79-99: solid ground (exit at column 95)

Platforms:
- Row 12, columns 12-16 (over first water pit)
- Row 10, columns 20-24 (enemy here)
- Row 8, columns 30-34
- Row 12, columns 33-37 (over second water pit)  
- Row 10, columns 40-44
- Row 8, columns 50-54 (enemy)
- Row 12, columns 53-57 (over fire pit)
- Row 14, columns 60-70 (lower platform, trophy at column 65?)
- Row 10, columns 60-64
- Row 12, columns 72-77 (over water pit)
- Row 10, columns 80-84
- Row 8, columns 88-92 (enemy)

OK this is getting complex. Let me just write the code and build the level with a combination of loops and specific placements.

I'll actually write a function that generates the level, using a base pattern with specific overrides for interesting features.

Let me think about one more thing: the player graphics. I want to draw a nice little character:

Player (Dangerous Dave-inspired):
- Red cap/hat
- Skin-colored face
- Blue shirt
- Brown pants
- Small boots

I'll draw this with basic shapes on a small canvas or directly with canvas drawing operations.

For the enemy, I'll make a simple creature:
- Green body
- Two eyes
- Small feet
- Maybe horns or spikes

For fire animation, I'll draw flame shapes with varying heights and colors using a sin wave.

For water, I'll use a blue base with lighter blue wave lines.

OK, I think I have enough planned. Let me write the complete code now.

Let me also handle:
- Mobile touch controls (on-screen buttons) for completeness
- Keyboard controls (arrows + space)

Actually, for mobile, I'll add simple touch buttons at the bottom.

Now let me write everything:

```javascript
// Game constants
const TILE_SIZE = 32;
const LEVEL_WIDTH = 100;
const LEVEL_HEIGHT = 20;
const GRAVITY = 0.6;
const PLAYER_SPEED = 4;
const JUMP_FORCE = -11;
const MAX_FALL_SPEED = 12;

// Canvas setup
const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');
canvas.width = 800;
canvas.height = 480;
```

OK, I'm going to write the whole thing now. Let me structure it well.

For the level array, I'll create it as a flat array or 2D array. 2D array of [row][col] where row is y and col is x.

Let me write it all now:

I want to make the game polished:
- Title screen
- Game over screen
- Win screen
- HUD with score and lives
- Smooth camera
- Particle effects for fire
- Animated water
- Good collision feel

Let me also add sound effects using the Web Audio API (oscillator-based, no files needed). That would be a nice touch. Simple beeps for jump, collect, death, win.

Actually, to keep it manageable, let me add minimal sound - just a few oscillator beeps.

OK, final plan:

HTML structure:
- Canvas centered on page
- Dark background
- Game title

CSS:
- Centered layout
- Dark theme
- Canvas with border

JS:
- Constants
- Level generation
- Camera class
- Player class  
- Enemy class
- Particle system
- Input handling
- Game loop
- Rendering
- Sound effects (simple oscillators)
- Game states: title, playing, dead, won, gameover

Let me code this up now. I'll be thorough but efficient.

I realize this is going to be quite long. Let me focus on making it really good and fun.

For the level, I want it to be well-designed. Let me create it with more deliberate structure. I'll define key sections:

Section 1 (columns 0-20): Introduction
- Player starts at column 2
- Simple terrain, few jumps
- First enemy encounter

Section 2 (columns 20-40): Water challenges
- Water pits to jump over
- Platforms over water
- Enemies on platforms

Section 3 (columns 40-60): Fire challenges
- Fire hazards
- Tight platforming
- Trophy hidden here (column 50, elevated)

Section 4 (columns 60-80): Mixed challenges
- Both water and fire
- More complex platforming
- Multiple paths?

Section 5 (columns 80-100): Final stretch
- Exit at column 95
- Final challenge before exit

This is getting complex. Let me just write the code and make it work. I'll build the level as I go.

Let me write the full code now. I'll aim for quality.

One important design choice: should the player be able to jump through platforms from below? (Like in many platformers where you can jump up through semi-solid platforms). I think yes - some platforms should be "one-way" (you can jump up through them but land on top). This makes level design more forgiving.

I'll have two types of solid tiles:
- Solid (fully blocking) - for ground
- Platform (one-way) - for floating platforms

Actually, for simplicity, let me make all platforms one-way (jump through from below). Ground is fully solid. I'll implement this by:
- Ground tiles: check collision from all sides
- Platform tiles: only check collision when player is falling (vy >= 0) and was above the platform

Let me code this up.

One more thing: I'll add a parallax background with:
- Mountains in the distance (darker, move slower)
- Clouds (move even slower)
- Stars or sky gradient

This will look really nice.

OK, I truly need to start coding now. Let me write the complete HTML file.

Actually, I realize I should also think about the tile rendering. Each tile type needs a distinct visual:

Tile types enum:
- AIR = 0
- GROUND = 1 (dirt/earth, brown)
- PLATFORM = 2 (stone/gray) 
- WATER = 3 (blue)
- FIRE = 4 (animated orange/red)
- TROPHY = 5 (golden)
- EXIT = 6 (door)

For enemies, I'll store them in a separate array since they move.

Playerspawn is also separate.

When rendering the level, I'll check each tile and draw accordingly. For ground tiles, I'll also check if the tile above is air and draw grass on top.

Alright, let me write the complete code. I'm going to create a really good game.

The level will be 120 tiles wide for a longer experience.

I need to be careful with the physics. Let me use these values:
- GRAVITY: 0.5 per frame
- JUMP_VELOCITY: -10
- MOVE_SPEED: 3.5
- MAX_FALL: 12

At 60fps, gravity of 0.5 means after 1 second the player falls ~30 pixels/second, which seems reasonable.

Actually, let me use deltaTime to make it frame-rate independent. But for simplicity, I'll assume ~60fps and use fixed timestep. I'll use requestAnimationFrame and assume roughly 60fps.

Let me also think about variable jump height:
- When the player presses jump, set vy = JUMP_VELOCITY
- Each frame while jump is held and vy < 0, apply less gravity (or no extra deceleration)
- When jump is released and vy < 0, multiply vy by 0.5 (cut the jump short)

This is a common technique and feels great.

OK let me write it all now. For real this time.

Here's my code structure:

```
1. HTML boilerplate
2. CSS styling
3. JS:
   a. Constants
   b. Audio (simple oscillator-based)
   c. Level data/creation
   d. Camera
   e. Player
   f. Enemies array
   g. Particles array
   h. Input state
   i. Game state machine
   j. Update loop
   k. Render functions
   l. Game loop (requestAnimationFrame)
   m. Event listeners
```

Let me write it now. I'll be thorough but not bloat the code unnecessarily. Target: ~600-700 lines.

Actually, given the feature set, this might be 800-1000 lines. That's fine for a complete game.

Let me start writing:

For the audio, I'll use a simple function that creates short beeps using the Web Audio API:

```javascript
function playSound(freq, duration, type = 'square') {
    const audioCtx = new (window.AudioContext || window.webkitAudioContext)();
    const osc = audioCtx.createOscillator();
    const gain = audioCtx.createGain();
    osc.type = type;
    osc.frequency.value = freq;
    gain.gain.value = 0.1;
    gain.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime + duration);
    osc.connect(gain);
    gain.connect(audioCtx.destination);
    osc.start();
    osc.stop(audioCtx.currentTime + duration);
}
```

Actually, creating a new AudioContext each time is bad. I'll create one at the start.

Now, for the level, let me design it. I'll create a 2D array [HEIGHT][WIDTH].

Here's my level layout (120 x 20):

Most of the level has ground at rows 16-19 (4 rows of dirt).
Row 15 gets grass drawn on ground tiles.

Gaps (pits):
- Cols 15-18: water pit 
- Cols 35-39: water pit
- Cols 55-58: fire pit
- Cols 75-79: water pit
- Cols 95-99: large water pit (final challenge)

Platforms (stone, rows 8-14):
- Row 12, cols 12-17 (over first pit)
- Row 10, cols 20-25
- Row 8, cols 30-35
- Row 13, cols 33-39 (over second pit)
- Row 10, cols 42-47
- Row 8, cols 52-57
- Row 13, cols 53-58 (over fire pit)
- Row 11, cols 62-67
- Row 9, cols 70-75
- Row 13, cols 73-79 (over water pit)
- Row 10, cols 82-87
- Row 8, cols 90-95
- Row 12, cols 93-99 (over final water pit)

Fire on ground (on row 15):
- Col 25
- Col 45
- Col 68

Trophy: col 50, row 14 (on a platform or near fire)
Exit: col 114, row 15

Enemies:
- Col 22, row 14 (ground enemy)
- Col 32, row 9 (platform enemy)
- Col 44, row 14 (ground enemy)
- Col 53, row 7 (platform enemy, near trophy area)
- Col 72, row 8 (platform enemy)
- Col 84, row 9 (platform enemy)
- Col 105, row 14 (ground enemy, near exit)

Player start: col 3, row 14 (on ground)

This is a solid level design. Let me code it up.

I'll represent the level as a 2D array where I set specific tiles.

Now, I want the renderer to draw grass on top of ground tiles:
- If a tile is GROUND and the tile above is AIR, draw grass on the top portion of this tile.

For platforms, I want them to look like stone blocks with mortar lines.

For water, I'll draw blue with animated lighter highlights.

For fire, I'll draw animated flame shapes.

For the trophy, I'll draw a golden cup/goal.

For the exit, I'll draw a door.

Let me write the trophy drawing:
- A golden cup: trapezoid base, rectangular stem, U-shaped cup on top
- Yellow/gold color with shine

Exit door:
- Brown rectangle (door frame)
- Darker brown door with a lighter handle
- Maybe a subtle glow when the trophy is collected

Player character (Dangerous Dave style):
- I'll draw him facing right by default, and mirror when facing left
- Red cap/bandana
- Skin-colored face
- Blue torso
- Brown/khaki pants
- Small boots

Enemies:
- Green or red body
- Round shape
- Two white eyes with black pupils
- Maybe small horns

Alright, I truly need to start writing the actual code now. Let me produce the complete file.

I'll also add:
- Screen shake on death
- Particle effects when trophy is collected
- Brief invulnerability after respawning
- Score display

For rendering, I need to convert tile coordinates to screen coordinates:
screenX = tileX * TILE_SIZE - camera.x
screenY = tileY * TILE_SIZE - camera.y

Only render tiles that are visible on screen (with some margin).

OK here we go. I'll write the complete file now.

Actually wait, one more design decision: the canvas size. I think 800x480 is good (16:9.6 ish). With 32px tiles, that's 25x15 visible tiles. The level is 120x20, so plenty of scrolling.

Let me also handle window resizing by scaling the canvas.

Alright, I'll start writing the code now.

I'll structure the JS as follows (all within one <script> tag):

```javascript
// === CONSTANTS ===
// === AUDIO ===
// === LEVEL DATA ===
// === GAME STATE ===
// === CAMERA ===
// === PLAYER ===
// === ENEMIES ===
// === PARTICLES ===
// === INPUT ===
// === UPDATE ===
// === RENDER HELPERS ===
// === RENDER WORLD ===
// === RENDER HUD ===
// === MAIN LOOP ===
// === EVENT LISTENERS ===
// === INIT ===
```

Let me write it all out now. I need to be very careful with the collision detection code.

Collision detection algorithm:
```
function checkCollision(x, y, w, h, ignorePlatforms) {
    // Get tile coordinates of the bounding box
    let left = Math.floor(x / TILE_SIZE);
    let right = Math.floor((x + w - 1) / TILE_SIZE);
    let top = Math.floor(y / TILE_SIZE);
    let bottom = Math.floor((y + h - 1) / TILE_SIZE);
    
    // Clamp to level bounds
    left = Math.max(0, left);
    right = Math.min(LEVEL_WIDTH - 1, right);
    top = Math.max(0, top);
    bottom = Math.min(LEVEL_HEIGHT - 1, bottom);
    
    for (let row = top; row <= bottom; row++) {
        for (let col = left; col <= right; col++) {
            let tile = level[row][col];
            if (tile === GROUND || (tile === PLATFORM && !ignorePlatforms)) {
                return true; // Collision
            }
            if (tile === WATER || tile === FIRE) {
                return 'hazard';
            }
        }
    }
    return false;
}
```

For platform one-way behavior:
- When the player is moving upward (vy < 0), platforms are ignored
- When the player is moving downward (vy >= 0), platforms are solid
- Additionally, check if the player was above the platform before the collision

Actually, the simpler approach: only check platform collision if the player's feet were above the platform tile in the previous frame. Or even simpler: only check platform collision if vy >= 0 (player is falling or standing).

For the horizontal collision check on platforms, I should still allow the player to walk through platforms from the side. So platforms only block vertical movement when falling.

This is a bit tricky. Let me handle it like this:
- For horizontal movement: only check GROUND tiles
- For vertical movement: check GROUND tiles always, and check PLATFORM tiles only when vy >= 0

This means the player can walk through platforms horizontally (which is actually fine and common in platformers) and can jump up through them.

Wait, actually in most platformers, you CAN'T walk through platforms horizontally. You can only jump through them vertically. Let me think...

In Mario, for example, you can jump up through semi-solid platforms but you can't walk through them from the side. The collision is only from the top.

So the correct behavior is:
- If the player approaches from above (falling onto platform), resolve collision
- If the player approaches from below (jumping up), no collision (pass through)
- If the player approaches from the side, collision should block them

For side collisions on platforms, I should check: is the player's vertical position such that they're colliding with the platform from the side? This is when the player's feet are below the platform top and their head is above the platform bottom. In that case, block horizontal movement.

Actually, the simplest approach that works well:
- First move horizontally, checking only GROUND tiles
- Then move vertically:
  - If vy >= 0 (falling), check GROUND + PLATFORM tiles
  - If vy < 0 (jumping), check only GROUND tiles

For horizontal, also check PLATFORM tiles if the player isn't fully above or below the platform.

Hmm, this is getting complex. Let me simplify:

For horizontal movement:
- Check all solid tiles (GROUND + PLATFORM)
- But for PLATFORM, only collide if the player's vertical overlap with the platform tile is significant (meaning they're walking into it from the side, not jumping through it)

Simpler approach: for PLATFORM tiles, only do collision if the player's center y is below the platform tile's top + some threshold. This way, if the player is jumping up into a platform, they pass through, but if they're standing on it or falling onto it, it blocks.

Actually, the cleanest approach used by many platformers:

Platform tiles: only check for collision if the player was ABOVE the platform tile's top edge in the previous frame. In other words, the player can only collide with a platform tile from above.

This handles all cases correctly:
- Jumping up through: player was below, no collision ✓
- Falling onto: player was above, collision ✓  
- Walking into side while on same height: player was above (if they were on the platform or above it), collision ✓
- Walking into side while below: player was below, no collision... 

Hmm, that last case - if the player is walking into the side of a platform from below, they'd pass through. That's actually common in games like Mario too.

OK, for simplicity, let me just do:
- Horizontal: check GROUND, and check PLATFORM only if the player is at the same level as the platform (overlapping vertically)
- Vertical: check GROUND always; check PLATFORM only when vy >= 0 (falling)

This is good enough and feels natural.

Let me implement it this way.

Now, for the complete code, let me write it. I'm going to aim for clean, well-organized code.

Actually, you know what, let me just write the code. I've planned enough. Here goes:

I'll write the complete file in one go. It'll be long but complete and functional.

Let me focus on making the game fun and polished. Key things:
1. Good level design with variety
2. Satisfying jump physics
3. Clear visual feedback
4. Reasonable difficulty
5. Nice procedural graphics
6. Smooth camera

Here's the plan for my procedural graphics:

**Dirt tile**: 
- Fill: #8B5E3C (brown)
- Grid lines: darker brown (#6B3E1C)
- Small dots for texture
- If has air above: draw green grass strip on top 4px (#4CAF50 with variation)

**Platform tile (stone/brick)**:
- Fill: #9E9E9E (gray)
- Brick pattern: darker mortar lines
- Slight bevel effect

**Water**:
- Fill: #2196F3 with animation
- Lighter wave highlights that move
- Semi-transparent white lines for waves

**Fire**:
- Base: orange/red
- Animated flame shapes (drawn with bezier curves or simple shapes)
- Flicker effect using time

**Trophy**:
- Golden cup shape
- Base: trapezoid (wide at bottom, narrow at top)
- Stem: thin rectangle
- Cup: U-shape or half-circle
- Color: gold (#FFD700) with lighter highlights

**Exit door**:
- Door frame: dark brown rectangle
- Door: lighter brown
- Handle: golden circle
- When trophy collected: green glow effect

**Player**:
- Height: ~28px
- Width: ~20px
- Head: circle, skin color (#FFD5B8), radius 6
- Hat: red rectangle/bandana on top of head
- Body: blue rectangle (#2962FF)
- Arms: small rectangles extending from body
- Legs: brown rectangles (#5D4037)
- Boots: dark brown
- Walking animation: alternate leg positions

**Enemy**:
- Body: green oval/blob (#4CAF50)
- Eyes: white circles with black pupils
- Small feet
- Maybe antennae or horns
- Walking animation: squish effect

OK, truly writing code now. Let me produce the complete HTML file.

I need to be very precise with the collision detection and physics to make the game feel good. Let me code carefully.

For the level data, I'll create it as a 2D array filled with zeros, then add ground, platforms, hazards, etc.

Let me structure this well. I think the best approach is to:
1. Initialize level with all AIR (0)
2. Add ground (rows 16-19, all cols)
3. Cut gaps for pits
4. Add water/fire in pits
5. Add platforms
6. Add trophy and exit
7. Add enemy positions (separate array)

For enemies, I'll store them as objects with position, patrol range, etc.

For the trophy, it's a tile but also needs state (collected or not).

OK, time to produce the actual code. Here's the complete file:

I should note - I want the game to be completable. The level should be challenging but fair. With the level layout I've planned, it should be fun to play through.

Let me also add checkpoints. If the player dies, they respawn at the last checkpoint (or the start if no checkpoint reached). Checkpoints could be at certain columns, like every ~20 columns.

Actually, for a short game, respawning at the start is fine. With 3 lives, the player has a few attempts. Let me add a checkpoint at the trophy though - once you collect the trophy, if you die you restart at the trophy location.

Simple implementation: when trophy is collected, set checkpoint to trophy position. On death, respawn at checkpoint.

Now I'll write the complete file. No more planning!

Let me also handle screen transitions:
- Title screen: "DANGEROUS DAVE" style title, "Press SPACE to start"
- Playing: HUD with score, lives
- Death: brief animation, then respawn
- Game Over: "GAME OVER" screen
- Victory: "LEVEL COMPLETE" with score

For the HUD, I'll show:
- Score (top left)
- Lives (top right)  
- Trophy status (top center, shows if collected)

Alright, coding now. For real.

The code will be long - probably 700+ lines. Let me write it all out carefully.

I realize I should also handle what happens when the player falls into a pit (below the level). If they fall below the map, they die.

Also, I need to handle the left/right boundaries of the level - the player can't go off-screen to the left/right.

Let me write it all now. I'll produce clean, well-commented code.

One thing about the level design: I want variety in the heights players need to traverse. Some sections should be higher up, some lower. This makes the game more interesting.

I'll also add some collectible items (like gems or coins) scattered around to encourage exploration. Actually, let me keep it focused: just the trophy. But I'll place it in an interesting location that requires some platforming to reach.

The trophy could be on a high platform that requires some tricky jumps. Or it could be guarded by enemies/fire.

I think I'll place the trophy on an elevated platform around the middle of the level, with fire hazards below and enemies nearby. The player has to carefully jump up to get it.

Then the exit is at the far right, requiring the player to traverse the rest of the level after getting the trophy.

OK, final code structure:

```
1. Constants
2. Audio system  
3. Level generation
4. Game state
5. Player
6. Enemies
7. Particles
8. Input
9. Camera
10. Physics/collision
11. Update loop
12. Render functions
13. Game screens
14. Main loop
15. Event listeners
16. Start
```

Write it all now. Go.

One more consideration: animation frames. I want the walking animation to be smooth. I'll use a simple sine-based leg swing for the player and a squish effect for enemies.

For fire animation, I'll use sin(time) to vary flame heights and colors.

For water, I'll use sin(time + x_offset) to create wave patterns.

OK, NOW I'm writing the code. Here's the complete index.html:

Let me think about one final detail: the canvas should be responsive. I'll set it up so it scales to fit the window while maintaining aspect ratio.

```css
canvas {
    display: block;
    margin: 0 auto;
    image-rendering: pixelated;
    max-width: 100vw;
    max-height: 100vh;
}
```

And in JS, I'll set the canvas size to 800x480 internally and let CSS scale it.

Actually, for pixel-perfect scaling, I might use `image-rendering: crisp-edges` or `pixelated`. This makes the pixel art look sharp when scaled.

But since we're drawing procedurally (not pixel art per se), crisp scaling might look weird with smooth gradients. Let me just use default scaling.

OK. Writing the code now. This is the final version.

I'll focus on:
1. Clean, readable code
2. Good game feel
3. Complete game loop (title → play → win/lose → restart)
4. All procedural graphics
5. No external dependencies

Let me actually write it now. No more delays.

Quick note on drawing the player: I'll draw directly to the main canvas context. For efficiency, I could pre-render sprites to offscreen canvases, but for a game this simple, direct drawing is fine.

Here's my approach for drawing the player:
- Save context state
- Translate to player position
- If facing left, scale(-1, 1)
- Draw body parts
- Restore context state

For enemies, similar approach.

For the level tiles, I'll use fillRect and strokeRect with appropriate colors and patterns.

For fire animation, I'll draw flame shapes using quadratic curves or simple triangle-based flames that vary over time.

OK, here's the complete code. I'll write it as one big string and create the file.

Let me also add screen shake for when the player dies (a nice polish touch).

And particles for trophy collection (sparkle effect).

Particle system:
- Array of particles
- Each particle has: x, y, vx, vy, life, maxLife, color, size
- Update: move by velocity, apply gravity (optional), decrease life
- Render: draw with alpha based on remaining life
- Remove dead particles

I'll use particles for:
- Fire sparks
- Trophy collection sparkles
- Water splash on death
- Exit celebration

Now, for real, the complete code:

Let me think about the exact tile rendering. Each tile is 32x32 pixels. When rendering:

1. Ground tile (type 1):
   - Fill entire 32x32 with brown (#8B5E3C)
   - Draw slightly darker lines at edges for grid effect
   - If tile above is air: draw green strip at top 5px (#4CAF50)
   - Add some darker dots for texture

2. Platform tile (type 2):
   - Fill with gray (#9E9E9E)
   - Draw mortar lines: horizontal line at middle, vertical line at middle
   - Bevel: lighter top-left edges, darker bottom-right edges

3. Water tile (type 3):
   - Fill with blue (#1565C0)
   - Draw animated wave highlights with lighter blue

4. Fire tile (type 4):
   - Base: dark red/orange
   - Animated flame shapes on top using curves

5. Trophy (type 5):
   - Draw golden trophy on transparent background
   
6. Exit door (type 6):
   - Draw door on the tile

For tiles that aren't a full 32x32 (like trophy and exit on the ground), I'll need to handle this. The trophy and exit should be positioned on top of ground tiles.

Actually, for simplicity, let me have the trophy and exit tiles replace whatever is beneath them, and I'll draw the ground underneath plus the object on top.

Or even simpler: the level array defines the type of each tile, and when rendering, trophy/exit tiles render their object on top of a default background.

Actually, let me make trophy and exit sit on platforms or ground. The trophy tile will just be the object drawn in that tile space, and the level designer will ensure there's ground/platform below.

When collision checking, trophy and exit tiles are not solid.

Let me define the tile types clearly:
- 0: AIR (transparent, no collision)
- 1: GROUND (solid, blocky brown)
- 2: PLATFORM (one-way solid, gray stone)
- 3: WATER (hazard, blue animated)
- 4: FIRE (hazard, orange animated)
- 5: TROPHY (collectible, golden, no collision)
- 6: EXIT (goal, no collision, requires trophy)

All clear. Let me write the code.

For the level array, I'll initialize it with air, then populate it.

One more thing: the enemies array. Each enemy has:
- x, y (pixel position)
- vx (horizontal velocity)
- patrolLeft, patrolRight (patrol bounds in tile coordinates)
- type (maybe different enemy types later)
- alive (boolean)

Enemies move back and forth within their patrol range. If they hit a wall or edge, they reverse direction.

OK. Actually writing code now. Here's the entire file. I'll write it to index.html.

Let me finalize the level layout. I'll define it more precisely:

Level: 120 columns x 20 rows
Ground: rows 16-19 (4 rows tall)
Grass appears on row 15 of ground tiles.

Pits (remove ground rows 16-19 in these ranges):
- Cols 15-18: water (fill with water tiles at row 19, maybe 18)
- Cols 35-39: water
- Cols 55-59: fire (fill with fire tiles at row 19)
- Cols 75-79: water
- Cols 95-99: large water pit (final challenge)

Fire on surface (replace row 15 ground with fire):
- Col 25
- Col 45
- Col 68

Platforms (row, startCol, endCol):
- (12, 12, 17) over first water pit
- (10, 20, 25)
- (8, 30, 35)
- (13, 33, 38) over second water pit
- (10, 42, 47)
- (8, 52, 57)
- (13, 53, 58) over fire pit
- (11, 62, 67)
- (9, 70, 75)
- (13, 72, 79) over water pit
- (10, 82, 88)
- (8, 90, 95)
- (12, 93, 99) over final water pit

Trophy: at column 50, needs to be somewhere interesting. Let me put it on a platform at column 50, row 7 (on top of the platform at row 8, cols 52-57). Wait, that doesn't align. Let me put the trophy at col 50, row 14 (on ground, but near some challenge). Actually, let me put it at col 64, row 10 (on the platform at row 11, cols 62-67).

Exit: col 114, row 15 (on ground, at the end)

Player start: col 3, row 15 (on ground, starting position)

Enemies:
- col 22, row 15 (ground level, patrols cols 20-25)
- col 32, row 7 (on platform at row 8, cols 30-35, patrols within platform)
- col 43, row 15 (ground level, patrols cols 41-46)
- col 53, row 7 (on platform, near trophy area)
- col 65, row 10 (on platform at row 11)
- col 72, row 8 (on platform at row 9, cols 70-75)
- col 85, row 9 (on platform at row 10, cols 82-88)
- col 105, row 15 (ground level, patrols cols 100-110)

This gives good enemy distribution.

Now, for the enemy patrol logic, each enemy patrols between two tile columns. When they reach the edge, they turn around. If they reach a pit edge (no ground tile below), they also turn around (so they don't walk off platforms).

Let me implement this.

OK. WRITING THE CODE NOW. No more planning updates. Just produce the file.

I'll aim for completeness and quality. The code will be self-contained and run in any modern browser.

Let me write it...

The file has been written. Let me verify it's there and looks good. Let me also check if there are any issues I should be aware of. Let me review the key parts of the game:

1. Level design: 120x20 tiles, ground at rows 16-19, pits with water/fire, platforms, trophy at column 64 row 10, exit at column 114 row 15, enemies patrolling.

2. Physics: gravity, jumping, horizontal movement, friction, collision detection with ground (solid) and platforms (one-way).

3. Enemies: patrol back and forth, can be stomped from above.

4. Hazards: water and fire kill on contact.

5. Trophy: collectible, checkpoint when collected.

6. Exit: requires trophy to complete level.

7. Visual: procedural graphics for all elements, parallax background with stars and mountains.

8. UI: HUD with score, lives, trophy status. Title screen, game over screen, win screen.

9. Mobile: touch controls.

Let me verify the file exists.

The file is there - 30,935 bytes, 1,091 lines. Let me verify the game logic is sound by reviewing a couple critical sections. Let me check the collision detection and level design to make sure everything is right.

Let me also make sure the exit being at column 114, row 15 is actually on ground (not in a pit). Looking at the pits:
- 95-99 is a water pit
- So columns 100-119 should be ground. Row 15 column 114 should be ground with grass on top. Good.

But wait - the exit tile is placed at level[15][114] = EXIT. Row 15 is the surface row (grass row above ground). But wait, looking at my code - ground is rows 16-19, not 15. Row 15 is air (unless overridden with surface fire or trophy/exit).

Actually, looking at the code again: ground fills rows 16-19. Row 15 is left as AIR unless specifically set. So the exit at row 15 col 114 is floating in the air above the ground at row 16.

Hmm, that's actually fine since the exit is rendered as a door tile. It looks like it sits on the ground. But the collision system will see it as a non-solid tile (EXIT tile), so the player can walk through it. The exit trigger is in `checkCollectibles()` which checks the tile at the player's center.

But visually, the exit should appear to sit on top of the ground. Since ground is at row 16, and the exit is at row 15 (the tile above ground), it'll look like a door standing on the ground. That works.

Actually, wait - let me re-check. The tile drawing function for EXIT tiles draws a full 32x32 door. It will overlap with the ground tile below. But since they're drawn in order, the exit at row 15 is drawn, and then row 16 ground is drawn on top... Actually, the rendering goes row by row from startRow to endRow, so tiles at lower rows (higher row index) are drawn after tiles at higher rows. So ground at row 16 would be drawn AFTER exit at row 15, potentially covering the bottom part of the exit.

Hmm, that's a problem. The ground tile at row 16 would draw over the bottom portion of the exit tile at row 15. Let me think about this...

Actually, looking at the render loop: it goes r from startRow to endRow, and c from startCol to endCol. So for each column c:
- Row 15 (EXIT) is drawn first
- Then Row 16 (GROUND) is drawn, covering the bottom 32px of the EXIT tile

This means the bottom half of the exit door would be hidden by the ground. That's not ideal.

I have a few options:
1. Put the exit at row 14 instead of 15 (so it's 2 tiles above ground)
2. Change the exit drawing to be shorter (only top 16px of the tile)
3. Skip drawing ground tiles that are directly below EXIT tiles

Option 1 is simplest. Let me change the exit position or handle it differently.

Actually, the simplest fix is to put the exit one row higher (row 14) so it renders fully visible above the ground. Or I can modify the rendering so that non-AIR tiles above ground tiles cause the ground tile to not draw its top grass portion.

Alternatively, I can just draw the exit to look like it fits on the ground by making the door start at the top of the tile and extend down, where the ground covers the bottom. But that looks weird.

Let me just move the exit to row 14:
`level[14][114] = EXIT;`

And adjust the player collision - the exit trigger checks the player's center tile, so if the player is walking on the ground (row 15), their center would be at about row 14-15. Actually, the player stands on row 15 ground, so their center is around row 14. If the exit is at row 14 col 114, the player walking through would trigger it.

Wait, I need to think about this more carefully. The player's feet are at ground level (touching row 16 ground top). Player is 28px tall. So the player occupies roughly rows 14-15 when standing on ground at row 16. The player's center y is at about py + 14, which is roughly (15*32 + 14) = at row ~15.

With exit at row 14, the trigger check uses:
- tc = Math.floor((player.x + player.w/2) / TILE)
- tr = Math.floor((player.y + player.h/2) / TILE)

If player stands on ground (feet at row 16 top, y ≈ 15*32), player center is at y ≈ 15*32 + 14 = row ~15. So tr = 15, not 14. The exit at row 14 wouldn't trigger.

I need to either:
- Put exit at row 15 and fix the rendering overlap
- Or check a range of tiles for the exit trigger
- Or move the exit higher but also adjust the trigger

Let me go with: put exit at row 15, but in the rendering skip drawing ground tiles when there's an exit tile above. Or, simpler: just draw the exit tile AFTER the ground tile. But the loop goes column-by-column within each row...

Actually, the simplest approach: modify the render loop to draw all ground/platform tiles first, then draw special tiles (trophy, exit, fire, water) on top. Or just do two passes.

Let me restructure the rendering: draw all solid/background tiles first, then draw all overlay tiles.

Actually, an even simpler fix: just draw the exit tile at a position offset upward by TILE pixels so it renders entirely above ground. I can do this in the drawTile function or by placing the exit at row 14 and adjusting the trigger.

Let me go with this approach:
- Place exit tile at row 14 (one tile above ground)
- Modify the exit trigger to check a 2-tile vertical range (rows 14-15) at the exit column

Or even simpler: make the exit trigger check both the player's center tile and the tile below it.

Actually, the cleanest fix: modify `checkCollectibles` to also check the tile below the player for the exit. This way the exit can be at row 14 and trigger when the player walks below it.

Let me make these changes.

Also, I should verify the trophy placement. Trophy at row 10, col 64. Row 10 is above the platform at row 11. So the trophy sits on the platform. The player needs to jump onto the platform (row 11) and then their center would be at row 10, triggering the trophy collection. That should work well since the player is 28px tall, and jumping on a platform at row 11 means the player's head reaches up to about row 10.

Wait, actually if the player stands on the platform at row 11 (feet at row 11 top, which is pixel y = 11*32), the player's center y = 11*32 + 14 = around row 11-12. The trophy at row 10 would be above the player's center. The player needs to be higher to collect it.

Hmm, the player needs to jump to reach the trophy. Let me put the trophy on row 10 (directly on the platform at row 11). When the player jumps while on the platform, their center can reach row 10.

Actually, let me just move the trophy to row 11 (on the same level as the platform). Wait, but row 11 has the platform. I could put the trophy at row 10 but on a different column... 

Let me reconsider. The platform is at row 11, cols 62-68. The trophy is at row 10, col 64. This means the trophy sits right above the platform. The player standing on the platform has feet at y = 11*32 + 32 (bottom of feet) = row 12 top? No...

Let me be precise:
- Platform tile at row 11: occupies y from 11*32 to 12*32-1
- Player stands on the platform, so player.y + player.h = 11*32 (top of platform)
- Player.y = 11*32 - 28 = 11*32 - 28
- Player center y = player.y + 14 = 11*32 - 14
- tr = Math.floor((11*32 - 14) / 32) = Math.floor(11 - 14/32) = Math.floor(10.56) = 10

So when the player stands on the platform at row 11, their center is at row 10! The trophy at row 10 would be collected simply by standing on the platform. That's actually fine - the trophy is sitting on the platform, and the player grabs it by reaching that height.

To make it more interesting, let me put the trophy on a separate, smaller platform one tile higher. But actually, this is fine for gameplay. The trophy is on a platform, and the player has to reach the platform to get it.

Let me keep the placement. But the issue is that the trophy tile at row 10 renders above the platform at row 11, which means the trophy draws on its tile and the platform draws below. Since the trophy tile is drawn first (row 10) and then the platform (row 11), the platform at row 11 doesn't overlap the trophy since the trophy is a whole tile above.

Wait, actually the trophy renders its own background. But that's fine since the platform below (row 11) provides the collision surface, and the trophy at row 10 is just visual + trigger.

OK, I think the trophy placement is fine. The rendering order works because row 10 (trophy) and row 11 (platform) are separate rows with no overlap.

Now, back to the exit issue. Let me fix the exit rendering. Options:
1. Put exit at row 15 and fix rendering overlap with row 16 ground
2. Put exit at row 14 and make trigger check both rows

I'll go with option 1 - put exit at row 15, but in the render loop, after drawing all tiles, draw exit and trophy tiles on top. Or better: do two render passes.

Actually, the simplest solution that doesn't require restructuring the render loop: swap the rendering so that for each column, we draw from bottom to top. That way, ground at row 16 is drawn first (bottom), then exit at row 15 is drawn on top.

Hmm but that makes grass-rendering weird (grass on top of ground is drawn based on whether the tile above is AIR - if exit is above, it's not AIR, so no grass is drawn on the ground tile below the exit - which is actually correct behavior!).

Wait, the grass check is: `if (r > 0 && level[r-1][c] === AIR)` - this checks the level array directly, not based on rendering order. So if ground at row 16 has exit at row 15 above it, level[15][114] is EXIT, not AIR, so grass won't be drawn on that ground tile. That's correct - the exit door replaces the grass.

If I render bottom-to-top (row 19 down to row 0), the ground at row 16 would be drawn first, then the exit at row 15 on top. The exit tile draws its own background (dark gray), so it would cover the top half of the ground tile. That's perfect!

But wait, there's an issue with bottom-to-top rendering: water and fire tiles in pits. Ground is removed in pits, and water/fire fills row 19. With bottom-to-top, row 19 water/fire is drawn first, then... nothing above since those are AIR tiles. That's fine.

What about ground fire (surface fire at row 15, with ground at row 16 below)? Fire at row 15 draws first (if rendering bottom-to-top), then ground at row 16 draws... wait, no. Bottom-to-top: row 19 first (bottom), then 18, 17, 16... So ground at row 16 draws, then fire at row 15 draws on top (partially covering the ground below the fire). But fire rendering fills the entire tile with a dark red background, so it would cover the grass/dirt below. That's actually fine for the visual.

Wait, fire should render ON TOP of the ground visually (flames rising from the ground). With bottom-to-top rendering, fire at row 15 (above ground) draws after ground at row 16, so fire overlaps the ground. But fire draws a full tile background (dark red). The flames extend upward from the bottom of the fire tile (or top of the tile below). Hmm, my fire drawing code draws flames going UP from the bottom of the fire tile. So the fire is drawn in its own tile space, with flames at the bottom. If fire is at row 15 and ground is at row 16, the fire tile bottom is at row 15 bottom = row 16 top. The flames go up from there. The dark red background fills the fire tile (row 15), which is above the ground. That actually looks fine - the ground below is unaffected, and the fire sits on top.

OK, bottom-to-top rendering would work. Let me change the render loop.

Alternatively, even simpler: just render the exit tile at a higher position by adjusting its drawing. Let me modify the EXIT drawing to be positioned as if it starts at the top of the tile below (i.e., offset by TILE upward). 

Actually, the cleanest fix is just a two-pass render: first pass draws all normal tiles (GROUND, PLATFORM, WATER, FIRE backgrounds), second pass draws overlay elements (TROPHY, EXIT, FIRE flames). But fire flames need the dark background too...

OK let me just do bottom-to-top rendering. Change:
```
for (let r = startRow; r <= endRow; r++) {
```
to:
```
for (let r = endRow; r >= startRow; r--) {
```

This way, lower rows (higher index) are drawn first, and higher rows (lower index) draw on top. Ground at row 16 draws first, exit at row 15 draws on top, covering the grass portion of the ground.

This also fixes any other overlay issues and is generally correct for rendering tiles.

Let me make this change and also verify a few other things.

Also, I need to reconsider: with bottom-to-top rendering, when water is at row 19 (bottom) and ground surrounds it (rows 16-18 removed), the water draws first (row 19), then the walls of the pit draw (rows 18, 17 - these are AIR since the pit removed ground), then... wait, the pit removes rows 16-19. So rows 16-18 in the pit are AIR. They draw nothing. Row 19 in the pit is WATER. Then ground resumes outside the pit at rows 16-19.

Hmm wait, the pit function removes ground from rows 16-19 and puts water at row 19. So in pit columns:
- Rows 16-18: AIR
- Row 19: WATER
- Row 20+: doesn't exist (max row is 19)

The water at row 19 fills the bottom-most row. The walls of the pit (row 15 and above) are AIR. So the player falls into the pit and hits the water at row 19.

With bottom-to-top rendering: water at row 19 draws first. Then rows 18-16 draw nothing (AIR). Then row 15 draws whatever is there (AIR or something else). This is fine.

What about rendering a pit adjacent to ground? The ground at columns 14 and 19 (outside the pit) would draw at rows 19, 18, 17, 16. Water at columns 15-18, row 19 draws. The ground at column 14, row 19 draws next to the water. Both are at row 19, so order depends on column iteration. Since they're side by side, there's no overlap issue.

OK, bottom-to-top rendering works fine. Let me make that change.

Also, let me lower the exit placement so it's on row 15 (ground surface). With bottom-to-top, ground at row 16 draws first, exit at row 15 draws on top.

Let me make the edit now.

Good. Now let me also move the exit from row 15 to row 14 so it renders fully above the ground. Actually wait, with bottom-to-top rendering, row 15 exit draws ON TOP of row 16 ground. So the exit tile background covers the top of the ground tile, which looks fine. The exit at row 15 should work.

Let me keep it at row 15. The bottom-to-top fix handles the rendering. And the broadened trigger checks both the player's center tile and the tile below.

Let me also move the trophy to row 10 instead of having it on the same row as the platform. Wait, it's already at row 10 with the platform at row 11. That should be fine.

Actually, I realize there might be an issue with the exit check. The exit is at row 15, col 114. The player's center, when standing on ground at row 15 (feet at row 16 top), is at approximately row 15 (y center = row 15*32 + 14 = row ~15). So tr would be 15, and the exit at level[15][114] would be detected. Good.

Let me also make sure the ground isn't in a pit at column 114. Pits:
- 15-18: water
- 35-39: water
- 55-59: fire
- 75-79: water
- 95-99: water

Column 114 is after all pits. The ground at rows 16-19 should be intact there. Good.

Now let me verify the game by checking the file once more. Let me re-read the critical sections.

Actually, I should also test this semantically. Let me think through the complete gameplay flow:

1. Title screen appears
2. Player presses Space
3. Game starts, player at column 3, row 15 (on ground)
4. Player moves right, jumps over pits, avoids fire and enemies
5. Player reaches column 64 area - needs to get onto platform at row 11
6. Trophy at row 10, col 64 - player collects it by being at that height
7. Checkpoint set at trophy location, trophy status saved
8. Player continues right, avoids more hazards
9. Player reaches column 114, walks into exit door at row 15
10. Exit triggers (hasTrophy is true), game won!

If player dies:
- Respawns at last checkpoint (trophy location if collected, otherwise start)
- Lives decrement
- Invulnerability for 1.5 seconds

If all lives lost:
- Game over screen

This should all work. Let me verify the file is in good shape.

One thing I want to double-check: the enemy stomp mechanic. When the player is falling (vy > 0) and lands on an enemy:
```
if (player.vy > 0 && py + ph - e.y < 12) {
```

This checks that the player is falling AND that the player's bottom is close to the enemy's top (within 12px). This should work for stomping.

Also, I want to make sure the death trigger from hazards works properly. The `rectOverlapsHazard` function checks the 4 corners of the player's bounding box. For fire at row 15 (surface fire), the player walking on adjacent ground wouldn't overlap the fire tile unless they walk into it. The player at row 15 (standing on ground at row 16) has feet at approximately row 15-16 boundary. The fire tile at row 15 occupies the full 32px of row 15. If the player's x overlaps with the fire tile's x, the player's corners would be within the fire tile, triggering death. Good.

But wait - the player stands ON the ground at row 16 (feet at y ≈ 15*32). The fire at row 15 occupies y from 15*32 to 16*32-1. The player's bottom corners are at y + h - 1 ≈ 15*32 + 27. That's within [15*32, 16*32-1], which is the fire tile. So walking into a surface fire tile from the side would trigger the hazard check. Death from fire works.

What about walking over a fire tile on the ground? If fire is at row 15 and the player walks through it, all 4 corners would be in fire territory, triggering death. Good.

Water in pits: water is at row 19. The player falls into the pit and reaches row 19, the water tiles trigger death. Good.

I think the game is complete and functional. Let me verify the file once more.

The collision detection looks correct. Let me verify the exit check code and the game over / win transitions.

Everything looks good. The enemy AI checks for ground below, reverses at patrol bounds or edges, and handles player collision (stomp or death). The game over transition is correct: when all lives are lost, it goes to STATE.GAMEOVER.

The file is complete and should work. Let me provide a summary to the user.

One thing I want to verify is that the file is valid HTML and has no syntax errors. Let me do a quick check.

The file is valid - JS syntax is OK, it has canvas, style, and DOCTYPE. The game is complete.

Let me provide a summary of what was built.