Dangerous Dave platformer · particle-1

Let me design the game.

Canvas, tile-based, 16px tiles scaled up maybe 32px. Screen ~960x600 (30x18 tiles at 32px = 960x576).

Design level with solid platforms, trophy, exit, fire hazards, water hazards, patrolling enemy. Need reachable route.

Let me define tile grid width 40, height 20 (at 28px => 1120x560?). Let's use camera? Keep it simple: entire level fits on screen. 40x20 tiles at 24px = 960x480. Canvas 960x560 with HUD area. Actually just canvas 960x540 with HUD overlay HTML.

Tile 24px, 40 cols x 20 rows = 960 x 480 canvas. Maybe canvas fits 960x480. Fine.

Let me carefully design a level map as strings. 40 chars wide, 20 rows.

Legend:
- '#' solid brick
- '.' empty
- '=' platform (solid, decorative)
- 'W' water tile (hazard)
- 'F' fire tile (hazard, animated)
- 'P' player spawn
- 'T' trophy
- 'E' exit
- 'X' enemy spawn
- maybe '^' spikes? Fire covers hazard requirement.

Design 40x20:

Row indices 0..19.

Let me sketch a level with a floor, platforms, water pit, fire pit, and a path to exit.

I want route: start bottom-left, go right over platforms, jump across water, avoid fire, reach trophy high, then exit.

Let's lay out:

```
row0:  ########################################
row1:  #......................................#
row2:  #......................................#
row3:  #.......................====...........#
row4:  #......................................#
row5:  #............====..............T.......#
row6:  #.....X................................#
row7:  #=========.............................#
row8:  #.........................====.........#
row9:  #......................................#
row10: #..........................F...E.......#
row11: #................===...................#
row12: #......................................#
row13: #.....====.............................#
row14: #......................................#
row15: #...........................====.......#
row16: #......................................#
row17: #P......................................#? 
row18: ####.........WWWW.........FF...........#
row19: ########################################
```

Hmm need coherent jumping. Tile 24px, jump height should be ~3 tiles, horizontal jump range ~4-5 tiles.

Let's simplify and make a thoughtful map. Player sprite 18x26 maybe, gravity and jump velocity.

Jump physics: jump velocity -8.2 px/frame at 60fps, gravity 0.5 => max height ~ 8.2²/(2*0.5) = 67px ~ 2.8 tiles. Horizontal speed 3.2 px/frame, airtime ~ 2*8.2/0.5 = 32.8 frames => horizontal ~105px ~ 4.4 tiles. Good.

Let me use tile 24. Canvas 960x480.

Level design:

Floor at rows 18 (top surface row 18?) Let's define solid rows 17-19 bottom floor. Pits with water/fire embedded in floor row 18-19.

Map rows (40 wide):

I'll write each row exactly 40 chars.

Row 0: "########################################"
Row 1: "#......................................#"
Row 2: "#......................................#"
Row 3: "#......................................#"
Row 4: "#..........................===.........#"  -- platform
Row 5: "#......................................#"
Row 6: "#.........===.................T........#"   T trophy at high? Need reachable.
...

Let me think about actual route instead of random.

Start at bottom-left on floor. There are fire hazards on floor that must be jumped over, water pit requiring platforms.

Plan horizontal course left→right along floor with hazards and gaps, then vertical ascent via platforms on right to trophy, then exit door at right on raised platform? Or exit ground.

Simpler and robust:
- Bottom floor spans full width except a water pit (gap with W hazard) around cols 14-18 and a fire zone cols 24-27 (fire tiles sitting on floor).
- Platforms above to cross water gap: platform at row 15 cols 14-17.
- Trophy on a platform at row 10 cols 32-35, reachable by ascending platforms at right.
- Exit on floor at far right (col 37), ground level, with door graphic 2 tiles tall.

Route: run right, jump over fire, reach water gap; jump onto platform row 15 then across to other side; continue right; climb platforms at right: platform row 15 cols 27-29, row 12 cols 31-33, row 9 cols 34-36? Then trophy on row 9 platform? Then descend to exit on floor right.

Need ensure reachable jumps: platform vertical gaps <= 2 tiles (48px) and horizontal <= 3 tiles. Jump height ~67px => can rise 2 tiles (48px) safely. Let's keep rises at 2 tiles and horizontal gaps <=3 tiles.

Define:

Ground floor: rows 18-19 solid across, except water gap cols 13-17 where rows 18-19 are water hazard (W) and no solid (so falling in = loss), and fire tiles: place F at row 17 cols 24,25 sitting on ground (hazard tiles on top of floor). Fire is a hazard tile occupying row 17.

Water gap cols 13-17 (5 wide) - need crossing platform at row 15 spanning cols 13-15? Jump from col 12 ground up 3 tiles? Too high? Ground surface is top of row 18 => y=18*24=432. Platform at row 15 top = 360, 72px above — too high (>67). Use row 16 platform: top=384, 48px above -> reachable. Then from platform to right edge ground at col 18. Horizontal from platform drop easy.

Actually simpler: water gap with a single stepping stone platform at row 16 in the middle. Jump from ground col 12 to stone top row16 col 15 (horizontal 3 tiles = 72px, vertical up 48) — combined possible? Jump arc: at 48px up, horizontal traveled around... time to rise 48px at v=8.2, g=0.45: solve 8.2t-0.225t²=48 => 0.225t²-8.2t+48=0 => t=(8.2-sqrt(67.24-43.2))/0.45 = (8.2-4.9)/0.45=7.3 frames => horizontal at speed 3.2 = 23px. Hmm too short! Player needs horizontal 72 - but can jump first and move horizontally; max height reached at t=18 frames, horizontal 58px. Then descending to row16 platform. Actually it's about landing on the platform when at proper height. With max height 74 (using g=0.45) > 72? 8.2²/(2*0.45)=74.7px = 3.1 tiles. So can reach 3 tiles high at apex but horizontal distance at apex ~58px (2.4 tiles). So jumping up 2 tiles and 3 tiles across is tight but possible? Let's compute: target platform top 48px above start, at horizontal dx. Player's y offset 48 at t≈7.3 (ascending) and t≈29 (descending? total airtime 36.4, symmetric-ish: t2=36.4-7.3=29.1). At descending t=29.1 horizontal = 93px. But the player's feet need to clear the platform edge before landing... Could land on top at up to ~93px away. So 3-tile gap with 2-tile rise is doable but requires near peak. Let's be generous: use tile 24, speed 3.6, jump 9.0, gravity 0.5.

v=9, g=0.5: max height 81px (3.4 tiles), airtime 36 frames, horizontal range 3.6*36=129px (5.4 tiles). Height 48 px at: 0.25t²-9t+48=0 => t=(9±sqrt(81-48))/0.5 = (9±5.745)/0.5 => t1=6.5, t2=29.5. Horizontal at t2 = 106px = 4.4 tiles. Good margins.

I might also implement coyote time & jump buffering for playability. Jump only allowed while grounded (requirement) — coyote time slightly extends grounded state; maybe acceptable but to be safe require actual grounded (onGround flag), no coyote. Fine.

Let's design final map 40x20 with tile char.

Rows:

0:  border
1-... interior.

Let me place:

- Ground: row 18 and 19 solid '#'; water gap at cols 13..17 both rows replaced by W (hazard) and not solid.
- Fire on ground: F at row 17, cols 23,24.
- Second fire maybe row 17 cols 30? no, keep one fire zone (2 tiles).
- Platforms for climbing near right:
  - platform A: row 16, cols 24..26? That's above fire - could be used.
  Hmm.

Let me define a clearer route:

Ground run from col 1 to col 12. Water pit cols 13-17. Stepping platform at row 16 col 15 (a 2-wide platform cols 14-16? spanning 3 tiles maybe easier).
Ground resumes cols 18-22. Fire at cols 23-24 on ground (row 17). Ground continues cols 25-36. Exit door at cols 36-37 on ground (row 16-17), marker E.

Trophy on high platform: platform at row 9, cols 30-33 with trophy at col 31 row 8. Climb route from ground right area:
- Platform P1: row 15, cols 26-28 (top 360, ground top 432 → 72px rise; 3 tiles; with v=9 max 81, tight but okay). Maybe better 2 tiles: row 16 top=384 (48 rise). P1 at row 16, cols 26-28.
- P2: row 13, cols 29-31 (rise 48 from P1, horizontal offset ok).
- P3: row 11, cols 30-32 (rise 48).
- Trophy platform P4: row 9, cols 32-34, trophy at col 33 row 8 (rise 48 from P3).

Then exit on ground far right (cols 36-37, row 16-17). Need to climb down — just fall, fine. Also need trophy collected then exit.

But the player could skip climbing then go to exit and get "need trophy" feedback. 

For the platform tiles, use solid tile type '=' which is solid and looks like metal/brick platform. To make the level look Dave-like, brick colors.

Wait: also the trophy must be visually identifiable, and exit. Use E tile rendered as door.

Enemy patrolling: on the ground region between cols 18-22 or on a platform. Enemy with horizontal patrol, turns at edges/walls. Put enemy at col 20 on ground, patrolling cols 18-22. But player must pass through there to reach right side and exit; enemy creates challenge. Player can jump over. Ensure enemy doesn't block impossible. Fine.

Maybe enemy on top of platform P1? Could fall off edges if patrol edges. I'll implement edge detection to turn around.

Collision: AABB vs tile solids. Player size 16x24. Tile 24.

Player spawn P at row 17, col 2 (standing on row 18). Player y = row*24 + (24 - 24) = 17*24=408, feet at 432. With height 24 fits exactly.

Camera: level width 960 = canvas width, no camera. Good. HUD in HTML above canvas showing controls and status.

Canvas 960 x 480. Add HUD overlay in HTML for trophy status "Trophy: missing / collected" and message. Draw win/lose overlays on canvas or via HTML? Use canvas overlay for win/lose and a Restart button in DOM. Use HTML button; also R key. Visible feedback when reaching exit without trophy: show banner "You need the trophy!" for ~2s.

Fire animation: procedurally drawn flame shapes using sine. Water: wavy animated blue. Enemy: red blob with eyes and feet animation. Trophy: gold cup. Exit: door with frame and glow. Player: Dave-like: blue overalls, cap? Draw simple character with head, body, arms, legs animated walking.

Decorative background: dark cave with brick texture, stars? Keep procedural: gradient background, brick pattern on tiles.

Implement game loop with requestAnimationFrame and dt clamp, fixed timestep maybe. Use physics per frame with dt normalization.

Level data as strings. Let's craft each row 40 chars carefully.

Columns 0..39. Border walls at col 0 and 39 and row 0 and row 19? Row 19 is bottom ground. Row 0 top border. Let's make outer frame solid for containment.

Let's write rows:

Row 0:  "########################################" (40)

Row 1:  "#......................................#" (1 + 38 + 1 = 40)

Row 2:  "#......................................#"

Row 3:  "#......................................#"

Row 4:  "#......................................#"  maybe platform decor.

Row 5:  "#......................................#"

Row 6:  "#......................................#"

Row 7:  "#......................................#"

Row 8:  "#...............................T......#"  -- trophy at col 32, row 8. But P4 platform row 9 cols 31-33. Let's compute.

Row 9:  "#..............................====....#"  -- platform cols 31-34? Need exact positions.

Let me index carefully. I'll write with a helper to validate lengths.

Better: build map programmatically? No, keep strings and validate.

Let me define positions numerically:

- Exit: cols 36-37 at rows 16-17. Solid elsewhere? Exit marker 'E' at (36,16) and (37,16)? Use one E tile at col 36 row 16 plus door visual spans 2x2. Simpler: exit trigger zone occupying x 36*24=864 to 38*24=912, y row15..17. Ground at row 18 top. Draw door on ground at cols 36-37, rows 15.5-18. Tile map mark two E tiles at rows 16,17 cols 36 and 37? But those tiles are non-solid. Fine, mark E in map for rendering. Trigger when player overlaps door rect.

- Trophy platform P4 row 9 cols 31-34? Trophy at row 8 col 32.
- P3 row 11 cols 28-30.
- P2 row 13 cols 26-28.
- P1 row 16 cols 25-27? Hmm climbing near exit might conflict with fire at cols 23-24. Let's move fire to cols 20-21 (ground hazard) and enemy patrol at cols 18-19? Hmm.

Let me restructure right side:

Ground from col 18 to col 35 (except fire hazard at cols 20-21 on row 17), then door at cols 36-37, wall col 38-39? Right border col 39 solid. The door at col 36-37 rows 16-17.

Climb route above ground cols 24-34:
- P1 row 16: cols 24-26 (top 384, ground 432 -> 48 rise, horizontal from ground).
- P2 row 14: cols 27-29 (48 rise, horizontal overlap).
- P3 row 12: cols 30-32.
- P4 row 10: cols 32-34, trophy at col 33 row 9.

Jump from P3 (row12 top=288) to P4 (row10 top=240): 48 rise and horizontal: from col32 to col33 etc. Fine.

Then from P4, exit is down-right on ground: fall from row 10 to ground row 18 = 8 tiles fall — fine (no fall damage). Door x 864-912. P4 cols 32-34 => x 768-840. Drop down and run right.

Enemy patrol on ground cols 18-22 maybe between water edge and fire, but then player jumps fire after. Alternatively enemy on ground cols 27-31 to threaten near ladder. Player can jump over. Put enemy at cols 28 on ground patrolling 26-31.

Fire hazard at ground cols 20-21 only, plus maybe fire pit? The requirement says fire and water hazards. Water pit satisfies water. Fire tiles satisfy fire.

Maybe add fire pits in floor: fire tiles at row 17 cols 20,21 sitting on ground. Player must jump over 2 tiles wide fire (48px) easy.

Trophy must be collected before exit. Fine.

Also ensure bottom border row 19 solid except water gap rows 18-19 replaced with W? Water pit should be at floor level: rows 18,19 of cols 13-17 => hazard. Player falls in, touches water => loss. There's no solid under, so they'd fall out of level; hazard triggers first.

Stepping stone over water: platform at row 16, cols 14-16. Jump from ground col12 (top 432) up to platform top 384 (48) horizontal: from player at col12 right edge x≈12*24+24 = 312; platform left col14 x=336. Gap 24px, easy. From platform right edge col16 x=408 to ground col18 x=432, drop 48 - easy.

Also the water pit spans cols 13-17 (5 tiles = 120px). Under the stepping stone at row 16 cols 14-16.

Now, could player simply jump over entire water pit without platform? 120px plus, with max range 129px, maybe; but that's fine.

Now let's define row strings with these features.

I'll write the map via rows:

Row 0: solid all.

Rows 1-7 mostly empty.

Row 8: trophy at col 33? Wait P4 row 10, so trophy sits on top of P4 => row 9, col 33. Trophy tile doesn't need solid.

Row 10: P4 cols 32-34: '=' at positions 32,33,34. Trophy at row 9 col 33.

Row 12: P3 cols 30-32.

Row 14: P2 cols 27-29.

Row 16: P1 cols 24-26, and stepping stone cols 14-16, and exit E at rows 16,17 cols 36,37? Let's draw exit door as E at rows 15..17? Door height 2 tiles: rows 16 and 17. But row 17 also ground-standing hazard? Door tiles are non-solid; player walks into trigger.

Ground row 18 solid except water cols 13-17. Row 19 solid except water cols 13-17.

Fire: row 17 cols 20,21 as F. Note player standing on ground occupies rows 16-17 area; fire is a hazard tile. Collision check with hazard tiles should allow touching.

P at row 17 col 2.

Enemy X at row 17 col 28? Enemy is on ground; spawn tile row 17 col 28. Patrol bounds computed by walking.

Now tile map rows 40 chars. Let me construct with a script to avoid length errors. I'll write levels with arrays and fill.

Actually simplest: define base map with strings generated from a 2D array in JS. But editing readability fine either way. I'll use JS arrays of strings but generate using code? No—just verify lengths with a node script after writing.

Let me generate rows in Python/Node for accuracy. I'll construct with a script now to print strings then embed.

Let me do that.

Additional features:
- HUD: controls displayed. Score/trophy status.
- Restart button + R key, visible during play and on win/lose.
- Loss state on hazard/enemy, win on exit with trophy.
- Exit without trophy: message overlay toast and keep active (brief invulnerability/cooldown so it doesn't spam).

Implementation details:

Game state object:
```js
const state = {
  mode: 'playing'|'won'|'lost',
  trophy: false,
  message: '',
  messageTimer: 0,
}
```

restart(): reset player position, velocity, trophy=false, enemy reset, mode playing, time.

Physics:
```
const GRAVITY = 0.5; // px per frame^2 at 60fps
const MOVE = 3.6;
const JUMP = 9.0;
```
Use fixed step dt in seconds: update(dt) with accumulator and fixed 1/60 steps. Simpler: use frame dt clamp and scale physics by dt*60; fine.

Collision resolution: move x then check solid overlap, resolve; move y then resolve; set onGround when moving down and collided.

Player rect: w=16,h=26? Tile 24. Player 16x26 fits stairs? height 26 > 24 means when standing on floor at row18, top at 432-26=406 (row 16.9). Fine. But if spawn at row 17 col 2, place feet on ground: y = 432 - 26 = 406.

Solid tile check: '#' or '='. Platform '=' should be solid all sides (simple). To make climbing easier, might make '=' one-way? No, solid is fine.

Water 'W' and fire 'F' hazard tiles: check overlap with tile rect; fire drawn with flames extending above but hazard rect is tile. Maybe fire hazard rect should be the tile row 17 (from y=408 to 432) — player standing adjacent... collision check overlap.

Enemy: AABB 20x22, patrol speed 1.2 px/frame, turn at solid wall or ledge (check tile below ahead). Reset position.

Player-enemy collision → lost.

Falling below canvas → lost? Yes if y > 480+100.

Drawing:
- background gradient + subtle cave stalactites/pattern, grid of bricks.
- Solid tiles: brick pattern: base color #6b4a2f, mortar lines, highlights. Platform '=' different: stone brick #7a7f8c? Keep Dave-like brown brick with top grass? Dangerous Dave uses blue/red bricks. Use textured bricks.

- Draw water animated with sine wave surface and bubbles.
- Fire animated flames with layered shapes, flicker.
- Trophy: cup with handles and glow, bobbing.
- Exit: door arch with "EXIT" sign, glow, maybe arrow. Identifiable. Add sign text rendered on canvas.
- Player: draw character with head, hat, overalls, animated legs when walking, direction facing.
- Enemy: red/purple bouncing blob with eyes.

- Overlay on win/lose: semi-transparent panel with message and "Press R or click Restart".

Also draw hint arrows? Not necessary.

Camera static (level 960x480, canvas 960x480). Use DPR scaling for crispness.

HTML layout: dark page, title, HUD row (controls + trophy status + restart button), canvas centered, footer hint.

Canvas internal 960x480; CSS max-width 100%.

Now build map strings.

Let me write Node script to generate.

Check positions:
- P4 platform row 10 cols 32-34? The output row10 shows = at index 31..33 maybe. Let me check: row 10 "#...............................===....#" — count dots. 31 dots? Index: '#' at 0, then dots 1..31 (31 dots), '=' at 32,33,34. Trophy row 9: "#................................T.....#" -> T at index 33. Good.

- Row 12 "#.............................===......#" = at 30,31,32. Good.
- Row 14 "..........................===........." -> 26 dots? '#' + 26 dots (1..26), '=' at 27,28,29. Good.
- Row 16 "#.............===.......===.........EE.#": '=' at 14,15,16, and 24,25,26; E at 36,37. Good.
- Row 17: P at 2, F at 20,21, X at 28, E at 36,37. Wait the output "........FF......X" – F at? index 20,21? Let's count: '#.P' -> 0 '#',1 '.',2 'P'. Then dots 3..19 (17 dots), F 20,21, dots 22..27, X 28. Yes.

Water at 13..17 row 18. Good.

Now check reachability:
- From ground to stepping stone row16 cols14-16: top y=384, ground top 432. Player jump height ~81. OK. But fire at cols20,21 row17, player on ground and must jump over 48px wide flame. Easy.

- Enemy patrol on ground row 17 near col28, patrol area from maybe col 22 to col 35 (door area). Door is non-solid; enemy can patrol to the wall. Enemy could wander into door zone, fine. But enemy on ground where player needs to pass to reach platforms at col24-26. Player jumps onto P1 platform from ground while avoiding enemy.

- Climb P1 row16 (top 384) → P2 row14 (top 336): rise 48, horizontal: P2 cols27-29, P1 cols24-26 adjacent. Easy jump up? Player standing on P1 at col25 top 384; P2 starts x=648 (col27). Player can walk to P1 right edge x=648, and P2 left edge is 648 directly above at 336. Player standing feet at 384, head ~358; P2 underside at 360? Wait P2 row14 occupies y 336..360. Player head at 384-26=358, which would overlap the platform under? Player standing at P1 right edge with x up to 648, platform above starts x=648, so no overlap. Jumping straight up at edge, then right slightly to land. Horizontal adjacent is doable but the head may bump underside if under. Since P2 begins where P1 ends, jumping from edge works: move right into open column while rising 48. Should be fine. Actually to land on P2 top (y=336) player feet must rise 48 above 384, yes max 81.

- P2 (cols27-29, top 336) → P3 (row12 cols30-32, top 288): again adjacent diagonally, rise 48. Good.
- P3 top288 → P4 row10 cols32-34 top 240: rise 48, adjacent. However P3 cols30-32 and P4 cols32-34 overlap at col32. So P4 overhangs P3 at col32. Player on P3 at col31 jumps up; at col32 platform above at row10 (y240..264). Player's head when standing P3 (feet 288, head 262) is just below P4 bottom 264 — 2px gap, so player can move under? Standing height 26, feet at 288, head at 262, P4 bottom at 264, overlap of 2 px! That would cause player standing on P3 at col32 to be stuck/embedded. Actually player can't stand at col32 because the tile above at row10 col32 bottom is 264, player top 262 => collision. The x-then-y resolution would push them down? Since player is not solid-overlapping when placed? He'd be overlapping solid tile by 2px, resolution might jitter.

Make player height 24 instead of 26 to fit exactly tile height: standing on top at y=288-24=264, exactly the platform bottom above. Zero gap—still tight but not overlapping. Jumping up from P3 at col32 would immediately hit ceiling; but can jump at col30/31 and move over. Hmm risk.

Better avoid overlap: P4 cols33-35, trophy col34. Then P3 cols30-32. No overlap: P4 starts col33, P3 ends col32. Adjacent. Let me shift trophy platform to cols33-35 and trophy at col34 row9. Door starts col36. P4 ends x=36*24=864, door at x=864. Fine, platform adjacent to door zone (door trigger at rows16-17).

But P4 at row10 cols33-35, top 240. Standing on P4, player top 216, fine.

Enemy: X at row17 col28. Player needs to pass. Fine.

Also check the player can fall from P4 to ground and exit. Yes.

Now jump from ground onto P1 (row16, cols24-26): ground top432 to 384 = 48. Horizontal fine. Player approaches from left at ground; enemy nearby. Good.

Could player reach trophy route from the right side too. Fine.

One concern: platform '=' as solid tiles means player can hit head on their underside when jumping from ground beneath P1 etc. That's okay; player jumps from beside.

Now update map: move P4 to cols 33-35, trophy col34 row9. Also check row 10 string.

Let me regenerate with that adjustment. Also maybe make platform widths 3 tiles.

Also consider making enemy patrol on ground between col 22 and col 34. Edge detection: ledge at water? Not in that range. Wall at door? Door non-solid, so ends at border col38. Fine.

Let me also add another fire hazard maybe on P3? No.

Ensure water hazard row 18/19 is reachable to touch: player falling into gap will collide with water tile (hazard) → lose instantly.

Now let me write index.html.

Key implementation snippets:

```js
const TILE = 24;
const MAP = [...];
const SOLID = new Set(['#','=']);
```

Build tiles: array of {ch, solid}.

Player:
```js
const player = {x:0,y:0,w:16,h:24,vx:0,vy:0,onGround:false,face:1,anim:0};
const spawn = findTile('P');
```
Spawn: feet on the tile below spawn? Spawn tile 'P' is at row17 (y=408..432). Place player with bottom at (row+1)*24 = 432 => y=408. x center of tile: col*24 + 4 = 52. w=16.

Since spawn 'P' is an empty tile in collision terms.

Physics:
```js
function solidAt(col,row) { if out of bounds return true if row>=H? Actually boundaries solid. }
```
Out of bounds: x<0 or x>=W → solid; y<0 solid; y>=H → not solid? Bottom border row19 solid so y>=H shouldn't happen except water pit where hazard triggers. Treat y>=H as solid maybe.

Rect overlap solids: check tile range floor(x/T)..floor((x+w-1)/T).

Move:
```js
p.x += vx; resolve X; p.y += vy; resolve Y.
```
Resolve X: for each overlapped solid tile, if vx>0 set x = tileX*T - w; else x = (tileX+1)*T. Set vx=0.
Resolve Y: if vy>0, y = tileY*T - h; onGround=true; vy=0. else y=(tileY+1)*T; vy=0.

Jump: if onGround && jumpPressed (space) vy = -JUMP. To satisfy "jumping is allowed only while grounded", use onGround. Add jump pressed only on keydown, and require onGround at that moment. But onGround is updated each frame. Add small jump buffer (~6 frames) to make gameplay smoother; that arguably still requires having been grounded. I'd include buffer but only set buffer when onGround on press. That's fine — jumping is allowed only while grounded (during coyote? skip coyote to be strict). I'll add a tiny jump buffer: when pressing space while grounded, jump immediately. If pressed in air, no jump. Keep strict.

Variable jump height: release space cuts vy. Nice optional. Maybe implement to allow good control: if !spaceHeld && vy < -4 then vy = -4.

Hazards: for each tile overlapped by player rect, if 'W' or 'F' → lose. Also fire flame visual extends above tile but hazard is tile.

Trophy collect: trophy position animate. Rect around trophy tile; overlap → trophy=true, play effect, message "Trophy collected!". Keep tray HUD.

Exit: rect covering cols 36-37, rows 16-17? Actually door visual drawn 2 tiles wide starting at col36, rows15..18 (floor). Trigger rect x=36*24=864, width 48, y from row15 360 to ground 432. Player overlap. If trophy → win; else show message with cooldown 1.5s and maybe pulse exit red. Requirement: stays active. Add message "The exit is locked — grab the trophy first!" and exit glow red briefly.

Enemy update: vx = dir*1.2; check wall ahead (solid tile at front, at enemy mid height) and floor below ahead (if no solid, turn). Move and collide. Patrol across ground; if enemy reaches door non-solid and wall at col38? border col39 solid... enemy x max 39*24 - w. Fine.

Enemy-player collision → lose.

Loss state: mode='lost'. Player stops. Overlay. R restarts.

Win: mode='won'.

Restart button always visible; click restarts. R key restarts anytime.

HUD trophy indicator: DOM element "TROPHY: MISSING"/"COLLECTED" with icon. Also maybe draw on canvas. DOM simpler.

Message toast: draw on canvas for centralized visuals.

Game loop update only in playing mode; still draw animations (time) always.

Fire animation: using time. Draw flames on top of tile, hazard tile base.

Draw function details:

Background: fill dark gradient (#1b1226 → #2c1a2f). Add distant brick wall pattern with low alpha, maybe grid of bricks at top. Add vignette? Could use CSS/canvas radial gradient.

Draw all tiles:
- '#' solid brick: color palette by depth: draw base #5b3a2e with mortar #2a1a16, brick rows offset. Add top highlight #8a5d45 if tile above is empty.
- '=' platform: different: stone/metal: base #6f7a86 with top light #aab6c2, rivets.
- 'W': water: base dark blue, wave surface animated with sin, bubbles.
- 'F': fire: draw dark charred base + flames animated upward with circles/triangles using sine offsets.
- 'E': draw door: on tile grid draw at rows16-17 cols36-37: rectangle with wood/metal, round window, "EXIT" sign above. Draw once per tile? Better draw as one object using exit rect.

Actually mark E tiles but skip in tile draw except skip; then custom drawExit().

Trophy custom draw at tile center with bob.

Player draw: facing direction, walking animation via legs. Colors: cap red, face tan, shirt blue? Dangerous Dave: red cap/shirt, blue jeans. Draw.

Enemy: green/red blob with eyes and spikes, bob.

HUD text in DOM: controls: "← → / A D — Move · Space — Jump · R — Restart". Show always.

Win/lose overlay: canvas dark overlay + panel text: "LEVEL COMPLETE!" / "OUCH! YOU LOST" + "Press R or click Restart". Plus DOM button.

Let's code. Use requestAnimationFrame with dt accumulator fixed step 1/60 to make physics deterministic and jump calculations consistent.

```js
let last=performance.now(), acc=0;
function frame(t){
  let dt=Math.min(0.05,(t-last)/1000); last=t; acc+=dt;
  while(acc>=1/60){ update(); acc-=1/60; }
  draw(t/1000);
  requestAnimationFrame(frame);
}
```
update uses per-frame units (same as 60fps).

Camera static.

Responsive canvas CSS width min(96vw, 960px), aspect.

DPR: set canvas width=960*dpr, height=480*dpr, ctx.setTransform(dpr...). CSS width 960. But screenshot viewport 1200x800 → fits with HUD. Fine.

Let me write the file now.

Details for drawing bricks procedurally:

```js
function drawBrick(x,y,ch){
  // base
  ctx.fillStyle = '#5a352a'; ctx.fillRect(x,y,24,24);
  // bricks
  ctx.fillStyle='#6d4231';
  // two rows of bricks with offset
  ...
  // top edge highlight
}
```
Use deterministic noise via a hash of col,row for color variation.

Because tiles are 24px, brick pattern: row height 12, brick width 24 with offset 12. Draw mortar lines 1px.

Platforms '=': stone slabs: base #59606e, top #8f9aa9, dark bottom, rivets.

Water:
- base gradient? fill rect #123c5a; animated surface at tile top with sine wave, lighter #2f7fb5, foam.
- Only surface row (row 18 is surface, row 19 below). Draw wave only if tile above not water.
- bubbles: deterministic circles moving with time using sin.

Fire:
- hazard tile occupies row17 (bottom aligned with ground top 432? tile y=408..432). Draw charred dark base and flames rising into row16 area (above). Use animated flame polygons/circles with orange/yellow, additive-ish.

Trophy:
- cup: draw gold shapes, glow via radial gradient. bob sin(time*3)*3.

Exit:
- door frame: x=864, y=row15? Draw door 2 tiles wide and 3 tiles tall (rows 15-17, bottom at 432): x=864..912, y=360..432, 48x72. Arch top. Dark interior, glowing green outline, sign "EXIT" above at y~350. Arrow. When locked (no trophy), red glow.

Player rendering ~ 16x24: head 8x8, cap, body, legs animated. Add shadow.

Enemy: 20x22, rounded body with eyes, legs.

Particles on trophy pickup? optional simple sparkles. Won overlay.

Fonts: use system font stack. Canvas text uses 'bold 28px system-ui, sans-serif'. No external.

Water and fire hazard collision: check player's AABB overlap each hazard tile rect. For fire, maybe shrink rect a bit (x+4,w-8,y+8,h-8) so it feels fair. Water hazard full tile.

Also add kill when falling into pit (if p.y > 560).

Exit locked feedback: messageTimer; plus exitFlash timer to draw red.

Local state resets on restart.

Handle inputs: keydown ArrowLeft/ArrowRight/a/d set flags; space triggers jump if onGround (and mode playing). Prevent default for arrows/space. R restarts.

Touch controls? Not required but could add on-screen buttons? The requirement says keyboard. I'll add clickable on-screen buttons maybe for convenience—optional. Adding mobile buttons increases complexity; skip but maybe include simple buttons under canvas? Not needed. Display controls.

Let me write code.

For update order:
1. timers message
2. if mode !== playing return (but still trophy spin etc handled in draw).
3. horizontal input, friction.
4. gravity, cap vy.
5. move & collide.
6. hazard checks, trophy, exit, enemy, fall.
7. anim time.

The exit without trophy: if player overlaps and !trophy and messageCooldown<=0, set message + cooldown 2s. Ensure repeated contact doesn't spam. Also perhaps push player? Keep active; allow walking through.

Win sets mode='won' and maybe confetti.

Enemy collision uses rects with margin 2.

Write code now. Also add instructions overlay initially? Maybe a small hint drawn at start "Find the trophy, then reach the exit!" with fade. Not necessary.

Also requirement "Display the controls." DOM panel is good.

One more: "at least one patrolling enemy" — one enemy; maybe add a second on a platform? One is fine but two adds life. Add second enemy on P2 platform (row13 top? P2 at row14 top336, enemy spawn row13 col28). Patrol edge detection will keep it on platform (3 tiles wide). Enemy width 20, platform 72 px, patrol area tiny but works. Risk of uneven collision. Keep one enemy to reduce risk. Actually let's add a second enemy on the ground on left side? Player must get past. One is enough. Keep 1.

Let me write the HTML.

For sprite drawing, use ctx.save/translate/scale(face,1) etc. Careful.

Player draw:
```js
function drawPlayer(){
  const px=player.x, py=player.y;
  // shadow ellipse at feet
  // body
  const cx=px+8;
  const walk = player.onGround && Math.abs(player.vx)>0.1;
  const legPhase = Math.sin(player.animTime*12)*...
  // legs: two rects from y=py+16 to py+24, offset
  // shoes
  // torso overalls: rectangle 10x8 at py+8
  // arms
  // head circle radius 5 at py+5
  // cap: arc + brim facing
  // eye
}
```
Scale details with 16x24 box. Let's do:
- feet baseline y+24.
- legs: rect (cx-5 + swing, py+15, 4, 8) etc.
- body overalls: fill blue #2a5c9a rect (cx-6, py+8, 12, 9), straps, red shirt shoulders.
- head: skin #f0c090 circle r5 at (cx, py+5).
- cap red arc top and brim toward face.
- eye dark dot at cx + face*2.
- hands skin small circles at sides.

Good enough at 24px.

Enemy draw: body dark red/purple rounded, two white eyes with pupils, horns, little feet. Add bob.

Now write.

Enemy patrol initialization: spawn tile X at col28,row17. Set enemy x = col*24+2, y = row*24 + (24-22)=410, w=20,h=22, dir=-1. Patrol logic:

```js
function enemySolid(cx,cy){ tile solid at (cx,cy) }
e.x += e.dir*1.2;
collide with solids (resolve); if blocked -> e.dir*=-1
// ledge check: point ahead = e.x + (dir>0? e.w+2 : -2), foot y = e.y+e.h+2
if (!solidAtPoint(aheadX, e.y+e.h+2)) e.dir *= -1;
```
But floor below: solid at y=e.y+e.h+2 = 432+? e.y+e.h = 432 exactly, +2 = 434 inside floor row18 → solid, good. At water pit edge? not in patrol area.

When enemy blocked by wall (door is non-solid, but border col39 solid, so turns).

Reset on restart.

Hazard check uses tile overlap:
```js
function tilesOverlapping(rect, cb)...
```

Trophy rect: tile col34,row9 → x=816+? trophy drawn center x=34*24+12=828, y row9*24=216..240. Collect rect x=816,y=216,w=24,h=24 (maybe bigger 32).

Wait earlier P4 at cols33-35 row10 and trophy col34 row9. Player standing on P4 top y=240, player top=216, overlaps trophy tile row9 (216..240) fully. Good, collection immediate when standing there.

Exit trigger: x=864..912, y=row15(360)..432. Player on ground at x~864 will overlap. Door visual drawn at 864..912, y=360..432.

But wait: door located at cols36-37, and border col39 solid with col38 empty. Player can stand in front. Exit trigger needs player to walk into zone. Fine. Add small arrow above.

Trophy at x=816..840 (col34), P4 platform cols33-35 x=792..864. Door at x864..912 immediately right of platform; if player walks off P4 right edge at x864, they'd fall into door zone at ground quickly (fall 192px); they'd trigger exit while falling in door column with trophy. That's fine (win).

Check trophy isn't accidentally overlapped by exit zone: no.

Now the "exit locked" message if no trophy: player can reach exit easily on foot (running right along ground). Actually yes, door is at ground level right side, reachable without climbing. So they might hit exit early without trophy → message. Good demonstration.

Also fire at cols20,21 on ground blocks path, and enemy patrol, so early exit attempt requires passing hazards. Fine.

Make sure water pit + fire path is manageable.

One concern: player width 16, height 24, standing on floor. Fire tiles at row17 (y408..432). Player standing adjacent at ground overlaps row17 fully. Jumping over 2 tiles fire: 48px wide. Easy.

Frame-rate independent fixed step.

Let's write the code now.

Also, add "flash" red screen on loss and green on win? Overlay enough.

Confetti on win: draw simple particles using deterministic math based on time since win.

We'll need a global `time` in seconds updated in draw.

HUD updates: use DOM: trophy status and maybe a tip line. Update only on change.

Restart button id="restartBtn". Add click listener. Also key R.

Pointer/touch controls optional: I'll add small on-screen buttons for left/right/jump maybe not needed. Skip to keep time.

Let me write index.html now with careful JS.

Potential issue with solid resolution when player stands exactly on ground and vy=0: gravity each frame gives vy=0.5 then move down 0.5 overlaps tile → resolve to top, onGround=true. Fine.

Order: set onGround=false before Y move, then set on collision.

Jump: triggered via keydown handler if mode==='playing' && player.onGround → vy=-JUMP. But onGround might be stale if key pressed right after leaving ledge (strict). Fine.

Space keydown repeat: if held, repeated keydowns could trigger autojump when landing. That's acceptable? "jumping is allowed only while grounded" - auto-jump while holding is still grounded. But better disable repeat via e.repeat check.

Variable jump: on keyup space cut vy.

vx handling: acceleration for smoothness:
```js
let ax = (right?1:0)-(left?1:0);
if (ax) { player.vx += ax*0.6; clamp to ±3.6; face=ax }
else player.vx *= 0.75; if abs<0.05 →0
```
Air control slightly less: *0.5 accel. Fine.

Max fall speed 12.

Hazard detection each update after movement.

Enemy contact uses overlap.

Falling off screen: if y > 520 → lose "You fell!" (water triggers earlier).

Let me now write.

Draw ordering:
1. background
2. tiles (solids, water, fire bases)
3. exit door (behind player? draw after tiles)
4. trophy
5. enemy
6. player
7. particles
8. message toast
9. overlays for win/lose

Draw fire after player? Flames should appear in front maybe, but hazard collision independent. Draw fire before player so player visible. Draw flames slightly transparent.

Background details: parallax cave pillars, torches? Add two decorative torches on walls (non-hazard). Keep simple: dark gradient + faint large bricks + floating dust motes. Dust motes deterministic from time.

Now write code.

Let me be careful with template braces.

I'll write full file.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Dangerous Dave — Trophy Run</title>
<style> ... </style>
</head>
<body>
<div class="wrap">
  <header>
    <div class="title">DANGEROUS DAVE <span>· TROPHY RUN</span></div>
    <div class="hud">
      <div class="hud-item" id="trophyHud">🏆 <span>TROPHY: MISSING</span></div>
      <div class="controls">← → / A D move · SPACE jump</div>
      <button id="restartBtn">RESTART (R)</button>
    </div>
  </header>
  <div class="stage">
    <canvas id="game" width="960" height="480"></canvas>
  </div>
  <div class="tip">Collect the golden trophy, then reach the EXIT door. Avoid water, fire and the patrolling creature.</div>
</div>
<script> ... </script>
</body>
</html>
```

Use emoji trophy in HUD? Emoji rely on system font, no network—fine. But canvas drawn trophy is procedural. HUD text "TROPHY: MISSING" enough. Emoji might render inconsistently; use plain text square? Use "🏆" likely available. Keep maybe a small CSS shape. Simpler: "TROPHY: MISSING". The requirement says everything drawn procedurally—HUD text is fine but avoid emoji maybe. Use a small CSS-drawn trophy icon? Skip icon.

CSS dark theme with game frame, monospace-ish font: "Trebuchet MS", system-ui. Pixel feel via letter spacing.

Canvas crisp pixel art: ctx.imageSmoothingEnabled = false. We're drawing vector shapes at 960x480; using DPR 1 for pixel crispness? On screenshot 1200x800, canvas CSS width maybe 960. If DPR scaling, shapes sharper. Use dpr to keep crisp but shapes are smooth. Pixel style better with DPR 1 and CSS scaling? I'll set canvas backing store to 960x480 and CSS width 100% max 960 — can be slightly blurry if scaled. Use devicePixelRatio scaling: backing = 960*dpr, transform. Then drawings smooth. Fine.

Actually for screenshot, viewport 1200x800; header ~90px, canvas 960x480 fits vertically (480+~150=630). Good.

Let me now write the JS.

```js
(() => {
'use strict';
const TILE=24, COLS=40, ROWS=20, WIDTH=COLS*TILE, HEIGHT=ROWS*TILE;
const MAP = [...];
const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');
const dpr = Math.min(2, window.devicePixelRatio||1);
canvas.width = WIDTH*dpr; canvas.height = HEIGHT*dpr;
canvas.style.aspectRatio = '2 / 1';
ctx.setTransform(dpr,0,0,dpr,0,0);
```
Wait if canvas width attr changed, CSS width 100% => 960 CSS. Good. But setting canvas.width resets transform; then set transform.

Note: with fixed backing 960*dpr, max 2 → 1920x960. Fine.

Map chars. Grid helper:

```js
function tileAt(col,row){
  if(col<0||col>=COLS||row<0||row>=ROWS) return '#';
  return MAP[row][col];
}
function isSolid(char){ return char==='#'||char==='='; }
```

But E tiles are non-solid. Good.

Player init:
```js
const spawn = (()=>{ for y,x if 'T'? no, find P and X ... })();
```

Build entities:
```js
let player, trophy, enemy, door, state;
function resetGame(){
  const sp = findChar('P');
  player = { x: sp.col*TILE+(TILE-16)/2, y: (sp.row+1)*TILE-24, w:16,h:24,vx:0,vy:0,onGround:false,face:1,anim:0 };
  const en = findChar('X');
  enemy = { x: en.col*TILE+2, y:(en.row+1)*TILE-22, w:20,h:22, dir:-1, anim:0, alive:true };
  const tr = findChar('T');
  trophy = { x: tr.col*TILE, y: tr.row*TILE, w:24,h:24, collected:false };
  state = { mode:'playing', msg:'', msgTimer:0, exitLockTimer:0, winTime:0, loseTime:0, particles:[] };
  trophyHud...
}
```

Door rect computed from E tiles: find min/max E. Hardcode x=36*24, y=15*24, w=48,h=72.

Physics update:

```js
function updatePlayer(){
  const left = keys.left, right=keys.right;
  let ax = (right?1:0)-(left?1:0);
  if(ax!==0){ player.vx += ax*(player.onGround?0.85:0.6); player.face=ax; }
  const maxSpd=3.7;
  if(player.vx>maxSpd) player.vx=maxSpd;
  if(player.vx<-maxSpd) player.vx=-maxSpd;
  if(ax===0){
    player.vx *= player.onGround?0.7:0.94;
    if(Math.abs(player.vx)<0.08) player.vx=0;
  }
  // gravity
  player.vy += 0.52;
  if(player.vy>13) player.vy=13;
  if(!keys.jump && player.vy<-4) player.vy=-4; // variable jump
  moveAndCollide(player);
  if(Math.abs(player.vx)>0.2 && player.onGround) player.anim += 1; else player.anim += 0.15;
  if(player.onGround && Math.abs(player.vx)<0.2) player.anim += 0.15;
}
```

Hmm variable jump based on keys.jump: need key state. Space held → true. Jump on keydown.

Careful: `if(!keys.jump && player.vy<-4)` means the moment you press space and keydown handler hasn't set keys.jump yet? Handler order: keydown sets keys.jump=true then triggers jump. Ensure. In keydown: if code Space { keys.jump = true; if(!e.repeat) tryJump(); }. Keyup sets false. tryJump sets vy=-9.3 if onGround.

But then in the same frame update, keys.jump true, no cut. Good.

moveAndCollide:

```js
function moveAndCollide(p){
  p.x += p.vx;
  let tiles = getSolidTiles(p);
  for (const t of tiles) {
    if (p.x < t.x + TILE && p.x + p.w > t.x && p.y < t.y + TILE && p.y + p.h > t.y) {
      if (p.vx > 0) p.x = t.x - p.w;
      else if (p.vx < 0) p.x = t.x + TILE;
      p.vx = 0;
    }
  }
  p.onGround = false;
  p.y += p.vy;
  tiles = getSolidTiles(p);
  for (const t of tiles) {
    if (...) {
      if (p.vy > 0) { p.y = t.y - p.h; p.onGround = true; }
      else if (p.vy < 0) { p.y = t.y + TILE; }
      p.vy = 0;
    }
  }
}
```

getSolidTiles(p): loop cols floor(p.x/TILE)..floor((p.x+p.w-0.01)/TILE), rows floor(p.y/TILE)..floor((p.y+p.h-0.01)/TILE). Use 0.01 epsilon so touching exactly doesn't count. Only solid chars.

But collecting tiles after x movement uses updated y; fine.

Edge case: if p.x becomes negative, tileAt out of bounds = '#', but getSolidTiles only iterates in-bounds. Out of bounds should be treated solid. Since borders exist (col0, col39, row0, row19) player can't leave normally. Water pit bottom row19 is W non-solid; falling y > HEIGHT triggers fall lose. Row 0 solid, borders solid. Keep bounds check inside isSolidAt with out-of-range => true for x and y<0; y>=ROWS return false. Since bottom border row19 solid except water, fine.

Hazard detection:
```js
function hazardHit(p){
  const c0=Math.floor(p.x/TILE), c1=Math.floor((p.x+p.w-0.01)/TILE);
  const r0=Math.floor(p.y/TILE), r1=Math.floor((p.y+p.h-0.01)/TILE);
  for rows/cols: const ch=tileAt; if(ch==='W'||ch==='F'){
    // shrink rect for fairness
    const hx=c*TILE+(ch==='F'?4:0), hy=r*TILE+(ch==='F'?10:0), hw=TILE-(ch==='F'?8:0), hh=TILE-(ch==='F'?10:0);
    if (overlap) return true;
  }
  return false;
}
```
Fire hazard rect y from r*24+8 to bottom. Player standing adjacent on ground at row17: player occupies rows 17 (y 408..432). Fire tile also row17 y408..432, shrink to 416..432. Player bottom 432 overlaps. If player is on ground next to fire touching horizontally? Player x adjacent, no horizontal overlap unless entering tile. Good.

Water: full tile. Player falling in overlaps row18.

Trophy overlap: use circle-ish rect: trophy x+4..x+20, y+2..y+24.

Door trigger: x=864..912, y=348..432 (slightly above). Check rect overlap with player.

Enemy collide margin 3.

Update enemy:

```js
function updateEnemy(){
  const e=enemy;
  e.anim += 1;
  let nx = e.x + e.dir*1.25;
  e.x = nx;
  // wall collision
  const solidTiles = getSolidTiles(e);
  ...resolve horizontal; if resolved, e.dir *= -1
  // ledge check
  const aheadX = e.dir>0 ? e.x+e.w+1 : e.x-1;
  const footY = e.y+e.h+2;
  if(!solidAtPoint(aheadX, footY)){ e.dir *= -1; }
}
```
Careful: ledge check after moving; also ensure enemy stays on ground rows. Enemy y fixed since no gravity; ground at 432, e.y=410? row17 spawn: (17+1)*24-22 = 432-22=410. Feet at 432. Good. If it walks over the water pit? patrol won't go there.

Door zone non-solid ground? Ground below door is solid row18. Fine.

Enemy hits player check after enemy update.

Enemy patrol bounds by walls: door area empty and border at col39 → turns. Left it may wander to col22 then fire? Fire tile is non-solid! Enemy would walk into fire at cols20-21 and then over ground beyond. Enemy passing through fire is visually odd but acceptable; but should turn at fire? Better add patrol bounds manually: minX = 22*24, maxX = 35*24. Simpler: turn if x < 22*TILE or x+w > 35*TILE. Enemy spawn col28 x=674. Range x 528..840 (22..35). It can patrol under platforms. Good. Set dir=-1 initially.

Actually keep it on ground between fire and door. Fine.

Rendering functions:

drawBackground(time):
```js
const g = ctx.createLinearGradient(0,0,0,HEIGHT);
g.addColorStop(0,'#150f1e'); g.addColorStop(1,'#2a1726');
fill.
// faint large brick wall
ctx.globalAlpha=0.15;
for rows ... draw staggered rectangles color #5a3a52 stroke...
ctx.globalAlpha=1;
// dust motes
for i<30: x = (i*137 + time*(6+i%5)) % WIDTH; y = (i*83 + Math.sin(time+i)*... )
```
Keep cheap.

Bricks draw:

```js
function drawSolid(x,y,col,row){
  const h = hash(col,row);
  // mortar bg
  ctx.fillStyle='#2a1712'; fillRect
  ctx.fillStyle = ['#6b3f2c','#734631','#5f3828'][h%3];
  // bricks 12 high
  for (let by=0; by<2; by++){
    const off = ((row*2+by)%2)*12;
    for (let bx=-12; bx<24; bx+=24){ draw brick from x+bx+off ... } // clip
  }
  // simpler: two rows each one brick offset
}
```
Simplify: base fill with color; draw mortar lines: horizontal at y+11.5; vertical seams at x+ (row%2? 6 : 18) maybe. Use clip to tile:
```js
ctx.save(); ctx.beginPath(); ctx.rect(x,y,24,24); ctx.clip();
ctx.fillStyle = shade;
ctx.fillRect(x,y,24,24);
// mortar grid
ctx.strokeStyle='rgba(20,10,8,0.55)'; lineWidth=1;
for (let gy=y; gy<=y+24; gy+=12){ line }
seams offset per row of bricks based on tile row parity.
ctx.restore();
// top highlight if tile above empty
if (tileAt(col,row-1) not solid && MAP row-1 ch !== ...) fillStyle='#b07a55'; fillRect(x,y,24,3);
```
Platform '=':
```js
ctx.fillStyle='#4a505e'; fillRect
top slab: '#8b96a6' fillRect(x,y,24,4)
dark bottom
rivets: circles at corners
vertical grooves
```
Water: draw per tile:
- base: gradient from '#164a72' to '#0a2238'.
- If tile above is not water: draw animated surface: build path across x with sin waves (per 4px), fill lighter blue.
- foam highlights small white-ish arcs.
- bubbles rise: for k, y = tile bottom - ((time*20+k*17)%48) etc, draw circle alpha.

Because water occupies 2 rows, draw bubbles in both.

Fire: hazard tile row17. Draw charred base (dark) and flames drawn upward beyond tile:
```js
const t = time*10;
const baseY = y+TILE;
// ash
ctx.fillStyle='#241312'; fillRect(x,y+14,24,10);
for i<5 flames: cx = x+4+i*4; hgt = 16+sin(t+i*1.7)*6; draw gradient triangle-ish with bezier.
```
Flames should be visible above floor level. Draw with globalAlpha 0.95 and gradient fill orange→yellow. Use `ctx.beginPath()` flame shape curves.

Also draw ember glow radial.

Trophy:
```js
const bob = Math.sin(time*3)*3;
const cx=trophy.x+12, cy=trophy.y+12+bob;
glow radial gradient gold alpha.
// stem, cup body, handles, base
```
Cup body path: top ellipse, arcs.

Exit door:
```js
const x=864, w=48, baseY=432, top=360; // 72 high
// frame
ctx.fillStyle='#2f2118'; roundRect(x-4, top-4, w+8, 76)...
// arch: interior dark, green glow if trophy, red if locked
// bricks around? 
// sign "EXIT" above at y=344 with glow
// keyhole/handle
```
Draw sign with text and small arrow; text drawn with bold 12px monospace, centered. Add pulsing glow if trophy collected: green frame; else amber.

If message lock flash: red frame.

Player draw detailed as above. Also draw shadow ellipse below feet on ground? Optional: if ground within few px.

Enemy draw:
```js
const bob=Math.abs(Math.sin(e.anim*0.15))*2;
// body rounded rect dark red, spikes on top
// eyes white with pupils looking dir
// feet blobs alternating
```

Message toast:
```js
if(state.msgTimer>0 && state.msg){ draw panel centered at y=120 with text, alpha fade }
```
Message timer decrement in update. Draw even in won/lost? Only playing.

Overlay:
```js
if mode!=='playing': dark overlay rgba(0,0,0,0.6); panel; title; subtitle "Click Restart or press R".
```
Win title color gold; loss red. Also show trophy status.

Particles for trophy pickup: array of {x,y,vx,vy,life}. Update in update; draw. Confetti on win maybe reuse with time-based deterministic sparkles—skip complexity; draw animated radial sparkles behind overlay.

Input handling:

```js
const keys = {left:false,right:false,jump:false};
addEventListener('keydown', e=>{
  const k=e.key.toLowerCase();
  if(['arrowleft','arrowright','a','d',' '].includes(...)) e.preventDefault();
  if(k==='arrowleft'||k==='a') keys.left=true;
  if(k==='arrowright'||k==='d') keys.right=true;
  if(e.code==='Space'){ keys.jump=true; if(!e.repeat) tryJump(); }
  if(k==='r') restart();
});
```
Note e.key for space is ' '. Use e.code Space.

Keyup reset. Blur resets keys.

Restart button: addEventListener('click', restart). restart calls resetGame and updates HUD; if mode won/lost, also.

HUD update:
```js
function updateHud(){
  trophyHud.textContent = state.trophy... 
}
```
Trophy stored in trophy.collected and state.mode.

Ensure restart restores trophy missing and player/enemy positions.

Now verify jump feasibility. vJump=9.2, g=0.52. Max height = 9.2²/(2*0.52)=81.4px (3.39 tiles). Rise 48 possible at horizontal ~? t up to height 48: 0.26t² - 9.2t + 48=0 → t=(9.2±sqrt(84.64-49.92))/0.52 = (9.2±5.893)/0.52 → t2=29.0. Horizontal speed 3.7 → 107px. Good.

But with variable jump cut only when releasing space. If player taps space quickly, jump height reduced—fine.

P2→P3 jump: platforms diagonal adjacent. From standing on P2 top at col29 edge, P3 starts col30 at row12 (48 px above P2's surface? P2 row14 top=336; P3 row12 top=288, yes 48). Jump right and up. Need horizontal 24px while rising 48. Max horizontal at t=29 frames 107px, but must clear platform edge early? At t=6.5 (height 48 ascending) horizontal = 24px — exactly reaches col30 edge while at 48 height. Tight-ish but apex is 81 high, so overshoot: in reality player can jump, move right, and land on top because when above top (>=48 high) for a long window. Player rising above 48 between t=6.5 and t=28.9 during which horizontal from 24 to 107px. So they'll be above platform height and moving right between x+24 and x+107, landing on the platform top at some point. Fine.

P1 at row16 cols24-26 top=384; P2 row14 cols27-29 top=336. Similar.

But note: platforms are solid full block 24px thick. Jumping from P1 at col26 right edge toward P2 at col27, the side face of P2 (rows 14, from y336..360) is above player's standing surface 384; player jumping right will collide with P2's left side if not high enough. Player standing at 384 feet, head 360; P2's bottom is 360. When moving right into col27 while feet still below 360? Player head exactly at 360 while standing; moving right at ground level, they'd be blocked by P2's side? Wait P2 occupies x 648..720, y 336..360. Player standing on P1 at x up to 648, y=360..384, head 360. The tile P2 spans y336..360; player top at 360 exactly touches but not overlap (epsilon). Moving right at x=648.. into P2 column while y=360 → no vertical overlap (player y starts at 360, tile ends at 360). So they can walk under P2? Player's head grazes it. If player jumps even 1px, head goes above 360 → collides with P2 side and can't pass, must jump higher than platform underside (24px) to land on top. That's normal platforming: to get on top you must jump and move right after rising above the platform's top (336) — you'd need to clear 48px and be horizontally past x=648 before descending. But while rising at x<648, player's head passes P2's left side? The side collision only matters when horizontal overlap. Player can rise straight up at x=647 (no horizontal overlap), then move right at apex, landing on top. That works but feels a bit tricky with full-solid platforms.

To make climbing much more forgiving, make '=' platforms one-way (pass through from below, land on top). That's typical platformer. Implement one-way platforms: only collide in Y when moving down and previous bottom <= platform top. That significantly improves playability: jumping from P1 up through P2 and landing on top. Also stepping stone over water works.

Let's implement one-way platforms:
- '#' fully solid.
- '=' one-way: collide only when p.vy > 0 and previous bottom (p.y - p.vy + h?) Actually check crossing: prevBottom = p.y + p.h (before y move) ... after p.y += vy, if p.vy>0 and prevBottom <= tileTop + 0.01 and new bottom > tileTop, and horizontal overlap → land.

Also allow dropping through? Not needed.

But exit door drawn on ground; door non-solid fine.

One-way requires separate handling in moveAndCollide. Let's implement:

```js
function moveAndCollide(p){
  // X: only '#'
  p.x += p.vx;
  resolveAgainstSolidX(p);
  // Y
  const prevBottom = p.y + p.h;
  p.onGround=false;
  p.y += p.vy;
  // full solids
  for tiles '#': resolve y...
  // one-way '=' only when vy>=0 and prevBottom <= tileTop+1
  if(p.vy>=0){
    tiles '=': if horizontal overlap and prevBottom <= tileTop+0.5 and p.y+p.h >= tileTop and p.y+p.h <= tileTop+Math.max(8, p.vy+2) ... 
  }
}
```
Simplify: after y move, for '=' tile if p.vy > 0 && prevBottom <= tileTop + 0.01 && p.y + p.h > tileTop && p.x+p.w > tileX && p.x < tileX+TILE → land: p.y = tileTop - p.h; p.vy=0; onGround=true. But if p.y+p.h only slightly > tileTop, land. Since tile thickness 24, when falling fast could pass through if prevBottom above tileTop but new bottom beyond tileTop+24? With speeds ≤13 and tile thickness 24, new bottom can be at most tileTop+13 after crossing—still within tile. We only need crossing check. Good.

However if player jumps up through platform, prevBottom (above? below) — vy<0 skip. Then falling from above lands.

Edge: standing on platform, each frame gravity vy=0.52 → prevBottom ≈ tileTop (floating point 384 exactly) <= tileTop+0.01, new bottom 384.52 > tileTop → land. Good.

Also head bump only on '#', not '=' — great.

Water stepping stone at row16 = one-way. Fine.

Hazard fire on ground is at row17; player can jump over.

X collision only '#', so platforms don't block horizontal movement—only landing. Standard.

Now, a subtlety: when walking on a one-way platform and moving horizontally, there's no X collision with platform—walk off edge and fall, expected.

Solid floor '#' full.

Let's ensure player can't fall through the floor due to prevBottom check? Floor is '#', resolved.

Pit: player falls into water; hazard check triggers loss.

Now regarding ground platform edges collision resolution: fine.

Also door tiles E are non-solid.

Let me now think about win trigger and trophy: trophy at row9 col34 above platform row10. Player jumps onto P4? Wait climb: P1 row16 top384 → P2 row14 top336 (one-way, jump through) → P3 row12 top288 → P4 row10 top240 → trophy at row9 (216-240) standing on P4 player top = 240-24=216 → overlaps trophy tile 216-240 exactly. Collect.

Horizontal positions non-overlapping make the climb: P1 cols24-26 (x576-648), P2 cols27-29 (648-720), P3 cols30-32 (720-792), P4 cols33-35 (792-864). Each step up-right by 1 col: rise 48, horizontal 24. With one-way platforms, player at P1 right edge can jump up through P2 and land. Actually horizontal overlap: player at x=632 on P1; P2 starts x=648. Jump up and right; passes P2 from below (no collision), lands when descending if above x≥648 and feet at 336. But wait, if jumping up from P1 top 384 to 336 = 48; apex 81 → plenty. Good.

The stepping stone is one-way too.

Fire flames drawn on ground might overlap player visually when passing nearby—fine.

Now, exit without trophy while falling from platform potentially triggers multiple times; cooldown handles.

Also, add visible "locked" state on exit: door glows red and sign says "LOCKED"? Dynamic sign text: if trophy collected "EXIT →" green else "EXIT" amber with lock icon. Feedback message on contact.

Let's implement message with panel and timer decrement.

Now write out the file. I'll be systematic.

Also add startup hint toast: state.msg = "Collect the trophy, then reach the exit!" for 3.5s at start? Nice. But tests might see it; fine. Keep message toast.

Particles for trophy pickup: 14 golden circles flying. Update in update() for playing only; they still draw.

Win confetti: spawn particles at win via addConfetti? Could reuse particle array but update in draw. Let's draw deterministic sparkles based on winTime.

Simplify: on win spawn 60 particles with random velocities and gravity, update particles always in update function even when not playing? Let's have updateParticles() called every fixed step regardless of mode using mode-specific; restart clears. Win: create confetti. Loss: nothing.

Particles format {x,y,vx,vy,life,maxLife,color,size,grav}. Update each step: vy+=grav; x+=vx;y+=vy; life-=1.

Draw alpha life/maxLife.

Now render loop:

```js
function draw(timeSec){
  ctx.clearRect(0,0,WIDTH,HEIGHT);
  drawBackground(timeSec);
  drawTiles(timeSec);
  drawExit(timeSec);
  drawTrophy(timeSec);
  drawEnemy(timeSec);
  drawPlayer(timeSec);
  drawParticles();
  drawToast();
  drawOverlay(timeSec);
}
```

drawTiles: loop rows/cols:
- '#' → drawBrick
- '=' → drawPlatform
- 'W' → drawWaterTile
- 'F' → drawFire (may draw flames up)
- E skip.
Also decorative: maybe vines/moss on some bricks deterministic. skip.

drawWaterTile needs neighbors to determine surface (above not W). Water top row 18 y=432; water occupies to 480. Surface waves at tile top; the pit walls at sides are floor bricks.

Water surface should read clearly as water hazard. Add lighter wavy top + sparkles.

For the water tile at row18 (surface), draw wave; row19 beneath draw dark gradient and bubbles. Since canvas bottom is row20 = 480, water fills to bottom edge; fine.

drawFire flames from row17 y=408..432, rise into row16.

Player animation: legs swing when moving.

Let me also draw a subtle "YOU" marker? Not needed.

Enemy: draw body at (e.x, e.y) w20 h22.

Potential bug: Player death from enemy collision when enemy spawns overlapping player? No.

Implement restart accessible anytime and UI button. Also clicking canvas when game over restarts? Nice: canvas click restarts if mode!=="playing". Add listener.

Prevent space scrolling page.

Let me now produce final code.

One more: "Display the controls." Header shows keys. Good.

Also HUD line maybe show "Trophy: MISSING/COLLECTED". Update after collect.

Colors for trophy HUD: add class collected.

Let me write the file.

For text rendering, use font: `bold 13px "Courier New", monospace` for pixel vibe.

Implementation of roundRect: ctx.roundRect exists in modern browsers; safe but maybe fallback. Use custom helper for rounded rect to be safe.

Time to write.

Code outline:

```js
<script>
(() => {
'use strict';

const TILE=24, COLS=40, ROWS=20, W=COLS*TILE, H=ROWS*TILE;
const MAP = [ ... ];

const canvas = document.getElementById('game');
const ctx = canvas.getContext('2d');
const trophyHud = document.getElementById('trophyHud');
const restartBtn = document.getElementById('restartBtn');
const dpr = Math.min(2, window.devicePixelRatio || 1);
canvas.width = W*dpr; canvas.height = H*dpr;
ctx.setTransform(dpr,0,0,dpr,0,0);
ctx.imageSmoothingEnabled = true;

// ---------- helpers
function tileChar(c,r){
  if(c<0||c>=COLS||r<0||r>=ROWS) return (r>=ROWS)?'.':'#';
  return MAP[r][c];
}
function isSolidChar(ch){ return ch==='#'; }
function isPlatformChar(ch){ return ch==='='; }

function findChar(ch){
  for(let r=0;r<ROWS;r++) for(let c=0;c<COLS;c++) if(MAP[r][c]===ch) return {col:c,row:r};
  return null;
}

function overlap(a,b){
  return a.x < b.x+b.w && a.x+a.w > b.x && a.y < b.y+b.h && a.y+a.h > b.y;
}
function roundRect(x,y,w,h,r){ ... ctx.beginPath(); ... }
```

Note using ctx in roundRect directly.

Reset:

```js
const EXIT = { x:36*TILE, y:15*TILE, w:2*TILE, h:3*TILE };
```
Door visual height 72 from y=360 to 432.

state and entities as globals.

```js
function resetGame(){
  const sp=findChar('P'), en=findChar('X'), tp=findChar('T');
  player = {x:sp.col*TILE+4, y:(sp.row+1)*TILE-24, w:16, h:24, vx:0, vy:0, onGround:false, face:1, anim:0, alive:true};
  enemy = {x:en.col*TILE+2, y:(en.row+1)*TILE-22, w:20, h:22, dir:-1, anim:0};
  trophy = {x:tp.col*TILE, y:tp.row*TILE, w:TILE, h:TILE, collected:false};
  state = {mode:'playing', msg:'Collect the golden trophy, then reach the EXIT!', msgTimer:3.2, lockCd:0, particles:[], winT:0, loseT:0, shake:0, exitFlash:0};
  keys.left=keys.right=keys.jump=false;
  updateHud();
}
```

HUD update:
```js
trophyHud.textContent = trophy.collected ? 'TROPHY: COLLECTED' : 'TROPHY: MISSING';
trophyHud.classList.toggle('got', trophy.collected);
```

Jump: 
```js
function tryJump(){
  if(state.mode!=='playing') return;
  if(player.onGround){ player.vy=-9.2; player.onGround=false; }
}
```

Note: if space pressed at exact moment when onGround false due to previous frame, no jump. Fine.

Update:
```js
function update(){
  const t=1; // fixed
  if(state.msgTimer>0) state.msgTimer -= 1/60;
  if(state.lockCd>0) state.lockCd -= 1/60;
  if(state.exitFlash>0) state.exitFlash -= 1/60;
  updateParticles();
  if(state.mode!=='playing'){
    if(state.mode==='won') state.winT += 1/60;
    if(state.mode==='lost') state.loseT += 1/60;
    return;
  }
  updatePlayer();
  if(state.mode!=='playing') return;
  updateEnemy();
  checkCollisions();
}
```
Enemy collision check in checkCollisions.

checkCollisions:
```js
// hazards
if(hazardAt(player)){ lose('Burned / drowned'); return; }
// trophy
const tRect={x:trophy.x+4,y:trophy.y+2,w:16,h:20};
if(!trophy.collected && overlap(player,tRect)){ collectTrophy(); }
// exit
if(overlap(player, EXIT)){
  if(trophy.collected) win(); else if(state.lockCd<=0){ state.lockCd=2.2; state.msg='The exit is locked! Find the trophy first.'; state.msgTimer=2.2; state.exitFlash=0.5; }
}
// enemy
const er={x:enemy.x+3,y:enemy.y+3,w:enemy.w-6,h:enemy.h-6};
if(overlap(player,er)){ lose('The patroller got you!'); }
// fall
if(player.y>H+40){ lose('You fell into the depths!'); }
```
Note if player touches water at row18 while its bottom at row19? Hazard triggers first.

lose(reason):
```js
state.mode='lost'; state.loseT=0; state.msg=reason; state.msgTimer=0; player.vy=0; player.vx=0;
```
But msg toast only drawn in playing; overlay shows.

win():
```js
state.mode='won'; state.winT=0; trophy.collected stays; spawn confetti at exit.
```

collectTrophy: trophy.collected=true; updateHud; state.msg='Trophy collected! Now reach the EXIT.'; timer=2.4; spawn gold particles; also maybe flash.

updatePlayer as designed.

One-way platform landing implementation:

```js
function moveAndCollide(p){
  // horizontal
  p.x += p.vx;
  if(p.x<0) {p.x=0;p.vx=0;}
  if(p.x+p.w>W){p.x=W-p.w;p.vx=0;}
  const r0=Math.floor(p.y/TILE), r1=Math.floor((p.y+p.h-0.001)/TILE);
  const c0=Math.floor(p.x/TILE), c1=Math.floor((p.x+p.w-0.001)/TILE);
  for(let r=r0;r<=r1;r++) for(let c=c0;c<=c1;c++){
    if(tileChar(c,r)==='#' && overlapTile(p,c,r)){
      if(p.vx>0){p.x=c*TILE-p.w;}
      else if(p.vx<0){p.x=(c+1)*TILE;}
      p.vx=0;
    }
  }
```
Careful: after adjusting p.x inside loop, subsequent tile tests based on stale ranges. For a 16px wide player, at most 2 columns; could resolve against both and end wrong. Simpler loop recompute? Common approach: for each overlapped tile, resolve minimal. Since level has contiguous walls, resolving at most twice could double-shift. E.g., wall col 0 and open... Player can only overlap wall on one side. I'll break after first resolution per direction. Implement: gather collision then apply based on movement direction once.

```js
function moveAndCollide(p){
  // X
  p.x += p.vx;
  let hitX = null;
  const rows = range...
  outer: for ... if '#' and overlap -> hitX = {c,r}; break outer;
  if(hitX){
    if(p.vx>0) p.x = hitX.c*TILE - p.w;
    else if(p.vx<0) p.x = (hitX.c+1)*TILE;
    p.vx=0;
  }
```
If player is exactly on ground (y bottom 432) and moving horizontally, rows include row18 (floor) since bottom-0.001=431.999 => row floor(431.999/24)=17. So floor not included. Good (rows 0..17). Overlap with row7 etc fine.

X collision with tiles uses vertical overlap check per tile: p.y < ty+TILE && p.y+p.h > ty. Use strict; since p.y+p.h == ty means no overlap.

Then Y:
```js
  const prevBottom = p.y + p.h;
  p.y += p.vy;
  p.onGround=false;
  // full solids
  let hitY=null;
  for rows/cols if '#' and rect overlap -> hitY=...
  if(hitY){
    if(p.vy>0){p.y=hitY.r*TILE-p.h; p.onGround=true;}
    else if(p.vy<0){p.y=(hitY.r+1)*TILE;}
    p.vy=0;
  }
  // one-way platforms
  if(p.vy>=0 && !p.onGround){
    for rows/cols if '=':
      const top=r*TILE;
      if(p.x+p.w>c*TILE && p.x<c*TILE+TILE && prevBottom<=top+0.6 && p.y+p.h>=top){
        p.y=top-p.h; p.vy=0; p.onGround=true; break;
      }
  }
```
Careful: after normalizing vy=0 on ground, next frame prevBottom=432; platform landing only at top. Good.

But `p.y+p.h>=top` with prevBottom<=top+0.6 means when already standing (prevBottom==top), gravity moved down 0.5 → yes lands.

However, one-way check must not trigger when player jumps up from below: vy<0 skip. When falling and prevBottom was above top. Works.

Potential issue: after landing on a full solid, vy=0 so platform branch skipped due to condition p.vy>=0 (0 true) && !p.onGround false. fine.

Bounds: keep player clamped within canvas x; top via row0 solid. y can exceed.

Player face & anim:
```js
if(p.vx>0.1)p.face=1; else if(p.vx<-0.1)p.face=-1;
p.anim += Math.abs(p.vx)*0.12 + 0.02;
```
Walking frame based on anim... For drawing legs use sin(p.anim * 1.8) when |vx|>0.3 else idle breathing.

Let's define p.anim increment: if onGround && |vx|>0.3 → p.anim += 0.25; else p.anim += 0.08.

Walking cycle = sin(p.anim*2.2)? Actually just use p.anim as phase and compute sin(p.anim). Increment 0.25/frame gives full cycle 25 frames. Good.

Jump pose: if !onGround legs tuck.

Now enemy casts.

Drawing specifics let me write carefully.

Background:
```js
function drawBackground(t){
  const g=ctx.createLinearGradient(0,0,0,H);
  g.addColorStop(0,'#171021'); g.addColorStop(0.6,'#241329'); g.addColorStop(1,'#2c1524');
  ctx.fillStyle=g; ctx.fillRect(0,0,W,H);
  // distant masonry
  ctx.save(); ctx.globalAlpha=0.10; ctx.strokeStyle='#9c6b8a'; ctx.lineWidth=1;
  for(let y=24;y<H*0.72;y+=44){
    for(let x=-20;x<W;x+=64){
      const off=((y/44)|0)%2?32:0;
      ctx.strokeRect(x+off, y, 62, 42);
    }
  }
  ctx.restore();
  // dust motes
  for(let i=0;i<26;i++){
    const sx=(i*211)%W, sy=(i*137)%H;
    const x=(sx + Math.sin(t*0.3+i)*18 + t*(4+(i%4)))%(W+40)-20;
    const y=sy + Math.sin(t*0.7+i*2)*10;
    ctx.globalAlpha=0.18+0.12*Math.sin(t+i);
    ctx.fillStyle='#ffd9a0';
    ctx.beginPath(); ctx.arc(x,y,1.4,0,7); ctx.fill();
  }
  ctx.globalAlpha=1;
}
```
Dust motes behind everything; ok.

Brick:
```js
function drawBrick(c,r){
  const x=c*TILE,y=r*TILE;
  const v=((c*13+r*29)%7);
  ctx.fillStyle='#2b1a15'; ctx.fillRect(x,y,TILE,TILE);
  const base = v<2?'#6c4030':v<5?'#5e372a':'#744837';
  ctx.fillStyle=base;
  // bricks rows 2, 12 high
  for(let br=0;br<2;br++){
    const by=y+br*12;
    const offset=((r+br)%2===0)?0:8;
    for(let bx=-12;bx<24;bx+=24){
      const px=x+bx+offset;
      const x0=Math.max(px,x+1), x1=Math.min(px+22,x+TILE-1);
      if(x1>x0) ctx.fillRect(x0,by+1,x1-x0,10);
    }
  }
  // shading
  ctx.fillStyle='rgba(0,0,0,0.18)'; ctx.fillRect(x,y+TILE-3,TILE,3);
  if(!(r>0 && (tileChar(c,r-1)==='#'||tileChar(c,r-1)==='='))){
    ctx.fillStyle='rgba(255,190,130,0.28)'; ctx.fillRect(x,y,TILE,2);
  }
}
```
Wait when r>0 and above is empty we highlight; condition: if tile above not solid, highlight. tileChar above may be '#','=' etc. Use:
```js
const above=tileChar(c,r-1);
if(above!=='#'&&above!=='='){ highlight }
```
Note row0 top border has row -1 => returns '#' so no highlight.

Platform:
```js
function drawPlatform(c,r){
  const x=c*TILE,y=r*TILE;
  ctx.fillStyle='#3b4250'; ctx.fillRect(x,y,TILE,TILE);
  ctx.fillStyle='#6f7b8c'; ctx.fillRect(x,y,TILE,TILE-4);
  // top bevel
  ctx.fillStyle='#aeb9c7'; ctx.fillRect(x,y,TILE,3);
  // grooves
  ctx.fillStyle='rgba(0,0,0,0.25)';
  ctx.fillRect(x+1,y+10,TILE-2,2);
  // rivets
  ctx.fillStyle='#c9d3df';
  ctx.beginPath(); ctx.arc(x+4,y+7,1.5,0,7); ctx.arc(x+TILE-4,y+7,1.5,0,7); ctx.fill();
  // dark under
  ctx.fillStyle='rgba(0,0,0,0.35)'; ctx.fillRect(x,y+TILE-4,TILE,4);
}
```
Make platforms visually distinct from bricks (blue-gray metal).

Water:
```js
function drawWater(c,r,t){
  const x=c*TILE,y=r*TILE;
  const above = tileChar(c,r-1);
  const isSurface = above!=='W';
  const g=ctx.createLinearGradient(0,y,0,y+TILE);
  g.addColorStop(0,'#1d5f8c'); g.addColorStop(1,'#0a2c4a');
  ctx.fillStyle=g; ctx.fillRect(x,y,TILE,TILE);
  if(isSurface){
    // wavy top band
    ctx.fillStyle='#2f86bd';
    ctx.beginPath();
    ctx.moveTo(x,y+8);
    for(let i=0;i<=TILE;i+=4){
      const wy=y+6+Math.sin((x+i)*0.25 + t*2.5)*2.2;
      ctx.lineTo(x+i,wy);
    }
    ctx.lineTo(x+TILE,y+16); ctx.lineTo(x,y+16); ctx.closePath(); ctx.fill();
    // foam line
    ctx.strokeStyle='rgba(180,230,255,0.75)'; ctx.lineWidth=1.5;
    ctx.beginPath();
    for(let i=0;i<=TILE;i+=4){
      const wy=y+5+Math.sin((x+i)*0.25 + t*2.5)*2.2;
      i?ctx.lineTo(x+i,wy):ctx.moveTo(x+i,wy);
    }
    ctx.stroke();
  }
  // bubbles
  for(let k=0;k<2;k++){
    const bx=x+6+((c*7+k*11)%12);
    const by=y+TILE - ((t*22 + k*17 + c*5 + r*9)% (isSurface?22:46));
    if(by>y+2){
      ctx.globalAlpha=0.45;
      ctx.strokeStyle='#9ee4ff'; ctx.lineWidth=1;
      ctx.beginPath(); ctx.arc(bx,by,1.6,0,7); ctx.stroke();
      ctx.globalAlpha=1;
    }
  }
  // side shading
  ctx.fillStyle='rgba(0,0,0,0.15)'; ctx.fillRect(x,y,TILE,1);
}
```
Bubbles positions may draw over brick? inside tile clipped not needed if by within tile.

Fire:
```js
function drawFire(c,r,t){
  const x=c*TILE,y=r*TILE;
  // scorched base
  ctx.fillStyle='#2b1712'; ctx.fillRect(x,y+6,TILE,TILE-6);
  ctx.fillStyle='#3d1f14'; ctx.fillRect(x+2,y+16,TILE-4,TILE-16);
  // glow
  const glow=ctx.createRadialGradient(x+12,y+12,2,x+12,y+8,34);
  glow.addColorStop(0,'rgba(255,150,40,0.35)'); glow.addColorStop(1,'rgba(255,80,0,0)');
  ctx.fillStyle=glow; ctx.fillRect(x-20,y-28,TILE+40,TILE+36);
  // flames
  for(let i=0;i<4;i++){
    const fx=x+4+i*5.2;
    const hgt=14+Math.sin(t*9+i*1.7+c)*5 + (i%2?4:0);
    const sway=Math.sin(t*7+i*2.3)*2.2;
    const g=ctx.createLinearGradient(0,y+20,0,y+20-hgt-8);
    g.addColorStop(0,'#ffcf3a'); g.addColorStop(0.5,'#ff8c1a'); g.addColorStop(1,'rgba(255,60,0,0.1)');
    ctx.fillStyle=g;
    ctx.beginPath();
    ctx.moveTo(fx,y+22);
    ctx.quadraticCurveTo(fx-4, y+22-hgt*0.5, fx+sway, y+22-hgt-6);
    ctx.quadraticCurveTo(fx+4, y+22-hgt*0.45, fx+4.5,y+22);
    ctx.closePath(); ctx.fill();
  }
  // bright core
  ctx.fillStyle='rgba(255,240,190,'+(0.55+0.2*Math.sin(t*12))+')';
  ctx.beginPath(); ctx.ellipse(x+12,y+22,7,3,0,0,7); ctx.fill();
}
```
Note y+22 relative to tile: bottom near 432.

Fire tile at row17 y=408; flames up to ~y+22-20=410? That's within tile mostly. Wait y+22 - (14+6)=y+2. Flames rise only to top of tile, not above. To make visible flames rise above hazard tile, use base at y+TILE and height ~20-24 → tops at y+0 to y-4. Good: base y+22, height 20 means top y+2. Additional +8 extends to y-6. Fine. Draw fires maybe above ground floor visually; fire tile row17 top is 408, ground surface 432. Flames up to 402. Good.

Trophy:
```js
function drawTrophy(t){
  if(trophy.collected) return;
  const bob=Math.sin(t*3)*3;
  const cx=trophy.x+TILE/2, cy=trophy.y+TILE/2+bob;
  // glow
  const g=ctx.createRadialGradient(cx,cy,2,cx,cy,30);
  g.addColorStop(0,'rgba(255,225,120,0.55)'); g.addColorStop(1,'rgba(255,190,40,0)');
  ctx.fillStyle=g; ctx.beginPath(); ctx.arc(cx,cy,30,0,7); ctx.fill();
  // handles
  ctx.strokeStyle='#e8b427'; ctx.lineWidth=2;
  ctx.beginPath(); ctx.arc(cx-8,cy-3,5,-Math.PI*0.9,Math.PI*0.9,true); ctx.stroke();
  ctx.beginPath(); ctx.arc(cx+8,cy-3,5,Math.PI*0.1,Math.PI*1.9,false); ctx.stroke();
  // cup
  const grad=ctx.createLinearGradient(cx-9,0,cx+9,0);
  grad.addColorStop(0,'#b8860b'); grad.addColorStop(0.35,'#ffe066'); grad.addColorStop(0.6,'#ffd23f'); grad.addColorStop(1,'#a97708');
  ctx.fillStyle=grad;
  ctx.beginPath();
  ctx.moveTo(cx-9,cy-10);
  ctx.lineTo(cx+9,cy-10);
  ctx.quadraticCurveTo(cx+8,cy+4,cx,cy+6);
  ctx.quadraticCurveTo(cx-8,cy+4,cx-9,cy-10);
  ctx.closePath(); ctx.fill();
  // rim
  ctx.fillStyle='#fff3b0'; ctx.fillRect(cx-10,cy-11,20,3);
  // stem/base
  ctx.fillStyle='#c99a12'; ctx.fillRect(cx-2,cy+6,4,5);
  ctx.fillStyle='#e8b427'; ctx.fillRect(cx-7,cy+11,14,3);
  // sparkle
  const sp=0.5+0.5*Math.sin(t*6);
  ctx.fillStyle='rgba(255,255,220,'+sp+')';
  ctx.beginPath(); ctx.arc(cx+7,cy-7,1.6,0,7); ctx.fill();
}
```

Exit:
```js
function drawExit(t){
  const x=EXIT.x,y=EXIT.y,w=EXIT.w,h=EXIT.h;
  const unlocked=trophy.collected;
  const flash=state.exitFlash>0;
  const pulse=0.5+0.5*Math.sin(t*4);
  // outer frame
  ctx.fillStyle='#3a2418'; ctx.fillRect(x-5,y-6,w+10,h+6);
  ctx.fillStyle='#5a3826'; ctx.fillRect(x-3,y-3,w+6,h+3);
  // arch door
  const inner={x:x+3,y:y+6,w:w-6,h:h-6};
  ctx.save();
  ctx.beginPath();
  ctx.moveTo(inner.x, inner.y+inner.h);
  ctx.lineTo(inner.x, inner.y+18);
  ctx.quadraticCurveTo(inner.x, inner.y, inner.x+inner.w/2, inner.y);
  ctx.quadraticCurveTo(inner.x+inner.w, inner.y, inner.x+inner.w, inner.y+18);
  ctx.lineTo(inner.x+inner.w, inner.y+inner.h);
  ctx.closePath();
  ctx.fillStyle='#120d16'; ctx.fill();
  // glow color
  const c1=flash?'255,70,70':unlocked?'80,255,150':'255,190,70';
  const grd=ctx.createLinearGradient(0,inner.y,0,inner.y+inner.h);
  grd.addColorStop(0,'rgba('+c1+',0.05)');
  grd.addColorStop(1,'rgba('+c1+',0.35)');
  ctx.fillStyle=grd; ctx.fill();
  ctx.strokeStyle='rgba('+c1+','+(0.5+0.4*pulse)+')'; ctx.lineWidth=2; ctx.stroke();
  ctx.restore();
  // EXIT sign
  ctx.save();
  ctx.font='bold 11px "Courier New", monospace';
  ctx.textAlign='center'; ctx.textBaseline='middle';
  const label = flash ? 'LOCKED' : 'EXIT';
  const labelColor = flash ? '#ff8080' : unlocked ? '#7dffb0' : '#ffd166';
  const tw=ctx.measureText(label).width+12;
  ctx.fillStyle='rgba(0,0,0,0.7)'; ctx.fillRect(x+w/2-tw/2, y-22, tw, 15);
  ctx.strokeStyle=labelColor; ctx.lineWidth=1; ctx.strokeRect(x+w/2-tw/2,y-22,tw,15);
  ctx.fillStyle=labelColor; ctx.fillText(label, x+w/2, y-14);
  ctx.restore();
  // handle
  ctx.fillStyle='#e8c15a'; ctx.beginPath(); ctx.arc(x+w-12,y+h*0.58,2.5,0,7); ctx.fill();
  // arrow bouncing when unlocked
  if(unlocked){ ... }
}
```
Door y=360, h=72. Sign at y-22=338 above door. Good. But note P4 platform row10 y up high, no conflict.

Player draw with cap etc. Let me write:

```js
function drawPlayer(t){
  const p=player;
  const x=p.x, y=p.y, f=p.face;
  // shadow
  ctx.globalAlpha=0.28; ctx.fillStyle='#000';
  ctx.beginPath(); ctx.ellipse(x+p.w/2, y+p.h+2, 8, 3, 0,0,7); ctx.fill();
  ctx.globalAlpha=1;
  const moving = p.onGround && Math.abs(p.vx)>0.4;
  const phase = p.anim;
  const swing = moving ? Math.sin(phase*1.6)*3 : 0;
  const cx=x+p.w/2;
  ctx.save();
  ctx.translate(cx, y);
  ctx.scale(f,1);
  // legs (blue jeans)
  ctx.fillStyle='#2d4f8a';
  if(p.onGround){
    ctx.fillRect(-6, 15+Math.max(0,swing), 5, 8-Math.abs(swing)*0.3);
    ctx.fillRect(1, 15+Math.max(0,-swing), 5, 8-Math.abs(swing)*0.3);
  } else {
    ctx.fillRect(-6,15,5,7);
    ctx.fillRect(1,14,5,8);
  }
  // shoes
  ctx.fillStyle='#3b2a22';
  ctx.fillRect(-7,22+(moving?Math.max(0,swing):0), 7,3);
  ctx.fillRect(1,22+(moving?Math.max(0,-swing):0), 7,3);
  // torso shirt red
  ctx.fillStyle='#c0392b';
  ctx.fillRect(-7,8,14,9);
  // overalls blue
  ctx.fillStyle='#2f62ac';
  ctx.fillRect(-6,11,12,6);
  ctx.fillRect(-5,8,2,4);
  ctx.fillRect(3,8,2,4);
  // buttons
  ctx.fillStyle='#ffd166';
  ctx.beginPath(); ctx.arc(-4,11,1,0,7); ctx.arc(4,11,1,0,7); ctx.fill();
  // arms
  ctx.fillStyle='#f2c79b';
  if(!p.onGround){ ctx.fillRect(6,9,4,6); ctx.fillRect(-10,9,4,5); }
  else { ctx.fillRect(6,10,4,6+Math.sin(phase*1.6)*1.5); ctx.fillRect(-10,10,4,6-Math.sin(phase*1.6)*1.5); }
  // head
  ctx.fillStyle='#f6cfa4';
  ctx.beginPath(); ctx.arc(1,5,5.6,0,7); ctx.fill();
  // ear
  ctx.fillStyle='#e0b184'; ctx.beginPath(); ctx.arc(-4,6,1.6,0,7); ctx.fill();
  // cap red
  ctx.fillStyle='#d93b2b';
  ctx.beginPath(); ctx.arc(1,3.2,5.4,Math.PI,0); ctx.fill();
  ctx.fillRect(-5,1.6,13,2.2); // brim
  ctx.fillStyle='#a8271c'; ctx.fillRect(1,2.2,9,1.6);
  // face
  ctx.fillStyle='#22150f';
  ctx.beginPath(); ctx.arc(4,5.5,1.2,0,7); ctx.fill(); // eye toward facing
  ctx.fillStyle='#b5523b'; ctx.fillRect(2.5,9.2,3,1); // mouth? maybe skip
  // mustache?
  ctx.fillStyle='#5b3522'; ctx.fillRect(2,7.4,5,1.4);
  ctx.restore();
}
```
Careful: ctx.scale(f,1) flips; drawn shapes relative ok. Eye positioned at positive x is toward facing direction.

Height 24: head top ~ -2? head center y=5 r5.6 → top -0.6 slightly above; cap arc up to -2.2. Player box y..y+24; sprite slightly above top by 2px—fine visually.

Legs feet at y+25 > 24 slightly; shadow; acceptable. Adjust to fit: legs from 15 to 23, shoes 21-24. Let me tune: legs y 15..23 (8), shoes y 21..24. Head top -1. Fine.

Enemy:
```js
function drawEnemy(t){
  const e=enemy;
  const bob=Math.sin(e.anim*0.18)*1.6;
  const x=e.x,y=e.y+bob;
  // shadow
  ctx.globalAlpha=0.3; ctx.fillStyle='#000';
  ctx.beginPath(); ctx.ellipse(e.x+e.w/2, 432, 10, 3,0,0,7); ctx.fill();
  ctx.globalAlpha=1;
  // feet
  ctx.fillStyle='#5b1c3b';
  const step=Math.sin(e.anim*0.32)*2;
  ctx.beginPath(); ctx.ellipse(x+4+step, y+21, 4,2.4,0,0,7); ctx.fill();
  ctx.beginPath(); ctx.ellipse(x+16-step, y+21, 4,2.4,0,0,7); ctx.fill();
  // body
  const g=ctx.createRadialGradient(x+7,y+7,2,x+10,y+10,16);
  g.addColorStop(0,'#c0392b'); g.addColorStop(1,'#7a1f4f');
  ctx.fillStyle=g;
  ctx.beginPath();
  ctx.moveTo(x+2,y+20);
  ctx.quadraticCurveTo(x-1,y+8,x+5,y+5);
  // spikes
  ...
}
```
Simplify body: ellipse center (x+10,y+11) rx10 ry11, plus 3 spikes triangles on top.

Eyes white two circles at y+8, pupils shifted by dir.

Let me write straightforward.

Particles:
```js
function updateParticles(){
  for(let i=state.particles.length-1;i>=0;i--){
    const p=state.particles[i];
    p.x+=p.vx; p.y+=p.vy; p.vy+=p.grav; p.vx*=0.99; p.life--;
    if(p.life<=0) state.particles.splice(i,1);
  }
}
function spawnBurst(x,y,color,n){
  for(let i=0;i<n;i++){
    const a=Math.random()*Math.PI*2, s=1+Math.random()*2.6;
    state.particles.push({x,y,vx:Math.cos(a)*s,vy:Math.sin(a)*s-1,grav:0.08,life:30+Math.random()*20,max:50,color,size:1.5+Math.random()*2});
  }
}
```
Math.random okay.

drawParticles: alpha = life/max.

Toast:
```js
if(state.msgTimer>0 && state.msg && state.mode==='playing'){
  const a=Math.min(1,state.msgTimer*2);
  ctx.globalAlpha=...; panel centered y=96 ...
}
```
Use measureText for width.

Overlay:
```js
if(state.mode!=='playing'){
  ctx.fillStyle='rgba(8,4,12,0.65)'; fillRect
  panel 480x200 centered
  title 'LEVEL COMPLETE!' / 'GAME OVER'
  subtitle: won ? 'You claimed the trophy and escaped!' : state.msg
  'Press R or click RESTART'
  draw trophy icon? maybe.
}
```
Animate panel scale with ease? Keep simple.

Also drawing win confetti: spawned on win.

Now, start game and loop.

Timing:
```js
let last=performance.now(), accum=0;
function frame(now){
  const dt=Math.min(0.05,(now-last)/1000); last=now;
  accum+=dt;
  let steps=0;
  while(accum>=1/60 && steps<4){ update(); accum-=1/60; steps++; }
  draw(now/1000);
  requestAnimationFrame(frame);
}
```
If paused/tab hidden dt clamp.

Note state may be reset; draw uses state.

Trophy HUD adds class 'got'.

Also keydown listener should ignore typing? no inputs.

If R pressed while holding... restart. Also restart button click then keys cleared.

Potential issue: restart while key space held—keys cleared; fine.

Let me also prevent context menu? not needed.

Test checklist after write: initial render, move right, jump, land on platform, collect trophy maybe via debug teleport? I can simulate keys via browser tool? Browser tool supports key/drag/click, no direct JS eval maybe inspect DOM only. I can use a temporary debug hook on window (e.g., window.__game = {player,state...}) to test via... browser tool has no eval. I could add URL hash debug? Hmm.

Simplest verification: use browser click/key actions and screenshots. To verify trophy/exit, could add keyboard shortcut? Better to use window-level debug API and a query param? Browser tool can navigate? It says run index.html, inspect, interact. No eval capability listed. I can verify movement/jump/restart manually via keys and screenshots. For win/lose states, I could expose functions to window and use inspect? inspect probably dumps DOM/console, not eval.

I could temporarily modify code to auto-run test scenarios (e.g., URL hash '#test-win' triggers simulated win) then remove. Or use console via page? No eval. Alternative: write a separate test harness Node script that extracts game logic? Overkill.

Practical: use key interactions. The route: start at x=52. Moving right: enemy and hazards are far. Trophy route requires sustained platforming—hard via scripted keys but possible with many key holds using tool? Each key press likely single keydown/keyup, not hold. The tool's key action may support holding? Unclear.

Better: temporarily expose debug helpers bound to keys (e.g., number keys 1,2,3 to teleport to trophy/exit) and test, then remove. Or keep debug keys hidden? Not needed.

I can test state transitions by injecting via a temporary separate HTML copy? But final verification should be on index.html. I can add debug code temporarily then remove and reload—fine.

Plan:
1. Write index.html.
2. Reload, screenshot initial.
3. Use key presses: Right (may be held briefly), Space for jump; screenshot.
4. Inspect console for errors.
5. Temporarily add debug keys/teleports? Instead, I can call internal functions by making them window-exposed and use browser? No eval.

Alternative: use a query-string-driven automated test in the final file that's harmless (e.g., ?debug). Could keep a tiny debug teleport via keys T/Y? That may be seen as extra but harmless. Better to remove before final.

Let me include a temporary `window.__DEBUG__` with methods and use... still need eval.

Hmm, maybe the browser tool's "key" action can press keys, and holding via repeated key? Let me check tool behavior after writing. Since browser tool likely Playwright behind scenes, keydown/keyup per call. Movement uses key state, so a single press/release gives a tiny nudge. Still enough to see motion.

For state transitions, easiest is to add temporary keyboard shortcuts:
- '1': teleport to trophy platform (set player near trophy) → collect then walk to exit? Hard.
- '2': win directly (collect trophy + move to exit), '3': lose.
Then remove after testing. Or keep debug features behind Ctrl+Shift? I'd rather test via temporary code and remove.

Actually I can expose window functions and then use browser inspect? inspect likely returns DOM and console logs—not arbitrary eval. Could make the game log state to console; inspect shows console. To trigger, I can use temporary auto-test via URL hash: the tool reloads index.html fixed path, maybe can't set URL. So use keyboard shortcuts.

I'll add temporary shortcuts (F2/F3/F4) at the end, test, then remove and re-check basic.

Let's write the file now.

HUD styles: 
- body background #0d0813 with radial gradient.
- .wrap max-width 1000px margin auto padding.
- header flex wrap.
- title font bold, letter-spacing, gold.
- canvas display block width 100%, border 3px solid #6b4a2f, border-radius 6px, box-shadow.
- controls chips.
- Restart button styled orange.

Ensure canvas fits 800 height: header ~70 + canvas 480 + tip 30 = 600.

Add pixelated? Set image-rendering: auto.

Write now.

Now run in browser. First inspect and screenshot.

The initial render looks good. Player at left, water, fire, enemy, platforms, trophy, exit visible.

Now test movement and jump. Use key actions. The key tool likely presses and releases. Let's try holding via repeated presses? First test right movement with a few presses, and jump.

But note player stands at y ~? We can inspect via console if we add logging, but inspect returns console logs only. We have window.__game.debug but no eval. However, I can use keyboard presses and screenshots.

Let's press ArrowRight several times and Space, then screenshot.

Actually the initial toast is shown. Need to check movement: press ArrowRight maybe 20 times? Each press/release might nudge slightly. Better: I could use `browser` key with text? Key action requires text maybe "ArrowRight". Let's try.

Player appears to have moved slightly right (from x~162 to x~165 maybe). The key press is momentary. The enemy moved position too (patrol working). Need a way to hold keys for movement tests. Perhaps the browser tool's `key` accepts text like "ArrowRight" and holds only briefly. Could use repeated presses quickly via multiple tool calls; each nudge small.

Alternatively, use debug hooks and add keyboard-based debug? I can add a debug query/key and then use browser keys. For example, press "T" to teleport player onto stepping stone / platform, then test landing.

But I also need to test hitting arrow keys cause sustained movement. The tool likely sends keydown then keyup after ~50ms; enough for ~3 frames of acceleration → small movement. Screenshot shows player moved ~2px? Hard to tell.

Let me compare coordinates via pixel image? Better: add a debug overlay text showing player position? Could add in DOM? Not desired final. But we can use console logs and inspect via console array. Console empty now.

I can temporarily expose state on document.title? Or add an always-visible debug readout? Not final.

Alternative: Use browser `type`? no.

Let me add temporary key shortcuts (1,2,3) plus a debug HUD div updated with player x,y,onGround that I can see in inspect DOM text, then remove after verification.

Actually simpler: temporary console.log periodically? inspect console would show output. Add a debug interval logging JSON every 500ms; inspect then shows console entries. Then keyboard-driven movement can be measured.

But keys are momentary, so movement accumulates a bit each press. I can press 30 times to move significantly and observe logs. Each call maybe 50ms of held key → ~3 frames × accel... vx builds to max quickly (~5 frames), moving ~3.7*3=11px per press. 30 presses ~330px, reaching water/fire. That could test.

Let's add temporary debug: set an interval to console.log state and expose keys? We can also programmatically simulate key holds by dispatching events—but no eval. However, we can make the game respond to keyboard keys for debug.

Plan verification approach:
- Add a temporary? Instead of editing the final file, I can create a separate test HTML that loads the game? Not easy.

I'll temporarily add to index.html:
```js
// DEBUG
setInterval(()=>console.log('DBG', JSON.stringify({x:player.x,y:player.y,onGround:player.onGround,mode:state.mode,trophy:trophy.collected,ex:enemy.x})),400);
```
And maybe keyboard shortcuts: 'k' teleport near trophy? But teleport onto trophy platform using coordinates. Actually jumping onto platforms manually through key presses is hard. I'll add debug keys temporarily:
- '1' → place player on stepping stone (x=14*24+4,y=16*24-24) to test landing.
- '2' → place player just left of trophy (x=33*24+4, y=10*24-24), then press Right to collect (or check auto-collect when overlapping).
- '3' → teleport player to exit without trophy to test lock feedback.
- '4' → teleport to exit with trophy (collect + move) to test win.
- '5' → teleport onto fire/water to test loss.

Use console logs to observe mode changes. Then remove debug code and do final sanity screenshot + restart.

Let me add temporary debug at end of script, plus a periodic log. Also add a debug HUD showing state values in the DOM? Console log is enough with inspect.

Let me patch temp code.

Now inspect console after 500ms.

Good: player onGround true at spawn; enemy patrol moving (637.8 → 600.3). Hmm enemy moving left, passes over? Enemy minX = 528. It will turn at 528.

Now test movement: press ArrowRight many times and see x increase. Let's do 10 presses and inspect.

Interesting: player x stayed at 52 despite 5 ArrowRight presses. Maybe the key tool sends to page but focus? The player hasn't moved. Perhaps key tool's key events aren't waking the game because e.key isn't 'ArrowRight'? Or maybe screenshot happens immediately before frame updates after keyup, so player returns? No, x doesn't revert.

Wait the console shows latest enemy x updated to 682, so time is passing. Player x 52 unchanged. Maybe the browser tool's key action sends text as literal "ArrowRight" typed? It might dispatch type events rather than keydown for named keys? The earlier first ArrowRight maybe no movement either. Screenshot initial and after look identical.

Possibly the page lacks focus — click canvas first then send keys. Let's click canvas center then press key. But clicking canvas while playing does nothing (only restarts when not playing), fine.

Let me click at player? Click anywhere, then key.

Enemy reached 807.8 then turned back (or patrol cap at 35*24=840 minus w 20 → 820; it turned at 807.8+? hmm e.x+w > 840 triggers; 807.8+20=827.8 not >840. Next step 809. etc. Maybe turn at 840). Fine.

Keys still not affecting player. Maybe the browser tool's keyboard events go to the browser chrome not the page, or the key action doesn't accept ArrowRight. Let me try typing via browser "type" text? The type action may type into focused element. Keydown listener on window should catch.

Maybe the game loop's player movement does work but the key tool press is too quick (keydown and keyup in same frame with no update in between). Physics: keydown sets keys.right=true; keyup sets false. If no animation frame between, no movement. Likely.

To test through the tool, I need longer key hold. Perhaps the key action supports a "text" like "ArrowRight" but doesn't hold. Could dispatch many presses but each call executes quickly; if no rAF between them, no movement. Hmm.

I could add a temporary auto-move test mode that simulates presses internally: expose debug keys to start scripted input. For verification, add keypress '7' → set keys.right=true for 60 frames then false; '8' → jump + hold right. That verifies physics really works.

Since I can't hold keys, modify temp debug to add scripted tests:
- '7': simulate walking right for 90 frames (set an array of timed input events).
- '8': from current pos, jump.
- '9': teleport to water etc.

Actually simpler: since we have debug hooks, schedule via setTimeout keys.right=true; setTimeout(...false) e.g., 700ms. This tests movement/jump using the real input flags and physics.

But to simulate keyboard jump, call tryJump(). This verifies physics, though not key binding itself. Key binding straightforward.

Also, maybe the tool's key output "Frame 1 +0ms" implies each call renders 1 frame? Hmm. "Frame 1, +0ms" maybe screenshot frame index. Whatever.

Let me add temp debug keys:
- '7': keys.right = true; then setTimeout(()=>keys.right=false, 800).
- '8': tryJump() plus same right hold (for platform test).
- '9': run scripted platform climb? Hard.

For verification tests:
1. walking + jump over ground: teleport near col17? We'll test at start: key '7' walk right 800ms from x=52 → ~x 250, no hazards. Then '8' jump while walking and observe y change and return to ground.
2. Landing on stepping stone: teleport player to x≈300,y? then walk right and jump onto stone at col14 (x336..384, top384). Could script: teleport to x=290 (col12), keys.right=true, jump at right moment. Timing: from standstill accelerate; easier: teleport to just left of stone x=320, y=408 (feet 432), then jump + right hold; after 500ms check landing: onGround with y=360 (on platform top 384 -24=360).
3. Collect trophy: key '2' teleports to platform, should collect automatically; check trophy=true.
4. Exit locked: teleport to door without trophy, verify mode playing and message.
5. Win: collect then exit → mode won.
6. Enemy loss: teleport onto enemy's current x → lost.
7. Water loss / fire loss: teleport into tile.
8. Restart: call resetGame via R or button; verify player x 52, trophy missing, enemy reset, mode playing.

I can do most with debug teleports + physics, checking console. Restart via key 'r' actual binding (the key tool might work for 'r' since handler runs immediately on keydown). Let's test later.

Add to temp debug:
```js
window.addEventListener('keydown', e=>{
 if(e.key==='7'){ keys.right=true; setTimeout(()=>{keys.right=false;},800); }
 if(e.key==='8'){ keys.right=true; tryJump(); setTimeout(()=>{keys.right=false;},800); }
 if(e.key==='9'){ player.x=320; player.y=408; player.vx=player.vy=0; keys.right=true; setTimeout(()=>{tryJump();},120); setTimeout(()=>{keys.right=false;},900); }
});
```
Test 9 lands on stepping stone.

Note debug keydown listener added after game listener; order fine.

Let me patch.

Now press '7' and wait, then inspect. Use key "7".

Player still at x=52. The key '7' event apparently reached the page? Console sampled x=52. Maybe the debug keydown handler didn't run because the browser sends key '7' with e.key='7'? Should have. But maybe keys.right didn't persist long enough? It logged at 3 sample points over 1.5s; tx unchanged. Hmm.

Maybe the `key` action doesn't dispatch events at all to the page (just sends to browser). The DOM console shows enemy moving (time). Perhaps we need focus via clicking page then key. We clicked at (500,400), should focus. Maybe the tool requires keydown names like "Key7"? Let's try clicking the restart button with browser click to at least test DOM button and key R.

Let's click Restart button at approx x=1040,y=128? Canvas viewport screenshot is 1200x800, header at y 128, button x≈1040. Click it and check maybe HUD reset (trophy already missing). Better test R key via tool.

Alternatively, use browser "type" action to type "7"? Focus on body. Let me try `type` with text "7".

Hmm, the game could be running in an iframe not focused? Click at (500,400) should focus.

Maybe the tool dispatches keyboard events only when the target is the page but our events reach? We saw no movement from ArrowRight key earlier.

Let me test clicking the Restart button (DOM click event) to see if tool interactions work. Also check if key events produce any effect: add temporary onscreen debug by drawing key flags? Could write to document.title and inspect? inspect DOM doesn't show title.

Better: make the debug DBG log include keys.right and add log on each debug keydown: console.log('KEY', e.key). Then trigger key and inspect. The console shows logs; if no 'KEY' entry, key events aren't reaching page.

Add logging to debug keydown handler. Also log restart button click.

Let me patch quickly.

Now try key "7" and inspect console.

Key events do reach page (KEY 7 logged). But player x remains 52, meaning the timeout that starts keys.right=true and executes physics did not move? Wait, the console sampling may be lagging: the last log after KEY 7 might have been sampled before 900ms elapsed, but earlier DBG showed x=52 across 5 samples. The key press happened at the end; no DBG after it yet.

Actually maybe the game is paused in background? Enemy changed between samples, so no.

Hold on: The player may be stuck because keys.right set true only in debug handler after game keydown handler... should move. Unless update loop stops when tab not focused? Enemy moves.

Let me wait a second and inspect again for new DBG.

Also note the DBG samples show enemy at 529.8 then 567.3 (turned). Fine.

Let me call screenshot after some time.

Movement works: x 52 → 253.9, stopped because timeout at 900ms. Ground stayed true. Player near water edge? x=253.9, water starts 312, so fine.

Now test jump. First test jump at spawn or current pos with '8' (right+jump). Current x=253.9. Press 8 and inspect y changes.

Now player is airborne (y changed? screenshot shows feet above floor). Need the DBG samples after key 8. Wait a moment then inspect/screenshot.

The jump + forward move went into the water (x=314.6 crosses into col13 water at 312) → loss works, hazard detection works. So jump physics works (y went 408 → 396.6 airborne, then moved right into water). Loss state overlay works nicely.

But I intended to land on stepping stone. Fine—this verifies hazard and loss. However, dying there highlights that jumping near start can easily fall into water; that's expected.

Now test restart via R key. Press 'r' and inspect. Also trophy state etc reset.

Restart works: player back at start, trophy missing, level reset, message shown, game playing. Enemy reset (visible near right).

Now test stepping stone landing with debug key 9. Press 9 and inspect.

Note: debug key 9 sets x=320 (col13.33), y=408, then right+jump after 100ms. Water starts at x=312; the player initially teleported onto the edge of water tile? Player x=320..336 lies over water col13 (312-336). At y=408..432, water row18 begins y=432, so standing at floor level - not overlapping water. But no floor there; with jump delayed 100ms, gravity drops player ~5px, still above water top? Feet at 432+; after 100ms falling: 0.5*0.52*(6)^2 ≈ 9px → feet at 441 → overlaps water → loss before jump. Bad test.

Change key 9: start at x=290 (col12, on solid floor, feet 432), jump immediately with right, then land on stepping stone at 336..408 (cols14-16) top 384. Horizontal distance from 290 to stone left edge 336 = 46px; jump reaches easily. Need to ensure not overshoot entire platform? right held 900ms → after landing may run off into water on the right side (stone cols14-16 ends 408, ground resumes 432). Holding right 900ms from x=290: jump duration ~36 frames=600ms at speed 3.7 → travels ~133px to x≈423, past stone (408) into gap? Then falls into water at col17 (408-432). Hmm. Better hold right only 500ms and jump at start. Horizontal: at t=500ms (30 frames), travel ~100px at max speed (with acceleration), x≈390, on stone (336-408). Stop right, land on stone. Let's modify key 9 accordingly: x=290, y=408; jump immediately; keys.right=true; timeout 500ms → false.

Actually jump from x=290 moving right: platform stone top=384 (48px above). Player rising, passes above stone when height>48 at t≈6.5 frames (x≈~300). At 30 frames x≈390, descending/landing? Airtime 36 frames; landing on platform happens when feet return to 384 at t≈29 frames, x≈~380. Good. Stop right at 500ms (~30 frames).

Let me patch key 9.

Also test obstacle jumps across water? The required check only needs jump near start and land on a nearby solid surface. The stepping stone test covers it nicely.

Patch and reload then press 9.

The player is at x~? Screenshot shows player near col13, at y ~580 (above ground level a bit, mid-jump). Let's wait for landing and inspect.

The player jumped but landed into water — x=343 at loss means he moved right too fast and overshot the stone? Wait platform stone is x=336..408 (cols14-16), top y=384. Player at x=343 mid-air y=410 descending, should land on stone (feet at 434 > 384). It seems the one-way platform didn't catch him! Why? Let's check the one-way logic.

In moveAndCollide, after vertical collision:
- rA = floor(p.y / TILE), rB = floor((p.y+p.h-0.001)/TILE)
- loop r from rA-1 to rB, c cA..cB looking for '='.
At the frame when crossing the platform: previous bottom <= top+0.6, new bottom >= top.

The player was at y=391.8 at sample; feet 415.8, platform top 384 — feet already below top (415 > 384) while descending. So he crossed top earlier. At the crossing frame, prevBottom <=384.6 and new bottom >=384; the check should have caught. Unless his x wasn't over the platform at that moment? At sample x=302.6, y=391.8 feet=415.8 — that's before the stone starts (x=336) and feet below platform top. He already passed the platform height while x<336. So when he reached x≥336, he was already below the platform top → no landing. He jumped too early relative to horizontal distance / or too slow horizontal. Actually jump from x=290, stone starts at 336: at t when height 48 (6.5 frames), x≈300, so at x<336. He then descends below 48 height before reaching x=336. That means jump height/time is not enough at that horizontal speed... but airtime 36 frames and he reached stone at ~16 frames? Let's compute speed: he started at 290, by sample x=302.6 at ~500ms? Hmm sample times every 500ms; hard to know.

Actually acceleration 0.85/frame from 0, max 3.7. At 30 frames, avg maybe 3.4 → 102px → x=392. So he should be over stone at ~14 frames (x=336), with height at t=14: y displacement = 9.2*14 - 0.26*196 = 128.8-51=77.8px above start — well above platform. Then descends, landing at 36 frames when x≈390. That would land on stone. But the DBG sample shows "lost tx 343.3 ty 410.7" — maybe water touched exactly when x=343 while descending... Wait y=410.7 feet=434.7 = water level; so he reached x=343 only at the end of jump, meaning horizontal movement was slower: about 53px over full airtime. Why? Because the key handler's `keys.right=true` plus `tryJump()` maybe occurred, but the game also may have had leftover keys from previous test? No.

Wait—timing issue: `keys.right = true; tryJump();` both immediate. Then setTimeout 500ms sets false mid-air. If horizontal speed reached max 3.7, distance by 500ms ≈ 3.7*(30 - accel ramp ~4) ≈ 96px → x=386. But he was x=343 at landing (~600ms). Something reduced movement: maybe he jumped, landed on stone briefly, then ran off? No, mode lost at y=410.7 (feet 434.7) in water, x=343 (over water cols 13-17 from 312-432!). Wait x=343 is over water because tile cols 13..17 = x312..432. The stone is at row16 cols14..16 => y=384 top. If he landed on stone, he'd be y=360. He never landed.

Why so slow horizontally? Let me reconsider: maybe he hit his head on... no ceiling. Hmm, x at 302.6 in first DBG after 500ms? The DBG interval is 500ms; the sample right after key 9 (<500ms) showed 302.6. That means within maybe 100-200ms he was at 302.6 and y=391.8 (height 16px). At that time, rising? y 391.8 is 16px above start. Then at next sample 500ms later he's lost. So he died early! At x=343.3, y feet 434.7. That suggests he fell into water soon after, not a full jump. 

Why did he fall early? Possibly `tryJump()` was called, but immediately the debug key handler sets keys.right, then... Hmm mode lost state freezes at collision. y=410.7 = 23px above ground start, feet 434.7. Water hazard rect is row18 y=432..456 full tile. Overlap when feet >432. So he fell just 3px into water and died.

Maybe jump never happened? If vy remained 0 (tryJump failed because onGround false?). In key handler I set player.y=408 and tryJump(); player was grounded from previous state → onGround true → vy=-9.2. Unless onGround was false at moment due to... reset? At reload, player onGround true after first physics frame. Should work.

But screenshot after key 9 showed the player visibly above the ground at x~430? In the attached image, player at x≈416 CSS (canvas offset 104 + x*... wait canvas displayed 1004px wide for 960 internal, scale 1.046). Player visual center ~ 417 → internal x ≈ (417-104)/1.046 ≈ 299. So x≈299, y visual ~ 577 vs ground top 604; player above ground ~27px → mid-jump. So jump happened.

Then next sample 500ms later: lost at x=343. So horizontal travel only ~44px over ~600ms → average 1.4 px/frame. Why so slow? Maybe `keys.right` was cleared almost immediately because the previous setTimeout from test '7'/'8' fired? No, reload reset all. Hmm, the game's keydown handler also runs for key '9' — no effect. The debug handler sets keys.right=true then a 500ms timeout. Unless... the `keyup` from the tool for "9" arrives and keys handler doesn't touch right.

Wait: maybe the player collided horizontally with the water? No, water isn't solid.

Could the player be blocked by the platform side? Platforms aren't solid. Hmm.

Actually look at jump: he starts at x=290, and after jump, key right acceleration is 0.6/frame in air; reaches 3.7 in ~6 frames. Fine.

Unless update loop is at ~20fps in the headless browser? Enemy speed is 1.25 px/frame at 60fps fixed step; DBG enemy changed 637.8→600.3 → 37.5px per 500ms = 75px/s; at 1.25 px/frame => 60fps. So loops fine.

Then why is player horizontal slow? Maybe because right was released at 500ms and lost happened right at 500ms — so from key press to death only 500ms. In 500ms = 30 frames: jump airtime should be 36 frames, so player still airborne. x distance ≈ 90px expected, but actual 53px (290→343). Hmm 1.77 px/frame average. Given acceleration 0.6/frame to max 3.7, reaching max in 6 frames gives 100px. Something limits speed.

Oh! The variable jump cut: `if (!keys.jump && player.vy < -4) player.vy = -4;` — keys.jump is false because we called tryJump() directly without setting keys.jump! So each frame vy is clamped to -4, reducing jump height (still enough ~?) and airtime, causing early landing. That explains short jump: vy cut to -4 immediately, max height 4²/(2*0.52)=15.4px, airtime ~15 frames = 250ms. Then falling into water quickly. Indeed y=391.8 is ~16px above start, consistent with capped jump.

So my debug jump helper is flawed (didn't set keys.jump). Real keyboard jump sets keys.jump=true before tryJump, so it's fine. To make debug correct, set keys.jump=true too and release after e.g. 300ms.

Also, gameplay-wise, the jump-cut logic with keys.jump is standard. But note: if the player taps space quickly (press/release within a frame), jump gets cut to -4, producing a very small hop. That's typical variable jump, but might feel bad if tool sends quick taps. Real users hold space. Fine, but perhaps make the cut less drastic: `if (!keys.jump && player.vy < -4.5) player.vy = -4.5;` and minimum height 20px. Actually with vy=-4.5, height ~19.5px < tile 24, so couldn't jump onto 48px platform on tap. Holding required, fine. But to be friendlier, cut at -5.5 (height 29px). Let's set cut to -5 for a minimum hop of 24px. Hmm.

The required verification "jump near the starting area and land on a nearby solid surface" — there's no nearby raised surface except floor. Fine.

Fix debug key 9 to set keys.jump=true and release after 250ms, and test landing.

Also I realize the level's stepping stone requires holding jump—fine.

Let's patch debug 9 (and maybe 8) to include keys.jump and release. Then test again.

The player is jumping; screenshot shows him above stone? Wait stone at cols14-16 = x336..432 internal; canvas offset x≈104 + x*1.046. Player internal x≈300 → screen 418. Stone screen x≈451..553. Player left of stone. Need to wait for completion.

Excellent! Player landed on the stepping stone: x=399.8, y=360 (platform top 384 - 24 = 360), onGround true. Movement, jump, landing on platform, one-way collision all verified.

Now test trophy collection (key 2 teleports to P4 platform standing at y=360? teleport x=33*24+4=796, y=10*24-24=216). Wait P4 row10 cols33-35; top y=240; player y should be 216 from teleport. Trophy tile col34 row9 center x=828, y=216..240. Player at x=796..812 — not overlapping trophy x=820..836 (trophy rect x+4=820). Hmm key 2 places x=33*24+4=796, so player right edge 812 < 820. Need walk right a bit or teleport x=34*24+4=820. Use key 2 then press 7 to walk right briefly? Or adjust debug key 2 to x=34*24+4. Let me just press '2' then 7 (walk right up to 900ms) — but may run off platform to right after collecting; fine (falls to ground near door, but without hazard). Actually collect happens immediately when overlapping. Let's adjust key 2 for direct overlap: x=34*24+4=820, y=216. Patch.

Then trophy collected via overlap check in update. Test exit locked first? Order:
- Restart via r.
- Press 3 teleport into door without trophy → message locked, mode playing. Screenshot/inspect.
- Press 2 (trophy) → collected.
- Then walk to door: teleport 3? That puts at y=360 (inside door zone), with trophy → win.

Patch key 2 coordinate.

Test locked exit: press 3.

Locked feedback works: toast "The exit is locked! Find the golden trophy first.", door label "LOCKED" red, level still active.

Now test trophy pickup: press 2 and inspect.

Player is standing on the trophy platform next to trophy but trophy not collected yet (trophy=false right after teleport). Trophy rect x+4..x+20 = 820..836; player at x=820..836 — overlapping exactly? Player x=820, width 16 → 820..836. Trophy x = 34*24=816, rect 820..836. Overlap horizontally full. Vertically trophy y=216..240, rect y+2=218..238; player y=216..240 → overlaps. So collection should trigger next update. The DBG last sample is right after key. Wait more. Also note the toast still shows old "locked" message because trophy collection hasn't happened yet.

Take screenshot after a bit.

Interesting: player is at x=820,y=216 standing on the platform but trophy is not collected. Looking at screenshot, the trophy is on the left side of the player (trophy x=816... player at 820). Wait visual shows trophy left of player; horizontal overlap should be full? Player at 820..836; trophy drawn cx=828 (center at 828). Player x=820..836, so player centered on trophy, covering it. The trophy drawn behind player. Yet trophy.collected false.

Why? The collision check happens in update after updatePlayer/updateEnemy. Trophy rect: {x: trophy.x + 4, y: trophy.y + 2, w: 16, h: 20} = x=820, y=218, w=16,h=20 → 820..836, 218..238. Player y=216..240, x=820..836. overlap() requires a.x < b.x+b.w (820<836 true) && a.x+a.w > b.x (836>820 true) && a.y < b.y+b.h (216<238 true) && a.y+a.h > b.y (240>218 true). True. Should collect.

But wait—update returns early if state.mode != playing. It's playing. Hmm.

Wait, maybe debug key 2's y=216 places player exactly on platform; but moveAndCollide corrects y to 360? No, y=216 sample persists.

Why no collection? Could it be that the trophy update code is after enemy update and before exit, fine.

Hold on: did key '2' also trigger keydown in game's first handler? No.

Maybe the trophy coordinates aren't where I think: findChar('T') finds row9 col33? Let me recount MAP row9: "#................................T.....#". After '#', 32 dots? Let me count precisely. Earlier generation placed trophy at col33? The script set g[9][33]='T'... wait output row9 from generator: "#................................T.....#" — count: position 0 '#', dots 1..32 (32 dots) → T at 33. Yes trophy.x=33*24=792, not 816! I mis-indexed. The platform row10 was cols 32..34 (not 33..35). Earlier generator set platform g[10][32..34] and trophy g[9][33]. Then I said move P4 to cols33-35 but never actually regenerated! I only edited the map? Let me check the map rows in the file. The MAP I wrote at the top was the generated output with trophy at col33 and platform cols32-34, NOT shifted. Right—the map array in the file is from the first generator output (trophy col33 row9, platform row10 col32-34).

So trophy.x = 792, rect 796..812; player at 820..836 → no overlap. That's why not collected. The visual shows trophy at cx=804, player at ~828, slightly right of trophy—matches.

The route is still fine: P4 spans 768..840, trophy above at 792..816; climbing from P3 row12 cols30-32 (720..792). Wait P4 row10 cols32-34 overlaps P3 col32 at x768-792. One-way platforms avoid head bump issues, and standing on P3 at col32 feet=288, head=264; P4 above at row10 occupies y240..264, top 240; head exactly at 264 touching the underside? One-way platform doesn't block vertical upward movement, so jumping through works. Landing on P4 by moving right through it works. Good. But when standing on P3 at col32 directly under P4, fine (no collision). The trophy platform is at row10 cols32-34.

The player teleported to x=820 was right of trophy. So collection logic likely fine. Let me press ArrowRight? No, need move left. Debug key 2 should teleport to trophy x. Change key 2 to x=33*24+4=796, y=216 — wait earlier I had that and changed from 33 to 34. Revert to x=33*24+4=796, y=10*24-24=216. Then rects: player 796..812, trophy rect 796..812 → overlap. Good.

Alternatively walk left with debug script. Simpler patch key 2 back to 33.

Also note: exit defined at 36*24.. and platforms near. Fine.

Let me patch and reload, then test collect + exit win.

Great initial view clearly shows player, trophy (gold cup), exit door, water, fire, enemy, platforms. Note the trophy platform seems at row10 cols32-34, trophy above center (col33).

Now press 2 to collect, inspect.

Trophy collected: HUD green "TROPHY: COLLECTED", toast, exit turns green with arrow. Player standing on P4 at trophy position.

Now win: press 3 (teleport to door) — mode should become won since trophy collected.

Win state works with overlay.

Now test restart via the actual button click (DOM). Click button at ~ (1041,128). Then verify state reset in console (trophy false, x 52). This tests Restart button.

Then test enemy loss: after restart, use debug key 6 (teleport onto enemy patrol) while mode playing; wait; mode lost. Also fire hazard loss maybe test key 5 (teleport into fire) — should be lost. Requirement both fire and water hazards cause loss; water already verified via scripted jump. Fire test key 5.

Let's click Restart button.

Restart button works: state playing, trophy missing, player at start, enemy reset to x=637.8. Message reset.

Now test fire hazard loss: press 5 (teleport onto fire at x=20*24+4=484, y=408). Fire is at cols20,21 => x480..528. Player at 484..500 within fire tile. Instantly should be lost.

Player teleported into fire but screenshot shows him alive standing amidst flames; mode? Console last sample before KEY 5. Need wait then inspect. Fire hazard rect is shrunk: x+4..x+20, y+9..y+24 (i.e., 417..432). Player standing y=408..432 → overlaps. Should lose next update. Let me inspect now.

Fire loss verified (GAME OVER, "You touched a deadly hazard!").

Now test enemy loss: restart, then key 6 teleports onto enemy's approximate position. Enemy patrols; key 6 sets x=28*24=672,y=408. Enemy currently around 556 after loss? After restart enemy resets to 637.8 and moves; teleport into it at 672 maybe not immediate. Instead, key 6 once after restart and wait; enemy may come to player (it patrols 528..840) and collide. Player standing at 672 will overlap when enemy passes. Since enemy collision check runs every frame, once enemy reaches x near 672 ± it's a collision → lost. That verifies enemy contact naturally! Let's do restart then 6 and wait ~2s.

Also need to check "restart during play" (R key) — already did R from loss, but also during play. The button worked from win. Good enough.

Then remove all debug code, final reload and quick movement test via actual keyboard? Actual key taps are too short; we already verified in-engine. Final screenshot after removing debug.

One thing to consider: the real keyboard movement requires holding key; verified via keys flags which is what real keydown sets. Key binding handler sets flags correctly (we saw 'KEY 7' log; arrows would work). Good.

Let's do enemy test.

Now press 6 to stand in enemy patrol path, wait for collision.

Player teleported to x=672, enemy at 581 nearby moving right toward player. Wait for enemy collision.

The enemy turned around at x=551 before reaching the player at 672 — why? It was moving right (544→551→588.5→...). It should keep going. Maybe it hit the fire? Fire isn't solid. Wait it moved from 544 to 551 (turn?) then to 588.5 moving right; player at 672. Need more time. Enemy speed 1.25/frame; 83px away = 66 frames ≈ 1.1s. The console samples stop at 588.5. Wait for another second.

Actually enemy x went 544→551, then 588.5, fine, moving right toward player. Let's wait and inspect again.

Enemy collision loss verified.

Now the full route reachability: I verified stepping stone, and the platform ladder positions. But I should verify the climb sequence P1→P2→P3→P4 works with the actual physics. P1 row16 cols24-26 (x576..648 top384), P2 row14 cols27-29 (648..720 top336), P3 row12 cols30-32 (720..792 top288), P4 row10 cols32-34 (768..840 top240). P4 overlaps P3 at col32 but one-way so fine.

The ascent is from ground. Jump from ground (432) onto P1 (384): 48 rise — verified same geometry as stepping stone. P1→P2 adjacent diagonal similar. P2→P3 similar. P3→P4: P4 is above at row10, starts col32 where P3 ends col32. From P3 top288 at x~780, jump right onto P4 top240. 48 rise, same. Should be fine. I can test the route programmatically with debug scripted motions? A full route is tough but the geometry is uniform and same as verified jump. Maybe verify one mid-level jump, e.g., teleport to P2 (x=27*24+4=652? y=14*24-24=312) then run+jump right to P3. But that's extra; the identical vertical spacing means okay.

However, I want to ensure the climb route is reachable starting from ground: P1 is at row16 top384 directly above the ground between cols24-26. Player approaching from left at ground: jumping onto P1 requires rise 48 and horizontal. The screenshot shows P1 at cols24-26 above ground near fire; player can jump from ground before/after. Fine.

One issue: trophy platform row10 cols32-34, the trophy at col33 row9. The player must collect trophy while on P4. Verified via teleport at 796 standing on P4 and overlap works. Good.

Another issue: after collecting, the exit is reached by dropping from P4 to ground at x~816 near door x864. Door zone begins 864. Fine.

Now check the requirement "Restart restores the level, trophy, enemies, and player position." Verified: trophy false, player x52, enemy x657.8 (post-reset first DBG shows 657.8 because reset enemy 674? Wait reset enemy x = col28*24+2 = 674, then first DBG after reload shows 637.8 because 500ms elapsed). After restart DBG shows 657.8, consistent with reset then movement. Good.

Now remove all temporary debug code and interval. Also remove window.__game if desired (it was temp). Then reload, screenshot, verify no console errors, and maybe test actual movement once more after removal using keys? Actual key taps don't produce motion due to no hold; can't verify physically, but code is unchanged from verified. Could test restart button after removal.

Also fix one thing: the `studentShake` leftover variable (weird name) used nowhere else. Clean up: remove `studentShake` lines. Harmless but tidy.

Also, jump height: with real keyboard, keys.jump stays true while held, full jump works. Good.

Potential issue: keyboard Space triggers jump on keydown; if the user holds space, no auto-repeat jump due to e.repeat check. Good.

Potential issue: The game displays controls; yes.

Check route physically reachable once more considering one-way platform collision and the walls. All platforms are one-way, ground is solid. Ascent P1 placed above ground: P1 at row16 cols24-26; jumping from ground beneath P1 passes through, lands on top. Good. But wait—jumping directly beneath P1 from the ground, the player would pass through and land on top? One-way platforms only catch when falling from above, so yes: rising through, then falling back onto it. That's fine and makes reaching it trivial.

However, there's a subtle exploit/problem: the player standing under a one-way platform can jump through and land on top even if the jump doesn't clear 48px? They need to get above the platform top (48px rise) which requires >48; max 81. Fine.

Fire at cols20-21 on ground: player must jump over; fire is 48px wide, jump range 130px, easy.

Water pit is 120px wide with stone platform at cols14-16 top384. Jump from ground col12 (x~300) to stone works (verified landing at x=399.8). From stone to ground col18, easy.

All good.

Now cleanup debug. Remove the entire temp block after requestAnimationFrame(frame); including window.__game, debug keydown listener, interval. Also remove studentShake lines.

Let me view the tail of the file to edit exactly.

Clean build renders with no console errors. Now do final checks after debug removal:
1. Click restart button to ensure still works.
2. Maybe simulate actual key holds? Can't. But keyboard handler changes untouched.

Potential issue found in final screenshot: the enemy appears at x≈805 (screen), which is near the door; it patrols 528..840. Fine. Note enemy patrol route passes through fire? Fire at cols20-21 x480-528, patrol min 528, so no.

One more thought: The enemy's patrol bottom is ground; it passes under the P1 platform; fine.

Also the exit is drawn over bricks at x864..912; doesn't overlap platform P4 (x768..840). Good.

Final verification of the "controls displayed" — header shows them.

Let me test restart button click once more and check no console errors. Also take a screenshot after to ensure reset.

Restart button works in clean build and restores initial state. No console errors.

One thing left unverified: actual keyboard-held movement/jump (via real Space/Arrow keys) — the browser tool can't hold keys, but the debug scripts exercised the same input flags and physics. Keydown handlers for ArrowRight/Space are standard; I saw 'KEY 9' logs earlier only after adding logging. The main game handler sets flags correctly.

Wait: one concern about jump via real Space — `keydown` handler calls tryJump() after setting keys.jump=true. If player is grounded, works. Verified logic.

One potential UX bug: in the `keydown` handler, pressing 'r' also triggers reset but `keys.left/right/jump` are reset inside resetGame — good.

Another check: clicking canvas during play does nothing; after win/lose restarts via click. Good.

The final file has one artifact: in win screen, `state.winT` unused except increment; harmless.

Final check: file exists at /tmp/job-rPV04p/index.html and no debug remains. grep TEMP etc.

Also validate that all map rows are 40 chars; already generated. Let me confirm quickly with node and check file size.

All clean. Final report.

Summarize what I checked:
- Initial render + console clean.
- Movement (scripted input through same key-state code): x 52→253.9, grounded.
- Jump + land on stepping stone platform at y=360, onGround true.
- Water hazard → loss.
- Fire hazard → loss.
- Enemy collision → loss ("The patrolling creature caught you!").
- Trophy collection via overlap → HUD changes, exit unlocks.
- Exit without trophy → "locked" toast, red LOCKED sign, stays playing.
- Exit with trophy → win overlay.
- Restart button + R during play/after loss/after win → resets player, trophy, enemy, mode.

Unverified: actual long keyboard holds via browser tool (tool can't hold), full manual playthrough start-to-finish of platform ladder (geometry checked and each jump type verified, uniform spacing), touch/mobile.

Could mention the level layout route. Keep concise.