Dangerous Dave platformer · qwen3.8-flash

Let me start by exploring the working directory and then build the game.

Let me plan the design:

- Canvas tile-based platformer, Dangerous Dave style: tiled levels, treasure collectibles, keys/doors, enemies (killing-bot style patrolling), hazards (lava/water), exit door, score/lives HUD.
- Requirement: solid platforms, trophy, exit, fire and water hazards, at least one patrolling enemy. Draw everything procedurally.
- Controls: Left/Right or A/D to move, Space to jump. Display the controls.
- Gravity, landing, solid-wall collision; jump only while grounded.
- Trophy required before exit. Reaching exit without it gives visible feedback (message "You need the trophy!") and keeps level active.
- Touching hazard or enemy → loss state. Reaching exit with trophy → win.
- Restart after outcome and during play (R key + button). Restart restores level, trophy, enemies, player position.
- Keep route physically reachable.

Let me design tile map. Tile size 24 or 32. Canvas maybe 800x600 with camera scrolling. Let's keep it a single screen-ish level but wide with camera.

Tile chars:
- `.` empty
- `#` solid brick
- `=` stone/solid platform
- `^` fire hazard
- `~` water hazard
- `T` trophy
- `E` exit (door)
- `P` player spawn
- `g` gem/coin (bonus, optional — Dave style collectibles)
- `k` key, `K` locked door? Might be extra complexity. Keep optional but nice. Requirements don't require keys. I could add a couple of gems for flavor but must not make route require them. Let's add gems for score (Dave-like treasure) — simple.
- `B` enemy spawn (patrolling bot)

Physics: gravity 0.5, jump velocity -11, move accel, max speed ~4. Tile size 32: jump height with v=-11, g=0.5 → h = v²/(2g) = 121/1 = 121 px ≈ 3.8 tiles. Good, so gaps must be ≤ ~4 tiles of jump height, horizontal reach: airtime ~ 2*11/0.5 = 44 frames, at 4px/frame → 176px = 5.5 tiles. Keep gaps ≤ 4 tiles to be safe.

Let me carefully author a level grid. I'll design with rows of strings. Let's do a level 60 tiles wide x 19 tall (19*32 = 608 tall; canvas 608? Let's do canvas 960x608 with camera). Actually let's do tile 32, view 30x19 tiles = 960x608. Level width 70 tiles.

Designing a grid by hand is error-prone; I'll write it as ASCII art with careful counting, then verify with a script that: each row same length, jump reachability of main path, etc. Let me design in segments.

Let me use a simpler approach: build level as string array with fixed width, drawn in a monospace editor-like fashion. I'll write the map then run a node script to check row lengths and simulate a solver? A quick check: verify key platforms reachable.

Let me lay out the level (W=70, H=19). Row 0 top.

Let me think of the layout:
- Ground floor at row 17 (solid), floor row 18 solid? Let's make row 18 solid bedrock across, row 17 mostly solid with hazards embedded (fire pits, water pools). Player walks on row 17's top surface = y=17*32=544.

Hmm, if hazards are embedded in the ground row, the player walking along ground would fall into them. Better: make ground solid with pits containing water/fire, requiring jumps across.

Plan of sections:
1. Start area (x 2-8): flat ground, player at tile (3,16) standing on ground row 17.
2. Small step up: platforms rows 14-15, a gem.
3. Fire pit at ground x=12..14 → jump over (3 tiles wide gap). Above it a solid platform.
4. Enemy patrol on a run of ground x=18..24.
5. Water pool x=26..30 (deep, 2 tiles) at ground; jump across.
6. Staircase platforms up to trophy on a pedestal at x=38, row 10 (elevated).
7. Enemy patrolling a platform.
8. Descend: platforms down to a lower area with fire.
9. Locked door / exit at far right x=66, row 16, on ground.
10. Optional: to reach exit you must cross a gap over water at x=60..63.

Need route physically reachable — I'll verify by a quick BFS reachability simulation using jump constraints? Simpler: verify manually with jump metrics: max jump height ~3.7 tiles (use 3 tiles safe), max horizontal gap ~4 tiles at same level, and when jumping from a higher ledge to lower, more horizontal.

Let me be generous with platform sizes (3-4 tiles wide) and gaps (2-3 tiles).

Let me write the grid concretely. I'll denote columns 0..69.

Row indices 0..18.

I'll create the map by writing rows as strings of length 70. Let me construct carefully with a script? Actually I'll hand-write with counting in chunks of 10.

Let me build a helper in my head: each row string I'll write in segments of 10 chars separated by `|` in my draft, then join without separators. I'll then verify lengths programmatically with node and fix.

Draft rows (70 wide):

row0:  "......................................................................"
row1:  same
...
Mostly empty until row ~9.

Let me place structures:

Ground: row17 = solid `#` everywhere except pits; row18 = solid `#` everywhere except where pit continues (pit rows 17-18 have hazard).

Pits:
- Fire pit A: columns 13-15 → rows 17-18 contain fire `^`.
- Water pit B: columns 27-30 → rows 17-18 water `~`.
- Water pit C (bottom right, before exit): columns 58-61 → rows 17-18 water.
- Fire pit D: columns 45-47 rows 17-18 fire.

Wait, need the ground row to be walkable surface; a pit at rows 17-18 means the player falling in lands on hazard — that's the death. Fine. But the player walking on row 16 stands atop row 17. Let's define: solid rows at bottom are rows 17 (top surface at y=544) and 18. Player spawn at row 16 (feet at 17*32=544).

Hmm, canvas 608 tall = 19 rows (0..18). Row 17,18 = ground. Play area rows 0..16. Good.

Actually let's reduce to tile size 32, rows 0..18 (19 rows, 608 px). Canvas 960x608.

Structures:

Platforms (solid `=` for metal/stone, `#` for brick):
- P1: row 14, cols 6-8 (small step).
- P2: row 12, cols 10-12? Above fire pit A? Fire pit A cols 13-15 at ground; jumping across it from col 12 to col 16 — gap 3 tiles wide; takeoff at edge col 12 top (standing row 16) landing col 16 row 16. That's fine: horizontal 4 tiles distance from x=12*32=384 to 16*32=512 = 128px = 4 tiles, airtime 44 frames at speed 4 → 176px, so it clears. But to be safe I'll also add an overhead-free approach.

Let me design a linear main path with side extras.

Actually, simpler and more robust: make the level mostly ground-level with pits, and an elevated shelf holding the trophy reachable by a staircase of platforms. Then return to ground and go right to exit. Also add a patrolling enemy on ground and one on a platform, plus moving fire? Fire as static tiles (blazing tiles animated) and water as tiles. Water = instant death hazard (Dave had... whatever). Both hazards kill on touch per spec.

Also add a couple of gems for score.

Trophy placement: on a shelf at row 8, cols 36-40 (shelf solid row 9). Staircase: platforms at row 14 (cols 30-32), row 11 (cols 33-35)? Jump from row 14 to row 11 = 3 tiles up (96px) — need jump height ≥ 3 tiles + player standing... jumping up 3 tiles vertically = 96px, max height 121px, ok but tight with horizontal movement. Let's use 2-tile rises for staircases to be safe (64px, easy).

Staircase plan:
- Ground level surface y=17 (player stands on row 17 top).
- L1: row 15, cols 28-30 (solid) — step 2 up. Wait ground top surface is row 17, so standing area row 16. Step platform at row 15 means its top surface is row 15 top = y=480, that's 2 tiles up from y=544. Fine (64px).

Hmm, let me define "platform at row r, cols a..b" as solid tiles occupying row r. Player stands on top of it, occupying row r-1.

Ground solid rows: 17,18 → player occupies row 16.
Platform row 14 (cols 24-26): player occupies row 13. Jump from row16 surface to row14 surface = rise 2 tiles (64px), horizontal must clear from ground to platform edge — fine since platform is above, you can jump straight up next to it? No — solid walls: you can't pass through; if the platform is a floating slab with space beneath, you can jump onto it from ground: rise 2 tiles, ok.

So staircase: row 15 slab, row 13 slab, row 11 slab, row 9 slab (trophy shelf). Each rise 2. Horizontal gaps 1-2 tiles.

Let me write out the level explicitly with columns. I'll draft with a coordinate list approach then generate the grid in code? Generating the grid in JS from rectangle primitives is cleaner and less error-prone than hand-drawn ASCII! I can define the level with an array of rect commands in JS:

```js
const LEVEL_DEF = {
  w: 72, h: 19,
  solids: [ [x,y,w,h], ... ],
  hazards: [ ... ],
  ...
};
```
Then build tiles. But hand-authored ASCII is easier to visually verify. Compromise: build with primitives and then render a debug ASCII to verify. I'll do primitives + a node check script that prints the grid as ASCII so I can visually confirm, plus a solver that checks reachability with BFS over jump arcs. That's a nice verification. Maybe simpler: I can implement in-game and check visually via screenshot.

Actually, let's do hand-drawn ASCII carefully; it's the most reviewable. I'll count in chunks. To reduce risk, I'll write a small node script to validate row lengths and print, and also run a physics reachability check by simulating with the same tile grid.

Let me draft the 72-wide, 19-tall map. I'll write rows with 10-char chunks.

Columns:      0         1         2         3         4         5         6
              012345678901234567890123456789012345678901234567890123456789012345678901234

Let me define width 64 to keep it simpler? 64 tiles * 32 = 2048px, view 30 tiles (960px). Camera scroll. Let's use W=64.

Layout plan (W=64, H=19):

Bottom ground: rows 17-18 solid, with pits:
- Fire pit: cols 11-13 (3 wide) rows 17-18 = fire.
- Water pit: cols 22-25 (4 wide) rows 17-18 = water. 4-tile gap: horizontal jump distance from col 21 edge (x=22*32=704, standing right edge at 736) to landing at col 26 (x=832)... Let me compute properly: player standing on ground at cols ...21, i.e. feet on row 17 top surface, last solid col 21. Player's right edge at x=22*32=704. Take off anywhere up to x=704 (left edge 704-32=672). Gap spans x from 704 to 832 (cols 22,23,24,25 water = 4 tiles = 128px). Landing: player left edge must be ≥ 832 to be on solid col 26. So needs 128px + of horizontal travel while airborne (must also rise above? water tiles at rows 17-18, top surface y=544; player height 2 tiles? Let's make player 1 tile wide x ~1.6 tiles tall? Actually player size ~ 22x38 px within 32 tile.

Hmm: water at rows 17,18 is flush with the ground surface (top of water at y=544 = same as ground top). Walking into it = touching water = death. To jump over a 128px gap: airtime with jump v=-11,g=0.5 → 44 frames; need horizontal distance 128 + player width... Let's say the player must travel from x_left=672 to x_left=832 → 160px at 4px/frame = 40 frames ≤ 44. Tight but doable with running start. To be safe, use gaps of at most 3 tiles (96px) at equal height, and give max speed 4.5. 3-tile gap: travel 96+? from 672 to 768 (col 24 left edge) = 96px → 22 frames. Easy.

So: pits of 3 tiles wide. And also place a stepping platform in the middle of the wider ones if I want.

Let me finalize pits: fire cols 11-13, water cols 22-24, fire cols 40-42, water cols 50-52. And ground solid elsewhere cols 0-63 rows 17-18.

Elevated shelf for trophy: rows 9-10 slab cols 30-38, with staircase from ground: 
- slab A: row 15, cols 26-28 (rise 2 from ground) — reachable from ground at col 25ish? Actually ground col 25 area. Wait, water pit cols 22-24 means after crossing you land at col 25. Then platform row 15 cols 26-28 above the ground — jump up 2 tiles.
- slab B: row 13, cols 29-31
- slab C: row 11, cols 32-34
- shelf D: row 9, cols 35-40 with trophy at col 37 (trophy tile placed on top of shelf → trophy occupies row 8, col 37; standing on shelf row 9 top).

Each rise 2 tiles, horizontal shift 1-2 tiles: jump from row15 surface (player occupies row 14) to row 13 surface (player occupies row 12) — the target slab is 2 tiles higher and its left edge is 3 cols to the right of source slab's left edge. From source right edge col 28 (x=29*32=928) to target col 29 (x=928)... they're adjacent, fine. Let me make them overlap-ish so jumps are short: A: row15 cols 26-29; B: row 13 cols 30-33; C: row 11 cols 34-37; D: row 9 cols 38-43 (trophy at col 40, row 8).

Check jump A→B: stand on A top (row 15) at col 29 (right edge x=30*32=960), B at row 13 starts col 30, top surface y=13*32=416, player feet need to reach y=416 from y=480: rise 64px, horizontal from x_left 960-32=928 to at least 960: short. During a 2-tile rise the player can travel horizontally: at apex 22 frames * 4 = 88px ≈ 2.7 tiles. Fine.

B→C: B row 13 cols 30-33 → C row 11 cols 34-37: same pattern. Fine.
C→D: C row 11 cols 34-37 → D row 9 cols 38-43. Fine.

Then from D (row 9, cols 38-43) the player can drop off the right end into... ground at col 44+ (ground rows 17-18 solid cols 43-49 since fire pit 40-42). Wait fire pit cols 40-42 at ground, and D shelf above cols 38-43. Dropping from D right end (col 43, x=1408) lands on ground col 43? Ground solid at cols 43-49 (40-42 is fire). Yes col 43 is solid. Good, safe landing.

Then continue right: ground cols 44-49, water pit cols 50-52, ground 53-63, exit at col 60 on ground (door occupying rows 15-16, col 60). Also maybe an enemy patrolling ground cols 53-59.

Also enemies:
- E1 patrol on ground cols 3-9 (before fire pit) — wait fire pit cols 11-13; enemy patrol ground cols 2-10.
- E2 patrol on ground cols 44-49.
- E3 patrol on shelf D cols 38-43? That'd block trophy collection—could be too hard. Maybe patrol on a mid platform: put E3 on slab A cols 26-29 (small). Hmm, patrolling enemies on the staircase make it hard but doable. Let's keep 3 enemies: ground left, ground right, and one on the shelf at row 9? Let's put E3 on row 11 slab (cols 34-37) patrolling its 4 tiles — a slow bot. That's fine, player can wait or... they can't jump over a 22px-tall bot? They could jump over it if it's short. Nice gameplay.

Also add gems (Dave treasure): a few `o` gems at various spots for score. Optional flavor; they add score.

Also add brick decorations: walls/ceiling to make it feel like a dungeon. Add a solid ceiling rows 0-1 across? Let's add side walls: col 0 rows 2-18 solid, col 63 rows 2-18 solid. Plus some brick columns as obstacles/pillars.

Careful: pillars in the path make jumps harder. Let's add pillars that the player must jump over or that block a passage requiring a higher route? Keep simple: a couple of 2-tall brick stacks (rows 15-16) at cols 18-19 which the player must jump over (2 tiles = 64px rise; jumpable from ground). Hmm, jumping onto a 2-tall block: rise 64px and land on top — fine, then drop on the other side.

Actually, to test "solid-wall collision" nicely, pillars are good.

Let me also consider the water pit: make it 2 tiles deep (rows 17-18) and 3 wide. And the fire: 3 wide rows 17-18. Good.

Let's now write the ASCII grid rows. W=64, H=19.

I'll list structures as tiles to place:
Solids `#` (brick) and `=` (stone platform). I'll use `#` for brick/pillars/ground, `=` for platform slabs.

1. Ground: rows 17,18 all cols 0..63 `#`, except pits: 11-13 fire, 22-24 water, 40-42 fire, 50-52 water.
   Also bedrock row 18 within pits: fire/water too (so falling in = death at bottom).
2. Left wall: col 0 rows 3..18 `#`. Right wall: col 63 rows 3..18 `#`.
3. Pillars: cols 18-19 rows 15-16 `#`. Hmm — with ground at row 17, a pillar occupying rows 15,16 = 2 tiles tall, top at row 15. To pass: jump onto it (64px rise) then step down. Alternatively route over via platform. Fine. But careful: it could also be possible to walk-run into it and just stop — dead end? Player can jump up 2 tiles, so no dead end. Good.

Actually let me double-check jump height: max 121px = 3.78 tiles, so 2-tile blocks are easily jumpable. Even 3-tile (96px) is jumpable.

4. Slab A: row 15, cols 26-29 `=`. Wait pillar at 18-19 rows 15-16, ground 22-24 water pit. Slab A at row 15 cols 26-29.
5. Slab B: row 13, cols 30-33 `=`.
6. Slab C: row 11, cols 34-37 `=`.
7. Shelf D: row 9, cols 38-43 `=` with maybe brick underside? Just the slab (1 tile thick).
   Trophy: col 41, row 8 (on top of shelf D). Trophy occupies row 8; the shelf top surface at row 9. Player walks on shelf at row 8 (occupying rows 8-7 since player is ~1.2 tiles tall? Need player height in tiles for collision: use pixel-based collision with tile grid, so trophy is a pixel-space item. Fine.
8. Extra: a brick roof / decorative ceiling rows 0-1? Let's add scattered solid bricks as decoration at rows 2-4 forming a partial ceiling, with gems. Keep them non-blocking.
9. Exit door: at col 58-59, rows 15-16 on ground: `E` tiles (2x2). Door is drawn as a big door. Interaction: player overlapping door area triggers check.
10. Gems `o`: at (row 14, col 27) above slab A? Gems should be placed at standing height: e.g. col 27 row 14 (on top of slab A), col 31 row 12, col 35 row 10, col 45 row 16, col 5 row 16, col 61 row 16.
11. Enemy spawns `B`: (row 16, col 6) ground; (row 16, col 46) ground; (row 10, col 35) on slab C. Wait row 10 is above slab C (row 11) → enemy occupies row 10 standing on slab. Good. Patrol bounds determined in code: patrol on the platform, walking back and forth within a range (detect edges: turn around when tile ahead-below is not solid or tile ahead is solid).

Edge detection generic: enemy moves; if the tile in front at its feet row is not solid → turn; if tile in front at body row is solid → turn. That keeps them on their platform.

Let me verify enemy on slab C cols 34-37: patrol between 34 and 37 edges. Fine. And player must pass slab C to reach shelf → must dodge by timing or jumping over (enemy ~20px wide/tall, player can jump over since jump is 3.7 tiles high).

Now, does the player need to descend from shelf D to continue right? Yes: drop off right edge (col 43) onto ground col 43. Ground at cols 43-49 solid. Fine. Alternatively drop into fire pit 40-42 (death). That's a risk—that's fine, that's the game.

Hmm wait: shelf D cols 38-43 sits above fire pit cols 40-42. Dropping straight down from shelf middle → into fire. Player must walk off the right end at col 43. That's a legit design.

Let me double-check: is there a way to reach the trophy without dying? From slab C (row 11, cols 34-37) jump to shelf D (row 9, cols 38-43): rise 2 tiles, horizontal from col 37 (right edge x=38*32=1216) to shelf; player must land on shelf top at row 9 → feet y = 288. Standing on slab C: feet y = 11*32=352. Rise 64px. Horizontal travel from x_left=37*32=1184 to x_left ≥ 1216-? Player needs to land on shelf: any feet position over cols 38-43 while at y=288. Travel needed ≥ 32-48px. During rise of 64px, time to reach apex 22 frames, horizontal 4px/frame → 88px. Fine.

Also, could the player overshoot the shelf right end and fall? ok.

Now the water pit at cols 50-52 then ground 53-62, exit door cols 58-59. Enemy patrolling cols 44-49 ground area (before the water pit). Player must dodge or jump over. Fine.

Alternatively add a second enemy between exit and water pit cols 53-62. Let's have: E1 ground left (patrol cols 3-9), E2 on slab C, E3 ground right cols 53-61, E4 ground cols 44-49. 4 enemies, 3 enemies is fine. Let's do 4 for spice? Keep 4 but with different speeds. Actually with the requirement "at least one patrolling enemy", more is fine. Let's do 4 enemies. But careful: jumping over enemies requires the enemy to be low enough. Player jump apex 121px above ground, enemy height ~22px → easy to hop over.

Also: Dave-style "lives"? Add lives=3? The spec says "causes a loss state" on touching hazard/enemy — so single touch = loss (game over state) with Restart. Keep it simple: instant loss state (message + restart). No lives to strictly follow spec.

HUD: score (gems), trophy collected flag, status message, controls display, restart button + R key.

Now rendering: procedural drawing of brick tiles with mortar lines, stone slabs, animated fire (flames flicker), animated water (waves), trophy (cup with handles + base, sparkle), enemies (killing-bot: metal box with treads, eye scanning, antenna), player (Dave: white/blue shirt, cap, boots, facing direction, walk cycle animation frames), door/exit (arched door with dark interior, glowing when trophy held), background (brick wall gradient with pillars/vignette), HUD panel.

Camera: follows player horizontally, clamped.

Let me now write the ASCII map carefully.

I'll write each row as 64 chars. Let me build them using a node script to assemble from primitives, then verify by printing. That's the safest path, and the assembled ASCII can be embedded... Actually, generating the map from primitives at runtime in JS is fine and compact. But hand-verifying is easier with printed ASCII. I'll write the game with an embedded ASCII string array (generated/validated by a node script during dev) so the file contains a readable level.

Plan: write a dev script that builds the grid from primitives, validates (row lengths), runs a reachability simulation (BFS with physics approximated) and prints ASCII. Then paste the resulting ASCII into index.html as MAP constant. Good.

Let me write the builder script.

Primitives:
```
W=64,H=19
fill rows 17-18 with '#' for cols 0..63
pits: fire cols 11-13 rows 17-18; water 22-24; fire 40-42; water 50-52
walls: col0 rows 3-18 '#', col63 rows 3-18 '#'
pillar: cols 18-19 rows 15-16 '#'
slabs: A row15 c26-29 '='; B row13 c30-33; C row11 c34-37; D row9 c38-43
decor ceiling: row2 c8-14 '#', row 2 c 20-26? Let's add brick canopy rows 0-1 partial? Simpler: add some decorative solid blocks high up that serve as bonus gem ledges: e.g., row 6 c16-19 '=' with gem at row5 c17, reachable? From where? Hard to reach — skip or make reachable.
```
Optional side platform with bonus gem: from pillar top (row 15 c18-19) jump to slab row 12 c16-19? rise 3 tiles (96px) with horizontal shift -2 (leftward). Reachable. Then a gem there, and drop back. Let's add: slab E: row 12, cols 15-18 '=' with gem at row 11 col 16. Jump from pillar top (feet y=15*32=480) to slab E (feet y=12*32=384): rise 96px, and horizontal from x≈18*32=576 to slab cols 15-18 includes 18 so directly above-left; easy.

Hmm but slab E at row 12 cols 15-18 with pillar at rows 15-16 cols 18-19: player standing on pillar top at row 14 (feet 480) jumps up; head goes to y=480-121=359 > 384 slab? Slab bottom is row 12+1 → occupies row 12 only (top y=384, bottom y=416). Player head at 359 would hit slab underside (416 top? no). Let me think: player feet 480, height ~38px → head at 442. Jump rises 121 → head at 321, feet at 359. Slab E occupies y 384..416 at cols 15-18. Player jumping at col 18-19 x position: if at col 18 (x 576..608) which is under slab E (cols 15-18 includes 18) → the player would hit the slab underside at y=416 (feet can't go above 416 while under it... actually head collides). So they'd bonk. To land on slab E, they should jump from a position to the right of col 18 — but pillar is cols 18-19, so jump from col 19? Slab E includes col 18, so above col 19 is free (slab E is cols 15-18). Rising there then moving left lands on slab E top. But collision at head: while under the slab the head is blocked... Player at col 19 rising to y between: at col 19 no slab, free up to row 3? Then move left onto slab E top while above y=384. Feet must be above 384 → rise from 480 to ≤ 384 is 96px, and max rise 121 gives ~25 frames of window where feet are above 384 near apex. Horizontal move 4px/frame; from x 608 (col 19 left edge = 19*32=608) to land on slab E top with feet above 384... Player must move left ~ from col 19 to col 18 (x 576-608). That's within reach. OK but tight-ish.

Simplify: slab E at row 12 cols 19-22. But then it's above the ground near the water pit 22-24... Actually slab E row 12 cols 19-22 and pillar rows 15-16 cols 18-19. Jump from pillar top (col 19, feet y=480) straight up: under slab? slab occupies row 12 at cols 19-22, i.e. y 384-416. Player at col 19 jumping up bonks their head at 416 - hmm.

Let's avoid the head-bonk complexity: place bonus slab with clear vertical access. Move bonus slab to row 13, cols 5-8 with gem at row 12 col 6, reachable by jumping from ground (feet 544 → 416 = 128px rise > 121 max!). Not reachable. Row 14: rise from ground = 544→448=96, reachable. So bonus slab: row 14, cols 6-9 '=' and a second slab row 11, cols 10-13? Hmm, then gem.

Simplest bonus: one slab row 14 cols 6-9 with a gem on it (score +, not required). And place a "key/locked door"? No—skip keys, out of scope.

Actually a bonus ledge above the shelf area to hold a second gem. Keep it minimal: 5 gems total placed at reachable spots (on the main path and one on the ledge).

Let me now finalize the map:

Solids (brick `#`):
- rows 17-18: cols 0-63 except pits.
- col 0: rows 3-16.
- col 63: rows 3-16.
- pillar: rows 15-16, cols 18-19.
- Bonus ledge: row 14, cols 6-9 (`=` stone). Wait player standing on ground (feet y=544) jumping onto row 14 slab: top y=448, rise 96. Reachable. Then from ledge they can walk and drop. Good. Gem at row 13 col 7.

Hmm but the ledge at row 14 cols 6-9 is above ground where enemy E1 patrols cols 3-9. Enemy under a ledge—fine, edge detection keeps it going.

Stone slabs `=`:
- A: row 15, cols 26-29
- B: row 13, cols 30-33
- C: row 11, cols 34-37
- D: row 9, cols 38-43
- L (ledge): row 14, cols 6-9

Hazards:
- fire rows 17-18 cols 11-13
- water rows 17-18 cols 22-24
- fire rows 17-18 cols 40-42
- water rows 17-18 cols 50-52

Wait — is a 3-tile-wide hazard pit jumpable from ground level? Standing surface row 16 both sides. Gap from col 11 to col 13 = 96px; the player must travel from x_left ≤ 10*32=320 (i.e. last safe standing col 10, right edge at 352 → player left edge 320) to landing left edge ≥ 14*32=448. So 128px of travel while airborne over a 96px hole plus player width 24. With 44-frame airtime at 4px/frame = 176px, comfortable. Good.

Hmm, one subtlety: player width 24, tile 32. When standing at the right edge of col 10, the player's left edge can be at 320 (x = 10*32) and body 320..344 (within solid col 10 which spans 320..352). Yes so takeoff x_left=320 max.

Exit door: cols 58-59 rows 15-16 (`E`). Door drawn 2x2 tiles. The player must overlap the door center. Ground beneath cols 58-59 rows 17 solid. Player approaches from left along ground. Also the right wall col 63.

Wait, door tiles at rows 15-16 must not be solid (otherwise blocked). They're marked `E` and treated as non-solid.

Trophy: col 41, row 8 (`T`) on top of shelf D. Non-solid.

Enemies `B`: row 16 col 6 (ground, patrols cols 3-9... but ledge above, fine), row 10 col 35 (on slab C row 11), row 16 col 46 (ground), row 16 col 55 (ground, near exit).

Gems `o`: row 13 col 7 (on ledge), row 14 col 28 (on slab A), row 12 col 32 (on slab B), row 10 col 36 (on slab C), row 16 col 47 (ground), row 16 col 61 (ground near exit). Hmm, gems are collectible for score, non-required.

Careful: gem at row 10 col 36 on slab C where enemy patrols — the enemy would "collect" nothing, but it makes it a risk. Fine.

Ceiling decor: add solid bricks rows 3 cols 12-20 and rows 3 cols 40-52 for visual variety (doesn't affect gameplay since player can't reach row 3 there... Actually jumping from ground max apex head at 544-38-121=385 → row 12. Can't reach row 3. On shelf D (feet 288) head reaches 288-38-121 = 129 → row 4! So a ceiling at row 3 above the shelf could bonk. Shelf D cols 38-43; if I put a ceiling there it'd restrict. Put decor ceiling only on the left side. Or skip ceiling decor entirely and paint background walls procedurally. I'll add small decor bricks at rows 2-3 for the background but as non-solid "background bricks" drawn in the bg layer, not tiles. Good idea: draw bg pattern procedurally, no collision.

Now build the ASCII map. Let me write a node script.

Then in index.html, embed MAP as array of strings.

Physics constants: TILE=32, GRAV=0.55, JUMP=-11.4? Let's recompute: max rise = v²/(2g). Want ~3.5 tiles (112px) so 2-tile steps are comfortable and 3-tile steps possible. v=11, g=0.5 → 121. Let's use GRAV=0.5, JUMP_V=11.2 → 125px. Airtime = 2*11.2/0.5 = 44.8 frames. Speed 4.0 → 179px horizontal.

For stepping up onto row 15 slab A from ground (rise 64px): the player's feet must be above 480 at the point of horizontal overlap. Fine.

Wait, but slab A at row 15 cols 26-29: is it reachable from the ground? Rise from feet 544 to feet 480 = 64px. Yes.

Hmm, but slab A's left edge at col 26; ground pit water at cols 22-24; so after crossing water you land at col 25 and can jump onto A. Good.

Now also make sure: after collecting the trophy on shelf D, the player descends to ground col 43-49, crosses fire pit 40-42? No—they're already past it (they land at col 43, east of the fire pit). Then continue right to water pit 50-52, jump across, ground 53-62, door at 58-59. 

Wait — I need to double check that going right along the ground from col 44 to col 49 there's no hazard: fire pit 40-42 is behind them. Yes.

Total level: 64 tiles wide.

Now let's think about the "Reaching the exit without trophy gives visible feedback and keeps the level active": show a message near the door "The door is sealed — find the TROPHY first!" plus the door shakes/red flash, and a HUD hint. And player keeps playing (no state change). Add a cooldown so message doesn't spam (fine, it's shown while touching).

Lose state: overlay "GAME OVER" + reason + Restart button; also R key. Win state: overlay "LEVEL COMPLETE" with time and gems + Restart (Play again).

Also a "Restart" button visible during play (HUD) — spec says provide Restart after either outcome and during play. So a button in HUD + R key.

Controls display: "← → / A D = Move · Space = Jump · R = Restart" shown in HUD and overlay.

Input handling: keydown/keyup with preventDefault for arrows/space. Jump only while grounded. Also implement coyote time? Spec says jumping only while grounded — strictly, no coyote. Keep strict grounded check (grounded flag from collision resolution this frame).

Let's implement collision: move X, resolve against solid tiles; move Y, resolve; set grounded when vertical velocity blocked downward.

Tile solidity: '#' and '=' solid. Fire/water/hazard are NOT solid (player passes into them and dies). Trophy/gem/door/enemy non-solid.

Hazard check: pixel-vs-tile overlap: check tiles overlapping the player's AABB for fire/water → death. Player hitbox: x+4..x+28? Let's make hitbox slightly smaller than sprite: w=22, h=34 offset within 32x40 sprite.

Enemies: AABB overlap → death.

Camera: cam.x = clamp(player.x + pw/2 - VIEW_W/2, 0, LEVEL_W*TILE - VIEW_W). VIEW_W=960 (30 tiles), VIEW_H=608 (19 rows). Canvas internal resolution 960x608; CSS scales to fit width. Maybe make canvas 960x600? Use exact tile math: 608 tall.

Hmm, 608 tall plus HUD panel ~ 90 in HTML above canvas. Fine.

Rendering style: Dangerous Dave vibe — VGA-ish palette, brick walls, beveled tiles, chunky pixel sprites drawn with fillRect at integer coords. Use imageSmoothingEnabled=false and draw at 2x? Let's draw at native and set ctx scale? Simpler: canvas 960x608, tiles 32px, sprites drawn with rects. For pixel feel, use a slightly lower internal res and CSS scale up with image-rendering: pixelated. E.g., internal 480x304 with TILE=16? That halves tile detail. Let's keep 960x608 with TILE=32 and draw chunky rects (each sprite drawn as blocks of 4px units to look pixelated). I'll implement a helper `px(x,y,w,h,color)` that snaps to 4px grid for a pixel-art feel: unit = 4px. Good: Dave sprites ~16x16 pixel art scaled 2x with pixel=... Let me define sprite drawing on an 8px unit grid within 32px tiles (4x4 units) — coarse. Use 4px units → 8x8 units per tile. Player 22x34 → drawn with 4px units ≈ 5x8 units. OK-ish. I'll do 2px units for sprites for finer detail (player 12x18 units). Good enough — I'll hand-draw with rects at 2px-ish granularity? Simplest: draw the player from a small pixel matrix (string art!) scaled by 4. Like:

```
const DAVE = [
 "....hhhh....",
 ...
]
```
That's a nice procedural approach: define sprite as string array with color codes, draw scaled. Enemy too, trophy, gem. That's "drawn procedurally" (no external assets) — fine, it's code-generated.

I'll do a `drawSprite(matrix, x, y, scale, palette)` with per-frame variants for walk (2-3 frames), enemy (legs alternate), trophy sparkle.

Let me design sprites:

Dave (12 wide x 16 tall units, scale 2 → 24x32 px; hitbox 24x32 fits tile 32). Player size: w=24,h=32? Standing on ground row 17 top y=544 → occupies y 512..544. Fine.

Sprite matrices (chars map to colors):
- `.` transparent
- `1` dark outline (#1a1a2a)
- `2` skin (#f2b48c)
- `3` shirt white/blue (#3a72d1)
- `4` pants (#2a2a4a)
- `5` boots (#7a4a2a)
- `6` cap red (#d13a2a)
- `7` hair (#5a3a1a)

Let me write Dave idle 12x16:
```
row0:  ....6666....
row1:  ...666666...
row2:  ...122221...
row3:  ..1221122...  hmm eyes
```
Let me keep it simple and readable; I'll make a 10x14 matrix, scale 2.4? Let's use scale = 2 with 12x16 matrix → 24x32. 

Idle (facing right):
```
"....66666..."
"...6666666.."
"...222222..."
"...212212..."   (eyes as 1)
"...222222..."
"....2222...."
"...333333..."
"..33333333.."
"..32333323.."  (arms skin at ends)
"..32333323.."
"...333333..."
"....4444...."
"...44..44..."
"...44..44..."
"...55..55..."
"..555..555.."
```
That's 16 rows of 12 chars. I'll flip horizontally for facing left by mirroring the matrix in code (scale -1 via transform or build mirrored matrix). Use ctx.save/translate/scale(-1,1).

Walk frame: legs apart variants.

Enemy "killing-bot" 12x12: metal body with red eye, treads:
```
".....11....."
"...116611..."
"..11333311.."
".1133333311."  etc.
```
Let me define: body steel `8`=#9aa3b0, dark `1`, eye `6`=red, treads `4`=#3a3a4a, antenna.

Trophy 10x12: gold `9`=#f5c542, dark gold `a`=#c08a1a, base dark.

Gem: diamond with facets.

Door: drawn with rects (arch, wood planks, glow).

Fire: animated flames: draw 3 flame tongues with per-frame sine offsets, orange→yellow gradient bands, plus glowing embers in the pit; also flicker.

Water: animated horizontal wave lines with two sine offsets, translucent blue layers, splash edges.

Background: dark blue-grey brick pattern with mortar, plus vignette and torches on the wall for atmosphere. Torches animated flicker (procedural). Nice.

HUD: In-canvas top bar? Better as HTML panel above canvas: score, gems, trophy status, message line, buttons (Restart), controls. Also draw in-canvas messages for door feedback (floating text) — spec wants visible feedback: show canvas toast near door + HUD message + door shake + red X flash. Let's do both.

Let's also add a small "level intro" overlay? Keep simple: game starts immediately, with a controls banner. Overlay only for win/lose.

Timer for score? Add elapsed time in HUD. Nice.

Now implementation structure:

```js
const TILE=32, MAP=[...];
state: {player, enemies, items, cam, status:'play'|'win'|'lose', msg, msgTimer, gems, hasTrophy, time}
reset() builds entities from MAP scan (T, o, B, E, P).
```
Player spawn `P` at row 16 col 3.

Game loop with requestAnimationFrame and fixed timestep accumulator (dt 1/60) for deterministic physics.

Collision function:
```js
function solidAt(tx,ty){ const c = tileAt(tx,ty); return c==='#'||c==='='; }
```
tileAt: out of bounds → treat as solid for left/right/top? For above (ty<0) treat as non-solid to avoid weirdness; but with ceiling walls, doesn't matter. Below/beyond map edges solid.

Move: 
```js
player.x += vx; resolve horizontal: check overlapping tiles; if solid, push out and vx=0.
player.y += vy; resolve vertical: if moving down and hit → y = tileTop - h, vy=0, grounded=true; if moving up → y = tileBottom, vy=0.
```

Hazard overlap: iterate tiles in AABB → if fire/water char → lose("You fell into the fire/water!").

Enemy: patrol with speed, reverse on wall or ledge. Draw. AABB overlap with player → lose("A killing-bot got you!").

Enemy movement uses same tile collision (simplified: horizontal resolve + vertical gravity). Or keep them glued to their platform: they move horizontally and reverse at edge: check tile ahead at feet level solid? and tile ahead at body level solid.

Death animation: brief (0.6s) shake + flash then overlay. Let's add `dying` state with particles, then overlay 'lose'. Similarly win: door opens, player walks in with a fade? Keep simpler: win overlay after a short sparkle animation (0.8s).

Also spec: "Touching a hazard or enemy causes a loss state." Direct is fine, I'll add a short 500ms death effect then overlay.

Let's write it. Also mobile? Not required.

Let me first build the map via script and validate.

I'll write /tmp/job-pSgopN/dev/map.js that builds and prints. Then embed. Let me go.

Also add a reachability sanity check: simulate a simple BFS over "standing positions" with jump model to verify path from P to door and trophy. That's a nice verification but time-costly. Alternative: I trust the geometry checks I did + verify in-browser by playing? I can't easily play through in the browser tool... Actually I can! I can drive the game by dispatching keyboard events via the browser tool and screenshots. Better: I can write a headless physics check in node: implement a "autopilot" that holds Right and Space when needed? Simpler deterministic check: greedy controller simulating the same physics — jump when blocked or when gap ahead. That's decent verification the level is completable. Hmm, time budget 15 min. Let me do a lighter check: verify each required gap/step against physics constants analytically (done above) and do a BFS reachability check over standing tiles with jump arcs using simplified physics: from a standing tile, allowed moves = walk to adjacent standing tile, fall to standing tile below (if no hazard in column), and jump arcs: for each of 44 frames simulate with vx∈{-s,0,s} and vy from jump, using real tile collision — that's a real physics-based search. I can implement it by reusing the same physics functions if I factor them into a shared module... In node I'd need to extract. Approach: write index.html with physics functions, then in node, extract the physics part via a small harness: read index.html, eval the MAP + functions? Doable with a regex slice but brittle.

Alternative: put the map + tile helpers in a separate dev file, generate the map ASCII, and write the physics-based solver in a dev file that duplicates constants (TILE, GRAV, JUMP, SPEED) and collision code (copy). It's dev-only; acceptable duplication. Time permitting I'll do the solver check. Let me prioritize: build map (script) → write index.html → browser verify (screenshots + console + simulate key presses) → optional solver.

Let me write the map builder now.

Actually simpler: I'll write index.html with the map as a generated string in JS from primitives? No — I want readable ASCII. Let me run the builder and paste.

Builder code:

```js
const W=64,H=19;
const g=[]; for(let y=0;y<H;y++) g.push(Array(W).fill('.'));
const set=(x,y,c)=>{ if(x>=0&&x<W&&y>=0&&y<H) g[y][x]=c; };
const rect=(x,y,w,h,c)=>{ for(let j=0;j<h;j++) for(let i=0;i<w;i++) set(x+i,y+j,c); };
// ground
rect(0,17,W,2,'#');
// walls
rect(0,3,1,14,'#'); rect(W-1,3,1,14,'#');
// pits
rect(11,17,3,2,'^'); rect(22,17,3,2,'~'); rect(40,17,3,2,'^'); rect(50,17,3,2,'~');
// pillar
rect(18,15,2,2,'#');
// ledges
rect(6,14,4,1,'=');
rect(26,15,4,1,'='); rect(30,13,4,1,'='); rect(34,11,4,1,'='); rect(38,9,6,1,'=');
// door
rect(58,15,2,2,'E');
// trophy
set(41,8,'T');
// gems
set(7,13,'o'); set(28,14,'o'); set(32,12,'o'); set(36,10,'o'); set(47,16,'o'); set(61,16,'o');
// spawn
set(3,16,'P');
// enemies
set(6,16,'B'); set(35,10,'B'); set(46,16,'B'); set(55,16,'B');
```

Wait: enemy at col 6 row 16 but spawn at col 3 row 16 — enemy patrols cols 3-9 near spawn; player would die immediately at start? Enemy starts at col 6 moving right, patrol range determined by edges: from col 6 it walks until edge/wall: to the right, ground is solid until col 11 (fire) so it turns at col 10 edge; to the left turns at col 1 (wall at col 0) or ledge? So it will pass right over the spawn point (col 3) at start. Player must move away immediately. Better: place the first enemy further right, e.g. cols 7-10 patrol, starting at col 9 moving right, so player has time. Or shift spawn to col 2 and enemy start at col 8. Let's put spawn col 2, enemy1 start col 8 with patrol toward right first. Player at col 2, enemy at col 8 moving right (away) → safe start.

Also gem at (7,13) requires jumping onto ledge row 14 cols 6-9; the gem occupies row 13 above ledge. Good.

Also enemy on slab C at row 10 col 36 (slab C row 11 cols 34-37). Patrol within those 4 cols.

Enemy at col 46 ground (between shelf/fire and water pit 50-52): patrol cols 44-49. Good.

Enemy at col 55 ground: patrol 53-62 (right wall col 63). Passes in front of the exit door (58-59) — makes the finale tense. OK.

Print rows to verify.

One more check: pillar cols 18-19 rows 15-16 sits between fire pit (11-13) and water pit (22-24); ground solid at cols 14-17 and 20-21. Fine.

Also check ledge row 14 cols 6-9 vs. fire pit 11-13: no conflict.

Door 58-59 rows 15-16, on ground. Right wall col 63 rows 3-16 — door not blocked.

Now the player must be able to reach the door area from water pit 50-52: land at col 53 ground → walk to door 58. Good.

Now, does the player have to pass through the door's tiles? Door tiles are non-solid; overlap triggers check. Good.

Let me write and run the builder.

Then index.html. Let me draft the code fully and carefully.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Dave's Dungeon — Tile Platformer</title>
<style> ... </style>
</head>
<body>
<div class="wrap">
 <h1>...</h1>
 <div class="hud">...</div>
 <div class="screen"><canvas id="game" width="960" height="608"></canvas></div>
 <div class="controls">...</div>
</div>
<script> ... </script>
</body>
</html>
```

CSS: retro dark page, pixel font via monospace (no external fonts), scanline overlay on canvas maybe. Buttons styled retro. Keep neat.

JS details:

```js
const TILE=32, VIEW_W=960, VIEW_H=608;
const SOLID = new Set(['#','=']);
const GRAV=0.5, MAXFALL=12, JUMP=11.2, RUN=4.0, ACCEL=0.8, FRICTION=0.6;
```
Movement: direct velocity control with a bit of accel:
```js
if(left) vx -= ACCEL ... clamp; else if(right) vx += ACCEL; else vx = approach(vx,0,FRICTION)
```
Simple: target velocity = dir*RUN, vx = lerp toward it (0.35 factor) for a snappy feel.

Jump: on keydown Space when grounded → vy = -JUMP, grounded=false. Must require key press edge? "jumping is allowed only while grounded" — with edge-trigger, holding space won't repeat-jump. I'll use edge trigger (jumpPressed flag consumed each frame) — but then holding space and landing won't jump (needs re-press). Standard. Actually many games let you hold. Spec: only while grounded. I'll allow jump on keydown edge OR when holding and grounded? Let's do: if space is held and grounded → jump (allows bunny hop), which satisfies "only while grounded". Simpler & forgiving. Hmm, but auto-bounce might feel odd. I'll do edge-triggered with a small buffer? Keep: jump requires grounded; trigger on keydown edge; also if key held, allow jump on landing (since grounded & held) — I'll just check held & grounded. Simple and robust. Let's do held & grounded.

Player state:
```js
player={x,y,w:22,h:30,vx,vy,grounded,face,anim}
```
Hitbox 22x30 for collisions; sprite drawn 32x40-ish centered.

Collision resolution function moveEntity(e,dx,dy).

Enemy patrol:
```js
e={x,y,w:22,h:22,vx,dir,min,max}
update: e.x += e.dir*e.speed; check tile ahead for wall → reverse; check ground ahead (tile below-front) → reverse; also clamp within [min,max] if given.
```
Gravity for enemies: keep them at fixed y (they never leave platform). Fine.

Hazards: check overlapping tiles of char '^' or '~' with player AABB; also for enemies? Enemies stay on platforms.

Win/lose overlays drawn in canvas (dim + big text) with restart hint, plus HTML overlay? Canvas overlay is nicer for style. Also show HTML message line. I'll do canvas overlay + HUD text and a visible Restart button always.

Message system: `toast(text,color,dur)` drawn above player/door.

Also HUD: gems collected count, trophy status icon, time, and status text.

Death: status='dying' with timer and particle burst; then 'lose' with reason.

Win: status='winning' → door glow, player fades; then 'win'.

Particles: array of {x,y,vx,vy,life,color}.

Draw order: bg → tiles (only visible range) → items → enemies → player → particles → foreground effects (fire glow) → HUD-in-canvas (toast) → overlay.

Fire glow: additive radial? Use gradient rectangles. Keep simple with rects.

Torch decor: draw on wall background at fixed positions, animated flame; purely cosmetic.

Sprite helper:
```js
function drawMatrix(m, cx, cy, scale, flip){
  for rows/cols: ctx.fillRect(...)
}
```
Colors map object.

Time: fixed step 1/60 with accumulator; frame counter for animations.

Let me also handle window blur → clear keys.

Restart button + R key → reset(). Also Enter/Space on overlay restarts? Space is jump; use R and Enter.

Camera also slight vertical? Level is exactly VIEW_H so no vertical scroll. Good (19 rows = 608).

Now HUD: gem count 6, trophy flag.

Let me write the code now. I'll write the full file and then test in browser.

Detailed drawing functions:

Background: 
```js
function drawBackground(cam){
  // dark gradient sky/cavern
  ctx.fillStyle='#121228'; fillRect(0,0,VIEW_W,VIEW_H)
  // back brick pattern (offset parallax 0.5)
  brickPattern(px offset)
  // vertical pillars decor
  // torches
  // vignette
}
```
Draw back bricks: for each cell of 32x16 pattern with alternating offsets, color #1c1c38 with 1px mortar lines #0d0d20. Parallax factor 0.4.

Tiles:
- '#': brick tile: base #a8452e? Dave used brick. Let's do: ground brick: fill #8b3a2a, bricks lines #5e2418, top highlight #c1613f when tile above is empty. Add 4px bevel: lighter top/left, darker bottom/right.
- '=': stone/metal slab: fill #6b7280 with beveled edges, rivets at corners, top highlight #aab2bd.
- '^': fire: draw pit base dark red #3a1010 with coals, then flames animated.
- '~': water: draw pit dark blue with animated surface waves and highlights.
- 'E': door frame: draw door (wood/iron) with arch; when hasTrophy, glow green/gold and show open light; else closed with keyhole & red X mark. Actually door tiles are non-solid; drawing occupies rows 15-16 (64x64).
- 'T' handled as item entity (trophy) drawn as sprite with sparkle; also mark tile as '.' for collision (keep in item list).
- 'o' gem items.
- 'P' spawn: tile '.'.
- 'B' enemy spawn: tile '.'.

So when parsing: build tiles grid with only structural chars; entities from T,o,B,E,P (E kept as door record + tile cleared).

Also mark hazard tiles list for drawing.

Let me code drawing of the trophy sprite 12x14 matrix:

```
"99999999.."
```
Let me design trophy (10 wide, 12 tall), palette: `9` gold light #ffd85e, `a` gold dark #c9931f, `b` shadow #7a5a10, `c` base brown #5a3a1a.

Rows (10x12):
```
"9999999999"? 
```
Let me draw a cup:
```
row0: "..999999.."
row1: ".99999999."
row2: "9a999999a9"   handles edges? handles are on sides
```
Better approach: cup bowl rows0-4, handles on sides rows1-3, stem rows5-6, base rows7-9.

```
0: ".99999999."  -> actually use indices 0..9
"..........",
".99999999.",
"99999999 99" hmm
```
Let me just write:
```
[
"..999999..",
".99999999.",
"9999999999",
"9a999999a9",
".a999999a.",
"..a9999a..",
"....aa....",
"...9999...",
"..999999..",
".99999999.",
"..........",
]
```
Handles: the '9' at col0 and col9 in rows 2-3 form side handles-ish. Good enough visually; I'll also draw ellipse-ish. Actually simpler: draw the trophy procedurally with rects/arcs: cup as trapezoid, two handles as arcs (stroke), base as stacked rects, plus a star sparkle. Using canvas paths is fine and "procedural". Maybe easier for trophy/door/torch: use paths. Mix: sprites (matrices) for player/enemies, paths for trophy/door/torches.

I'll do trophy with paths:
- bowl: path with moveTo/lineTo trapezoid + quadratic bottom.
- handles: two arcs stroked gold, lineWidth 3.
- stem+base: rects.
- sparkle: 4-point star animated.

Enemy bot: matrix is nice for treads. Let me use a matrix 12x10 with palette and 2 walk frames (tread offset lines, eye direction).

Player Dave: matrix 12x16 with 3 frames (idle, step1, step2) and mirrored for facing left. I'll write frames sharing the top rows and different legs.

Let me write matrices carefully with exactly 12 chars per row and 16 rows.

Common head/torso (rows 0-10), legs variants rows 11-15.

Row template (12 cols, indices 0-11):
```
r0:  "....6666...."
r1:  "...6666666.."
r2:  "..66666666.."
r3:  "...222222..."
r4:  "..22122122.."
r5:  "..22222222.."
r6:  "..22444422.."   (mouth? no) hmm
```
Let me simplify to a chunky 8-bit look:

```
r0:  "....6666...."   cap
r1:  "...666666..."   cap brim
r2:  "...222222..."   face
r3:  "...212212..."   eyes (1 dark)
r4:  "...222222..."   face
r5:  "....2222...."   chin
r6:  "..33333333.."   shirt top + arms
r7:  ".33333333 33" no
```
OK let me write it out concretely as strings with exact counts, using a builder in node to check lengths. I'll write a quick check script for matrices too.

Final attempt (12 wide, 16 tall):

frame idle:
```
"....6666...."
"...666666..."
"...222222..."
"...212212..."
"...222222..."
"....2222...."
"..33333333.."
".3333333333."
".3233333323."
".3233333323."
"..33333333.."
"....4444...."
"....4444...."
"...44..44..."
"...55..55..."
"..555..555.."
```
Each row 12 chars. Let me verify a few: "....6666...." = 4+4+4=12 ✓. "...666666..." = 3+6+3=12 ✓. "...222222..." ✓ 3+6+3. "...212212..." = 3 + "212212"(6) + 3 ✓. "....2222...." = 4+4+4 ✓. "..33333333.." = 2+8+2 ✓. ".3333333333." = 1+10+1 ✓. ".3233333323." = 1+10+1 = 12 ✓ (chars: 3,2,3,3,3,3,3,3,2,3 = 10 ✓). "..33333333.." ✓. "....4444...." ✓. "...44..44..." = 3+2+2+2+3=12 ✓. "...55..55..." ✓. "..555..555.." = 2+3+2+3+2=12 ✓.

Walk frame A (legs stride):
rows 0-11 same; rows 12-15:
```
"....4444...."
"....4444...."
"...444..44.."
"..555....55."
```
Check "...444..44.." = 3+3+2+2+2 = 12 ✓. "..555....55." = 2+3+4+2+1 = 12 ✓.

Walk frame B (opposite stride):
```
"....4444...."
"....4444...."
"..44..444..."
".55....555.."
```
".55....555.." = 1+2+4+3+2 = 12 ✓. "..44..444..." = 2+2+2+3+3=12 ✓.

Jump frame (legs tucked):
```
"....4444...."
"....4444...."
"...444444..."
"...55..55..."
```
Hmm 16 rows: rows 0..13 same-ish and 14-15 tucked. Let me define jump legs rows 12-15:
```
"....4444...."
"....4444...."
"...44..44..."
"..555..555.."
```
"..555..555.." = 2+3+2+3+2 = 12 ✓.

Palette: 1=#14142a, 2=#f0b48a, 3=#3f7fd6 (blue shirt... Dave wears white/blue overalls), 4=#2a2a52 (pants), 5=#8a5a2a (boots brown), 6=#d6412f (red cap).

Add skin hands: '2' used in rows 8-9 at cols 1 and 10 (the 3233333323 pattern gives 2 at col 2 and col 9) - those are hands. Fine.

Enemy matrix 14 wide x 10 tall, scale 2 → 28x20 px. Hitbox ~24x20.

```
r0:  "......44......"   antenna? use 14 chars
```
Let me design 14x10:
```
"....11111...."
```
Count carefully with 14 columns:

```
r0:  ".......11....."   antenna (1 dark)  → 7+2+5=14 ✓
r1:  ".......1......"  → 7+1+6=14 ✓  (antenna stalk) hmm
```
Simpler bot design (14x10):
```
r0:  "....111111...."  top plate? 
```
Let's do:
```
r0:  "..8888888888.."  2+10+2 = 14 ✓  (steel top)
r1:  ".888888888888."  1+12+1 = 14 ✓
r2:  ".8866111166 88"  no
```
Cleaner: body rows with an eye band:
```
r0:  "...88888888..."   3+8+3=14 ✓
r1:  "..8888888888.."   2+10+2 ✓
r2:  "..8811111188.."   dark visor band ✓ (88 111111 88 = 2+2+6+2+2=14 ✓)
r3:  "..881661 11..."  
```
Let me use: visor row with red eyes:
```
r3:  "..88166161 88."  
```
Getting messy. Let me do a 14x10 with rows:

```
r0 "...11111111..."  (3 dots + 8 '1' + 3 dots = 14) top edge dark
r1 "..1888888881.."  (2+1+9+1+... ) hmm count: 2 dots + '1' + 8*? 
```
I'll write the builder check script to validate matrix lengths — that solves the counting anxiety. I'll design loosely and let the script pad/validate.

Bot matrix (14 cols, 10 rows) — final:
```
r0:  "..1111111111.."
r1:  "..1888888888 1."  → I'll avoid spaces; use: "..18888888881." (13) nope.
```
OK, let me be disciplined and count with a table. 14 columns indexed 0..13.

Bot:
- Antenna: col 6-7 rows 0-1 = '1' (dark)
- Head/body: cols 2..11, rows 2..6 = '8' steel, with border '1'
- Eye band: row 4, cols 3..10 = '1' with two red eyes '6' at col 5 and col 8
- Legs: row 7-8: '4' treads at cols 2..11
- Spike arms: cols 0..1 and 12..13 rows 3..5 = '1'/'7'

Rows:
r0: cols0-13: ".....11....." — need 14: dots at 0-5, '1' at 6,7, dots 8-13 → 6 dots + 2 + 6 = 14 ✓ → "......11......" is 14? 6+2+6=14 ✓ string: "......" (6) + "11" + "......" (6) = 14 chars. Good: `......11......`
r1: `......11......` (14) ✓
r2: `..1111111111..` = 2+10+2 = 14 ✓
r3: `..1888888881..` = 2 + '1' + 8*'8'? count inner: "1888888881" = 10 ✓ → total 14 ✓
r4: `..1861111681..` hmm want eyes red '6' with dark band: inner 10 chars: "1" then "6 6"... let me do inner = "1811661181"? Let's define: dark visor with 2 red eyes: chars: '1','1','6','1','1','1','1','6','1','1' → "1161111611" (10) → r4 = `..1161111611..` = 14 ✓. Hmm this puts red eyes at cols 4 and 9? whatever, looks like two eyes.
Actually better: visor band row: `..1166116611..`? Let me just use: r4 = `..1166116611..` count inner "1166116611" = 10 ✓ but that's 4 red pixels - looks like eyes with 2px each. Fine.
r5: `..1888888881..` (14) ✓ (below visor, steel with dark border? inner "1888888881")
r6: `..1111111111..` (14) ✓ bottom body edge
r7: `.444444444444.` = 1+12+1 = 14 ✓ (tread block) — but treads should be two wheels: `.441111111144.`? Let's do r7 = `.4444444444 4.`... simpler: r7 = `..4444444444..` (14) ✓ and r8 = `..4111111114..`? Tread pattern rows 7-8 with alternating dark dots for animation:
r7: `..4444444444..`
r8: `..4141414141..` (frame A) / `..1414141414..` (frame B) → animated treads ✓
r9: `.111111111111.` = 1+12+1 = 14 ✓ (base plate)

That gives a nice chunky bot. Eyes: maybe put a single big red eye that scans. Fine as is.

Palette additions: 8=#98a3b3 steel, 4=#3a3f52 dark grey, plus a lighter steel highlight — I'll add a shade by drawing rects over: use '8' steel and '1' outline; add a highlight color '7'=#d6dde8 for top-left edge: r3 inner → "1788888881"? Keep simple.

Gem sprite: drawn with paths (diamond) — easier.

Door: paths.

Now sizes: player hitbox w=22,h=32; sprite 12*2=24 wide, 16*2=32 tall → draw at (x-1, y) with x being hitbox left. Good: sprite 24x32 vs hitbox 22x32 (centered, 1px each side).

Enemy hitbox: 24 wide x 20 tall (sprite 28x20 at scale 2 → 14*2=28 x 10*2=20). Enemy sits on platform.

Now camera & world width: 64*32 = 2048. VIEW_W=960 → scroll range 1088.

Let me write everything now. I'll aim for clean, complete code.

Additional features to polish:
- Score: gems ×250, trophy +1000, time bonus on win.
- Sound: skip (no assets; could use WebAudio beeps — allowed since no network). Add tiny WebAudio bleeps for jump/collect/hit/win (procedural oscillators). That's a nice touch and uses no external resources. Must handle autoplay policy: create AudioContext on first keydown. Optional but let's include a small synth with a mute toggle. Keep it short.

Let me include: beep(freq, dur, type, gain) and specific effects. Wrap in try/catch.

Now write the code.

```js
// ===== Level =====
const MAP = [ ... 19 strings of 64 ... ];
```

Let me generate the MAP strings via script now.

Then the game code. Let me write it.

For "visible feedback" at door without trophy: set `doorMsg` toast + shake + HUD message "The exit is locked — grab the TROPHY!" + red flash on door. Also a persistent objective line in HUD: "OBJECTIVE: Find the trophy, then reach the exit."

Also add a "hint arrow" pointing toward trophy? Nice-to-have, skip.

Let me start executing.

I'll write dev/map.js, run it, get the ASCII, then write index.html.

Let me also write dev/physics-check.js that simulates a scripted autopilot? I'll decide after the main build if time remains.

Go.

No visible pipeline dir here. Let's write dev/map.js.

Wait, the map is 64 wide, but rows have 64 chars; the header trick may be off. Let me just run it.

Also note: my tile grid is 64 wide. But I need to verify reachability. Let me also add a simple physics-based BFS solver in node using the same constants. But first run map.js.

The map looks good. A couple of considerations:

1. Trophy at (41,8) sits on shelf D (row 9, cols 38-43). ✓
2. Gem at (36,10) sits on slab C (row 11 cols 34-37) where enemy B is at (35,10). ✓
3. Gem at (47,16) — inside ground? row 16 is the walkable air row above ground row 17. ✓
4. Gem at (61,16) ✓.
5. Enemy at (8,16) patrols right from col 8; ground below is solid through col 10, then fire at 11-13 → it turns at col 10 edge. It will walk left too, all the way to col 1 (wall at col 0), passing the spawn at col 2. Player must jump over it or time. That's the tutorial enemy — okay, but it will come to the player immediately at start. Let's set enemy start position col 8 with dir = +1, and give patrol bounds so it goes right first. It'll reach fire edge at col 10 then walk left, reaching col 2 in ~1.5s (speed ~1 px/frame → 6 tiles = 192px → 192 frames = 3.2s). Enough time for player to react/jump. Fine. Actually maybe move the first enemy patrol to cols 5-10 so it stays near the fire pit and the player has room. Let's keep spawn at col 2 and enemy start col 8 moving right. The player's immediate instinct is to run right; enemy comes toward them. They can jump over it (20px tall bot, jump 125px). OK.

Alternatively make ledge at cols 6-9 give a safe perch above the first enemy. Nice: player can jump onto the bonus ledge early to escape. Good.

6. Water pit at 22-24: after crossing, land at col 25; slab A at row 15 cols 26-29.
7. Pillar at 18-19 rows 15-16: player must jump over (rise 64) or... The gap between pillar right edge (col 19 → x=640) and water pit start (col 22 → x=704) is cols 20,21 (64px of ground). So they jump over the pillar then must immediately cross the 3-tile water pit. Tight: land at col 20/21 then run and jump. Player can do it — need running start; they can drop in the gap between pillar and pit, then jump across the pit. Gap from col 21 right edge (x=704) to col 25 left (x=800): 96px travel for the left edge; airtime 44 frames * 4 = 176. Easy.

But careful: if the player jumps over the pillar and continues right at max speed, they'd be airborne over cols 20-21 and might overshoot? No, they'd land on ground col 20/21 or possibly fly over the pit (good). Fine.

8. Between shelf D right end (col 43) and the ground: shelf D covers cols 38-43 above fire pit 40-42 + col 43 ground solid. Drop off right end at col 43 → lands on solid ground. ✓

Also: can the player skip the shelf entirely? The main path continues along the ground: after water pit A (22-24) ground continues 25-39, but shelf/ledges are floating slabs; the ground path from col 25 to col 39 is unobstructed (slabs are at rows 15,13,11,9 — high enough to walk under? Player height 32px = 1 tile. Slab A at row 15 → clearance below is row 16 only (ground surface at row 17). So walking under slab A at row 16 is exactly 1 tile clearance: player occupies row 16 (y 512..544) and slab A bottom at y=15*32+32=512. So the player would collide with slab A's underside if they walk under it? The player hitbox top = 512, slab occupies y 480..512. Touching at exactly 512 — no overlap (player AABB y in [512, 544), tile in [480,512)). Border collision: my collision check uses tile range floor(y)..floor(y+h-1)? Let's use standard AABB with tiles: ty0 = floor(y / T), ty1 = floor((y + h - 1)/T). With y=512, h=32 → ty0=16, ty1=16. No overlap with row 15. ✓ So the player can walk under slab A. That means the ground route is open — good, it means the staircase is optional but the trophy requires the shelf route. Perfect: the shelf is the only way to the trophy.

But wait: walking under slabs B/C/D: B at row 13 → plenty of clearance. D at row 9 above fire pit B (40-42): fine.

9. Slab C at row 11 cols 34-37: can the player walk under it? Yes at rows 14-16 free. So the staircase can also be entered from below at various points. Also slab B row 13 cols 30-33 and C row 11 cols 34-37: from ground under slab C, jump up 3 tiles to land on slab C bottom? No—land on top requires rising from y=544 to y=352 = 192px, impossible. So staircase must be climbed A→B→C→D. But is A reachable from the ground? Yes (2 tiles). Good.

Is there an alternate route to D? From ground under D (rows 14-16 free at cols 38-43): jump 6 tiles? No. So staircase only. ✓

10. Also check the drop from D: the player at col 43 walks off and lands on the ground (row 17 top). ✓

11. Then the player crosses fire pit B at cols 40-42? They'd be at col 43 going right; no need. ✓

12. Then water pit B at 50-52, then ground 53-62 with door at 58-59 (rows 15-16 non-solid). Enemy B at row 16 col 55 patrols 53-62. Also gem at 61,16. ✓

One concern: door tiles at rows 15-16 are non-solid; the player walking on the ground (row 17 top, occupying row 16) overlaps the door's lower half → they trigger door check when overlapping. Good, and it's automatic as they walk by. Fine.

Also: with trophy, overlapping the door wins immediately. Good.

Now enemy patrol on slab C (row 11, cols 34-37) — it patrols 4 tiles and the player must land on slab C to climb. The player can wait on slab B and jump over the bot. Good.

Let's also check: the enemy at (46,16) between fire pit B (40-42) and water pit B (50-52): ground cols 43-49 → patrols 43..49. ✓ Gem at col 47. The bot patrols right through the gem — irrelevant.

Now, hazard detection with the player standing near a pit: fire tiles at rows 17-18, tops at y=544 = ground surface. The player walking on the ground at row 16 (y 512..543) — no overlap with row 17 ✓. When they walk off the edge at col 10, they fall into fire → death. ✓

One risk: the player standing at col 10 (ground last solid), hitbox x range must not overlap col 11's fire tile at row 17 — no, since hitbox is in rows 16 only.

Now let me also double check that jumping from ground at col 10 over fire (11-13) to land at col 14: distance from x=320 to x=448 for the left edge. With run speed 4 and airtime 44 → 176px ✓.

Great. Now the physics-based solver check. I'll write a node script that shares constants + collision, does BFS over states (x,y,vx,vy,grounded) with discrete control options (jump at fixed intervals with 3 horizontal inputs). This can be heavy. Simpler: check reachability of key waypoint tiles with analytic checks (already done). I'd rather spend remaining time on the game itself, then do a quick autopilot simulation as verification: scripted inputs sequence (hold right, tap jump at specific frames). That's brittle.

Best verification: after building index.html, run it in the browser, and use a small in-page test hook: expose `window.__test` with functions like `step(inputs)` to run physics headlessly, and a solver? Actually I can implement in the game a debug reachability BFS (dev-only, guarded) — but including it in the shipped file adds noise. Alternative: in node, extract the game script from index.html with a regex and run it with stubbed canvas/document? Too brittle.

Middle ground: write dev/physics.js duplicating my tile collision + player physics (copy ~40 lines) and run a proper BFS/simulation to verify (a) landing works, (b) jump clears fire pit, (c) staircase reachable, (d) a full auto-run to the door with trophy is possible using a scripted/greedy AI. Then I keep the game code's physics identical. Risk: divergence between the two copies. Acceptable for verification; I'll note that.

Actually a neat approach: implement the physics in the game file inside a function that's exported to `window.__GAME`. Then in node, I can read index.html, strip the script, and eval it with a fake DOM stub. Many drawing calls would break. Could stub canvas context with a no-op proxy (all methods no-op, properties settable). That's actually easy:

```js
const ctxStub = new Proxy({}, {get:(t,p)=> (p==='canvas'?canvasObj : (...args)=>undefined), set:()=>true});
```
Hmm, need to handle property reads/writes and returning functions. And document.getElementById returns an object with getContext → stub, addEventListener noop, style {}, width/height. requestAnimationFrame → noop (so the loop doesn't run). Then window/document globals defined. Then I can call the exposed game functions like `simulate`. But my game code's reset() might reference things. Risky but potentially fine. Time cost maybe 5-8 min out of 15.

Decision: prioritize building and browser-verifying. Then, if time remains, do the greedy-AI check in the browser itself by injecting a test script through the browser tool? The browser tool only supports click/key/type/screenshot — I can't evaluate arbitrary JS. Hmm, no evaluate action. So headless checks must be in node.

Alternative pragmatic verification in-browser: use `key`/`type` actions to send keys and take screenshots. Typing text into the page — the `type` action types text into focused element; keyboard events would go to document. I can send arrow/space keys via `key` action presumably ("ArrowRight", "Space"). Then screenshots show the player moved/jumped. That covers the required "Verify" step: movement + jump near start, landing on solid surface, trophy and exit visible (I can check via screenshot after moving camera... trophy is far right, needs scrolling. I could temporarily spawn the camera or move the player via key presses held for a while — but each key press is one event; holding requires repeat... the `key` action may send a single keydown+keyup. So the player would move ~a few px.

Better approach for verification screenshots: add a dev URL param or a hidden debug function to teleport the player, e.g. `?debug=trophy` sets spawn near the shelf, or expose `window.warp(x,y)` in the game (small, harmless — I could include it as a dev helper). Adding a `window.__dave` API exposing state + warp is fine and helps me verify visually. I'll expose a minimal debug API: `__dave.warp(tx,ty)`, `__dave.grant()`, `__dave.state()`. Justifiable? It's extra code not requested but harmless. Keep it tiny and documented as "debug hooks". Hmm, the reviewer might not like debug hooks; but they help verification and don't affect gameplay. I'll include a small one, clearly marked. Actually I can avoid polluting: use it for verification, then... no, keep it — it's genuinely useful and I'll label it as dev/debug hooks.

Alternatively, take a screenshot of the whole level by... no, canvas is viewport-sized.

I'll include `window.__dave` debug API (warp, giveTrophy, setKeys) so I can drive the game headlessly-ish and also verify. `setKeys` lets me simulate held inputs for scripted tests — great, then I can even run an autoplay in-browser? No eval though. Hmm, but with key actions only single press/release. The `type` action sends characters... it can produce keydown/keyup per char probably briefly.

OK: with `__dave.hold('right', true)` I can't call it without eval. So the debug API is only reachable if I can run JS. The browser tool has no evaluate. Hmm.

So node-side harness is the way for scripted physics tests. Let me do this: structure the game so the simulation core is DOM-free and testable:
- Put the game logic in a script that, at the end, checks `if (typeof module !== 'undefined') module.exports = { ... }`? In the browser that line is harmless (module undefined). And in node I can extract the script text from index.html and eval it with `module` defined... but the DOM code runs at load (canvas init). Solution: wrap DOM/canvas setup inside an `init()` function called only when `typeof document !== 'undefined' && document.getElementById('game')` — for node harness, define `document` as undefined. So:

```js
const CORE = { MAP, TILE, constants, makeWorld(), stepPlayer(...), collide(...) };
if (typeof window === 'undefined') { /* node harness */ globalThis.__CORE = CORE; } else { boot(); }
```
That's clean: `if (typeof window !== 'undefined') boot(); else { /* headless test target */ }` — the file ends up with a guard. Nice, and the dev script can require/eval index.html's script content and run a physics BFS to verify reachability, then delete or keep the dev folder.

I'll do that: game file has `const DAVE = { ...pure sim... }` and at the bottom `if (typeof document !== 'undefined') startGame();`. For node, I stub: read index.html, extract <script> content, run in a vm with no document/window → then call the pure sim. Drawing functions are defined but never called. As long as top-level code doesn't touch document/canvas. So I must be careful: all DOM access inside startGame().

Then the node verification: implement a greedy/AI search using the pure functions:
- `simStep(world, player, input)` returns new player state (pure-ish, mutate copies).
BFS: states = quantized (x,y,vx,vy,grounded)? Let's do forward simulation with input options per jump: from a grounded state, try each combination of horizontal direction (left/right/none) held for the whole jump plus initial jump, walk arcs until landing or death (or 120 frames). Add reachable landing states to a queue, plus walking (ground traversal) as BFS edges: from a standing tile, walk left/right along the surface until blocked/falling; if falling, simulate the fall until landing (no jump) or death. This is a classic platformer reachability solver and it's enough for this level since jumps can be considered at any grounded position. Also need "jump while moving" (handled), plus mid-air jumps not allowed.

Let me write it as: `reach` set of states keyed by rounded x (1px?) Let's key by tile x and tile y (surface) — coarse but okay; the takeoff position matters for gaps. Use sub-tile positions in half-tile increments (16px) and consider jumps launched from any x along the walkable surface, direction ∈ {-1,0,1} and speed at launch = full run speed in the direction or 0. Simulate 60 frames of physics with the real collide function. Then from each landing, continue.

This is a decent verification: check that the trophy tile and door tile are in the reachable set, and that the route from spawn exists. I'll spend ~4 minutes on it. Worth it for "Keep the level's route physically reachable."

Time check: I've used ~2 min. Let's write index.html now (the bulk).

Code plan (single file):

```html
<!doctype html>
<html><head><meta charset><meta viewport><title>Dave's Dungeon — Episode 1</title><style>...</style></head>
<body>
 <main class="frame">
  <header class="titlebar">
    <h1>DAVE'S DUNGEON <span>EPISODE 1 · THE FIRE &amp; WATER VAULTS</span></h1>
    <div class="stats"> score / gems / trophy / time </div>
  </header>
  <div class="stage">
    <canvas id="game" width="960" height="608"></canvas>
  </div>
  <div class="panel">
    <div class="keys"> ... </div>
    <button id="btnRestart">RESTART (R)</button>
    <button id="btnSound">SOUND: ON</button>
  </div>
  <div class="msg" id="msg">OBJECTIVE: ...</div>
 </main>
 <script>...</script>
</body></html>
```

CSS: dark page bg (#0b0b16), neon retro title, canvas with pixelated rendering and border glow, key caps styled like keyboard keys, HUD text with monospace font (system fonts only: ui-monospace, "Courier New", monospace). No external fonts.

JS structure:

1. Constants + MAP.
2. Pure sim core: parseMap → {tiles (2D array), w, h, solids, hazards, items, enemies, spawn, door}.
3. Player physics: `stepWorld(world, dt)`, `collideRect`, `tryMove`.
4. Rendering functions.
5. Game loop, input, HUD updates, overlays.
6. Guarded boot.

Let me write the physics carefully.

```js
const TILE=32, GRAV=0.5, JUMP_V=11.2, RUN=4, MAX_FALL=12;
function solidAt(W, tx, ty){
  if (tx<0||ty<0||tx>=W.w||ty>=W.h) return tx<0||ty>=W.w||ty>=W.h ? true : false; 
```
Hmm: out of bounds: treat outside horizontally and below as solid so entities can't escape; above (ty<0) as non-solid (open sky). Let's implement:
```js
function tileAt(W,tx,ty){ if(tx<0||tx>=W.w||ty>=W.h) return '#'; if(ty<0) return '.'; return W.grid[ty][tx]; }
function isSolid(W,tx,ty){ const c=tileAt(W,tx,ty); return c==='#'||c==='='; }
```
Wait ty<0 → '.' (not solid) via first check? tx in range and ty<0: returns grid index negative → I handle `if (ty<0) return '.'` before. Order: check tx out of range → '#'; check ty>=h → '#'; check ty<0 → '.'.

Player move:
```js
function moveX(W,p,dx){
  p.x += dx;
  const dir = Math.sign(dx);
  if (dir!==0){
    const top = Math.floor(p.y/TILE), bot = Math.floor((p.y+p.h-1)/TILE);
    const col = dir>0 ? Math.floor((p.x+p.w-1)/TILE) : Math.floor(p.x/TILE);
    for(let ty=top;ty<=bot;ty++) if(isSolid(W,col,ty)){
       p.x = dir>0 ? col*TILE - p.w : (col+1)*TILE;
       p.hitWall = true; p.vx = 0; break;
    }
  }
}
```
Also for horizontal movement with |dx|<1 steps? We move up to 4px per step, fine. But if the player is pressed against a wall, we do p.x += 0 → skip.

Careful with the "wall snapping" when p.w=22 and tile=32: standing on ground next to a wall, the check col uses p.x+p.w-1 → fine.

moveY:
```js
function moveY(W,p,dy){
  p.y += dy;
  const dir = Math.sign(dy);
  if(dir!==0){
    const left=Math.floor(p.x/TILE), right=Math.floor((p.x+p.w-1)/TILE);
    const row = dir>0 ? Math.floor((p.y+p.h-1)/TILE) : Math.floor(p.y/TILE);
    for(let tx=left;tx<=right;tx++) if(isSolid(W,tx,row)){
      if(dir>0){ p.y = row*TILE - p.h; p.vy=0; p.grounded=true; }
      else { p.y = (row+1)*TILE; p.vy=0; }
      p.hitCeil = dir<0; break;
    }
  }
}
```
Since dy can be up to 12 (<TILE), single-step is fine.

Per-frame player update:
```js
function stepPlayer(W,p,in_){
  const dir = (in_.right?1:0)-(in_.left?1:0);
  if(dir!==0){ p.vx += (dir*RUN - p.vx)*0.35; p.face=dir; } else { p.vx *= 0.72; if(Math.abs(p.vx)<0.12) p.vx=0; }
  p.grounded=false;   // recompute
  if(in_.jump && p.groundedPrev) { p.vy=-JUMP_V; }
```
Hmm ordering: jump check must use grounded from previous frame's collision. Let me structure the frame:
1. read input; if jump held && p.grounded → vy = -JUMP, grounded=false, spawn dust, sound.
2. vx from input.
3. vy += GRAV, clamp MAX_FALL.
4. moveX; moveY (set grounded).
Then hazards.

When jumping we set vy negative; gravity applies same frame — standard.

Also add variable jump height (release space early → cut)? Not required; skip for simplicity but nice: if !in_.jump && vy<0 → vy += GRAV extra. Let's include (feels good, doesn't violate "only while grounded").

Enemy update:
```js
function stepEnemy(W,e){
  e.x += e.dir*e.speed;
  // check wall ahead
  const aheadCol = e.dir>0 ? Math.floor((e.x+e.w-1+2)/TILE) : Math.floor((e.x-2)/TILE);
  const footRow = Math.floor((e.y+e.h+2)/TILE);
  const bodyRow = Math.floor((e.y+e.h/2)/TILE);
  if(isSolid(W,aheadCol,bodyRow) || !isSolid(W,aheadCol,footRow)) { e.dir*=-1; e.x += e.dir*e.speed*2; }
  e.anim+=e.speed;
}
```
Careful: floor((e.y+e.h+2)/TILE) when standing on ground: e.y+e.h = surface y (e.g., 544) → +2 = 546 → row 17 → solid ✓.

Also patrol bounds: if the enemy's platform extends further, it patrols the whole span. Fine.

Hazard/death checks: iterate tiles overlapping player AABB (using hitbox) and check for '^'/'~'.

Fire vs water distinction for message.

Enemy AABB overlap check.

Item pickup: gems (circle distance) → score; trophy → hasTrophy (removes trophy from world? Spec: "Restart restores the level, trophy..." — so on pickup it's gone until restart; keep a flag `taken`).

Door check: player AABB overlaps door rect → if hasTrophy → win; else toast + shake (rate-limited every ~1.2s but keep message visible while touching).

Now render code. Let me write it.

```js
function draw(){
 // bg
 drawBack(ctx,cam)
 // tiles
 const x0=Math.floor(cam.x/TILE), x1=Math.min(W.w-1, x0+31);
 for ty 0..18 for tx x0..x1: drawTile(...)
 // items (gem, trophy)
 // door
 // enemies
 // player
 // particles
 // fire/water glow overlay? included in drawTile with additive
 // toast text
 // HUD-ish overlays (win/lose)
}
```

Back pattern: brick wall in dark tones with parallax 0.5, plus 4 torches at fixed world positions on the back wall, drawn with flicker, plus glow gradient.

Tiles:
- '#': brick: base #7a3b2b? Let me use two variants based on (tx+ty)%2 for color noise. Draw: fillRect base, then mortar lines: horizontal line at top+1 and mid, vertical offset brick joints. Top cap: if tile above not solid → draw highlight strip #c07a52 (2px) and a slight bevel.
- '=': metal/stone slab: base #6d7688, bevel top #aeb8cc, bottom dark #3a4052, rivets (4 small squares).
- '^' fire: pit tiles: draw the tile as a pit: dark base #2a0a06, magma gradient, flames drawn with animated polygons + flicker, glow.
- '~' water: dark base #06182e, wave surface: if tile above is not water (top row of water), draw wavy highlight lines; body with lighter blue bands.

Since fire/water occupy rows 17-18 with ground to their sides, the "pit" appearance works: hole with hazard at bottom. Actually the top of the hazard is flush with the ground surface, making it look like a hazard band in the floor rather than a pit. To look like a pit, I could draw the top row of hazard tiles as an open hole: dark void at the top 12px, water/fire lower. Simpler: draw hazard tiles as full tiles (lava/water surface flush with the floor — like Dave's lava pools). That reads fine: lava pool in the floor, water pool in the floor. I'll draw the water surface at ~6px below the tile top with a dark "hole" band above it for depth. For fire, flames rise above the tile so it's clearly readable, plus a dark rim.

Tooltips/labels: draw small text labels "EXIT" above the door and "TROPHY" sparkle? The requirement: "trophy and exit are visibly identifiable" — draw a floating sign/arrow above both with labels. Yes: above the shelf, a small arrow + "TROPHY" label; above the door "EXIT" (and "LOCKED" when no trophy). Labels in-world help. I'll add them subtly (they also confirm reachability visually).

Win overlay: dark veil, "LEVEL COMPLETE!" big, stats (time, gems, score), "Press R or click RESTART".
Lose overlay: "GAME OVER", reason, same.
Play state: HUD at top of canvas? I'll draw a compact in-canvas HUD: score, gems x/6, trophy icon (dim/lit), timer, plus status toast. And HTML panel below with the controls & restart.

Let me write the code now. I'll be thorough but efficient.

Sound: WebAudio, small helper. Include mute toggle. Keep short:

```js
let actx=null, soundOn=true;
function sfx(type){ if(!soundOn) return; try{ actx = actx||new (window.AudioContext||window.webkitAudioContext)(); ... }catch(e){} }
```
Sounds: jump (square 330→520 short), land (noise thud), gem (triangle 880→1320), trophy (arpeggio), locked (square 160 buzz), die (saw 300→60), win (arpeggio up).

Implementation: `tone(freq, dur, type, gain, slideTo)`.

Now writing the file. Also need fixed timestep loop:

```js
let last=0, acc=0;
function frame(t){ ... acc += min(0.05,(t-last)/1000); while(acc>=STEP){ update(); acc-=STEP; } draw(); raf(frame) }
```
STEP = 1/60.

Input: keydown/keyup listeners; keys map ArrowLeft/a/KeyA etc. Use e.code where possible: 'ArrowLeft','KeyA','ArrowRight','KeyD','Space','KeyR','Enter'. preventDefault for Space/arrows to avoid page scroll.

Death/win transitions: state 'play' | 'dying' | 'dead' | 'winning' | 'won'.

Restart: `world = makeWorld(); player = ...; reset entities; state='play'; score=0; gems=0; hasTrophy=false; time=0; toast('GO!')`.

Let me now write everything into index.html.

Sprite matrices — write and validate lengths in node after.

Player frames: idle, walk1, walk2, jump. I'll define `BODY` rows 0..11 shared and legs variants for rows 12..15.

BODY (12 wide, 12 rows):
```
"....6666...."
"...666666..."
"...222222..."
"...212212..."
"...222222..."
"....2222...."
"..33333333.."
".3333333333."
".3233333323."
".3233333323."
"..33333333.."
"....4444...."
```
LEGS_IDLE (4 rows):
```
"....4444...."
"...44..44..."
"...55..55..."
"..555..555.."
```
LEGS_W1:
```
"....4444...."
"...444..4..."
"..44....44.."
"..555....5.."
```
Hmm keep simple: W1 and W2 mirror-ish strides:
```
W1: "....4444...."
    "...444..4..."   → 3+3+2+1+3 = 12 ✓
    "..44....44.."   → 2+2+4+2+2 = 12 ✓
    ".555....555."   → 1+3+4+3+1 = 15 ✗ → ".55.....55.." = 1+2+5+2+2=12 ✓
```
Let me finalize:
W1:
```
"....4444...."
"...444..4..."
"..44....44.."
".55.....55.."
```
W2:
```
"....4444...."
"...4..444..."
"..44....44.."
"..55.....55."
```
count "...4..444..." = 3+1+2+3+3 = 12 ✓; "..44....44.." ✓ (2+2+4+2+2=12); "..55.....55." = 2+2+5+2+1 = 12 ✓; ".55.....55.." = 1+2+5+2+2 = 12 ✓.

JUMP legs:
```
"....4444...."
"....4444...."
"...44..44..."
"..555..555.."
```
✓

Enemy 14x10 (validated counts):
```
"......11......"
"......11......"
"..1111111111.."
"..1888888881.."
"..1166116611.."
"..1888888881.."
"..1111111111.."
"..1444444441.."
"..1414141414.."
".111111111111."
```
Counts: 6+2+6=14 ✓; 2+10+2=14 ✓; inner "1888888881"=10 ✓; "1166116611"=10 ✓; "1444444441"=10 ✓; "1414141414"=10 ✓; 1+12+1=14 ✓.
Frame B treads: "..1141414141.." hmm: "1141414141" = 10 ✓.

Enemy colors: 1 = #10121c outline, 8 = #98a3b3 steel, 6 = #ff3b30 eye, 4 = #2b2f3d tread.

I'll also add a steel highlight row? fine.

Gem: path-drawn diamond.

Now the code. Let me write it all out.

For the door drawing (2x2 tiles at 58,15 → world rect x=58*32=1856, y=480, w=64,h=64):
- Stone frame around it: rects
- Wooden door with arch top, iron bands, dark window
- When unlocked: glowing light beam from inside + green arrow; when locked: red chain/keyhole + "LOCKED" label.

Win animation: on win, set state 'winning' for 45 frames: door flash white + particles, then 'won'.

Death animation: 'dying' 40 frames: particles + screen flash + shake, then 'dead'.

Screen shake: apply ctx.translate offset during draw for a few frames.

HUD drawn in canvas top-left: score, gems, time, trophy icon; controls reminder bottom-left in canvas? The HTML panel shows the controls; also draw at canvas bottom: "←/→ or A/D MOVE   SPACE JUMP   R RESTART". Good — "Display the controls" is satisfied twice.

Now write. Also handle canvas CSS scaling with aspect ratio, `image-rendering: pixelated`.

Let me write the whole file.

Also: objective HUD text updates: "Grab the TROPHY!" → "Now reach the EXIT!".

Toast system: `toast(text, ms, color)` displayed centered at top area of canvas with fade. Door lock message: also set `doorWarn=1` for shake.

Let me write out the code now in one go, then validate with node (syntax + matrices) and browser.

Regarding the `typeof document` guard for headless testing: I'll write:

```js
const SIM = { TILE, GRAV, JUMP_V, RUN, MAP, makeWorld, moveX, moveY, stepPlayer, stepEnemy, hazardAt, overlaps, ... };
if (typeof document === 'undefined') { globalThis.SIM = SIM; }  // headless test hook
else { boot(); }
```
Hmm, in a browser `globalThis.SIM` also assigned harmlessly. I'll do: assign SIM to window always (useful), and only boot when document exists.

In node harness: `vm.runInNewContext(scriptSrc, sandbox)` where sandbox has globalThis? Use a context object with `globalThis` self-reference... In vm, `global` inside context refers to the sandbox object; `globalThis.SIM = SIM` works in a fresh vm context. So: read index.html, extract script between `<script>` and `</script>` (the last one), run in vm context with globals: Math, console, etc. (vm provides standard built-ins). `typeof document` → 'undefined' ✓ (no document in sandbox). Then `ctx.SIM`.

But the game code references `window` inside boot only, and maybe at top level for `performance.now()` — keep those inside functions/boot.

Let me now write the game.

One more thing: the sim functions take a world object; makeWorld() returns fresh state from MAP. stepPlayer(world, input) uses world.player. Good for harness: simulate inputs frame by frame.

For BFS solver: states = {x,y,vx,vy,grounded} cloned. Let me write solver:

```js
const {SIM}=...
const W = SIM.makeWorld();
function clone(p){return {...p};}
function landState(p){return {x:Math.round(p.x), y:Math.round(p.y)};}
queue of grounded states; visited set keyed by quantized x (to 4px) and y.
For each state:
  - simulate "walk" with dir=+1/-1 and no jump for 400 frames: each frame record any new grounded states (so we capture walking and falling onto lower platforms). Stop after 400 frames (dead or stuck).
  - simulate jumps: dir ∈ {-1,0,1} for the whole airtime, jump at frame 0: run stepWorld with input {dir, jump held at frame 0 only} up to 90 frames, record all grounded states; stop on death.
```
Because walking is simulated as part of the same step function with dir held, we get edges naturally.

Death detection: hazard overlap or enemy — ignore enemies for reachability (they move, so timing dodges are possible; treat as avoidable).

Then check: is there a reachable state adjacent to the trophy (overlap trophy rect) and a reachable state overlapping the door? Compute by checking during simulation whether the player AABB overlaps the trophy cell/rect or the door rect. Record flags reachedTrophy, reachedDoor, and also "door with trophy" — need the ability to carry trophy; approximate by: after reaching the trophy, continue search from that state (BFS from the trophy state) and check door reachability. Simple approach: run BFS once collecting all reachable states; check that some state overlaps trophy and some state overlaps door AND the door state is reachable from a trophy state. To keep it simple: BFS from spawn (all reachable states set R), then BFS from the trophy state(s) (set R2) and check door overlap in R2. Path back-tracking not needed. Good enough.

Number of states: quantize to 4px x, and y quantize to 1px? Positions: level 2048 wide → 512 x-slots per y-level; y-levels ~ several. Fine.

Let me write these scripts after index.html.

Also for jump: the max rise matters for head-bonk with slabs; the sim handles it.

OK writing index.html now.

I need to fix a bug: in update() I have a stray line `const target = Math.max(0, Math.min(W.w * TILE - VIEW_W, p => 0));` — that's invalid JS (arrow function inside Math.min is actually valid syntax as an expression? `p => 0` is an arrow function, valid expression, so Math.min with a function → NaN, harmless but ugly). Remove it.

Also drawPlayer: `mat(m, x, y, 2, p.face > 0)` — face>0 means right; my matrices face right by default? The matrix is symmetric-ish except eyes; flipping when facing right is wrong. Let's flip when face<0 (facing left). Actually the sprite is nearly symmetric, so either way. Set flip = p.face < 0.

Also enemy sprite mat position: `mat(f, x, y - 20 + e.h - 20, 2, e.dir > 0)` — with e.h=20, that's y-20 → sprite 28x20 drawn from y-20 to y; but enemy top should be at e.y. Bot matrix is 10 rows × 2 = 20px tall, so it should be drawn at (x, e.y). Fix to `mat(f, x - 1, y, 2, e.dir < 0)`.

Also makeWorld enemy y: `y * TILE + (TILE - 20)` → for B at row 10, y = 10*32+12 = 332; slab C at row 11 top = 352; enemy bottom = 332+20 = 352 ✓ standing on slab.

Player spawn: `y*TILE + (TILE-PH)` = 16*32 + 0 = 512, PH=32 → bottom = 544 = ground top ✓.

Also `msgColor` declared with `let` after use in toast — hoisting: `let msgColor` is in TDZ but resetGame() runs after full script evaluation (boot at end), so fine.

Also the trophy hit test: `{x: T.x-2, y:T.y, w:28, h:30}` fine.

Also drawTrophy pedestal at y+26 etc. Fine.

Also text 'EXIT LOCKED' etc.

Also `hazardAt(W, p.x+2, p.y+2, p.x+p.w-2, p.y+p.h)` — fine.

Also in update, `p` is defined inside the if-block; at the end I used `world.player.x` for camera, good. Remove reference to `p` outside scope: camera line uses `world.player`. OK.

Also `draw()` uses `W.player.x` fine.

Also `text()` uses ctx.font — fine.

Also the syncHud during resetGame: hud elements exist only after boot; resetGame() is called inside boot after hud assigned ✓. But resetGame is also called from key handler (fine) and from node harness? Node harness doesn't call resetGame.

Also: DAVE export — in browser, `window.DAVE` set. In node vm sandbox, need to expose. In the vm, top-level `const DAVE` won't attach to the sandbox global (const in script scope of vm → actually top-level const/let in a vm script go to the script's lexical scope, not global object, but accessible via runInContext later in same context? Each runInContext call has separate lexical scope). Simplest: add `globalThis.DAVE = DAVE;`? Hmm, `var`-less. I can append at the end: `if (typeof globalThis !== 'undefined') globalThis.__DAVE__ = { makeWorld, stepPlayer, stepEnemy, hazardAt, hitRect, TILE, GRAV, JUMP_V, RUN, PW, PH, MAP };` That's fine and also useful.

Also guard boot: `if (typeof document !== 'undefined' && document.getElementById('game')) boot();` — needed since node vm has no document. But the script references `document` only inside functions except that guard. `addEventListener` only in boot ✓. `requestAnimationFrame` only in loop ✓.

Let me also verify: `drawPlayer` save/restore: when mode is winning, I `ctx.save()` and set globalAlpha, then draw, then restore in the branch — but the shadow rect drawn before save? Let me re-check the code: I save at top, and restore at the end only in winning/won mode. But if mode is 'dying' and blink returns early — no save happened (return before save? No: the save occurs after those checks? Order: if dying blink return; if winning/won { save; globalAlpha } — yes save happens after returns. And restore at end for winning/won ✓. Balanced.

Now fix the identified issues with edits, then create the dev reachability test, then browser-verify.

Let me make the edits.

Now remove the old trailing guard lines (`if (typeof document !== 'undefined') boot(); else ... globalThis.DAVE`) — duplicate. Let me check the tail and fix, then run the reachability test in node.

Use node: it only exists as a global in vm contexts.

Then simulate a player: I'll write a solver that:
- states: (x,y,vx,vy,grounded) quantized.
- BFS with actions: from a grounded state: (a) walk left/right with no jump for N frames recording new grounded states, (b) jump with dir ∈ {-1,0,1} held for up to 120 frames recording grounded landings, stop on hazard.

Implementation with __DAVE__ functions: create world W (single world object, reuse by setting player state). stepPlayer mutates W.player and reads input. Hazard check via hazardAt.

Let me write it compactly.

Key detail: stepPlayer uses `inp.jump && p.grounded` — jump requires grounded, good. To simulate a jump launched at a state, set jump true for frame 1 then false (or hold — holding would re-jump on landing; for arc simulation, hold jump only for the first frame then release; but variable height cut applies when released... My physics: if !jump && vy < -3 → extra gravity. So releasing immediately shortens the jump. To get max height, hold jump for the whole ascent. Let me simulate 2 variants: hold-jump (full) and release after 12 frames (short hop). Simpler: always hold jump during the airtime until landing (which then re-jumps on landing—fine, it's a "bunny hop" chain, which is a legitimate move too, but for BFS landing states I want discrete landings). I'll record a state each time it becomes grounded during the arc (with jump then released...). Let me implement: for jump actions, set jump=true for the first 30 frames then false; record state on every grounded frame (and stop simulating that branch once grounded after airborne).

Let's code it.

Problem: reaching the door is checked from spawn-BFS which doesn't require passing the trophy, but the level's linear structure means the door is beyond the trophy shelf anyway; if door reachable AND trophy reachable, likely fine. But to be rigorous, I should check door reachable from a state after trophy. Since the trophy is on the shelf which is on the only route... actually the ground route bypasses the shelf, so the door might be reachable without the trophy (that's intended — you can reach the exit but it's locked). The key requirement is that a full win route exists: trophy AND door reachable in sequence. Because the trophy shelf is reachable and after collecting you can drop back to the ground and continue right (the ground route is continuous), a win route exists if (a) trophy reachable from spawn, (b) door reachable from spawn without crossing hazards, and (c) the ground path from the shelf-drop to the door exists. I'll additionally run a BFS seeded at a trophy-contact state and check the door. Let me modify: when out.trophy, capture a state where the player overlaps the trophy, then run a second BFS from those states to the door.

Time is short (~6 min for the whole job... I've used maybe 12 min wall? The reminder said 5 minutes remain). Let me just run this and check results quickly; if it prints trophy reachable and door reachable, that's good enough combined with structure reasoning.

Also `vm.runInNewContext` — the script contains `const` at top level; `box.__DAVE__` assignment via `globalThis.__DAVE__` → globalThis in the vm context = box ✓. But `const MAP` etc. are in lexical scope; the assignment expression references them in the same script ✓.

Let's run.

Trophy NOT reachable per the BFS. That's a real problem — must fix. Likely the staircase jump A→B→C→D fails because of head-bonk on the slab above, or the ledges are too far apart. Let me debug: find the maximum x reachable. Let me print the reachable states' coverage (max x, and whether slab A/B/C tops are reached).

Quick analysis: Slab A row 15 cols 26-29 (top y=480), B row 13 cols 30-33 (top 416), C row 11 (top 352), D row 9 (top 288).

Jump from A top (feet 480) to B (feet 416): rise 64, and B's left edge x=960 (col 30). A spans cols 26-29 → x 832..960. Player standing on A at right edge: p.x max = 960-22 = 938. Jumping from there: to land on B, need p.x ≥ 960-... any x with feet above 416. The problem: while ascending from A, the player's head/body may hit B's underside? B occupies y 416..448 at cols 30-33. Player at x 938..960 (body width 22 → spans 938..960) overlaps col 29 only (928..960)? col 29 = x 928..959, and x=960 exactly is col 30 boundary; p.x+p.w-1 = 959 → col 29. So no overlap with B. Rising to feet y=416 requires horizontal move to col 30+ → at feet 448 the player is beside B? B's rows 13 (416-447). If the player rises while at x 938, feet go from 480 to 416-... at feet=448, body occupies 448..479 (row 14), no overlap with B (row 13) ✓. Then moving right, at feet 416 they collide with row 13? MoveX at feet 416: body occupies 416..447 → row 13 → B solid at col 30 → bump. Hmm: to land on B, the player's feet must be above 416 (i.e., y ≤ 415) when passing over col 30. Rise of 65px needed from 480 — max rise 125 ✓ so that's OK in principle.

But wait, maybe the issue is my physics: with `!inp.jump && vy < -3 → vy += GRAV*1.6` and fullJump hold for first 26 frames — that's fine.

Maybe the real blocker: the walk-off-A states. My BFS holds a fixed direction for the whole 130 frames, which prevents "walk right for 5 frames, then jump" — no, the jump action starts immediately at the state. Since states include positions along the walk (walk sim records every grounded frame state? No — `push(st)` only for grounded states in `out`, and out includes every frame's snap, so all grounded positions along the walk get pushed ✓). So jumping from any position on A is available.

Hmm, but the jump action starts from a grounded state with jump held for 26 frames ✓.

So why unreachable? Maybe the head-bonk: when jumping from A (feet 480, body 480..511... wait body top = y = 480, bottom = 511 → occupies rows 15,16 → A occupies row 15! Contradiction: standing on top of A means feet at A's top = 15*32 = 480, so body spans y 448..479 (rows 14). Yes y=448 with h=32. I conflated: p.y is the TOP. feet = p.y + p.h.

So on A: p.y = 448. Jumping: rise to p.y = 448-125 = 323. To land on B, need p.y+p.h ≤ 416 → p.y ≤ 384 ✓ easily. Horizontal: from x≈938 to ≥960 while above 384... but here's the issue: while ascending at x 938 (body rows 14,13 at start), the head hits B? B is row 13 cols 30-33; the player at x 938-959 is col 29, no. Then moving right at head y in rows 13/14... at feet above 416 (p.y ≤ 384, body 384..415 = row 12) then moveX: col = 30 → isSolid(30,12)? row 12 is '.' → no collision; continue; when descending onto B, moveY hits row 13 ✓ lands.

So it should work. Unless... the BFS `simulate` uses `give(s)` which sets p.grounded = s.grounded, and `p.grounded=false; moveX; moveY` — hmm in stepPlayer, grounded is reset to false then set by moveY. Jump check happens before ✓.

Maybe the issue is that reaching A itself fails! A is at row 15 cols 26-29, but the water pit at cols 22-24 → the player lands at col 25 ground... then must jump 64px onto A. From the ground, p.y=512; jump apex p.y=387; needs p.y ≤ 448 while over A's columns ✓.

Let me debug quickly by printing reachable states' coverage: which tiles are stood on (occupying row above solid). Then I'll see where the chain breaks.