Wolfenstein raycaster · glm-4.7-flash

Let me build a single-file raycaster maze shooter. I'll write the whole thing in one go, then test in the browser.

Key features:
- Raycasting with DDA, textured walls (procedural textures generated on offscreen canvases).
- Enemies: sprites rendered with depth buffer occlusion.
- Controls: W/S forward/back, A/D strafe, arrows turn, Space shoot. Mouse optional.
- Collision: circle vs grid.
- Level: small maze map, exit tile, ≥3 enemies.
- Health, enemy count HUD, game over, win state, restart.
- Weapon feedback: muzzle flash, weapon bob.

Let me write the code carefully.

Map: 16x16 grid. 1 = wall, 0 = floor, 2 = exit (locked until all enemies dead; walkable only when unlocked), 3 = exit. Let me use: 0 empty, 1 brick wall, 2 stone wall variant, 9 exit tile (locked door — render as special wall when locked, floor/walkable when unlocked). Actually simpler: exit is a wall tile type 'E' that becomes passable and renders differently (glowing) when unlocked. When player walks onto it, win.

Map design (16 wide × 12 tall):

```
1111111111111111
1..............1
1.111.11111.1..1
1.1.....1...1..1
1.1.111.1.111..1
1.1.1...1.....E1
1...1.1.11111.11
1.1.1.1........1
1.1...1111.11.1
...
```

Let me just design it carefully as strings. Player start at (1.5, 1.5) facing east. Exit at right side.

Map rows (16 chars each), 12 rows:

```
row0:  1111111111111111
row1:  1......2.......1
row2:  1.1111.2.1111..1
row3:  1.1..........E.1
row4:  1.1.111.111.1111
row5:  1...1...1.....31
row6:  1.111.1.1.111..1
row7:  1.1.........1..1
row8:  1.1.11111.1.1.11
row9:  1...1.....1...31
row10: 1.1...111.111..1
row11: 1111111111111111
```

Hmm, that's fiddly. Let me be careful and design a simple valid maze. I'll write it and then verify with a quick script (flood fill) in bash before rendering. Actually I can just verify in browser test. Better: write a small node/python check via bash for flood fill from start to exit and enemy positions.

Enemies: '3' markers in map → enemy spawn positions, floor tile. Need at least 3.

Let me design:

```
################
#S.....#....3..#
#.###..#.####..#
#.#3#..#....#..#
#.#.####.##.#.##
#.#......##....#
#.##.###.##.##.#
#....#3..#..#..#
####.#.###..##.#
#3...#.....#...#
#.####.####.##E#
################
```

Each row must be 16 chars. Let me count each:

Row0: "################" =16 ✓
Row1: "#S.....#....3..#" → # S . . . . . # . . . . 3 . . # = 16 ✓ (S = player start)
Row2: "#.###..#.####..#" → count: #,.,#,#,#,.,.,#,.,#,#,#,#,.,.,# =16 ✓
Row3: "#.#3#..#....#..#" → #,.,#,3,#,.,.,#,.,.,.,.,#,.,.,# =16 ✓
Row4: "#.#.####.##.#.##" → 16? #,.,#,.,#,#,#,#,.,#,#,.,#,.,#,# =16 ✓
Row5: "#.#......##....#" → 16 ✓
Row6: "#.##.###.##.##.#" → #,.,#,#,.,#,#,#,.,#,#,.,#,#,.,# =16 ✓
Row7: "#....#3..#..#..#" → 16 ✓
Row8: "####.#.###..##.#" → #,#,#,#,.,#,.,#,#,#,.,.,#,#,.,# =16 ✓
Row9: "#3...#.....#...#" → 16 ✓
Row10: "#.####.####.##E#" → #,.,#,#,#,#,.,#,#,#,#,.,#,#,E,# =16 ✓
Row11: "################" ✓

Check connectivity: player at (1,1) — well (1.5,1.5). Exit at (14,10).

Path check: from (1,1): down col1 rows1-... row2 col1 '.', row3 col1 '.', row4 col1 '.', row5 col1 '.', row6 col1 '.', row7 col1 '.', row8 col1 '#' (row8 starts "####"), so col1 blocked at row8. From row7 col1-4 "...." → row7: cols1-4 open, col5 '#'. row8 col4 '.', col5 '#', col6 '.', col7 '#'. Hmm row8: cols: 0#,1#,2#,3#,4.,5#,6.,7#,8#,9#,10.,11.,12#,13#,14.,15#. So from row7 col4 down to row8 col4 '.', then row9 col4 '.'. Row9: "#3...#.....#...#": col1 '3', col2 '.', col3 '.', col4 '.', col5 '#', cols6-10 '.....', col11 '#', cols12-14 '...', col15 '#'.

row10: "#.####.####.##E#": col1 '.', col2-5 '#', col6 '.', col7-10 '#', col11 '.', col12-13 '#', col14 'E', col15 '#'. Wait col14 is E? "#.####.####.##E#": chars: 0#,1.,2#,3#,4#,5#,6.,7#,8#,9#,10#,11.,12#,13#,14E,15#. Yes col14 E, row10. But row9 col14 '.', and row9 col12-14 '...'. And row10 col11 '.', row9 col11 '#'. Hmm, how to reach E at (14,10)? From row9 col14 down to row10 col14. Row9 col14 reachable? Row9 col11 is '#', cols12-14 open, col15 '#'. To get to row9 cols12-14: from row8 col14 '.', and row8 col14 reachable from row7 col14? Row7: "#....#3..#..#..#": col12 '.', col13 '#', col14 '.', col15 '#'. So col14 row7 '.', row8 col14 '.', row9 col14 '.', row10 E. Good.

How to reach row7 col14? Row6 col14 '.', row6: "#.##.###.##.##.#" col14 '.'. Row5 col14? Row5: "#.#......##....#" col14 '.'. Row5 cols11-14 '....'. Row4 col14? Row4 ends "#.##": col14 '.', wait row4: "#.#.####.##.#.##": col14 '.', col15 '#'. Hmm row4 col14 '.', row4 col12 '.', col13 '.', col14 '.', col15 '#'. Row3 col13,14: "..". Row3: "#.#3#..#....#..#": cols12 '.',13 '.',14 '.',15 '#'. Row2 col13 '.', col14 '.': ".." at end. Row1 cols13,14 '.','.'; row1 col11 '3'? Row1: "#S.....#....3..#": col12 '.', col13 '.', col14 '.', col11 '3'. Wait chars: 0#,1S,2.,3.,4.,5.,6.,7#,8.,9.,10.,11.,12 3? Let me recount: "#S.....#....3..#": # S . . . . . # . . . . 3 . . # → indices 0-15: 0'#',1'S',2'.',3'.',4'.',5'.',6'.',7'#',8'.',9'.',10'.',11'.',12'3',13'.',14'.',15'#'. So enemy at (12,1) region. Row1 cols8-14 all open, row2 col8 '.', col13 '.', col14 '.'.

So top-right corridor: row1 col8-14, connects down via row2 col8 to row3? Row3 col8 '.'. Row3: "#.#3#..#....#..#": 0#,1.,2#,3'3',4#,5.,6.,7#,8.,9.,10.,11.,12#,13.,14.,15#. So col8-11 open, col12 '#', col13-14 open. Row3 col8 connects row2 col8 to row1 col8. Good, so player can reach row1 right side → down col13/14 → row3 col13-14 → row4 col12-14 → row5 col11-14 → row6 col14 → row7 col14 → row8 col14 → row9 col14 → row10 col14 E. Reachable! 

Other enemies: (3,3) '3' at row3 col3, (6,7) at row7 col6, (1,9) at row9 col1. All reachable?

Enemy at (3,3): row3 col3. Neighbors: row3 col1 '.', col2 '#', col4 '#'. row2 col3 '#', row4 col3 '.'. Row4: "#.#.####.##.#.##": col3 '.', col4 '#'. So (3,3)-(3,4) corridor. Row4 col3 connects row5 col3 '.'. Row5 col3 '....' region: row5 cols3-8 '......'? Row5: "#.#......##....#": 0#,1.,2#,3.,4.,5.,6.,7.,8.,9#,10#,11.,12.,13.,14.,15#. So cols3-8 open. Row5 col3 up to row4 col3 up to enemy. Good, enemy reachable. Also row5 col8? col9 '#'. Row5 col4 up row4 col4 '#'. Row6 col4 '.'? Row6: "#.##.###.##.##.#": col4 '.'. So row5 col4 down to row6 col4, row7 col4 '.', row7 cols1-4 open, col5 '#'. Row7 col6 '3' (enemy): neighbors row6 col6 '#', row8 col6 '.', row7 col5 '#', col7 '.'. Row7 col7 '.'? Row7: "#....#3..#..#..#": 0#,1.,2.,3.,4.,5#,6'3',7.,8.,9#,10.,11.,12#,13.,14.,15#. So enemy at col6, col7 '.', col8 '.'. Row8 col8 '#'? Row8: "####.#.###..##.#": 8'#'. Row8 col7 '#'. Hmm enemy (6,7): row8 col6 '.', so down: row8 col6 '.', row9 col6? Row9: "#3...#.....#...#": col6 '.', row9 cols6-10 open. Row10 col6 '.'. So enemy at (6,7) reachable from row9 corridor. Row9 col6 reachable from row9 col1-4? col5 '#'. Row9 cols6-10: connected up row8 col10 '.', col11 '.'? Row8 col10 '.', col11 '.'. Row8 col10 up row7 col10 '.', row7 col10-11 '..', row6 col10 '#', col11 '#'. Hmm row7 col10 connects left? row7 col9 '#'. So pocket: row7 col10-11, row8 col10-11, row9 col6-10. Row9 col6-10 connected to row10 col6 '.' → row10 col6: neighbors row10 col5 '#', col7 '#', row11 '#'. Dead end but fine. And row8 col6 '.', connects row7 col6 (enemy) and row9 col6. So enemy (6,7) reachable via row9 cols6-10 which connect via row8 col10/11 to row7 col10/11... but is that pocket connected to the rest? Row9 cols6-10: col5 '#', col11 '#'. Row8: col6 '.', col10 '.', col11 '.'. Row7: col10 '.', col11 '.'. Row6: col10 '#', col11 '#'? Row6: "#.##.###.##.##.#": 0#,1.,2#,3#,4.,5#,6#,7#,8.,9#,10#,11#,12.,13#,14.,15#. Yes col8 '.' at row6! Row6 col8 '.', row5 col8 '.', row7 col8 '.'. So row5 cols3-8 → row6 col8 → row7 col8 → row7 col7 '.' → enemy col6. And row7 col10-11 pocket connects row8 col10-11 → row9 col10. Fine.

Enemy at (1,9): row9 col1. Neighbors: row8 col1 '#', row10 col1 '.', row9 col2 '.'. Row10 col1 '.', row10 col0 '#', col2 '#'. Row9 col2,3,4 '...'. So enemy at (1,9) reachable via row9 col2-4 ← row8 col4 ← row7 col4. Good.

Enemy at (12,1): row1 col12, reachable via row1 corridor. Good.

Player start 'S' at (1,1). Exit E at (14,10). 4 enemies ≥3. 

Wall variety: I'll add texture variety — maybe use different wall types: '#' = brick, and maybe make some walls 'B' stone for variety. Could just vary texture by tile parity... Simpler: texture chosen by map value: '#'=brick, and I can make row/col-based shading. Or add 'B' stone walls in a few places. Eh — I'll do: brick texture for '#', and for border walls use different? Keep simple: two wall types via different chars? All walls are '#'. I could procedurally vary tint based on side (N/S vs E/W) which is standard. Add slight variation using map cell coordinates for texture variant selection (brick vs mossy). I'll do two textures: brick and stone, chosen by (x+y)%2 for variety. Fine.

Now the raycaster:

Standard DDA raycast per screen column. Wall texture 64x64 procedural. Use an offscreen canvas with ImageData for the main render? For performance and pixel manipulation, render to an ImageData buffer directly at internal resolution (e.g., 640×400 or 480×300), then drawImage scaled to display canvas with imageSmoothing off. That's classic.

Floor/ceiling: could do floor casting but that's expensive; simple solid colors with gradient is fine — maybe simple horizontal gradient bands. Keep ceiling dark, floor lighter.

Texture generation: create 64x64 textures via a function drawing pixels: brick pattern, stone, exit door (locked: metal door with lock; unlocked: glowing green). Generate as Uint8ClampedArray or canvas getImageData. I'll store textures as {data: Uint8ClampedArray, w, h} for fast sampling into main buffer.

Sprites: enemies drawn as procedurally generated sprite textures (e.g., imp/monster: 64x64 with transparent background). Render with billboard projection: transform sprite pos to camera space, project, scale, draw columns with depth test against zbuffer.

Enemy AI: states idle/chase/attack/hurt/die. If line-of-sight (raycast clear) and within distance, chase player (move with collision). Attack: if distance < 0.9 and LOS, attack with cooldown, deal 8-15 damage with a windup. Simple: enemy attacks when dist < 1.2 and LOS clear, every 1s, dealing 10 dmg, with a flash/animation.

Shooting: hitscan — cast ray from player center; find nearest enemy whose angle within small threshold and LOS clear and closer than wall hit distance. Damage 34 (3 hits to kill, enemy hp 100). Muzzle flash + weapon recoil animation + hit flash on enemy.

Enemy rendering states: normal, attack (different frame?), dead (fade out corpse). Keep simple: draw enemy sprite tinted red briefly when hit; on death, spawn "dead" sprite (flat) that fades.

Weapon: draw a simple gun at bottom center (canvas 2D drawing over the buffer, on the display canvas after drawImage). Muzzle flash when firing.

HUD: health bar, enemy count, message area ("Find the exit — 3 enemies remain", etc.). Controls text.

Game states: 'play', 'dead', 'won'. Restart button + R key.

Damage flash: red vignette when hit.

Let me now think about performance: internal res 480×300 might be fine. Use 400×250? Let's use W=480, H=300 internal. 144k pixels per frame with per-pixel work — okay in JS.

Actually simpler approach: internal canvas 480×300, get ImageData, per-column wall drawing with texture sampling per pixel, floor/ceiling as precomputed gradient fills (fill rows before walls using putImageData? No—ImageData includes everything). I'll fill ceiling/floor into buffer first as vertical gradients (precompute row colors), then draw walls per column, then sprites per column.

Z-buffer: array of per-column wall distances for sprite occlusion.

Sprites per column: for each enemy, compute screen x range, for each column in range if depth < zbuf[x], sample sprite texture column.

Mouse turning optional: add pointer lock? Skip or add simple mousemove when clicked. I'll add optional pointer-lock mouse look — small code. Actually "must not be required" — I'll include it but it's optional. Keep it minimal: click canvas → requestPointerLock, mousemove → rotate. Fine.

Sound: skip (no assets needed; could do WebAudio beeps but optional). Maybe tiny WebAudio for shoot/hit — nice but adds risk. I'll add minimal WebAudio synth sounds (shoot noise, hurt). Small. Let's include simple ones with try/catch.

Turn speed: arrows rotate 2.5 rad/s. Move speed 3 units/s. Strafe 2.4.

Collision: circle radius 0.25, check axis-separated movement.

Shooting cooldown 0.4s. Auto-fire on hold? Space held → fire when cooldown ready. Fine.

Exit: when locked, tile renders as wall type 'door' (solid, blocks). When unlocked, becomes walkable floor with glowing floor marker? Simpler: exit tile 'E' is a wall (door texture) while locked; when all enemies dead, becomes walkable and render as open doorway (draw as floor... tricky in raycaster). Alternative: keep exit as walkable tile 'E' (floor) from start, marked with a glowing exit sign wall adjacent? Hmm.

Simplest robust: exit is a door wall tile. When locked: solid door texture, blocks movement, can't win. When unlocked: door "opens" — treat as non-blocking, and render it as... it would look weird rendering nothing. Option: render exit door texture with green glow when unlocked but still solid, and reaching it = touching it (player adjacent within 0.7). That avoids rendering issues: "reach the exit" = get close to the door. Win when player within 0.6 of exit tile center while unlocked. Actually better: when unlocked, make it passable and render as an open passage with a bright exit glow texture on the surrounding? Passing through would render nothing for that tile — looks like a gap in wall, which is fine actually (doorway). But ray passing through exit tile hits wall behind (border '#' at row10 col15? Exit at (14,10), col15 is '#', row9 col14 is '.', so rays through doorway hit wall further). A gap in the wall looks like an open doorway — acceptable and cool. But then the door frame... fine.

Decision: exit tile 'E': solid door while locked; when unlocked → walkable (treated as empty for collision and raycasting), plus a green glow overlay at that tile? I'll render a "victory light" by making rays that pass through... overkill. Keep it: unlocked door becomes open gap; player walking into tile center (dist < 0.5 to tile center) triggers win. Also show message "EXIT UNLOCKED — escape!". Good.

Ray hit on door tile when locked: use door texture. Also door tiles should render both sides — fine, standard.

Line of sight function: DDA from enemy to player, step through grid, blocked if wall or locked door.

Enemy movement collision: same circle collision, and don't walk into other enemies (simple: skip). Enemy speed 1.2. Only move when has LOS to player OR recently seen. Simplify: enemies always chase if LOS or player fired recently (alerted). Let's do: each enemy has aggro flag; aggro if LOS within 8 units, or player shoots (all enemies within 10 with LOS? or all aggro on shot). Keep: on player shot, aggro all enemies with LOS; enemies with LOS chase regardless; once aggroed, chase player position always (they know where you are). Simple and functional.

Attack rule: dist < 1.1, LOS clear, cooldown 1.2s, deal 8+rand*6 damage, show enemy "lunge" (scale pulse) and player red flash.

Enemy sprite art: 64×64 procedural demon: body, horns, eyes. I'll draw with canvas 2D onto offscreen canvas, then getImageData. Two frames: idle and attack (arms raised / mouth open)? Keep one frame + hit tint + death sprite (splat). Maybe two frames via parameter.

Now write code.

Main structure:

```js
const IW=480, IH=300; // internal
canvas display: fill window or fixed 960×600. Use CSS to scale. Display canvas 960×600, drawImage(internal,0,0,960,600) with smoothing off.
```

Texture gen functions returning Uint8ClampedArray(64*64*4):

- brick(x,y): pattern rows 8px, offset alternating, mortar lines.
- stone: noise blotches.
- door: metal with rivets + lock; locked version red-ish; unlocked overlay green glow (separate texture).
- exitOpen: not needed.

Sprite gen via canvas 2D:
- enemy frame: dark red demon.
- dead: puddle.

Render loop with requestAnimationFrame, dt clamp.

Buffer: `const img = ctx.createImageData(IW,IH); const buf = img.data;`

Ceiling/floor precomputed: for y < IH/2 ceiling color gradient dark blue-gray; below floor gradient brown. Precompute per-row base colors into arrays; fill buf each frame (144k*... fill loop). Fine.

Wall casting:

```
for x in 0..IW:
 cameraX = 2*x/IW - 1
 rayDir = dir + plane*cameraX
 DDA...
 perpWallDist
 lineHeight = IH / perpWallDist
 texX from hit
 drawStart/end with texture sampling, shade by distance & side
 zbuf[x] = perpWallDist
```

Fisheye correction with perpWallDist standard.

Shading: multiply rgb by min(1, 1/(1+dist*0.15)) or similar; side darkening 0.75.

Sprites:

```
invDet = 1/(planeX*dirY - dirX*planeY)
for each enemy alive or corpse:
 relX = ex-px, relY = ey-py
 transX = invDet*(dirY*relX - dirX*relY)
 transY = invDet*(-planeY*relX + planeX*relY)
 if transY <= 0.1 skip
 screenX = (IW/2)*(1+transX/transY)
 size = IH/transY * scale
 sort by transY desc
 draw columns where transY < zbuf[col]
```

Vertical offset: enemies stand on floor: drawEnd = h/2 + IH/(2*transY) ... standard: spriteHeight = IH/transY; drawStartY = IH/2 - spriteHeight/2 (centered). For floor-standing: bottom at IH/2 + IH/(2*transY). Use full height sprite covering floor to ceiling? Wolfenstein enemies are shorter. I'll place sprite with vertical center offset: spriteScreenHeight = IH/transY * 0.8; bottom aligned to floor line: floorY = IH/2 + (IH/(2*transY)); drawEnd = floorY; drawStart = floorY - spriteScreenHeight. Good.

Weapon drawing: on display canvas overlay after drawImage: draw gun shape with paths at bottom center, bob offset from walk, recoil from shoot, muzzle flash circle. Use ctx2d drawing (display ctx). Also HUD text and bars on display canvas.

HUD: top-left "HEALTH" bar; top-right "ENEMIES: n"; messages center-top; crosshair center.

Game over / win overlays: dark overlay + text + "Press R or click Restart".

Restart: reset state from map.

Now write the code. Let me draft key functions carefully.

```js
const MAPSTR = [...rows];
const MW=16, MH=12;
let grid; // parsed: 0 empty, 1 brick, 2 stone, 3 exit door
```

Parse: '#'→1, 'S'→0 start, '3'→0 enemy, 'E'→3 (exit door).

isWall(x,y): cell>0 (3 counts as wall while locked; when unlocked treat as 0 for both ray and collision). I'll handle: `solidAt(cx,cy)` returns grid val, with exit unlocked → 0.

Raycast DDA handles: if cell==1 → brick/stone texture by ((cx+cy)&1); cell==3 → door texture (locked or open? when unlocked, treated as 0 so rays pass).

Wait, when unlocked, exit tile becomes empty → rays pass through → gap. Good.

Texture sampling: texture arrays as Uint8ClampedArray with 64 width. texX = int(frac * 64). Sample per y step.

Wall render per column:

```
lineH = IH / perp
drawStart = max(0, IH/2 - lineH/2)
step = 64/lineH
texPos = (drawStart - IH/2 + lineH/2) * step
for y=drawStart..drawEnd:
  texY = texPos & 63
  color from tex
  shade
  buf[idx...]
```

Side shading: multiply 0.7 when side==1.

Distance shading: `s = Math.min(1, 6/(perp+1.5))`? Let's use shade = 1/(1+perp*perp*0.06)? Simpler linear: `sh = Math.max(0.35, 1 - perp/14)`. Times side factor.

Enemy sprite textures: generate with canvas:

```js
function makeSprite(draw){ c=document.createElement('canvas'); c.width=64;c.height=64; g=c.getContext('2d'); draw(g); return g.getImageData(0,0,64,64).data; }
```

Demon: ellipse body dark red (#7a1010), horns, yellow eyes, claws. Attack frame: mouth open bigger, eyes brighter. I'll parametrize.

Also hit flash: when drawing enemy, if hitTimer>0, add red tint to pixels (boost r).

Death: corpse sprite (dark splat ellipse low). Draw corpses without occlusion issues same way.

Now enemies update:

```js
e = {x,y,hp:100,cool:0,hitT:0,dead:false,aggro:false,deadT:0}
```

LOS(px,py,tx,ty): DDA grid walk; also treat unlocked exit as passable. Step along direction with small increments (0.1) checking solid — simpler sampling approach; fine for small map. Use ray marching with step 0.05? Distance up to ~16 → 320 samples per enemy per frame ×4 enemies = ok but let's use 0.15 step. Fine.

Attack: if !dead && dist<1.15 && losT: if cool<=0: player.hp -= 8+Math.random()*7; cool=1.3; e.attackT=0.4; flash.

Chase: if aggro && !dead: dir to player; try move with collision (try x then y). If dist<0.8 stop.

Aggro: each frame if LOS && dist<9 → aggro=true. On shoot: enemies with dist<12 && LOS → aggro. Simplify: shooting aggros all enemies with LOS (dist<14).

Player shoot:

```
if fireCool<=0:
 fireCool=0.35; recoil=1; flash=0.08; sound
 for each alive enemy:
   compute angle diff between player dir and vector to enemy
   if abs(angleDiff) < atan(0.35/dist) (i.e., enemy radius ~0.3) or dist<0.6:
     cast ray toward enemy: dist to wall along that ray (use castRay function returning distance)
     if wallDist > distToEnemy: hit! enemy.hp -= 34; enemy.hitT=0.15; aggro
     break at first hit? Actually hitscan should hit nearest enemy in path. Iterate enemies sorted by distance, first one whose ray passes within radius and before wall → hit, break.
```

castRay(px,py,dx,dy) returns perp? For hit test, we need actual distance along ray to wall (not perp). DDA returns side dist; the true distance along the ray = the DDA distance (since we step the ray). I'll write generic castRay returning distance along ray to wall hit.

Angle-based hit test: compute unit vector to enemy; angle between player dir and that vector; threshold = Math.atan2(0.35, dist) approx for enemy half-width. Use dot product: dirDot = (dx*ex_n + dy*ey_n) where... use perpendicular distance: project enemy pos onto ray: t = relX*rdx + relY*rdy; if t>0: perp = |relX*rdy - relY*rdx| (cross). If perp < 0.4 && t < wallDist → hit candidate. Choose nearest t. Nice, no angles needed.

Exit check: unlocked && dist(player, exitCenter) < 0.6 → win.

Exit center: (14.5, 10.5).

Win/lose: state='won'/'dead'; show overlay; stop input effects. R restarts.

Sounds: WebAudio — create on first user gesture. shoot: short noise burst; hurt: low tone; enemyDie: descending tone; win: arpeggio. Keep ~30 lines. Use try/catch.

Controls display: bottom-left text on canvas HUD or HTML overlay. HTML overlay div with instructions is easy and always visible. I'll do HTML HUD overlay (absolute positioned) with health bar as HTML? Canvas HUD is fine too. I'll do HTML for controls & message, canvas for crosshair/health? Simpler: HTML HUD: health bar div, enemies count, message, controls list, restart button. That satisfies "display the controls" clearly.

Game over/win overlays also HTML divs with Restart button.

Let me now write the file.

Key input: keydown/keyup set flags; prevent default for arrows/space. R key → restart.

Pointer lock optional: canvas click → requestPointerLock; mousemove → if locked rotate by movementX*0.0025. Wrap in try.

Movement: velocity from keys each frame; normalize diagonal; collision resolve axis-separated with radius 0.22:

```
function tryMove(nx,ny){
  r=0.22;
  if(!blocked(nx,py)) px=nx;
  if(!blocked(px,ny)) py=ny;
}
blocked(x,y): check the 4 corners cells around circle: for cx in floor(x-r)..floor(x+r), cy likewise: if solid return true. Actually check cells overlapped by circle: floor(x-r),floor(x+r) etc. (ignores corner rounding, fine).
```

Enemy uses same blocked with exit unlocked state.

Rendering fill order: ceiling/floor rows into buf via loop (precompute rowColor arrays), then walls, then sprites sorted far→near (or use zbuf test per column which handles order... sprites overlap each other though; sort by dist desc and per-column zbuf test handles mutual occlusion adequately since nearer sprite drawn later overwrites and zbuf test only vs walls — mutual occlusion needs sprite zbuf too. Standard trick: sort far to near and just test against wall zbuf; near sprite drawn later covers farther — correct). Then putImageData.

Then display: dctx.imageSmoothingEnabled=false; drawImage(internal,0,0,dispW,dispH). Then weapon, crosshair, damage vignette (canvas), all scaled coordinates.

Display size: canvas width 960 height 600, CSS max-width 100%. Keep fixed aspect.

Bob: weapon y offset = sin(walkPhase)*8 when moving.

Muzzle flash: when flashT>0 draw yellow radial at gun tip; also brighten scene? Just weapon flash.

Damage vignette: if hurtT>0, draw red translucent rect border (radial gradient) on display.

Enemy attack visual: enemy attackT>0 → use attack frame sprite + slight lunge scale.

Also crosshair: small cross at center.

Now, potential perf: per-pixel loops in JS at 480×300 = fine.

Write it.

Texture generation details (procedural, math-based, into Uint8ClampedArray directly):

brickTex:
```
for y,x:
 row = y>>3 (8px bricks); mortar if y%8==0 or (x + (row&1)*4) % 8 == 0 → gray mortar (100,95,90)
 else base color with per-brick variation: hash(brickId) → r=140+h*40 etc. Add noise: n = hash(x,y) small.
```

stoneTex: base gray-blue, blotches via value noise: v = sin(x*0.7)*... plus random per 8x8 cell jitter. I'll do: cell = ((x>>3)+(y>>3)); base 105 + hash variations; edge darkening near cell borders for blocks; noise per pixel.

doorTex (locked): dark metal vertical planks, rivets around edge, red warning stripe? Make it distinct: gray steel with rivets and a red "LOCK" light. Unlocked: bright green glowing doorway — but unlocked tile is passable, not rendered. Hmm, then player never sees green door. The message tells them. Also I can render the open doorway glow: when a ray passes through unlocked exit tile... skip. Alternatively keep the door rendered even when unlocked but passable — rays would hit it and block view... that's fine too actually! Keep exit tile rendered as door wall always (raycast hits it), but collision passable when unlocked. Then player walks "through" the door — visually walks into the door texture then wins. Slightly odd but the win triggers at dist<0.6 to center so they barely overlap. Hmm, walking into a wall visually then winning = feels like the door opens. Alternative: two textures: locked (red X) and unlocked (green glowing open doorway) and keep it solid-rendered. Player approaches, sees door change from red to green glow when unlocked, walks into it → win. That's clear and looks good. Do that: exit always solid for rays; solid for movement only when locked; win check dist<0.55.

Good, that's cleaner.

Texture ids: 1 brick, 2 stone, 3 door. Choose 1/2 by (cx+cy)%2? That might look noisy; instead: outer border rows/cols → stone, inner → brick? Map: use cell coordinate: if cx==0||cy==0||cx==MW-1||cy==MH-1 → stone else brick. Fine.

Now sprite generation with canvas 2D drawing:

```js
function demonSprite(attack){
  ...64x64, transparent bg
  body: radial gradient dark red ellipse cx32 cy40 rx16 ry18
  head circle at cy20 r10
  horns: triangles
  eyes: yellow glowing (brighter if attack)
  mouth: black arc; attack: big open mouth with teeth
  arms/claws at sides; attack: raised
}
```

Corpse: dark red splat ellipse at bottom with bones? Simple.

Now write everything. Also verify map connectivity via quick node/python script.

Let me write index.html now.

Details for wall texture sampling with side==1 flipping? Not necessary.

texX computation:
```
if side==0: wallX = py + perp*rayY ... standard:
wallX = side==0 ? py + perp*rayDirY : px + perp*rayDirX
wallX -= floor(wallX)
texX = floor(wallX*64)
if (side==0 && rayDirX>0) texX = 63-texX; if (side==1 && rayDirY<0) texX=63-texX; (flipping for consistency)
```

DDA:

```
mapX=floor(px), mapY=floor(py)
deltaX = abs(1/rdx) (Infinity if 0)
...
loop up to 64 steps: step, check cell
if cell>0 → hit
```

perp = side==0 ? sideDistX - deltaX : sideDistY - deltaY. Clamp min 0.01.

Line height: IH/perp. drawStart = floor(IH/2 - lineH/2) etc.

Sprite draw:

```
function drawSpriteColumn-based:
 spriteH = (IH/transY)*0.85
 width = spriteH (square)
 floorY = IH/2 + IH/(2*transY)
 drawEndY = floorY, drawStartY = floorY - spriteH
 startX = screenX - width/2 ...
 for sx in [ceil(startX), endX): if sx in [0,IW) and transY < zbuf[sx]:
   texX = ((sx - startX)/width*64)|0
   for sy...
     texY = ((sy - drawStartY)/spriteH*64)|0
     a = alpha; if a<40 skip
     shade
```

Skip transparent pixels (alpha check) since sprite canvas has transparent bg.

Enemy hit tint: add +100 to r channel.

Sorting sprites by transY descending before drawing.

Enemies dead: corpse sprite scale smaller (0.35 height), draw flat at floor.

OK, HUD update via DOM each frame is fine (textContent cheap; only update when changed—just update, fine).

Now code writing. Also add a minimap? Optional — skip to save time, or tiny minimap helps testing. Add small minimap in corner showing walls + player + enemies (only aggro'd?). It's nice for verification. I'll add a small minimap top-left under health? Could clutter. I'll include a simple minimap — helps me verify maze layout via screenshot. Keep it toggleable? Just always show, small (map 16×12 → 4px cells = 64×48). Draw on display canvas after HUD: walls dark, player dot, enemies red dots (alive). Fine.

Timer: requestAnimationFrame with performance.now dt, clamp 0.05.

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

Also win check needs unlocked computed: enemiesAlive==0.

Message logic: default "Eliminate all demons, then reach the glowing EXIT door." When unlocked: "EXIT UNLOCKED — find the green door!" transient messages (hit marker?).

Controls HTML:
- W/S — move
- A/D — strafe
- ←/→ — turn
- SPACE — shoot
- R — restart

Let me write.

One more: player.hp=100; hp<=0 → state dead, overlay "YOU DIED". Restart button in overlays and top HUD.

Edge: enemies shouldn't stack on player; attack range 1.15 while stop dist 0.8 → they attack from 0.8–1.15. ok.

Player collision radius vs enemy? Enemies could overlap player; attack stops at 0.8, fine.

Write code now.

For sounds:

```js
let AC=null;
function ac(){ if(!AC){ try{AC=new (window.AudioContext||window.webkitAudioContext)()}catch(e){} } return AC; }
function sfx(type){ const a=ac(); if(!a) return; ... oscillator/noise ... }
```

shoot: noise buffer 0.15s bandpass; hurt: sawtooth 110Hz 0.2s; die: square descending; win: triangle notes.

Keep it brief with try/catch.

Now produce file.

Rough code (final):

```html
<!DOCTYPE html>
<html>
<head><meta charset="utf-8"><title>...</title>
<style>...</style>
</head>
<body>
<div id="wrap">
 <canvas id="screen" width="960" height="600"></canvas>
 <div id="hud">...</div>
 <div id="msg"></div>
 <div id="overlay">...</div>
</div>
<script> ... </script>
</body></html>
```

Layout: wrap relative, canvas block; hud absolute top; controls bottom-left; overlay centered flex hidden by default.

CSS: dark bg, monospace font, canvas border, responsive width.

Let me write it all.

For the win check: dist to exit tile center < 0.55 and unlocked → win. Exit at (14.5,10.5). Player must enter tile. Door solid for movement? No — passable when unlocked. But ray renders it solid → player sees door, walks in, dist<0.55 triggers before going deep. Movement into the door tile allowed when unlocked (solid() returns false for it). But other cells behind (row10 col15 is '#') so player can stand in the tile. Win triggers. Good.

Also: exit door rendered from both sides — rays from inside corridor hit it. Fine.

Restart function resets: player pos/dir, hp, enemies array (respawn all), unlocked=false, state='play', message.

Enemy respawn positions from parsed spawn list.

Now write for real.

Code for enemy sprite drawing (canvas 2d), 64×64:

```js
function drawDemon(g, attack){
  g.clearRect(0,0,64,64);
  // legs
  g.fillStyle='#4a0d0d';
  g.fillRect(22,50,8,12); g.fillRect(34,50,8,12);
  // body
  const grd=g.createRadialGradient(32,34,4,32,36,20);
  grd.addColorStop(0,'#a52323'); grd.addColorStop(1,'#5b0f0f');
  g.fillStyle=grd;
  g.beginPath(); g.ellipse(32,38,15,17,0,0,Math.PI*2); g.fill();
  // arms
  g.strokeStyle='#5b0f0f'; g.lineWidth=6; g.lineCap='round';
  if(attack){ g.beginPath(); g.moveTo(20,30); g.lineTo(8,14); g.moveTo(44,30); g.lineTo(56,14); g.stroke(); }
  else { g.beginPath(); g.moveTo(19,32); g.lineTo(10,44); g.moveTo(45,32); g.lineTo(54,44); g.stroke(); }
  // claws
  g.fillStyle='#e8d9a0';
  ...
  // head
  g.fillStyle='#8f1a1a';
  g.beginPath(); g.arc(32,20,11,0,Math.PI*2); g.fill();
  // horns
  g.fillStyle='#d9c48f';
  g.beginPath(); g.moveTo(24,13); g.lineTo(18,2); g.lineTo(27,9); g.closePath(); g.fill();
  g.beginPath(); g.moveTo(40,13); g.lineTo(46,2); g.lineTo(37,9); g.closePath(); g.fill();
  // eyes
  g.fillStyle=attack?'#ffe600':'#ff9c00';
  g.beginPath(); g.arc(27,18,2.6,0,Math.PI*2); g.arc(37,18,2.6,0,Math.PI*2); g.fill();
  // mouth
  g.fillStyle='#1a0000';
  if(attack){ g.beginPath(); g.ellipse(32,26,6,5,0,0,Math.PI*2); g.fill(); teeth... }
  else { g.fillRect(26,25,12,3); }
}
```

Corpse:

```js
function drawCorpse(g){ clear; dark ellipse at bottom y=58 rx=18 ry=5 fill '#3a0a0a'; some bone bits '#cfc5a0' small rects }
```

OK. Time to write the actual file. I'll write it in one `write` call. Then test with browser: reload, screenshot, key presses.

Testing with browser tool: actions like key. The browser tool has key action with text. I can send 'w' etc. Motion/screenshot. Verify rendering, HUD, health.

Also bash-check map connectivity first with python3 quickly. Actually I already traced it manually; still, run a quick flood-fill to be safe.

Let me write the file.

Also make sure Space doesn't scroll page: preventDefault on keydown for handled keys.

Now write.

One subtlety: putImageData ignores smoothing; internal canvas separate from display canvas. Use two canvases: `off` (480×300) hidden, `screen` (960×600).

Turn: left arrow = rotate left (counterclockwise, decreasing angle if angle standard math with dir=(cos a, sin a)); right arrow +.

dir=(cos a, sin a), plane = (-sin a * 0.66? ) Standard: plane = perpendicular: planeX = -dirY*0.66... Let me use: dirX=cos a, dirY=sin a; planeX=-sin a*0.66, planeY=cos a*0.66. Turning left (counterclockwise visually on map where y increases downward)... In screen raycasting with plane as above, cameraX negative = left side. Just test signs in browser: pressing right arrow should turn right (view rotates right). I'll set: right arrow → a += rotSpeed*dt. If it appears reversed in screenshot test I'll flip. Actually let's reason: with dir=(cos,sin) and plane=(-sin,cos)*0.66: for a=0, dir=(1,0) facing +x. plane=(0,0.66). Column x=IW-1 → cameraX=+1 → ray=(1,0.66) → pointing +y. In map coords, is +y screen-right? With plane=perp rotated +90° (counterclockwise in math coords, but canvas y-down means clockwise visually...). Whatever — I'll verify visually. Common implementations use dir=(-1,0), plane=(0,0.66) and right arrow decreases angle. I'll just pick right arrow: a += rot and check via screenshot: player at (1.5,1.5) facing +x (east), corridor extends east along row1 — a wall should be on the right side (row0 is wall to the north, y=0 → smaller y). Hmm orientation ambiguity (north = -y). If facing east (+x), the wall at y<1.5 (north) should appear on the LEFT of screen if y-down world maps with... Let's think: ray for left screen edge (x=0, cameraX=-1): ray = dir - plane = (1,-0.66) → +x,-y direction = northeast. So left edge shows northeast, right edge southeast. Facing east, north on left — like looking at a map with north up. So pressing right arrow should rotate view toward southeast → a increases (since increasing a rotates dir from (1,0) toward (0,1)=south which appears right). Yes: right arrow → a += rotSpeed*dt. Consistent.

Sprites transX sign: standard formula gives screenX = IW/2 * (1 + transX/transY). Trust it.

Write now. Also floor colors: ceiling #2a2a33→#15151c gradient; floor #4a3b2a→#241d14? Precompute per row.

Also add slight fog: shade function.

Let me finalize numbers: shade(dist, side): base = Math.max(0.25, 1.15 - dist*0.075) capped 1; side==1 → *0.75.

Let me write.

Damage flash vignette: hurtT decays; draw radial gradient red alpha hurtT.

Also enemies colliding with each other: check target pos not within 0.5 of another enemy — simple loop, cheap.

Now writing the full file.

Also handle key 'r' restart anytime.

Enemy count HUD: "DEMONS LEFT: n".

Health bar: HTML div width %.

Messages: setMsg(text, timeout).

Alright, writing the file now. Then flood fill check, then browser test.

Actually let me write the code with care to avoid bugs:

Full JS sketch:

```js
'use strict';
const IW=480, IH=300;
const FOV_PLANE=0.66;
const MAPW=16, MAPH=12;
const MAPS=[
"################",
"#S.....#....3..#",
"#.###..#.####..#",
"#.#3#..#....#..#",
"#.#.####.##.#.##",
"#.#......##....#",
"#.##.###.##.##.#",
"#....#3..#..#..#",
"####.#.###..##.#",
"#3...#.....#...#",
"#.####.####.##E#",
"################"];

let grid=[], spawns=[], startPos={x:1.5,y:1.5}, exitPos={x:14.5,y:10.5};
MAPS.forEach((row,y)=>{ grid[y]=[]; for(x...){ c=row[x]; if(c=='#')grid[y][x]=1; else if(c=='E')grid[y][x]=3; else grid[y][x]=0; if(c=='S')startPos={x+0.5,y+0.5}; if(c=='3')spawns.push({x:x+.5,y:y+.5}); }});

function cellAt(cx,cy){ if(cx<0||cy<0||cx>=MAPW||cy>=MAPH) return 1; return grid[cy][cx]; }
function solidAt(cx,cy){ const c=cellAt(cx,cy); if(c===3 && exitOpen()) return 0; return c; }
function blockedAt(x,y,r){ for(cy=floor(y-r)..floor(y+r)) for(cx=floor(x-r)..floor(x+r)) if(solidAt(cx,cy)) return true; return false; }
```

Textures: `function makeTex(fn){ const d=new Uint8ClampedArray(64*64*4); for y,x { const [r,g,b]=fn(x,y); ...}}` plus hash:

```js
function h2(x,y){ let n=x*374761393+y*668265263; n=(n^(n>>13))*1274126177; return ((n^(n>>16))>>>0)/4294967295; }
```

brick fn:

```js
const row=y>>3, mortar = (y&7)===7 || ((x + (row&1?4:0)) & 7)===7;
if(mortar) v=[88,84,80] + noise
else { id = row*8 + ((x + (row&1?4:0))>>3); t=h2(id,7); base=120+t*45; n=(h2(x,y)-0.5)*18; r=base+n, g=base*0.55+n, b=base*0.45+n }
```

stone fn:

```js
blocks 16px: bx=x>>4, by=y>>4; edge = (x&15)===15||(y&15)===15 → dark line (60)
base = 100 + h2(bx,by)*35 + noise*10; slight blue: r=g*0.95,b=g*1.1
```

door fn (locked) & doorOpen fn:

```js
locked: metal: base=95+noise*12; vertical seams x%16==0 darker; rivets at corners of 16x32 panels; central red panel? Keep: dark steel + red rune circle center: dist from (32,32)<10 → red glow (150+..., 30,40). 
open: dark green glow: base green (30..90) with bright center radial (60,220,90), plus frame edges dark.
```

OK.

castRay(px,py,dx,dy) → {dist, side, cell, wallX} generic:

```js
function castRay(px,py,rdx,rdy,maxD){
 let mapX=Math.floor(px), mapY=Math.floor(py);
 const ddx=Math.abs(1/(rdx||1e-9)), ddy=Math.abs(1/(rdy||1e-9));
 let stepX,stepY,sdx,sdy;
 if(rdx<0){stepX=-1;sdx=(px-mapX)*ddx}else{stepX=1;sdx=(mapX+1-px)*ddx}
 if(rdy<0){stepY=-1;sdy=(py-mapY)*ddy}else{stepY=1;sdy=(mapY+1-py)*ddy}
 let side=0, cell=0;
 for(let i=0;i<64;i++){
  if(sdx<sdy){ mapX+=stepX; side=0; if(sdx>maxD) return null; sdx+=ddx; }
  ...
```

Hmm standard loop: compare sdx/sdy before increment. Let me write standard:

```js
 for(let i=0;i<80;i++){
   if(sdx<sdy){ sdx+=ddx; mapX+=stepX; side=0; }
   else { sdy+=ddy; mapY+=stepY; side=1; }
   const c=solidAt(mapX,mapY);
   if(c>0){
     const dist = side===0 ? sdx-ddx : sdy-ddy;
     let wallX = side===0 ? py+dist*rdy : px+dist*rdx; wallX-=Math.floor(wallX);
     return {dist:Math.max(dist,0.0001), side, cell:c, wallX, mapX, mapY};
   }
 }
 return null;
}
```

LOS: castRay from shooter toward target; if returned dist > distToTarget → clear. Use direction normalized.

Rendering walls per column uses castRay with dir per column; note solidAt for exit: if unlocked, exit renders... wait, I decided exit renders as door always (solid for rays), passable for movement. So solidAt used for rays includes door; collision uses separate movementBlocked where door passable when unlocked. So: solidAt (rays) treats 3 as solid always. moveBlocked treats 3 as solid only if locked. LOS uses solidAt (rays) — enemies can't shoot through closed door, and when unlocked door still blocks LOS but who cares.

So:

```js
function solidRay(cx,cy){ return cellAt(cx,cy); } // any nonzero
function solidMove(cx,cy){ const c=cellAt(cx,cy); return c!==0 && !(c===3 && exitOpen()); }
```

Ray uses solidRay; blocked/collision use solidMove; LOS uses solidRay.

Texture pick: cell===3 → locked? doorTex : doorOpenTex. cell 1 → stone if border else brick.

Now sprite draw function:

```js
function drawSprites(){
 const list=[];
 for(const e of enemies){
   const rx=e.x-px, ry=e.y-py;
   const inv=1/(planeX*dirY - dirX*planeY);
   const tx=inv*(dirY*rx - dirX*ry);
   const ty=inv*(-planeY*rx + planeX*ry);
   if(ty>0.15) list.push({e,tx,ty});
 }
 list.sort((a,b)=>b.ty-a.ty);
 for(const s of list){
   const e=s.e;
   const isCorpse=e.dead;
   const sprite = e.dead?corpseTex:(e.hitT>0?hitTex... )
```

Simplify: sprite pixel data chosen: dead → corpseTex; else demon frame (attack if attackT>0). Hit tint applied at draw time.

```js
   const h = (IH/s.ty) * (isCorpse?0.3:0.85);
   const w = h * (isCorpse?1.4:1);
   const floorY = IH/2 + IH/(2*s.ty);
   const y1 = floorY - h, y0 = floorY; // draw from y1..y0
   const x0 = s.tx... screenX = IW/2*(1+s.tx/s.ty); x1=screenX-w/2;
   for(let sx=Math.max(0,Math.ceil(x1)); sx<Math.min(IW, x1+w); sx++){
     if(s.ty >= zbuf[sx]) continue;
     const u = Math.floor((sx-x1)/w*64); if(u<0||u>63) continue;
     for(let sy=Math.max(0,Math.ceil(y1)); sy<Math.min(IH,y0); sy++){
       const v = Math.floor((sy-y1)/h*64);
       const ti=(v*64+u)*4; const a=tex[ti+3]; if(a<50) continue;
       shade...
       buf[...]=r; buf+1=g; buf+2=b; // keep alpha 255
     }
   }
 }
}
```

Buffer index: (sy*IW+sx)*4. Alpha default 255 everywhere since we fill. Good.

Shade for sprites: sh = Math.max(0.3, 1.1 - s.ty*0.08). Hit tint: r += 120 clamp.

Enemy update:

```js
function updateEnemies(dt){
 for e alive:
  e.cool-=dt; e.hitT-=dt; e.attackT-=dt;
  const dx=px-e.x, dy=py-e.y, d=Math.hypot(dx,dy);
  const los = hasLOS(e.x,e.y,px,py);
  if(los && d<9) e.aggro=true;
  if(e.aggro && state==='play'){
    if(d>0.85){ move toward player with collision, speed 1.3*dt; enemy-enemy separation }
    if(d<1.25 && los && e.cool<=0){ e.cool=1.3; e.attackT=0.35; damagePlayer(7+Math.random()*7); }
  }
}
```

damagePlayer: hp-=amt; hurtT=0.5; sfx hurt; if hp<=0 → gameOver.

Shooting:

```js
function shoot(){
 if(fireCool>0 || state!=='play') return;
 fireCool=0.38; recoilT=0.18; flashT=0.09;
 sfx('shoot');
 // direction ray from center
 const rdx=dirX, rdy=dirY;
 const wallHit = castRay(px,py,rdx,rdy,40);
 const wallD = wallHit? wallHit.dist : 40;
 let best=null,bt=1e9;
 for(const e of enemies){ if(e.dead) continue;
   const rx=e.x-px, ry=e.y-py;
   const t=rx*rdx+ry*rdy;
   if(t<=0.1||t>wallD) continue;
   const perp=Math.abs(rx*rdy-ry*rdx);
   if(perp<0.45 && t<bt){ bt=t; best=e; }
 }
 if(best){ best.hp-=34; best.hitT=0.18; best.aggro=true; if(best.hp<=0){best.dead=true; alive--; sfx('die'); msg...} }
 // aggro others
 for(e) if(!e.dead && hasLOS(...)) e.aggro=true;
}
```

Note cross product: rx*rdy - ry*rdx where (rdx,rdy) unit — yes since dir normalized. Player dir always normalized (angle-based). Good.

Perp threshold 0.45 approximates enemy width 0.9 — bit generous, fine for playability. Wall occlusion: t < wallD ensures no through-wall hits. But wallD is distance along ray to wall; enemy t is distance along ray to enemy's center projection — correct comparison.

Win check per frame: if exitOpen() && hypot(px-ex,py-ey)<0.55 → win.

exitOpen(): aliveCount===0.

Messages: when last enemy dies → msg "The EXIT has unlocked — escape through the green door!" persistent. Win → overlay.

HUD DOM update in loop.

Minimap: draw on display ctx: at (12,70)? top-left below health bar (HTML hud occupies top ~50px). Place minimap bottom-right corner: cell 5px → 80×60 at (dispW-90, dispH-150)? Weapon at bottom center, fine. Place minimap top-right under enemies counter... HTML hud has health top-left, enemies top-right. Minimap bottom-left? Controls text bottom-left (HTML). Put minimap bottom-right. Weapon drawn center-bottom might overlap nothing. OK: minimap at bottom-right, semi-transparent.

Draw minimap: for each cell solid→ fill rgba(255,255,255,0.25); exit green/red; player dot yellow; enemies red dots.

Now HTML/CSS. Fonts: monospace. Colors: retro amber/green.

Overlay div (#overlay) with big text and Restart button; hidden unless dead/won. Also a start overlay? Not needed; game starts immediately.

Restart button also in HUD top ("RESTART [R]").

Let me now also compute weapon drawing:

```js
function drawWeapon(dctx){
 const cx=dispW/2, bob=Math.sin(walkPhase)*10*moveAmt, recoil=recoilT>0? recoilT*40:0... 
 gun: dark gray rectangle barrel + body + hand.
 draw simple: 
  dctx.fillStyle='#23262b'; barrel rect (cx-14, H-120+bob+recoil, 28, 90)
  grip...
  muzzle flash if flashT>0: radial gradient yellow circle at (cx, gunTopY)
}
```

Simplify: draw a shotgun-ish shape with paths. Fine.

Crosshair: lines at center.

Now let me count code size — maybe 500 lines. OK.

Also initial dir angle: facing east a=0 → dir (1,0). Start (1.5,1.5) corridor row1 extends east. Good.

Write file now. Then run checks.

Also `enemy separation`: when moving, check other enemies dist>0.6 at new pos; else skip move.

hasLOS(x1,y1,x2,y2): d=hypot; steps=ceil(d/0.15); step along, check solidRay at each floor cell; skip cells equal to start/end? Checking floor cell of each sample; endpoints are in open cells so fine. If any solid → false. Also cap d<20.

Edge case: castRay maxD param — LOS uses distToTarget+0.1.

Now the write.

For text rendering crispness: HUD via HTML so canvas only has game + weapon + minimap + crosshair + vignette.

Let me also handle canvas display scaling: canvas width=960 height=600 attribute; CSS width: min(100%, 960px); aspect-ratio preserved automatically since height auto? Set style width 100%, height auto. Wrap max-width 960. HUD absolute inside wrap.

Mouse look: screen.addEventListener('click', ()=> screen.requestPointerLock?.()); document.mousemove → if document.pointerLockElement===screen → a += e.movementX*0.0022.

Prevent context issues: fine.

Write it.

let me write the death of enemy: alive count recompute = enemies.filter(!dead).length.

Game over: state='dead'; overlay show "YOU DIED" + button. Won: "YOU ESCAPED" + button. During overlays, updates stop except render? Just stop updates (state check in update).

Restart(): reset everything, hide overlay, state='play'.

Also weapon fireCool, recoilT, flashT, walkPhase, moveAmt decays.

Input keys object: KeyW/KeyS/KeyA/KeyD/ArrowLeft/ArrowRight/Space.

Turn also Q/E? Not required; arrows enough. Maybe also mouse optional.

dt loop:

```js
let last=performance.now();
function frame(now){ const dt=Math.min(0.05,(now-last)/1000); last=now; update(dt); render(); requestAnimationFrame(frame); }
```

update: if state==='play': movement, shoot (if space held), enemies, win check, timers. Always decay visual timers.

fillRect-based... no, buffer fill each frame:

```js
// ceiling & floor
for(let y=0;y<IH;y++){
 const t = y<IH/2 ? (1 - y/(IH/2)) : ((y-IH/2)/(IH/2));
 colors precomputed rows: ceilRow[y], floorRow[y]
 const c = y<IH/2? ceilRow[y]:floorRow[y];
 for(let x=0;x<IW;x++){ const i=(y*IW+x)*4; buf[i]=c[0];buf[i+1]=c[1];buf[i+2]=c[2];buf[i+3]=255; }
}
```

That's 144k iterations — fine.

Then walls, sprites, putImageData, then display blit + overlays.

OK writing now for real. I'll aim for clean, correct code.

One more check on sprite floorY: with ty small (close), IH/(2*ty) large → floorY > IH → clamped by loop bounds. Good.

Sprite near clip ty>0.15 avoids huge blowups.

Also enemies standing: their sprite bottom at floorY which corresponds to their position — but if enemy is very close, floorY beyond screen; fine.

Write.

Map is fully connected. Now write index.html.

Images not supported by the model, so screenshots won't show me visuals. I need to verify via DOM/console and by instrumenting state. The browser tool gives console + DOM text. I can't see the canvas pixels. I can add temporary console.log diagnostics? Better: I can run checks via browser inspect + inject JS? The browser tool actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. No evaluate. Hmm — console only shows warnings/errors.

To verify behavior I can add a debug hook: expose window.__dbg = {get state} in the game. But I can't execute JS in the page via the tool... Actually `key` and `type` actions can trigger game input; DOM text shows HUD updates (health, enemy count, msg). That verifies a lot: moving into a wall won't show; but health changes when hit by enemy, msg changes when shooting/hit.

But I can't observe the canvas rendering directly since model doesn't support images. Alternative: use console — add a debug logging that logs render diagnostics once (e.g., after first frame, log zbuf stats, center wall distance, etc.). I can add temporary debug code, run, read console, then remove. Let's do that: log at frame ~10: player pos, center column zbuf value, sprite counts, any NaN in buffer.

Plan:
1. Add temporary debug: window checks + console.log diagnostics after 30 frames.
2. Use browser key actions to simulate movement/turning, then read console (does inspect return console? The screenshot action returned console list; presumably inspect too). Let me use key 'w'... key action probably presses and releases; movement needs hold. There's `motion` action to capture frames over time. key with text maybe supports repeats? Let's try: browser key text 'w' — a single press-release gives tiny movement (one frame ~0.016s → 0.05 units). Hmm, small but detectable via debug log.

Alternatively I can key-hold via type? Unclear. Let me add debug that logs periodically (every 60 frames) pos/ang/hp/alive, then use `motion` after pressing keys? `key` action may accept sequences like "www"? Let me just experiment.

Also I can verify stability: zbuf center distance changes with movement and turning.

Let me add debug logging now.

No debug logs yet? The interval fires every 700ms; maybe console output only captured at action time and none appeared. Wait — the console array only shows the sandbox warning. Maybe console.log isn't captured, or the interval hasn't fired by the time the snapshot was taken. Let me wait — do another action to check console again.

Game runs, no NaN, player at start (1.5,1.5), facing east, center wall 5.50 units away (map row1 corridor: wall at x=7 col '#', from 1.5 → 7.0 = 5.5. Correct!).

Now test movement: key 'w'. Single press probably gives brief movement. Let me send 'w' and check position change. Also test arrow turning, space shooting, collision against wall (move toward wall at x=7 and confirm player stops), and R restart.

A single 'w' keypress didn't move the player (pos unchanged after the press). The key action likely presses/releases too fast (between frames, keys[e.code] set then cleared before a frame reads it — actually keydown sets keys.KeyW=true, keyup clears it; if both happen within the same interval between frames, no movement occurs).

To test sustained movement, I need key held over time. Maybe the `type` action or `key` with a long text like "wwww..." produces repeats? Or `motion` action captures frames while a key is held? Not sure. Options:

1. Make the debug loop simulate keys directly: temporarily, in debug code, simulate movement by setting keys flags programmatically with timers. E.g., window.__dbg.hold('KeyW', 1000). But I can't execute arbitrary JS in page... unless I add debug code that on some keypress (like 't') starts a scripted test sequence: hold W 1s, turn right 0.5s, etc., logging positions. That's a nice approach: a scripted self-test triggered by pressing 't', logging everything. Then I press 't' via browser key action and read the console.

Let me implement: on 'KeyT', run a test script using setInterval/timeouts:
- t=0: log start
- hold W for 1.2s → expect pos.x ≈ 1.5+3.6=5.1 (or stop at wall)
- release, log
- hold ArrowRight 0.6s → ang ≈ +1.56
- hold A 0.5s → strafe
- hold W toward a wall until blocked (hold 3s): player should stop at wall with clearance ~0.22
- press Space once: shoot log
- press KeyR: restart → log pos/hp reset

Implement helper: press(code) { keys[code]=true }, release after ms.

Let me rewrite the debug block accordingly.

Test started. It takes ~1.2+0.6+0.5+2.5+... ≈ 5.5s plus. Wait then inspect.

All checks pass:
- W for 1.2s: moved from (1.50,1.50) to (5.10,1.50) — 3.6 units = 3.0 u/s ✓
- ArrowRight 0.6s: ang 1.56 ≈ 2.6*0.6 ✓
- Strafe A 0.5s: moved perpendicular ✓
- W into wall: stopped at (3.98,1.76), centerWall=0.24 — collision with the wall (row 0 is at y=0; facing ang=1.56 (south, +y)... wait facing ang=π/2 → dir (0,1) = +y. Wall at row0 y=0? Player at y=1.76 moving +y → hits wall at y=2.0 (row2 col3 is '#': row2 = "#.###..#" col3 '#' yes). Player y=1.76, wall face at y=2.0, distance 0.24 = PLAYER_R ✓ collision works.
- Space shot: fired (no error), hp unchanged (correct — shot hit wall).
- Restart: pos (1.50,1.50), ang 0, hp 100, alive 4, state play ✓.

Now test enemy damage + win flow? That requires playing through. I can add a scripted test: teleport near an enemy? I shouldn't teleport via debug since it's temp code anyway... A quick additional test: use debug to move player near an enemy spawn (e.g., enemy at (12.5,1.5) — set px=11.5,py=1.5) and let enemy approach/attack; verify hp drops. Also test shooting an enemy dead and exit unlock/win by teleporting to exit after killing? Full win test: set all enemies dead via shooting would need aim. Simpler scripted test:

Test2 (KeyY):
1. Log. Teleport player to (10.5,1.5) facing east (ang=0). Enemy at (12.5,1.5) — LOS clear along row1. Enemy should aggro and approach and attack → hp drops over ~3s. Log hp after 3s.
2. Then shoot twice while aiming at enemy? Aiming is automatic if facing. After 3s enemy is close (it approaches). Space shots with 0.38 cooldown... The test could hold Space for 1.5s → ~3 shots → enemy takes 102 dmg if hits connect. Enemy dead → alive=3, message unlock only at 0. Log.
3. Teleport player adjacent to exit (14.2,10.5)... that's far; set alive=0 by killing remaining? For win test, I can directly set enemies dead (e.dead=true; alive=0) then teleport near exit (13.9, 10.5) and walk in → win. That tests exitOpen + win condition + overlay.

This is temp debug code so it's fine to simulate. Let me add KeyY test.

Also should verify enemy can't damage through wall and shots can't hit through wall — harder to script quickly but LOS function already handles; skip explicit test, but I can test occlusion: teleport player to a position where enemy is behind wall (e.g., player at (5.5,1.5), enemy at (12.5,1.5) but wall at col7 row1 blocks) — enemy shouldn't aggro/attack. Check hp stays 100 over 2s. Add to test2:

- Teleport (5.5,1.5), enemy at (12.5,1.5) behind wall col7. Wait 2s. hp should remain 100, enemy not aggro.

But enemy already aggro'd from step 1 in test2 sequence... I'll do the occlusion test first, then LOS test. Sequence for KeyY:
1. teleport (5.5,1.5), ang=0 facing east toward enemy behind wall at col7 (row1 col7 '#'). Wait 2.0s → log hp (expect 100), log enemy aggro (expect false).
2. teleport (11.5,1.5), ang=0 → LOS to enemy at (12.5,1.5). Wait 2.5s → log hp (expect < 100), enemy aggro true.
3. Hold Space 1.6s → ~4 shots, enemy at close range should die → log alive (expect 3), then set other enemies dead, teleport (13.5,10.5) facing... walk W 1.5s into exit → expect state 'won', overlay shown.

Actually simpler: after killing enemy, kill all: enemies.forEach(e=>{if(!e.dead){e.dead=true}}); alive=0; then teleport player (13.5,10.5), hold W 1.5s → win state. Log.

Implement.

Results:
- Behind wall: hp=100, aggro=false ✓ (shots/AI blocked by wall)
- Clear LOS: hp dropped to 77.6, aggro=true ✓
- Firing killed enemy: alive=3 ✓ (also enemy still attacked during firing — hp 66.8, fine)
- Win test FAILED: at exit (13.20,10.50), centerWall=0.80 cell=3 → exit door at x=14.0, distance 0.80. Player should move forward... state=play and pos stuck at 13.20. Why? Player was teleported to (13.2,10.5) and... update() runs movement only via keys — no keys held, so player doesn't move. My test expected player to walk but I never held W! The win check requires dist<0.6 to (14.5,10.5); from 13.2 that's 1.3 away. The test didn't move the player. So the game is fine — test was incomplete. Also note the door is solid for movement? No — when unlocked (alive=0), solidMove returns false for the door. centerWall=0.80 is just the ray hitting the door texture (rays always hit it).

Let me fix the test: hold W for ~1s to walk into the door tile. Actually dist from 13.2 → 14.5 is 1.3; at 3 u/s need ~0.44s. Hold W 0.8s.

Note: also the door being ray-solid means when player walks in (x up to 14.5), the wall texture fills the screen — win triggers at dist<0.6 i.e. x>13.9. OK.

Quick retest with held W.

Still pos=(13.20,10.50) — W held for 900ms did not move the player! Player is stuck. Why? Blocked() check at (13.2+small, 10.5): moving east (+x) toward the exit door at cell (14,10). When unlocked, solidMove(14,10) should be 0... wait — cellAt(14,10)=3, exitOpen() → alive===0 → true, so solidMove returns false → passable. But the player is facing ang=0 (+x). At x=13.2, radius 0.22: floor(13.2±0.22)=13 → cells 13 only. Moving to x=13.3: floor(13.52)=13 still. Hmm so player should move at least to x≈14.28 before x+r crosses into cell 14 (x=13.78+r=0.22 → floor(14.0)=14 checks cell 14 which is passable when unlocked). So it should move.

Unless... wait, the win condition: dist to exit center (14.5,10.5) < 0.6 → x>13.9. Player should reach ~14.28 or stop at 14.5? They'd walk into the tile and win at 13.9.

But pos stayed exactly 13.20 — not even a tiny move. That means blocked() returns true for the first x-step... or the KeyW handler in test didn't work. Hmm — keys['KeyW'] = true set directly, that works for update(). Wait — was the timer even reached? "[test2] at exit" logged with state=play — yes it logged after the 900ms hold. During those 900ms W was held... player didn't move at all.

OH WAIT. I see it: `py = 10.5` — row 10! Let me recheck the map: row10 = "#.####.####.##E#" — col13 = '#', col14 = 'E'. Player at (13.2,10.5) is INSIDE cell (13,10) which is '#'! Teleporting into a wall. Then blocked() at their position is true, so any move is blocked (moveWithCollision checks destination only — destination (13.3,10.5): cells floor(13.3-0.22)=13, floor(13.3+0.22)=13 → cell (13,10) solid → blocked → no move). So the player was embedded in a wall and couldn't move. My test bug, not game bug.

Teleport to a valid open cell near the exit: (12.5, 10.5) — row10 col12 '#'... row10: "#.####.####.##E#": cols: 0#,1.,2#,3#,4#,5#,6.,7#,8#,9#,10#,11.,12#,13#,14E,15#. Hmm col12 '#', col13 '#'. Open cells in row10: 1, 6, 11, 14. So near exit, open neighbor is (11.5,10.5)? That's 3 units from exit... row9 col12-14 are open: row9 = "#3...#.....#...#": col12 '.', col13 '.', col14 '.'. So teleport to (13.5, 9.5) facing south (ang=π/2 → dir (0,1)). Then walk south into (14,10)? Path: from (13.5,9.5) moving +y → cells (13,10) is '#'! Facing straight south hits the wall. Need to approach exit door cell (14,10) from (14.5,9.5) i.e. x=14.5? floor(14.5)=14, row9 col14 '.'. OK teleport to (14.5,9.5), ang=π/2 (south). Moving +y: x stays 14.5, x±0.22 → floor(14.28)=14, floor(14.72)=14 → cell (14, y). Passable when unlocked: row9 col14 open, row10 col14 is door (passable), row 11 border. So walking south from 9.5 → 10.5 → win triggers at y>9.9. 

Set px=14.5, py=9.5, ang=Math.PI/2. Fix test.

All tests pass:
- Behind-wall occlusion: hp=100, aggro=false ✓
- Clear LOS: attacked, hp 100→78.7, aggro=true ✓
- Shooting kills enemy: alive 4→3 ✓
- Win: state=won, overlay "YOU ESCAPED!" shown ✓

One more: Game Over test. Add quick check: set hp=5, let enemy attack → dead state + overlay. Or simply test damagePlayer(100). I'll do a tiny test3 on KeyU: set hp=10 near enemy... simpler: damagePlayer(50) twice → state dead, overlay text. Then press R via real key to restart → verify hud shows health 100 and enemies 4 again.

Then remove all debug code, reload, final sanity screenshot (can't see images but confirm no console errors), done.

Game Over → R restart restores state=play, hp=100, alive=4, position and angle reset, overlay hidden (DOM no longer shows "YOU DIED"). All verified.

Now remove ALL temporary debug code and do a final clean reload check.

Clean build loads with no console errors (only the pre-existing sandbox warning from the harness environment). Final file is in place. Done — report.