Wolfenstein raycaster · mimo-v2.6-flash

Let me build this. I'll start by writing the file, then test it in the browser.

Let me design the raycaster carefully.

Key components:
- Map grid, e.g. 16x16 with walls, exit tile.
- Player: x, y, angle, health.
- Raycasting with DDA, textured walls (procedural textures generated on offscreen canvases).
- Sprites: enemies with procedural texture (drawn to offscreen canvas), rendered with z-buffer per column, occluded.
- Shooting: hitscan along center ray, check z-buffer / wall distance, check enemy hit via angular check and distance; can't damage through wall — check wall distance first.
- Enemies: AI — idle until player in line of sight and within range, then approach and attack when close (attack rule: within 0.9 units, attack every 0.8s dealing damage).
- HUD: health, enemies remaining, controls display.
- Game over / win overlay with Restart.

Let's write it.

Rendering: canvas internal resolution, e.g. 320x200 scaled up with image-rendering pixelated, or render at 480x300. Use a back buffer ImageData for walls for speed, then draw sprites on top via drawImage of offscreen canvas with per-column clipping... Actually sprite occlusion with z-buffer: easiest is to draw sprites column by column using drawImage with source rect per column, skipping columns where sprite distance > zbuffer. That works.

Alternative: render everything into ImageData pixel buffer including sprites (sampling sprite canvas pixels). That's cleaner for occlusion. Sprite canvases 64x64 with alpha. Sampling: for each column of sprite, compute tex x, then for each row compute tex y, get pixel, if alpha>0 write to buffer. Need to read sprite image data once (cached ImageData).

Floor/ceiling: simple gradient fills (fast) — do it per-row on ImageData? Could just fill ceiling and floor with solid/gradient colors using fillRect before putting ImageData... but ImageData covers whole canvas. Instead: draw walls into ImageData, putImageData, then draw floor/ceiling? Order matters. Simpler: fill ceiling and floor in the ImageData with per-row shading (cheap-ish loops over 320x200 = 64000 pixels, two loops for rows above/below horizon with gradient). That's fine.

Actually full-screen per-pixel loop: 64000 pixels * operations. Fine at 60fps in JS.

Let me set resolution 400x250 maybe. Ray per column = 400 rays. Fine.

Let me write DDA raycasting standard.

Map: 16x16 grid. Let me design a map with an exit.

Let me use a map like:

```
1111111111111111
1000000000000001
1011110111111101
1010000100000101
1010111101100101
1010000001100101
1011110111000101
1000010100000101
1111010101111101
1000010101000001
1011110101011101
1010000001010001
1010111111010101
1000000000000101  ... 
```

Hmm, let me just carefully make a map with digits: 1 = wall A, 2 = wall B (different texture), 3 = exit tile? Exit should be a tile the player walks onto. Let's make exit a floor tile marked 'E' — reachable, and locked until all enemies dead (visually shown as barrier? Or just reaching it while locked shows message). Requirement: "Defeating all enemies unlocks the exit; reaching it shows a win state." So reaching locked exit → show "Exit locked" message; after all dead → win.

I'll make exit tile rendered as a floor decal (glowing portal drawn on floor) — simpler: draw a distinct floor texture color on exit tile, plus a glowing sprite marker at exit position. The exit tile is floor (0) so reachable.

Let me design a 16x16 map manually ensuring connectivity. I'll write it as strings and validate with BFS mentally... better: I'll add a quick connectivity check in code? Could just test in browser. Let me carefully craft.

Map (row 0 at top, x = col):

```
"1111111111111111",
"1000000000000001",
"1011110111110101",
"1010000100000101",
"1010111101100101",
"1010000001100101",
"1011110111000101",
"1000010100000101",
"1111010101111101",
"1000010101000001",
"1011110101011101",
"1010000001010001",
"1010111111010101",
"1010000000000101",
"1011111111100101",  
"1111111111111111",
```

Hmm this is a maze; I need to verify connectivity to place enemies and exit. Rather than hand-verify, I'll generate... no, requirement says "small level". I could hand-place and then verify with BFS in a node script quickly using bash. Good plan: write the map, run a node BFS check to confirm all floor cells connected, adjust if needed.

Actually node available? Let's check. I'll run a quick node script.

Player start: (1.5, 1.5) facing east? Let's pick start and exit at opposite corners.

Let me just do BFS verification via node.

Enemy design: sprite drawn procedurally — a demon-like figure: red body, eyes. 64x64 canvas, draw with shapes.

Weapon: shotgun drawn at bottom center, procedural, with muzzle flash on shoot. Recoil animation.

Shooting logic: on space, if cooldown ready: flash, then hitscan:
- Cast ray from player along view direction (camera plane center). Compute wall hit distance via DDA.
- For each enemy: project onto view: compute dx,dy; dist; angle diff relative to player angle; if |angleDiff| < atan(hitRadius/dist) roughly, and dist < wallDist, and enemy alive → hit nearest such enemy. Damage 34-ish so 3 shots? Or damage 50 → 2 hits. Let's give enemy HP 100 and shotgun damage 60 → 2 shots, feels good. Actually maybe one shot kills at close range... keep simple: damage 55, hp 100 → 2 hits.

Also add a slight aim: use angular threshold based on enemy radius (0.3) => maxAngle = atan2(0.35, dist). Player can strafe/turn to aim. Fine.

Enemy AI:
- States: idle, chase, attack.
- If distance to player < detection range (8) and line of sight clear → chase (move toward player with simple wall collision, sliding).
- If distance < 1.2 → attack: every 1s deal 12 damage, with a lunge animation (scale flash).
- Enemies can't pass through walls.

Line of sight: sample ray with DDA or step sampling — use simple stepping (0.1 increments) checking wall cells.

Damage feedback: red vignette flash.

HUD: HTML overlay with health bar, enemies count, controls text, messages, restart button in overlays.

Restart: reset everything.

Let's also handle minimap? Optional, small minimap could be nice but not required. I'll add a small minimap in corner — helps verify. Keep it simple.

Mouse turning optional — skip mouse (or add pointer lock optional). Skip to keep it robust; keyboard only.

Let's write the code.

Rendering details:

```js
const W=400,H=250; // internal
canvas.width=W; canvas.height=H;
ctx.imageSmoothingEnabled=false;
```
CSS scales canvas to fit viewport width, image-rendering: pixelated.

Raycasting:
```
dirX=cos(a), dirY=sin(a)
planeX=-dirY*planeLen, planeY=dirX*planeLen  (planeLen ~0.66 for 66° FOV)
for x in 0..W:
  cameraX = 2*x/W - 1
  rayDirX = dirX + planeX*cameraX
  ...
DDA
perpWallDist
lineHeight = H / perpWallDist
drawStart = -lineHeight/2 + H/2 + pitch (pitch 0)
wallX = exact hit coordinate
texX = ...
```

Textures: 64x64 canvases with ImageData; store as Uint32Array for fast access (use Uint8ClampedArray and index). I'll create textures as {w,h,data} from canvas getImageData.

For ceiling/floor: per-row color shading. Ceiling: dark gray-blue gradient darker at horizon? Typically ceiling darker near horizon... whatever. I'll do: ceiling color varies with row distance, floor with row distance (perspective). Compute rowDist for floor rows: rowDist = (H/2) / (y - H/2) * something... Standard: for y > H/2, rowDistance = (0.5*H) / (y - H/2). Then shade factor = clamp(1/ (1+rowDistance*0.15)). Colors: floor brick-ish brown, ceiling dark. Add slight checker pattern using player-space? That requires pos pos calculations with camera dir — doable: floor casting. Floor casting per pixel with rowDist and rayDir0/rayDir1 interpolation is standard and cheap enough. Let's do proper floor casting for a nicer look — adds authenticity. It's a known loop:

```
for y in H/2+1..H:
  p = y - H/2
  posZ = 0.5*H
  rowDistance = posZ / p
  floorStepX = rowDistance * (rayDir1X - rayDir0X) / W
  floorX = posX + rowDistance * rayDir0X
  for x...
    cellX = floor(floorX); tx = ((floorX - cellX)*64)&63
    ...
    floorX += floorStepX
```
rayDir0 = dir - plane, rayDir1 = dir + plane.

Ceiling: mirror row (y' = H-1-y) with ceiling texture. Exit tile floor: if cell is exit cell, use exit texture (glowing). Nice.

Then walls drawn over. Then sprites. Then weapon. Weapon drawn with ctx after putImageData.

Order:
1. Fill ImageData: floor+ceiling cast, walls via DDA, storing zbuffer.
2. putImageData.
3. Sprites: iterate sprites sorted far→near, draw columns sampling sprite ImageData into... but putImageData already done. Need sprites in buffer too. Option: draw sprites into same ImageData before putImageData. Yes — do that: after walls, write sprite pixels into buffer with zbuffer check. Then putImageData. Then weapon + effects with ctx.

But sprites with transparency writing to buffer: need alpha blend? Sprites are opaque where drawn (alpha 255) with transparent elsewhere, so just write RGB. Add distance shading to sprites too.

Then damage flash & muzzle flash via ctx fillRect with alpha.

Weapon: draw shotgun procedurally each frame with ctx (scaled by canvas res). Keep it simple: barrel rectangles + hands, recoil offset, flash when shooting.

Now sprites list: enemies + exit portal marker. Exit marker: a glowing orb sprite that's always visible when... it should be occluded by walls too (that's fine and correct). Show locked (red/dim) vs unlocked (green bright).

Enemy sprite animation: 2 frames? Keep one texture + bobbing scale, plus attack flash (draw red overlay?). Simpler: two textures (idle, attack) — I'll draw attack frame with mouth open / claws. Or tint by drawing a second canvas. I'll make 3 frames: walk1, walk2, attack. Might be overkill but fine — procedural drawing with parameter.

Let me make enemy sprite function drawEnemy(frame) where frame in {0,1,2}: 0 idle/walkA, 1 walkB, 2 attack.

Sprite rendering math (standard):
```
spriteX = ex - posX; spriteY = ey - posY;
invDet = 1/(planeX*dirY - dirX*planeY)
transformX = invDet * (dirY*spriteX - dirX*spriteY)
transformY = invDet * (-planeY*spriteX + planeX*spriteY)  // depth
if transformY <= 0 skip
spriteScreenX = (W/2)*(1 + transformX/transformY)
spriteHeight = abs(H/transformY) * scale
vMove for vertical offset (enemy stands on floor: shift down)
drawStartY = -spriteHeight/2 + H/2 + vMoveScreen
```
For floor-standing: bottom of sprite should align with floor line. Floor at screen y for distance d: yFloor = H/2 + (0.5*H)/d... Actually wall bottom for distance d is H/2 + (H/d)*0.5 (since lineHeight=H/d, half = H/(2d)). So bottom = H/2 + H/(2*transformY). Set sprite bottom there, spriteHeight = H/transformY * scale (scale ~0.8 of wall height). Good.

texX loop with zbuffer check per column.

Now collision: circle vs grid. Player radius 0.25. Move separately in x and y: attempt newX, check cell solid at (newX±r, y±r) — do AABB check: function canMove(x,y,r) checks the 4 corners cells... standard: check cells overlapping the circle bounding box are non-wall.

Enemies same with r=0.3.

Exit: tile at exit position; when player cell == exit cell (or dist < 0.5) and enemies all dead → win. If locked → message.

Now HUD in HTML overlay.

Let me now write the map and verify with node BFS.

Let me draft map 16x16:

Row strings of length 16, using '1','2' walls, '0' floor, 'X' exit maybe.

I'll write it and BFS-check.

Design:

```
r0:  1111111111111111
r1:  1000000000000001
r2:  1011111110111101
r3:  1010000010100101
r4:  1010111010100101
r5:  1010100010100101
r6:  1010101110100101
r7:  1010100000100101
r8:  1010111110100101
r9:  1010000000100101
r10: 1011111111100101
r11: 1000000000000101
r12: 1011111111111101
r13: 1000000000000001
r14: 1000111111111101  -- hmm
r15: 1111111111111111
```

This is getting messy. Easier approach: generate the maze programmatically? Requirement doesn't forbid procedural level gen, but "small level" with reachable exit — a fixed hand-crafted map is safer for testing. I can verify with node BFS and iterate quickly.

Alternative simpler design: mostly open rooms with wall clusters — easy to guarantee connectivity. A "maze" look with pillars and corridors. Let's do a 16x16 with a mix:

```
r0:  1111111111111111
r1:  1000000000000001
r2:  1000111111110001
r3:  1000100000010001
r4:  1010101110010101
r5:  1010001000000101
r6:  1011101011110101
r7:  1000001000010001
r8:  1111101110011101
r9:  1000000000000001
r10: 1011111101111101
r11: 1010000001000001
r12: 1010111111011101
r13: 1000100000010001
r14: 1000000111100001  ... 
```

Too risky by hand. I'll write a node script to generate/validate. Actually simplest: write map candidate in a file, run BFS script, iterate until connected. Let's do that.

Or: do it programmatically in the page but deterministic fixed seed... no, just verify with node.

Plan:
1. Write a small node script mapcheck.js with candidate map, BFS from start, check exit reachable and count reachable cells; also print unreachable floor cells.
2. Iterate.
3. Then embed final map in index.html.

Let's go. Time budget 15 min — be efficient.

Actually, I can also make the map generator be a simple randomized Prim maze in JS at load with fixed seed — guaranteed connected, and then carve some rooms. But "Restart to restore the level" — regenerating with same seed is fine. Still, a static map is more predictable for testing "nearby wall collision". I'll go static + node BFS check.

Let me write index.html now with a placeholder map, then verify with node by extracting? Simpler: design map in a separate check script first.

Let me do the BFS check first quickly.

Map candidate (16 rows × 16 cols). I'll write rows carefully counting characters.

Row template: 16 chars.

```
1111111111111111  (16)
1000000000000001
1011101111011101
1010000001000101
1010111101010101
1010000101010101
1011100100010101
1000001110110101
1111000000000101
1001011111110101
1001010000010001
1011010110011101
1000000100000001
1011111101111101
1000000000000001
1111111111111111
```

Start (1,1) → col1,row1. Exit at (14,14) row14 col14.

I'll verify with node.

Let me write the checker.

Also enemies placed at reachable open cells.

OK, write files.

Enemy placement: pick 4 open cells far from start: e.g. (14,1)? etc. BFS-verify distances maybe. I'll just place and check in browser.

Now write index.html. It's long; let's compose carefully.

Key code sections:

```html
<!DOCTYPE html><html><head><meta charset=utf-8><title>...</title>
<style>...</style></head>
<body>
<div id="wrap">
  <canvas id="game" width="400" height="250"></canvas>
  <div id="hud">... bars, counters ...</div>
  <div id="controls">W/S move ...</div>
  <div id="msg"></div>
  <div id="overlay"><h1>...</h1><button id="restart">Restart</button></div>
</div>
<script>...</script>
</body></html>
```

HUD overlay on top of canvas, pointer-events none except button.

Let me write the JS.

```js
const W=400,H=250;
const MAP=[...strings];
const mapW=16,mapH=16;
function tileAt(x,y){ if(x<0||y<0||x>=mapW||y>=mapH) return 1; const c=MAP[y][x]; return c==='0'?0:(c==='X'?0:1); }
```
Exit tile 'X' is floor. Walls '1','2'.

Solid check: cell>0 where cell computed from char: '1'→1, '2'→2, '0'/'X'→0.

Textures: genTextures() creates:
- texBrick (walls type 1): stones with mortar lines, gray-blue.
- texStone2 (type 2): darker red brick.
- texFloor: cobblestone brown.
- texCeil: dark concrete.
- texExit: glowing green/purple portal floor.

Generate with canvas 2D ops then getImageData.

Draw textures deterministically-ish with Math.random — fine.

Wall shading: multiply by light factor = clamp(1.2 - dist*0.08) and side (y-side darker).

Buffer: use Uint32Array view over ImageData.data.buffer for fast writes (little-endian ABGR). packed = 0xff000000 | (b<<16) | (g<<8) | r.

Let's write helper: shade(r,g,b,f) → pack.

Main render():

```js
function render(){
  const buf = frameBuf; // Uint32Array
  // ceiling/floor cast
  ...
  // walls DDA per column, write zbuf
  // sprites
  // imageData.data.set? 
}
```
Since buf is Uint32Array over imageData.data.buffer, writes go directly. Then ctx.putImageData(imageData,0,0).

Floor casting full res 400x250: rows 125..250 → ~31k pixels ceiling+31k floor = 62k iterations with texture sampling. Should be OK (~a few ms). Plus 400 rays. Fine.

Actually to be safe on perf, I could do floor casting at half resolution? No — keep full, modern JS handles 60k pixel loops easily (sub-ms to 2ms).

Sprite pixel writing: need enemy textures' ImageData cached.

Let me define sprite objects: {x,y,tex(imgData),vOffset,alive,...}.

Enemies array: {x,y,hp,state,attackCd,frame,flash,speed}.

Enemy movement: if los and dist<9 → move toward player (dir normalized, with collision). If dist<=1.3 → stop and attack (cd 1s, damage 10). Attack state shown for 0.35s.

Player health 100. Damage flash: red overlay alpha.

Shooting: cooldown 0.45s. Muzzle flash timer 0.08s. Weapon bob.

Recoil: weaponY offset.

Hit detection: on shoot:
```
const wallD = castRayDistance(dirX,dirY);
let best=null;
for e of enemies alive:
  const dx=e.x-px, dy=e.y-py; const d=Math.hypot(dx,dy);
  if(d>wallD-0.2) continue; // behind wall
  const diff = angleDiff(atan2(dy,dx), playerAngle);
  if(Math.abs(diff) < Math.atan2(0.45,d)) { if(!best||d<best.d) best={e,d}; }
}
if(best){ best.e.hp-=55; best.e.hitFlash=0.2; best.e.aggro=true; if(hp<=0) kill }
```
Also pellet spread: could check multiple angles; keep single central ray with generous cone.

Feedback: crosshair flash, hitmarker, blood particles? Simple: hit flash on enemy + "HIT" msg maybe. Add small screen shake? Keep: hitmarker X flashes.

Game states: 'playing','dead','win'.

Restart resets: player pos/angle/health, enemies, timers, messages.

Minimap: draw in top-left with ctx after putImageData: cells 4px each → 64px. Show walls, player dot, enemies, exit. Nice for verification. It's fine.

Controls display: bottom-left panel.

Now weapon drawing: draw a shotgun from player view:
- Stock/barrel: dark gray rectangles centered bottom.
- Two hands: skin color blocks.
- Muzzle flash: yellow polygon when flash active.

Let's code drawWeapon():
```
const t=now;
const bob = moving? Math.sin(t*8)*4 : Math.sin(t*2)*1.5;
const recoil = shootTimer>0 ? Math.sin(shootTimer/0.15*Math.PI)*10 : 0; hmm simpler: recoil = shootTimer>0? 12*(shootTimer/0.12):0
const cx=W/2, baseY=H+recoil... 
```
Draw barrel: two long rectangles angled slightly (perspective) — draw a simple pump shotgun:
- barrel: rect from (cx-8, H-60+bob) to (cx+8, H-20) dark gray with highlight.
- receiver below.
- hands: brownish rounded rects at sides.

Muzzle flash: when flashT>0, draw yellow/orange radial star at top of barrel.

Good enough.

Crosshair: small cross at center, flashes on shoot/hit.

Now let's write everything. I'll be careful with syntax.

Also handle window blur → clear keys.

Key handling: keydown/keyup with e.code: KeyW,KeyA,KeyS,KeyD,ArrowLeft,ArrowRight,Space. preventDefault for arrows/space.

Movement: 
```
speed=3.0 units/s, rotSpeed=2.4 rad/s
if forward: move along dir; strafe along plane.
collision: try x then y separately with radius 0.28.
```

Also enemy collision with player: enemies stop at dist 1.0.

Let me write the file now.

For textures generation, code:

```js
function makeTex(size, draw){
  const c=document.createElement('canvas'); c.width=c.height=size;
  const g=c.getContext('2d'); draw(g,size);
  const d=g.getImageData(0,0,size,size);
  return {w:size,h:size,data:new Uint32Array(d.data.buffer.slice(0))};
}
```
Note: Uint32Array over a copied buffer to keep it independent.

Wall texture sampling returns uint32 packed (ABGR little endian: 0xAABBGGRR). I'll compute packed at creation time? data is RGBA bytes; reading as Uint32 gives 0xAABBGGRR on little-endian. Then shading needs to split channels:
```
const p=tex.data[off];
let r=p&255, g=(p>>8)&255, b=(p>>16)&255;
apply factor → out = 0xff000000 | (b<<16)|(g<<8)|r;
```
Fine.

For sprites: need alpha; when sampling check (p>>>24)>128.

Endianness assumption: browsers are little-endian essentially always. Acceptable.

Now floor casting writing per pixel: also packed shade.

Write render:

```js
function render(){
  const dirX=Math.cos(player.ang), dirY=Math.sin(player.ang);
  const planeLen=0.7;
  const planeX=-dirY*planeLen, planeY=dirX*planeLen;
  // FLOOR & CEILING
  const halfH=H>>1;
  for(let y=halfH+1;y<H;y++){
    const p=y-halfH;
    const rowDist=(0.5*H)/p;
    const stepX=rowDist*( (dirX+planeX) - (dirX-planeX) )/W; // = rowDist*2*planeX/W
    let fx=player.x+rowDist*(dirX-planeX);
    let fy=player.y+rowDist*(dirY-planeY);
    const light=Math.min(1, 1.15/(1+rowDist*0.25));
    const rowF=W*y, rowC=W*(H-1-y);
    const isCeilRow = ... // we write both floor(y) and ceiling(H-1-y)
    for(let x=0;x<W;x++){
      const cx=Math.floor(fx), cy=Math.floor(fy);
      const tx=((fx-cx)*64)&63, ty=((fy-cy)*64)&63;
      ... floor tex sample → buf[rowF+x]=shade(...light)
      ... ceil tex sample → buf[rowC+x]=shade(...lightCeil)
      fx+=stepX; fy+=stepY;
    }
  }
```
Careful: writing ceiling row (H-1-y) inside same loop — when y ranges halfH+1..H-1, H-1-y ranges halfH-2..0. Combined covers all rows except y=halfH and y=halfH-1? Let's check: floor rows written: halfH+1..H-1. Ceiling rows written: 0..halfH-2. Rows halfH and halfH-1 unwritten — they'd be garbage (initial 0 = transparent black... actually initial buffer zero → black). Walls usually cover, but at long distances walls are short and those rows near horizon remain. Better to also write row halfH and halfH-1 explicitly: for y=halfH: p=0 → rowDist infinite. Just fill those two rows with a horizon color (dark). Or set rowDist clamp. Simplest: pre-fill buffer with a horizon color? Just do: buf[halfH*W+x]=ceilingColorDark; buf[(halfH-1)*W+x]=floorColorDark... Actually the two rows nearest horizon: ceiling side row halfH-1 and floor side row halfH. So set row halfH = floor far color (dark), row halfH-1 = ceiling dark. I'll fill them after loop.

Actually cleaner: iterate y from halfH+1..H-1 and write floor at y and ceiling at (H-1-y)... that leaves exactly halfH and halfH-1 unwritten, yes. Fill them with dark gray/blue.

Exit floor texture: if cell is exit cell, use texExit instead of floor. Check inside loop via MAP[cy][cx]==='X'. Also exit cells surrounding glow — just the tile.

Walls DDA: standard.

Sprites: build list each frame: enemies (alive → walk frame; dead → corpse? simpler: remove on death but add a "corpse" sprite? skip, just remove with death animation: shrink over 0.4s then remove), exit portal.

Sort by distance descending.

Exit portal sprite: floating orb at exit cell center; when locked, red with lock icon-ish; when unlocked, green pulsing. Draw procedurally into two textures (locked/unlocked).

Vertical placement: bottom at floor line, height = H/transformY * 0.7, so orb floats: offset upward a bit — vMove negative.

For enemies: height = H/transformY * 0.85 (slightly shorter than wall).

OK now HUD numbers update each frame via DOM (throttle to when changed).

Message system: showMsg(text, dur).

Attack rule clarity: display in controls: "Enemies chase when they see you and strike at close range (every 1s, 10 damage)".

Win: overlay "YOU ESCAPED" + restart. Dead: "GAME OVER".

Restart button in overlay + also R key restart.

Let me write it all now.

Also "Sample the scene for stable wall rendering" — I'll take screenshots and maybe sample pixel colors via canvas getImageData in browser tool? The browser tool has inspect action — maybe returns DOM/console. I can expose a helper: window.__sample = ()=>{...} and call via inspect? The inspect action probably runs JS? Not sure. I'll add a debug hook: on load, sample a few pixels and console.log them; then read console via inspect. That satisfies "sample the scene".

Let me write code now.

I'll write the whole file in one `write` call. Then node-check map separately? I can't run browser JS to check map connectivity before... Actually I can run node with a extracted map. Let me first do the map BFS check with a quick node script, then write index.html with the validated map. That's two steps but cheap.

Let me write mapcheck quickly.

Map candidate — I'll write it and check. Let me go.

Actually — I can also make the map generator be a simple randomized Prim maze in JS at load with fixed seed — guaranteed connected, and then carve some rooms. But "Restart to restore the level" — regenerating with same seed is fine. Still, a static map is more predictable for testing "nearby wall collision". I'll go static + node BFS check.

Let me do BFS first.

The map is fully connected (122/122). Now I need open cells for enemies and exit. Let me pick candidates programmatically: exit at (14,14) (dist 26), enemies at cells with distance > 8 from start, spread out. Let me compute a set of good enemy positions: pick cells with dist ~10-20 and spread apart. Let me run a quick script to suggest 4 positions.

Good picks: enemies at (9,1), (13,1), (3,3), (8,5)... but two enemies at distance 8 might aggro immediately. That's OK — it's fine to have some approach. Actually enemies aggro only if line of sight and dist<8. At (3,3) dist path 8, euclid ~2.8 from start — that's very close, will immediately chase. Maybe fine for action but could be overwhelming. Let's pick enemies further: use pool dist>=10.

Let me just choose: exit (14,14) path 26. Enemies: (13,1) d=12, (12,5) d=15, (14,9) d=21, (1,14) d=19. Four enemies, spread out. Check pairwise euclidean separation: (13,1)-(12,5)=~4.1, (12,5)-(14,9)=~4.5, (14,9)-(1,14)=~13.9, (13,1)-(14,9)=8. Good. Also (1,14)-(14,9) fine. (12,5)-(1,14) far. Good spread.

Check LOS from start (1,1): (13,1) is along row 1 — row1 is all open from x=1..14! So enemy at (13,1) has direct LOS with player at distance 12 > 8 detection, so won't aggro initially. Good.

Now, also confirm those cells are open: 13,1 open (row1 all open), 12,5 open, 14,9 open, 1,14 open. All from earlier check (14,1 open, 14,9 open reach true; 12,11 was wall). Let me verify 12,5 and 1,14: row5 = "1010000101010101": index12 → row5 chars: 1 0 1 0 0 0 0 1 0 1 0 1 0 1 0 1 → index12='0' open ✓. Row14 = "1000000000000001" index1='0' ✓. Row9="1001011111110101": index14='0'? chars: 1,0,0,1,0,1,1,1,1,1,1,1,0,1,0,1 → index14='0' ✓.

Start (1,1), facing... let's face east (angle 0) down the long corridor row1. Nearby wall: player can move forward along row 1 to x=14. For "collision against a nearby wall" test — strafing up (north) hits wall row0. Good: from (1.5,1.5) move up → wall at y=0. Also turning left/right.

Actually start facing south maybe more interesting (see more maze). Facing east along the long corridor shows depth nicely. I'll start facing east (angle 0).

Hmm, for a nicer initial view, maybe start at (1.5,1.5) facing south (angle π/2): row2 col1: row2="1011101111011101" index1='0' open, so there's a corridor south. Fine — facing south you'd see walls closer. East corridor gives a long perspective view — visually good for "stable wall rendering" sampling. I'll face east.

Now write index.html.

Let me write the code carefully.

Detailed code:

```js
const W=400,H=250;
const MAP=[...];
const START={x:1.5,y:1.5,ang:0};
const EXIT={x:14.5,y:14.5};
const ENEMY_SPAWNS=[[13.5,1.5],[12.5,5.5],[14.5,9.5],[1.5,14.5]];
```

Textures:

makeTex brick (gray stone):
```js
function texBrick(g,s){
  g.fillStyle='#4a4a55'; g.fillRect(0,0,s,s);
  // stones
  const rows=4, cols=4;
  for(let r=0;r<rows;r++){
    const off=(r%2)*(s/cols/2);
    for(let c=-1;c<cols;c++){
      const x=c*(s/cols)+off, y=r*(s/rows);
      const w=s/cols-2, h=s/rows-2;
      const v=60+Math.random()*35;
      g.fillStyle=`rgb(${v},${v-4},${v+8})`;
      g.fillRect(x+1,y+1,w,h);
      g.fillStyle='rgba(255,255,255,0.08)'; g.fillRect(x+1,y+1,w,1);
      g.fillStyle='rgba(0,0,0,0.35)'; g.fillRect(x+1,y+1+h-1,w,1);
      // noise specks
      for(let i=0;i<10;i++){ g.fillStyle=`rgba(0,0,0,${Math.random()*0.25})`; g.fillRect(x+1+Math.random()*w, y+1+Math.random()*h,1,1);}
    }
  }
}
```
Careful with x negative: c starts -1 → x negative, fillRect clipped fine.

texRedBrick for type 2: similar with reddish tones.

texFloor: dark cobble: base #3a3128 with random stones.

texCeil: dark #1a1c22 with noise.

texExitFloor: dark with glowing green grid.

texWall variants: map chars '1' → brick gray, '2' → red brick. Let me sprinkle '2' in the map for variety: replace some wall cells with '2' — must keep connectivity (walls don't affect floor connectivity as long as not blocking... changing a wall to another wall char keeps same layout, safe). I'll assign type 2 to some wall cells, e.g. based on pattern: any wall cell where (x+y)%3===0 → '2'. Do it at runtime instead of editing strings: wallType(x,y) = ((x*7+y*13)%4===0)?2:1. Nice, keeps map strings simple.

Sprites:

drawEnemy(g,s,pose):
- Body: demon, dark red/maroon with horns, yellow eyes, claws.
- pose 0: arms down; pose 1: arms raised (walk); pose 2: attack (mouth open wide, arms up high).

Let's draw:
```
g.clearRect
// shadow handled separately? skip
// legs
// torso ellipse
// head with horns
// eyes glowing yellow
// arms/claws
```
Use simple shapes.

drawOrb(g,s,color): glowing circle with gradient... gradient allowed (canvas API, not network).

Enemy textures: 64x64.

Rendering sprite function: takes imageData-derived Uint32Array with alpha.

Now let's think about the death animation: when hp<=0, set e.dying=0.45; while dying, scale shrinks and we draw a "corpse" — simpler: keep drawing same sprite with vertical scale shrinking (vShift down) and fading? Alpha blending with buffer needed for fade; simpler: shrink to zero and remove. I'll implement: during dying, spriteHeight *= (dying/0.45) and bottom stays at floor → looks like sinking. Also tint darker. Good enough.

Now shoot: also make a "shot pellet" check with slight spread: check angle offsets [-0.05,0,0.05]? Might make it too easy. Keep central ray with cone based on enemy radius.

Wall distance for shot: cast ray straight, get distance.

Damage rule: shotgun damage 55, enemy hp 100 → 2 shots. Player health 100, enemy melee 10 dmg per hit with 1s cooldown, only when within 1.4 units and LOS.

Enemy count HUD: "ENEMIES 4/4".

Exit locked: message "EXIT LOCKED — eliminate all enemies" when stepping on exit while enemies remain, with cooldown to avoid spam.

HUD layout: top-left: HEALTH bar + number; top-right: ENEMIES remaining; bottom-left: controls; bottom-right maybe minimap? Minimap top-left under health? Let's do minimap at bottom-right (small, 16x16 cells * 4px = 64px + padding).

Crosshair center.

Overlays: start overlay? Requirement doesn't say, but showing controls is required. I'll show controls always in a panel; plus a start screen "CLICK/press any key to start"? Adds complexity for testing — but a start overlay requires an extra click in testing; that's fine and normal. Hmm, simpler: game starts immediately (enemies far), controls displayed. I'll start immediately to reduce friction. Add pause on window blur (keys cleared) but not game pause... Actually enemies chasing while testing could kill player. That's OK.

I'll start immediately.

Restart: button always visible? Put "Restart" button top-right corner as small button plus in overlays. Requirement: "Provide Restart to restore the level, player, enemies, and health." A always-available Restart button + R key. Good for testing.

Now writing the render loop with delta time clamp.

Console debug hook: after first frame, console.log sample pixels:
```js
setTimeout(()=>{ const d=ctx.getImageData(...).data; sample at few points; console.log('SAMPLE', ...) },200)
```
Also expose window.__state() for inspection: returns {px,py,ang,hp,enemies,fps,lastShot}.

The browser tool's inspect action likely returns DOM/console output. Let's write.

Perf: ImageData buffer as Uint32Array: 
```js
const img=ctx.createImageData(W,H);
const buf=new Uint32Array(img.data.buffer);
```

Wall rendering loop writes buf[y*W+x].

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

Sprite drawing into buf:

```js
function drawSprite(sp, dirX,dirY,planeX,planeY){
  const sx=sp.x-player.x, sy=sp.y-player.y;
  const invDet=1/(planeX*dirY - dirX*planeY);
  const tX=invDet*(dirY*sx - dirX*sy);
  const tY=invDet*(-planeY*sx + planeX*sy);
  if(tY<0.15) return;
  const screenX=Math.round((W/2)*(1+tX/tY));
  const floorY=H/2 + (H/(2*tY));   // wall bottom line
  const h=Math.abs(H/tY)*sp.scale;  // sprite height
  const w=h; // square textures
  const bottom=floorY - sp.lift*(H/tY); // lift in wall-units
  const top=bottom-h;
  ...
  const startX=Math.max(0,Math.floor(screenX-w/2));
  const endX=Math.min(W-1,Math.ceil(screenX+w/2));
  for(x..){
    if(tY>=zbuf[x]) continue;
    const texX=Math.floor(((x-(screenX-w/2))/w)*sp.tex.w);
    ...
    for(y=startY..endY){
      const texY=Math.floor(((y-top)/h)*sp.tex.h);
      const p=tex.data[texY*tex.w+texX];
      if((p>>>24)<128) continue;
      // shade by light + flash
      buf[y*W+x]=shadePacked(p, light, sp.tintR..)
    }
  }
}
```

Hit flash: multiply color toward white/red: if sp.flash>0 blend toward white.

Enemy death sink: sp.scale shrinks — but shrinking both w and h around bottom keeps feet on floor. Since bottom is fixed and top=bottom-h, shrinking h shrinks upward from floor... no: top=bottom-h, so shrinking h lowers top → sprite shrinks toward bottom (feet). That's a sink. 

Enemy bobbing: slight vertical bob using time → adjust lift by sin.

Exit orb: lift so it floats: lift 0.25 (in wall units, meaning it's raised above floor line by lift*(H/tY) pixels).

Now zbuf per column from wall casting.

Let's also handle when sprite is behind wall but partially... per-column zbuf handles it.

Weapon drawn with ctx after putImageData.

Let me now write out the code fully.

Also screen effects: damage flash (red overlay alpha = dmgFlash), muzzle flash (brighten whole screen slightly), low health vignette (dark red edges) — draw with ctx radial? simple: fillStyle rgba red with alpha.

Game over/win overlay: HTML div with class hidden toggled.

Message element: HTML.

FPS: compute simple.

Now the code. Writing it.

One more: mouse turning optional → skip entirely but mention keyboard only. Controls display includes: W/S move, A/D strafe, ←/→ turn, SPACE shoot, R restart.

Let me write.

```js
// ---------- state ----------
const state={mode:'playing',msg:'',msgT:0};
const player={x:1.5,y:1.5,ang:0,hp:100,maxHp:100,cool:0,recoil:0,flash:0,bob:0,moveT:0};
let enemies=[];
function resetGame(){...}
```

Enemy AI update(dt):
```js
for(e of enemies){
  if(e.dying>0){e.dying-=dt; if(e.dying<=0) e.remove=true; continue;}
  e.flash=Math.max(0,e.flash-dt);
  const dx=player.x-e.x, dy=player.y-e.y, d=Math.hypot(dx,dy);
  const los = d<12 && lineOfSight(e.x,e.y,player.x,player.y);
  if(e.hp<=0){e.dying=0.4; continue;}
  if(los && d<9) e.aggro=true;
  if(!e.aggro){ e.frame=(e.frame+dt*2)%2? ... idle wander slight; continue;}
  if(d>1.15){
    const sp=e.speed*dt;
    const nx=dx/d, ny=dy/d;
    moveEntity(e, nx*sp, ny*sp, 0.3);
    e.moving=true;
  } else { e.moving=false;
    e.atkCd-=dt;
    if(e.atkCd<=0){ e.atkCd=1.0; e.pose=2; e.poseT=0.35; player.hp-=10; dmgFlash=0.5; shake... }
  }
}
```
Attack applies damage at the moment of the swing; pose shows attack anim.

Enemy movement may get stuck on walls; add simple sliding (try x, then y separately) — moveEntity does axis-separated movement so they slide along walls. Pathfinding around corners: none → enemies may get stuck behind walls, but aggro only when LOS, so when they lose LOS they still chase last-known direction and slide along walls — acceptable. To reduce stuckness, if blocked in both axes, try perpendicular offset. Keep simple: axis-separated sliding.

lineOfSight: step along the segment in small increments (0.1) and check solid.

Now HUD update function writes textContent.

Restart button click → resetGame().

Also 'KeyR' → resetGame.

Sample debug: 
```js
function sampleScene(){
  const pts=[[100,60],[200,125],[300,200],[200,40],[50,180]];
  const d=ctx.getImageData(0,0,W,H).data;
  const out=pts.map(([x,y])=>{const i=(y*W+x)*4;return `${x},${y}:#${...}`});
  console.log('SCENE_SAMPLE', out.join(' '), 'state', JSON.stringify(window.__state()));
}
window.__sample=sampleScene;
```
Call it once after ~500ms of first render.

Note: getImageData on a canvas — no taint since all drawing is local. Fine.

Let's write the file now. Long but let's go.

Floor casting detail — including exit tile check:
```js
const c=MAP[cy] && MAP[cy][cx];
const tex = c==='X' ? texExit : texFloor;
```
But exit glow should also brighten neighbors? skip.

Careful with fx/fy negative → Math.floor handles; out-of-bounds MAP check → use texFloor default.

Ceiling: use texCeil.

Let's write shade:
```js
function sh(p,f){ // p packed ABGR
  const r=(p&255)*f, g=((p>>8)&255)*f, b=((p>>16)&255)*f;
  return 0xff000000|((b>255?255:b)<<16)|((g>255?255:g)<<8)|(r>255?255:r);
}
```
Need |0 conversions: use Math.min(255, r)|0.

For speed in floor loop, inline.

Time to write.

Weapon drawing (ctx, after putImageData):

```js
function drawWeapon(){
  const bobX=Math.sin(player.moveT*9)*3*player.moving... 
```
Let's track player.bobT accumulating while moving.

```js
const bx = Math.sin(player.bobT)*5;
const by = Math.abs(Math.cos(player.bobT))*4;
const rec = player.recoil*18; // recoil 0..1 decaying
const cx=W/2+bx, y0=H-by+rec;
// barrel
ctx.fillStyle='#2b2f36'; ctx.fillRect(cx-7, y0-70, 14, 55);
ctx.fillStyle='#3c424b'; ctx.fillRect(cx-7, y0-70, 5, 55); // highlight
ctx.fillStyle='#1a1d22'; ctx.fillRect(cx+4, y0-70, 3, 55);
// receiver
ctx.fillStyle='#4a3b2a'? shotgun: wood stock brown
ctx.fillStyle='#5a4632'; ctx.fillRect(cx-14, y0-28, 28, 22);
ctx.fillStyle='#6b5540'; ...
// pump
// hands
ctx.fillStyle='#c9927a'; ctx.fillRect(cx-24, y0-30, 12, 16); (left hand)
ctx.fillStyle='#c9927a'; ctx.fillRect(cx+12, y0-46, 12, 16);
```
Muzzle flash when player.flash>0: draw star at (cx, y0-72):
```js
const f=player.flash/0.09;
ctx.fillStyle=`rgba(255,230,120,${f})`;
// draw a few triangles
```
Plus ctx.globalCompositeOperation lighter? keep simple.

Crosshair: draw after weapon? Before weapon is fine; crosshair at center always visible.

OK writing now for real.

Also handle canvas scaling: CSS `#game{width:100%;height:auto;image-rendering:pixelated}` in a wrapper with max-width ~1000px.

HUD absolutely positioned over canvas within wrapper.

Let's write the file.

I need to quickly verify in browser. Let me run a quick check: reload, screenshot, check console, test movement, shooting, restart.

One thing I noticed: in the code I left a stray `const 控制 = null;` — that's valid JS actually (unicode identifier), fine but odd. Also START.y line is weird but works. Let's do a fast browser check.

Also potential issue: enemy walk frame logic `e.pose = (Math.floor(...) % 2) + 0; e.poseT = 0.001;` messy but harmless.

Let's test quickly.

The stray `const 控制` apparently isn't in the file? I wrote it in my draft... let me grep. It says false — maybe I didn't include it. Actually I did write `const 控制 = null;` in the write... The check says false. Hmm, maybe encoding. Let's just grep quickly. Anyway JS parses OK.

Now browser check.

There's a syntax error: `const控制 = null;` — apparently the newline was lost (Unicode identifier merged with const). Actually `const控制` — since `控制` is a valid identifier char, `const控制` parses as a single identifier? No — `const控制` would be an identifier `const控制` which is not a keyword, so `const控制 = null` is a reference-assignment to an undeclared variable → ReferenceError at runtime. That's why everything's black — the script died at that line? No, that line is at top-level inside IIFE: `const控制 = null;` → ReferenceError: const控制 is not defined. Yes, whole script aborted.

Fix: delete that line. Also simplify START.y weirdness.

Wait, my edit oldText for the first was `  const控制 = null;\n  const KEYMAP...` but the grep showed `  const控制 = null;`. The edit succeeded, so it matched. Good.

Reload and check.

The game renders: textured walls, floor casting, ceiling, an enemy visible down the corridor, weapon, minimap, HUD. Console clean (the SCENE_SAMPLE log may not have appeared yet at frame 1).

Now verify behaviors quickly:
1. Movement & turning near start.
2. Collision against a nearby wall.
3. Fire → weapon feedback (flash, recoil, hitmarker).
4. Sample scene for stable rendering (call __sample twice and compare).
5. Restart → initial viewpoint + health.

Let me do this via key presses on canvas and inspecting __state. The browser tool has "type" and "key" actions. Let me use key action. Does key dispatch keydown with code? Probably. Let's try: press KeyW by clicking canvas first to ensure focus (window listener — fine regardless).

Plan a single sequence of calls:
- click canvas (focus)
- key W... The `key` action takes `text`. Maybe text like "w". Uncertain semantics. Alternative: use `type` action with text? Safer: use inspect with JS evaluation? inspect likely returns DOM/console without running code.

Hmm. Given uncertainty, I'll try `key` with text "w" and see if state changes. But I can't read __state unless inspect runs JS. The inspect output includes console and dom. I could expose state into the DOM (e.g., document.title) so inspect shows it! Quick: set document.title = JSON of state each frame? That would let me verify via inspect. Let's add: in frame(), `document.title = mode+' hp'+player.hp+' pos'+...`. Cheap and useful. Actually simpler: update a hidden DOM element's text. Let's add title update (inspect shows title? maybe not). DOM output showed text of elements. I'll add a visually-hidden div #dbg whose textContent is the state JSON each ~5 frames. That appears in dom output.

Let's add that, reload, then do tests: send key events via `key` action, then inspect to read #dbg.

Also for shooting feedback I need to see flash — screenshot right after space.

Time is tight (~4 min). Let's be efficient:

Edit: add debug div + title update in frame().

Then: reload, inspect (initial state), press W (hold? key action likely press+release or hold). Movement test: if key action is a single keydown+keyup, with dt clamped, the player moves only ~1 frame worth (0.05 units). Hmm. Might be too small to observe. Better: also test via a scripted "simulate" — but the requirement says test movement. I can dispatch keydown, wait, keyup using separate browser calls: key action maybe supports keydown only? Unknown.

Alternative robust approach: in the debug element, also track cumulative movement distance traveled (player.moved distance). Then even a brief key press shows movement > 0. And collision test: teleport player next to wall? Better: move player to (1.5, 0.9) facing north and press W; position y shouldn't go below ~0.26... Actually wall at y=0, so y min = 0.26.

Simplest collision check: call window.__setPos(1.5,0.4) then dispatch keydown W and see if y decreases below 0.3 — can't with brief press. Instead, my moveEntity already blocks; I can verify by directly computing: set pos near wall and call an exported step function? I have __setPos. I could add __step(dt) that runs update(dt) with keys.f forced true. That's a legit test of movement+collision logic deterministically.

Let me add to debug: __press(name, duration) that sets keys[name]=true and schedules false after duration — then use setTimeout in page: `__press('f',500)` runs 500ms of movement. Then inspect state. That's real movement through the actual update loop. 

I'll add: window.__press = (k,ms)=>{keys[k]=true; setTimeout(()=>keys[k]=false,ms);};
And for shooting, __shoot exists; Space key also works via key action.

So tests:
1. inspect → initial state (pos 1.5,1.5 ang 0 hp100).
2. run __press('f',600) — can't run JS directly... inspect doesn't run JS. Ugh.

Can the browser tool run JS? Only actions listed: reload, inspect, screenshot, motion, click, drag, key, type, scroll. No evaluate.

So I must drive via real input events. `type` sends keydown/keypress/keyup per char presumably — typing "www" would produce w keydowns (KeyW? it sends code based on char, likely code 'KeyW' for 'w'). That gives movement! Typing a long string of "w" chars gives repeated keydown/keyup — each press moves 1 frame (~0.05 units)... Actually between keydown and keyup of the same char, multiple frames may pass (browser dispatches keydown then keyup nearly instantly though). Typically ~1 frame. So movement per char ≈ 0.05.

Hmm, but keys.f stays true only between down and up. If type dispatches down and up synchronously in same task, no frame passes → no movement.

Alternative: my keys stay true if I only send keydown without keyup. Does `key` action send keydown only, or both? Unknown — commonly key press = down+up.

Fallback: trust logic + verify state changes in a limited way. But I want actual verification.

Pragmatic approach: add an auto-test hook inside the page itself — run a self-test at load (or on demand via URL hash) that exercises movement, collision, shooting, sampling, and restart, logging results to console, which inspect shows. E.g. `#selftest` in location.hash triggers tests after 1.5s. That's legitimate: it tests the same update/render code paths, and I can read console output.

But real keyboard input also needs verifying at least once: I can send a Space key via `key` action and then screenshot to see muzzle flash / hitmarker — feedback observable in image.

Given ~4 minutes: do it.

Plan:
1. Edit index.html: add self-test function that runs (only if location.hash === '#test'), performing:
   - movement: press forward logically (keys.f=true; update(0.1)x N) — but update is internal; expose __test internally can call update directly. It's within closure, so define test function inside IIFE and expose via window.__runTests. Then trigger: since I can't call JS... trigger by hash: window.addEventListener('load') check location.hash — but reload action reloads same URL (no hash control).

Hmm, I can't set the URL hash either without evaluate... reload action maybe accepts no URL param.

Alternative trigger: run the self-test automatically on load, but only log concise results, and disable player control interference? Auto-running tests at load is ugly but this is a verification harness. Better: run tests automatically but in a way that doesn't disturb: run them once at t=2.5s, restore player state after, and log results. Then restart game state after tests (resetGame). Console then shows results. Any player-visible flash is fine.

Actually cleaner: make it a hidden verification that runs only once and then calls resetGame() to restore the initial state; log "SELFTEST {...}". The gameplay experience: at 2.5s after load the player may teleport briefly then reset. Since a user won't know, but it's odd. Gate it behind a condition that's true in my test: e.g., navigator.webdriver? Not set probably. Or check document.referrer? Simplest legit gate: run tests only if `location.hash` includes 'test' OR a flag set before load... 

Cheaper alternative: skip the automatic harness; do the state checks via observable means:
- Movement: screenshot after pressing/holding arrow/W — position change visible on minimap (player dot moves) and in the view. That's observable visually! Minimap dot moves → movement verified.
- Turning: view changes → arrow key.
- Collision: position player facing a wall, hold W → player stops; visible as view not passing through wall. Could show via minimap.
- Shooting: space → muzzle flash visible in screenshot, enemy takes damage (KILLS/hp) — visible via "ENEMY DOWN" message or hitmarker.
- Sample scene: call sampleScene via... console logs only happen at fixed time (600ms). I already get SCENE_SAMPLE in console via inspect! It logs once at 600ms. For "stable" rendering, sample twice — I can trigger window.__sample only via evaluate... unavailable. But I could log samples repeatedly every 2s for the first 10s: cheap edit, gives stability evidence.
- Restart: click Restart button (click action works!) → inspect shows hp 100, kills 0, and screenshot shows initial viewpoint.

Keyboard: the `key` action likely holds? Let's just try: key with text "w" then screenshot; check minimap dot moved. If key = down+up quickly, movement ~0 → try multiple times or rely on `type`.

Given time, let me make movement observable without hold: increase per-frame test? No.

Decision: Try `key` action with text "w" and check. Also try `type` "wwww". If neither moves, fall back: add a click-to-move? No.

Actually — mouse turning optional; I could add mouse click = shoot, which also gives an easy shoot test. Space is required and displayed; adding click-to-shoot is a bonus and easy to test via click action. Let's add mousedown → tryShoot.

Time is tight. Steps:
1. Edit: add mousedown shoot; periodic scene samples (first 3 samples at 1s intervals).
2. Reload, inspect (console shows samples).
3. Press key w / arrow keys, screenshot.
4. Press space, screenshot (flash).
5. Click Restart, inspect/screenshot.

Let's go fast. Add minimal edits.

Also, the samples include state JSON. Also I want position in the debug visible. __state logged in sampleScene. Good.

Now reload and test keys.

Now test input. Move forward: hold key w. The `key` action with text. Let's send key "w" and then take screenshot to see minimap/player movement. Also send ArrowRight.

Let me do: key w, then inspect (console should show sample with state after ~3s). Actually samples at 600ms, 1800ms, 3000ms. Each sample logs STATE with position — that gives position over time (without input though).

Sequence: key w (maybe hold?), then quickly inspect to catch sample #2/#3 with changed position if key held.

Let's try key with text "w" first.

Samples are stable (identical pixel values across 3 samples at different times — wall rendering stable, since camera didn't move). Position unchanged (1.5,1.5, ang 0) — the `key` action press didn't produce movement (probably down+up in same frame, or key code mismatch). Note enemy did approach (closer now, aggroed).

I need to verify movement/turning. The key action may not be holding. Let's try pressing key repeatedly via `type` with many chars? Or key action might support holding — unknown.

Let's try `type` with "wwww" — if it generates keydowns with code KeyW and the keyup happens later or the dispatch is async between frames, movement occurs.

Actually a more reliable approach: `key` action might accept text like "w" and dispatch down then up immediately. Then update loop never sees keys.f true (unless a frame runs in between — impossible within same task).

Hmm. But what about `type`: likely per-char input events dispatched sequentially; still same task possibly.

Given constraints, maybe the key action holds the key until the next action? Some harnesses dispatch keydown only. But state showed moving:false at samples taken after the key press — samples ran at 0.54/1.74/2.94s; key press happened at ~3s (after frame 1). Actually the samples appeared in this result, meaning they occurred during/after my key action... The last state time=2.94 and key pressed at ~3s. So samples may have preceded the keypress. Inconclusive!

So: press key again, then immediately inspect to get a fresh sample? Samples stop after 3. Instead I can verify visually: take screenshot after pressing arrow-right to see if view rotated.

Let's press ArrowRight then screenshot.

The ArrowRight key didn't rotate the view (view unchanged). So the harness `key` action likely isn't dispatching keydown to window, or it dispatches to focused element (body) — should still bubble to window. Hmm, or it uses e.key like "ArrowRight"? I listen by e.code which would be "ArrowRight" for that key either way.

Maybe the key event is dispatched but preventDefault... no, that wouldn't stop my handler.

Possibly the `key` action requires text like "arrowright"? Or it types into an input? Uncertain.

Alternative: `type` action sends keydown events for characters — 'w' would have code KeyW. Let's test type with "aaaa" (turn left repeatedly) and screenshot.

Also possibility: my keydown handler is on `window` — events dispatched via dispatchEvent on document would still reach window (they propagate). Should work.

Another possibility: the harness sends KeyboardEvent without proper `code` (only key), so e.code === '' → no match. For 'w' typed, code might be set. Let's test with type.

Time: ~3-4 min left maybe. Priority: verify movement/turning and shooting; fix only essential issues.

Let's try type "dddd" and screenshot to check turning.

Typed characters don't trigger keydown handlers with code (probably dispatched as text input events only, or code='').

I need a reliable way to verify movement/turning. Options:
1. Make input handling also accept `e.key` as fallback: e.key 'w','a','s','d','ArrowLeft','ArrowRight',' '. If the harness dispatches events with only `key`, this fixes it — and it also makes the game more robust (real keyboards always provide both, so no downside).

That's an essential robustness fix worth doing.

Let me update the handlers to map by e.key as well as e.code.

Then retest with type "dddd" and key "ArrowRight"/"w".

Let me rewrite the input section compactly:

```js
function keyName(e){
  const c = e.code || "";
  if (c) return c;
  const k = (e.key||"").toLowerCase();
  if (k==='arrowleft') return 'ArrowLeft';
  if (k==='arrowright') return 'ArrowRight';
  if (k===' ') return 'Space';
  if (k==='w'||k==='a'||k==='s'||k==='d'||k==='r') return 'Key'+k.toUpperCase();
  return '';
}
```
Then use keyName in both handlers.

Wait — but maybe the harness events have code set and the issue is something else: e.g. events dispatched on a different window/document? The screenshot shows no change at all even for ArrowRight which would turn 2.5rad/s over the frame duration... If key action = down+up immediately, no turn happens (update reads between frames). So possibly the code IS being received but the press is instantaneous → no movement.

To handle instantaneous press: my handler for Space calls tryShoot() directly on keydown (so shooting works even for instant press — good). For movement/turning, instant presses do nothing.

Fix: handle movement on keydown too — e.g., on keydown, apply a small immediate impulse (turn a bit / step a bit). Better: keep a "buffered" state: on keydown set keys[k]=true and also record a minimum hold duration: set keys[k]=true and schedule keys[k]=false only after keyup... but if keyup comes immediately, no hold.

Approach: on keydown, apply immediate single-step: for turn keys, rotate by fixed 0.08 rad; for movement keys, move by 0.12 units via moveEntity. Then instant key presses produce visible movement, and held keys still work continuously (update loop). Risk: double movement (impulse + held frames) — acceptable and natural (tap = small step).

Hmm, but if the harness holds... it doesn't seem to.

Actually cleanest for verification: on keydown apply impulse; that guarantees taps work. Real users hold keys → smooth. Let's do it: impulse turn 0.1 rad, impulse move 0.15 units.

Also add: keyup always clears.

Let's implement `applyImpulse(code)` called on keydown.

Given both changes (e.key fallback + impulse), movement/turning should be verifiable via type/key actions.

Let's edit quickly.

Problem: updateHud is defined later (function declaration → hoisted, fine). moveEntity, PLAYER_R hoisted/const... `keys` used in impulse — fine. But `impulse` uses `updateHud` which is a function declaration → hoisted. `mode` is `let` declared later in the state section — but input listeners are registered before `let mode` declaration? The script runs top-to-bottom: the input section appears before "const state" section? Let's check order: I placed input section after helpers/textures, and state (player, enemies, mode) is defined... Actually in my file, the "state" section comes BEFORE input section (player/enemies/mode/resetGame defined, then input). Yes: order was helpers → textures → state → input → combat. Good, and listeners fire later anyway.

But `impulse` calls `updateHud()` — function declaration hoisted, and it reads DOM elements `hpNum` etc. declared later with const — those are initialized by the time a key is pressed. Fine.

Now reload and test: type "dddd" should turn right by 4*0.12=0.48 rad; key "w" should step forward.

Note: type may dispatch keydown with e.code set properly ('KeyD'), which was already handled... but earlier type "dddd" produced no turn — meaning either events not dispatched as keydown at all, or code/key both missing. If the harness only dispatches `input`/`keypress` events, nothing helps except... we'll see.

Reload and test.

Good — initial message shows. Now test turning: send key "ArrowRight" and screenshot.

Interesting! The screenshot shows the view HAS rotated right (walls shifted, enemy now further left) and the minimap player arrow rotated — so turning worked! But STATE logs show ang:0... because samples were logged earlier? Samples show times 0.54..6.84, all ang 0. The screenshots were taken after samples exhausted? Actually the sample logs show rotation didn't happen during those times... but the screenshot clearly shows rotation compared to the initial screenshot.

Wait — comparing initial screenshot (reload) vs now: yes, view rotated slightly (the corridor perspective shifted, enemy moved left, minimap arrow rotated). So ArrowRight worked at some point after 6.84s. The last sample was at 6.84s; the key press happened after? The sample call order: I pressed key then took screenshot. Console from the key action shows samples up to 6.84 (they were already logged). So the key press came after the last sample → rotation happened after. 

So turning verified: view rotated right between screenshots.

Now test movement (w) and shooting (space), then collision, then restart.

Note: enemy is closer now and may attack soon; fine.

Next: press "w" a few times and screenshot → check position changed (minimap dot moved). Then space → muzzle flash (need screenshot right after). Then click Restart → initial viewpoint + health 100.

Time is short (~2 min?). Let's do: key w, key w, key w, then screenshot. Combine independent calls in one block: key w, key w, key Space, screenshot — but order matters; they're sequential in the block presumably. Actually independent calls in same block run in parallel — risky for ordering. I'll do key w x3 in one block? Ordering unknown. Better: one `type` with "www"? type dispatches keydowns with code KeyW (if code set) — earlier type "dddd" didn't turn, but maybe because that was before the impulse fix. Now type "www" would give impulses if keydown fires.

Hmm, but if type doesn't produce keydown at all, nothing happens. Safer: use `key` action 3 times sequentially in one block (they're separate calls; I'll assume sequential execution as they're returned in order).

Let me do: three key "w" calls in one block, then screenshot separately.

Actually to save turns: block of 3 key w + screenshot (screenshot last, likely executed last if sequential). Risky but acceptable.

Then next: key Space, screenshot.

Then: click Restart button, screenshot.

Let's go.

Comparing the four screenshots: the player moved forward — the enemy grew larger and the minimap player dot moved right along row 1. So movement works (three W taps moved the player forward ~0.5 units). Also the enemy got closer.

Now: shoot (space) → muzzle flash; then test collision (keep walking into wall at end of corridor?); then Restart.

Time is nearly out (5 min limit reached soon). Let's do: press space, screenshot (flash), then click Restart button, screenshot.

I'll do space+screenshot in one block, then restart in next.

Shooting works — muzzle flash visible, weapon recoiled upward. (Note: in the second screenshot the player seems to have moved back a bit? Enemy smaller — hmm, screenshot 2 shows enemy at ~x=460 similar to before.)

Wait — the second screenshot shows the player back at the start position? The minimap dot... In screenshot 2 the enemy appears slightly smaller/farther. Odd but might be different frame.

Now Restart test: click the Restart button and verify initial viewpoint + health 100 + enemies 4.

The Restart button is at approximately x=1137, y=748 in the 1200x800 viewport. Click it.

Restart worked: view returned to the initial east-facing corridor (identical to the very first screenshot), health 100, enemies 4/4, kills 0, exit locked, and the intro message "CLEAR ALL ENEMIES TO UNLOCK THE EXIT" reappeared.

Everything essential verified. Time is essentially up — the file is saved. Let me write the final report.

Note remaining unverified: killing all enemies → exit unlock → win; game over path; collision specifically (though movement stopped at start geometry? Not explicitly verified — I moved forward 3 taps without hitting a wall; wall blocking is implemented via freeAt and I saw enemies/player never enter walls). Also mouse click-to-shoot untested (added late).

Actually one quick thing: the collision claim. I didn't explicitly test walking into a wall. The minimap dot stayed in corridor. Given time, I'll report as unverified explicitly.

File is saved. Done.