Wolfenstein raycaster · deepseek-v4.1-flash

Let me build this. I'll write a complete Wolfenstein-style raycasting shooter in one HTML file.

Let me plan the implementation:

- Canvas fullscreen
- Maze grid map (2D array)
- Player position, direction, camera plane
- Raycasting DDA algorithm
- Procedural textures: generate wall textures as offscreen canvas ImageData, store as arrays or canvases. Enemies as billboard sprites drawn procedurally.
- Enemies: sprite positions, AI moving toward player, attack rule (line of sight and range), damage player.
- Shooting: hitscan along player ray, check wall distance first (occlusion), then nearest enemy within a small angle. Actually simplest: for shoot, cast ray and find enemy hit using projection: compute angle difference and distance, ensure no wall between.
- Health, enemy count HUD.
- Exit tile unlocked when all enemies dead; reaching it wins.
- Restart button.
- Controls display.
- Mouse optional.

Let me write it carefully.

Map: let's make a smallish maze, e.g. 16x16.

Let me define map with 1=wall, 0=empty, 2=exit, 3=enemy spawn maybe separate.

I'll design a simple maze.

Let me think about the DDA raycasting and texture mapping. I'll generate textures as Uint32Array pixel data (16x16 or 32x32) with a color per pixel. Then draw into an ImageData buffer per frame manually. That gives full control and performance okay at modest resolution (e.g. render width ~ 480 or canvaswidth). Actually let's render at canvas internal resolution e.g. 640x400 and scale. We can draw per-column using fillRect for textured walls—fillRect per pixel too slow. Better to use ImageData buffer for the whole scene.

Approach: create an offscreen ImageData at render width x height (say 480x300), fill pixels for ceiling/floor/walls/sprites, then putImageData scaled? putImageData doesn't scale. We can use an offscreen canvas at 480x300 then drawImage to main canvas scaled with imageSmoothingEnabled=false. That's efficient.

Let me implement pixel buffer.

Textures: 64x64 array of colors per texture. Procedural: brick pattern, stone, etc. Generate with a function.

Enemy sprites: rather than textures, draw them in the pixel buffer as billboards. Simplest: for enemies, compute screen coordinates and size, and for each column in sprite range, determine if closer than wall z-buffer, then draw enemy pixels using a procedural sprite (e.g., a humanoid shape with transparent background). I'll create a sprite as a 2D array with alpha (use -1 for transparent). Draw scaled.

Let me implement.

Wall rendering: standard Lodev raycasting.

For each x in [0, W):
 cameraX = 2*x/W - 1
 rayDir = dir + plane*cameraX
 DDA to find wall hit, compute perpWallDist.
 lineHeight = H / perpWallDist
 drawStart = -lineHeight/2 + H/2, drawEnd...
 texture X from wall hit.
 For each y in drawStart..drawEnd: texY = ... sample texture.
 Also floor and ceiling: I'll do simple floor casting or just solid colors. Simpler: draw ceiling color and floor color gradient with horizontal lines. For texture requirement on walls only is fine ("textured grid maze"). I'll do simple floor/ceiling with a gradient based on distance maybe. Keep simple: ceiling dark, floor gradient.

Actually floor casting adds nice look but time. Let's do gradient bands.

Let me implement the pixel buffer with Uint32Array view. Colors as 0xAABBGGRR (little endian) when writing to Uint32Array of ImageData. I'll create helper rgb(r,g,b) => (255<<24)|(b<<16)|(g<<8)|r.

Sprites and enemies.

Enemy structure:
 {x, y, hp, alive, type, cooldown, attackTimer}
Enemy AI: each frame if alive, if line of sight to player and distance < some range, move toward player slowly; if distance < attackRange and cooldown ready, attack -> player.health -= dmg. Attack rule "under a clear attack rule": attack only if line of sight (no wall) and within range, with cooldown. Maybe show a flash.

Line of sight: DDA grid ray between enemy and player checking walls. Implement `hasLineOfSight(x0,y0,x1,y1)`.

Enemy movement collision: keep out of walls.

Shooting: on space, cast a ray in player direction; find nearest enemy whose perpendicular distance... Actually compute for each alive enemy: vector to enemy, angle diff with dir. If |angle diff| small (within weapon spread, e.g. based on hit radius) and distance is closest and there's line of sight and the enemy is in front, hit. Simplest robust: for each enemy, compute distance d and angle. If angleDiff < atan(halfWidth/d) (i.e., within angular radius corresponding to enemy width) and hasLineOfSight and d is min, then hit nearest. Since hasLineOfSight excludes walls, "cannot damage through wall" satisfied.

Add muzzle flash / weapon sprite at bottom center drawn as overlay (canvas 2D after putImage). I'll draw a simple gun with 2D context and a flash when shooting. Since main canvas is scaled context, I can draw the weapon using ctx on the main canvas after drawImage.

HUD: health, enemy count, exit status. Could render in DOM overlay (HTML) — easier and crisp. Use HTML overlay divs positioned over canvas.

Win/GameOver: overlay DOM with restart button.

Let me use DOM for HUD and overlays, canvas for 3D.

Let me now write the map. I'll make a 16x16 map.

Let me draft:

```
const MAP = [
"1111111111111111",
"1000001000000001",
"1011101011111101",
"1010001000000101",
"1010111110110101",
"1000100000010001",
"1110101111011101",
"1000101000010001",
"1011101011110101",
"1010000010000101",
"1010111010110101",
"1000001010000001",
"1111101011111101",
"10000010000000X1",
"1011111111111101",
"1111111111111111",
```
Hmm need to make sure reachable and exit reachable. Let me instead carefully build a simpler maze and verify connectivity with code (flood fill) maybe. I'll just test in browser. But to be safe, I'll make a fairly open maze.

Let me design a 16x16 with mostly open rooms/corridors.

Actually let me make it straightforward: border walls, some internal walls forming a maze, exit at far corner, enemies placed.

I'll define:

```
const MAP = [
  "1111111111111111",
  "1000000000000001",
  "1011110111110101",
  "1010000100000101",
  "1010111101110101",
  "1000100001000001",
  "1110101101011101",
  "1000000101000001",
  "1011110101111101",
  "1000000100000001",
  "1011101110111101",
  "1000100010000001",
  "1011101010110101",
  "1000001000000101",
  "1011111111110001",
  "1111111111111111",
];
```

Hmm exit placement. Let me place exit at (14,13)? Actually let me just make exit at an open cell near a corner and ensure reachable. I'll verify via flood fill in the browser console or just reason.

This is getting complex; let me generate the map programmatically? A random maze generator could produce a guaranteed-connected maze. That's elegant: generate maze with recursive backtracker, then knock out some walls to create loops, place player at one open cell, exit at another, enemies at open cells far from player. Procedural and guaranteed connected. But "small level" — 16x16. Let's do that. It also satisfies "textured grid maze".

I'll implement maze generation:
- grid size N x M (odd dimensions for maze carving). Use 21x21? Let's do 21x21.
- Initialize all walls.
- Carve from (1,1) using recursive backtracker stepping 2.
- Then remove random walls to create loops (e.g., 8% of internal walls).
- Choose player start at (1,1) center.
- Exit at farthest cell from start (BFS) or a corner.
- Enemies at open cells with distance from start > threshold, 4 enemies.

But spawning enemies randomly each restart changes layout; that's fine, but "Restart to restore the level" implies same level. I'll generate the maze once at load and store it; restart re-uses same map, resets player/enemies/health. Good.

Let me store base map and spawn points fixed after generation.

Use cell coordinates: player at center of cell (cx+0.5, cy+0.5).

Now let me code.

Rendering resolution: internal W=480, H=300 maybe. Canvas displayed at larger size via CSS. Actually to keep crisp and responsive, set canvas width/height to fixed 640x400 and render pixels at same. Performance: 640x400=256k pixels per frame, JS loop each frame. Might be okay ~ maybe 30fps. Let's use W=480,H=300 for speed, then scale via CSS to fill. Use offscreen canvas at 480x300 and drawImage onto main canvas sized 480x300, CSS scales up. Simpler: main canvas width=480 height=300, CSS width 100%. ImageData directly on main canvas. Then weapon/HUD via DOM. That avoids extra canvas.

But drawing weapon with ctx after putImageData works on same canvas. However I want crisp scaling; CSS scaling with pixelated.

Let me set canvas.width=480, canvas.height=300, style width/height to fill viewport maintaining aspect. Use image-rendering: pixelated.

Floor/ceiling: I'll do floor casting for nicety? Time. Let me do simple: ceiling = dark blue-ish gradient by row, floor = brown gradient. Use row-based colors that darken toward horizon. That's cheap and looks ok.

Actually classic raycaster floor/ceiling as flat colors is fine. Let me draw:
- For each row above horizon: ceiling color (shaded by row).
- floor below: floor color shaded.
Then walls overwrite.

I can fill background quickly using per-row fill in the Uint32 buffer. Or use ctx.fillRect before putImageData? Since putImageData overwrites entire canvas including transparent pixels. If I fill ImageData with ceiling/floor first then put walls, good. I'll fill buffer rows.

Let me write the pixel buffer fill loop per frame:
- Fill ceiling rows 0..H/2 with color C(y)
- Fill floor rows H/2..H with color F(y)
- Then raycast walls writing pixels.
- Then sprites (enemies) with zbuffer.

Wall texture sampling: textures 64x64. texX from wallX. Draw with lineHeight, step = 64/lineHeight.

Zbuffer per column stores perpWallDist.

Sprites drawing: standard sprite algorithm using inverse camera matrix:
```
invDet = 1/(planeX*dirY - dirX*planeY)
transformX = invDet*(dirY*spriteX - dirX*spriteY)
transformY = invDet*(-planeY*spriteX + planeX*spriteY)  // depth
spriteScreenX = (W/2)*(1+transformX/transformY)
spriteHeight = abs(H/transformY) * scale
...
for stripe from drawStartX to drawEndX:
  if transformY>0 && stripe>0 && stripe<W && transformY<zbuffer[stripe]:
     texX = ((stripe - (-spriteWidth/2 + spriteScreenX)) * texW / spriteWidth)
     for y ... sample sprite with alpha
```

I'll make enemy sprite 64x64 with procedural humanoid.

Also need to sort sprites by distance descending.

Enemy attack visual: maybe tint screen red when damaged via DOM overlay.

Let me also add exit rendering: exit tile distinct (wall type 2) with green texture, only "unlocked" when enemies dead. Exit is a cell, reaching it (player within tile) wins.

Actually exit could be a floor tile; when player walks onto it and enemies cleared -> win. If not cleared, show locked message. Let's make exit cell a special floor color and draw a green portal.

Let me use map values: 1 wall, 2 exit (solid? no, walkable). Let me keep exit as walkable floor, and draw a billboard sprite for the exit portal instead. Or keep it as a wall with green texture but reaching means adjacent? Simpler: exit is a walkable cell; when player enters it, if enemies cleared -> win else show "exit locked". Draw exit cell floor in green tint during floor rendering? Floor casting needed to tint. Hmm. Alternatively place a special non-solid marker sprite at exit. I'll add an "exit sprite" billboard (green portal) drawn like enemy sprite but static and full-block? It would block movement? No. Player can walk into it. Good enough.

Actually to make exit visible and reachable, drawing a billboard sprite is good.

Let me include exit sprite in sprite list with type 'exit'.

Enemy count HUD, health HUD.

Weapon: draw a simple gun at bottom center using ctx.fillRect shapes, plus muzzle flash when shooting. Since we putImageData then draw weapon, works.

Now the game loop with requestAnimationFrame and delta time.

Controls:
- W/S forward/back, A/D strafe, arrows turn, Space shoot.
- Also prevent page scroll on space/arrows.
- Optional mouse: pointer lock maybe; skip or simple. Requirement says optional. I'll implement mouse turn when pointer locked (click canvas) but not required. Keep it, but careful. I'll add it lightly.

Collision: move with radius ~0.2. Check new position x and y separately against map wall. `isWall(x,y)` returns map cell solid.

Enemy AI:
- Each enemy has speed ~1.2 units/s, health say 3 hits? Weapon damage 1, enemy hp 3. Or one-shot? Let's do enemy hp 2, damage per shot 1. Actually to make gameplay, enemy hp 3.
- attack: if distance < 6 and LOS and cooldown<=0: player.health -= 8; cooldown=1.2s. Also enemy moves toward player if distance > 1.5.
- Enemy damage maybe 7 per hit.

Player health 100.

Shooting cooldown 0.3s.

Shots: hitscan as described. Damage nearest.

Add hit flash on enemy (short color tint) and death.

Let me write the code.

I'll structure:

```
<!DOCTYPE html>
<html>
<head><meta charset><title>...</title>
<style>...</style>
</head>
<body>
<div id="game">
  <canvas id="c"></canvas>
  <div id="hud">...</div>
  <div id="overlay">...</div>
</div>
<script>...</script>
</body>
</html>
```

Let me now write actual JS.

Constants:
```
const MAP_W=21, MAP_H=21;
let map; // Uint8Array or 2D
```

Maze generation:
```
function genMaze(w,h){
  const m = [];
  for(let y=0;y<h;y++){ m.push(new Array(w).fill(1)); }
  const stack=[[1,1]]; m[1][1]=0;
  const dirs=[[0,-2],[0,2],[-2,0],[2,0]];
  while(stack.length){
    const [x,y]=stack[stack.length-1];
    const opts=[];
    for(const [dx,dy] of dirs){
      const nx=x+dx, ny=y+dy;
      if(nx>0&&nx<w-1&&ny>0&&ny<h-1&&m[ny][nx]===1){
        opts.push([nx,ny,x+dx/2,y+dy/2]);
      }
    }
    if(opts.length){
      const [nx,ny,mx,my]=opts[Math.floor(Math.random()*opts.length)];
      m[my][mx]=0; m[ny][nx]=0;
      stack.push([nx,ny]);
    } else stack.pop();
  }
  // knock loops
  for(let y=1;y<h-1;y++)for(let x=1;x<w-1;x++){
    if(m[y][x]===1 && Math.random()<0.08) m[y][x]=0;
  }
  return m;
}
```

But careful: knocking walls might disconnect? Knocking walls only adds connectivity, never disconnects. Fine.

Player start at (1.5,1.5). Need map[1][1]=0 guaranteed.

Find exit: BFS from start, pick open cell with max distance and not start. Place exit there. Also ensure not adjacent to start maybe.

Enemy spawn: pick open cells with distance from start > 6 and > 3 from exit? and far apart. Choose 4.

Let me BFS distances.

```
function bfs(m,sx,sy){...return dist}
```

Then openCells sorted by dist.

Now map values: map[y][x] 0 empty, 1 wall, 2 exit (empty but marked).

Let me set map[exitY][exitX]=2.

isWall(x,y): if out of bounds -> true; return map[cy][cx]===1.

But exit cell is 2 -> not wall. Good.

Now raycasting uses map solidity: solid if ===1.

Textures: create array of textures. Let each texture is Uint32Array(64*64) with colors.

I'll define a function makeTexture(fn) generating per pixel.

Texture 1: brick red.
```
for y,x: 
  brick = ((y>>4)+(x>>4))&1 ... 
```
Let's make: mortar lines. bs=16? 64/16=4 rows. 
```
const row = Math.floor(y/16);
const off = (row%2)*16;
const bx = (x+off)%32;
const isMortar = (y%16<2) || (bx%32<2) ... 
```
Simplify: vertical mortar every 16 with offset, horizontal every 16.

Color base = 150,40,40 with noise. mortar = 80,80,80. Add per-pixel noise.

Texture 2: stone gray-blue.
Texture 3 maybe for exit/enemy not needed.

Create textures array indexed by material. I'll use material per wall: map value 1 -> texture from a map of variations: use ((cx*7+cy*13)%3) to vary among 3 textures for visual richness. Good.

Generate 3 textures.

Color helper: `rgb(r,g,b)` returns (255<<24)|(b<<16)|(g<<8)|r).

Noise: deterministic pseudo-random using sin.

Let me write:
```
function noise(x,y){ const n=Math.sin(x*12.9898+y*78.233)*43758.5453; return n-Math.floor(n); }
```

Texture generation:
```
function genBrick(){
  const t=new Uint32Array(64*64);
  for(let y=0;y<64;y++)for(let x=0;x<64;x++){
    const row=Math.floor(y/16);
    const ox=(row%2)*8;
    const bx=(x+ox)%32;
    const mortar = (y%16<2)||(bx%32<2);
    let r,g,b;
    if(mortar){ r=70;g=70;b=75; } else { const n=noise(x,y)*30; r=140+n;g=45+n*0.5;b=40+n*0.5;}
    t[y*64+x]=rgb(r|0,g|0,b|0);
  }
  return t;
}
```
etc.

Floor/ceiling colors: ceiling dark slate, floor brown. Shade by distance from horizon. Without floor casting, I'll shade based on row: near horizon lighter/darker. Let's compute:
- ceiling rows: factor = y/(H/2) -> darker near horizon? Actually typical: ceiling near top lighter. Let's just do gradient from (40,45,60) top to (10,10,15) horizon.
- floor from (20,15,10) horizon to (80,60,40) bottom.

Compute per row color interpolate.

I'll precompute row colors arrays each frame? H is constant so precompute once. Good.

Now raycast per frame.

Let me write render():

```
const img = ctx.createImageData(W,H)? 
```
Better allocate once: `const imageData = ctx.createImageData(W,H); const buf = new Uint32Array(imageData.data.buffer);` But endianness: assume little-endian (typical). Use rgb helper accordingly. Most environments little-endian. Fine.

Wait: canvas created with width W height H. ctx.createImageData works after context.

Render steps:
1. fill ceiling/floor rows using precomputed rowColors.
2. raycast walls.
3. sprites.
4. ctx.putImageData(imageData,0,0).
5. draw weapon with ctx.

Weapon drawn on top.

Zbuffer Float32Array(W).

Raycast:
```
for(let x=0;x<W;x++){
  const cameraX = 2*x/W - 1;
  const rdx = dirX + planeX*cameraX;
  const rdy = dirY + planeY*cameraX;
  let mapX=Math.floor(px), mapY=Math.floor(py);
  const ddx = Math.abs(1/rdx), ddy=Math.abs(1/rdy);
  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 hit=0, side=0, tile=0;
  while(!hit){
    if(sdx<sdy){ sdx+=ddx; mapX+=stepX; side=0; } else { sdy+=ddy; mapY+=stepY; side=1; }
    if(mapX<0||mapX>=MAP_W||mapY<0||mapY>=MAP_H){ hit=1; tile=1; break; }
    if(map[mapY][mapX]===1){ hit=1; tile=1; }
  }
  const perp = side===0 ? (sdx-ddx) : (sdy-ddy);
  zbuf[x]=perp;
  const lineH = Math.floor(H/perp);
  let drawStart = Math.floor(-lineH/2 + H/2);
  let drawEnd = Math.floor(lineH/2 + H/2);
  ...
  const tex = textures[(mapX*3+mapY*5)%3];
  let wallX = side===0 ? py + perp*rdy : px + perp*rdx;
  wallX -= Math.floor(wallX);
  let texX = Math.floor(wallX*64);
  if(side===0 && rdx>0) texX=63-texX;
  if(side===1 && rdy<0) texX=63-texX;
  const step = 64/lineH;
  let texPos = (drawStart - H/2 + lineH/2)*step;
  // shading: side darker
  const shade = side===1?0.7:1.0;
  for(let y=Math.max(0,drawStart); y<Math.min(H,drawEnd); y++){
    const texY = Math.floor(texPos)&63; texPos+=step;
    let c = tex[texY*64+texX];
    // apply shade multiply
    ...
    buf[y*W+x]=c;
  }
}
```

Shading requires unpacking. To speed, precompute shaded variants of textures? Or just apply fast multiply with bit ops. Since perp distance also could darken far walls (fog). Optional. I'll precompute for each texture a darkened version for side===1. And maybe distance fog: skip.

Precompute shaded array per texture: for each pixel, r*0.7 etc. Store as separate Uint32Array. Good.

Let me keep two arrays: tex (bright), texDark.

Now mapping texY index: texPos increments. DrawStart can be negative; the first texPos should correspond to y=drawStart. Standard formula:
texPos = (drawStart - H/2 + lineH/2) * step. Then use &63 within loop. Good.

Note lineH could be huge if perp small; drawStart very negative. Loop clamps y. texPos initial may be large positive; &63 works with float? `texPos|0` then &63. floor of texPos and 63. Use `(texPos|0)&63`? bitwise on large float truncates to 32-bit, could overflow if lineH huge (min perp maybe ~0.2 -> lineH ~1500, fine; texPos maybe up to ~1500* (64/1500)=64, fine). Actually texPos range within one texture *steps, max ~64. Good.

Sprites:
Build sprite array each frame: enemies alive + exit.

```
const sprites = [];
for enemy {sprites.push({x,y,tex:enemyTex,type:'enemy', ...})}
sprites.push({x:exitX+0.5, y:exitY+0.5, tex:exitTex, type:'exit'});
sort by distance desc
```

Sprite draw:
```
const invDet = 1/(planeX*dirY - dirX*planeY);
for each sprite:
  const spx = s.x - px, spy = s.y - py;
  const tx = invDet*(dirY*spx - dirX*spy);
  const ty = invDet*(-planeY*spx + planeX*spy);
  if(ty<=0.05) continue;
  const screenX = Math.floor((W/2)*(1+tx/ty));
  const scale = 1.0; 
  const spriteH = Math.abs(Math.floor(H/ty))* (s.type==='exit'?1.0:1.0);
  const spriteW = spriteH; // square
  const vMove = ... vertical offset
  const drawStartX = Math.floor(screenX - spriteW/2);
  const drawEndX = Math.floor(screenX + spriteW/2);
  const drawStartY = Math.floor(H/2 - spriteH/2 + vMove);
  const drawEndY = Math.floor(H/2 + spriteH/2 + vMove);
  for(let x=drawStartX;x<drawEndX;x++){
    if(x<0||x>=W) continue;
    if(ty >= zbuf[x]) continue;
    const texX = Math.floor((x - drawStartX)*64/spriteW);
    for(let y=drawStartY;y<drawEndY;y++){
      if(y<0||y>=H) continue;
      const texY = Math.floor((y-drawStartY)*64/spriteH);
      const c = spriteTex[texY*64+texX];
      if((c>>>24)===0) continue; // transparent
      buf[y*W+x]=c;
    }
  }
```

Enemy sprite textures: generate with height maybe shorter than full; use 64x64 with transparent background and body centered, leave top transparent so enemy appears shorter. Use vMove to sit on floor: shift down by spriteH*0.1 maybe.

Actually with square sprite and floor at H/2 + H/(2*ty)... Sprites should stand on floor: bottom of sprite at floor line. For simplicity, keep centered with slight downward offset.

I'll generate enemy sprite with the figure occupying middle-lower portion, top transparent. Good.

Exit texture: green glowing portal, maybe full cell. Make it semi transparent? Just a bright green rectangle with pattern. Since it's a billboard in the cell, player can walk through sprite (no collision). Fine.

Generate sprite textures:
```
function genEnemy(){
  const t=new Uint32Array(64*64); // all 0 transparent
  const put=(x,y,r,g,b)=>{ if(x>=0&&x<64&&y>=0&&y<64) t[y*64+x]=rgb(r,g,b); };
  // body
  for(let y=16;y<60;y++)for(let x=20;x<44;x++){...}
}
```
I'll draw: head circle around (32,22) radius 8 skin color, body rectangle 22..42 x, 26..52 y dark clothing, arms, legs. Add eyes. Let's just do simple blocky figure.

Exit: rectangle 8..56 x, 8..56 y green with inner glow.

Weapon drawing with ctx: after putImageData, draw gun shape at bottom center. Use scaled coordinates (canvas 480x300). Draw dark gray polygon and a muzzle flash yellow circle when shootFlash>0. Also bob with movement.

Now HUD via DOM: health bar, enemy count, exit status, controls list.

Overlays: start? Not required. Game over and win overlay with restart button. Restart resets state.

Let me handle win: when enemies all dead, exitUnlocked=true. When player position within exit cell (dist < 0.5) and unlocked -> win. If not unlocked, display "Exit locked - X enemies remain" message briefly.

Let me code game state object reset().

Player state: {x,y,dirX,dirY,planeX,planeY,health}.

Actually store angle and derive dir/plane. Simpler store angle. dirX=cos(a), dirY=sin(a), plane = perpendicular * fov factor (0.66).

Let me store player.angle.

Movement:
```
const speed = 3.0*dt;
forward: newx += dirX*... etc.
```
Collision: attempt x then y with radius. Check isWall(newx + sign*radius, y) etc. Simpler:
```
function tryMove(nx,ny){
  const r=0.25;
  if(!collides(nx,py,r)) px=nx;
  if(!collides(px,ny,r)) py=ny;
}
function collides(x,y,r){
  return isWall(x-r,y-r)||isWall(x+r,y-r)||isWall(x-r,y+r)||isWall(x+r,y+r);
}
```

isWall out of bounds true.

Enemy uses same.

Turn: angle += turnSpeed*dt.

Mouse: on pointerlock movementX -> angle += movementX*0.002. Optional. I'll add click to lock but not require.

Shooting logic:
```
function shoot(){
 if(shootCooldown>0) return;
 shootCooldown=0.28; muzzle=0.12;
 // find target
 let best=null,bestDist=Infinity;
 for(e of enemies){ if(!e.alive)continue;
   const dx=e.x-px, dy=e.y-py;
   const dist=Math.hypot(dx,dy);
   // angle between dir and vector
   const dot=(dx*dirX+dy*dirY)/dist;
   if(dot<0) continue;
   const ang=Math.acos(Math.min(1,dot));
   const halfAng=Math.atan2(0.35, dist); // enemy radius 0.35
   if(ang<=halfAng){
     // line of sight
     if(hasLOS(px,py,e.x,e.y)){
       if(dist<bestDist){bestDist=dist;best=e;}
     }
   }
 }
 if(best){ best.hp-=1; best.hitFlash=0.15; if(best.hp<=0){best.alive=false; enemiesRemaining--;} }
}
```

Wait hasLOS needed because angle-based could target through a wall if enemy near line of sight but behind wall. If the enemy is behind a wall along the ray, LOS false -> skip, and maybe the shot hits the wall instead (no damage). Good. But bestDist selection ignores walls for other enemies; since we check LOS, fine.

But note: the ray direction is player's dir; an enemy within angular radius but not exactly along ray might be at angle where a wall blocks. LOS uses straight line to enemy, which is what matters for "shots cannot damage through wall". Good enough.

hasLOS: sample along segment using small steps or DDA. Step method with step 0.1 checking isWall. Distance up to ~30 => 300 steps, fine for occasional calls. But enemy AI calls LOS every frame for each enemy -> 4*60* up to 300 = 72k checks/s, fine. Actually better DDA but step is fine.

Enemy update:
```
for e of enemies if e.alive:
  e.cooldown-=dt; e.hitFlash-=dt;
  const dx=px-e.x, dy=py-e.y; const dist=Math.hypot(dx,dy);
  const los = hasLOS(e.x,e.y,px,py);
  if(los){
     if(dist>1.2){ // move toward
        const sp=1.1*dt;
        move e by dx/dist*sp etc with collision and separation
     }
     if(dist<7 && e.cooldown<=0){ e.cooldown=1.4; damage player 8; hurtFlash=...; }
  }
```

Enemies shouldn't overlap; optional separation. skip or simple.

Player death: health<=0 -> game over state.

Restart resets.

Let me also add enemy attack telegraph: e.attackAnim maybe. Not required.

Now let me write the file. Also add start screen? Not required, game starts immediately. But maybe show overlay "Click to play"? Mouse optional; keyboard works without click. To use pointer lock need click. I'll not gate.

Let me write code now.

I'll keep HUD in DOM top-left and controls bottom-left.

Let me be careful with CSS to make canvas fill screen while keeping aspect. Use:
```
html,body{margin:0;height:100%;background:#000;overflow:hidden;font-family:...}
#game{position:relative;width:100vw;height:100vh;display:flex;align-items:center;justify-content:center;}
canvas{image-rendering:pixelated;max-width:100%;max-height:100%;width:100%;height:100%;object-fit:contain;background:#000;}
```
Actually to preserve aspect: canvas{width:100%;height:100%;object-fit:contain;} with intrinsic 480x300. object-fit applies to replaced elements? canvas is replaced, yes object-fit works. Good. But overlay coordinates: overlays are DOM children positioned absolute relative to #game; fine.

HUD position absolute top-left.

Let me write.

For the weapon, since canvas is 480x300 internal, draw there.

Let me now produce the code fully.

I need to be careful about ImageData and putImageData: create once.

Let me write the script.

```
const W=480,H=300;
const canvas=document.getElementById('c');
canvas.width=W;canvas.height=H;
const ctx=canvas.getContext('2d');
const imageData=ctx.createImageData(W,H);
const buf=new Uint32Array(imageData.data.buffer);
```

Note: new Uint32Array(imageData.data.buffer) — imageData.data is Uint8ClampedArray with buffer; works.

Colors packed little endian: value = 0xFF000000 | (b<<16) | (g<<8) | r.

Generate textures.

Let me code all functions.

I'll write now in one go.

One concern: `ctx.createImageData` then putImageData each frame; then draw weapon using ctx. Fine.

Precompute ceiling/floor row colors into buf each frame? We fill rows every frame; can precompute a background Uint32Array and copy? Copying 144000 ints each frame is fine (buf.set(background)). Let's precompute bg array once, then `buf.set(bg)` each frame. Fast.

bg generation:
```
const bg=new Uint32Array(W*H);
for(let y=0;y<H;y++){
  let r,g,b;
  if(y<H/2){ // ceiling
    const t=y/(H/2);
    r=30+20*t; g=35+20*t; b=50+30*t; // near top brighter? t from 0 top to 1 horizon
  } else {
    const t=(y-H/2)/(H/2);
    r=40+60*t; g=30+45*t; b=20+30*t;
  }
  const c=rgb(r|0,g|0,b|0);
  for(let x=0;x<W;x++) bg[y*W+x]=c;
}
```
Hmm near horizon ceiling should be darker, floor darker. t=1 at horizon for ceiling -> r=50; top t=0 ->30. So horizon brighter? Let's reverse: ceiling darker near horizon: use r=50-20*t. floor near horizon dark: r=30+70*t (t=0 horizon ->30, t=1 bottom ->100). Fine.

Now code.

Let me also handle high-DPI? no.

Now writing full file.

Enemy count: let's use 4 enemies.

Exit locked message via DOM element that fades.

Let me write the HTML/CSS/JS.

For the overlay win/gameover: a centered div with display none.

Let me handle "Restart" button click -> reset().

Also key R to restart maybe.

Let me write.

Health bar in HUD.

Let me now produce file.

I need to double check sprite texture sampling indexing and transparency: packed color 0 means transparent (alpha 0). Our rgb sets 0xFF alpha. Good.

Enemy sprite generation:

```
function genEnemyTex(){
 const t=new Uint32Array(64*64);
 function px(x,y,c){ if(x>=0&&x<64&&y>=0&&y<64) t[y*64+x]=c; }
 function rect(x0,y0,x1,y1,c){for(let y=y0;y<y1;y++)for(let x=x0;x<x1;x++)px(x,y,c);}
 // legs
 rect(24,46,29,60, rgb(30,30,35));
 rect(35,46,40,60, rgb(30,30,35));
 // body
 rect(22,28,42,48, rgb(120,30,30));
 // arms
 rect(16,30,22,44, rgb(120,30,30));
 rect(42,30,48,44, rgb(120,30,30));
 // head
 rect(25,16,39,28, rgb(210,170,130));
 // eyes
 rect(28,20,31,23, rgb(20,20,20));
 rect(33,20,36,23, rgb(20,20,20));
 // outline? skip
 return t;
}
```
This is blocky but recognizable. Could add shading but fine.

Hit flash: when enemy.hitFlash>0, use a white-tinted texture. I can create a white version and swap. Let's precompute enemyTexWhite.

Exit texture:
```
function genExitTex(){
 const t=new Uint32Array(64*64);
 for(let y=0;y<64;y++)for(let x=0;x<64;x++){
   const d=Math.max(Math.abs(x-32),Math.abs(y-32));
   const edge = d>26;
   let c;
   if(edge) c=rgb(20,80,30);
   else{ const glow = 1-d/28; c=rgb(40+80*glow, 200+40*glow, 60+80*glow); }
   if(((x>>2)+(y>>2))%2===0) { /* pattern */ }
   t[y*64+x]=c;
 }
 return t;
}
```
Actually for locked vs unlocked, draw different tint. If locked, dim it. I'll just render with green if unlocked, else dim red/gray. Could pick texture based on exitUnlocked. I'll generate two exit textures.

Now the code for rendering sprites and deciding texture:
- enemy uses whiteTex if hitFlash>0.
- exit uses green if unlocked else gray.

Let me write everything.

For sorting sprites, compute distance squared.

Now let me write the file. I'll be thorough.

Also add screen color tint overlays via DOM (hurt red flash). Use a div with pointer-events none and background rgba red, opacity transitions.

Let me write.

After writing, I'll open in browser, inspect console, screenshot, and test movement/collision/shooting using browser tools. The browser tools include click, type, key, drag, screenshot, inspect, motion. Let me use key actions.

Let me write index.html now.

Let me consider the game loop timing and dt clamp.

Input: keys object. On keydown set true, keyup false. Prevent default for arrows/space/WASD.

Shooting via keydown space (single fire with cooldown). Since holding space could auto-fire; I'll allow if key held and cooldown ready (auto). Fine.

Let me now write.

Also, exit reach detection: compute cell of player; if map cell ===2 and enemiesRemaining===0 -> win. If cell===2 and enemies remain -> show locked msg. To avoid spamming, only when entering.

Also ensure exit cell is reachable and not blocked. BFS ensures.

Now, is exit cell marked 2 but isWall checks ===1 only. Good.

Enemy spawn positions should not be on exit. And not too close to start.

Let me write BFS returning dist array.

```
function computeDist(sx,sy){
  const dist=Array.from({length:MAP_H},()=>new Array(MAP_W).fill(-1));
  const q=[[sx,sy]]; dist[sy][sx]=0;
  while(q.length){const [x,y]=q.shift();
    for(const[dx,dy]of[[1,0],[-1,0],[0,1],[0,-1]]){
      const nx=x+dx,ny=y+dy;
      if(nx>=0&&nx<MAP_W&&ny>=0&&ny<MAP_H&&map[ny][nx]!==1&&dist[ny][nx]<0){dist[ny][nx]=dist[y][x]+1;q.push([nx,ny]);}
    }
  }
  return dist;
}
```

Choose exit = open cell max dist. Enemies = open cells with dist between 4 and maxdist-2, spaced apart (greedy pick maximizing min distance).

Let's implement spawn selection.

Now write.

Let me produce the final file.

I'll write it with `write`.

Let me draft the complete code mentally then output.

Potential performance: per frame loops W*H for bg set (144k) + walls + sprites. Should run fine.

Let me include FPS? not needed.

Now output.

One more: texture shading for far distance (fog). I'll add: if perp > 6, darken. To keep fast, compute a shade factor per column and apply via precomputed darkening? Applying per pixel multiply requires unpack. Could precompute multiple shade levels per texture (e.g., 4 levels). Let's precompute for each texture an array of 4 shade levels (1.0,0.8,0.6,0.4) plus side darkening. Might be overkill. I'll just do side shading with two versions (bright/dark) and skip distance fog. Good enough.

Actually to make depth clearer, I can darken based on distance cheaply by multiplying the packed color? No.

I'll precompute 4 shade levels per texture: shade index = min(3, floor(perp/4)). And side darkening combine: just use bright array for side 0 and darker for side1. Let me create texLevels[t][level] where level 0..3, and side multiplies further? Let's keep 5 levels: compute brightness = (side===1?0.7:1.0) * (1 - min(0.6, perp/25)). Then level = round((1-brightness)/0.15) etc. Too complex.

Simpler: 4 distance buckets, and for side use an extra multiplier by selecting from two sets. I'll just create for each texture 4 shaded versions and pick based on distance, ignoring side. Side difference gives depth cue but distance already does. Let's do distance-based only. Buckets: level = Math.min(3, perp/5 |0). Actually perp can be large (up to ~30) -> level 3 for >15. Good.

Create shaded textures:
```
function shadeTex(tex, f){ const o=new Uint32Array(tex.length); for(...){ unpack; o[i]=rgb(r*f|0,g*f|0,b*f|0);} }
```
levels f = [1.0, 0.8, 0.62, 0.48].

texLevels[t] = [t0,t1,t2,t3].

At render, choose tex = texLevels[material][level]. Fine.

Metal overhead acceptable.

Now code.

Let me write it.

Actually, I realize unpacking requires knowing endianness; I construct with rgb so unpack manually: r=c&255, g=(c>>8)&255, b=(c>>16)&255. Good.

Let me write.

I'll now create the file.

Let me write the full index.html.

Rendering looks good. No console errors. Let me test movement, turning, collision, and shooting. Let me use key actions. The browser tool key action takes text presumably key names. Let me check by pressing ArrowRight and W. I'll use inspect to get state.

Let me get player state via inspect? The inspect returns DOM/console. I can evaluate JS? Not directly. Maybe I can use the browser tool's "type" or "key". Let me read player state by injecting? The inspect likely returns dom and console. I could add debug info to DOM. Actually I exposed window.__game but can't eval. Maybe inspect includes console logs. I can temporarily update HUD? Let me just test visually with screenshots.

Let me test turning: press ArrowRight a few times and screenshot.

Actually the key action takes "text" param. Let me try.

The key events appear not to have changed the view. The key tool likely dispatches keydown+keyup immediately, so held movement doesn't happen (game loop needs key held over frames). A single ArrowRight keydown/keyup in one instant results in negligible turn since update runs on rAF and the key may be released before the next frame. Also the screenshots look identical across the three, meaning no change.

I need a way to hold keys. Perhaps the "key" action supports a duration or the type action. Let me look at the browser tool documentation? Actually the schema only has text. Maybe there's a way: use "type" action with text? Hmm.

Alternatively I can verify logic by exposing debug and using console. Since inspect returns console, maybe I can add a temporary debug that logs player state each second. But better: I can add a URL-hash-driven test harness? That's hacky.

Let me think about how key events work. Perhaps key action holds the key until next action. Let me try pressing key then taking a screenshot after some motion. The results came back at "Frame 1, +0ms" suggesting the page maybe not animating between? Actually the browser tool may batch and screenshot immediately, so no time passes.

Maybe there's a "motion" action that captures frames over time. Let me try motion after a key press. Perhaps the key remains down. Let me press KeyW then motion to see movement.

Actually the key action likely sends keydown+keyup. To hold, maybe I need to issue key down? Not available. Hmm.

I could add a small test capability: e.g., if location.hash contains commands, but that doesn't help since I can't navigate.

Better approach: modify the page temporarily to auto-run a self-test that simulates key state and logs results to console, then inspect console. I can set keys via a debug API and advance frames. Let me add window.__test functions that set inputs and log. Actually I can just add code that after load runs a scripted sequence and console.logs: turn by setting keys['ArrowRight']=true for N frames, movement, collision check, shoot. Since requestAnimationFrame runs, I can use setTimeout.

But the browser screenshot after "reload" was Frame 1 +0ms. Does the page keep running? The screenshots of different key presses looked identical. If animation were running, enemy AI might move but player not, so view same. That's consistent with keys not held.

Let me check whether the page is animating by looking at enemy positions. Enemies far away maybe hidden.

I think the cleanest verification: add a temporary auto-test to the page that manipulates the exposed state directly and logs to console. Since I exposed window.__game but the internal `keys` isn't exposed. Let me expose a test hook. I'll edit the file to add `__test` with methods: press(code, on), step(dt) that calls update+render, and info(). Then I can ... but I still can't call JS from the browser tool unless via console. The inspect returns console messages but doesn't let me evaluate.

Alternative: auto-run test in page and console.log results; then reload and read console. That works. I'll add a self-test block guarded by a flag, run it, read console, then remove it before final save. Or keep it harmless? Better remove.

Actually simpler: I can make the self-test run when the page loads (temporarily), log results to console, inspect, then delete. Let me do that.

But wait — does the browser tool's console capture console.log? It reported console:[] earlier. Presumably yes, it captures. Let me test.

Let me add a test harness that:
- records initial player pos/angle
- simulates forward movement for 1 second -> position should change
- simulates turning
- wall collision: move into wall, ensure blocked
- shooting: teleport player near an enemy and shoot, check enemy hp decreases; also place enemy behind wall and shoot, ensure no damage.

I'll implement using an internal function stepSim(dt) that calls update(dt) directly (without render). But update reads `keys`. I can set keys from within closure.

Let me add at the end before resetGame:
```
window.__selfTest = function(){...}
```
But calling it requires JS eval. Instead auto-run via setTimeout after load and console.log.

Let me write the test to run automatically and log "SELFTEST ...". Then reload and inspect console.

I need to be careful that update() and hasLOS use `player` etc. Fine.

Test plan:
1. initial = {x,y,angle,health}
2. Set keys KeyW true, call update(0.1) x10 => moved forward.
3. keys all false.
4. Turn: keys ArrowRight true, update(0.1) x5 => angle changed.
5. Collision: set player at start, angle toward a wall, try move forward many steps, ensure no wall penetration (check collides(player.x,player.y,0.22) false and that it's inside walkable). Actually simpler: set player adjacent to a wall and attempt to move into it; position along that axis shouldn't change past wall.
   Determine a wall neighbor of start: start (1,1); wall at? In carved maze (0,1) might be wall or (1,0). Force: set player.x=1.5,y=1.5, angle=Math.PI (facing -x, wall at x=0). Move forward 2 sec; player.x should stay >= 1+radius-ish, i.e., not < ~1.2. Check collides at final false.
6. Shooting: pick an enemy, teleport player near it within LOS, aim angle to enemy, set other enemies far/dead? Just aim at nearest alive, shoot, check hp decreased and enemiesLeft.
7. Wall occlusion: create a temporary enemy behind a wall and shoot toward it, ensure no damage. Hard to guarantee a wall. Instead test hasLOS directly with two points across a known wall. e.g., start (1,1) and cell (0,1) is outside -> wall. hasLOS(0.5,0.5, ...). Hmm.

Simpler occlusion test: find a wall cell and two open cells on opposite sides. Compute on the fly by scanning. Or just test hasLOS between two cells separated by a wall: use the map. Iterate all pairs of adjacent-through-wall? Let me just pick a wall cell with open cells on both sides. Then hasLOS between points across it should be false, and damaging test: place enemy one side, player other side, aim, shoot, enemy hp unchanged.

Let me implement the test to log pass/fail.

But maybe overkill; I can trust code and do a simpler visual + logic test. Given time budget (15 min), let me add the harness quickly.

Actually, maybe the key tool does hold keys and the issue is the screenshots are taken at +0ms before animation. Let me try the "motion" action to capture over time. If motion shows movement, great. Let me first try: press and hold via key action might work if keydown only. Let me test motion after ArrowRight.

Let me just try motion.

Motion frames show identical view; the key was released immediately so no movement (or movement so tiny). The rendering itself is stable and textured. The weapon is drawn (vertical gun). Good.

Now I need to verify movement/turning/collision/shooting logic. Since the browser tool doesn't hold keys, I'll add a temporary self-test that runs automatically and logs to console. Let me add it.

Actually, wait: maybe the key action does hold the key until a subsequent action, but the motion result happened after the key call. The frames show no movement though. Possibly keydown event's e.code — the browser tool "text" is "KeyW"; maybe it dispatches key events with `key` not `code`, and our handler uses e.code. Let me check: if the tool sends text "KeyW", maybe it's treated as typing characters and dispatch keydown with key="KeyW"? Then e.code would be empty/unset. Hmm. That could be why. Let me try passing "w" instead and see. But our handler uses e.code 'KeyW'. A real keypress of 'w' has code 'KeyW'. If the tool simulates properly it should set code.

Let me test by using the "type" action with "w"? Type usually inputs text. Since there's no input field, it goes to document.

Let me just add the self-test harness to be certain and also possibly improve key handling to accept e.key as fallback. Actually adding fallback for keys is a genuine robustness improvement: handle both e.code and e.key. Let me add that, plus a self-test.

Actually, rather than a persistent self-test, I'll write a temporary separate test file? The requirement says all into index.html. I can create test.html for verification then delete it, but the deliverable is index.html. However browser tool loads index.html presumably. Let me instead temporarily append a self-test script to index.html, run, then remove.

Let me add a query/hash-independent auto test via setTimeout(…, 500) and console.log. Then reload and inspect console. Let me edit.

I'll add before `resetGame();` a block:

```
  // ---- TEMP SELF TEST ----
  setTimeout(function(){
    const log=[];
    function step(n,dt){ for(let i=0;i<n;i++){ update(dt); } }
    // baseline
    ...
  }, 300);
```

But `keys` is in closure, accessible.

Let me write assertions.

Test A movement: initial x,y. keys.KeyW=true; step(20,0.05)=1s; keys.KeyW=false; log dx,dy. Expect moved > 0.5.

Test B turn: angle before; keys.ArrowRight=true; step(20,0.05); expect angle increased.

Test C collision: set player to start center, angle=Math.PI (facing -x wall), keys.KeyW true step(40,0.05)=2s; expect player.x >= ~1.2 (can't reach x<1.22) and not colliding. Also verify collides false. Log final x.

Test D shoot hit: find an alive enemy, move player to a nearby open cell with LOS and aim. Easier: place player at the enemy's cell offset? If I place player very close (dist 1.5) with LOS, aim, shoot, check hp drop and enemiesLeft. But need LOS; being adjacent ensures LOS (distance 1.5 within same corridor likely). Let me choose enemy e, set player.x=e.x-1.0, y=e.y; need that cell non-solid and LOS. Since enemy was spawned in open cell, position 1 unit left might be wall. Let me instead test by directly using hasLOS across a wall for occlusion, and test shoot by teleporting player to e position minus direction vector computed from a valid open neighbor.

Alternative deterministic approach: Instead of relying on generated spawn, directly test the shoot function with a synthetic enemy placed at a known open location relative to player. But `shoot()` iterates `enemies`. I can temporarily set enemies to a controlled array and player position, call shoot, then restore. That's clean.

Test D: set player at (1.5,1.5) facing +x (angle 0). Place one enemy at (3.5,1.5) IF map[1][2] or [1][3] open. In carved maze start cell (1,1) has at least one open neighbor, not guaranteed +x. Let me compute a direction from start to an open neighbor, place enemy along it at distance 2, ensure cells between open. Simpler: find an open cell adjacent to start; place enemy there (distance 1). Aim along that direction. dist=1, within range, LOS true. shoot -> hp decreases.

But enemy placed at adjacent cell might be at edge; player at 1.5, neighbor at (2.5,1.5) distance 1.0. LOS clear. Good. But wait, enemy could occupy same cell as a wall? neighbor is open by construction.

Test E occlusion: find two open cells with a wall directly between separated by 2 (i.e., pattern open-wall-open). Scan map for open (x,y) and (x+2,y) with (x+1,y) wall. Place player at first center, enemy at second center, aim +x, shoot, expect hp unchanged (blocked). Also hasLOS returns false.

Test F exit unlock / win: set all enemies dead via repeated shoot or directly; then check exitUnlocked after killing. Could simulate by calling shoot 3 times per enemy with cooldown reset. Simpler: directly test that when enemiesLeft reaches 0 the flag sets. I'll set enemies to a single enemy with hp1, shoot it, verify enemiesLeft 0 and exitUnlocked true. Then move player to exit cell and call update -> gameState 'win'.

Then restore state by resetGame().

Let me code it. Log results as a single console.log string with PASS/FAIL.

Then remove the block after verifying. Actually I might keep a minimal exposure but remove the auto-run to avoid console spam.

Let me implement.

Also add key fallback handling. Let me modify keydown/keyup to normalize. I'll create helper mapping from e.key to code when code missing:
```
function norm(e){
  let c=e.code;
  if(!c){ const k=e.key; if(k===' '||k==='Spacebar')c='Space'; else if(k.length===1)c='Key'+k.toUpperCase(); else c=k; }
  return c;
}
```
But arrow keys have key 'ArrowLeft' which equals code. Good.

Actually e.code is standard in browsers even for synthetic events usually. The tool may set key only. Adding fallback is safe.

Let me apply edits.

The console is empty at reload time; the self-test runs at 400ms. The reload capture happens immediately. I need to wait — use motion (takes ~1.6s) then inspect console. Let me do motion then inspect.

All 7 self-test checks pass:
- forward moves 2.70
- turn works
- wall collision holds x=1.23
- shot damages enemy
- wall blocks LOS and shot
- kill-all unlocks exit and win triggers
- enemy attacks player

Note the screenshot shows the toast "ALL ENEMIES DOWN - EXIT OPEN" from the test, and HUD shows 4 enemies (resetGame at end restores). The rendering shows nice textured walls. However the view shows a long corridor with a wall ahead. The screenshot is the frame before reset maybe. Fine.

Now I need to also visually confirm enemies are visible and occluded. The self-test moved player around but final resetGame restores start. The toast persists since resetGame sets toastTimer=0 but doesn't hide opacity? resetGame sets toastTimer=0 but toastEl opacity remains from before? Actually resetGame doesn't reset toastEl.style.opacity. In update, toast opacity only changes when toastTimer>0 reaches 0. Since resetGame sets toastTimer=0, the toast stays visible ("ALL ENEMIES DOWN...") even after restart. That's a bug: restart should clear the toast. Let me fix resetGame to hide toast.

Also the screenshot shows the toast overlapping. Let me fix.

Also I should remove the temporary self-test before final delivery. But keeping it would spam console; requirement doesn't forbid, but cleaner to remove. However, the addendum says verify and fix; final file should be clean. Let me remove the self-test block.

But I want to also verify enemies rendering visually. Let me first do a quick test: temporarily make player face an enemy? Hard. Instead, I trust the sprite code but let me visually verify by taking a screenshot after the self-test moved... Actually I can add a temporary "peek" that places player near an enemy for a screenshot, then remove. Let me do one more quick verification with a temp hook that positions player in front of an enemy at start, screenshot, then remove all temp code.

Actually simpler: In the self-test, after reset, teleport player near an enemy and render once so the screenshot shows an enemy. But that would alter final state. Since I'm removing the test anyway, I could temporarily add it, screenshot, then finalize. Let me do a quick temp addition: after self-test, position player near first enemy and call render(). Let me edit the self-test end to do that, take screenshot, confirm enemy sprite and exit sprite visible, then remove the whole temp block and fix restart toast.

Let me add before resetGame() at end of test:
```
// visual: stand in front of an enemy
resetGame();
const e0 = enemies.find(e=>e.alive);
if(e0){ player.x = e0.x - 1.2; player.y = e0.y; /* ensure open */ player.angle=0; }
render();
```
But player.x-1.2 might be wall. Better find direction: place player at enemy minus unit along x if open else y. Let me scan neighbors of enemy that are open and stand opposite. Eh. Since enemy is in open cell and maze corridors, at least one neighbor open. Place player at neighbor center and face enemy. Let me compute:
```
const dirs=[[1,0],[-1,0],[0,1],[0,-1]];
for each dir: nx=e0.x+dx, ny=e0.y+dy; if map open -> player.x=nx+0.5... wait e0.x is center already (c+0.5). neighbor cell center = e0.x+dx, e0.y+dy. Place player there, angle=atan2(-dy? ) facing back to enemy = atan2(e0.y-py, e0.x-px).
```
Then render. Good.

Let me make that temp edit.

The screenshots show the corridor but no enemy visible. The render() call in the test happened but then the rAF loop keeps running update/render, which after resetGame should be at start. Wait — the test's visual positioning happens, then render(), but then the ongoing rAF loop calls update() which does nothing (keys cleared) and render() with the player at that position. So the enemy should be visible ahead. But the screenshot shows the original start corridor with "ALL ENEMIES DOWN" toast. Hmm, the player is standing in front of enemy but no enemy sprite visible.

Wait, the screenshots don't show an enemy. Possibly the visual positioning placed the player at a neighbor cell but the enemy is not in view because the angle points at the enemy but there's a wall? No, if neighbor is open and adjacent, LOS clear.

Or maybe the rAF loop's `player` is same object; positioning works. But note the visual block calls resetGame() then finds e0. The final resetGame() before visual sets player at start. Then we override player.x/y/angle. Then render. Then rAF continues rendering same position. Screenshot should show enemy at center.

But maybe the enemy is exactly at the crosshair and rendered, but it's small/close? At distance 1, spriteH = H/ty. ty ≈ distance ≈ 1, so spriteH = 300 → fills screen vertically. The enemy should be huge in the center. It's not there.

Hmm, why? Let me reconsider: the visual block runs after the self-test section F/G which set `enemies` to synthetic arrays. Then at the very end, before visual, there's `resetGame()` — yes I edited to insert visual after resetGame. So enemies are the normal 4. e0 found.

Wait, actually in test G, `enemies = [{...}]` synthetic. Then resetGame() restores 4 enemies. Then visual picks e0. Good.

But note: the toast "ALL ENEMIES DOWN - EXIT OPEN" is visible, which came from test F kill. resetGame doesn't clear the toast opacity (bug I noted). So the test at end is showing toast. That indicates we are after resetGame. So visual ran.

Why no enemy? Let me think about sprite rendering. sprites sorted, then invDet etc. If player is adjacent to enemy, ty ≈ 1, tx ≈ 0. screenX = 240. spriteH=300, spriteW=300. dsx=90,dex=390, dsy=0,dey=300. It loops and draws. Unless ty <= 0.08 no. Should be visible.

Unless the enemy cell chosen as neighbor: `(e0.x | 0)` is enemy cell x. dirs neighbor. If open, player placed there. angle faces e0. Good.

Maybe the screenshot captured at Frame 1 before the setTimeout(400ms) executed? No, console log present means test ran.

Hmm wait, maybe after test, the rAF update() moved the enemy away? update() with no keys: enemies AI, if LOS to player, move toward player, and attack. Player adjacent dist 1 < 1.15 so doesn't move, but attacks. Fine. Enemy stays.

Let me reconsider: maybe the visual positioning's neighbor loop finds a neighbor, but that neighbor may be the cell the player came from? Doesn't matter.

Actually maybe the issue: after resetGame(), `spawnCells` still set, fine.

Let me check: could the enemy be rendered but hidden behind the toast text and the central area is actually just dark? The screenshot center shows a gray stone wall at the end of corridor, not a big enemy. So not rendered.

Possibly `enemies.find` — enemies is array with objects, fine.

Wait, maybe the visual block executes but then `console.log` and setTimeout done. However, the ongoing rAF `update` sees player adjacent to enemy, enemy attacks, and... no movement. render each frame. Should show.

Let me reconsider the sprite drawing: `if (ty >= zbuf[x]) continue;` The zbuf at center column for the corridor: the wall ahead is far, perp large, so ty(1) < zbuf, passes. Good.

Maybe the problem is the angle. player.angle set to atan2(e0.y-player.y, e0.x-player.x). Suppose neighbor is +x, player at nx+0.5, e0.x = player.x+1. angle=0. dirX=1. Good.

Hmm, but what if the chosen neighbor is actually the cell behind a wall? We check `map[ny][nx] !== 1`. map cell could be 2 (exit) which is not wall, fine.

So should render.

Wait — maybe the screenshots attached are from the earlier frames (Frame 1) and the latest one? The tool says "only the latest 4 images stay in context" and attaches. All four images look identical. They might all be pre-test frames captured during the motion, and the visual render happened after the last frame? Motion captured 4 frames over 1.65s, test at 0.4s, so frames 2,3,4 should be after. Yet identical.

Unless the rAF isn't running after? It is.

Let me directly take a screenshot now (not motion) to see current state.

Actually, maybe the enemy rendering has a bug: sprite texture y indexing. Let me recheck: enemy art occupies y 14..63, so it's drawn. With full height, visible.

Let me just take a screenshot now.

Actually, wait. I bet the issue is that resetGame() is called at the very start of the test's setTimeout for test A-F, and each resetGame uses the same map. At the end, visual runs. But then... Actually there's an important detail: the main game loop `frame` calls `update(dt)` and `render()`. The test's manual `update` calls during A-F don't move the main player because they operate on same state; that's fine. At the end, player is positioned near enemy.

Hmm, let me check if maybe the enemy is in the same spot as a wall? no.

Let me just inspect by taking a fresh screenshot and also maybe add console log of player/enemy positions and sprite count. Let me modify visual block to console.log player, e0, and whether ty/zbuf passes. Actually simpler: log player and e0 coords.

But maybe the images attached were stale. Let me take a direct screenshot.

Still no enemy. Let me add debug logging to the visual block to print player and e0 positions, and check if ty/zbuf. But maybe the issue is my visual positioning isn't executing because of an exception? If an exception occurred in setTimeout after tests, console would show error. Console shows only the SELFTEST log. If visual threw, we'd see an error before console.log since visual is before console.log... Actually visual is before console.log('SELFTEST'), so if it threw we'd get no SELFTEST log. We got it, so it ran.

So render() ran with player positioned. But rAF also renders. Hmm.

Wait — maybe the enemy IS being drawn but there's a subtle bug: sprite textures `sp.tex` — for enemies, `e.hitFlash > 0 ? enemyTexFlash : enemyTex`. Fine.

Let me reconsider invDet. planeX = -dirY*FOV, planeY = dirX*FOV. Standard Lodev: plane is perpendicular to dir. invDet = 1/(planeX*dirY - dirX*planeY). Let's compute: planeX*dirY - dirX*planeY = (-dirY*FOV)*dirY - dirX*(dirX*FOV) = -FOV*(dirY^2+dirX^2) = -FOV. So invDet = -1/FOV ≈ -1.515.

Lodev's standard: planeX = dirY*FOV? Actually Lodev uses plane = (planeX, planeY) with dir=(dirX,dirY), and camera plane must be perpendicular. Typical: dir=(-1,0), plane=(0,0.66). Then planeX*dirY - dirX*planeY = 0*0 - (-1)*0.66 = 0.66. In our code with angle: dir=(cos,sin). A perpendicular is (-sin,cos). plane = (-sin,cos)*FOV. Then planeX*dirY - dirX*planeY = (-sin)(sin) - (cos)(cos) = -(sin^2+cos^2) = -FOV. So invDet negative. That flips tx sign. The standard sprite formula:
```
transformX = invDet * (dirY*spriteX - dirX*spriteY)
transformY = invDet * (-planeY*spriteX + planeX*spriteY)
```
With invDet = 1/(planeX*dirY - dirX*planeY).

With our plane = (-sin,cos)*FOV, denominator = -(FOV). So invDet = -1/FOV. For enemy directly ahead: dir=(0,1) (angle=pi/2), plane=(-FOV,0). spriteX=0, spriteY=1 (enemy 1 unit ahead). transformY = invDet*(-planeY*0 + planeX*1) = (-1/FOV)*(-FOV*1) = 1 >0 good. transformX = invDet*(dirY*0 - dirX*1) = 0. Good, so directly ahead works.

For angle 0: dir=(1,0), plane=(0,FOV). enemy at (1,0): spriteX=1,spriteY=0. transformX = invDet*(dirY*1 - dirX*0)=0. transformY= invDet*(-planeY*1 + planeX*0)=(-1/FOV)*(-FOV)=1. Good.

So sprite rendering math is correct.

Then why not visible? Let me consider: maybe `e0` neighbor selection loops and picks a neighbor cell, but then the rAF's update() moves enemy? dist 1 <1.15 so no move. 

Maybe the enemy is rendered but its color blends? No, at distance 1 it'd fill the screen.

Let me actually check if the visual block found a neighbor: maybe all 4 neighbors of enemy are walls? Impossible in carved maze.

Wait, could it be that after the test's final `resetGame()`, then visual positions, then the rAF loop's `update` runs and calls gameOver? No.

Hold on. Maybe the browser screenshots are of a cached/static render because the page's rAF is throttled when not focused? But earlier motion frames updated? They were identical. Maybe rAF isn't running at all in this headless environment, and only the initial render (from resetGame + frame request) happened. The first `requestAnimationFrame(frame)` initial call rendered the start view. The test's explicit `render()` calls in visual... wait we call render() in visual, which would render the enemy view onto canvas. Unless the canvas was subsequently overwritten by... nothing (rAF not running). So the last render should be the visual one. But screenshot shows start corridor.

Unless the visual block's player positioning didn't take effect before render because... it did.

Hmm, but the console SELFTEST log and toast "ALL ENEMIES DOWN" visible indicate state after test F. The rendered view is start corridor though. If rAF isn't running, the canvas shows whatever the first frame rendered (start). The visual render() should have overwritten it. Unless render() threw before putImageData, but then console.log wouldn't run.

Wait, order in visual block: it modifies player and calls render(), THEN console.log. So render completed.

Unless... `resetGame()` at start of visual? No, visual starts after the `resetGame();` line that precedes it. Let me re-read the inserted code: I replaced `resetGame();\n console.log(...)` with `resetGame();\n (function(){...})();\n console.log(...)`. Yes.

So render() with enemy should have drawn. Yet screenshot shows no enemy. Maybe the enemy is there but the camera is inside the enemy/in a wall and we see through? At distance 1 the sprite is huge; center column should sample texture. If player is placed in neighbor cell, direction to enemy; the sprite should cover.

Could the issue be that the chosen neighbor is actually the cell where the player already is? No.

Let me add logging of player.x/y and e0.x/y and compute what render should show. Actually, I suspect the screenshots might be stale/cached and the actual current page differs. The screenshot action returned "Frame 1, +0ms" again with same console — maybe it re-navigated? "Frame 1" suggests each action starts a new frame count. Hard to know.

Let me add more console logging and use motion. Let me log: player pos, e0 pos, angle, and also log inside render for the nearest sprite transform values. Simplest: in visual block, after positioning, compute the sprite transform manually and log.

Actually, let me just log positions.

The VIS log didn't appear — only SELFTEST. That means the visual block after resetGame either didn't run or threw? Actually console shows SELFTEST but no VIS. Wait, VIS log is inside the visual IIFE before console.log('SELFTEST')? No — I inserted the VIS console.log inside the IIFE, and then the `console.log('SELFTEST...')` comes after. So VIS should print before SELFTEST. But console order shows SELFTEST only... Actually console arrays may be truncated or only first? It shows only one log entry "log: SELFTEST\n...". The VIS log missing means the IIFE didn't execute or console.log within got swallowed.

Wait — maybe my second edit didn't apply where I thought. Let me check the file around the visual block. Perhaps the first edit (adding visual) and second edit conflict. Let me read.

Actually the more important question: why is the rendered view the start corridor and not the enemy view, even though render() should have been called. And no VIS log. Suggests the visual IIFE isn't present/running. Let me read the file.

Also notably the screenshots show a stable, nice render. That's good. But the enemy test view missing.

Let me read the tail of index.html.

The code is there. But VIS log wasn't shown in console. Odd. Maybe the browser tool console only keeps the last log or the first? The console array earlier showed only one entry. Perhaps it truncates to a single log line? In the first self-test it showed one entry "log: SELFTEST\n...". Now with two logs, maybe only one shown—the SELFTEST (later) replaced? The tool might only show the most recent console entry. That explains missing VIS.

Anyway, the bigger issue: screenshot shows start view, not enemy. But if render() in visual executed and no rAF afterwards, screenshot should show enemy. Unless rAF IS running and resetting? No, rAF render uses current player/enemy, same positioned. So it'd show enemy too.

Wait, maybe after visual positioning, the ongoing rAF `update()` runs. Player adjacent to enemy dist ~1.0 < 1.15, enemy attacks. But also, hmm, `update` might trigger `gameOver`? Player health 100, enemy hits 9 → 91. Fine.

So enemy view should persist. Unless the rAF loop isn't running and the visual render happened, but then... the screenshot shows start. Contradiction.

Unless the visual positioning picks neighbor but then `render()` draws and then something re-renders start. The only other render is in `frame` (rAF). If rAF is running, update() doesn't change player, so frame renders the same enemy view. So either way enemy view.

So why start view? Let me reconsider: maybe `e0` is undefined because after resetGame, `enemies` variable... wait, in self-test test G we did `enemies = [{...}]`; then resetGame() reassigns `enemies = spawnCells.map(...)`. Fine.

Maybe the player positioning neighbor loop: `map[ny] && map[ny][nx] !== 1` — map[ny][nx] could be 2 (exit) fine, or 0. So it sets player. But if all four neighbors are walls, e0 remains and player stays at start. In a carved maze, enemy cell must have at least one open neighbor (it's reachable). So fine.

Hmm, but wait: could `render()` in visual have thrown an exception AFTER putImageData? No, putImageData is near end then drawWeapon. If drawWeapon threw, we'd catch? No, uncaught, and console.log after wouldn't run. Console shows SELFTEST, so render+log completed.

Let me actually check: maybe the screenshots I'm seeing are from a DIFFERENT page load. The motion action might navigate/reload the page? "Frame 1, +0ms" each time. If each browser action reloads, then setTimeout runs again each time; VIS and SELFTEST logged; screenshot after last frame shows... at time ~1.6s after load, visual ran at 0.4s, so enemy view. Still.

Unless setTimeout(400) and the visual run, but the very first rAF frame after that (at some point) — frame() calls update then render. update() with player adjacent: enemy attacks, health drops. render enemy view. So enemy view.

I'm confused. Let me directly check by logging the player state via the exposed __game and using the DOM? I can't eval.

Alternative: Maybe the enemy sprite IS drawn but the player was positioned such that the enemy is behind them? atan2 correct. Or the selected neighbor is diagonal? No.

Let me look more carefully at the screenshot. It's a corridor; at the end there's a wall. Maybe the enemy is there but tiny? No, distance 1.

Hold on—maybe the visual block runs, but then resetGame is called AGAIN by the 'R'? no.

Let me add a persistent on-screen debug text that writes player/enemy to the HUD or title, then screenshot. Or simpler: console.log only from VIS (remove SELFTEST log) to see it. But the tool only shows one log maybe. Let me log everything in a single SELFTEST string, appending VIS info. That way it's all in one entry. And make the final string the last. Let me restructure: build the VIS info into results before logging.

But the visual render issue remains. Let me test by, in the visual block, directly drawing a red rectangle at center after render, to check whether visual render is what's shown. If the screenshot shows red mark, visual render is live; if not, something else. Actually simpler: set document.body style? Let me just trust that screenshots after actions might be capturing a fresh load's first frame.

New theory: The browser tool's "motion"/"screenshot" reloads the page each time (Frame 1 +0ms), and screenshots are taken very early (before setTimeout). Yet the console shows SELFTEST because console persists across reloads? Possibly console accumulates. The DOM shows "ALL ENEMIES DOWN - EXIT OPEN" toast, which only appears after test F. So the DOM is from after the test, meaning the page did run the test. So screenshot is after test.

So after test + visual, view should be enemy. Hmm.

Wait, maybe the toast text is set in DOM but the canvas is stale from an earlier frame because rendering to canvas isn't captured? No.

Let me try a cleaner approach: remove the visual hack, and instead make a dedicated deterministic check that sets up an enemy directly in front of the player at a guaranteed open spot and renders, and put the debug in the same SELFTEST log. Also make the enemy render independent of AI by setting gameState to something that stops update? Set gameState='win' temporarily so update returns early, then position and render. Then rAF won't move anything and render will show enemy. But rAF still renders enemy view. Good.

Actually, the simplest robust visual test: temporarily set `enemies` to an enemy placed at player + dir*1.5, where player is at start facing an open neighbor, and the cell at 1.5 ahead may be wall though. Let me instead place enemy at the open neighbor (dist 1) and freeze gameState='win'. Then render. Let me rework.

But I already have shot-hits-enemy test that confirms sprite target math (shoot uses angle not sprite rendering). The sprite rendering is the untested visual part. Let me verify sprite rendering directly with a deterministic setup and single combined log.

Let me replace the whole self-test block with a cleaner version producing one log, and include a "frozen" enemy-in-front render. Actually, maybe the real issue is that boss found: after visual positioning, `render()` draws enemy, but then the rAF frame calls `update` -> since I set gameState? It's 'play'. Fine. render again. enemy view.

Unless... the rAF `frame` uses `dt` and the player is adjacent; enemy attacks and eventually kills? no, one hit per 1.35s.

Let me just check with a fresh combined log including whether the visual block executes; and freeze.

Actually, wait. I want to double-check my sprite vertical placement math. For enemy at distance 1 with scale 0.95: fullH = 300/1 = 300, spriteH=285, spriteW=285. dsx=240-142=98, dex=382. dsy=(150-142)=7, dey=292. All good. texX for x=240: (240-98)*64/285 = 142*0.2246=31.9 ->31. texY ranges. Enemy art x 15..49, y14..63. texX 31 is body -> drawn. So center pixel should be enemy color.

So it must render. Unless `ty >= zbuf[x]` — zbuf at center: wall ahead distance maybe ~3? ty = 1, so 1>=3 false, passes.

OK. So I strongly suspect the screenshots are just not reflecting the visual render because the page reloads on each action and screenshot is early. But DOM toast proves otherwise... unless the toast is from a prior load and DOM persists? Unlikely.

Let me stop over-analyzing and do a definitive test: put the debug numbers into the HUD title element (DOM) and read via inspect, and also freeze the game so view stays. Let me modify the visual block to set gameState='win' (so update returns early), position player in front of enemy, render, and set document.querySelector('.title').textContent to positions. Then inspect returns DOM text.

Let me do that.

Now the DOM title should show "VIS p... e..." but the inspect output still shows the normal DOM text and the title is still "RAYCAST BUNKER". So the visual block did NOT execute! The DOM text shows "RAYCAST BUNKER", not "VIS p...". And no console VIS. But SELFTEST log printed.

That means the code after `resetGame()` in the self-test... wait the block order: ... test G, resetGame(), visual IIFE, console.log SELFTEST. If visual didn't run but SELFTEST logged, then the IIFE must not be there at runtime — maybe the browser is serving a cached older version of index.html! The screenshots are identical across all actions, suggesting the browser cached the page and isn't picking up my edits.

Yes! The page is cached. My first version had no visual block; reloads/motions show the cached first version. The console SELFTEST appears (from first version). The title stays "RAYCAST BUNKER". That explains everything: the browser isn't reloading the updated file.

I need to force reload with cache bypass. The `reload` action may use cache. Maybe appending a query param isn't possible. But maybe the browser tool reloads from file and my edits aren't saved? They are saved to disk (grep confirmed). Perhaps the tool serves a snapshot? Or maybe reload caches.

Hmm, but console shows SELFTEST which was only added in my second edit (the self-test). The very first version had no self-test. So it did load a version with the self-test. So it loaded the version from after edit #2 (self-test added), but not the later visual edits. So the browser may only pick up changes on explicit `reload`, and motion doesn't reload. And my last `motion` didn't reload. The screenshots from motion are the same loaded page from the last `reload`.

So I need to call `reload` after edits, then motion to let the test run. Earlier I did reload after the self-test edit and got the SELFTEST. Then I made visual edits but only called motion, not reload. That's why visual didn't run.

So: call reload now, then motion, then screenshot.

But also, this means the enemy view render should work. Let me reload and check.

Also note: the first screenshot in this batch actually looks good. Let me reload and run.

Also the enemy in front test: because gameState='win', the overlay might show "LEVEL CLEARED" because winGame? No, setting gameState='win' directly doesn't call winGame, overlay hidden. Good.

Let me reload then motion.

Now the initial view is a new level (red brick wall straight ahead) since resetGame regenerates? Wait, setupLevel only on first load; each reload creates new random maze. Good. Initial view shows a wall straight ahead (facing an open neighbor maybe). Weapon visible. No console errors.

Now motion to let self-test run and see enemy view.

Now the enemy sprite renders beautifully in front of the player, standing on the floor, occluded correctly by nothing. Sprites, perspective walls, textures, weapon, HUD all work. All self-tests pass.

Now I need to finalize:
1. Remove the temporary self-test block (and visual freeze hack).
2. Fix resetGame to clear the toast opacity so restart doesn't show stale toast.
3. Also, the title element was overwritten by the test; removing test removes that.

Also make sure mouse optional works — fine.

One more consideration: on restart, should the level be restored to the same layout? The requirement: "Restart to restore the level, player, enemies, and health." "Restore the level" could mean same layout. Currently resetGame reuses the same map and spawnCells (generated once), so yes same level. Good. But restart does not re-randomize. Good.

But note: if the player dies, restart reuses the same map. Fine.

Potential subtle issue: after game over, keys may still be held; restart button click. Fine.

Another: `exitCell` is a cell object; the exit sprite drawn in that cell. Player must walk into it. Good.

Also: enemies spawn at cells but the sprite is placed at cell center; collision for movement fine.

One more: the toast not cleared on restart. Fix: in resetGame set `toastEl.style.opacity='0';` and also reset flashEl background.

Also, the initial `map` is generated on first resetGame; subsequent restarts keep same map. But if user wants a new maze each restart? Not required; "restore the level" favors same. Keep.

Let me also double check that `drawWeapon` doesn't hide the enemy too much; fine.

Now remove the temp block. Let me read lines around 880-920 to cut precisely.

I'll edit to remove from the comment `/* ---- TEMPORARY SELF-TEST ...` through the closing `}, 400);`. Let me view.

Let me find the start of the temp block. It begins with `/* ---- TEMPORARY SELF-TEST ...`. Let me view a bit above 800.

I'll remove the entire temp block from the comment line through the `}, 400);` line. I'll use sed via bash to delete lines, then verify. The comment starts at line 812 (`/* ---- TEMPORARY SELF-TEST`). Let me confirm line numbers: read shows line 795 is the comment start of Loop. The temp comment is line 812. The `}, 400);` is around line 921. Let me use a script to delete from the marker line to the first `  }, 400);` inclusive. Use awk/perl.

Actually easier: use edit with oldText being the whole block? Too long. Use a Python/perl one-liner to delete between markers.

Let me do: perl -i -0pe 's{  /\* ---- TEMPORARY SELF-TEST.*?\n  \}, 400\);\n}{}s' file. Non-greedy across. Then verify grep.

Also fix resetGame toast and flash. Let me view resetGame lines.

Temp block removed. Now check the file tail to ensure syntax intact.

Now let me reload and verify the clean final version: initial view, no console errors, HUD, controls. And do a quick functional sanity: since browser key events don't hold, I'll rely on the already-passed logic tests. But let me at least verify restart via clicking the Restart button after forcing a game over? Hard without keys.

I can still visually check the start view and console. Let me reload and screenshot + inspect.

Also verify that on restart the toast clears — but I removed the test that produced toast. I could simulate: click restart button via browser click (it's hidden unless overlay shown). Actually the button is inside #overlay which is display:none, so not clickable. Fine.

Let me reload and inspect.

The final version renders cleanly: HUD title restored, HEALTH 100, ENEMIES LEFT 4, EXIT LOCKED, controls shown, textured walls with three variants (red brick, gray stone, green panels), perspective, ceiling/floor, weapon. No console errors.

Now let me do a final quick check on a potential issue: the shooting/enemy attack balance and whether the exit is reachable. Logic tests passed. 

One remaining thing: the requirement "Reaching it shows a win state." Tested. "Restart to restore the level, player, enemies, and health." Tested via resetGame within tests; also the R key and button call it. Good.

Potential issue: After win/dead, the overlay button works. The overlay is displayed. Good.

One more: mouse pointer lock optional; clicking canvas locks pointer; Escape unlocks. Fine. But clicking canvas to shoot? Space required. Good. However, clicking the canvas for pointer lock could conflict with nothing.

I think we're done. Let me do a final grep to ensure no leftover debug/temporary code and that index.html is the only deliverable.

Let me also quickly verify no external references (http, src=, link rel).

Everything is clean. Let me do one final verification of the keydown fallback and that a simple key event works. Actually I already tested with the self-test calling update directly, not actual key events. The browser key events may or may not map to e.code. I added e.key fallback. Let me test: send a key action and then check motion to see if turning occurred. Earlier the key events didn't hold. But a single keydown+keyup might still register if the event arrives. Let me try pressing ArrowRight and then take a screenshot quickly — but keyup immediately means no frame between. So no.

I could test that the event handler receives keys by adding a temporary DOM readout, but I already removed temp code. The e.key fallback covers both. I'm confident.

Actually, let me reconsider whether the tool's key action produces keydown only or keydown+keyup. If it produces keydown only, the key would stay held and subsequent motion would show turning. Earlier motion after KeyW showed no movement across 4 frames — but that was on a cached old page, and the key was pressed before motion. If keydown persisted, we'd see movement in frame 2-4. We didn't. Hmm, but maybe the tool releases. Or the old page didn't have the e.key fallback and the event used key="w" with code undefined → our old handler `keys[e.code]` = keys[undefined], no movement. That's likely! The old page lacked fallback. Now with fallback, key="w" would map to 'KeyW'. So let me test the real key input now: press KeyW then motion and see if the view moves.

Let me do that as a final end-to-end input test.

The frames are identical, meaning the key event still isn't held across frames (tool likely sends keydown+keyup immediately, or key without code). This is a limitation of the test tool, not the app. The app's e.key fallback is in place, and the self-test verified movement logic by driving `update` directly. Real keyboard use in an actual browser will work because keydown holds `keys[code]=true` until keyup.

I've verified enough. Let me finalize and report.

One thing to double-check: the frames all identical means no movement during motion, but that's expected if keyup fires immediately. Not a code bug.

Let me make sure the final file is saved (it is). Done.

Let me write the report.