Wolfenstein raycaster · hy4

We need build single self-contained index.html, run browser inspect initial output/console, brief checks movement collision fire restart etc. Need implement solid game robustly. Need understand browser tool likely can inspect DOM/console/screenshot/click/key/motion. Need design and maybe expose debug state/window for testing. We should create polished raycaster.

Need think through requirements and implementation carefully. Let's design.

Canvas likely 960x600 or responsive internal 960x600. CSS full page dark, HUD overlay, controls display, restart button. Canvas raycaster with procedural textures, enemies as sprites, weapon, muzzle flash, HUD perhaps DOM. Need game state. Need pointer lock optional perhaps avoid mouse required; could implement mouse movement on canvas with pointer lock but not necessary. Maybe optional mouse turn via pointer lock on click? But click can conflict shooting. Simplest no mouse turning; use arrow keys. Could add mouse drag to turn optional, but not required. Need controls shown.

Maze small grid, reachable exit, at least three enemies. We need choose map ensuring start area, nearby wall for collision, enemy visibility maybe initial view. Need ensure exit reachable and locked until all enemies defeated. Need enemy occlusion and shots can't through wall. Need clear attack rule. Could make stationary enemies that shoot when player within e.g. 5 tiles, line of sight, and cooldown, with visible laser/projectile? Clear rule displayed: "Enemies fire when they can see you within 5 tiles (every 1.2s)." Need player movement and collisions. Could also chase. Need enemies visible via sprites rendered with z-buffer based on distance and wall occlusion. Need shots ray hit detection with walls first and enemy intersection, perhaps also choose nearest enemy and verify no wall with DDA / line sampling; hitscan crosshair. Need weapon feedback: recoil, flash, audio? No external; can use WebAudio oscillator generated sounds optionally after user gesture. Visual muzzle flash and message/hit marker, enemy flash/damage/death. Need inspect via screenshots. Need perhaps expose game state (window.__game) for browser checks. We can leverage browser inspect maybe DOM text, perhaps no JS execution tool but browser inspect returns DOM/console? Need see tool behavior. We can use browser actions with key to simulate. Maybe use screenshot images output attached visually. Need perhaps query DOM via inspect? likely browser "inspect" gives DOM/console maybe enough. We can expose status element with coordinates/angle etc for testing. Could build hidden debug output or visible telemetry. Need use screenshot to sample stable wall rendering perhaps browser screenshots. Could use canvas pixel sampling via DOM? No arbitrary JS exec tool listed except browser inspect maybe can inspect DOM. Could add debug state to HUD status text perhaps show position, angle, enemies, health, status; helpful verifying via DOM/text. Could also include data attributes on root updated. We can evaluate via browser inspect maybe there is a JS eval? Let's inspect docs? No need pi docs (not asked). We can use browser tool after making file.

Let's plan game architecture.

Canvas internal dimensions maybe 960x600. CSS scales responsive with max width, fixed aspect. Use canvas width=960 height=600. World view raycasting: for each x column (maybe 480 columns at 2px for speed) cast ray using DDA. Use FOV 66° (π/3). Wall projection height = H / perpDist maybe `lineHeight = H / perpDist` with wall height 1.0; perhaps projection plane `H*0.85/perpDist`, horizon H/2. Need textured vertical strip. Generate procedural texture data arrays of size 64x64 RGBA or Uint32Array. Could use ImageData on offscreen canvas? We can draw pixel with per-texture-height sample into `ImageData` buffer (canvas ImageData at render resolution) then overlay sprites/weapon via canvas draw calls. Or draw 1px-wide vertical strips with Canvas 2D using an offscreen texture canvas and `drawImage(texCanvas, texX,0,1,64, x,drawStart,columnWidth,lineHeight)` with shading via fillRect overlay. This gives textured walls with perspective correction. Need floor/ceiling perhaps procedural gradient and maybe checker floor via simple horizon gradient or per-pixel floorcasting. Requirement textured grid maze; walls textured enough. Could add floor/ceiling gradient and grid lines via floorcasting maybe visually better. Could use a pre-rendered floor/ceiling background gradient with horizontal stripes. But raycaster can do floorcasting to make textured floor; more complex but manageable. Need perspective wall heights and visible enemies. We can add procedural floor texture and cast floor per row using classic Lodev floorcasting, maybe 960x300 at half resolution. Better performance with a `floorImageData` of 480x150 or direct 960x300 at 1x. For 60fps, 288k pixels per frame, okay in JS maybe. Could instead pre-render horizon gradient with scanlines and grid lines that don't move with player, but walls are key. To be Wolfenstein style, textured floors/ceilings perhaps important. We can do floorcasting at 2x2 pixel blocks: buffer 480x150, fill 72k pixels per frame, scale up via drawImage. Use texture arrays (Uint32Array RGBA little endian). Need know endianness; perhaps easier use ImageData `Uint8ClampedArray` and manually RGBA per pixel. For each floor pixel at (x,y) from horizon down in low-res coordinates, derive rowDistance = `posZ / (y - horizon)` with `posZ=0.5*H` (camera height). Compute `rayDir0 = dir - plane`, `rayDir1=dir+plane`, step = rowDistance*(rayDir1-rayDir0)/w`, floorX=px+rowDistance*rayDir0.x etc. Then sample 64x64 tiles and shade by distance. Ceiling mirrored. Could generate two textures. Need handle y = horizon exactly; skip.

Alternatively render walls with `ctx.drawImage` from texture canvases and shade. Sprites can be drawn as procedural 2D graphics (enemy soldiers/demons) with scaling according to distance and occlusion by z-buffer. Could also generate offscreen canvas sprites procedurally (64x64 or 96x96) and use drawImage column-by-column respecting wall zbuffer. Need occlusion by walls: for each sprite column, if transformY > zBuffer[x] (closer) draw; using sprite canvas slices or pixel buffer. Need ensure project with camera plane method.

Need map design. Let's choose 12x12 or 13x13 grid with wall types:

Legend:
`1` = brick
`2` = stone
`3` = metal/blue
`4` = exit door maybe locked (render distinct)
`0` empty
Maybe `5` exit tile (floor) and `4` exit door on boundary? We can use exit position in open cell and draw portal/marker; wall? Requirement reaching exit shows win. Could define `E` exit at a cell (floor with glowing portal sprite), locked until all enemies defeated. Need perhaps visual locked exit likely map cell with texture? We can use map value 0 and exit object at x,y; render as vertical green portal/exit sprite. On contact (within 0.45), if enemies remaining 0 win else show message "Exit locked — eliminate all enemies". Could show from start if visible? Maybe exit at end corridor. The exit can be represented by map value 4 as wall-like "door" that blocks movement until unlocked; reaching cell adjacent? But "reaching it" could mean touching door. Better use floor tile with an exit portal, and map value 0. Draw a green glowing rectangular door sprite at that location maybe sprite rendering. Collision if locked? Could treat portal as non-solid, and winning requires standing on it when unlocked. If locked, sound/message. Might be okay. Could also map value `4` as solid wall and when all enemies defeated, becomes passable; reaching it (collision attempt) can show win. But required "Defeating all enemies unlocks the exit; reaching it shows a win state" implies door stays wall when locked, then opens. We can implement exit tile type `4`: drawn as wall (door texture) and collision while locked. Once unlocked, map cell set to 0, door represented as glowing portal at that cell; player walks onto it and win. Need maintain map clone to set. Use `baseMap` string or arrays. Draw exit cell as wall type 4 when locked; when unlocked set `map[y][x]=0` and add portal object. This is clean.

Need ensure exit reachable. Design level.

Let's draw grid 14x12 maybe. Start at (2.5,2.5) facing east? Need nearby wall for collision test. Put start in a small room with a wall directly ahead at perhaps x=4? If facing east and wall 2 cells away, we can move W into wall and check collision. Need initial viewpoint maybe show an enemy in corridor and walls. Better start facing east down a corridor with visible enemy ~5 tiles away and wall nearby to north/south. Adjacent wall for collision could be to left or right by strafing. "check collision against a nearby wall" likely can use A/D against side wall. Put wall directly right/left near start, e.g. start (2.5,2.5) with north wall y=1 and south wall y=3; A/D strafe to wall and see blocked. But movement with W forward should not be immediately blocked; perhaps corridor east. Let's design map with decorative walls and loops.

Maybe use 16x12 grid:

```
################
#S....#....E...#
#.##..#..###.#.#
#.#...#....#.#.#
#.#.#####..#.#.#
#...#...#..#...#
###.#.#.#.####.#
#...#.#...#....#
#.###.#####.##.#
#.....#.....#..#
#.##..#..##....#
################
```
Need ensure connectivity and enemies in open spaces. Hard to verify manually. Could use BFS in script perhaps. Better design simpler handcrafted interconnected maze with explicit corridors, ensure path. Could choose grid 13x11:

Row indices 0..10, cols 0..12:
```
"#############",
"#S....#....E#",  // y1 start x1 facing east, corridor x1..5; wall x6; right chamber x7..11 with E x11
"#.###.#.###.#",  // openings?
"#...#...#...#",
"###.#.###.#.#",
"#...#.....#..#",
"#.#####.###..#",
"#.....#....#.#",
"#.###.#.##.#.#",
"#.......#....#",
"#############"
```
Need path from start to exit. Let's map connectivity carefully. Could use BFS mentally or write a quick node script after designing. We can generate a coherent maze algorithmically! Requirement "small level", no need fixed? But restart restores level. Procedural maze generation with a fixed seed and deterministic enemies could guarantee reachable exit. Could generate maze using recursive backtracker with fixed seed, then add loops, place start/exit/enemies on reachable cells. But need nearby wall collision and initial viewpoint. We can pick fixed generated map or custom. Algorithmic maze often narrow corridors and easy to guarantee. Need enemies visible and at least 3. But initial viewpoint could look down corridor. Procedural textures. Could use deterministic seeded PRNG. Build an odd-sized grid with wall boundaries and carved passages. Start at (1.5,1.5), exit farthest reachable cell. Enemies at specific reachable cells with line-of-sight from start perhaps. But for testing turning/movement, deterministic map okay. Yet visual appeal and exit door maybe. We can include a custom map with open chambers and use BFS to verify.

Let's design custom map and use a BFS script to check. We'll create grid strings of equal length. Need wall type distinctions. Could first create binary map. Let's use 15 columns x 11 rows (x 0..14, y 0..10) or 16x12.

Map:
```
################
#......#.......#
#.####.#.#####.#
#.#....#.....#.#
#.#.########.#.#
#.#..........#.#
#.#####.####.#.#
#.....#.#....#.#
#####.#.#.####.#
#.......#......#
################
```
Here outer boundary plus internal. Need exit maybe at x14? Need reachable. Let's BFS connectivity with Python quickly. But design should have exit at x14? boundary wall no. Could make exit door in outer boundary at e.g. x14,y9 set E; map boundary mostly wall. Start x1,y1. Need reach from start to x13,y9 then E on x14,y9. Let's check BFS from (1,1) to (13,9), treating # walls. Use python later. Actually we can use bash now to test candidate map. Let's do that perhaps.

No python. Use node likely available via /app/pipeline perhaps. `node` maybe. Let's check.

Wait BFS path from (1,1) to (6,1) but map row1 has x6 = '#'? Let's index: "#......#.......#" positions: x0 '#', x1-6 '.', x7 '#', x8-14 '.', x15 '#'. Ah yes x6 '.', x7 '#'. My BFS path goes x6,y1 -> x6,y2 -> x6,y3. Row2 "#.####.#.#####.#" positions x0#,x1.,x2-5#,x6.,x7#,x8.,x9-13#,x14.,x15#. okay. Then row3 "#.#....#.....#.#" x1.,x2#,x3-6.,x7#,x8-12.,x13#,x14.,x15#. etc. Great. Total reachable 76 (all open). Good.

Need exit at outer boundary perhaps choose x14,y9? Row9 "#.......#......#" x14 '.', x15 '#'. We can set exit at x14,y9 perhaps door along boundary? Actually cell x14 is open and x15 boundary wall; can set x15,y9 as exit door `4` maybe map row becomes 16 chars with outer boundary still; x15 can be door. Then from x14,y9 move east onto x15,y9 door cell. But when door becomes open, that's beyond boundary but still within map; okay. Or set x14,y9 itself as `4` wall/door and adjacent x13 open. Better define exit cell x14,y9 as door `4` (solid while locked), and when unlocked set it to 0, portal at center (14.5,9.5). Reaching center triggers win. But x14 also might be part of a corridor from top via x14,y1 etc? Need check right-side connectivity. If x14,y9 is door, path from x13,y9 to door. We can set row9 to "#.......#.....E#" where E at x14. Need ensure no alternate path via x14,y1 downward? Let's list row indices. Right top chamber from x8..14 y1; row2 x8 '.' and x14 '.', row3 x8..12 '.', x14 '.', etc. This might connect down to lower right chamber through x14 column? Let's see column x14:
- y0 #
- y1 .
- y2 .
- y3 .
- y4 .? row4 "#.#.########.#.#": positions: x0#,1.,2#,3.,4-11# (8 chars?),12.,13#,14.,15# yes x14 '.'
- y5 "#.#..........#.#": x1.,x2#,x3-12.,x13#,x14.,x15#
- y6 "#.#####.####.#.#": x14 '.'? parse x0#,x1.,x2-6#,x7.,x8-11#,x12.,x13#,x14.,x15#.
- y7 "#.....#.#....#.#": x14 '.'? x0#,x1-5.,x6#,x7.,x8#,x9-12.,x13#,x14.,x15#.
- y8 "#####.#.#.####.#": x14 '.'? positions x0-4#,x5.,x6#,x7.,x8#,x9.,x10-13#,x14.,x15#.
- y9 x14 '.'
So x14 is a long vertical corridor connecting top and bottom right. If exit at x14,y9, from start can reach it perhaps via x8,y1 -> x14,y1 -> down x14 to y9. That is reachable. Good. But door at x14,y9 would block x14 column lower end; path from top to x14,y8 then blocked. Main path via x13,y9 also adjacent. Fine. Need exit door visible maybe from long corridor. Could choose x15,y9 as door boundary and x14 remains open; easiest. But "reaching it" then player walks through boundary tile. We can set `E` at x15,y9 (replacing wall), and when unlocked map becomes 0. The exit is on outer boundary and adjacent to x14,y9. Travel distance to center x15.5,y9.5 from x14.5 is 1.0; trigger within 0.55. Need map raycaster DDA at x16 would be out of bounds if unlocked; but map cells include x15 and outer boundary in view. We can guard out-of-bounds as solid; or when door opens, player reaches it and wins before crossing. Need render portal wall at x15.5? If door cell is open after unlock, portal sprite at center. Could instead draw a portal billboard at x15.5,y9.5. Need raycaster safe when looking through to x16: treat out-of-bounds as wall type 1 perhaps. Could implement mapAt with out-of-bounds return 1. Then no crashes. Fine. But exit tile at boundary visible from corridor as a door wall from east? From x14.5,y9.5 facing east, wall at x15 is 0.5 away; likely too close; when locked, collision prevents moving but player can see door texture. Good.

Maybe easier set exit at x14,y9 as special wall `4`, and when unlocked set map to 0 and render glowing floor/portal sprite at center. Then reaching center (14.5,9.5) triggers win. We need ensure that x14,y9 isn't reachable from above by walking through x14,y8; door cell blocked. But when unlocked, player may approach from above or left. Good. Define map row9: `#.......#.....4#` where x14='4'. Let's count: "#" + "......." 7 + "#" =9? Let's explicitly build using arrays from strings with `E` char. Use map chars:
- '#' for brick type 1 maybe
- 's' stone wall type 2?
- 'm' metal wall type 3?
- 'E' exit door type 4
- '.' empty
Could decorate wall types by deterministic formula instead of map chars; map walls all `1`, but use coordinate hash to choose texture 1/2/3. Better could put different chars for variety:
```
const rawMap = [
"1111111111111111",
"1......2.......1",
"1.2222.1.22222.1",
...
]
```
where 1 brick, 2 stone, 3 metal. Need careful with lengths. Could use '#' for all walls and derive texture from coordinate/elevation. Simpler. Use `getWallType(cell)`: map values 1 = brick, 2 = stone, 3 = tech, 4 = exit. Could transform every '#' using deterministic `(x*7+y*11)%...`: e.g. outer walls mostly type 2, internal with occasional 3. Need ensure walls visually varied. Could create map from strings `#` and `E`; when building:
```
let v = ch==='.'?0:ch==='E'?4:( (x*13+y*7)%11<2?3:((x+y)%6<3?2:1));
```
Floor maybe mark start area etc. Good.

Enemies: choose at least 3, maybe 5 to make game engaging and count. Place at reachable open cells with clear line of sight from start maybe first at (5.5,1.5) along initial corridor. Start (1.5,1.5) facing east. East corridor x1..6 at y1; place enemy at (5.5,1.5) 4 tiles away. Need walls at y0 and y2; side walls nearby for collision. Nice. Place second at (10.5,3.5), third at (7.5,5.5), fourth at (11.5,7.5), fifth at (11.5,9.5). Need ensure paths. Let's verify all open:
- row1 x5 '.'
- row3 "#.#....#.....#.#" x10 '.' likely.
- row5 x7 '.' yes.
- row7 x11 '.' likely.
- row9 x11 '.' yes.
Need check line-of-sight from start to first: yes.
Need maybe enemies can move/chase through maze? Stationary is okay; they can damage player under clear attack rule. Could make them patrol/chase a little, but then occlusion logic and collision more complex. Requirement "visible enemies"; no explicit movement. We can implement enemies as stationary sentries with animated sprite and attack when player within 5 tiles and line of sight, cooldown 1.1s, 8 damage. Clear rule displayed. Could also add "Enemies shoot when they have line-of-sight within 5 tiles (1.2s cooldown)." Need perhaps visual tracer from enemy to player. Shots from enemies could be immediate hits. To make gameplay fair, health 100, enemies each 3 hits maybe. Shooting has cooldown 0.28 s, 34 damage, 3 shots per enemy. Visual crosshair and weapon. Need ammo? Not required; unlimited. Could add ammo not needed. Need perhaps one-shot per enemy? 2 shots maybe easier. Use 50 damage, 2 shots each; enemies count 5. Show hit feedback. Need shooting failure if wall blocks. Need use ray from player direction and intersection with enemy circle; pick nearest enemy in angular cone and check wall distance via DDA. Could implement robustly:
- On shoot, set weapon timer/flash.
- Compute ray `(dirX, dirY)`.
- Cast wall DDA to get `wallDist` (perpendicular? Actually Euclidean distance along ray).
- For each alive enemy, vector dx,dy; `dist = sqrt(dx²+dy²)`; projection along ray = dot; perpendicular = |cross|; if projection > 0 and projection < wallDist and abs(perp) < enemy.radius (0.30 or 0.36) and angular cone maybe fine (perp condition already within cylinder), candidate. Choose nearest projection. If candidate, damage; else show "Shot blocked by wall" or just spark/no hit.
- Need possibly ensure target isn't behind wall by wallDist check. Use DDA returns Euclidean ray length. For sprite rendering, transformY is depth along camera direction, and zBuffer stores perpendicular distance; consistent. For a central shot at angle 0, wallDist along ray = perpDist; for off-center enemies hit only if within radius and ray direction, fine. We can compute wallDist along ray with DDA. Need avoid wall side orientation irrelevant.
- Need wall distance if map out-of-bounds. DDA returns hit at boundary.
- Need crosshair center; shots center only.
- Could optionally add slight aim assist? Not necessary.
- Need visual hit marker (red/white cross or green) and floating text "HIT" / "WALL" maybe DOM. Need weapon feedback: gun recoils downward, muzzle flash, shell casing perhaps; generated audio via WebAudio. Need ensure browser autoplay restrictions: create AudioContext on first key/click user gesture; catch errors. Could implement tiny synthesized gunshot/hit/hurt sounds; no external requests. Good. But browser tool headless may not support WebAudio; catch. Could rely visual.

Enemy rendering:
- Generate procedural sprite canvases for enemy type maybe 64x96 pixel art robot/soldier. Need draw column-by-column with z-buffer to occlude. Could create `enemySprite` offscreen canvas with transparent pixels, perhaps 96x96. Use pixel-art style drawing: red/gray armored humanoid, eye glowing yellow, weapon. Generate with Canvas 2D shapes. Need maybe 2-3 frames (idle bob, attack flash). Could generate array of 4 canvases: normal, firing, hurt, death? We can tint via `globalCompositeOperation` or overlay. Simpler: generate base enemy sprite and draw dynamic overlay flash using `ctx.filter`? For occlusion, drawing slices with drawImage; could apply brightness? `ctx.globalAlpha` etc. For each column, if transformY < zbuffer[x], draw a 1-pixel slice of sprite at screen x with vertical scaling. Need generate sprite as canvas with transparent background. Drawing 1px slices many times (sprite height maybe 300 px) can be somewhat expensive but only few enemies. Could batch visible contiguous spans: for each x from drawStartX to drawEndX, check zbuffer; for contiguous visible runs, draw one `drawImage(sprite, sourceX,0,sourceW,sprite.height, destX,destY,destW,destH)` where sourceX maps by start relative to spriteW. We can perhaps draw entire sprite only if no wall occludes across any column; but requirement walls occlude, so need column-wise.
- Use `ctx.drawImage(sprite, sx, 0, 1, H, x, drawStartY, 1, spriteH)` for each column. At canvas width 960, enemy sprite width maybe 350; 350 draw calls x 5 enemies, okay ~1750/frame maybe still okay. Could render at 2 px columns to reduce: step=2; dimensions accordingly. For each stripe width 2, use source width proportional. We'll use `SPRITE_STEP=2`, loop x from start to end step 2 and zbuffer index `x/2` if zbuffer lower res. Need define rendering resolution.

Wall rendering:
- Use internal canvas 960x600. We can cast 480 rays (one per 2px column) and draw each as 2px wide strip. Use texture canvas 64x64 and drawImage with source 1x64 to dest 2px x lineHeight. Shade by darkening with `fillRect` `rgba(0,0,0,shade)` over strip. Need darken side faces and distance fog. Could use `ctx.globalAlpha` with black overlay. Since drawImage and fillRect 480 times each, okay. Use `ctx.imageSmoothingEnabled=false`.
- For floor/ceiling, pre-render at 480x300? Need a separate offscreen `backCanvas` at `RW=480,RH=300` and `ImageData`, then draw scaled to full canvas. For each low-res y from 0 to RH/2? Actually horizon at H/2=300; low-res height RH=300, horizon=150. For each y 0..149, ceiling row mirrored: rowDistance = (0.5*RH)/(RH/2 - y)? Need derive with low-res coordinate scaling. Classic: for each y below horizon in screen pixels H, `p = y - H/2`, `posZ=0.5*H`, `rowDistance=posZ/p`. If we use low-res RH=300 (half of 600), horizon=150, posZ=0.5*RH=150, so `rowDistance=150/(y-150)` in world units. For y=151 rowDistance=150 (huge), y=299 rowDistance≈1.0. That's okay: with camera at half wall height, floor at one wall-unit away appears near bottom. Need FOV / plane included in step, no vertical FOV scaling; world wall height projected as H/perpDist = 600/perpDist, consistent. So using H=600, posZ=300; if low-res horizontal scaling only while vertical also half, we'd need posZ=150? Since scale factor 0.5 both x and y, wall projection would be 300/perpDist. Our wall rendering uses full H=600 on full canvas, so floor would be inconsistent if we use low-res y and scale to full. Could use low-res width but full-res height `RH=600`, `RW=480`, then scale horizontally 2x only. That is 480x600 =288k pixels/frame; maybe okay. Or floorcast directly in full res 960x300=288k; okay. Could use `ImageData` for low-res 480x300 and scale both axes 2x; then wall projection should use 300 as projection height rather than 600 to be consistent; but can adjust wall `lineHeight = (H/2)/perpDist`? That's too short. Actually low-res output scaled 2x: wall drawn on full-resolution can still use 600/perpDist; floorcast low-res projection needs use full H in world formulas but y low-res coordinate corresponds to 2*screenY. Let `Yfull = 2*yLow`; `p = Yfull - H/2 = 2*yLow - 300`; `posZ = 0.5*H = 300`; rowDistance = 300/(2*yLow-300)=150/(yLow-150). Aha same formula! Great. So low-res horizon y=150, rowDistance=150/(2*(y-150))? Wait compute: `p_full = 2*yLow - 300 = 2*(yLow-150)`. rowDistance=300/[2*(yLow-150)] =150/(yLow-150). Exactly initial. At bottom yLow=299, rowDistance=150/149≈1.0. Good. So consistent. Nice.

For each low-res y from horizon+1 to RH-1:
- `rayDir0 = dir - plane`, `rayDir1=dir+plane`; `step = rowDistance*(rayDir1-rayDir0)/RW` (RW=480).
- `floor = [px + rowDistance*rayDir0.x, py+...]`
- `cellX=floor[0]&63`, `cellY=floor[1]&63`; shade based on rowDistance (fog).
- fill floor pixel at y, ceiling pixel at RH-y-1 maybe (mirrored). Need floor texture and ceiling texture. Ceiling could use darker checker pattern. Use `floorTex` and `ceilTex`, generated `Uint8ClampedArray` 64*64*4. Could perhaps use one texture with different tint. Need write into `ImageData.data` directly.
- Need ensure endianness irrelevant with Uint8Array writes.
- `ImageData` created once. Need `putImageData` to `terrainCanvas`, then `ctx.drawImage(terrainCanvas,0,0,960,600)`.

Could also draw grid line on floor by texture itself (procedural tile pattern: dark grout lines at edges) to emphasize grid. Generate 64x64 per-pixel:
  - brick texture: mortar lines, bricks pattern with noise and light/shadow.
  - stone: stone blocks with cracks and speckles.
  - metal: blue-gray panels with rivets and stripes.
  - door: red/gold panels with lock emblem, "EXIT" maybe generated with canvas text (procedurally generated canvas okay). Need wall texture canvases.
  - floor: dark gray checker tiles with subtle noise and grid.
  - ceiling: dark blue/graphite panel with lines/noise.
  - enemy sprite: pixel art.
  - gun sprite: draw with Canvas 2D shapes at bottom right/center; can draw directly each frame with recoil transform rather than sprite.
  - portal sprite: glowing green exit after unlocked.

Need walls different textures based on map cell value. Use `wallTextures[1..4]` canvases. Need texture sampling source x. DDA:
```
let cameraX=2*x/RW-1;
let rayX=dirX+planeX*cameraX;
...
let mapX=floor(px), mapY=floor(py);
deltaX = abs(1/rayX)...
...
while(!hit && steps<64) ...
if side==0 perpDist=(mapX-px+(1-stepX)/2)/rayX else analogous.
```
`perpDist` is distance along camera direction (not Euclidean along ray), used for wall height and zBuffer. Need zbuffer per low-res column `zBuffer[x]=perpDist`.
- Texture coordinate `wallX`: if side 0, py+perpDist*rayY; else px+perpDist*rayX; subtract floor. If side==1, reverse? need typical:
```
if side==0 wallX = py + perpDist*rayY;
else wallX=px+perpDist*rayX;
wallX -= Math.floor(wallX);
texX = Math.floor(wallX*TEX);
if(side==0 && rayX>0) texX=TEX-texX-1;
if(side==1 && rayY<0) texX=TEX-texX-1;
```
- lineHeight = Math.floor(H/perpDist), drawStart = -lineHeight/2+H/2, drawEnd=...; maybe use `Math.floor((H-lineHeight)/2)`, and drawImage source y may need crop if line extends beyond screen. Canvas drawImage with offscreen bounds will clip automatically, and source coordinates remain full texture; if destination extends beyond canvas, the whole texture is stretched over full lineHeight, clipping does correct mapping (yes).
- shade = min(0.75, 0.08 + perpDist*0.055) + side*0.15. Could use black overlay. Need perhaps bright near wall. Use `ctx.fillStyle = rgba(0,0,0,shade)` for each strip.
- Add fog color maybe overlay dark blue with alpha based on distance. Black okay.
- Need maybe no drawing for `perpDist <= 0`.
- `mapAt` out-of-bounds returns wall type 1.

Sprites:
Classic transform:
```
spriteX = ex-px; spriteY=ey-py;
invDet=1/(planeX*dirY - dirX*planeY);
transformX=invDet*(dirY*spriteX - dirX*spriteY);
transformY=invDet*(-planeY*spriteX + planeX*spriteY); // depth along dir
if transformY<=0.15 skip.
spriteScreenX = Math.floor((RW/2)*(1+transformX/transformY)); // low-res coordinate
spriteHeight = Math.abs(Math.floor(H/transformY)); // full H projection
spriteWidth = spriteHeight * (sprite.width/sprite.height) * maybe 0.75.
```
But because screen x uses full W in classic code: `W/2*(1+transformX/transformY)`. If our zBuffer is low-res columns and rendering full width, `screenXFull = W/2*(1+...)`; `spriteScreenXLow=screenXFull/2`, equivalent RW/2. For sprite width on full screen, can use `spriteHeight = H/transformY`, `spriteWidth = spriteHeight * aspect` perhaps. Enemy sprite 64x96 aspect .667, so width ~400 px at dist 1.5, height 400? Actually H/1.5=400, width267; okay. Need maybe scale enemy down to 0.8 height (enemy shorter than walls): use `spriteHeight = (H/transformY)*0.8`; width=spriteHeight*0.75. drawStartY = H/2 - spriteHeight/2 maybe align floor? Since camera center at half wall height and enemy stands on floor, bottom should align with wall bottom: wall bottom = H/2 + H/(2*dist). If sprite height = H/dist * 0.8, bottom should be wall bottom, so drawStartY = H/2+H/(2*dist)-spriteHeight. top = H/2+H/(2d)-0.8H/d = H/2-0.3H/d. center would be H/2-0.1H/d, slightly above horizon. Classic billboard centers at horizon, making feet too high. We can set:
```
wallBottom = H/2 + H/(2*transformY);
spriteH = H/transformY*0.78;
drawStartY=wallBottom-spriteH;
```
This makes floor alignment good.
For portal billboard maybe similar, height=H/dist*0.9 and bottom at wall bottom.
- vertical move/bob: add small `Math.sin(t*...)` to drawStartY maybe.
- sprite screen X full: `W/2*(1+transformX/transformY)`. drawStartX = screenX - spriteW/2.
- Loop over full x from start to end step `SPRITE_STEP=2`; calculate zBuffer index `floor(x/2)` or `Math.floor(x*RW/W)`; if `transformY < zbuffer[idx] - 0.02`, draw a column slice. Need map source coordinate:
```
u=(x-drawStartX)/spriteW; srcX=Math.floor(u*sw);
ctx.drawImage(sprite, srcX,0,1,sh, x,drawStartY, SPRITE_STEP, spriteH);
```
For runs, no need; per 2px column up to 300 draw calls per enemy. Fine.
- Need clip offscreen source u [0,1].
- Could draw a translucent shadow ellipse at bottom if visible across center; not needed.
- Since canvas drawImage with transparent sprite column by column will respect zbuffer per stripe. Need ensure full sprite not drawn as one image; yes.

Enemy animation:
`enemy.frame` perhaps use normal, firing, hurt. Generate 3 variants or overlay. Could create `enemySprite` base with transparent background; `hurtSprite` maybe red tinted. Generate via `makeEnemySprite(mode)` with different colors. For firing, add bright muzzle to gun; for hurt, red glow. Death maybe remove immediately and spawn particles. Need visual feedback perhaps add floating "DOWN" text or explosion burst. We can add particles with life, rendered as 2D screen-space maybe simpler. Need not overcomplicate.
- Enemy attack: when line-of-sight (no wall), distance <=5.2 and cooldown <=0, subtract e.g. 7 health. Need clear rule. Show a red tracer from enemy to player? Need map to screen location perhaps draw a brief red vignette and enemy firing frame; also status message "Enemy hit! -8". Need perhaps implement actual projectiles? Could be immediate with visible line across screen from enemy's screen x to center, but enemy may be occluded? Need only attack with line of sight. Could draw a red HUD tracer from computed enemy screen X to crosshair maybe. But that might look odd; easier add `damageFlash` overlay red and message "Enemy fire: -8 HP", plus enemy muzzle flash. Requirement clear attack rule; textual rule enough. Could also show small red bolt sprite moving from enemy to player over 0.15 sec; but unnecessary. Could implement `enemy.attackTimer = 0.25`, `enemy.firing = true`, and indicator. Need check clear line of sight:
```
function hasLineOfSight(x1,y1,x2,y2) {
  // DDA along segment; return false if any solid map cell before endpoint
}
```
Could use ray stepping at 0.04 increments and check mapAt floor; if wall then false. Need ensure enemy and player not inside walls. Use DDA or sampling. Small grid so step 0.05 works. For occlusion across exit door (wall type 4 while locked), mapAt should treat >0 solid. Use `isSolid(cx,cy)`.
- Enemy attack cooldown maybe 1.2 sec plus random phase; to avoid all enemies simultaneously. Need seeded initial cooldown. Each enemy `cooldown = 0.8 + i*0.23`.
- Health 100; 8 damage per hit; player can die if stands near enemies. Need game over state when <=0. Need stop movement/shooting/enemy attacks. Show overlay "GAME OVER" and Restart button.
- Win when player reaches exit cell center (distance <0.55) and enemiesRemaining=0. Need set gameState='won'. Could also if proximity to locked door show message "Exit locked: N enemies remain" with debounce. Need collision against door while locked: isSolid map value 4. Need after all dead, `unlockExit()`: set map[exit.y][exit.x]=0; maybe show banner "EXIT UNLOCKED — find the green portal"; portal sprite drawn at exit center. Need exit door texture perhaps show "LOCKED" door. Need maybe generate door canvas with `EXIT` text and red lock icon. Good.
- Reaching exit: if map cell open, player can step into center; check `Math.hypot(px-exit.cx,py-exit.cy)<0.55`, win. Need maybe only active when unlocked. Good.

Map generation:
```
const MAP_ROWS = [...]; // 16x11
const map = rows.map((row,y)=>[...row].map((ch,x)=>{
 if(ch==='#') return wallTypeFrom(x,y);
 if(ch==='E') return 4;
 return 0;
}));
```
Need place E in row9 x14. Let's create strings exactly length 16:
row0 "################" (16)
row1 "#......#.......#" (16)
row2 "#.####.#.#####.#" count? 1+1+4+1+1+1+5+1+1 =16? Let's count: "#"1 "."2 maybe easier use JS check later.
row3 "#.#....#.....#.#" length 16.
row4 "#.#.########.#.#"? Need count. Original "#.#.########.#.#" has 16 likely: # . # . ######## . # . # = 1+1+1+1+8+1+1+1+1=16. yes.
row5 "#.#..........#.#" = # . # 10 dots # . #? 1+1+1+10+1+1+1=16.
row6 "#.#####.####.#.#" =1+1+5+1+4+1+1+1+1 =16? 1+1=2, +5=7,+1=8,+4=12,+1=13,+1=14,+1=15,+1=16 yes.
row7 "#.....#.#....#.#" = # +5 + # + . + # +4 + # + . + # =1+5+1+1+1+4+1+1+1=16.
row8 "#####.#.#.####.#" =5+1+1+1+1+1+4+1+1 =16.
row9 "#.......#.....E#" =1+7+1+5+1+1 =16? 1+7=8,+1=9,+5=14,+E=15,#=16. x14 E. Good.
row10 "################"
Need maybe set row1 x5 enemy okay. Need path from start to exit. Let's BFS with E as blocking perhaps. We'll test.
Need wall texture distribution by coordinate; map value >0. `wallTypeFrom`: maybe boundary walls type 2 (stone) or type 1 brick; internal walls alternate. We can do:
```
if ((x*7+y*11)%13===0) return 3;
if ((x+y)%4===0) return 2;
return 1;
```
But all walls still solid. Need use mapAt returning 1 for out of bounds.
Need door cell 4. Need floor variations perhaps from coordinates; floor texture sampled from tiling world. Good.

Player start `(1.5,1.5)` facing east angle=0; dir=(1,0), plane=(0,tan(FOV/2)=0.66). Need near side walls: north y0 wall, south row2 x1 '.', actually row2 x1 '.' means south from start x1,y2 is open vertical corridor down! Need check map row2 "#.####.#.#####.#": x1 '.' yes. So from start, south is open, not wall. North y0 wall immediate; west x0 wall. A/D strafe: facing east, A (left) moves north (negative y) into wall at y0 (distance 0.5), D (right) moves south into open cell y2. Requirement "check collision against a nearby wall": can use A to hit north wall. But initial corridor has north wall close; strafe A will be blocked quickly. Maybe better have both side walls? Could set row2 x1 to '#' to make south wall, but that may disconnect lower maze? Need ensure path via x6,y2 etc. Start east corridor x1..6; from x6,y1 to x6,y2 open; fine. We can set row2 x1 '#' without disconnecting because path from start east to x6 then down. Then start has north and south walls, nice corridor. But lower left path maybe still via x3,y3 etc connecting from central corridor. Let's modify row2 to "##.###.#.#####.#"? Need careful. Original row2 x0#,x1.,x2-5#,x6.,x7#,x8.,x9-13#,x14.,x15#. Setting x1 to `#` yields "##.####.#.#####.#"? Wait x0#,x1#,x2-5#,x6.,x7#,x8.,x9-13#,x14.,x15#: string "######.#.#####.#"? Count: x0-x5 six # -> "######", x6 '.', x7 '#', x8 '.', x9-x13 five #, x14 '.', x15 '#' => "######.#.#####.#"? That's 6+1+1+1+5+1+1=16. Actually "######.#.#####.#" has maybe 16. But then lower-left x1,y3 maybe connected? Let's check. Need not; could still connect via x3,y3 to x6,y3 and x6,y2 to top corridor. Maybe x1,y5 etc connects through x3,y5? Need BFS. Let's use node to check candidate. But first maybe keep x1 open to make side corridor and use west wall as collision by S movement from start (backward into x0 wall). That's obvious. Starting facing east; S moves backward west into wall at x0; easy to check collision. But requirement specifically "movement and turning near starting area, check collision against a nearby wall" can be S into west wall. Good. We don't need both sides. Could keep original map for connectivity. However starting with a south opening makes movement turning more interesting.

Need maybe set start at (2.5,1.5) so west wall not immediate? Could set x1.5 as before. Need first enemy at x5.5,y1.5. A/S collision with north/west walls easy.

Enemy placements need line of sight and BFS. Let's test map strings and placements with node.

BFS treats E as open; locked door should be blocked but reachable adjacency x13,9 or x14,8. Need check exit adjacency reachable if E excluded. But likely. Fine.

Need verify line-of-sight from start to enemy1: row1 x1..6 open; yes. Need maybe enemy at x5.5 is too close and can shoot player immediately; okay but should give player a moment. Attack range 5 and x difference 4, so from start enemy sees player and can shoot after 0.8s. That's fine; user can shoot. Could perhaps set enemy at x6.5? x6 row1 open, x7 wall; distance 5; still starts seeing. But x5.5 is fine. Need health maybe drain while testing; okay. Could set initial attack cooldown 2.5s for first enemy to allow testing. Need clear rule. We can set `cooldown=1.4 + i*0.4` and attack range 4.8; start distance 4.0, so first attacks after 1.4s. Fine.
Need perhaps enemy count 5. Kill all to unlock exit. Need game winnable, but browser verification only restart initial viewpoint and health. Could perhaps test using debug shortcuts? We need not play to win manually, but we should ensure code logic. Could expose window.__mazeGame with state and methods to inspect or even force kill? We can add debug API intentionally for testing, but must not be obvious cheat. Could set `window.__game = { get state(){...}, ... }` with `snapshot()`. Browser inspect may allow reading text, but not arbitrary eval. We can update a hidden DOM element with JSON telemetry and visible status line. That is good for verification. Need perhaps ensure movement via keyboard events works with browser tool key action. Browser key action likely sends keydown/keyup to page; need handle codes `KeyW`, `KeyS`, `KeyA`, `KeyD`, `ArrowLeft`, `ArrowRight`, `Space`. Need prevent default for arrows and space. Need maybe continuous movement via `keydown` sets keys; `keyup` clears. Browser tool `key` might send a single keydown + keyup quickly; if continuous movement only in animation loop, duration may be too short. Need perhaps on each keydown also apply a discrete movement step? Better design: keydown set key, and also call `stepPlayer` maybe continuous quickly, but with browser tool key likely sends keydown only with no delay? Need understand. Could implement movement on keydown as discrete step plus key held continuous via RAF, so a single key event moves. Similarly turning on arrow keydown applies discrete angle increment, then continuous if held. Shooting on Space keydown triggers shot immediately. This makes testing robust. Need avoid double movement too fast while held; on keydown, set key true and `applyImpulse` maybe 0.12 tile move / 0.08 rad turn. Then RAF continuous movement. Could simply handle all movement in keydown discrete with repeat; no need keyup? But smooth movement desired. We can support both: on keydown if not already down, call `player.moveImpulse` with `dt=0.10` (or t) once; then RAF also moves while held. Browser key may produce keydown+keyup, no continuous movement; impulse ensures effect. Need avoid collision check. For turning, impulse angle 0.06 rad. Need perhaps tests expect larger change; could use 0.12 rad. For movement, impulse 0.16 tile. Need ensure collision against a nearby wall: if starting x1.5 and press S (backwards west), with step 0.16, x becomes 1.34 still not hitting wall; need multiple presses or held. Better set impulse 0.22 or 0.3 tile. Starting position might be x1.5 with radius 0.22; wall at x0 means minimum center x1.22. Press S once from 1.5 to 1.28, not blocked; second to 1.22 hits. Browser tool can send multiple key events. Could make impulse dt=0.35 sec * speed 3.0 =1.05 tile, too far. Maybe use `movePlayer(0.55*speed*0.16?)`. Need balance. Could set start x1.35 near west wall so one S press collides; but initial viewpoint too close to wall, still okay? x1.5 is fine. For collision test using A into north wall: y1.5, radius 0.22, min y1.22; one 0.3 step would hit. We can use impulse displacement 0.32 tile (`dt=0.12`, speed=2.8 =>0.336). So one A or S press collides. But a held key could double step through? Collision resolution axis-wise prevents crossing; okay. Need perhaps turn impulse 0.10 rad. Might be enough to see change via telemetry. Could use 0.12.

Need consider key action coordinates perhaps key event target. Use `window.addEventListener('keydown'...)`. Space should trigger shoot once per keydown, not auto-fire? Could hold for repeated? Browser key might send repeated keydown; we'll use if !keys.Space and cooldown <=0. Need also allow click on canvas to shoot (optional) and button. Use button "FIRE" maybe for mobile? Not required but helpful. Need controls displayed. We can add bottom control strip with keys. Could include a button `FIRE` and `RESTART`; restart visible in HUD and overlay. Need maybe show a "Controls" panel. Use CSS responsive layout.

Need browser tool maybe can click coordinates. Need canvas in 1200x800 viewport. We'll design page centered within 1200x800; canvas maybe 960x600 scaled to fit width 100%, max 960? Need exact screenshot coordinates for clicks if needed. We'll use keyboard mostly. Need restart button perhaps at HUD top-right and overlay. Could give IDs. Need browser tool click by coordinate; if canvas scaled, maybe less relevant. Could use `button#restart`. Browser click tool only coordinate, perhaps no selector. We can ensure restart button at a predictable screen coordinate by CSS. But perhaps browser inspect supports selectors? Tools description says click x,y. We'll need know coordinates from screenshot. Could also use keyboard `R` to restart, easier. Requirement "Provide Restart"; button enough, plus `R` shortcut can help test. We can use browser key `r` to trigger restart. Need implement `KeyR`.

Need console errors inspection. Need avoid using external fonts/assets. Use system font via CSS. Could use `font-family: "Courier New", monospace` no network. Need inline SVG? no external, but can use CSS shapes. No network.

Need code structure:

HTML:
```
<!doctype html>
<html lang="en">
<head><meta charset="utf-8"><meta name="viewport"...><title>Neon Block Labyrinth</title>
<style>...</style></head>
<body>
<div id="app">
<header>
 <div class=title>...</div>
 <div class=stats>
  <div class=stat>HEALTH <span id=health>100</span><div class=bar>...</div></div>
  <div class=stat>ENEMIES <span id=enemies>5</span></div>
  <div class=stat>EXIT <span id=exitState>LOCKED</span></div>
 </div>
 <button id=restart>Restart [R]</button>
</header>
<div id=stage>
 <canvas id=game width=960 height=600 ...></canvas>
 <div id=crosshair perhaps drawn on canvas not DOM>
 <div id=toast>...</div>
 <div id=overlay class=hidden>... restart button ...</div>
 <div id=damageOverlay maybe CSS>
</div>
<div id=controls>... list W/S etc ... enemy rule ...</div>
<div id=telemetry aria-hidden=true>...</div> maybe visible small line with POS/ANG/STATE, perhaps no need hidden. Could style tiny and call "view data" for debug maybe useful. But hidden text still in DOM maybe inspect tool sees it. Use `<div id="diagnostics" aria-hidden="true" hidden>...` with data attributes on body or canvas. But `hidden` attribute might be ignored by inspect text search; style `position:absolute; left:-9999px`. We can also display a small "POS 1.50,1.50 · FACING 0.0°" in controls area, useful for verification. This is fine, not too intrusive. Let's show `SCAN: x... / angle...` in bottom status. Also `#health`, `#enemies`, `#exitState`, `#stateText`, `#feedback`. We can use inspect DOM to see updates. Need perhaps canvas hash for stable wall rendering? Could add `#renderSignature` computed from a few pixels every frame? Nice idea: after rendering, compute `ctx.getImageData` at sample points on walls and update a hidden `<span id=pixelSamples>` for checks. But "sample the scene for stable wall rendering" perhaps we can use browser screenshots or canvas pixel samples via hidden telemetry. Could expose `window.__raycast = { snapshot() }` with `pixelSignature` computed. Browser inspect maybe can execute JS? Not sure. We can display a "WALL SAMPLE" checksum in diagnostics. We can compute a hash of wall strips from canvas after rendering at fixed sample coordinates, then update e.g. every 30 frames. But initial viewpoint after restart can be checked via signature. Need stable wall rendering means no flicker/black screen, perhaps screenshot. Could add `canvas.dataset.frame`, `canvas.dataset.renderHash` each frame. Browser inspect may show dataset. Need perhaps hidden `span` with sample swatches. Let's design robust diagnostics:
- Update `<div id="debugLine">POS ... · DIR ... · F ... · PIX <hash>` with tiny text maybe visible under canvas.
- `hash` computed from `ctx.getImageData` at say 9 fixed points: (80,250),(160,300),(240,350),(480,150),(480,450),(720,250),(800,300),(880,350),(480,300), sum RGB. But sprites/enemy movement could affect; wall sample points mostly walls/ceiling/floor. Need stable across frames at same viewpoint; if enemies attack or weapon animates maybe some sample points include. Choose points likely wall: center (480, 220/380) may be enemy; corners perhaps. Could compute a full low-resolution `getImageData(0,0,960,600)` hash every 20 frames, but changes due to animation would not be stable. Better update a `wallRenderSignature` based on DDA zbuffer/texture IDs before overlays: e.g. hash of `zBuffer` and wall texture IDs at sampled columns. That is deterministic for a given viewpoint and shows raycaster stable. Data attribute `canvas.dataset.wall = hash` with `zBuffer` values. Could also add DOM text. This is internal but useful. User needn't see. Requirement "Sample the scene for stable wall rendering" from verification instructions; we can use screenshot visually and perhaps compute data. Good.

Could expose `window.gameDebug = { snapshot:()=>({...}) }` for browser checks. Browser inspect maybe can call? No JS exec tool. But can maybe use browser tool "inspect" with text? Need see after running. Could also use `document.title` updated to state; not necessary.

Need perhaps implement `aria-live` feedback. Good.

CSS:
- dark background with radial gradient, neon amber/red/green accents.
- `#app` width min(100vw, 1100px), margin auto, padding 14px, display flex column.
- header flex; title small.
- `#stage` position relative; width maybe 960px; canvas width 100%; height auto; aspect-ratio 8/5; border 2px solid #5a3d24; box-shadow; background #000; image-rendering: pixelated; cursor crosshair.
- HUD overlay top-left maybe on canvas: health bar and enemies. But we already have header; could draw HUD on canvas too (health, ammo etc). Requirement show health and remaining enemy count; DOM header suffices. Could also draw top-left HUD in canvas with text for immersive. Need not duplicate. But perhaps crosshair drawn on canvas. Use CSS overlay for toast and state.
- `#overlay` absolutely centered, backdrop-filter? no external. hidden class.
- controls panel below: key caps inline `<kbd>` and rule. Need show W/S etc and Space. Could give each. Maybe compact.
- footer status line with feedback and diagnostics.

Canvas rendering details:
- `ctx.imageSmoothingEnabled = false;` each frame maybe after resize? Canvas internal fixed.
- `ctx.clearRect`.
- Draw floor/ceiling background.
- Draw walls.
- Draw sprites sorted back-to-front:
  - include enemies and portal if unlocked.
  - each item has x,y, sprite canvas, scale, maybe bob, `depth`, `tint`.
  - sort descending depth; for each call `drawBillboard`.
- Draw ceiling/wall fog maybe already.
- Draw HUD: crosshair at center with subtle lines; weapon at bottom center/right, recoil offset; muzzle flash; hitmarker; damage vignette; status text perhaps.
- Draw "locked exit" message? Door texture has lock.
- Draw minimap in top-right corner maybe not required, but helpful for level/restart. Could draw small 2D minimap with walls, player, enemies, exit. But that may reveal enemies and clutter. Could be nice. Need perhaps avoid screenshot complexity. But could help verifying initial viewpoint via visible map. We can draw a small minimap with translucent background at lower-left or top-right. Not required; but adds polish. Need ensure not obscure wall sample. Maybe draw top-right 160x110 at x790,y10. Could display walls in dark, floors, enemies red, exit green/amber, player yellow triangle. This also satisfies textured grid maze perhaps visually. But could be considered cheat; fine.
- Need weapon feedback: weapon is drawn as a stylized pistol/rifle at bottom center. draw using paths:
  - translate(W/2+recoilX, H+recoilY), draw gun body with gradient polygons, barrel, hand/glove; maybe simpler.
  - muzzle flash radial polygon at center around H-160; use additive blending. Shot timer 0.16; recoil offsets.
  - Cartridge/ejection maybe small.
  - crosshair.
  - hit marker if hitTimer >0.
  - shot puff at wall maybe could create 3D spark? Need perhaps compute hit point and draw small screen-space spark near crosshair. Could set `shotSpark = {x,y,t}` based on hit at center; draw crosshair spark. Since center shot always, draw orange burst around crosshair. Need feedback for wall vs enemy: status text "DIRECT HIT" or "ROUNDS SPENT" and hitmarker color.
- Enemy damage flash: render `hurtSprite` for `enemy.hurtTimer>0`, firing sprite for `attackTimer>0`. Death: spawn particles; spawn maybe small red burst at enemy screen position? Could just use toast "SENTRY DOWN · 4 LEFT". Need visual reaction perhaps hurt sprite flash. Need maybe 2 hits to kill. On killing, create floating text `+ DOWN` in screen coordinates; can store world-to-screen position. Simpler draw a quick center-screen green "TARGET DOWN" message via toast.
- Need enemy attack maybe screen red vignette and toast "HIT! -8 HP · enemy has line of sight". Need clear. Could also draw small red directional arrow? not necessary.
- Need defeat all enemies unlocks exit: on last kill, map cell set 0; portal sprite appears; exit state "OPEN"; toast for 3 sec "EXIT UNLOCKED — reach the green portal". Need map texture update.
- Need restart reset map, player, enemies, health, state, timers, camera. Need also reset keys maybe not? Could clear keys to avoid stuck keys. Need reset audio? no.
- Need game over/win overlays with restart button(s). Need one top restart button and overlay button both call restart. Need avoid duplicate IDs. Use class `.restartBtn`, attach event listener to all. Could click overlay button by coordinate; or press R. Good.
- Need maybe `R` key restarts. Need also avoid context menu on canvas. Optional mouse turning: could implement drag to turn without pointer lock; not required. We can include "drag canvas to look" as optional perhaps but no need. Maybe implement pointer lock on double-click? Might be too much. Mouse turning optional and must not be required. We can avoid entirely to keep controls simple. But perhaps user expects first-person shooter to support mouse; text says optional. Fine.

Need procedural texture generation details. Let's write functions:

```
function makeTexture(drawFn) {
 const c=document.createElement('canvas'); c.width=TEX; c.height=TEX; const g=c.getContext('2d'); g.imageSmoothingEnabled=false; drawFn(g); return c;
}
```
For per-pixel noise, use deterministic hash:
```
function hash2(x,y,s=0){ let n=x*374761393+y*668265263+s*1442695041; n=(n^(n>>13))*1274126177; return ((n^(n>>16))>>>0)/4294967295; }
```
Need be careful JS number multiplication with bitwise; use Math.imul maybe:
```
function rand2(x,y,s=0){ let h=Math.imul(x,374761393)+Math.imul(y,668265263)+Math.imul(s,1442695041); h=Math.imul(h^(h>>>13),1274126177); return ((h^(h>>>16))>>>0)/4294967296; }
```
Procedural textures:
- Use ImageData and direct RGBA for brick/stone/metal/floor/ceiling, maybe door drawn with ctx shapes and text. Need offline canvas generation no network.

`makePixelTexture(fn)`:
```
const c = document.createElement('canvas'); c.width=c.height=64;
const ctx=c.getContext('2d');
const img=ctx.createImageData(64,64);
for y,x { let [r,g,b,a=255]=fn(x,y,n); ...}
ctx.putImageData(img,0,0);
return c;
```
- brick:
```
const row=Math.floor(y/16), offset=(row%2)*16;
const bx=(x+offset)%32, by=y%16;
const mortar = bx<2 || by<2;
const brickIndex = Math.floor((x+offset)/32)+row*3;
const noise = rand2(x,y,1)*18-9;
const base = mortar ? [54,48,43] : [120+... , 48+..., 35+...];
add highlights near top/left, dark bottom/right.
```
Need maybe use `rand2(Math.floor(x/2),Math.floor(y/2))` for pixel clusters. Good.
- stone:
```
block rows 21? irregular pattern maybe floor(y/16), columns with offset; mortar lines; gray-blue; cracks using hash threshold.
```
- metal:
```
panel lines x%32<2 or y%32<2; base [55,70,82]; rivets at corners; diagonal scratches; maybe yellow hazard stripe every 16 pixels.
```
- door:
Could use pixel fn with dark red panels and bright gold border; then overlay text "EXIT" using canvas `fillText`, but texture stretched vertically on wall; text may distort, but fine. Need maybe draw a lock icon. Use `ctx.font='bold 12px monospace'; fillText('LOCKED',...)` maybe. Since texture wraps on wall strips, text appears in each wall cell; okay. Could instead use locker symbol.
- floor:
```
tileX=x%32, tileY=y%32; checker = (floor(x/32)+floor(y/32))%2
base checker [45,42,38] vs [52,48,43]; grout if x%32<2||y%32<2; noise; occasional specks.
```
- ceiling:
```
base [24,29,37]; panel lines; subtle blue light strips at x%32 between 14-16; noise.
```
Need store `Uint8ClampedArray` for floorcasting. Could create arrays directly from generated canvases:
```
function texturePixels(canvas){ return canvas.getContext('2d').getImageData(0,0,64,64).data; }
```
Need room for optimization: floorcasting references `floorPix[floorTexIndex]` etc. Could cache. Because `getImageData` returns a Uint8ClampedArray; okay.
- enemy sprite canvas:
  - create 96x128 maybe. Need transparent background.
  - draw shadow? no, transparency.
  - pixel-art shapes rectangles with crisp edges and outlines.
  - body torso, head, helmet, eyes, arms, gun, legs, highlight.
  - perhaps use shapes with `fillRect` and polygons. Need avoid anti-aliasing? fine.
  - draw at 64x96 maybe enough. Use `spriteW=64,spriteH=96`, maybe scale up. Generate at 64x96 with no smoothing.
  - Define `makeEnemySprite(mode)` where mode 0 normal, 1 firing, 2 hurt. Use base colors depending.
  - Pixel art:
    - dark outline silhouette (head/body/legs) using rectangles and path.
    - helmet: rounded-ish block.
    - visor red/yellow eyes.
    - chest armor with central glowing red light.
    - shoulders.
    - arms and gun extending right.
    - legs.
  - Need transparent background; draw only filled shapes.
  - To make mode firing, muzzle flash star at gun tip; hurt: bright red-orange tint overlay with `globalCompositeOperation='source-atop'` maybe fill whole canvas with rgba red 0.45 while preserving alpha. Use `source-atop`.
  - Could make `deathSprite` maybe not needed.
- portal sprite:
  - 64x96 with green glow rings and dark center; use radial gradients and rectangles. Need generate once, maybe animate with time by drawing additional glow? Could perhaps draw sprite with gradient once and use globalAlpha oscillation. Need sprite canvas transparent.
  - green vertical arch with central swirling lines, "EXIT" text. Use `ctx.shadowBlur` and strokes.
- weapon perhaps draw directly with gradients every frame; no external assets. Need handle no network.

Floorcasting implementation:
```
const RW=480, RH=300, BW=960, BH=600;
const zBuffer=new Float32Array(RW);
const wallIdBuffer=new Uint8Array(RW);
const terrainCanvas=document.createElement('canvas'); terrainCanvas.width=RW; terrainCanvas.height=RH;
const tctx=terrainCanvas.getContext('2d');
const terrainImg=tctx.createImageData(RW,RH);
const floorData=floorTexData, ceilData=ceilTexData;
function drawTerrain() {
 const data=terrainImg.data;
 const dirX=player.dx, dirY=..., planeX=..., planeY=...
 const ray0X=dirX-planeX, ray0Y=dirY-planeY;
 const ray1X=dirX+planeX, ray1Y=dirY+planeY;
 for (let y=151; y<RH; y++) {
   const p = 2*(y-RH/2); // full-res p maybe -? 
   const rowDist = (BH/2)/p; // 300/(2*(y-150)) =150/(y-150)
   const stepX = rowDist*(ray1X-ray0X)/RW;
   ...
   let fx=px+rowDist*ray0X, fy=py+rowDist*ray0Y;
   const shade = Math.max(0.15,1/(1+rowDist*0.12)); maybe 0.4...
   for x=0..RW-1 {
      const tx=((Math.floor(fx*64))&63) etc. Need careful negative modulo; use `&63` works with two's complement for integer.
      const i=(ty*64+tx)*4;
      const fi=(y*RW+x)*4;
      data[fi]=floorData[i]*shade; ...
      const ci=((RH-1-y)*RW+x)*4; // mirrored ceiling row
      data[ci]=ceilData[i2]*shade*0.8...
      fx+=stepX; fy+=stepY;
   }
 }
 tctx.putImageData(terrainImg,0,0);
 ctx.drawImage(terrainCanvas,0,0,BW,BH);
}
```
Need ceiling sample use same floor coordinates but ceiling texture perhaps offset or shifted; okay. Need handle rowDist huge near horizon causing step and texture alias; shade near horizon very dark, okay. `rowDist` at y=151=150; shade maybe 0.1. Use `Math.min(1, 0.9/(1+rowDist*0.05))` etc. Need avoid too dark. Could use fog:
```
let light = Math.max(0.18, Math.min(1, 1.35/(1+rowDist*0.18)));
```
At rowDist 1 =>1.14→1; at 5=>0.71; at 10=>0.48; at 150=>0.05→0.18. Ceiling dark factor 0.65. Need maybe floor bright enough. Good.
- Need horizon row y=150 maybe fill with dark color. Loop y=0..RH-1 including horizon? We can initialize ImageData every frame; we need fill all rows. We handle ceiling mirror for y from 151 to 299, corresponding ci row from 148 down to 0. The horizon rows y=149,150 remain old/zero; need fill them with a dark horizon color. Could fill entire data with #10141c initially or explicitly rows 149,150. Actually y=151 maps to ci=RH-1-151=148; y=299 maps ci=0. So rows 0..148 ceiling filled, rows 151..299 floor filled; rows 149,150 need fill. Add loop over x for y=149,150 set dark gray [16,18,24].
- `putImageData` with full data each frame; untouched alpha maybe 0 initially; need set alpha 255 for all pixels. We can initialize alpha to 255 once after createImageData:
```
for (i=3;i<data.length;i+=4) data[i]=255;
```
Then fill RGB for all rows. Good.
- Need maybe tile shading depending on wall proximity; not necessary.

Wall rendering from texture canvases:
```
function castWalls() {
 for x=0;x<RW;x++ {
  ...
  while(steps<64) { ... mapAt returns solid; if hit break; }
  if no hit set dist=20, type=1;
  zBuffer[x]=perpDist;
  wallIdBuffer[x]=type;
  const tex=wallTextures[type]||wallTextures[1];
  const lineH = Math.min(2000, Math.floor(BH/perpDist));
  const y0 = Math.floor((BH-lineH)/2);
  ctx.drawImage(tex, texX,0,1,TEX, x*2,y0,2,lineH);
  const shade = ...
  ctx.fillStyle = `rgba(0,0,0,${shade})`;
  ctx.fillRect(x*2,y0,2,lineH);
 }
}
```
Need if y0 negative and lineH huge, fillRect beyond canvas okay. Need maybe ensure lineH at least 1.
- Need perhaps not render walls when `perpDist` > MAX=20 due to out-of-bounds fallback; okay.
- Need `mapAt` outside returns 1; DDA can step to x=-1 etc; `mapAt` handles.
- Need wall type retrieval from map for exit door; if unlocked map[9][14]=0. Need `isSolid` returns mapAt>0.
- Need darken side with `sideShade=side===1?0.18:0`, distance shade `Math.min(0.75, Math.max(0, (perpDist-1)*0.08))`. Maybe near wall shade 0.15. Overlay black. Could add distance fog blue-ish fill but black enough.
- Need maybe draw horizontal "light strip" on wall? texture handles.
- Need wall sample signature:
```
function calcWallSignature() {
 let sum=0;
 for(let i=0;i<RW;i+=37) sum=(sum+Math.floor(zBuffer[i]*1000)+wallIdBuffer[i]*17)%1000000007;
 return sum.toString(16).padStart(8,'0');
}
```
Update `canvas.dataset.wallHash` maybe every frame and diagnostics every 10 frames. Need initial viewpoint after restart hash should return same value. Since initial enemies/animations don't affect zBuffer. Good.
- Need update diagnostics text with x,y,angle,state,health,enemies,wallHash. This gives browser DOM inspect to verify.

Game loop:
```
let lastTime=performance.now();
function loop(now) {
 const dt=Math.min(0.05,(now-lastTime)/1000); lastTime=now;
 if (state==='playing') {
   handleHeld(dt);
   updateEnemies(dt);
   updateTimers(dt);
   checkExit();
 }
 render(now/1000);
 updateHUD maybe throttle? Could update every frame; fine.
 requestAnimationFrame(loop);
}
```
Need handle discrete key impulses and continuous: `keys` object. On keydown:
```
if (!keys[code]) {
 keys[code]=true;
 if (state==='playing') {
   if(code==='KeyW') move(0, 0.09); // dt equivalent
   ...
 }
}
```
But RAF will also process held keys in same frame. Fine. Need use `dt` in `handleHeld` and impulse uses dt=0.12. Need perhaps if keyup occurs before RAF, impulse already applied. Good.
- Need maybe `event.repeat` ignored? We can ignore repeated keydown to avoid repeated shots; browsers may send repeat with keys true, so just set. If key gets stuck due to no keyup, could move; key action likely sends keyup. Need `window.addEventListener('blur', ()=>keys={})`.
- Need key mapping:
  - W: forward +1
  - S: backward -1
  - A: strafe left (relative to dir) -1
  - D: strafe right +1
  - ArrowLeft: turn left negative angle? Need coordinate system: dir=(cos a,sin a), y increasing downward; increasing angle rotates clockwise (toward south). Left arrow should decrease angle; right arrow increase. Good.
  - Space: shoot
  - R: restart
  - maybe Enter on overlay restart? not necessary.
- Need pointer drag optional maybe not implement. Could implement mouse turning by moving over canvas with pointer lock? But click on canvas could shoot; no need. Maybe add `canvas.addEventListener('mousemove', e=>{ if(e.buttons&1) player.angle += e.movementX*0.003;})`; this is optional mouse turning via dragging, and not required. But not necessary; could introduce complexity. Maybe mention optional "drag canvas to turn" and support. But requirement says mouse turning optional and must not be required. We can avoid.

Movement/collision:
```
function tryMove(nx,ny) {
 const r=0.22;
 // axis-separated to slide:
 if (!solidAt(nx+r*sign? ...)) ...
}
```
Need robust circle-vs-grid collision. Simpler:
```
function canStand(x,y) {
 const r=0.22;
 return !isSolidAt(x-r,y-r)&&!isSolidAt(x+r,y-r)&&!isSolidAt(x-r,y+r)&&!isSolidAt(x+r,y+r) && !isSolidAt(x,y-r)... maybe four corners enough; for axis-aligned cells, four corners suffice.
}
function movePlayer(dx,dy) {
 if(canStand(px+dx,py)) px+=dx;
 if(canStand(px,py+dy)) py+=dy;
}
```
Need `isSolidAt(x,y)`:
```
const cx=Math.floor(x), cy=Math.floor(y);
return mapAt(cx,cy)>0;
```
Four corners with r=0.2 works. Need also check center. Good.
- Movement direction:
```
const forward = W?1:0 + S?-1:0;
let mx=dirX*forward + planeNormalized? For strafe, left vector = (dirY,-dirX)? Wait dir=(cos,sin), right vector perpendicular clockwise = (-sin, cos)? Let's derive with screen y down: facing east (1,0), right (south) should (0,1). Right vector = (-dirY, dirX) = (0,1). Left = (dirY,-dirX)=(0,-1). So D right = (-dirY,dirX), A left = (dirY,-dirX). Good.
```
Need normalize if both forward and strafe to avoid faster diagonal:
```
let mx=0,my=0; if forward ...; if strafe ...
if(mx||my){ const len=Math.hypot(mx,my); mx/=len; ...; movePlayer(mx*speed*dt,my*speed*dt);}
```
Turning:
```
player.angle += turn*ROT_SPEED*dt; updateVectors();
```
Need direction/plane:
```
dirX=Math.cos(angle),dirY=Math.sin(angle);
planeX=-dirY*FOV_PLANE; planeY=dirX*FOV_PLANE; // plane length tan(fov/2)≈0.66
```
At angle0, plane=(0,0.66), ray right edge has +y (south), so screen x increases right, good.
- Need maybe clamp angle to [-π,π] to keep diagnostics stable. Use `angle = (angle+2π)%(2π)` perhaps. After restart 0. Could use `normalizeAngle`.
- Speed 2.5 tiles/sec, turn 2.2 rad/sec. Impulse dt=0.12 gives 0.3 tile / 0.264 rad. Good. Maybe turn impulse 0.12 sec enough to see. For continuous key held, works.
- Need near wall collision: from start facing east, S impulse `-dir*0.3` -> x1.2, collision radius 0.22 means min x1.22, so blocked at 1.22. Good. A impulse left `(0,-0.3)` -> y1.2, blocked at 1.22. Need map row0 solid. Good. W impulse moves to x1.8, fine. D moves south to y1.8; row2 x1 open, okay. Could choose to test A/S.
- Need prevent player from walking through locked door `4`. isSolid true. On unlock map cell set0.

Line of sight:
```
function clearLine(x1,y1,x2,y2){
 const dx=x2-x1,dy=y2-y1, dist=Math.hypot(dx,dy);
 const steps=Math.ceil(dist/0.05);
 for(let i=1;i<steps;i++){
   let t=i/steps; let cx=Math.floor(x1+dx*t),cy=Math.floor(y1+dy*t);
   if (mapAt(cx,cy)>0) return false;
 }
 return true;
}
```
This treats exit door as solid while locked. Need avoid detecting starting/ending cells; we start at i=1 and end i<steps; okay.
- Need wallDist for shooting:
```
function castWallDistanceAlongRay(ox,oy,rdx,rdy,maxDist=20) {
 let mapX=Math.floor(ox), mapY=Math.floor(oy);
 let deltaX=Math.abs(1/rdx),...
 return distance along ray (for side0 (mapX-ox+(1-stepX)/2)/rdx; etc)
}
```
Need if rdx or rdy zero, delta=Infinity.
- Need hit detection:
```
function shoot() {
 if (state!=='playing'||shotCooldown>0) return;
 shotCooldown=0.28;
 weaponKick=1; muzzleTimer=0.14;
 playSound('shoot');
 const wallDist=castWallDistance(...);
 let best=null,bestT=Infinity;
 for e alive:
   const vx=ex-px,vy=ey-py;
   const t=vx*dirX+vy*dirY;
   const perp=Math.abs(vx*dirY-vy*dirX); // cross magnitude
   if(t>0 && t<Math.min(wallDist,bestT) && perp<e.radius) {best=e;bestT=t;}
 if(best){ damage ...; } else { feedback...; }
}
```
Need if enemy behind wall but wallDist > enemy t? If wall before enemy, wallDist<t, reject. Good. Need if ray starts at wall? no.
- Need perhaps use enemy radius 0.35 and crosshair alignment; yes.
- Need if enemy center is slightly off crosshair due to perspective, perpendicular distance condition corresponds to world-space cylinder, so crosshair can hit enemy if ray passes within 0.35 tile of center. Good.
- Need damage 50, enemy hp=100; 2 shots. Could give hit marker and health bar above enemy maybe. Need draw enemy health bar maybe if hurt; could render small bar near sprite top using screen coordinates if visible. But drawBillboard only knows sprite; can optionally draw bar after if center depth < zbuffer at center. Could implement:
  - `drawEnemyHealth(e)` after sprite? Need occlusion check center column; if visible, draw small bar above sprite. Could compute transform and screen coords again, or store from `getBillboard`. Better `drawBillboard` returns `{x,y,w,h,visibleCenter}`. Could draw bar inside function if `item.healthRatio<1`. But requirement doesn't need. Could add. Need sprite occlusion still fine.
- Need enemy hit visual: set `hurtTimer=0.18`; maybe set `flash=...`. On death remove from alive but `enemiesRemaining` count. Could still draw death particles perhaps.

Enemy attack:
```
function updateEnemies(dt){
 let anyAttack=false;
 for e alive:
  e.cooldown-=dt; e.hurtTimer=Math.max(0,...); e.fireTimer...
  const dist=...;
  const sight=dist<=5.0 && clearLine(...);
  if(sight && e.cooldown<=0){
    e.cooldown=1.15+rand? deterministic maybe 1.2;
    e.fireTimer=0.25;
    damagePlayer(8);
  } else if(!sight && e.cooldown<0) e.cooldown=0.25; // avoid instant attack on gaining sight? Maybe reset to 0.5.
```
Need clear rule says "within 5 tiles with unobstructed view; every 1.2 seconds." Need perhaps use fixed 1.2s cooldown. Add slight per-enemy phase but okay. Could set `e.cooldown=1.2` after attack; initial 1.2+i*0.15. If out of sight, cooldown still ticks down; when player enters sight, attack immediate. Could be harsh but clear. Could reset to 0.35 when no sight. Better:
```
if (!sight) e.cooldown=Math.max(e.cooldown,0.35);
```
So entering sight gives 0.35s warning. But still rule every 1.2s while in view. Need maybe visual enemy firing frame triggers. Good.
- `damagePlayer` subtract 8, `damageFlash=1`, feedback "ENEMY FIRE · -8 HP (clear line of sight)". If health<=0, state='lost', overlay. Need maybe stop enemies.
- Need perhaps enemy attack only if alive and state playing.
- Need perhaps update shot cooldown, weaponKick, muzzleTimer, hitTimer, toastTimer, damageFlash. Do timers in `updateTimers`.
- Need perhaps fade toast using CSS class? Could update textContent and `toast.style.opacity` each frame. Simpler CSS transition and set `toast.classList.add('show')`, with timeout saved. Could use JS timer. Need no reliance on setTimeout perhaps safe. Use `showToast(text, kind, duration=1800)` sets text, class, `toastTimer=duration`; updateTimers decrements and remove class. Could do CSS opacity. Need ensure both game feedback and DOM accessible. Good.
- Need status feedback text also in `#feedback` under controls, updated immediately and persists. Could use `#feedback` as last event line. Need maybe enough for browser inspect after shooting. `toast` may disappear; feedback persists. Add `<span id="eventLog">Ready.</span>`. Need update on shot, hit, wall, enemy attack, etc.
- Need health/enemy count DOM update each frame or on state changes. `updateHUD()` called in loop; set text. Need maybe `healthFill.style.width=...`; `health` color.
- Need exit state text `LOCKED` / `OPEN`. Need show `state` maybe `PLAYING`, `GAME OVER`, `VICTORY`. Use overlay hidden. Need perhaps `#gameState`.
- Need diagnostics visible:
```
<div class="status-line">
 <span id="eventLog">...</span>
 <span id="telemetry">POS ...</span>
</div>
```
Need make robust inspection.

Overlay:
```
<div id="overlay" class="overlay hidden">
 <div class="panel">
  <h1 id="overlayTitle">GAME OVER</h1>
  <p id="overlayText">...</p>
  <button class="restartBtn">Restart Mission</button>
 </div>
</div>
```
Need hidden class `display:none`. On win/lost, show. Need top restart button always available. Need maybe overlay restart button event. Need top button call restart.

Sound:
- WebAudio optional. Need create context lazily on user gesture. Use `AudioContext || webkitAudioContext`. Need avoid errors in headless. `let audioCtx; function initAudio(){...}`. Functions `beep(freq,dur,type,gain,slide)` using oscillator/gain. Gunshot noise could use buffer with random values; generated. Need no external. But perhaps browser console error if AudioContext unavailable; catch. Could implement minimal:
```
function playShot() {
 if(!audioCtx) return; 
 const buffer=audioCtx.createBuffer(1, sampleRate*0.12, sampleRate); fill random decaying; source...
}
```
Need maybe can create AudioContext on keydown; initial key action is user gesture. But if browser tool doesn't allow audio, catch. Could skip audio entirely to avoid complexity; visual feedback enough. But audio adds polish. Requirement no third party; WebAudio is fine. Need not be verified. Could include with safe try/catch.
- Need no network requests.

Minimap:
```
function drawMinimap() {
 const cell=9, ox=W-16*cell-14 etc ...
 ctx.save(); ctx.globalAlpha=0.85; fill translucent rect; for rows,cols draw walls dark/gray; exit color; enemies red; player triangle; maybe FOV cone. 
}
```
Need map 16x11, cell=9 ->144x99. Place x=960-154-12=794,y=12. Good. Draw at top-right; HUD header already DOM, but okay. Need maybe texture pixelated. Need draw player direction arrow. Need avoid enemy occlusion? minimap can show all enemies; okay.
- Could also draw crosshair and weapon over minimap? minimap drawn before weapon. Fine.

Sprite rendering with zbuffer:
Need careful coordinate mapping. Let's derive transform determinant with plane:
```
invDet = 1.0 / (planeX * dirY - dirX * planeY);
```
At angle0 dir=(1,0), plane=(0,0.66): det = 0*0 - 1*0.66 = -0.66, inv=-1.515. transformX = inv*(dirY*spriteX - dirX*spriteY)=inv*(-spriteY)=1.515*spriteY; when enemy south (positive y), transformX positive (right), good. transformY=inv*(-planeY*spriteX + planeX*spriteY)=inv*(-0.66*spriteX)=spriteX, good. Formula works.
`screenX = (W/2)*(1+transformX/transformY)`. At enemy south by 1 and east by 4, transformX=1.515, transformY=4, screenX=480*(1+0.379)=662, right, good.
Need draw sprite width perhaps `spriteH * (sprite.width/sprite.height)`; if spriteH=H/transformY*0.78 and aspect=64/96=0.667, width=312 at d=1.5. Good.
Need maybe floor alignment:
```
const wallBottom = BH/2 + BH/(2*transformY);
const h = (BH/transformY)*item.scaleY (0.82);
const y=wallBottom-h+item.vOffset*...; 
```
At d=4, wallBottom=300+75=375,h=600/4*0.82=123, y=252. Enemy appears from y252 to375, centered 313.5; horizon 300, good. Great.
- Need `transformY` is perpendicular depth along dir, same as zBuffer. Good.
- Need if sprite center behind wall, we still draw visible side portions maybe zbuffer handles per column. Need also check center for occlusion to avoid health bar. Fine.
- Need sort sprites far-to-near to blend properly:
```
items.sort((a,b)=>b.depth-a.depth)
```
- Need portal drawn at exit x14.5,y9.5; if cell open, mapAt=0; raycaster sees through to boundary wall at x15 maybe? Wait exit at x14,y9 originally door; after unlock map[9][14]=0. From inside near x13.5,y9.5 looking east, ray passes through x14 cell then hits x15 wall (type1) at distance 1.5; portal at x14.5 is in front and visible. Good. If player enters x14 cell, portal sprite may be directly around player and fill screen; check win when within0.55 before that. Fine.
- Need if exit unlocked and player far away, draw portal only if in view; yes.

Enemy sprite occlusion by walls: zBuffer at column stores perpDist. If transformY < zBuffer[xLow], draw. Need use correct zBuffer index:
```
const zi = Math.min(RW-1, Math.max(0, Math.floor(x*RW/W)));
```
For `x` full-screen coordinate; with W=960,RW=480, `x/2`. Use `Math.floor(x/2)`.
Need loop x from max(0, Math.floor(startX)) to min(W,ceil(startX+w)) step2. Maybe align to even columns:
```
let start = Math.max(0, Math.floor(startX/2)*2);
let end = min(W, Math.ceil((startX+w)/2)*2);
for(let x=start;x<end;x+=2) { ... sourceX = Math.floor((x-startX)/w*sw); ...}
```
If sourceX outside [0,sw-1], skip. Need draw width2 maybe going beyond W at edge; clipped.
Need maybe apply sprite shading with distance: after drawing each slice, could overlay black with alpha based on depth, but doing per slice doubles calls and may create visible seams. Could pre-generate darkened sprite variants? Simpler skip shading; sprites stay bright, but fog should be present. Could use `ctx.globalAlpha = Math.max(0.45, 1/(1+depth*0.07))`; but transparency would let background through, not darken (fog should darken). Could overlay a dark rectangle across full sprite only in visible strips after draw; use `ctx.fillStyle` and `globalCompositeOperation='source-atop'`? Hard. Could generate tinted/darkened sprites for 3 distance buckets; not necessary. Could simply set `ctx.filter = brightness(...)` before drawImage; browser support likely okay, but filter can be costly. Avoid.
- For hurt/firing sprites, choose based on timers.
- Need draw health bars:
```
if(item.hpRatio<1 && item.type==='enemy' && centerVisible) {
  const bw = Math.min(80,w*0.5);
  ctx.fillStyle='#1b0b0b'; ctx.fillRect(cx-bw/2, y-8,bw,5);
  ctx.fillStyle='#e84b3c'; ctx.fillRect(...*hpRatio);
}
```
Need ensure bar doesn't show through wall if center occluded; check `transformY < zBuffer[Math.floor(cx/2)]`. Good.
- Need avoid drawing bar before sprite? draw after. Fine.

Door texture and wall ID: map value4 -> wallTextures[4]. When locked, door wall is solid. When unlocked, set map to0 and portal. Need wallIdBuffer signature changes after unlock. Fine.

Potential issue: floorcasting with unlocked exit and boundary wall at x15: from portal cell, ray beyond x16 out-of-bounds returns wall type1; okay. Need `mapAt` for x=16, y=9 returns1. DDA side distances with mapX=16; works. Need no indexing error. `map[y]?.[x] ?? 1`.

Potential issue: wall texture `drawImage` using source x texX, width1, source y0 height64, destination y maybe negative, height lineH. For lineH > canvas, clipping correct. Need perhaps `ctx.fillRect` overlay from y0 to lineH, okay.
- Need `ctx.globalAlpha` reset to1 after terrain/sprites. Good.
- Need `imageSmoothingEnabled=false` on main ctx; when scaling terrainCanvas 2x, nearest-neighbor blocks, pixelated style. Fine.

Need procedural wall texture are canvases with 64x64; drawImage source slice 1x64; no external.

Need hit detection using DDA with out-of-bounds walls. Need accurate wallDist:
```
function castWallRay(ox,oy,rdx,rdy,maxDist=24) {
 let mapX=Math.floor(ox),mapY=Math.floor(oy);
 let deltaX = rdx===0 ? Infinity : Math.abs(1/rdx);
 ...
 let sideDistX...
 let distance=0;
 for(let i=0;i<80;i++){
   if(sideDistX<sideDistY){ distance=sideDistX; sideDistX+=deltaX; mapX+=stepX; } else ...
   if(mapAt(mapX,mapY)>0) return distance;
   if(distance>maxDist) return maxDist;
 }
 return maxDist;
}
```
At step, distance is distance along ray from origin to boundary. Use sideDist before increment; correct. Note if start inside open; mapAt at new cell check after crossing. Good. For shooting, maxDist maybe 16 enough; map is 16x11. Could use 32. Need no side orientation.
- For line-of-sight, could use same DDA with normalized vector to target and check wallDist >= distToTarget. Could avoid sampling:
```
function hasClearLine(x1,y1,x2,y2){
 dx=x2-x1,dy=...,dist=hypot, nx=dx/dist,ny=dy/dist;
 return castWallRay(x1,y1,nx,ny,dist+0.5) >= dist-0.05;
}
```
Better and consistent with raycaster. Need ensure `castWallRay` returns `maxDist` if no wall before; pass `dist` and check >=dist-1e-4. But if endpoint is inside wall? no. Could implement:
```
const wallDist=castWallRay(x1,y1,nx,ny,dist);
return wallDist>=dist-0.02;
```
If no wall, loop eventually distance > maxDist returns maxDist; true. Need if target is at wall cell boundary? enemies always open. Good.
- For shooting, use `dirX,dirY` normalized; castWallRay returns distance along ray. Need `perp` using cross product. Good.

Need maybe enemy not visible due to wall but sprite projection still shows if zBuffer. Need requirement "Enemies must be occluded by walls"; our per-column zbuffer does. Need perhaps test with screenshot/telemetry. Could maybe add a debug function `isEnemyVisible(e)` compute transform and zbuffer; but not needed. However verification might ask to check shots cannot damage through wall. We can build a test by exposing a hidden debug function? Need perhaps browser tool can't execute JS; but we can manually use map geometry and keys to turn/shoot. Could use developer console? Not available. Could add an in-page self-test function invoked at startup that runs internal assertions and logs results to console. This is clever: on load, run a suite of logic tests (wall ray, line of sight, sprite occlusion maybe) and `console.log` results, plus perhaps show in DOM. Browser inspect can check console messages. Need ensure no console errors. We can implement `runSelfTests()` at startup after initialization:
- Check `canStand` near wall, movement collision.
- Check `hasClearLine` from start to first enemy true, and from e.g. (1.5,1.5) to (10.5,3.5) false (wall between).
- Check `castWallRay` from start east returns ~5.5? Need calculate map row1: start x1.5, east corridor x1..6 open, x7 wall. Distance to boundary x7 is 5.5. Nice. Enemy at x5.5 distance4.0, wallDist5.5 -> shoot can hit. Place a hypothetical enemy behind wall at x8.5 and assert no hit. Need implement `pickShotTarget` function returns target based on current player; can call with temporary enemy array or custom ray. Could have `resolveShot(ox,oy,rdx,rdy,enemyList)` pure function. Then test from start east with enemy at(5.5,1.5) => hit; with enemy at(8.5,1.5) behind wall x7 => null. Need ensure map row1 x7 is wall. Great.
- Check sprite occlusion perhaps compute zbuffer from initial render and check an enemy behind wall would have `transformY > zBuffer[center]`, but harder because initial enemies are not behind wall. Could do a self-test with hypothetical enemy at x8.5,y1.5 and zBuffer from initial wall cast. Need `castWalls` writes global zBuffer; at start, center column wall at x7 dist5.5. Hypothetical enemy transformY=7.0, zBuffer center=5.5, so occluded. Could assert. But `castWalls` draws to canvas; calling in self-test might alter render but next frame redraws. Could create a pure `castWallData(px,py,dirX,dirY,planeX,planeY, targetZ)` that only fills zbuffer and returns perhaps; but current `castWalls` both fills and draws. We can separate ray computation from drawing. Maybe too much. Could skip self-test occlusion; visual render enough.
- Need perhaps `console.info('Raycast self-tests passed', {...})`. Browser inspect initial output/console can see. Great. Need avoid test side effects (e.g., damage or state changes). Use pure functions.
- Need maybe `window.__mazeDebug = { snapshot, testShot, restart, killAll... }`. Could include for browser testing, but hidden. This might be considered extraneous but harmless. Could be useful if browser tool allows JS eval via `inspect`? We can perhaps use `browser` tool with action "inspect" and maybe it has ability to run JS via text? Need see tool docs? Not listed; likely `inspect` returns DOM and console, perhaps can use `text` for selector? We'll find. Could also use `document.body.dataset.state` etc. Let's include accessible debug object:
```
window.__mazeDebug = {
 snapshot:()=>({...}),
 testShotFromStart:...,
 restart
};
```
Need avoid adding cheats that could be triggered by user keyboard. Fine.

Need maybe force kill all for win verification? Could expose `defeatAll()` but not needed. Could provide `snapshot.enemyPositions`. For browser testing we can perhaps use `key` to shoot first enemy twice and verify enemy count. But aiming from start east at enemy x5.5,y1.5 should be direct center, so two Space key presses with cooldown need wait between. Browser tool key actions likely instantaneous; shot cooldown 0.28 seconds. We can perhaps implement browser `key` with `text` maybe `Space` and use `motion` frames to wait. Need pass representative checks, not necessarily win. Need specifically "fire to inspect weapon feedback": one shot enough. Could check event log says "DIRECT HIT" and hitTimer maybe. Need muzzle flash screenshot immediately after Space; browser screenshot might capture. Need perhaps with key action, screenshot after may be delayed >0.14s, so muzzle flash gone. Could set muzzleTimer=0.35s and weaponKick to make feedback visible longer. Need maybe persistent `lastShotAt` and draw a small "BANG" or shell casing for 0.6s. We'll use `muzzleTimer=0.28`, `weaponKick=1`, decay over 0.25 sec. Screenshot after key action likely within ~100ms, okay. Could also draw a muzzle flash residue for `shotAge<0.5` or update event log. Good.
- Need perhaps firing hit marker visible for 0.35s.
- Need shoot cooldown maybe 0.24s; pressing key twice after wait 0.3s. Need browser motion tool maybe captures frames; not sure. Could use `browser key` with `text: "Space"` and then `browser motion` to wait? Need see. We'll try.

Need maybe add a visible FIRE button to click; requirement controls says Space. Could include button that triggers shoot on click and gives a long enough visual. Browser tool can click button then screenshot; easier. Add `<button id="fireButton">FIRE [SPACE]</button>` in controls or HUD. Need clicking button with coordinates. But requirement controls display W/S etc and Space to shoot; button is supplementary. Could help testing firing with screenshot. Need ensure button not trigger keyboard focus issues; call `shoot()` and `canvas.focus()`. Fine.
- Need maybe a "TURN LEFT"/"TURN RIGHT" buttons? Not required. We can include small on-screen controls for accessibility but not necessary. Browser key action likely works.

Need perhaps `canvas tabindex="0"` and focus on load so keys go to canvas? We listen on window, so no need.

Need ensure page fits 1200x800 viewport. Header 70px, canvas 600px, controls maybe 80px, total 750px; okay. But canvas width may be 960, height600; app width maybe 1000; centered at x100. With browser viewport 1200x800, body maybe no scroll if total <800. Need calculate: body padding 12, header 62, gap10, stage600, controls maybe70, status30 =784; okay. If slightly >800, bottom can scroll; fine. Need click restart top at predictable coordinate maybe easier with key R. We'll use R.
- Need CSS max width maybe 1000px; canvas border etc. With 1200 viewport, x=100..1100; center. Restart button at top-right around x1050,y40. Could click if needed. Need maybe overlay button center around x600,y430.
- Need canvases internal fixed 960x600 but CSS width `min(100%, 960px)`; if app width 1000 and stage width 960, okay. Need maybe stage width exactly960. Use `.stage { width: min(96vw, 960px); }` and canvas width:100%; aspect-ratio: 8/5; height:auto. If viewport1200 =>960. Good. Header width same. Controls width same. Total height 600+... maybe fits.
- Need `body` maybe `display:flex; align-items:center; justify-content:center;` but if tall, can cause clipping. Use `min-height:100vh; padding:10px; box-sizing:border-box;`.
- Need overlay panel.

Need think about browser tool `inspect`: maybe returns screenshot plus DOM snapshot with text. We'll run. Need maybe use `browser screenshot` to visually inspect. Need perhaps use `browser motion` to get frames with movement. Need perhaps use `browser key` with text parameter. We can infer action: `{"action":"key","text":"w"}` perhaps sends key. Might need `text:"KeyW"`? Usually browser tool accepts key names like "w", "ArrowLeft", "Space". Need see after building. Could maybe test with `browser key text:"w"` and inspect telemetry. If no effect, try `text:"KeyW"`, or click canvas first. Need be prepared. Need perhaps set a fallback: listen to both `event.code` and `event.key` mapping. This will make any key string work. Implement mapping:
```
function keyId(e){
 const k=e.key.toLowerCase();
 if(e.code==='KeyW'||k==='w') return 'W';
 ...
 if(e.code==='ArrowLeft'||k==='arrowleft'||k==='left') return 'LEFT';
 if(e.code==='Space'||k===' '||k==='spacebar'||k==='space') return 'SPACE';
 ...
}
```
Then browser key text can be 'w' or 'W'. Good. Need if text is "Space" maybe key = ' ' or code? We handle lower 'space' too.
- Need `event.code` may be `'Space'`, key `' '`. Good.
- For arrow keys, preventDefault.
- For R, restart.
- On keydown, `const action=mapKey(e); if(!action)return;` `keys[action]=true;` and apply impulse. But if R, don't set movement key maybe restart and return.
- On keyup, set `keys[action]=false`.
- Use `keys` object with uppercase IDs.
- Need discrete impulse:
```
function keyImpulse(action){
 switch:
  W: moveRelative(1,0,IMPULSE_DT)
 ...
  LEFT: turnPlayer(-1,IMPULSE_DT)
 ...
  SPACE: shoot()
}
```
Need `moveRelative(forward,strafe,dt)`. But with continuous handleHeld, using same values. Need avoid `turnPlayer` changing dir vectors each call. Fine.
- Need `IMPULSE_DT=0.12`; speed=2.6 =>0.312; turn=2.4=>0.288 rad (16.5°). That might be a bit large for one key press, but okay. Could use 0.08 =>0.208 tile, 0.192 rad (11°). For collision from start 1.5 to1.292, still not map wall with r0.22 min1.22, so need 2 presses. Could set start x1.35,y1.35 to make one press collide; but initial viewpoint corridor near walls could look okay. However enemy at x5.5,y1.5 would be slightly off center (dy0.15 at distance4.15 -> ~2°), still within hit radius. We could set start x1.5,y1.5 and impulse dt=0.12. Good.
- Need collision check nearby wall via `S` maybe two presses. Browser tool can send multiple key actions. Could also use A from y1.5 with movement 0.312 -> y1.188, collision clamps to1.22; one press. Great. Since left strafe changes y to1.188, canStand false at y-r=0.968 (<1), so axis movement blocked entirely, y stays1.5. That means the player doesn't even move to1.22 (because we only allow full step or none). To show collision, telemetry y unchanged. Good. Need solid wall collision. Could implement sliding partial step to boundary for smoother:
```
function moveAxis(dx,dy) {
 let step=...
 // binary search to max allowed fraction
}
```
Then from1.5 move -0.312 clamps to1.22, showing contact. But simpler full step blocked may feel sticky when approaching wall at 0.4 away; could implement sub-stepping:
```
const parts=Math.ceil(Math.max(abs(dx),abs(dy))/0.05);
for i parts: if canStand(px+dx/parts,py) px+=...; if canStand(px,py+dy/parts) py+=...
```
This allows sliding up to wall. Great. Use `movePlayer(dx,dy)` with substeps based on distance /0.05. For each substep, axis-separated. Starting y1.5, dy=-0.312, parts7, each -0.0446; moves to y1.267, then next y1.222, then next y1.178 blocked; final y≈1.222. Good. Telemetry shows clamp. Nice. Need collision robust.
- Need `canStand` with r=0.22. At y=1.222, y-r=1.002 >1, okay. Good.
- Need `isSolidAt` four corners; at y=1.222, top corners y1.002, mapY1; okay. At x1.5, corners x1.28/1.72, mapX1; okay. Good.
- Need x start1.5, west wall at x0; S movement dx=-0.312 clamps x≈1.222. Good.
- Need continuous held movement plus impulse could move ~0.3 extra in first frame; okay. Need speed 2.5 and dt max0.05; if browser keyup instant, only impulse. Good.
- Need turning impulse maybe 0.12rad rather than 0.288; maybe use TURN_IMPULSE=0.09rad for one key press. Could set `KEY_TURN_STEP=0.11`. For held, RAF continuous. Need inspect angle change. Fine.
- Need movement impulse maybe use fixed `KEY_MOVE_STEP=0.30` regardless speed. Good. We can call `movePlayer(dirX*0.30,dirY*0.30)`. For held, speed*dt. Need normalize diagonal. Need key impulses for W and A might each be applied separately on keydown; diagonal normalized not crucial.
- Need shooting cooldown on discrete key: if browser sends multiple key events quickly, `keys.Space` might remain true after first if no keyup; subsequent keydown will be ignored since `keys[action]` already true. Need keyup. Browser tool likely sends both. If not, we could allow `event.repeat` to shoot again when cooldown<=0. But need avoid stuck. Could handle keydown for Space regardless of previous key state if `cooldown<=0`, but auto-repeat could fire rapidly; cooldown limits. That's okay. Use:
```
if (action==='SPACE') { if(!e.repeat || shotCooldown<=0) shoot(); }
```
Need maybe keys['SPACE'] true prevents continuous firing; not needed. We can call shoot on each keydown if cooldown ready. Good.
- For movement keydown, if keys[action] already true from a stuck event, ignore impulse? Could still apply to make repeated test steps. Maybe use `if(!keys[action]) applyImpulse`; if no keyup, repeated key events won't move. Could also apply impulse on every non-repeat keydown regardless. Browser tool likely keyup. To be robust:
```
const first=!keys[action]; keys[action]=true;
if(first || !e.repeat) applyImpulse(action); // synthetic keydown always e.repeat=false
```
That means every key event moves. Good. For real held key, auto-repeat has e.repeat true, so no impulse extra; continuous handles. For browser synthetic repeated presses, e.repeat false, each moves. Fine.
- Need `keyup` clear. Good.

Need restart resetting keys perhaps if R is held? `restart()` clears keys. Then R keyup clear. Fine.
- Need update HUD after restart immediate before next frame. Call `render(0)`? Could rely next RAF. To ensure browser inspect after key, call `updateHUD()` and perhaps `drawFrame(performance.now()/1000)`. But restart can call `syncView()` and `render`. Need avoid double RAF but okay.
- Need `runSelfTests()` after initial `resetGame()` and perhaps after each restart? Only startup. Need console logs maybe repeated on restart avoid. Fine.
- Need initial render before RAF? Call `resetGame(); render(0); requestAnimationFrame(loop);`. Good.
- Need console errors clear.

Need implement `updateHUD()` maybe called every frame; expensive DOM changes but okay. Could throttle to only if values changed. Simpler update each frame.
- Need `eventLog` persist. `showToast()` sets eventLog. Need perhaps showToast used by enemy attack frequently could flood; debounce with `lastAttackMessageTime` or `toastTimer`; not important. Could log "Enemy fire -8" repeatedly. Need perhaps clear after 2s to "Standby." but then browser inspect after shoot might see something else if enemy attacks. Better keep last event text until new event; no clear. Toast overlay fades but eventLog stays. Good.
- Need maybe `#lastAction` line. We'll call `setEvent(text, kind)` updates eventLog and toast. Enemy attacks can override shot feedback if they happen concurrently; for testing, first shot likely within initial 1.2s before enemy attack. Fine. Could suppress enemy attack messages from overwriting shot feedback for 0.5s? Not needed.
- Need `showToast` CSS colored by class maybe.
```
toast.className='show '+kind;
```
Need remove class after duration but keep log. Good.

Need maybe `health` display as integer. Health max100. Enemy count alive. Exit locked/open.

Need level "small" 16x11. Good.

Need procedural texture generation maybe need ensure all functions available and no syntax errors. We'll write full file carefully. Let's sketch code in detail.

HTML structure:

```
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Labyrinth 3D — Raycast Maze Shooter</title>
<style>
:root {...}
* {box-sizing:border-box}
html,body {margin:0; min-height:100%; background:...; color...; font-family:...}
body {min-height:100vh; display:flex; justify-content:center; align-items:flex-start; padding:10px 12px 14px; overflow-x:hidden}
#app {width:min(100%,1000px);}
header {...}
...
</style>
</head>
<body>
<main id="app">
 <header class="topbar">
  <div class="brand"><span class="eyebrow">SECTOR 7</span><h1>LABYRINTH <em>3D</em></h1></div>
  <div class="hud">
   <div class="meter"><span>HEALTH</span><strong id="healthValue">100</strong><div class="healthTrack"><i id="healthFill"></i></div></div>
   <div class="pill"><span>ENEMIES</span><strong id="enemyValue">5</strong></div>
   <div class="pill"><span>EXIT</span><strong id="exitValue" class="locked">LOCKED</strong></div>
   <div class="pill"><span>STATE</span><strong id="stateValue">PLAYING</strong></div>
   <button id="restartTop" class="restartBtn">Restart <kbd>R</kbd></button>
  </div>
 </header>
 <section id="stage">
  <canvas id="view" width="960" height="600" tabindex="0" aria-label="..."></canvas>
  <div id="toast" aria-live="polite"></div>
  <div id="vignette"></div> // maybe draw damage flash via CSS opacity
  <div id="overlay" class="hidden">...
  </div>
 </section>
 <section class="controlbar">
  <div class="control-list">
   <span><kbd>W</kbd><kbd>S</kbd> move</span> ...
  </div>
  <p class="rule">Enemy attack rule: ...</p>
  <button id="fireButton">FIRE <kbd>SPACE</kbd></button>
 </section>
 <footer class="statusbar">
   <span id="eventLog">Ready. Find and eliminate every sentry.</span>
   <span id="telemetry">...</span>
 </footer>
</main>
<script>
(()=>{ 'use strict'; ...})();
</script>
</body>
</html>
```
Need maybe CSS `#vignette` pointer-events:none, background radial red, opacity via JS. Could use `damageFlash` variable to set style. Good.
- `#toast` positioned top 14%, center, with CSS opacity0 transform, transition. `show` opacity1. Need ensure no pointer events.
- `#overlay` with backdrop dark, panel.
- `.hidden{display:none!important}`.
- `kbd` styling.
- `#view` display:block;width:100%;height:auto; aspect-ratio:8/5; image-rendering:pixelated; background:#05070a; border etc.
- Stage width maybe `min(100%,960px); margin:auto; position:relative`.
- Header width960 maybe.
- At 1200 viewport, app1000, stage960 centered20 margin. Canvas x=(1200-960)/2=120. Good.
- Topbar maybe height58.
- Controlbar maybe grid. Need maybe total fit:
body padding10, topbar 62, stage600, controls ~72, status~25 + gaps maybe 30 =>799. Just fits. Good.
- Need if viewport height800, potential scroll by ~10px. Fine.
- CSS `h1` margin 0 font-size22.
- HUD flex gap8, maybe width. Need topbar display flex; brand width230; hud flex1 justify-end. likely fits1000. Buttons maybe.
- controlbar display grid columns 1fr auto; control-list flex wrap; rule maybe full? Let's design:
```
.controlbar {display:grid; grid-template-columns:1fr auto; gap:6px 12px; ...}
.control-list {display:flex; flex-wrap:wrap; gap:...}
.rule {grid-column:1/-1; margin...}
.fireButton {grid-column:2; grid-row:1;}
```
Would increase height ~60. Good.
- footer flex justify-between.

Need maybe body background with linear gradients no external.

JS details:

Constants:
```
const canvas = document.getElementById('view');
const ctx=canvas.getContext('2d',{alpha:false});
const W=canvas.width,H=canvas.height,RW=W/2,RH=H/2,TEX=64;
const FOV_PLANE=Math.tan(Math.PI/6); // 60° FOV; maybe 66° = tan(33°)=0.65. Use 0.66.
const PLAYER_RADIUS=0.22, MOVE_SPEED=2.6, ROT_SPEED=2.35, KEY_MOVE_STEP=0.30, KEY_TURN_STEP=0.11;
const ENEMY_RADIUS=0.34, ENEMY_RANGE=5.0, ATTACK_DAMAGE=8, ATTACK_INTERVAL=1.2;
```
Need maybe 3 enemies at least; use5.

DOM refs.

Map:
```
const MAP_ROWS=[...];
const EXIT={x:14,y:9,cx:14.5,cy:9.5};
function wallType(x,y){...}
function buildMap(){ return MAP_ROWS.map(...); }
let map;
```
Need `door` cell 4. `wallType` must not override E. Use:
```
if(ch==='E') return 4;
if(ch==='.') return0;
return ((x*17+y*31)%17<3)?3:((x+y)%5<2?2:1);
```
- Need maybe boundary x0 or y0 use type2 perhaps:
```
if(x===0||y===0||x===15||y===10) return ((x+y)%7<3?2:1);
```
No matter.

`mapAt(mx,my)`: if `my<0||... return1; return map[my][mx];`.
`isSolidAtWorld(wx,wy)` uses floor.
`canStand(x,y)`: four corners plus center. Need check corners with `isSolidWorld`:
```
const pts=[[-r,-r],[r,-r],[-r,r],[r,r],[0,0]];
for ... if(isSolidWorld(x+dx,y+dy)) return false;
return true;
```
Need if x or y out-of-map, isSolidWorld handles.
`movePlayer(dx,dy)`:
```
const steps=Math.max(1,Math.ceil(Math.hypot(dx,dy)/0.04));
for (let i=0;i<steps;i++){
 const sx=dx/steps,sy=dy/steps;
 if(canStand(player.x+sx,player.y)) player.x+=sx;
 if(canStand(player.x,player.y+sy)) player.y+=sy;
}
```
Need if both dx and dy, axis-separated per substep. Good.
- Need after move check exit trigger. Could call in loop after update.
- Need maybe player start x1.5,y1.5. `angle=0`, health100.
- `syncView()`:
```
player.dirX=Math.cos(angle); dirY...
player.planeX=-dirY*FOV_PLANE; planeY=dirX*FOV_PLANE;
```
Normalize angle:
```
function wrap(a){ while(a<0)a+=Math.PI*2; while(a>=2π)a-=...; return a;}
```
Need after restart angle0. Use simple modulo:
```
player.angle=(player.angle+Math.PI*2)%(Math.PI*2);
```
- `turn(amount)` update angle and syncView.

Enemy definitions:
```
const ENEMY_SPAWNS=[
 {x:5.5,y:1.5}, {x:10.5,y:3.5}, {x:7.5,y:5.5}, {x:11.5,y:7.5}, {x:11.5,y:9.5}
];
function makeEnemies(){return ... hp:100, cooldown:1.35+i*0.22,...}
```
Need ensure at x11.5,y9.5 open; row9 x11 '.', yes. Exit at x14. Good.
- Need maybe enemy at x10.5,y3.5 line of sight from start blocked; fine. Need at least one visible initially. First at x5.5,y1.5 is visible. Need perhaps enemy at x10.5,y3.5 can attack via corridors. Fine.
- Need enemy count5. `aliveEnemies()` filter.
- Need maybe enemy can shoot through wall? `hasClearLine` prevents.
- Need maybe line-of-sight from start to first enemy: castWallRay east5.5, target dist4, wall dist5.5; okay.

Textures:
Need write code carefully. Use deterministic PRNG. Let's formulate `noise(x,y,s)`:
```
function hash(x,y,s=0){
 let h = Math.imul(x|0,374761393) ^ Math.imul(y|0,668265263) ^ Math.imul(s|0,1442695041);
 h = Math.imul(h ^ (h>>>13), 1274126177);
 return ((h ^ (h>>>16)) >>>0) / 4294967295;
}
```
Good.

`makePixelTexture(kind)`:
```
const c=document.createElement('canvas'); c.width=c.height=TEX;
const g=c.getContext('2d'); const im=g.createImageData(TEX,TEX); const d=im.data;
for y...
 let r,g,b;
 if(kind==='brick')...
 ...
 const k=(y*TEX+x)*4; d[k]=clamp(r);...
 d[k+3]=255;
g.putImageData(im,0,0); return c;
```
Need function clamp maybe `Math.max(0,Math.min(255,v))|0`.
Brick code:
```
let row=Math.floor(y/16), shift=(row%2)*16;
let bx=(x+shift)%32, by=y%16;
let mortar=bx<2||by<2;
let n=(noise(x>>1,y>>1,1)-0.5)*22;
let tone=(noise(Math.floor((x+shift)/32),row,7)-0.5)*22;
if(mortar){r=55+n*.3;g=50+n*.3;b=44+n*.3;}
else {r=130+tone+n;g=56+tone*.5+n*.5;b=39+tone*.3+n*.4; if(by<4)r+=15,g+=8,b+=4; if(bx<4)r+=8; if(by>12)r-=18,g-=10,b-=5;}
```
Stone:
```
let row=Math.floor(y/21), shift=(row%2)*10; let bx=(x+shift)%21; let mortar= y%21<2 || bx<2; n...
base 82,88,95; cracks if noise(x,y,9)>0.985 maybe dark.
```
Metal:
```
panel x%32,y%32; border; base [54,70,82]; stripe maybe if ((x+y)%16<4 && y>24&&y<40) yellow; rivets near corners radius<2; noise.
```
Door:
```
base dark red [72,22,25], border bright gold x<4 etc; vertical center line; rivets; maybe hazard stripe. Then overlay text via ctx after pixel put:
g.fillStyle='rgba(255,210,100,.9)'; g.font='bold 9px monospace'; g.textAlign='center'; g.fillText('EXIT',32,31); g.font='bold 7px'; g.fillText('LOCKED',32,44); draw lock.
```
Need textual texture may appear mirrored/rotated but fine. Could perhaps not use `font` external; monospace system. Good.
Floor:
```
tile=32; grout x%32<2 || y%32<2; checker=(floor(x/32)+floor(y/32))%2; base 48/38; noise; if hash>0.99 speck.
```
Ceiling:
```
panel lines x%32<2||y%32<2; base 25,30,38; light strips maybe x%32 between14-17 -> +12; n...
```
Need `pixelData(canvas)` after creation:
```
const wallTex = [null, brick, stone, metal, door];
const floorTex = ...; const ceilTex=...;
const floorPixels=floorTex.getContext('2d').getImageData(...).data;
```
Need perhaps use `willReadFrequently:true`? not necessary.

Enemy sprite:
```
function makeEnemySprite(mode){
 const sw=64,sh=96,c=...; const g=...;
 g.imageSmoothingEnabled=false;
 function rect(color,x,y,w,h){g.fillStyle=color;g.fillRect(x,y,w,h);}
 // outline dark
 // maybe draw with blocky polygons via helper
 const main = mode===2 ? '#ff4b3a' : '#8b2730';
 ...
 // legs
 rect('#171b22',18,64,10,27); etc
 // body outline
 fill polygon with g.beginPath...
 ...
 // helmet, visor
 // weapon on right
 // highlights
 if(mode===1) muzzle star at x58,y53
 if(mode===2) { g.globalCompositeOperation='source-atop'; g.fillStyle='rgba(255,80,50,.35)'; g.fillRect(0,0,sw,sh); ...}
 return c
}
```
Need mode-specific base colors. Need use `roundRect`? Canvas roundRect support maybe not all; avoid. Use rects/paths.
- Need draw legs behind body. Use simple polygons:
```
function poly(points,color){...}
```
- Need make silhouette:
  - shadow outline: poly([(17,22),(47,22),(53,35),(49,70),(43,88),(36,88),(32,70),(20,70),(15,35)], '#10131a')
  - body fill: poly([...], '#6f2730')
  - chest plate: fillRect(22,38,20,22,'#a9383b'), center light
  - head: rect(22,12,20,18,'#2f3944'); helmet top rect...
  - visor: rect(25,22,14,5,'#17141a'); eyes rect...
  - arms: rect(10,38,8,24,'#7a3034'), rect(46,38,8,22,...)
  - gun: rect(46,48,15,6,'#252c35'), barrel rect...
  - legs.
```
Need transparent outside. Good.
- Hurt sprite red tint via source-atop; firing flash via star.
- Maybe use mode0/1/2. Need `enemySprites=[...]`.

Portal sprite:
```
function makePortalSprite(){
 c 64x96, ctx;
 radial gradient around center; fill elliptical arch maybe.
 ctx.shadowColor='#56ff9a'; shadowBlur=18;
 ctx.strokeStyle='#79ffb3'; lineWidth=5; beginPath; moveTo(12,88); lineTo(12,35); quadraticCurveTo(32,0,52,35); lineTo(52,88); stroke...
 ctx.fillStyle='rgba(20,255,130,.25)' fill same path maybe;
 swirl lines; text 'EXIT' at y58.
 return c
}
```
Need use gradients, no external. Fine.

Terrain canvas init:
```
const terrain = document.createElement('canvas'); terrain.width=RW; terrain.height=RH;
const tctx=terrain.getContext('2d');
const terrainImg=tctx.createImageData(RW,RH);
for(let i=3;i<terrainImg.data.length;i+=4) terrainImg.data[i]=255;
```
Need maybe `tctx.putImageData` each frame.
`zBuffer`, `wallIds`.

`drawTerrain()` code details:
```
const data=terrainImg.data;
const horizon=RH/2;
for(let x=0;x<RW;x++){ for y=horizon-1..horizon? set dark }
const ray0X=..., ray1X...
for(let y=horizon+1;y<RH;y++){
 const rowDistance=(H/2)/(2*(y-horizon)); // 300/(2*(y-150))
 const stepX=rowDistance*(ray1X-ray0X)/RW;
 ...
 let wx=player.x+rowDistance*ray0X; // floor coords
 const shade=...
 for(let x=0;x<RW;x++){
   const tx=Math.floor(wx*TEX)&(TEX-1); // need bitwise & on signed fine but if wx negative large; Math.floor negative, &63 yields 0..63 due two's complement. Good.
   const ty=Math.floor(wy*TEX)&63;
   const ti=(ty*TEX+tx)*4;
   const fi=(y*RW+x)*4;
   data[fi]=floorPixels[ti]*shade; etc
   const ci=((RH-1-y)*RW+x)*4;
   // maybe ceiling tex coords with offset hx=wx*0.5 etc; use same tx,ty
   data[ci]=ceilPixels[ti]*shade*0.85 + maybe dark blue 3; 
   wx+=stepX; wy+=stepY;
 }
}
```
Need horizon rows:
```
for(let yy=horizon-1;yy<=horizon;yy++){...}
```
But y=horizon is150; ceiling mirror from y=151 maps ci=148, y=299 maps0, so rows0..148 filled. Rows149,150 horizon; set dark. Need y=horizon-1=149 and y=horizon=150. Good.
- Need `shade` maybe:
```
const shade=Math.max(0.16,Math.min(1,1.45/(1+rowDistance*0.18)));
```
At d1 ~1.23→1; d5=1.45/1.9=.76; d10=.52; d150=.05→.16.
- Ceiling shade `shade*0.72` maybe.
- Need maybe floor RGB clamp automatically via Uint8ClampedArray assignment; assigning floats clamps/rounds. Good.
- Need `ctx.drawImage(terrain,0,0,W,H)` with nearest scaling. Good.

`castWalls()`:
Need maybe use `wallTextures[type]`; `wallIds[x]=type`.
- Need `perpWallDist` can be 0 if ray starts inside wall, but start open. Need clamp to0.05.
- DDA loop:
```
let hit=0,type=1,side=0, steps=0;
while(hit===0 && steps++<80) { if(sideDistX<sideDistY) ...; const cell=mapAt(mapX,mapY); if(cell>0){hit=1;type=cell;} }
const perpDist= side===0 ? (mapX-player.x+(1-stepX)/2)/rayX : ...;
```
Wait after stepping into wall cell, `mapX` is wall cell coordinate. Formula for sideDistX before increment was distance to boundary of that cell; indeed after increment, use `sideDistX - deltaX` as distance. Classic code uses:
```
if(side==0) perpWallDist = (mapX - posX + (1 - stepX)/2) / rayDirX;
```
where mapX has been incremented to wall cell. For ray east from x1.5, stepX=1, when entering x7 wall cell, mapX=7, formula=(7-1.5+0)/1=5.5. Correct. For ray west, stepX=-1, entering x0 wall, mapX=0, formula=(0-1.5+(1-(-1))/2)/-1 =(-1.5+1)/-1=.5. Correct.
- Need if rayX negative, sideDistX initial `(px-mapX)*deltaX`; good.
- Need if rayX=0, deltaX=1e30 perhaps; sideDistX huge; no issue. Use `Infinity`.
- `cameraX=2*x/RW-1` with x from0..RW-1. Good.
- `texX` maybe:
```
let wallX = side===0 ? py+dist*rayY : px+dist*rayX;
wallX -= Math.floor(wallX);
let texX=Math.floor(wallX*TEX);
if(side===0&&rayX>0) texX=TEX-texX-1; ...
texX=Math.max(0,Math.min(TEX-1,texX));
```
- `lineHeight=Math.floor(H/dist)` maybe huge at close wall. At d0.5 =1200, y=-300. fine.
- drawImage with dest x=x*2, width2. Need maybe draw to full H and clamp source? Canvas handles.
- Shading:
```
let shade = Math.min(0.72, 0.06+dist*0.065)+(side===1?0.16:0);
if(type===4) shade=Math.min(shade,0.35);
if(shade>0){ctx.fillStyle=`rgba(3,6,12,${shade})`;ctx.fillRect(...);}
```
Using rgba with decimal; okay. Could use black.
- Need maybe horizon scanline overlay later.
- `wallSignature` update after cast:
```
let hash=2166136261; for(let i=0;i<RW;i+=31){ hash=Math.imul(hash ^ (Math.round(zBuffer[i]*1000)|0),16777619); hash=Math.imul(hash ^ wallIds[i],16777619);}
return (hash>>>0).toString(16).padStart(8,'0');
```
Need compute every frame; okay.
- Need perhaps `zBuffer` used by sprites and debug; `castWalls()` must run before sprites. Good.

`castWallRay` for shooting/LOS similar but no plane. Need ensure out-of-bounds walls. Should check maxDist:
```
function castWallRay(ox,oy,dx,dy,maxD){
 let mapX=Math.floor(ox),mapY=Math.floor(oy);
 let deltaX=dx===0?1e30:Math.abs(1/dx),...
 let stepX, sideDistX...
 let dist=0;
 for(let i=0;i<128;i++){
   if(sideDistX<sideDistY){dist=sideDistX;sideDistX+=deltaX;mapX+=stepX;}
   else {...}
   if(dist>maxD) return maxD;
   if(mapAt(mapX,mapY)>0) return dist;
 }
 return maxD;
}
```
Need if starting at cell boundary and dx=0; fine.
- Need maybe ray direction normalized; dir is normalized. For LOS, normalize.
- Need `hasClearLine`:
```
const dist=Math.hypot(...); if(dist<0.001)return true;
const nx=dx/dist,ny=dy/dist;
return castWallRay(x1,y1,nx,ny,dist)>=dist-0.015;
```
If wall at endpoint cell boundary exactly (e.g., target adjacent to wall), might return false. Enemies away from boundary. Good.
- Need `resolveShot(ox,oy,dx,dy,candidates)`:
```
const wallD=castWallRay(ox,oy,dx,dy,30);
let best=null,bestT=Infinity;
for(const e of candidates){if(!e.alive)continue; const vx=e.x-ox...; const t=vx*dx+vy*dy; const across=Math.abs(vx*dy-vy*dx); if(t>0.05 && t<wallD-0.02 && across<ENEMY_RADIUS && t<bestT){...}}
return {target:best,wallD,t:bestT};
```
Need if wallD is exactly enemy t? no. Use `t < wallD - 0.02`. Shots cannot damage through wall. Need wallD perhaps 30 if no wall.
- Need `shoot()` uses `resolveShot(player.x,player.y,player.dirX,player.dirY,enemies)`. Need maybe hit enemy through locked door? wallD handles.
- Need status:
```
if(target){ target.hp-=50; target.hurtTimer=.22; hitMarker=.35; hitKind='hit'; playSound...; if(hp<=0) {alive=false; ...; killEnemy();} else setEvent('DIRECT HIT — sentry damaged','good');}
else { wallSpark=.25; setEvent('SHOT ABSORBED BY WALL — no damage through cover','warn');}
```
Need shot feedback even if cooldown not ready? Maybe event "Weapon cycling..." but not necessary. Need muzzle flash on every shot. Need weapon cooldown set0.26.
- Need `killEnemy(e)`:
```
e.alive=false; spawnBurst maybe; if(aliveCount===0) unlockExit();
```
Need perhaps create a floating `downText` with screen position; could store generic `particles` in screen space:
```
particles.push({x:W/2,y:H/2-40,life:.6,color:'#...'});
```
But death at enemy screen x may be off-center. Could compute billboard screen x from `getSpriteProjection` and push. Maybe not needed. Could add `toast` enough.
- Need maybe draw death explosion at enemy location with a 3D sprite? Could generate simple `burstSprite` and add ephemeral sprite item with type 'burst'. Need complexity. Visual hit feedback can be hitmarker and enemy flash. Fine. Need perhaps 2nd shot kills and enemy disappears; toast. Good.
- Need perhaps if all enemies dead, `map[EXIT.y][EXIT.x]=0; exitUnlocked=true;` and maybe exit state. Need also `wallTextures` door no longer used. Need set event "EXIT UNLOCKED..." and play jingle. Good.
- Need `setEvent` perhaps called in `shoot()` after kill, but `killEnemy` sets event; avoid overwrite. Use return status maybe. We'll order:
```
if(target.hp<=0){target.alive=false; onEnemyDown(target);} else setEvent(...);
```
`onEnemyDown` handles event. Good.

Enemy attack:
```
function updateEnemies(dt){
 for(const e of enemies){
  if(!e.alive)continue;
  e.hurtTimer=Math.max(0,...); e.fireTimer...
  e.cooldown-=dt;
  const dist=...;
  const sees=dist<=ENEMY_RANGE && hasClearLine(e.x,e.y,player.x,player.y);
  e.visible=sees; // maybe for minimap? no
  if(sees && e.cooldown<=0){
    e.cooldown=ATTACK_INTERVAL; e.fireTimer=0.22;
    player.health=Math.max(0,player.health-ATTACK_DAMAGE);
    damageFlash=1;
    setEvent(`ENEMY FIRE — ${ATTACK_DAMAGE} damage (clear sight, ≤5 tiles)`,'bad',1.0);
    playSound('hurt');
    if(player.health<=0) endGame('lost');
  } else if(!sees && e.cooldown<0.25) e.cooldown=0.25;
 }
}
```
Need potential multiple enemies attack same frame: if first kills player, state changes; break. Add check `if(state!=='playing') break`.
- Need `hasClearLine` from enemy to player using map; if player behind wall no damage. Good.
- Need maybe enemy shoot animation frame should appear even if offscreen, but only visible if clear line.

Timers:
```
function updateTimers(dt){
 shotCooldown=Math.max(0,...);
 weaponKick=Math.max(0,weaponKick-dt*5); // line
 muzzleTimer=Math.max(0,...);
 hitMarker=Math.max(0,...);
 wallSpark=...
 damageFlash=Math.max(0,damageFlash-dt*2.5);
 if(toastTimer>0){...}
}
```
Need weaponKick decays with ease maybe `Math.max(0,weaponKick-dt*4)`. Draw uses `kick=weaponKick^2`.
- Need `shotCooldown` maybe 0.24. Browser key shots need wait.
- Need `vignette.style.opacity=damageFlash*0.55`. Do in render or updateHUD.
- Need perhaps particles not used.

`render(t)`:
```
ctx.imageSmoothingEnabled=false;
drawTerrain();
const wallHash=castWalls();
drawSprites(t);
drawMinimap();
drawHUDCanvas(t);
canvas.dataset.wallHash=wallHash;
canvas.dataset.frame=String(frame++);
updateDiagnostics(wallHash);
```
Need `drawTerrain` uses current player angle/sync. Good.
- Need `drawSprites(t)`:
```
const items=[];
for e alive:
 const proj = getProjection(e.x,e.y);
 if(proj) items.push({... sprite: enemySprites[...], scale:.82, ...});
if(exitUnlocked) portal projection...
items.sort((a,b)=>b.depth-a.depth);
for item drawBillboard(item,t);
```
Need `getProjection` returns `screenX,depth,wallBottom`. Need use global plane/dir.
```
function projectSprite(wx,wy){
 const sx=wx-player.x,sy=wy-player.y;
 const invDet=1/(planeX*dirY-dirX*planeY);
 const transformX=...
 const transformY=...
 if(transformY<=0.1)return null;
 return {...};
}
```
Need determinant never zero. Good.
- `drawBillboard`:
```
const h=(H/proj.depth)*item.scale;
const w=h*(item.sprite.width/item.sprite.height);
const x0=proj.screenX-w/2;
const wallBottom=H/2+H/(2*proj.depth);
const y0=wallBottom-h + (item.bob||0);
let start=Math.max(0,Math.floor(x0/2)*2), end=Math.min(W,Math.ceil((x0+w)/2)*2);
let any=false;
for(let x=start;x<end;x+=2){
 const zi=Math.min(RW-1,Math.floor(x/2));
 if(proj.depth >= zBuffer[zi]-0.015) continue;
 const u=(x-x0)/w, sX=...
 if(sX<0||sX>=sw)continue;
 ctx.drawImage(sprite,sX,0,1,sh,x,y0,2,h);
 any=true;
}
if(item.hpRatio<1 && centerVisible) draw health bar.
return any;
```
Need if zbuffer at a column is huge and sprite farther than wall but side portions could be in front? zbuffer handles. Need if `proj.depth` is less than wall depth but wall depth maybe 5.5 and enemy7; no draw. Good.
- Need maybe sort items by depth descending. Portal and enemy can occlude each other based on depth. Fine.
- Need enemy firing/hurt sprite selection:
```
const mode=e.fireTimer>0?1:e.hurtTimer>0?2:0;
```
Need hurtTimer priority perhaps if both; choose hurt first maybe. Fine.
- Need bob: `Math.sin(t*2.4+e.id)*2` perhaps small full-screen px maybe not scale with distance. Could use 1.5. Fine.
- Need portal scale0.95, bob maybe `Math.sin(t*3)*3`, `glow` maybe globalAlpha oscillates. Could draw with `ctx.globalAlpha=0.85+0.15*Math.sin(t*4)` then reset. But column slices with globalAlpha; okay. Need portal maybe always visible after unlock. Good.
- Need health bar draw after sprite, perhaps even if wall hides center. Determine:
```
const ci=Math.floor(proj.screenX/2);
const centerVisible = ci>=0&&ci<RW&&proj.depth<zBuffer[ci];
```
Need draw bar at y0-8; could be above wall due to perspective but okay. Need no occlusion per bar width; if center visible, good.
- Need maybe draw a faint elliptical shadow under sprite: can draw if center visible, with `ctx.fillStyle='rgba(0,0,0,.35)'`, ellipse at wallBottom. But if wall occludes center, skip. Good. Could draw before sprite slices; health bar after. Need order: shadow before sprite. Add `ctx.beginPath(); ctx.ellipse(screenX,wallBottom,w*0.3,Math.max(2,h*0.035),0,0,2π); ctx.fill();` Need `ellipse` support. Should be fine. Could avoid for compatibility. Fine.

`drawMinimap()`:
```
const cell=9, ox=W-16*cell-14, oy=14, pad=4;
ctx.save(); ctx.globalAlpha=.88; 
ctx.fillStyle='rgba(8,12,18,.78)'; ctx.fillRect(ox-5,oy-5,Wcell+10,Hcell+10); stroke...
for y,x: if map[y][x]>0 fill color based type, else fill '#151b20'; if exit cell open maybe green.
for enemies alive: draw red square/dot.
draw exit: if locked amber at cell14,9 else green.
draw player triangle/circle and FOV line.
ctx.restore();
```
Need ensure map array values. Need maybe `map[y][x]` can be4 locked, color amber. Need draw `#` walls. Good.
- Need maybe show "MAP" label. Fine.
- Need perhaps minimap reveals all enemies; okay.

`drawHUDCanvas(t)`:
- crosshair:
```
ctx.save(); ctx.strokeStyle='rgba(240,245,220,.8)'; ctx.lineWidth=2; lines around center; small dot.
if(hitMarker>0){... draw X green}
if(wallSpark>0){... orange sparks}
```
- weapon:
```
const kick=weaponKick*weaponKick;
const recoilY=kick*28; const recoilX=kick*6;
ctx.save(); ctx.translate(W/2+recoilX, H+recoilY);
drawGun(ctx); // shape coordinates relative to bottom center, y negative
ctx.restore();
if(muzzleTimer>0) drawMuzzleFlash(...);
```
Need draw order: weapon before muzzle? Muzzle flash should be in front of gun. Could draw gun then flash with additive.
- `drawGun` perhaps:
```
function drawGun(g){
 // arm/glove at bottom right
 g.fillStyle='#2b3040'; poly points...
 // rifle body centered
 const grad=g.createLinearGradient(0,-180,0,0);...
 g.fillStyle=...; g.beginPath(); 
 // barrel at center with dark metal
 // stock, hand, highlights
}
```
Need coordinate design relative to W/2,H:
  - gun base from x=-90 to90, y=-120..20.
  - barrel from x=-18,y=-190 to18,-80; dark barrel.
  - body from -65,-100 to65,0.
  - hand/glove at -100,-20 etc.
  - maybe two-handed futuristic rifle.
  - muzzle at (0,-190).
```
function drawGun(g){
 // vertical barrel and receiver
 g.fillStyle='#10141b'; g.fillRect(-18,-190,36,120);
 g.fillStyle='#394452'; g.fillRect(-12,-190,24,100);
 // sight
 g.fillRect(-4,-202,8,14);
 // body
 poly([[-70,-80],[70,-80],[90,-10],[62,20],[-62,20],[-90,-10]], '#293242');
 // panel
 poly([[-48,-66],[48,-66],[60,-18],[45,-2],[-45,-2],[-60,-18]], '#4b5665');
 // orange stripe
 ...
 // hands
 poly([[-110,-15],[-65,-35],[-40,10],[-60,40],[-120,30]],'#6c4a35');
 ...
}
```
Need maybe flash at (0,-190) plus center screen? Weapon barrel pointing up from bottom center, crosshair at y300; muzzle near y410 (H-190=410), not aligned with crosshair center y300. In FPS, gun barrel muzzle often lower; flash around y400, okay. But crosshair at center y300; shot direction from center, flash visually lower. Could place muzzle at y350 (H-250) maybe. Let's choose gun taller: barrel top at -245 -> y355, closer to crosshair. Need not occlude center. Use -215 =>385. Fine. Muzzle flash at center x480,y385. Good.
- Need weapon kick moves gun down (positive y) and maybe rotate slightly. We can `ctx.translate(W/2, H+recoilY); ctx.rotate(kick*0.04);`.
- Muzzle flash drawn after restore, at x=W/2+recoilX, y=H-205+recoilY. Need use same barrel top coordinate. Let's define `MUZZLE_Y=-205`.
```
if(muzzleTimer>0){ const a=muzzleTimer/0.28; ctx.save(); ctx.globalCompositeOperation='lighter'; ctx.translate(W/2,H-205+recoilY+...); draw star polygons with scaling...; ctx.restore();}
```
Need weapon drawn with `translate(W/2,H+recoilY)` so muzzle y=H-205+recoilY. Good. Need maybe rotate affects coordinates; if rotate around bottom center, muzzle x shifts; could ignore. Draw flash at unrotated x.
- Need shell casing maybe:
```
if(muzzleTimer>0.12) draw small yellow rotating rect at xW/2+80,yH-100...
```
- Need hit marker at center maybe green/red X. Good.
- Need damage vignette CSS overlay covers entire stage; canvas also maybe red border. Could update style.
- Need top canvas HUD maybe show current objective in small text at top-left:
```
ctx.fillStyle='rgba(0,0,0,.45)'; fillRect(12,12,250,36); text 'ELIMINATE 5 SENTRIES' etc.
```
But minimap top-right, top-left might overlay wall. Nice. Need maybe `remaining` number. Need not duplicate DOM but immersive. We'll draw small objective.
- Need draw bottom ammo "∞" perhaps.
- Need draw floor/horizon line maybe. Fine.

`drawGun` must be deterministic. Need no external gradients? createLinearGradient is internal. Fine.

`drawHUDCanvas` objective:
```
ctx.font='bold 14px monospace'; fillText(...)
```
Need `font` uses system. Good.

`updateHUD()`:
```
healthValue.textContent=player.health;
healthFill.style.width=...; healthFill.style.background=...
enemyValue.textContent=aliveCount;
exitValue.textContent=exitUnlocked?'OPEN':'LOCKED'; className...
stateValue.textContent=state==='playing'?'PLAYING':...
overlay.classList.toggle('hidden',state==='playing');
if(state!=='playing'){ overlayTitle..., overlayText...}
vignette.style.opacity=(damageFlash*0.55).toFixed(2);
telemetry.textContent=`POS ${x.toFixed(2)},${y.toFixed(2)} · YAW ${(angle*180/π).toFixed(1)}° · HP ${health} · LEFT ${alive} · WALL ${lastWallHash}`;
```
Need maybe update telemetry every frame; okay. Need if state won/lost, overlay text set every frame; fine.
- Need `document.body.dataset.state=state`, `dataset.health`, etc perhaps for inspect. Add in updateHUD.
- Need `canvas.dataset.wallHash=wallHash` from render. Need `lastWallHash` global.
- Need maybe `canvas.dataset.health=...`.
- Need maybe `window.__mazeDebug.snapshot()` returns map etc. Good.

`showToast`/`setEvent`:
```
function setEvent(text,kind='info',duration=1.5){
 eventLog.textContent=text;
 toast.textContent=text;
 toast.className=`toast show ${kind}`;
 toastTimer=duration;
}
```
Need CSS `#toast.show`. If `toast.className='show good'`, base styles by ID still apply. Good.
`updateTimers`: if toastTimer<=0 and toast.classList.contains('show') remove. Need avoid resetting class too often.

`endGame(result)`:
```
state=result; keys={}; overlay...; setEvent(...); playSound...
```
Need maybe no `state='lost'` while updateEnemies loop continues; break. Good.

`checkExit()`:
```
if(exitUnlocked){
 const d=Math.hypot(player.x-EXIT.cx,player.y-EXIT.cy);
 if(d<0.55){ endGame('won'); }
 else if(d<1.2 && !exitHintCooldown) ...? 
} else {
 // if near door and pressing forward? maybe show locked hint occasionally
 if(Math.hypot(player.x-14.5,player.y-9.5)<1.4 && lockedHintTimer<=0){ setEvent(`EXIT LOCKED — ${aliveCount} enemies remain`,'warn'); lockedHintTimer=2.5;}
}
```
Need avoid message flood. Add `lockedHintTimer` updated in timers. But not necessary; we can just check on collision? Could detect when `movePlayer` blocked by door. Simpler: if d<1.25 and locked and `lockedHintTimer<=0`, show. Need if standing near door, repeated every2.5s. Fine.
- Need `checkExit` called each frame after movement. Need if gameState playing.
- Need `exitUnlocked` after last enemy. Need map cell set0.
- Need `endGame('won')` sets event "MISSION COMPLETE..." and overlay. Need perhaps health remains. Good.

`restart()`:
```
map=buildMap(); exitUnlocked=false; player={x:1.5,y:1.5,angle:0,health:100,...}; syncView(); enemies=makeEnemies(); state='playing'; clear keys; timers=0; damageFlash=0; setEvent('Level restored. Five sentries active.'); updateHUD(); render(performance.now()/1000); canvas.focus(); 
```
Need if called from button, focus button might capture keys; we can focus canvas so keyboard works. But focusing canvas may show outline; CSS `outline:none` maybe. Fine.
- Need `restart` preserve audio context.
- Need maybe reset `lastWallHash` so signature initial same. `render` recomputes.
- Need `frame` maybe not reset? Could reset to0 for diagnostics. Fine.
- Need initial viewpoint and health check via telemetry and wallHash after restart. Need verify same wallHash as initial. Good.

Self-tests:
Need pure functions operate with current map and player perhaps. Could define:
```
function selfTest(){
 const tests=[];
 const d=castWallRay(1.5,1.5,1,0,10); tests.push({name:'east wall',pass:Math.abs(d-5.5)<0.01,value:d});
 const los=hasClearLine(1.5,1.5,5.5,1.5); tests.push...
 const blocked=hasClearLine(1.5,1.5,8.5,1.5); tests.push({pass:!blocked});
 const fake1={x:5.5,y:1.5,alive:true}, fake2={x:8.5,y:1.5,alive:true};
 tests.push({name:'shot hits visible sentry',pass:resolveShot(...).target===fake1});
 tests.push({name:'wall blocks shot',pass:resolveShot(...[fake2]).target===null});
 const oldX=player.x, oldY=player.y; // movement collision test with helper maybe movePlayer would mutate player; don't do. Instead canStand(0.8,1.5) false; canStand(1.5,0.8) false; canStand(1.5,1.5) true.
 tests.push...
 const all=tests.every(t=>t.pass);
 console.info('[Labyrinth3D] startup checks', all?'PASSED':'FAILED', tests);
 window.__startupChecks=tests;
}
```
Need `resolveShot` expects candidates with `alive`; okay.
- Need `hasClearLine` from start to x8.5,y1.5: castWallRay east max7, wall at5.5 => returns5.5, false. Good.
- Need `resolveShot` from start east with fake behind wall: wallD5.5, t7, reject. Good.
- Need maybe cast wall ray at start east actually x7 wall value>0; yes.
- Need collision `canStand(0.8,1.5)` true? Let's check x0.8 with r0.22 corners x0.58,1.02; x0.58 is in cell0 wall, so false. Good. `canStand(1.5,0.8)` false due y0.58. Good.
- Need perhaps exit reachable test via BFS:
```
function reachableToExit() { BFS from start to neighbor of door treating locked door as wall; check some adjacent cell reachable }
```
Could include self-test. Need map built with locked door. Use BFS over open cells only (`mapAt===0`), from (1,1) to (13,9) or (14,8). Need check if any neighbor of door reachable. Need perhaps map row9 x13 open and row8 x14 open; BFS should reach. Add:
```
function exitAdjacentReachable(){...}
```
Need maybe no third-party. Good. This is robust.
- Need log tests to console; no errors. Could perhaps use `console.table` but maybe browser inspect console receives. Use `console.info`.
- Need maybe self-tests run before initial render after `resetGame()`, map built. `castWallRay` uses map; good.
- Need `window.__mazeDebug` set after functions; expose:
```
window.__mazeDebug={ snapshot(){...}, restart, castWallRay, resolveShot, lineOfSight:hasClearLine };
```
Need `snapshot` include wallHash, player, enemies, state, exitUnlocked, map maybe not. Good. Could include `zBuffer` samples and `wallIds` samples.
```
function snapshot(){
 return {state,health:...,enemies:aliveCount,exitUnlocked,player:{...},wallHash:lastWallHash, z:[...], wallIds:[...], keys:{...}, event:eventLog.textContent};
}
```
Need browser tool maybe can inspect via `window.__mazeDebug` only if JS eval; but telemetry DOM enough. Still useful.
- Need maybe expose `fire`, `move`, `turn` functions for automated checks? We can add `debugStep(action)` maybe. But not needed. Could add:
```
step(action,amount){...}
```
But maybe avoid.
- Need perhaps browser inspect can evaluate expressions? Not sure. We can add a query parameter? Not needed.

Need audio function details:
```
let audioCtx=null;
function ensureAudio(){ if(audioCtx)return; try{ audioCtx=new (window.AudioContext||window.webkitAudioContext)(); }catch(e){} }
function tone(freq,dur,type='square',gain=.05,endFreq=null){ if(!audioCtx)return; try{ const o=...,g=...; o.frequency.setValueAtTime(...); if(endFreq)...; g.gain.setValueAtTime(...); g.gain.exponentialRampToValueAtTime(.001,audioCtx.currentTime+dur); o.connect(g).connect(audioCtx.destination); o.start();o.stop(...);}catch(e){} }
function noise(dur=.1,gain=.08){ ... create buffer ...}
function playSound(name){ ensureAudio(); if(!audioCtx||audioCtx.state==='suspended') audioCtx.resume().catch(()=>{}); ...}
```
Need autoplay restrict if resume promise; okay. Need no console errors from unhandled promise. Use `.catch`. Need if context absent, no errors. Could call on key events. Need maybe browser tool no audio device; AudioContext could throw; catch.
- Need maybe `ensureAudio` called from `shoot` triggered by keydown; good.
- Need use `Math.random` for noise? No external; okay. But deterministic not required. Could use hash. Simpler fill `Math.random()*2-1`.
- Need sound for hit/hurt/win. Fine.

Need render function call from restart while `toastTimer` etc. Need `render` calls `updateHUD` maybe could recurse? keep separate. `loop` calls `render` then `updateHUD`. `restart` calls both. Fine.
- Need `updateHUD` overlay text set each frame; `showToast` event maybe. Fine.
- Need maybe `stateValue` class color. Could set via CSS based on state. Use `className` maybe.

Need potential issue with `event.preventDefault()` on `Space` while focus on Fire button: pressing Space could click button and also shoot; our window keydown prevents default, so button click not triggered. Fine. Need maybe pressing R while focus on button still works.

Need potential issue with `canvas.dataset.wallHash` when render called by restart and loop same frame; no issue.
- Need `document.body.dataset.wallHash` perhaps for inspect. Add.

Need maybe check stable wall rendering by hash after restart. Need initial wallHash expected maybe compute from browser telemetry; after restart should match. We can inspect. Need maybe if damage/timers don't affect hash. zBuffer/wallIds only depend on player position/angle and map. At initial and restart map same; hash same. Good.

Need browser interactions:
1. Load page via browser tool `reload` maybe need first write index.html. Then `inspect` initial output and console. Use `screenshot`.
2. keyboard `w`, `ArrowLeft` maybe check telemetry position/yaw. Need maybe `browser key` with text "w". Could inspect after each. Need perhaps click canvas first? Window listener no focus needed, but browser key action likely sends to focused document; okay.
3. collision: press `a` or `s` and see position clamps. Need perhaps after moving/turning, side wall not necessarily north; if turn changed angle, A direction changes. Could test collision after restart with S or A. Need maybe use `r` to restore initial. Then `s` and check x clamps ~1.22. Need browser key action maybe event.key. We'll try.
4. fire: press `Space` and inspect eventLog, screenshot. Need maybe enemy in initial center, direct hit. Need check weapon feedback. Could maybe use `browser motion` to capture frames after firing. Need maybe click Fire button and screenshot. We can try.
5. sample scene: screenshot and wall hash from telemetry; maybe press no keys and inspect hash stable across frames. Could use motion to capture multiple frames and compare hash. Need maybe `browser motion` returns frames maybe. We can call `inspect` after a second and see same wallHash. Need if enemy attacks and player health changes, wallHash unaffected. Good.
6. restart: press `r`, inspect telemetry for POS1.50,1.50 YAW0.0 HP100 LEFT5 WALL same initial. Need perhaps top restart button via click too; requirement "Provide Restart", we can check button exists. Maybe click top restart after moving to verify via telemetry. Browser click coordinates. Need perhaps use `r` and button both. We'll see.

Need perhaps use browser tool's `inspect` with text parameter maybe it can query DOM. Need discover. We'll call `browser action:"inspect"` and see output. Good.

Need write file now. This is a large file maybe ~1000 lines. Need ensure syntax. We can use write tool with full content. Let's draft carefully. We have plenty token budget. Need maybe use bash `node --check` on extracted script? We can write file then run `node` syntax check by extracting script with no DOM execution? `node --check` on JS snippet might parse. Could use `node -e` with regex to extract script and `new Function(...)` to parse without running. Or use `node --check` after extracting to temp. We can use DOM unavailable but parse only. Good. Need perhaps cwd /tmp/job-gypnoY; write absolute or relative. We'll use `index.html`.

Let's write full file. Need be meticulous with escaping within tool call JSON; tool handles content string. We'll include backticks in JS template literals; fine. Need use no `${}` accidental? fine. Need careful about `<` in JS strings? e.g. comparing `<` inside `<script>` okay. Need avoid `</script>` sequence in JS strings; none. Need HTML entity? fine.

Let's compose.

Potential syntax issue in CSS `color-mix`? avoid for compatibility. Use standard.

JS gradient names. Need no use of `roundRect` maybe.

Let's write.

Need inspect syntax. I notice potential bug: keydown handler for Space:
```
if (first || (!e.repeat && action !== "SPACE")) impulse(action);
if (action === "SPACE" && first) shoot();
```
For action SPACE, first true -> condition `first` true, so impulse(action) called, which calls shoot(); then second `if` calls shoot again, but shotCooldown prevents second. So okay but weird; shot once. For synthetic repeated Space with `first=false` due stuck key, no shot; cooldown likely. But if first true, impulse shoots, second shoot blocked by cooldown. Fine. Could simplify but not needed. Need maybe `keys.Space` remains true and no keyup, browser repeated key events won't fire; but likely keyup. Could perhaps allow repeated synthetic by handling action SPACE even if !first. We'll consider later.

Need parse syntax with node. Need extract script from HTML and `node --check` perhaps. Use node script to read file, regex /<script>([\s\S]*?)<\/script>/ and `new Function(js)` parse. Need no execution; `new Function` compiles. Let's do.

Need run browser. Use browser action reload/inspect/screenshot. Let's start with reload and inspect.

Initial screenshot looks good! Need note canvas occupies x~120..1077, y77..677 in 1200x800. We see corridor, enemy centered, textured walls, floor, ceiling, weapon, minimap, HUD. Console startup checks passed. Need inspect stable wall rendering perhaps hash. Need test movement/turning/collision/fire/restart. Need understand browser key syntax. Let's use key "w" and inspect.

Interesting health dropped to60 already after ~? Browser reload to key action likely took ~6 sec (5 attacks). That's okay; clear rule. Position1.93 from W: impulse0.3 plus continuous held perhaps 0.13? Actually moved0.43, good. Need test turning. But note enemy attack health 60 means 5 hits at1.2s; browser tool interaction time maybe ~6 sec. Fine. Need maybe health can drain to zero during checks; restart helps. Need testing movement/turning near starting area. Use `ArrowRight` maybe text "ArrowRight". Need perhaps browser key text maybe "ArrowRight" accepted. Let's call and inspect.

Turn works, yaw13° (0.11+ continuous). Health20 due time. Need avoid game over before fire/restart? Could restart now. Need test collision near wall. Use `r`, then maybe `a` to hit north wall and inspect. Need maybe health starts100 but enemy attacks quickly; tool calls maybe ~5s each due screenshot process? Health drops between calls. Restart resets. Need perhaps browser key `r` and then `a` in same tool call? Could use key text "r" then next call "a". Or perhaps browser tool supports multiple key events via text string? Maybe `text:"r a"`? Not sure. We can call parallel? Need sequential. We have time. Need maybe reduce enemy attack rate for playability? It's 1.2s per enemy, but only first enemy sees player initially; health from100 to60 over ~6s. Real-time browser tool calls take ~6s due screenshots. If user plays, health drains slowly but enough time to kill first enemy in 2 shots (0.26s cooldown). Fine. However initial enemy starts shooting after1.35s; health100 gives ~15s. That's okay. Need maybe first attack rule clear. Good.

Need verify collision: press "r" then "a" quickly. Browser tool call itself maybe 0ms frame but real wall clock between calls maybe several seconds; health may drop but still >0. We can perhaps restart then use `key text:"a"` in same call? Tool only one action. Could use `text:"r"` then next `text:"a"`. Need maybe use click `fireButton` after restart to avoid health drop etc. Fine.

Need perhaps check stable wall rendering: hash initial `7ab03aa0`; after W `147c1019`; after turn `cc49d44c`. Need restart returns `7ab03aa0`. We can later compare.

Need maybe test fire. Restart, then key "Space" or click fire button. Need check weapon feedback and event. Because enemy initially centered, direct hit. Need maybe screenshot after fire. Need maybe muzzle flash visible. Browser screenshot after key likely immediate but tool call may be delayed due internal render; however `muzzleTimer=0.3` and screenshot perhaps after ~0ms? In previous key actions, screenshot attached shows no muzzle because we didn't shoot. Let's do restart then Fire button click perhaps screenshot. Need coordinate for button around x1002,y712 from screenshot. Could use `browser click x:1002,y:711`. Or key Space easier. Need maybe after restart, browser key "Space" and screenshot. But tool call time between restart and key might allow health to drop; still fine. Need perhaps use key `Space` from initial orientation. Let's do restart first and inspect to confirm initial hash/health.

Restart via R works and initial hash same `7ab03aa0`, health100, viewpoint1.50,1.50,yaw0. Need test collision. Press `a` (left strafe north into wall). Health may drop but okay. Need inspect after.

Collision: y clamps at1.24 near north wall, good. Need perhaps a second A press to verify no further movement through wall. Could call `a` again; likely y remains1.24. But health drops maybe. Could use same call perhaps. Need do quickly.

Wall hash stable `ae94fd8c` across two A presses (same position), good stable wall rendering. Need fire from this position perhaps enemy slightly off-center due y1.24 vs enemy y1.5, ray east at y1.24 passes perpendicular0.26 <0.34, so still hits. Good. Need maybe press r to restore health then Space. Need perhaps test weapon feedback via click Fire button, which might happen with screenshot immediate. Let's restart first.

Need fire. Use browser key "Space". Need see event/hitmarker/muzzle. Let's call.

Excellent screenshot shows muzzle flash, hit marker, hurt enemy red, shell casing, event direct hit, wall hash same initial. Good weapon feedback. Need maybe check shots cannot through wall from logic self-tests already console passed, but perhaps need verify startup checks details? Console shows object array but not names in DOM. Could perhaps use browser inspect with text? We can maybe use browser tool `inspect` with `text` parameter to evaluate? Need understand tool. Could call `browser action:"inspect", text:"window.__startupChecks"` maybe? The tool's `text` may be CSS selector or JS? Let's test. Need be cautious; the browser tool might treat text as selector for inspect. Could perhaps call `action:"inspect", text:"window.__startupChecks"` and see. But no need if console says passed. Yet requirement specifically "shots cannot damage an enemy through a wall" and "enemies occluded by walls"; our self-test checked shot logic and line of sight. Need perhaps verify sprite occlusion visually. Could perhaps turn to view a wall with enemy behind and see sprite hidden. Need maybe use browser debugging to move/rotate to a position where an enemy behind wall would project; perhaps trickier. But startup checks pass and zbuffer rendering code. Need perhaps test with a hidden in-page scene? Could use debug object to move player? We didn't expose `player` mutation. Could expose a debug method `setView` perhaps to check occlusion. But not necessary. However requirement says "Verify: Test movement and turning near starting area, check collision against a nearby wall, and fire to inspect weapon feedback. Sample the scene for stable wall rendering, then use Restart and check initial viewpoint and health." We have done all these. Need maybe "use Restart" could mean click button, not just R. We should click the top Restart button to verify button works. Need do that. We can click approximate x1010,y40 from screenshot. Then inspect initial viewpoint/health. Let's do. Need perhaps first move/turn or fire then click. We just fired and health68. Click restart button. Need browser click coordinates perhaps `x:1010,y:39`. Let's call.

Restart button works. Need maybe check "stable wall rendering" more explicitly over time. We saw hash 7ab03aa0 initial and after several frames/restart; after A at wall hash ae94fd8c stayed same across two presses. Could perhaps call `browser action:"motion"` to capture frames and check no flicker. Need perhaps do that. Need maybe use motion action with delta? Let's see. `browser motion` maybe captures animation frames. Could call with no text. Need maybe from initial state, enemy attacks will affect health, but wall hash stable. Let's call motion maybe returns 4 frames.

We need finalize soon. Need consider any essential issues discovered. Motion frames show stable walls, same hash. However health drops fast due enemy attack. Could be considered gameplay too punishing? Start enemy visible and attacks every1.2s from t1.35, health to44 after~7s, game over in~15s if idle. That's okay for an FPS but perhaps user wants playable; 5 enemies and 100hp, first enemy can kill in 15s if idle. Shooting requires 2 shots; can kill quickly. But moving through maze with enemy attacks could be hard but playable. Need maybe reduce damage or increase cooldown to make game more forgiving. Not essential; clear rule says 8 damage every1.2s. Fine.

Need check bug: initial enemy attacks from outside view? It has line of sight and distance4.0, okay. Need maybe "Enemies must be occluded by walls" our zbuffer. Good.

Need perhaps fix potential severe issue: keydown Space calls shoot twice as noted, cooldown prevents second, fine. But if `keys.SPACE` remains true after browser tool key doesn't send keyup, repeated Space might not fire because `first=false` and no impulse. Yet browser tool does send keyup likely. Fine.

Need perhaps check restart after win/game over overlay button. We didn't verify win/game over states. Need perhaps reason through code. Could be bug: `endGame('lost')` from updateEnemies sets state lost; subsequent `checkExit()` still called in loop because inside same `if (state==='playing')` block started before state change; checkExit doesn't check state. Suppose player near exit when health reaches0, checkExit could call endGame('won') and override lost; unlikely. More importantly after state lost, updateTimers/render; overlay shown. Restart button works. Fine.
- Need potential bug: win state check after all enemies dead and player reaches exit. map door cell open; can player actually reach center? Need map cell x14,y9 open, adjacent x13,y9 open and x14,y8 open. `canStand(14.5,9.5)` corners x14.28/14.72 within cell14; y9.28/9.72 within cell9. Map row9 x14 open. Good. `checkExit` d<.55 triggers. Need map cell x15 wall; okay.
- Need potential bug: sprite projection and zbuffer when exact wall at x7; fine.
- Need potential bug: `castWalls()` if no hit, uses type1 and dist25 but texX computed from last mx/my maybe out of bounds; mapAt handles; no issue.
- Need potential bug: floorcasting `Math.floor(wx * TEX) & 63` when wx huge negative: bitwise on 32-bit signed; still yields mod64, okay.
- Need potential bug: `startupChecks` uses `resolveShot` with fake enemy objects lacking hp/alive? We set alive true. Fine.
- Need potential bug: browser `dom.toast.className` with `show good` works; CSS `#toast.good` applies. Good.
- Need potential bug: use `Array.prototype.includes` supported. Fine.
- Need potential bug: `canvas.focus({preventScroll:true})` perhaps throws in older; catch calls canvas.focus. Fine.
- Need potential issue: all enemies visible on minimap through walls; requirement "Enemies must be occluded by walls" refers 3D render, not minimap. Fine.
- Need potential issue: shots cannot damage through wall; resolveShot uses wallDistance from center ray. Could an enemy partially visible near an edge be hit though ray passes close to wall? If ray passes through open cell to enemy and cross within radius, wallDistance > t. Fine. Could ray hit an enemy behind a wall if enemy radius overlaps ray before wall but center behind wall? Our candidate test doesn't check enemy center t vs wallD if t < wallD then center is before wall. If center behind wall t>wallD, rejected. Good.
- Need potential issue: enemy occlusion by walls if sprite depth > wall depth; zbuffer per stripe. Good.
- Need potential issue: enemy attacks through walls: hasClearLine uses castWallRay and mapAt; good. Wall type4 exit door blocks line of sight until unlocked. Fine.
- Need perhaps "at least three enemies": 5. Good.
- Need "small level with reachable exit": startup BFS passed. Good.
- Need "Display controls": yes.
- Need "A/D strafe": yes, tested A. Need D not specifically tested but same code.
- Need "Left/Right arrows to turn": tested right, left same.
- Need "W/S move": tested W, S via logic maybe not explicitly. Could test S collision maybe no time. But code same. We can perhaps final mention W/Right tested; S/D/Left unverified but same handler. Need report which behaviors remain unverified.
- Need "Sample scene for stable wall rendering": motion frames and hash. Good.
- Need "use Restart and check initial viewpoint and health": both R and on-screen button tested. Good.
- Need "Game Over": not verified in browser. Need mention unverified. Win state and enemy unlock not verified end-to-end; startup BFS and logic. Need perhaps could do a quick end-to-end check by exposing debug? We have ~5 min but user says finalize asap. We could maybe implement a quick keyboard cheat? No. Need not. We can mention unverified. But perhaps we can verify Game Over quickly by letting idle browser for ~15s with motion; health currently44 after 2.24s, need maybe 7 more attacks ~8s. Browser motion duration fixed2.24s; could call a few times. But user says finalize soon, no need. Could maybe use browser key "r" then wait motion repeated to see game over, but that takes calls. Better not, given time. Need perhaps final save file already saved. Could make one minor essential fix: maybe make initial enemy attack less punishing? Is that essential? Let's think. During browser checks, health dropped from100 to44 within 7 seconds motion, plus tool latency ~? Actually motion 2.24s but DOM says health44 from prior health100 maybe 7 hits, implying more time passed between tool calls (maybe ~8s). Real user can kill first enemy in 2 shots quickly, but if they read controls for 15s before starting, game over. A playable shooter should perhaps not start enemy attack until player moves or shoots, or give a 3s grace period. That would be a nice essential usability fix: set first enemy cooldown to 3.0s, or add global `gameStartGrace` 3s. The clear rule still says every1.2s when in sight. But if idle at start, enemy should attack under clear rule; perhaps no issue. However game could become unplayable if player is slow to act. But health100, 13 attacks ~15s; enough to read controls maybe not. We can increase initial cooldown to 2.5s for first enemy and 1.6+ for others, still clear. But this changes behavior and requires recheck. Is it essential? Not really. Could soften attack damage to5 or interval1.5s, but displayed rule would need change. The user didn't specify damage/cooldown; clear rule is explicit. We could reduce to6 damage every1.3s and update text, but more edits/time. Better leave.

Need perhaps fix a more concerning bug: The initial enemy's ``fireTimer`` visual flash appears only .24s, but attack interval1.2; fine. Enemies can damage player from behind/offscreen if line of sight; that's consistent, though maybe player can't see them. Clear rule says line of sight, not field of view. Fine.

Need maybe check enemy count after kill? We only shot once, enemy hp50. Could perhaps fire second shot to verify enemy count decrements and unlock logic. Need maybe use browser key Space again after cooldown; current state health44 and enemy hp50. We could press Space now and check count4. This would verify shooting can kill and maybe count. Could be worthwhile and quick. Need perhaps health still >0. Press Space. Let's do one call; then restart to initial. But user says finalize as soon as possible. One call maybe okay. Could also use `browser key text:"Space"`; because from previous click restart, keys.Space likely cleared, so should fire. Need check.

We verified Game Over state and overlay! The Space press was ignored due state game over. Need now click overlay Restart Mission to verify restart from game over, perhaps important. Need do one call then final. But perhaps need fix potential key Space double issue? no. Let's click overlay button around x600,y431 and inspect. Then perhaps restart state. Need maybe there is a bug: clicking overlay restart button might also trigger canvas click? Overlay button is above canvas; click event doesn't bubble to canvas (canvas not ancestor), so fine. Need check.

All good. Need decide whether to make any final edit. Maybe simplify Space keydown double call? Not essential but could fix to avoid weirdness. Could change:
```
if (first || (!e.repeat && action !== "SPACE")) impulse(action);
if (action === "SPACE" && first) shoot();
```
to:
```
if (action === "SPACE") { if (first || !e.repeat) shoot(); }
else if (first || !e.repeat) impulse(action);
```
This would make synthetic repeated Space fire even if key state stuck, and avoid double call. Better. But changing now would require recheck. Could still do a quick edit and reload inspect maybe within time. Is it essential? Not really. But user says fix only essential issues. Avoid change. Need maybe ensure file present. Yes. Need perhaps final response concise, report checks and unverified. Need mention file path. Need not mention every detail, but instructions ask briefly report what actually checked and behaviors remain unverified. Need include:
- `index.html` saved, self-contained.
- Checks: initial render/console no errors, startup checks passed; W and ArrowRight changed position/yaw; A into nearby north wall clamped y1.24 and repeated press didn't pass; wall hash stable across motion frames; Space produced hit/muzzle/recoil/hitmarker/direct hit event; Game Over at zero health and overlay; Restart via R, top button, overlay button restored HP100, enemies5, POS1.50,1.50, YAW0, wall hash7ab03aa0.
- Unverified: full playthrough to defeat all enemies, unlock exit, reach win state; shots through walls/sprite occlusion end-to-end visually (though startup logic checks passed). Maybe S/D/Left keys not individually browser-tested; same handlers. Need mention. Also maybe enemy count decrement after kill not observed end-to-end; we only damaged first enemy. Need mention. Could say "End-to-end win, all-enemy kill/unlock, and visual occlusion behind a wall were not browser-played; startup assertions covered wall-blocked shots and exit reachability." Need maybe note "no console errors". Good.
- Need maybe mention health attack rule verified from health drops with event message. Good.

Need ensure final answer doesn't say saved now if no changes since write. It's saved. Could say "Final file is /tmp/job-gypnoY/index.html." Need perhaps path clearly. Good.

Need perhaps no more tools. Final.