Wolfenstein raycaster · particle-1

Let me build this. Need a raycasting engine with procedural textures, sprites for enemies, HUD, etc. Let's write a solid single-file implementation.

Plan:
- Canvas full screen, internal resolution like 640x400 scaled up with image-rendering pixelated? Could render at lower res for performance. Use a 480x300 backbuffer drawn to canvas, scale up via CSS or drawImage.
- Maze grid, e.g. 24x24 with walls made of textured blocks. Use a fixed level map.
- Procedural textures: brick wall, stone, exit door (green), generated into offscreen canvases or directly into typed arrays of 64x64 RGBA.
- Enemies as billboard sprites with depth buffer occlusion. Draw sprite procedurally (pixel art-ish demon) into an offscreen canvas with transparency.
- Enemies patrol/chase with simple rules; attack when close and line of sight, cooldown, damage player.
- Shooting: hitscan from player along view, check nearest enemy within a cone and line of sight unblocked, apply damage. Muzzle flash, gun animation.
- Health, enemy count HUD, game over, win, restart button and R key.
- Controls display.
- Weapon feedback: gun sprite at bottom with recoil, muzzle flash, sound via WebAudio (procedural, no external). Sound optional but nice; guard against autoplay issues.

Let me carefully write the code.

Key elements:

Map: array of strings, each char: '#' wall, '.' floor, 'D' exit door, 'E' enemy spawn, 'P' player spawn. Level should be small-ish but with a reachable exit.

Let's design a 24x20 maze:

Use strings of equal length. Let me construct with code maybe. I'll hand-craft.

Let me make a 24 wide x 20 tall map:

```
########################
#P...#........#........#
#....#..####..#..####..#
#....#..#..#..#..#..#..#
#.......#..#.....#..#..#
####.#..#..#######..#..#
#....#..#.........#..#.#
#.##.#..#####.###.#..#.#
#.#..........#...#.....#
#.#.####.###.#.#######.#
#...#..E...#.#.......#.#
###.#.####.#.#######.#.#
#...#.#..#.#.....#...#.#
#.###.#..#.#.###.#.###.#
#.....#..#...#E#.#.....#
#.#####..#####.#.#.###.#
#.....#E.......#.#...#.#
#.###.#######..#.###.#.#
#....................D.#
########################
```

Hmm need to verify reachability and that exit is reachable. Rather than hand-verify, I can write a BFS check in JS at load time and console log. But I need the actual game to work; let me carefully design a simpler maze that's guaranteed connected — e.g., generate a maze with recursive backtracker at load time (procedural), then place player, enemies, and exit in open cells with BFS distances. That guarantees connectivity and reachability. That's elegant and "generate textures procedurally" as well. But maze needs to be small and open enough for combat. Use odd size grid like 21x17, recursive backtracker with cell width 2, then randomly remove some walls to make loops (braid) so it's less claustrophobic.

Map generation: W=21,H=17 (odd). Initialize all walls. Carve from (1,1) with DFS. Then with probability 0.25 remove random interior walls that aren't pillars? Removing walls randomly can create 2x2 open areas, fine.

Then pick player start cell as far as possible from exit? Player at a random open cell; exit at the farthest open cell by BFS distance; enemies at open cells with enough distance from player and mutually spaced.

Ensure exit is reachable: farthest BFS cell guarantees it.

Enemy count = 4.

Enemy AI: state idle/chase. Each enemy has position. If line of sight to player and within ~8 tiles, move toward player using simple grid-based pathfinding (BFS from player to get distance field, or greedy movement with collision). Simpler: use BFS distance field from player computed occasionally (every 0.3s) for all cells, enemies follow the gradient — good navigation.

Attack rule: if distance < 1.2 tiles and LOS and cooldown elapsed (1s), damage player by ~8, flash screen red, sound.

Shooting: on Space, hitscan along nearest enemy within angle threshold and distance, must have LOS. Deal 34 damage (3 hits to kill with 100 hp enemy). Add tracer/flash. Enemies flash white on hit.

Also enemies can see player through LOS only.

Rendering:
- Rays: for each screen column x (at render width e.g. 400), compute ray direction using camera plane. DDA. Wall type determines texture. Shade by distance and side.
- Floor/ceiling: simple vertical gradient fill, maybe textured floor casting (cheap-ish). I can do a simple gradient for ceiling and floor to keep perf, but textured floor is nicer. Performance might be OK at 400x250 with gradients only. Let's do gradient + subtle noise pattern? Simplest: solid gradient. Requirement says textured grid maze — walls textured suffices. Maybe add textured floor via floor casting at half res... skip, keep perf. Actually floor casting at 400x250 is fine in JS? per pixel for lower half = 50k pixels, ok at 60fps? Might be heavy. Use gradient with some horizontal banding to look like tiles. I'll do simple approach: floor gradient plus fog. Fine.

Textures: generate 64x64 RGBA arrays with functions:
- brick texture (red/brown with mortar lines and noise)
- stone block (gray)
- mossy stone / tech panel
- exit door: green with glowing stripes.
Procedural generation with ImageData or typed arrays.

I'll build texture as Uint32Array? Use ImageData-based canvases per texture then sample via getImageData into Uint32Array. Simpler: build Uint8ClampedArray data manually (r,g,b per pixel), create ImageData, put into canvas, then use drawImage in vertical strips scaled — but per-column drawImage with clipping and scaling is fine and fast: for each column, draw a 1px-wide slice of texture scaled to wall height. That avoids per-pixel loops. With 400 columns and 400 drawImage calls per frame... drawImage 400 times per frame is generally OK. But shading: apply darkness with fillRect over the column with rgba black — doubles calls to 800. Could pre-generate shaded variants? Simpler: use globalAlpha + fillStyle black overlay per column. In practice, 800 canvas ops at 60fps maybe ~fine on modern machines. Alternative: per-pixel loop into ImageData buffer: 400x250 = 100k pixels, pure JS ~ fine (few ms). Let's do per-pixel into ImageData for full control (textures, shading, sprites z-buffer). That's the classic approach. 400*250=100k px, each doing some math — ~5-10ms in JS. Acceptable. Then scale up with imageSmoothingEnabled=false.

Let's set render resolution 400x250, canvas CSS scaled to fit window preserving aspect ratio (4:3-ish 1.6). Actually 400x250 = 1.6, fine.

Detailed renderer:
- ImageData buffer Uint32Array (little-endian ABGR) for speed. Build using DataView? Use Uint32Array over imageData.data.buffer, and pack colors as 0xFF000000 | (b<<16) | (g<<8) | r for little-endian. Assume little-endian (standard). I'll compute color as (255<<24) | (b<<16) | (g<<8) | r.

Sky/ceiling: gradient rows precomputed colors per row (dark). Floor: gradient with checker? Precompute per-row colors; maybe add simple perspective checker via floorcasting: for each pixel below horizon, compute row distance and world coords with texture lookup — cost 60k pixels with divisions. Let's do floor casting: rowDist = (0.5 * h) / (y - h/2). Precompute per row: rowDistance, and stepX/stepY. Then per pixel, tx = floor(worldX*64) & 63, ty similarly; sample floor texture; shade by distance. That's about 60k samples/frame. Should be fine. Ceiling can be a simple dark gradient (or same cast with different texture). Do ceiling flat dark gradient to save time.

Fog/shading: shade = 1/(1+dist*0.12) etc., or use distance-based darkening with min brightness. Apply multiply.

Walls: standard raycast per column. Compute perpWallDist, lineHeight = (h / perpWallDist) * projScale. Use texture X from wall hit. Then per-pixel y from drawStart..drawEnd, sample texture Y. Apply side shading and distance fog. Save zBuffer[x] = perpWallDist.

Sprites (enemies, exit marker?): sort by distance descending, project with inverse camera matrix, draw with zBuffer check per column.

Enemy sprite: pre-render a canvas 64x64 with pixel art monster (procedural drawing: body, eyes, horns). Convert to Uint32Array with alpha. For rendering, per-column, per-row sample. Need to handle alpha=0. Sprite scaling: sprite height in world ~0.9; project: spriteScreenX etc. Standard Lode's tutorial.

Also death animation: enemy death -> play shrink/fade? Simpler: on death, mark dead and remove from list after short fade (scale down). Keep simple: dead enemies disappear with a brief "flash" particle? I'll add a short death animation: timer 0.35s, scale vertical shrink. Could just remove immediately and show hit marker. Let's do shrink.

Exit: draw as a wall tile type 'exit' with green glowing door texture. When locked, maybe show red bars? Requirement: defeating all enemies unlocks exit; reaching it shows win state. If all enemies dead, the exit tile glows/opens; when player within 0.6 tiles of exit cell center, win. Show message "Exit locked — 4 enemies remain" when near? HUD indicator.

Exit tile: since it's a wall, player can't walk into it; reaching means getting adjacent within 1.0 distance. Compute distance from player position to exit cell center; if < 0.9 and unlocked -> win. Let's place exit as a wall cell that's the farthest from start. Player must approach it. Fine.

HUD: draw in DOM overlay (HTML/CSS) rather than canvas — easier: health bar, enemies remaining, message banner, controls list, restart button, crosshair. Requirement says display controls. Use HTML overlay.

Weapon: draw gun on canvas at bottom, procedurally with rects, with recoil animation and muzzle flash. Draw after 3D scene with scale based on canvas size. Gun drawn in the low-res buffer? Better draw on the scaled canvas after scaling the image? Simplest: draw everything in the low-res buffer coordinate system on the display canvas: drawImage of lowres into a scaled canvas context... Let's use one canvas at fixed internal resolution 800x500? Hmm. Use display canvas full window size with ctx.imageSmoothingEnabled=false and drawImage(offscreen 400x250, 0,0,w,h). Then draw weapon with vector paths scaled to canvas size. Good: weapon crisp-ish vector.

Sounds: WebAudio procedural: shoot (noise burst + saw), hit, enemy growl, hurt. Keep small. Init on first input.

Input: keydown/keyup map. Prevent default arrows/space. Also focus; use window listeners.

Movement: speed 2.6 tiles/s, strafe; collision with radius 0.25 using separate axis checks. Turn speed 2.2 rad/s.

Frame loop with dt clamped.

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

Restart: regenerate level? "Provide Restart to restore the level, player, enemies, and health." Could regenerate maze each time — "restore the level" maybe same level. Safer: keep the generated level but reset player/enemies/health, so it "restores". I'll generate level once per restart with same seed? Simpler: reset everything to the same level layout (regenerate identical using stored map). I'll store initial map and reset. Actually regenerating with random seed each restart is also fine and arguably "restore". I'll reset to the same stored map positions: store playerStart, enemies spawns, exit. Reset positions and health. Good.

Now BFS for pathfinding gradient from player. Compute every 0.25s: BFS over open cells from player cell, produce dist array. Enemy movement: each enemy tries to move toward neighbor cell with lower dist value (or direct toward player if LOS). Use direct steering toward center of next cell with collision.

Enemy-enemy separation: avoid stacking — apply small repulsion.

Enemy attack: if LOS and dist < 1.3 and cooldown <=0: damage 9-14, set cooldown 1.1s, screen flash, sound. Also enemies stop when close.

Line of sight: DDA step along segment sampling cells every 0.05; check if cell is wall (including exit).

Shooting: check each alive enemy: vector to enemy, project onto dir, if forward dot > 0 and dist < 14, angle between dir and vector < atan(?) use perpendicular distance < 0.35 (roughly hit radius) — must have LOS. Choose closest hit. Damage 40. Enemy hp 100 → 3 shots. Enemy count decrements on death.

Crosshair DOM.

Also display minimap? Not required; skip (or small minimap optional). Keep focus.

Let me be careful with performance: per-pixel loops with typed arrays.

Implementation details for textures: create function makeTexture(size, drawFn) returning Uint32Array using a canvas 2D then getImageData. That's easy: use OffscreenCanvas? Use document.createElement('canvas'). Draw with 2D ops (fillRect etc.) then read pixels. Good and simple for procedural art.

Textures needed: 0 brick, 1 stone, 2 metal/tech, 3 exit door (locked/unlocked variants?) — I can use two textures: exit locked (red door) and exit open (green glowing). Since the whole map uses wall type per tile, when unlocked I change tile type at render time based on flag: use texture 3 when locked, texture 4 when unlocked.

Wall tile values: map cell 0 = empty, 1..4 = wall types, 5 = exit. Map stored as Int8Array of size W*H.

Texture sampling arrays 64x64 = Uint32Array(4096).

Colors packed little-endian as above.

Shading multiply: extract channels and multiply by factor; do function shade(color, f). To speed, precompute? Just do arithmetic per pixel: r=(c&255)*f etc. It's fine.

Let's write the wall shading: base = color; apply side darkening (0.7 for y-side) and fog factor f = clamp(1.8/(1+dist*0.25)?). Let's use f = 1/(1+d*0.18) clamped min 0.15; plus ambient .1. Try f = Math.max(0.12, 1 - d/16) maybe. Use light = clamp(1.6/(1+d*0.35), 0.15, 1). Hmm with typical distances 1-10. I'll use f = 1/(1+d*0.22), min 0.12, and multiply side factor 0.72.

Floor casting: for each row y > horizon: rowDist = (0.5*h) / (y - h/2) — where camera height 0.5. Actually standard: posZ = 0.5*h; rowDistance = posZ / (y - h/2). With h=250, horizon 125. For y=126 rowDist=125. Then floorStepX = rowDistance * (rayDirX1 - rayDirX0)/w etc. Add wave/checker pattern: sample floor texture at scale 2 (tiles of 0.5 world units? use 1 unit tile = 64px texture: worldX*64 & 63).

Floor texture could be two: checker tiles. Ceiling: similar but dark; do gradient with subtle horizontal lines.

Actually with floor casting for ceiling too it doubles cost. Ceiling as flat dark gradient is fine and Wolfenstein-ish (usually flat ceiling).

Sprites: enemy sprite 64x64 texture with alpha (store Uint32 with alpha bits). Draw billboard: standard.

Enemy sprite variants: one texture, maybe tinted at hit. Add hurt flash: when hit, render sprite with white overlay for 0.1s. Also different enemy colors? Could tint per enemy slightly (multiply). Let's do tint factor per enemy (slightly different hue) — apply at render: shade color with tint. Simple.

Sprite art: create 64x64 canvas:
- transparent bg
- body: an armored demon: dark torso, red eyes, horns, claws.
Draw with rects for pixel-art feel (draw at 8px blocks? use 4px blocks on 64 grid = chunky). Let's draw with 2px blocks for detail.

Let me write pixel art function using palette grid strings! That's clean: define 16x16 char grid, each char maps to color, draw each cell as 4x4 pixels. Nice.

Design a 16x16 monster sprite:

```
................
....##....##....
...#..#..#..#...
...#..####..#...
...##......##...
....########....
...#@@#@@#@@#...
...#@##@@##@#...
...#@@@@@@@@#...
....#@#..#@#....
....###..###....
...#..#..#..#...
..#...#..#...#..
..#...####...#..
..#...#..#...#..
.....##..##.....
```

Hmm, let's make something readable: horns on top, red glowing eyes, ugly mouth, arms.

Chars: '.' transparent, '#' dark outline, 'b' body greenish, 'd' dark body shade, 'r' red eyes, 'w' teeth white, 'c' claws.

16x16 grid, scale 4 -> 64px.

```
................
..#..........#..
..##........##..
..#b#......#b#..
...#b######b#...
....bbbbbbbb....
...bbbrbbrbbb...
...bbbbbbbbbb...
...bb#wwww#bb...
....bbbbbbbb....
...b#bbbbbb#b...
..#bb#bbbb#bb#..
..#bb..bb..bb#..
...#...bb...#...
.......bb.......
......#..#......
```

Good enough. Make eyes 'r' bright red.

Also add a "hurt" white version when flashing — apply at render time via tint.

Maybe add a second sprite for "exit" marker? Not needed.

Enemy render: sprite drawn with vertical offset so feet on floor: sprite height in world 0.95, sprite bottom at floor line. Standard: spriteHeight = abs(h / transformY) * 0.95; vMove = ... For floor alignment: vMoveScreen = (0.5 - 0.5*scale?) Let's use standard with uDiv/vDiv and vMove. Simpler custom:

transformY = depth along camera direction, transformX lateral.
spriteScreenX = (w/2) * (1 + transformX / transformY)
spriteH = (h / transformY) * 0.9  (world height 0.9 with camera plane at 0.5 height... for 1-unit tall object, h/transformY gives correct).
Feet at horizon + (h/2)/transformY? The floor point at distance d appears at y = h/2 + (h/2)/d. So bottom of sprite = h/2 + (0.5*h)/transformY (camera height 0.5). Top = bottom - spriteH where spriteH = h/transformY * 0.9. Good.

Width = spriteH (square-ish) * aspect... Use spriteW = spriteH * 0.8.

Then per column within [x0,x1], if transformY < zBuffer[col], sample texture column.

Sprite texture coords: texX = ((x - x0) / (x1 - x0) * 64)|0.

Now camera: plane vector = perpendicular of dir * fov factor 0.66. Standard DDA.

Turning with left/right; also optional mouse? Skip mouse; add pointer lock optional? Requirement says optional and not required. Add mouse look via drag maybe? Keep simple: optional mouse move when pointer locked on canvas click. I'll add pointer lock mouse turn + click to shoot? Clicking might conflict with Restart button; add mousemove handler when pointerLockElement===canvas. And mousedown to shoot. Fine, low risk. Actually risk: pointer lock in sandbox may fail. It's optional, wrap in try/catch. Let's include: click canvas → requestPointerLock (guarded), mousemove → turn. Hmm pointer lock hides cursor; user could get stuck. Keep it simple and skip pointer lock. Add only keyboard. I'll skip mouse entirely to reduce risk.

Weapon rendering: draw on display canvas ctx with coordinates scaled: gun body polygon bottom center, sway based on movement (bob), recoil offset, muzzle flash. Use ctx transform scale relative to canvas size.

HUD overlay in HTML with CSS: top-left health bar, enemies remaining, message center, controls bottom-left, restart button.

Let's write code now.

Structure:

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

Canvas sizing: JS sets canvas.width/height to window inner size on resize, CSS fills. Offscreen buffer 400x250 fixed? For crispness maybe 480x300. Ray count 480, pixel buffer 144k — fine.

Actually aspect: use render W=480 H=300. Display scaling preserves aspect: set canvas CSS width/height to fit container with aspect 480/300, centered with black letterbox.

Let's code:

```js
const RW=480, RH=300;
const buf = document.createElement('canvas'); buf.width=RW; buf.height=RH;
const bctx = buf.getContext('2d');
const img = bctx.createImageData(RW,RH);
const pix = new Uint32Array(img.data.buffer);
```

Textures: function makeTex(size, fn) : canvas, ctx, fn(ctx,size), getImageData → Uint32Array.

Packing: on little-endian, Uint32 = a<<24|b<<16|g<<8|r. I'll check endianness? Just assume; browsers on LE overwhelmingly.

Wall textures:

tex0 bricks:
```js
function texBrick(){
 return makeTex(64,(c,s)=>{
  c.fillStyle='#6b3a2a'; c.fillRect(0,0,s,s);
  // noise
  for(let y=0;y<s;y+=16){
    for(let x=0;x<s;x+=32){
      const off = (y/16)%2?16:0;
      for(let bx=-32;bx<s+32;bx+=32){
        c.fillStyle = `hsl(${12+Math.random()*8}, ${35+Math.random()*15}%, ${26+Math.random()*10}%)`;
        c.fillRect(bx+off+1,y+1,30,14);
      }
    }
  }
  // mortar noise dots
  for(let i=0;i<400;i++){ c.fillStyle='rgba(0,0,0,'+(Math.random()*0.2)+')'; c.fillRect(Math.random()*s|0,Math.random()*s|0,1,1); }
 });
}
```
Careful with loops generating odd patterns across tile edges — seams; acceptable.

tex1 stone: gray blocks with cracks.
tex2 metal panel: blue-gray with rivets/vertical stripes.
tex3 exit locked: dark red door with bars.
tex4 exit open: green glowing.

Floor: tile texture 64: checkered stone.
Ceiling: dark gradient computed per row.

Sprite texture from palette.

Game data:

```js
const MAPW=21, MAPH=17;
let map = new Uint8Array(MAPW*MAPH);
```
Maze gen:

```js
function genMaze(){
  map.fill(1);
  // carve odd cells
  const stack=[[1,1]];
  map[1*MAPW+1]=0;
  const visited=...
```
Recursive backtracker:
```js
const cellW=((MAPW-1)/2)|0, cellH=((MAPH-1)/2)|0;
function idx(cx,cy){return (cy*2+1)*MAPW + cx*2+1;}
visited set...
```
Then braid: for each wall cell at even coordinate? Remove random interior walls with prob 0.22 where it isn't boundary: for cells x in 1..MAPW-2, y in 1..MAPH-2, if map[cell]==1 and random<0.12 → 0. This creates loops.

But ensure walls remain "thick" enough visually? 1-cell walls are fine in raycaster.

Guarantee: after braid, flood fill from player start to find farthest open cell → exit. Also ensure enough open cells for enemies (>=6 apart).

Player start: pick open cell near (1,1) say the first open cell. BFS distances. Exit = max distance cell. Also choose the exit cell as a WALL cell adjacent to that farthest open cell? Requirement: reaching it shows win state. If exit is a wall tile, player walks adjacent to it. Better: make exit an open cell with a special floor marker (green glow) plus a door frame? Simpler: exit is an open cell containing a glowing portal drawn as sprite/floor marker; walking within 0.5 units triggers win. That avoids wall-tile logic. But a "door" looks nicer. Either is acceptable.

Design: exit is an open cell marked as exit; render a glowing green portal as a billboard sprite in that cell (like a wall-less arch) plus floor glow. Trigger when player within 0.6 units of center. That's clear.

But if exit unlocked indicator: while locked, portal is red and message "Defeat all enemies to unlock the exit". Near exit while locked: show "Exit locked".

For rendering exit portal: sprite billboard 64x64 with arch/portal art drawn procedurally (rings). Drawn with depth buffer occlusion, so it will be hidden behind walls. It's in an open cell, so it could be visible through corridors - fine.

Enemy spawn cells: open cells with BFS distance from player start >= 4 and distance from exit > 1, spread out. Pick randomly among candidates, requiring min separation 3 between enemies.

Enemies count 4.

Now code details:

```js
const state = {
 mode:'playing', // playing | dead | win
 time:0, bob:0, muzzle:0, recoil:0, flash:0,
 health:100
}
const player = {x,y,dirX,dirY,planeX,planeY}
```

Store dir as angle for easier turning: px,py,ang. Compute dirX=cos(ang), dirY=sin(ang); plane = (-sin*0.66, cos*0.66)? For standard camera plane perpendicular: plane = dir rotated 90° * 0.66 → (dirY, -dirX)*0.66? Let's set planeX = -dirY*fov? In Lode's, dir=(-1,0), plane=(0,0.66). plane is dir rotated -90°: rotate (x,y) by -90 → (y,-x). dir=(-1,0) → (0, 1)*0.66 = (0,0.66). Yes plane = (dirY, -dirX)*0.66. Then screen x from left to right maps cameraX -1..1, ray = dir + plane*cameraX. With dir=(-1,0) plane=(0,0.66), cameraX=-1 gives ray (-1,-0.66)?? that's left side... y negative. Hmm in Lode's plane is (0,0.66) and ray for x=0 is dir-plane = (-1,-0.66) which appears left of facing. Fine either way; just consistent. Let me define plane = (dirY, -dirX)*fov → for dir=(1,0) (facing +x), plane=(0,-fov): ray at screen left = dir - plane = (1, +fov) which is... in world coordinates with y down (map rows), turning right should be -? Let's think: screen left should correspond to direction rotated counterclockwise in standard math, but with y down screen coords, up/down flips visual.

Let's just use angle: ang increases → dir rotates toward +y (down in map). Turning right (arrow right) increases ang (clockwise in screen terms since y is down... ). With y down, rotating dir clockwise visually means (x,y)->(x cosθ - y sinθ, x sinθ + y cosθ) which is standard rotation but appears clockwise on screen because y is down. So ArrowRight → ang += turnSpeed. Ray for screen column x: cameraX = 2*x/RW - 1, rayAng = ang + atan(cameraX*tan(fov/2))? That's a non-linear camera (fisheye corrected differently). Simpler to use raycaster with plane: planeX = -sin(ang)*0.66? Let's derive: screen right direction (cameraX=+1) should be dir rotated +90° visually (clockwise on screen) = (cos(ang+90), sin(ang+90)) = (-sin, cos). So plane = (-sin(ang), cos(ang)) * 0.66. Then ray = dir + plane*cameraX. With dir for ang=0: (1,0), plane=(0,0.66): cameraX=+1 → ray (1,0.66) points down-right on map → on screen appears to the right. Good? In screen space, whether that's right depends on projection; standard geometry yes.

So planeX=-sin*f, planeY=cos*f. FOV factor 0.66 (66°).

DDA standard.

Collision: circle radius 0.28. Try move X then Y with map cell check plus adjacent cells.

```js
function isWall(cx,cy){ if(cx<0||cy<0||cx>=MAPW||cy>=MAPH) return true; return map[cy*MAPW+cx]!==0; }
function canMove(x,y){ // check circle
 const r=0.28;
 if(isWall(Math.floor(x+r),Math.floor(y+r))) ... 
```
Standard: check four corners of bounding box:
```js
function blocked(x,y){
 const r=0.27;
 for(const [dx,dy] of [[-r,-r],[r,-r],[-r,r],[r,r]]) if(isWall(Math.floor(x+dx),Math.floor(y+dy))) return true;
 return false;
}
```

move:
```js
let nx = x + mx; if(!blocked(nx,y)) x=nx;
let ny = y + my; if(!blocked(x,ny)) y=ny;
```

BFS dist field from player cell (open cells only), computed each 0.2s for enemies. BFS over open cells; for exit cell open also traversable.

Enemy update:
```js
e = {x,y,hp,maxhp,alive,cooldown,hurt,deadT, tint}
```
Compute LOS: blocked line of sight function (sample every 0.08 along line).
If dist < 0.9 and LOS → attack.
Movement: if dist > 1.0:
 - if LOS: direction directly toward player
 - else: use gradient: current cell's neighbors → choose min dist; target = center of that cell; direction toward target.
 Then move speed 1.35 * dt, with collision (blocked by walls).
Separation: for other enemies within 0.45 → push away slightly.

Enemy takes damage: hp -= 40; hurt=0.12; if hp<=0 → alive=false, deathT=0, count--, add score.

Shooting: 
```js
function shoot(){
 if(!canShoot) return;
 muzzle = 1; recoil = 1; playShoot();
 // find target
 let best=null, bestT=Infinity;
 for(e of enemies) if(e.alive){
   const dx=e.x-px, dy=e.y-py;
   const t = dx*dirX+dy*dirY;
   if(t<=0.2||t>16) continue;
   const perp = Math.abs(dx*plane... )
```
Use perpendicular distance from ray: cross = |dx*(-dirY) + dy*dirX|? Actually lateral = dx*rightX + dy*rightY where right=(-dirY? ) Hmm: dot with the perpendicular direction (screen right) = (-sin, cos) = (-dirY, dirX). lateral = dx*(-dirY)+dy*dirX. If |lateral| < 0.42 (enemy radius) and t < bestT and LOS → candidate. Also distance along t. Choose min t. Damage 40. Add hit marker flash & ping sound. Note enemies smaller hitbox; also add slight aim assist.

Also shooting hits wall: spawn tracer? Weapon muzzle flash enough.

Fire cooldown: 0.28s between shots.

Enemy damage to player: health -= 7 + random 5. flash = 1, screen shake maybe. If health<=0 → mode 'dead'.

Win: if unlocked and distance to exit < 0.55 → mode 'win'.

HUD update each frame via DOM text/width (cheap). Also update message.

Now rendering.

```js
function render(){
 // ceiling gradient & floor casting
 for y in 0..RH:
   if y < horizon: color gradient (dark blue-gray) with slight dithering
   else: floorcast
```

Floor cast per row precompute:
```js
const posZ = 0.5*RH;
// ray dirs for leftmost and rightmost
const rayDirX0 = dirX - planeX, rayDirY0 = dirY - planeY;
const rayDirX1 = dirX + planeX, rayDirY1 = dirY + planeY;
for(y = horizon+1; y<RH; y++){
  const p = y - RH/2;
  if(p<=0) continue;
  const rowDist = posZ / p;
  const stepX = rowDist*(rayDirX1-rayDirX0)/RW;
  const stepY = rowDist*(rayDirY1-rayDirY0)/RW;
  let fx = px + rowDist*rayDirX0;
  let fy = py + rowDist*rayDirY0;
  const shade = fog(rowDist);
  for(x=0;x<RW;x++){
    const tx = ((fx*64)&63)>>>0; // fx*64 mod 64
    const ty = ((fy*64)&63)>>>0;
    const c = floorTex[ty*64+tx];
    pix[y*RW+x] = shadeColor(c, shade);
    fx+=stepX; fy+=stepY;
  }
}
```
Note `&63` on negative numbers works in JS bitwise (two's complement) giving positive. Good. fx*64 could be big; use `(fx*64) & 63` works with floats? Bitwise converts to int32 (truncates), fine. But very large world coords not an issue.

Cost: 150*480 = 72k pixels with tex sample and shade function. Should be OK (~5ms).

Fog function: 
```js
function fog(d){ let f = 1.0/(1.0 + d*d*0.028); return f<0.11?0.11:f; } 
```
Hmm at d=1: 0.97; d=3: 0.8; d=5: 0.55; d=8: 0.33; d=12: 0.18. Good.

shadeColor: 
```js
function shadeColor(c, f){
 const r = (c & 255)*f;
 const g = ((c>>8)&255)*f;
 const b = ((c>>16)&255)*f;
 return 0xFF000000 | (b<<16) | (g<<8) | r;
}
```
Careful: bit shifts need ints: `(b|0)<<16`.

Performance: creating function calls per pixel fine.

Optimization for ceiling: per row fill with precomputed color: loop x, assign same value — fine.

Walls:
```js
for(x=0;x<RW;x++){
 const cameraX = 2*x/RW - 1;
 const rdx = dirX + planeX*cameraX;
 const rdy = dirY + planeY*cameraX;
 let mapX = px|0, mapY = py|0;
 const ddx = Math.abs(1/rdx) (handle inf naturally), ddy...
 ...
```
Note px|0 floors for positive; fine.

DDA returns side, perpWallDist, wall type.

texX computation:
```js
let wallX = side===0 ? py + perp*rdy : px + perp*rdx;
wallX -= Math.floor(wallX);
let texX = (wallX*64)|0;
if(side===0 && rdx>0) texX = 63-texX;
if(side===1 && rdy<0) texX = 63-texX;
```

lineHeight = RH/perp * 1.0? Wall height 1 with camera at 0.5 → projected wall spans RH/perp... Actually with camera plane projection, wall of height 1 at distance d covers (1/d)*RH pixels vertically? In Lode's: lineHeight = h/perpWallDist, centered at h/2, giving walls of height 1 world unit when camera height 0.5 and projection plane distance ~1. Yes.

drawStart = -lineHeight/2 + RH/2, drawEnd = +.

Then per pixel:
```js
const step = 64/lineHeight;
let texPos = (drawStart - RH/2 + lineHeight/2)*step;
for(y=Math.max(0,drawStart|0); y<Math.min(RH, drawEnd|0); y++){
 const texY = (texPos & 63) >>> 0; texPos += step;
 ...
}
```
Wait `texPos & 63` with float→int truncation works.

Shade: fog(perp) * (side===1?0.72:1). Also add a slight vertical gradient? no.

zBuffer[x] = perp.

Sprites: gather [enemies alive + exit portal + dying enemies], compute distance, sort desc, project.

```js
function drawSprite(tex, sx, sy, scale, wScale, yOffset, tint, alpha)
```
transform:
```js
const invDet = 1/(planeX*dirY - dirX*planeY);
const transformX = invDet*(dirY*dx - dirX*dy);
const transformY = invDet*(-planeY*dx + planeX*dy);
if(transformY <= 0.15) skip;
const screenX = (RW/2)*(1 + transformX/transformY);
const spriteH = Math.abs(RH/transformY) * scale;   // scale = world height
const spriteW = spriteH * wScale;
const bottom = RH/2 + (0.5*RH)/transformY + yOffset*(RH/transformY);
```
Hmm: bottom (floor contact) = RH/2 + (0.5*RH)/transformY? Projection of point at height 0 (floor) relative to camera at height 0.5: screen y = RH/2 + (0.5 * RH)/transformY? The projection: screenY = RH/2 + (cameraZ - worldZ) * (RH / transformY)? For cameraZ=0.5, worldZ=0 → offset = 0.5*RH/transformY. Yes for an object with total height 1 (top at 1): topY = RH/2 + (0.5-1)*RH/transformY = RH/2 - 0.5*RH/transformY, so spriteH = RH/transformY. Good, matches lineHeight at distance. So for scale s (height fraction), top = bottom - s*RH/transformY.

I'll compute spriteH = (RH/transformY)*scale and bottom = RH/2 + (0.5*RH)/transformY, top = bottom - spriteH.

For death animation, scale shrinks and yOffset? just scale.

Horizontal: left = screenX - spriteW/2, right = screenX + spriteW/2, where spriteW = spriteH * aspect (texture is square) maybe *0.9.

Per column: for x from max(0,left) to min(RW-1,right): if transformY < zBuffer[x] then sample.

Per row: for y in max(0,top)..min(RH-1,bottom): texY = ((y-top)/spriteH*64)|0, texX = ((x-left)/spriteW*64)|0.

Alpha blending: sprite tex has transparent pixels (alpha 0), skip; else write shaded. For tint/flash: if hurt>0 use white-ish. For portal sprite maybe emissive (no fog darkening, actually use fog but boost brightness).

Enemy tint colors: multiply r,g,b by tint factors. Implement shadeTint(c, f, tr,tg,tb).

Simplify: shadeColor then optional tint. Let's implement inline.

Portal sprite: texture 64x64 drawn with green rings; use additive-ish? Just draw with brightness boost and ensure drawn even at distance with glow (fog factor min 0.6). Looks fine.

Weapon draw with display ctx after scaling buffer:

```js
const W = cvs.width, H = cvs.height;
ctx.imageSmoothingEnabled=false;
ctx.drawImage(buf,0,0,W,H);
// gun
const t = performance.now()/1000;
const bobX = Math.sin(state.bob*2)*W*0.012*moveamount...
```
Keep simple: base at bottom center, barrel rectangle, hands, muzzle flash circle when muzzle>0. Use scaled coordinates from H.

Let me write gun:
```js
ctx.save();
ctx.translate(W/2, H);
const s = H/300; // scale
ctx.scale(s,s);
const bob = ...;
// gun body
ctx.fillStyle='#2a2d34';
ctx.beginPath(); // polygon
...
ctx.restore();
```
Draw in a 300-height coordinate space anchored bottom center:
- gun barrel: x -14..14 from y -70 to -150; body wider.
- muzzle flash: radial gradient at (0,-155) radius 30 when firing.
- Arms: rounded rects.

Add slight sway using state.swayX/Y.

Crosshair drawn in DOM (CSS) maybe. Use canvas crosshair drawn at center: simple lines + dot.

Screen damage flash: fill red rgba when flash>0.

Now HUD DOM:
```html
<div id="hud">
  <div class="panel">
    <div class="row"><span>HEALTH</span><span id="hpVal">100</span></div>
    <div class="bar"><div id="hpFill"></div></div>
    <div class="row"><span>ENEMIES</span><span id="enemyVal">4</span></div>
    <div class="row"><span>EXIT</span><span id="exitVal">LOCKED</span></div>
  </div>
  <div id="controls">W/S move · A/D strafe · ←/→ turn · SPACE shoot · R restart</div>
  <div id="msg"></div>
  <div id="centerMsg"></div>
</div>
```

Game over / win overlay with Restart button:
```html
<div id="overlay" class="hidden">
  <h1 id="ovTitle">GAME OVER</h1>
  <p id="ovText"></p>
  <button id="restartBtn">RESTART</button>
</div>
```

Restart button click → resetGame(). Also R key.

Ensure keyboard works when button focused: prevent default for space so button isn't triggered weirdly; after restart, blur the button.

Sound: create AudioContext on first keydown; functions beep noise. Let's implement minimal:
```js
let actx;
function initAudio(){ if(!actx){ try{actx = new (window.AudioContext||window.webkitAudioContext)();}catch(e){} } }
function sfx(type){ if(!actx) return; ...}
```
Shoot: noise buffer + lowpass sweep; hurt: sawtooth down; enemy death: square down; hit ping.

Make a noise buffer once.

Keep code moderate. Now maze generation details and ensure playable.

MAPW=21, MAPH=17 gives cell grid 10x8, corridor count decent. Player start near center-ish? Player at first carved cell (1,1). Exit farthest = maybe corner. Enemies 4 placed at open cells with dist>=5 from start and >=3 from each other and >=1 from exit.

Recursive backtracker with braiding probability 0.18.

Also must ensure the exit cell is open and marked. I'll keep map types; exit stored as {x,y} open cell. When rendering the portal, add to sprite list.

Additional gameplay: maybe display "exit" area floor glowing. Not necessary.

Now BFS:

```js
function computeDist(sx,sy){
 const d = new Int16Array(MAPW*MAPH).fill(-1)? 
```
Int16Array fill(-1) ok.
BFS queue Int32Array length MAPW*MAPH.

Player cell = floor(px), floor(py).

Enemy gradient step: look at 4 neighbors (including diagonals for smoother), pick min d, target center.

To avoid jitter, enemies move toward the center of the target neighbor cell; when close to player (LOS) move directly.

Let's write:

```js
function updateEnemies(dt){
 for(const e of enemies){
   if(!e.alive){ e.deadT += dt; continue; }
   e.hurt = Math.max(0, e.hurt-dt);
   e.cooldown = Math.max(0, e.cooldown-dt);
   const dx = px-e.x, dy=py-e.y;
   const dist = Math.hypot(dx,dy);
   const los = lineOfSight(e.x,e.y,px,py);
   if(los && dist < 1.25){
     if(e.cooldown<=0 && state.mode==='playing'){ attack(e); }
     continue; // hold position & attack
   }
   let tx,ty;
   if(los && dist < 9){ tx=px; ty=py; }
   else {
     // gradient
     const cellX=Math.floor(e.x), cellY=Math.floor(e.y);
     let bestD = distField[cellY*MAPW+cellX], bx=-1, by=-1;
     for(dx2=-1..1,dy2=-1..1) if not both 0 and open cell and distField < bestD ...
     if(bx>=0){ tx = bx+0.5; ty=by+0.5 } else { tx=px; ty=py }
   }
   const mdx = tx-e.x, mdy = ty-e.y; const ml=Math.hypot(mdx,mdy)||1;
   const sp = e.speed*dt;
   let mx = mdx/ml*sp, my = mdy/ml*sp;
   // separation
   for others close: push
   // move with collision
   if(!blockedCircle(e.x+mx, e.y, 0.3)) e.x+=mx;
   if(!blockedCircle(e.x, e.y+my, 0.3)) e.y+=my;
   // keep out of player's space
 }
}
```

Diagonal neighbor choice: allow only if both adjacent orthogonals open to avoid cutting corners — the collision handles it anyway.

attack(e): health -= 8; state.flash = 0.5; e.cooldown = 1.15 + Math.random()*0.4; sfx hurt; if health <=0 die.

lineOfSight: 
```js
function lineOfSight(x0,y0,x1,y1){
 const dx=x1-x0, dy=y1-y0; const d=Math.hypot(dx,dy);
 const steps = Math.ceil(d/0.1);
 for(let i=1;i<steps;i++){
   const t=i/steps;
   if(isWallCell(Math.floor(x0+dx*t), Math.floor(y0+dy*t))) return false;
 }
 return true;
}
```
Note exit cell is open so no issue.

Now textures & sprite art.

Let me now write the whole file.

Sizes: RW=480, RH=300. At full screen maybe upscale blur; set image-rendering: pixelated.

Canvas display: CSS `width:100%; height:100%; object-fit:contain`? For canvas element, use style width 100%, height 100%, and it stretches to container aspect. Better: compute CSS size in JS on resize to preserve aspect and center via flexbox: container flex center, canvas with `max-width:100%; max-height:100%; aspect-ratio:480/300;` Actually set canvas width/height attributes = RW/RH and CSS width/height via JS: fit window. Let's do:

```js
function fit(){
  const s = Math.min(window.innerWidth/RW, window.innerHeight/RH);
  cvs.style.width = (RW*s)+'px';
  cvs.style.height = (RH*s)+'px';
}
```
And canvas attributes width=RW height=RH? But then drawing weapon in low-res would be chunky. That's fine and pixel-art style — draw weapon directly into the low-res buffer? Drawing vector gun into 2D ctx of the buffer then sampling? The buffer is ImageData-based; I'd need to putImageData then draw gun on buf ctx, then scale buf to display. That's easy:

- Render 3D + sprites into pix buffer.
- bctx.putImageData(img,0,0).
- Draw gun, crosshair, flash on bctx (vector, low-res, chunky pixels but pixelated look).
- On display canvas (RW x RH attributes), drawImage(buf,0,0) with imageSmoothingEnabled=false.
- CSS scales.

But HUD is DOM so it's crisp. Good. Actually simplest: single canvas with width=RW, height=RH (480x300) scaled up via CSS with pixelated rendering. Weapon details at 480x300 look fine.

Hmm, but the gun at 480x300 rendered with vectors then scaled maybe blurry if CSS upscaling uses pixelated → chunky but acceptable retro. Good.

Alternatively make canvas 960x600 and render 3D at 480x300 scaled up 2x, drawing gun at full res. Better visuals: display canvas 960x600; drawImage(buf, 0,0,960,600) with smoothing off; then draw gun at 960x600. Pixel walls 2x2 blocks — still retro, gun smooth. Let's do that: internal RW=480, RH=300; canvas 960x600; CSS scales to fit. Good.

Now weapon drawing in 960x600 space.

Let me write texture functions.

```js
const TEX=64;
function makeTex(draw){
  const c=document.createElement('canvas'); c.width=TEX;c.height=TEX;
  const g=c.getContext('2d');
  draw(g,TEX);
  const d=g.getImageData(0,0,TEX,TEX);
  return new Uint32Array(d.data.buffer);
}
```
Note Uint32Array view over data.buffer works.

Brick:

```js
const baseTex = [
 makeTex((g,s)=>{
   g.fillStyle='#3d241c'; g.fillRect(0,0,s,s);
   for(let row=0; row<s/16; row++){
     const off = (row%2)?16:0;
     for(let bx=-32; bx<s; bx+=32){
       const x=bx+off, y=row*16;
       // brick rect with variation
       const l = 22 + Math.random()*10;
       g.fillStyle = `hsl(${14+Math.random()*10}, ${30+Math.random()*15}%, ${l}%)`;
       g.fillRect(x+1,y+1,30,14);
       // highlight top
       g.fillStyle='rgba(255,200,150,0.10)'; g.fillRect(x+1,y+1,30,2);
       g.fillStyle='rgba(0,0,0,0.25)'; g.fillRect(x+1,y+13,30,2);
     }
   }
   for(let i=0;i<600;i++){ g.fillStyle=`rgba(0,0,0,${Math.random()*0.18})`; g.fillRect(Math.random()*s|0, Math.random()*s|0, 1, 1); }
 }),
 ...
];
```

Stone mossy variant for variety.

Metal: base '#3b4652', vertical panels every 16px with highlights, rivets at corners, horizontal scratch lines, red hazard stripes maybe.

Exit locked door: dark steel with big red X bars and rivets.
Exit open: bright green glow frame.

Floor tex: checkered stone 2 colors 32px squares + noise, plus grout lines.

Ceiling: I'll compute per-row gradient in the render loop directly.

Sprite textures: function makeSprite(grid, palette) returns Uint32Array with alpha.

```js
function makeSprite(rows, pal, scale=4){
  const s=TEX;
  const c=document.createElement('canvas'); c.width=s;c.height=s;
  const g=c.getContext('2d');
  const px = s/rows.length;
  rows.forEach((row,y)=>{ [...row].forEach((ch,x)=>{ const col=pal[ch]; if(col){ g.fillStyle=col; g.fillRect(x*px, y*px, px, px);} }); });
  // optional shading...
  const d=g.getImageData(0,0,s,s);
  return new Uint32Array(d.data.buffer);
}
```
Alpha channel is 0 where not drawn (canvas transparent). Good. Colors: getImageData stores premultiplied? Canvas 2D getImageData returns unpremultiplied RGBA. If alpha=0, color bits are 0. Fine.

Enemy grid 16 rows, 16 cols, cell 4px.

Enemy palette:
'#': '#1a1a22' outline
'b': '#4f7a3a' body green
'd': '#2f4a24' darker
'B': '#6d9b4f' light
'r': '#ff3b2f' eyes
'w': '#d8d8c8' teeth
'c': '#cfc7a8' claws

Grid:
```
"................",
"..#..........#..",
"..##........##..",
".#b#........#b#.",
".#bb########bb#.",
"..bbbbbbbbbbbb..",
"..bbbrbbrbbrbb..",
"..bbbbbbbbbbbb..",
"..b#wwwwwwww#b..",
"..bbbbbbbbbbbb..",
".#bb#bbbbbb#bb#.",
"#bb#..bbbb..#bb#",
"#b#...bbbb...#b#",
".#....bbbb....#.",
"......bbbb......",
".....##..##.....",
```
Hmm 16 rows? Count: 16 rows listed. Each must be 16 chars. Let me verify later in code by padding.

Claws maybe bottom. Fine.

Death frames: not necessary; shrink scale.

Exit portal sprite: 64x64, draw green arch/portal: circles.
Use canvas drawing:
```js
const exitTex = makeTex((g,s)=>{
  // transparent? makeTex returns full opaque; portal should be alpha
});
```
Need alpha for portal too. Use makeSprite-like approach: draw on transparent canvas with arcs.

```js
const portalTex = (()=>{ const c=..., g=...;
 // ring
 g.strokeStyle='#5cff9a'; g.lineWidth=4; g.beginPath(); g.arc(32,40,20,0,Math.PI*2); g.stroke();
 ... inner glow gradient
 return new Uint32Array(...)
})();
```
Actually simpler: draw radial gradient ellipse at bottom, and arcs. The sprite is billboard so looks like glowing portal. Draw a few concentric circles.

Then for locked: portal red; open: green. Two textures: portalLocked, portalOpen.

Draw portal with emissive shading: fog factor f = max(0.55, fog(d)) so it glows at distance.

Also add pillar sides? no.

Now render sprites list with type: enemy objects, and portal object {x,y,tex}.

Sorting by dist descending and drawing with zBuffer.

Enemy death animation: keep drawing while deadT<0.4, scaling = 1-deadT/0.4, brightness flash.

Alright, write the code.

Also handle window resize.

Also "visible enemies" requirement — at least some visible from start? Not necessarily; but ensure at least one enemy is visible near start for demo? Verification will sample scene. We could place one enemy in line of sight of start if possible: choose an open cell visible from start (lineOfSight) at distance 3-8 for the first enemy. Try: candidates with LOS from start; if found, place first enemy there. Good for screenshot.

Similarly exit maybe not visible.

Now start position: choose open cell from maze; spawn at center.

Let me write generateLevel:

```js
function generateLevel(){
  // maze
  map = new Uint8Array(MAPW*MAPH).fill(1);
  const visited = new Uint8Array(MAPW*MAPH);
  const stack=[];
  let cx=1, cy=1;
  map[cy*MAPW+cx]=0; visited[cy*MAPW+cx]=1; stack.push([cx,cy]);
  const dirs=[[2,0],[-2,0],[0,2],[0,-2]];
  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&&ny>0&&nx<MAPW-1&&ny<MAPH-1&&!visited[ny*MAPW+nx]) opts.push([nx,ny,x+dx/2,y+dy/2]);
    }
    if(opts.length){
      const [nx,ny,midx,midy]=opts[(Math.random()*opts.length)|0];
      map[midy*MAPW+midx]=0;
      map[ny*MAPW+nx]=0;
      visited[ny*MAPW+nx]=1;
      stack.push([nx,ny]);
    } else stack.pop();
  }
  // braid: remove some walls
  for(let y=1;y<MAPH-1;y++) for(let x=1;x<MAPW-1;x++){
    if(map[y*MAPW+x]===1 && Math.random()<0.16){
      // avoid removing walls that separate two open cells diagonally? fine
      map[y*MAPW+x]=0;
    }
  }
```
Wait MAPW=21, MAPH=17: cells at odd coords 1..19,1..15. Carve loops fine.

But braiding inside thick walls can create large rooms — good for combat.

Then pick start cell: prefer cell near (1,1) open. Actually the maze is fully connected from (1,1), so start at (1,1) center.

Compute BFS distances from start. Exit = cell with max distance (excluding start). Ensure dist>8.

If exit distance small, braiding may have created shortcuts; still reachable. Fine.

Enemies: candidates = open cells with dist >= 4, distance to exit >= 2, and not start. Choose first enemy with LOS from start at distance between 3 and 9 to guarantee visible enemy. Then others random with separation.

Choose up to 4.

Store level config? On restart, reset positions/hp using stored spawn list. Keep same map.

Now write player reset: player.x = start.x+0.5 etc., angle facing open direction: find neighbor open cell and face it. Let's pick angle = direction toward the neighboring open cell with the largest BFS dist? Simply face toward exit? Could face a wall. Better: find open neighbor cell, ang = atan2(ny - y, nx - x).

Store startAngle.

Implementation state.

Let me now write full code carefully.

```js
// ---------- constants
const RW=480, RH=300, TEX=64;
const MAPW=21, MAPH=17;
```

Rendering fog function.

Colors packing little endian check: We'll just use the same packing method for textures and buffer, since textures come from getImageData (Uint32Array reading memory in platform endianness) and we write to buffer the same way. So no need to know endianness as long as I construct colors the same way. But when I shade, I extract r=c&255, g=(c>>8)&255, b=(c>>16)&255 and rebuild the same way — consistent on LE. On BE it'd be wrong but irrelevant. Fine.

Alpha check: for sprite, `if((c>>24)&255 === 0) continue;` On LE, alpha is in top byte. Yes.

Shading function must preserve alpha 255.

```js
function pack(r,g,b){ return 0xFF000000 | (b<<16) | (g<<8) | r; }
```

Tile types stored as wall texture index: use 1..3 walls (brick, stone, metal) and exit door type? The exit is an open cell with portal sprite, so map wall values just 1..3.

Assign wall types randomly: brick mostly, stone, metal. Or based on regions. Random per cell with weights for visual variety.

Now rendering the ceiling: rows above horizon:
color from top dark '#0b0d12' to '#262c3a' at horizon? Add slight per-pixel noise? Keep flat per row. Fine.

Actually ceiling flat bands may look odd but acceptable.

Let me add ceiling light fixtures? skip.

Now let me write the code.

```js
function renderScene(){
  const dirX = Math.cos(player.a), dirY = Math.sin(player.a);
  const planeX = -dirY*0.66, planeY = dirX*0.66;
  const horizon = RH/2;
  // ceiling
  for(let y=0;y<horizon;y++){
    const t = y/horizon;
    // gradient
    const r = 10 + t*18, g=12+t*22, b=18+t*30;
    const col = pack(r|0,g|0,b|0);
    const off=y*RW;
    for(let x=0;x<RW;x++) pix[off+x]=col;
  }
```
RW*150=72k assignments per frame — fine.

Floor:
```js
  const posZ = 0.5*RH;
  const rdx0 = dirX - planeX, rdy0 = dirY - planeY;
  const rdx1 = dirX + planeX, rdy1 = dirY + planeY;
  for(let y=Math.ceil(horizon); y<RH; y++){
    const p = y - horizon;
    const rowDist = posZ/p;
    const stepX = rowDist*(rdx1-rdx0)/RW;
    const stepY = rowDist*(rdy1-rdy0)/RW;
    let fx = player.x + rowDist*rdx0;
    let fy = player.y + rowDist*rdy0;
    const f = Math.max(0.10, 1/(1+rowDist*rowDist*0.045));
    const base = y*RW;
    for(let x=0;x<RW;x++){
      const tx = (fx*TEX) & 63;
      const ty = (fy*TEX) & 63;
      const c = floorTex[(ty<<6)+tx];
      pix[base+x] = pack((c&255)*f, ((c>>8)&255)*f, ((c>>16)&255)*f);
      fx+=stepX; fy+=stepY;
    }
  }
```
pack with floats: `pack(r,g,b)` uses `(b<<16)` converting to int truncates, and `| r` truncates. Fine but need `|0`. pack: `0xFF000000 | ((b|0)<<16) | ((g|0)<<8) | (r|0)`. Note 0xFF000000 is negative int; still works.

Optimization: inline instead of function call pack? Function call 72k/frame fine.

Walls loop with DDA.

Sprites.

Then putImageData, draw gun + flash + crosshair.

Gun drawing at canvas ctx scaled 2x from low res? Let's do display canvas 960x600, draw buffer scaled. Gun drawn in display ctx coordinates.

Let me define display canvas width/height = 960x600 attributes and fit via CSS.

Weapon drawing function drawWeapon(ctx,W,H):

```js
const u = H/600; // scale
const cx = W/2 + swayX, swayY...
ctx.save();
ctx.translate(W/2, H);
ctx.scale(2,2)?? 
```
Let's just use H=600 baseline coordinates directly with scale factor k = H/600 (H is 600 always). So coordinates fixed.

Design gun in 960x600 space:
- Barrel: rect centered x from -20 to 20 (i.e., 460..500), top around y=330..470.
- Body: trapezoid 380..580 at y 430..600.
- Hands: ellipses at 400,520 and 560,520.

Draw with a dark metallic gradient, highlights.

Muzzle flash: when state.muzzle>0, draw star/glow at (W/2, 330) radius 40*muzzle with orange/yellow.

Recoil: translate down by recoil*25 and scale slightly.

Let's write:

```js
function drawWeapon(g,W,H){
  const bobX = state.bobX*18, bobY = Math.abs(state.bobY)*12;
  const recoil = state.recoil;
  g.save();
  g.translate(W/2 + bobX, H + bobY + recoil*30);
  // hands
  g.fillStyle='#c98f6b';
  // left arm
  g.beginPath(); g.moveTo(-230,60); g.lineTo(-150,-40); g.lineTo(-70,10); g.lineTo(-130,120); g.closePath(); g.fill();
  // right arm
  ...
  // gun body
  g.fillStyle='#262a30'; ...
}
```
Coordinates relative to bottom center. Let me design simpler shapes:

Gun central: body polygon points: (-95, 10), (-70,-70), (-22,-150), (22,-150), (70,-70), (95,10) → a wide trapezoid; barrel: rect (-18,-215,36,80) plus muzzle ring.

Hands: two rounded rects at (-120,-30) and (50,-30) size 70x110.

Fine. Add details: dark outlines, top highlight lines, rivets.

Muzzle flash circles at (0,-220).

Also gun bob: state.bob = accumulates with movement.

Crosshair: four short lines around center with gap; dot at center. Draw white with alpha .7 and dark outline.

Damage flash: red vignette overlay when state.flash>0: fillStyle rgba(255,0,0,0.28*flash) fillRect whole.

Also low health pulse red vignette.

HUD updates: health bar width, colors; enemy count; exit status; message.

Center message overlay for events like "EXIT UNLOCKED" for 2.5s.

Game over overlay: show, with title and stats.

Now careful about restart: reset state arrays.

Let me structure code:

```js
// globals
let map, distField, startInfo, exitInfo, enemies, player, state;
function newGame(){ generateLevel(); resetGame(); }
function resetGame(){ ... }
```

Level generation stores: startInfo {x,y,a}, exitInfo {x,y}, enemySpawns [{x,y}].

Restart uses same map & spawns.

Also "R" restart anytime.

Fire input: keydown Space; also mouse click shoot (optional). Add mousedown on canvas → shoot.

Holding space auto-fire? keydown repeat handles; but use key state and continuous fire in update if space held and cooldown ready. Let's do that: keys[' '] true → in update, if fireCooldown<=0 → shoot.

Now writing.

Potential pitfall: bitmap font/DOM overlay sizes. Use CSS with responsive units (vh/rem). Use vmin units for HUD.

CSS design: dark background, white text, red/green accents, monospace font.

Let me write the HTML/CSS.

```css
html,body{margin:0;height:100%;background:#05060a;overflow:hidden;font-family:"Courier New",monospace;color:#dfe6f0;}
#wrap{position:fixed;inset:0;display:flex;align-items:center;justify-content:center;}
canvas{image-rendering:pixelated;image-rendering:crisp-edges;display:block;box-shadow:0 0 60px #000 inset, 0 0 40px rgba(0,0,0,.8);}
#ui{position:fixed;inset:0;pointer-events:none;}
.panel{position:absolute;top:16px;left:16px;...}
```
Use percentage sizes so it scales with the window (not the canvas): acceptable.

HUD panel top-left with health, enemies, exit.

Bottom-left controls.

Center message `#toast` at top center.

Overlay full screen with semi-transparent dark bg, pointer-events auto, hidden class.

Crosshair in canvas.

Let's write JS now in full.

```js
(function(){
'use strict';

const RW=480, RH=300, TW=64;
const MAPW=21, MAPH=17;

const cvs = document.getElementById('view');
const ctx = cvs.getContext('2d');
cvs.width=960; cvs.height=600;

const buf = document.createElement('canvas');
buf.width=RW; buf.height=RH;
const bctx = buf.getContext('2d');
const frame = bctx.createImageData(RW,RH);
const pix = new Uint32Array(frame.data.buffer);
const zBuf = new Float32Array(RW);
```

Fit canvas via resize:

```js
function fit(){
  const s = Math.min(innerWidth/960, innerHeight/600);
  cvs.style.width = (960*s)+'px';
  cvs.style.height = (600*s)+'px';
}
addEventListener('resize', fit); fit();
```
But if scale > 1.5, pixelated upscale. Fine.

Now textures.

I'll write makeTex with drawing callbacks.

Then level gen.

Then input & loop.

Let me write the whole thing in one go, then test with browser tools.

One more consideration: the game must not break if AudioContext unavailable.

Write code:

```js
// ===== texture helpers =====
function canvasOf(w,h){ const c=document.createElement('canvas'); c.width=w;c.height=h; return c; }
function grab(c){ const g=c.getContext('2d'); const d=g.getImageData(0,0,c.width,c.height); return new Uint32Array(d.data.buffer); }
function makeTex(draw){
  const c=canvasOf(TW,TW); const g=c.getContext('2d');
  draw(g,TW);
  return grab(c);
}
```

Wall textures array `WALLTEX = [brick, stone, metal]` with index 1..3 → WALLTEX[t-1].

Random noise helper `rnd(a,b)`.

Brick as above.

Stone:
```js
makeTex((g,s)=>{
  g.fillStyle='#40464d'; g.fillRect(0,0,s,s);
  for(let y=0;y<s;y+=16){
    for(let x=0;x<s;x+=16){
      const v = 34+Math.random()*18;
      g.fillStyle=`hsl(${200+Math.random()*20},${6+Math.random()*8}%,${v}%)`;
      g.fillRect(x+1,y+1,14,14);
    }
  }
  // cracks
  g.strokeStyle='rgba(0,0,0,0.5)'; g.lineWidth=1;
  for(let i=0;i<6;i++){
    g.beginPath();
    let x=Math.random()*s,y=Math.random()*s;
    g.moveTo(x,y);
    for(let j=0;j<4;j++){ x+= (Math.random()-0.5)*10; y+=(Math.random()-0.5)*10; g.lineTo(x,y); }
    g.stroke();
  }
  // moss
  for(let i=0;i<120;i++){ g.fillStyle=`rgba(60,90,45,${Math.random()*0.4})`; g.fillRect(Math.random()*s|0,Math.random()*s|0,2,2); }
}))
```

Metal:
```js
makeTex((g,s)=>{
  g.fillStyle='#2c333d'; g.fillRect(0,0,s,s);
  for(let x=0;x<s;x+=16){
    g.fillStyle = x%32? '#333b46':'#2a313a';
    g.fillRect(x,0,16,s);
    g.fillStyle='rgba(255,255,255,0.07)'; g.fillRect(x,0,2,s);
    g.fillStyle='rgba(0,0,0,0.3)'; g.fillRect(x+14,0,2,s);
    // rivets
    g.fillStyle='#5a6675';
    for(let y=6;y<s;y+=16){ g.beginPath(); g.arc(x+8,y,1.6,0,7); g.fill(); }
    // hazard stripe
  }
  g.fillStyle='rgba(180,60,40,0.5)';
  g.fillRect(0,54,s,6);
  for(let i=0;i<60;i++){ g.fillStyle=`rgba(0,0,0,${Math.random()*0.2})`; g.fillRect(Math.random()*s|0,Math.random()*s|0,1,1); }
})
```

Floor:
```js
const floorTex = makeTex((g,s)=>{
  for(let y=0;y<s;y+=32) for(let x=0;x<s;x+=32){
    const dark=(x/32+y/32)%2;
    const l = dark? 16:21;
    g.fillStyle=`hsl(210,8%,${l}%)`;
    g.fillRect(x,y,32,32);
    g.fillStyle='rgba(255,255,255,0.035)'; g.fillRect(x,y,32,1); g.fillRect(x,y,1,32);
    g.fillStyle='rgba(0,0,0,0.35)'; g.fillRect(x,y+31,32,1); g.fillRect(x+31,y,1,32);
  }
  for(let i=0;i<1200;i++){ g.fillStyle=`rgba(0,0,0,${Math.random()*0.25})`; g.fillRect(Math.random()*s|0,Math.random()*s|0,1,1); }
});
```

Sprite texture helper:

```js
function makePixTex(rows, pal, px){
  const c=canvasOf(TW,TW), g=c.getContext('2d');
  const n = rows.length;
  const cell = TW/n; // rows.length 16 → 4
  for(let y=0;y<n;y++){
    const row=rows[y];
    for(let x=0;x<row.length;x++){
      const col = pal[row[x]];
      if(col){ g.fillStyle=col; g.fillRect(x*cell, y*cell, cell, cell); }
    }
  }
  return grab(c);
}
```

Enemy sprite rows must all be 16 long; I'll write a pad helper.

Portal textures: use canvas paths.

```js
function makePortal(openState){
  const c=canvasOf(TW,TW), g=c.getContext('2d');
  const cx=32, cy=40;
  const col1 = openState? '#6dffa6' : '#ff5a4a';
  const col2 = openState? '#1f8f55' : '#8f211b';
  const grad = g.createRadialGradient(cx,cy,2,cx,cy,28);
  grad.addColorStop(0, openState? 'rgba(160,255,200,0.95)':'rgba(255,160,140,0.85)');
  grad.addColorStop(0.5, openState? 'rgba(60,220,130,0.55)':'rgba(220,60,40,0.45)');
  grad.addColorStop(1, 'rgba(0,0,0,0)');
  g.fillStyle=grad; g.beginPath(); g.ellipse(cx,cy,28,30,0,0,7); g.fill();
  g.strokeStyle=col1; g.lineWidth=3;
  for(let i=0;i<3;i++){ g.globalAlpha=0.5-i*0.12; g.beginPath(); g.ellipse(cx,cy,10+i*6,12+i*7,0,0,7); g.stroke(); }
  g.globalAlpha=1;
  // base
  g.fillStyle=col2; g.fillRect(cx-22,58,44,6);
  return grab(c);
}
```

Sprite drawing function:

```js
function drawSprite(tex, wx, wy, hFrac, emissive){
  const dirX=..., etc from global camera set in renderScene (store in a cam object).
```
Set camera globals: cam = {dirX,dirY,planeX,planeY,invDet}.

I'll pass camera into functions via module-level vars set in renderScene.

```js
function drawSprite(tex, wx, wy, hFrac, fogMin){
  const dx = wx - player.x, dy = wy - player.y;
  const tX = cam.invDet*(cam.dirY*dx - cam.dirX*dy);
  const tY = cam.invDet*(-cam.planeY*dx + cam.planeX*dy);
  if(tY <= 0.12) return;
  const screenX = (RW/2)*(1 + tX/tY);
  const h = (RH/tY)*hFrac;
  const w = h;
  const bottom = RH/2 + (0.5*RH)/tY;
  const top = bottom - h;
  let x0 = Math.floor(screenX - w/2), x1 = Math.ceil(screenX + w/2);
  let y0 = Math.max(0, Math.floor(top)), y1 = Math.min(RH, Math.ceil(bottom));
  if(x1<0||x0>=RW) return;
  const f = Math.max(fogMin||0.12, 1/(1+tY*tY*0.045)) ... 
```
Wait fog based on distance: use tY (depth) approximates distance. Use f = 1/(1+tY*tY*0.03)? For tY=1: 0.97, 3:0.79, 6:0.48. Fine.

Per pixel:

```js
  for(let x=Math.max(0,x0); x<Math.min(RW,x1); x++){
    if(tY >= zBuf[x]) continue;
    const texX = Math.min(63, Math.max(0, ((x - (screenX - w/2)) / w * TW)|0));
    for(let y=y0;y<y1;y++){
      const texY = Math.min(63, Math.max(0, ((y - top)/h*TW)|0));
      const c = tex[(texY<<6)+texX];
      const a = (c>>>24)&255;
      if(!a) continue;
      const r=(c&255)*f, gg=((c>>8)&255)*f, b=((c>>16)&255)*f;
      pix[y*RW+x] = 0xFF000000 | ((b|0)<<16) | ((gg|0)<<8) | (r|0);
    }
  }
}
```
Note for tinting/hurt flash: add optional tint color multiplier. For enemy hurt: pass `tint=1` alternates? Instead of white flash, I'll pre-create a white silhouette texture? Simpler: if e.hurt>0, use f*1.8 and clamp → brighter. Add flag `bright`.

Pass extra param object? Keep signature drawSprite(tex,wx,wy,hFrac,minFog,bright).

Death shrink: hFrac scaled and bottom stays at floor: with hFrac smaller, top moves down — that's a shrink toward feet. Fine.

Alpha blending skipped (all hard pixels). Edges slightly jagged, fine for retro.

Sorting: build list:
```js
const sprites = [];
for(const e of enemies){ if(e.alive) sprites.push({d:dist2, kind:'enemy', e}); else if(e.deadT<0.45) ... }
sprites.push({...exit...});
sprites.sort((a,b)=>b.d-a.d);
```
Then draw.

Portal hFrac = 1.0, draw centered cell; height 1.0 (from floor to ceiling) with texture art that's mostly in middle. Good.

Now DDA wall loop.

```js
function renderScene(){
  const dirX=Math.cos(player.a), dirY=Math.sin(player.a);
  const planeX=-dirY*0.66, planeY=dirX*0.66;
  cam.dirX=dirX; cam.dirY=dirY; cam.planeX=planeX; cam.planeY=planeY;
  cam.invDet = 1/(planeX*dirY - dirX*planeY);
```
invDet: standard det = planeX*dirY - dirX*planeY. With plane=(-dirY*.66, dirX*.66): det = (-dirY*.66)*dirY - dirX*(dirX*.66) = -0.66*(dirY²+dirX²) = -0.66. invDet = -1.515. Standard formulas: transformX = invDet*(dirY*dx - dirX*dy); transformY = invDet*(-planeY*dx + planeX*dy). Check with dx along dir (dx=dirX,dy=dirY): transformY = invDet*(-planeY*dirX + planeX*dirY) = -1.515*( -dirX*.66*dirX + (-dirY*.66)*dirY ) = -1.515*(-0.66) = 1. Good, positive. transformX with dx=dirY (right vector? right = (-dirY, dirX)): take point at player + right: dx=-dirY, dy=dirX: transformX = -1.515*(dirY*(-dirY) - dirX*(dirX)) = -1.515*(-1) = 1.515. Screen x = RW/2*(1+1.515/tY)... if tY=1 that's way off screen; hmm right vector point should map near edge at cameraX=1 → screenX = RW. With tY=1, need transformX=1. So my right vector should be scaled by 0.66? Indeed the plane is 0.66 long, so right edge at distance 1 is at player + plane = dx=-dirY*0.66,... then transformX = 1.515*(0.66*(dirY²+dirX²)) = 1.0. Correct. Good.

DDA:

```js
for(let x=0;x<RW;x++){
  const cameraX = 2*x/RW - 1;
  const rdx = dirX + planeX*cameraX;
  const rdy = dirY + planeY*cameraX;
  let mapX = Math.floor(player.x), mapY=Math.floor(player.y);
  const deltaX = rdx===0?1e30:Math.abs(1/rdx);
  const deltaY = rdy===0?1e30:Math.abs(1/rdy);
  let stepX, stepY, sideDistX, sideDistY;
  if(rdx<0){ stepX=-1; sideDistX=(player.x-mapX)*deltaX; } else { stepX=1; sideDistX=(mapX+1-player.x)*deltaX; }
  if(rdy<0){ stepY=-1; sideDistY=(player.y-mapY)*deltaY; } else { stepY=1; sideDistY=(mapY+1-player.y)*deltaY; }
  let side=0, tile=0, guard=0;
  while(guard++<200){
    if(sideDistX<sideDistY){ sideDistX+=deltaX; mapX+=stepX; side=0; }
    else { sideDistY+=deltaY; mapY+=stepY; side=1; }
    if(mapX<0||mapY<0||mapX>=MAPW||mapY>=MAPH){ tile=2; break; }
    tile = map[mapY*MAPW+mapX];
    if(tile>0) break;
  }
  let perp = side===0 ? (mapX - player.x + (1-stepX)/2)/rdx : (mapY - player.y + (1-stepY)/2)/rdy;
  // avoid negative/zero
  perp = Math.max(0.05, perp);  // hmm if perp negative due to precision; clamp.
  zBuf[x]=perp;
  const lineH = RH/perp;
  let dstart = (RH - lineH)/2, dend=(RH+lineH)/2;
  const texArr = WALLTEX[Math.min(2, tile-1)];
  let wallX = side===0 ? player.y + perp*rdy : player.x + perp*rdx;
  wallX -= Math.floor(wallX);
  let tx = (wallX*TW)|0;
  if((side===0 && rdx>0)||(side===1 && rdy<0)) tx = TW-1-tx;
  const f = Math.max(0.08, 1/(1+perp*perp*0.03)) * (side===1?0.72:1);
  const step = TW/lineH;
  let texPos = (dstart - RH/2 + lineH/2)*step;
  const yStart = Math.max(0, Math.ceil(dstart)), yEnd=Math.min(RH, Math.ceil(dend));
  for(let y=yStart;y<yEnd;y++){
    const ty = (texPos) & 63;
    texPos += step;
    const c = texArr[(ty<<6)+tx];
    pix[y*RW+x] = pack((c&255)*f, ((c>>8)&255)*f, ((c>>16)&255)*f);
  }
  // fill ceiling/floor where wall not covering already done
}
```
Note pix buffer ceiling/floor already filled, so walls just overwrite. Good.

'guard' limit.

Potential issue: `(texPos)&63` when texPos negative due to dstart - RH/2 + lineH/2 = 0 → 0. If lineH > RH, dstart negative, texPos starts ... (dstart - RH/2 + lineH/2) = 0 exactly, so fine. Good.

Texture for outside bounds tile uses WALLTEX[1].

pack with float args—define pack(r,g,b) using `(r|0)`.

Let's define:
```js
function pack(r,g,b){ return 0xFF000000 | ((b|0)<<16) | ((g|0)<<8) | (r|0); }
```

Now game loop:

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

update(dt):
- if mode playing: movement, weapon cooldown, enemies, win check.
- always update bob, flash decay, muzzle, recoil, toast timer.

Movement:
```js
const fwd = (keys['w']?1:0) - (keys['s']?1:0);
const strafe = (keys['d']?1:0) - (keys['a']?1:0);
const turn = (keys['arrowright']?1:0) - (keys['arrowleft']?1:0);
player.a += turn*2.4*dt;
const spd = 2.8*dt * (fwd&&strafe?0.75:1);
let mx=0,my=0;
if(fwd||strafe){
  const dx=Math.cos(player.a)*(fwd) + Math.cos(player.a+Math.PI/2)*strafe...
```
right vector = (-sin, cos)? With a increasing turning right (screen-wise), forward=(cos,sin), right = (cos(a+90°), sin(a+90°)) = (-sin, cos). Check a=0: forward (1,0), right (0,1) which in map coords is downward; on screen, facing +x, "right" should be... if camera plane right is (-sin,cos)*0.66 = (0,0.66) → yes matches. Good.

```js
mx = fX*fwd + rX*strafe; my = fY*fwd + rY*strafe;
const len = Math.hypot(mx,my)||1;
mx = mx/len*spd; my=my/len*spd;
tryMove(mx,my);
state.bob += dt * (fwd||strafe ? 9 : 3);
```
Weapon sway: state.sway = sin(bob)*...

Fire:
```js
state.fireCd -= dt;
if((keys[' ']||state.mouseDown) && state.fireCd<=0 && mode==='playing'){ shoot(); }
```

Enemy update as described.

Win check: if enemiesAlive===0 and dist(player, exit) < 0.85 → mode 'win', show overlay.

Note exit is a cell center; player has radius 0.27 so can get within 0.5? Player can occupy the exit cell entirely since it's open. dist to center < 0.4 when standing in it, so threshold 0.8 works.

HUD updates.

Now BFS dist field recompute:
```js
let distTimer=0;
function updateDist(){
  distField.fill(-1);
  const q = new Int32Array(MAPW*MAPH); let head=0,tail=0;
  const sx=Math.floor(player.x), sy=Math.floor(player.y);
  const si=sy*MAPW+sx;
  if(map[si]!==0) return;
  distField[si]=0; q[tail++]=si;
  while(head<tail){
    const cur=q[head++]; const cx=cur%MAPW, cy=(cur/MAPW)|0;
    const d=distField[cur];
    for(const [dx,dy] of [[1,0],[-1,0],[0,1],[0,-1]]){
      const nx=cx+dx, ny=cy+dy;
      if(nx<0||ny<0||nx>=MAPW||ny>=MAPH) continue;
      const ni=ny*MAPW+nx;
      if(map[ni]!==0 || distField[ni]!==-1) continue;
      distField[ni]=d+1; q[tail++]=ni;
    }
  }
}
```

Enemy gradient:
```js
const cx=Math.floor(e.x), cy=Math.floor(e.y);
const cd = distField[cy*MAPW+cx];
let bx=cx, by=cy, bd=cd;
for(dx..) neighbors open && distField>=0 && <bd → update
```
Careful if cd = -1 (shouldn't happen).

Then target center of best cell.

Separation: 
```js
for(const o of enemies) if(o!==e && Math.hypot(o.x-e.x,o.y-e.y) < 0.7){ ... push }
```
Only alive.

Now shoot implementation:

```js
function shoot(){
  state.fireCd = 0.16; // maybe 0.3
  state.muzzle = 1;
  state.recoil = 1;
  sfxShoot();
  const dirX=Math.cos(player.a), dirY=Math.sin(player.a);
  let best=null, bestT=1e9;
  for(const e of enemies){
    if(!e.alive) continue;
    const dx=e.x-player.x, dy=e.y-player.y;
    const t = dx*dirX+dy*dirY;
    if(t<0.15||t>18) continue;
    const lat = Math.abs(dx*(-dirY)+dy*dirX);
    if(lat > 0.42) continue;
    if(!lineOfSight(player.x,player.y,e.x,e.y)) continue;
    if(t<bestT){ bestT=t; best=e; }
  }
  if(best){ damageEnemy(best, 40); }
}
```
Enemy radius 0.42 is generous, fine. Also add slight vertical aim irrelevant.

damageEnemy: hp -= dmg; hurt=0.15; sfxHit; if hp<=0 → alive=false; deadT=0; state.kills++; toast('ENEMY DOWN'); if all dead → toast('EXIT UNLOCKED') + sfx.

Weapon feedback also screen tiny shake.

Enemy attack:
```js
function enemyAttack(e){
  e.cooldown = 1.1 + Math.random()*0.5;
  state.health -= 7 + Math.floor(Math.random()*6);
  state.hurtFlash = 1;
  sfxHurt();
  if(state.health<=0){ state.health=0; gameOver(); }
}
```
Requirement "Enemies can damage the player under a clear attack rule." — attack when within 1.2 tiles with line of sight, every ~1.2s. Show in controls/help? Add a hint line in HUD: "Enemies attack in melee range with a clear line of sight." Maybe under controls.

Add on-screen text: "Controls: W/S move · A/D strafe · ←/→ turn · SPACE shoot · R restart".

Game over overlay: title "GAME OVER", text "You were slain. Health 0." Restart button.

Win overlay: "ESCAPED" text "You cleared all 4 enemies and reached the exit."

Let me write it all now.

Also need to make sure restart resets killer state: player position/angle, health, enemies, kills, cooldowns, keys maybe.

State object:
```js
function resetGame(){
  player = {x:level.start.x+0.5, y:level.start.y+0.5, a:level.start.a};
  state = {mode:'playing', health:100, kills:0, hurtFlash:0, muzzle:0, recoil:0, fireCd:0, bob:0, toastT:0, toastText:''};
  enemies = level.enemySpawns.map(s=>({x:s.x+0.5,y:s.y+0.5, hp:100, alive:true, cooldown:0.6, hurt:0, deadT:0, speed:1.15+Math.random()*0.3, tint:...}));
  ...
}
```
Note enemy count 4 stored.

HUD enemy count: enemies.filter(alive).length.

When drawing, exit portal uses open state based on kills.

We should also make exit cell marked on the floor? Add sprite always. Locked red, open green.

Fine.

Now DOM references and updateHUD called each frame.

Toast for events: set state.toastText, toastT=2.5. HUD center message shows it.

Message for locked exit when player near: "EXIT LOCKED — X ENEMIES REMAIN" maybe in HUD exit status line always shows LOCKED n / OPEN.

Let me write the code now for real. I'll write the file with the write tool.

Also add a start cover? No, immediate play.

Edge case: generateLevel may place exit too near start. Farthest cell guarantees decent distance.

Enemy spawn visibility from start: first enemy with LOS. Since maze corridors, LOS from start likely only within corridor. If no LOS candidates, just pick farthest.

Let me write code.

```js
function generateLevel(){
  map = new Uint8Array(MAPW*MAPH).fill(1);
  const visited = new Uint8Array(MAPW*MAPH);
  const stack = [[1,1]];
  map[1*MAPW+1]=0; visited[1*MAPW+1]=1;
  while(stack.length){
    const [x,y]=stack[stack.length-1];
    const opts=[];
    if(x-2>0 && !visited[y*MAPW+x-2]) opts.push([x-2,y,x-1,y]);
    if(x+2<MAPW-1 && !visited[y*MAPW+x+2]) opts.push([x+2,y,x+1,y]);
    if(y-2>0 && !visited[(y-2)*MAPW+x]) opts.push([x,y-2,x,y-1]);
    if(y+2<MAPH-1 && !visited[(y+2)*MAPW+x]) opts.push([x,y+2,x,y+1]);
    ...
  }
```
Careful bounds: cells at x odd up to MAPW-2=19. Condition x+2<MAPW-1 means x+2<20 → x<=17 → target 19. Good.

Then braid:
```js
for(let y=1;y<MAPH-1;y++) for(let x=1;x<MAPW-1;x++){
  const i=y*MAPW+x;
  if(map[i]===1 && Math.random()<0.18) map[i]=0;
}
```
This may remove walls making bigger rooms. Also assign wall texture variants after (based on random).

Then BFS from (1,1) to find farthest:
```js
const dist = new Int16Array(MAPW*MAPH).fill(-1);
... BFS
let ex=1,ey=1,ed=-1;
for cells open: if dist>ed ...
```
Then set exit cell = farthest.

Enemy spawn selection:
```js
const candidates=[];
for cells open with dist>=5 and not exit and not start...
shuffle; pick with min separation 3 and not too close (>=2) to exit.
```
First enemy: find cell with LOS from start center and distance between 3 and 10 and dist>=3. Try candidates sorted random.

Also mark enemy spawn cell for visibility: fine.

Wall type assignment: for map cell 1 → 1 + (random<0.6?0: random<0.5?1:2). Let me do: r<0.65 brick(1), r<0.85 stone(2), else metal(3). Ensure variety.

Also make exit area slightly nicer? skip.

Let's also add a light vignette? CSS.

Now write.

For the loop and DOM, careful with ids.

Also must handle the restart button pointer-events.

Let me write the file.

Potential issue with `keys` using e.key.toLowerCase(); Space is ' '. Arrow keys 'arrowleft'/'arrowright'.

Prevent default for arrows, space, wasd.

Blur on window loses keys → clear keys.

Now write the code.

Additionally: if the player is dead, stop movement but keep rendering.

Let's write everything.

Audio:

```js
let AC=null, noiseBuf=null;
function audioInit(){
  if(AC) return;
  try{
    AC=new (window.AudioContext||window.webkitAudioContext)();
    const len=AC.sampleRate*0.5;
    noiseBuf=AC.createBuffer(1,len,AC.sampleRate);
    const d=noiseBuf.getChannelData(0);
    for(let i=0;i<len;i++) d[i]=Math.random()*2-1;
  }catch(e){ AC=null; }
}
function sfxShoot(){
  if(!AC) return;
  const t=AC.currentTime;
  const src=AC.createBufferSource(); src.buffer=noiseBuf;
  const g=AC.createGain(); g.gain.setValueAtTime(0.5,t); g.gain.exponentialRampToValueAtTime(0.001,t+0.18);
  const f=AC.createBiquadFilter(); f.type='lowpass'; f.frequency.setValueAtTime(2400,t); f.frequency.exponentialRampToValueAtTime(300,t+0.18);
  src.connect(f); f.connect(g); g.connect(AC.destination); src.start(t); src.stop(t+0.2);
  const o=AC.createOscillator(); o.type='square'; o.frequency.setValueAtTime(160,t); o.frequency.exponentialRampToValueAtTime(60,t+0.1);
  const g2=AC.createGain(); g2.gain.setValueAtTime(0.18,t); g2.gain.exponentialRampToValueAtTime(0.001,t+0.12);
  o.connect(g2); g2.connect(AC.destination); o.start(t); o.stop(t+0.13);
}
```
Others simple.

Keep it short.

Now writing index.html.

Careful with template literals inside the script inside HTML — fine.

Let me write the full file now mentally then type.

Also note: In the floor casting loop, `fx*TW & 63`: JS bitwise on float converts via ToInt32, which truncates toward zero; product may exceed 2^31 for large coords? fx is small (<21), fine.

Sprite texture sampling uses `(texY<<6)+texX` fine.

For performance, precompute fog per row for floor. Already do.

Also for sprites, limit loop bounds.

Now, weapon and muzzle flash rendering onto the 960x600 display ctx:

```js
function drawWeapon(g,W,H){
  const swayX = Math.sin(state.bob)*10;
  const swayY = Math.abs(Math.cos(state.bob))*7;
  const rec = state.recoil;
  g.save();
  g.translate(W/2 + swayX, H + swayY + rec*34);
  // scale based on H (600) - static
  // arms
  g.fillStyle='#a9714f'; // arms
  g.beginPath();
  g.moveTo(-250, 90); g.lineTo(-120, -30); g.lineTo(-40, 20); g.lineTo(-140, 140); g.closePath(); g.fill();
  g.beginPath();
  g.moveTo(250, 90); g.lineTo(120, -30); g.lineTo(40, 20); g.lineTo(140, 140); g.closePath(); g.fill();
  // hands
  g.fillStyle='#c98a63';
  roundRect...
```
Use ellipses for hands: g.beginPath(); g.ellipse(-70,-10,42,55,0,0,7); fill.

Gun:
```js
  g.fillStyle='#1b1e25';
  g.beginPath();
  g.moveTo(-70, 30); g.lineTo(-52,-90); g.lineTo(-24,-190); g.lineTo(24,-190); g.lineTo(52,-90); g.lineTo(70,30); g.closePath(); g.fill();
  // barrel
  g.fillStyle='#2b303a';
  g.fillRect(-16,-250,32,70);
  g.fillStyle='#3a414f'; g.fillRect(-16,-250,8,70);
  g.fillStyle='#0c0d10'; g.fillRect(-11,-252,22,8);
  // highlights
  g.strokeStyle='rgba(160,190,220,0.25)'; g.lineWidth=3;
  g.beginPath(); g.moveTo(-20,-180); g.lineTo(-38,-80); g.stroke();
  // glowing sight dot
  g.fillStyle='#ff9a3c';
  g.beginPath(); g.arc(0,-196,5,0,7); g.fill();
```
Muzzle flash:
```js
  if(rec>0.15){
    const a=rec;
    g.save(); g.globalCompositeOperation='lighter';
    const grd=g.createRadialGradient(0,-255,0,0,-255,90*a);
    grd.addColorStop(0,'rgba(255,240,180,'+(0.9*a)+')');
    grd.addColorStop(0.4,'rgba(255,150,40,'+(0.6*a)+')');
    grd.addColorStop(1,'rgba(255,80,0,0)');
    g.fillStyle=grd; g.beginPath(); g.arc(0,-255,90*a,0,7); g.fill();
    g.restore();
  }
  g.restore();
```
Note translate uses H (600) so the gun occupies bottom.

Crosshair drawn separately at center of the display canvas (W/2,H/2).

Hurt flash red overlay + low-health vignette.

PutImageData then drawImage scaled:

```js
bctx.putImageData(frame,0,0);
// weapon onto low-res buffer? No — draw buffer to display, then weapon on display.
ctx.imageSmoothingEnabled=false;
ctx.drawImage(buf,0,0,960,600);
ctx.save();
// vignette/damage flash
drawWeapon(ctx,960,600);
drawCrosshair(ctx,960,600);
ctx.restore();
```

Hmm crosshair should be added after the 3D scene; fine.

The buffer drawing at 2x.

Let me also add a dark vignette gradient overlay each frame? CSS box-shadow inset on canvas: `box-shadow: inset 0 0 200px rgba(0,0,0,0.85)` — works with canvas? box-shadow inset renders over the canvas background... yes inset shadow draws over content. Good.

HUD.

Now write the final code.

One more: initial "controls" overlay. Always visible bottom-left with the key list.

Also add a title/name top-right maybe.

Let me now write the file.

I need to double check the enemy sprite rows are 16 chars each and 16 rows. Let me carefully craft strings of exactly 16 chars.

Row template indices 0..15.

1: "................" (16)
2: "..#..........#.." → 2 dots + '#'(3) + 10 dots (13) + '#'(14) + 2 dots (16). count: 2+1+10+1+2 = 16 ✓
3: "..##........##.." → 2+2+8+2+2=16 ✓
4: ".#b#........#b#." → 1+3+8+3+1=16 ✓
5: ".#bb########bb#." → 1+1+2+8+2+1+1 = 16? ".#bb########bb#." length: . # b b # # # # # # # # b b # . = 16 ✓ (2 b + 8 # + 2 b)
6: "..bbbbbbbbbbbb.." → 2+12+2=16 ✓
7: "..bbbrbbrbbrbb.." → 2 + "bbbrbbrbbrbb"(12) + 2 = 16 ✓
8: "..bbbbbbbbbbbb.." ✓
9: "..b#wwwwwwww#b.." → 2 + b # wwwwwwww(8) # b (12) + 2 = 16 ✓
10: "..bbbbbbbbbbbb.." ✓
11: ".#bb#bbbbbb#bb#." → 1+1+2+1+6+1+2+1+1 = 16 ✓ ("." "#" "bb" "#" "bbbbbb" "#" "bb" "#" ".")
12: "#bb#..bbbb..#bb#" → 1+2+1+2+4+2+1+2+1 = 16 ✓
13: "#b#...bbbb...#b#" → 1+1+1+3+4+3+1+1+1 = 16 ✓
14: ".#....bbbb....#." → 1+1+4+4+4+1+1 = 16 ✓
15: "......bbbb......" → 6+4+6=16 ✓
16: ".....##..##....." → 5+2+2+2+5=16 ✓

Palette:
'.' transparent
'#' '#141419'
'b' '#5b8a3f'
'w' '#d9d9c4'

Add shading: makePixTex could add some shading by darkening bottom rows? Skip.

Maybe add claws? fine.

Now draw the enemy sprite as billboard with hFrac 0.85 so it doesn't touch ceiling.

Let's write everything now.

Also handle the case where the maze generation makes the start cell enclosed by walls? Start (1,1) is carved and connects. Good.

Also, braiding may remove walls around boundary? Loop restricted 1..MAPW-2 so no boundary removal. Good.

Enemy movement collision radius 0.28, but corridor 1 wide, fine.

Now, enemies could get stuck if distField is -1 for their cell (shouldn't).

Write the code.

Additional check: player's start cell and enemy positions must not overlap the exit; fine.

Now the actual write.

I'll write the file with careful syntax. Then run in browser and inspect console.

Let me write the JS in an organized manner.

Also note distField is global typed array allocated in generateLevel.

Code for spawn selection:

```js
function pickSpawns(){
  const open=[];
  for(let y=1;y<MAPH-1;y++)for(let x=1;x<MAPW-1;x++) if(map[y*MAPW+x]===0) open.push({x,y});
  const dStart = bfs(start.x,start.y);
  const dExit = bfs(exit.x,exit.y);
  const spawns=[];
  // try visible
  const vis = open.filter(c=>{
    const d = dStart[c.y*MAPW+c.x];
    return d>=4 && d<=11 && c.x!==start.x || ... 
  });
```
Hmm need LOS check from start center to candidate center. lineOfSight with the actual player position (start+0.5).

```js
  const shuff = open.slice().sort(()=>Math.random()-0.5);
  for(const c of shuff){
    if(spawns.length>=4) break;
    const ds = dStart[c.y*MAPW+c.x];
    if(ds<4) continue;
    if(c.x===exit.x&&c.y===exit.y) continue;
    if(dExit && dExit[c.y*MAPW+c.x]<2) continue;
    let ok=true;
    for(const s of spawns){ if(Math.hypot(s.x-c.x,s.y-c.y)<4){ ok=false;break; } }
    if(!ok) continue;
    spawns.push({x:c.x,y:c.y});
  }
```
But we want the first to be visible: reorder candidates so visible ones first:
```js
  const visible = shuff.filter(c=>lineOfSight(start.x+0.5,start.y+0.5,c.x+0.5,c.y+0.5) && dStart[...]>=3 && dStart[...]<=9);
```
Then spawns push from visible first (one) then rest.

If fewer than 4 spawns found, relax spacing. Add fallback loop ignoring spacing.

Ensure at least 3 enemies required. With 21x17 maze, plenty of cells.

Let me write BFS helper returning Int16Array:

```js
function bfs(sx,sy){
  const d = new Int16Array(MAPW*MAPH).fill(-1);
  const q = new Int32Array(MAPW*MAPH); let h=0,t=0;
  const si=sy*MAPW+sx;
  if(map[si]!==0) return d;
  d[si]=0; q[t++]=si;
  while(h<t){
    const cur=q[h++]; const cx=cur%MAPW, cy=(cur/MAPW)|0;
    const base=d[cur];
    if(cx>0){...}
```
Write straightforward neighbor loop.

Farthest cell: iterate.

Start angle: find open neighbor of start, prefer the one with greater dStart. 
```js
let bestN=null,bestD=-1;
for(...4 neighbors) if open && dStart[ni]>bestD ...
start.a = Math.atan2(bestN.y-start.y, bestN.x-start.x);
```
If none (impossible), angle 0.

Okay, write it.

HUD updates: use textContent.

Now write file.

Also add `document.getElementById('restartBtn').onclick = ()=>{ newRun(); }` where newRun resets same level. Should restart also regenerate? Keep same level for deterministic "restore".

I need to be careful that `enemies` global is reassigned in resetGame while render uses it.

Let me write.

Another detail: canvas click to focus? Keyboard listeners on window; fine.

Preventing scrolling with Space: preventDefault when key in set.

Now writing the final file.

For the overlay hidden class toggling.

Let me now produce the code.

Also, guard `requestAnimationFrame` first timestamp.

Let me draft in the write call.

I'll include a small on-screen hint box "Enemies attack in melee range (with line of sight)" — maybe not needed, but helpful. Add to controls text.

Writing now.

After writing, run browser, inspect console, screenshot, test movement/collision/shoot/restart via JS evaluation? The browser tool only has click/type/key/screenshot, no JS eval. Hmm, `action: "inspect"` returns DOM/console. There's no evaluate. So testing must be via key events and screenshots. I can add debug hooks to window and read via inspect? Inspect likely gives DOM text and console. I can console.log state info periodically (or on demand) and read console via inspect. Let's add a `window.__debug` object plus a console.log every ~2s? Too noisy. Instead log initial level info once (start, exit, enemies, visible cells) and expose functions; then use type action? Typing goes to focused element—keydown listeners on window will get them. I can press keys to move, then screenshot.

For verifying state, I can update a debug line in HUD? Actually HUD shows health, enemies. For position, not necessary. I could add a tiny hidden debug element updated with player coords and mode, then inspect DOM. Nice: `<div id="dbg" style="display:none"></div>` updated each frame with JSON. Inspect action may show it. Let's do that — helps verify collision and movement numerically.

Also add console.log of level generation results.

Let's write.

For collision verification, I can log position changes.

Time budget 15 min; be efficient.

Now, actual code writing.

I'll write the full file now.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>MAZE OF THE DAMNED — Raycaster</title>
<style>
  html,body{margin:0;padding:0;height:100%;background:#04060a;overflow:hidden;
    font-family:"Courier New",Courier,monospace;color:#e6ecf5;user-select:none;}
  #stage{position:fixed;inset:0;display:flex;align-items:center;justify-content:center;}
  canvas{image-rendering:pixelated;display:block;background:#000;
    box-shadow:inset 0 0 200px rgba(0,0,0,.9);}
  ...
```
box-shadow inset on canvas may not show because canvas paints over? Inset shadow paints above background but canvas content is the element's content painted... Actually box-shadow inset is painted above the background but below the content? Per spec, inner shadow is painted above background and below border/content? Hmm, inner shadows are drawn over the background, but canvas content counts as content, drawn above. So inset shadow won't be visible. Instead draw a vignette on canvas or use an overlay div with radial-gradient and pointer-events none. Use overlay div vignette.

```html
<div id="stage"><canvas id="view"></canvas></div>
<div id="vig"></div>
```
#vig{position:fixed;inset:0;pointer-events:none;background:radial-gradient(ellipse at center, rgba(0,0,0,0) 45%, rgba(0,0,0,0.75) 100%);mix-blend-mode:multiply;} Hmm multiply darkens edges. Simple rgba gradient is fine.

HUD elements:
```html
<div id="hud">
  <div id="stats" class="panel">
    <div class="label">HEALTH</div>
    <div class="barwrap"><div id="hpBar"></div></div>
    <div class="line"><span>HEALTH</span><span id="hpVal">100</span></div> ...
```
Simplify:
```html
<div id="stats" class="panel">
  <div class="row"><span class="k">HEALTH</span><span id="hpVal" class="v">100</span></div>
  <div class="barwrap"><div id="hpBar"></div></div>
  <div class="row"><span class="k">ENEMIES</span><span id="enVal" class="v">4</span></div>
  <div class="row"><span class="k">EXIT</span><span id="exitVal" class="v locked">LOCKED</span></div>
</div>
<div id="toast"></div>
<div id="controls">...</div>
<div id="overlay" class="hidden">
  <div class="ovbox">
    <h1 id="ovTitle"></h1>
    <p id="ovText"></p>
    <button id="restartBtn">RESTART</button>
    <p class="hint">or press R</p>
  </div>
</div>
```

CSS with clamp font sizes.

Now write.

For the bar color change low health via style.

Let me write full code finally in the tool call. I need to be careful about syntax errors; I'll test.

Let me write out the JS fully:

```js
(function(){
'use strict';
const RW=480, RH=300, TW=64;
const MAPW=21, MAPH=17;
const cvs=document.getElementById('view');
cvs.width=RW*2; cvs.height=RH*2;
const ctx=cvs.getContext('2d');
const buf=document.createElement('canvas'); buf.width=RW; buf.height=RH;
const bctx=buf.getContext('2d');
const frame=bctx.createImageData(RW,RH);
const pix=new Uint32Array(frame.data.buffer);
const zBuf=new Float32Array(RW);
const cam={dirX:1,dirY:0,planeX:0,planeY:0.66,invDet:-1.51};
```

Wait invDet compute each frame.

fit()...

Textures...

Let me write in code now and test.

Potential edge: `new Uint8Array(MAPW*MAPH).fill(1)` good.

Now BFS written.

Then resetGame, etc.

Time to write.

For the HUD enemy count: alive count.

Enemy spawn visible check: use lineOfSight which uses isWallCell; map must be generated.

Let me write.

Also note start at (1,1) always; farthest cell likely a corner.

Now the code.

```js
/* ---------- textures ---------- */
const rnd=(a,b)=>a+Math.random()*(b-a);
function cv(w,h){const c=document.createElement('canvas');c.width=w;c.height=h;return c;}
function grab(c){const d=c.getContext('2d').getImageData(0,0,c.width,c.height);return new Uint32Array(d.data.buffer);}
function makeTex(fn){const c=cv(TW,TW);fn(c.getContext('2d'),TW);return grab(c);}
```

Brick:
```js
const TEX_BRICK=makeTex((g,s)=>{
  g.fillStyle='#2a1a14'; g.fillRect(0,0,s,s);
  for(let r=0;r<4;r++){
    const off=r%2? 8:0;
    for(let bx=-16;bx<s+16;bx+=16){
      const x=bx+off, y=r*16;
      const l=rnd(18,30);
      g.fillStyle=`hsl(${rnd(10,20)},${rnd(30,45)}%,${l}%)`;
      g.fillRect(x+1,y+1,14,14);
      g.fillStyle='rgba(255,190,140,0.12)'; g.fillRect(x+1,y+1,14,2);
      g.fillStyle='rgba(0,0,0,0.35)'; g.fillRect(x+1,y+13,14,2);
    }
  }
  for(let i=0;i<800;i++){g.fillStyle=`rgba(0,0,0,${Math.random()*0.22})`;g.fillRect(Math.random()*s|0,Math.random()*s|0,1,1);}
  for(let i=0;i<300;i++){g.fillStyle=`rgba(255,220,180,${Math.random()*0.05})`;g.fillRect(Math.random()*s|0,Math.random()*s|0,1,1);}
});
```
Brick size 16x16 cells with 14x14 bricks: pattern repeats every 16 in x; offset 8. Fine.

Stone:
```js
const TEX_STONE=makeTex((g,s)=>{
  g.fillStyle='#2b2f35'; g.fillRect(0,0,s,s);
  for(let y=0;y<s;y+=16)for(let x=0;x<s;x+=16){
    g.fillStyle=`hsl(${rnd(200,220)},${rnd(4,10)}%,${rnd(22,34)}%)`;
    g.fillRect(x+1,y+1,14,14);
    g.fillStyle='rgba(255,255,255,0.06)'; g.fillRect(x+1,y+1,14,1);
    g.fillStyle='rgba(0,0,0,0.3)'; g.fillRect(x+1,y+14,14,1);
  }
  // moss patches
  for(let i=0;i<5;i++){...}
  ...
});
```

Metal as described.

Spawn etc.

Given the 15 min budget, keep moving. Write file now.

I'll write the code with reasonable care and then test.

Regarding the `drawSprite` fog for portal: pass minFog 0.6 for emissive glow.

Enemy hit flash: pass a flag to brighten: f *= (e.hurt>0?1.9:1). Clamp 1. Actually f can exceed 1 → colors clipped, looks white-ish flash. Use Math.min(1.2, f*1.9) but color channels clamp at 255 anyway due to bitwise? Values >255 when |0 then packed into bytes overflow into other channels. Must clamp: helper `cl(v)`.

Implement shade in sprite loop with clamping:
```js
let r=..., gg=..., b=...;
if(r>255)r=255; ...
```
Do it.

For walls, f max 1 (side factor ≤1), fine.

Floor f max 1.

Now write.

Also state.bob increments only when moving.

Camera shake when hurt: add small random offset to player.a? That would change aim; do screen shake by offsetting horizon? Skip.

Let me write.

One more requirement: "visible enemies" — ensure the first enemy has LOS from start so the initial screenshot shows at least one enemy (if within FOV). LOS doesn't guarantee within FOV, but facing the corridor direction helps. Set start angle facing the first visible enemy? That could face a wall if... no, LOS guarantees open corridor toward it. Set start.a = atan2(enemyY - startY, enemyX - startX) if visible enemy exists. That guarantees a visible enemy at start. 

But then movement test W moves toward enemy; fine.

Do that after spawns selection.

Now writing.

Let me think about the wall texture index mapping: map values 1,2,3. WALLTEX[tile-1]. If tile out of range (shouldn't), clamp.

Write now.

Also for the DDA, the starting map cell might be a wall if the player gets stuck inside; guard.

Let me finalize shoot cooldown 0.22s, damage 34 → 3 shots (100hp). Hit feedback.

Enemy health 100.

Player speed 2.6.

Now write the file.

I'll include debug element.

Let me write it.

Also update HUD on mode change and toast.

For the overlay button, pointer-events auto.

Ok writing now for real.

Code for updateHUD:

```js
function updateHUD(){
  const hp=Math.max(0,Math.round(state.health));
  hpVal.textContent=hp;
  hpBar.style.width=hp+'%';
  hpBar.style.background = hp>60? 'linear-gradient(90deg,#39b54a,#7dff8a)' : hp>30? 'linear-gradient(90deg,#c9a227,#ffe066)' : 'linear-gradient(90deg,#a11d1d,#ff5a4a)';
  const alive=enemies.filter(e=>e.alive).length;
  enVal.textContent=alive;
  const unlocked=alive===0;
  exitVal.textContent=unlocked?'OPEN':'LOCKED';
  exitVal.className='v '+(unlocked?'open':'locked');
  toast.textContent=state.toastT>0?state.toastText:'';
  toast.style.opacity = state.toastT>0? Math.min(1,state.toastT*1.5):0;
}
```

Toast element id 'toast' — declare var names carefully (toast conflicts with function name? use elToast).

Also display the exit arrow? no.

Now writing the file. I'll be verbose but correct.

After writing, test with browser.

Let me also double-check sprite transform formulas in drawSprite with cam.invDet computed as 1/(planeX*dirY - dirX*planeY). With planeX=-sin*0.66, planeY=cos*0.66, dirX=cos, dirY=sin:
det = (-sin*.66)(sin) - cos*(cos*.66) = -.66. invDet = -1.515.
transformY for point straight ahead (dx=dirX*d, dy=dirY*d):
= invDet * (-planeY*dx + planeX*dy) = -1.515*( -cos*.66*cos*d + (-sin*.66)*sin*d ) = -1.515*(-0.66*d) = d. ✓
transformX for point at right (dx = planeX*d? right = -sin, cos scaled .66): take dx=-sin*d, dy=cos*d:
= invDet*(dirY*dx - dirX*dy) = -1.515*( sin*(-sin d) - cos*(cos d) ) = -1.515*(-d) = 1.515d. Hmm with transformY = d? For point offset by right vector (unscaled by .66 but by 1), result transformX/transformY = 1.515, screenX = RW/2*(1+1.515) → offscreen; but the point at lateral distance 1 is at the edge at distance d where FOV half-width = 0.66*d. Right, lateral 1 > 0.66*d for d=1, so at screen edge when d=1.515. Correct.

ScreenX = RW/2*(1 + tX/tY). With plane-based camera this is standard. ✓

Now writing.

Sprite left/right width: for a sprite of world height hFrac and square texture, world width = hFrac (square). Then screen width = RH/tY*hFrac = same as h. Fine.

Enemy sprite center y: with hFrac=0.85, feet at floor. Good.

Portal: hFrac=1.0, bottom at floor, top at ceiling. Good.

Death animation: scale = max(0.03, 1 - deadT/0.45), and y position maybe. Fine.

Now code.

I also want the "hit" feedback on crosshair (red X) briefly; skip.

Final: write file.

One concern: `new Uint32Array(d.data.buffer)` — getImageData data buffer length is w*h*4, so Uint32Array length w*h. Good.

Let me write.

I'll be careful about variable name collisions: `exit` is a keyword-ish (not reserved but avoid). Use `exitCell`.

Now writing everything.

For the message when shooting enemy behind wall: nothing happens — correct per requirement.

For LOS, the function uses map wall check, and enemy positions not exactly at cell centers; sampling step 0.08.

Time to write the file.

Let me write the file.

Now test in browser.

The scene looks good. But the enemy at (12,1) should be visible (LOS). The start is at (1,1) and enemy at (12,1) is 11 tiles away down the corridor, but fog is very dark. I see something faint at the center. Fog might be too dark at distance; the enemy is barely visible. Let's increase fog brightness and maybe make enemy visible near start closer. Also the gun body is drawn but arms shapes look odd (two orange blobs at bottom). Acceptable but could improve slightly.

Concerns:
1. Fog too strong: at 11 tiles, f = 1/(1+121*0.03)=0.216 → enemy visible faintly. Portal too. Level might be too dark overall. Let's brighten: fog 1/(1+d*d*0.02) maybe, min 0.14. Also distance shading of walls.

2. Enemy at (12,1) — actually with fog 0.2 it's dim but visible. To make gameplay clearer, spawn first enemy closer (distance 4-7). The visible filter allows d between 4 and 12 but shuffled selection picked 12 away. Change visible filter to d between 3 and 8 and pick nearest.

3. The ceiling is fairly plain; fine.

4. The gun is quite small; could scale up but acceptable. Let me make the weapon larger for more presence. Increase body width maybe by using scale factor 1.3 for the weapon drawing. Also arms look like two orange petals — acceptable retro.

Let me check the player facing angle: start a=0 facing +x, enemy at (12,1) down the corridor. That's the visible spot. Good.

Let's brighten lighting a bit and closer visible enemy. Also increase enemy sprite contrast (bright green body should show).

Also check collision and shooting by moving. Let me test keys.

First tweak fog:
- Wall: f = max(0.10, 1/(1+perp*perp*0.018)) → d=5:0.69, d=10:0.36.
- Floor: 0.03.
- Sprite: 0.022.

And make the first visible enemy prefer nearest.

Let me also consider the enemy at 11 tiles may not be clearly visible; with brighter fog 1/(1+121*0.022)=0.27, still dim. Prefer distance ≤7.

Let me update the level generation visible filter to d>=3 && d<=8, sort by distance ascending.

Then screenshot again.

Update visible filter to distance 3..8 and nearest-first, and increase brightness slightly. Also make sure trySpawn's d>=4 check doesn't reject visible at d=3; change to d>=3.

Also improve lighting.

The player faces a wall (angle 0.825, enemy at 13,14 apparently not visible? Hmm spawns[0] = (13,14) which presumably was the "visible" one? Its BFS distance might be small due to braiding but LOS from start. Facing atan2(13.5-1.5, 13.5-1.5)? angle = atan2(12.5,12.5)? Wait spawns[0] is 13,14 and start 1,1: atan2(13,12)=0.825. Yes facing diagonally—wall very close. So the "visible" filter included a cell with LOS through a diagonal gap? Actually it's facing a wall because the enemy is behind a corner—LOS sampling might pass between two diagonally adjacent wall cells (a corner). That's the classic diagonal LOS leak: line crossing exactly at the corner cell check. Actually with floor at sample points, the segment from (1.5,1.5) to (13.5,14.5) passes through walls... Something off. Wait, lineOfSight from (1.5,1.5) to (13.5,14.5) — should be caught unless map open along that diagonal line. The screenshot shows a wall within 2 tiles straight ahead. Hmm but the enemy supposedly is in view.

Unless the visible[0] spawn failed trySpawn (e.g., dExit<2 or spacing) and spawns[0] is from the general list, and the re-aim still happened since d0 computed from spawns[0] = (13,14) with d0>=4? Requirement in code: if d0>=4 aim at it. dStart at (13,14) is probably large (like 20) so aim applies even though not visible. That's the bug: aiming at an arbitrary first spawn, not necessarily visible.

Fix: only aim at a spawn that has LOS from start. Better: after spawns selection, find any spawn with LOS and aim at the closest one; if none, keep the corridor-facing angle.

Also the wall texture looks quite dark/flat and brick pattern shows huge bricks at close range — bricks are 14px on 64 texture → fine at distance, close-up huge. That's normal.

Brightness improved.

Let me fix aiming. Also, the enemy at (13,14) with dist from start? Doesn't matter.

Additionally since the first visible cell wasn't accepted, we should ensure the visible spawn passes trySpawn criteria: if it fails, no visible enemy at start. The visible filter cells are open with dStart>=3, and spacing check only matters for later. dExit may be <2 for those near exit. Fine; then at least aim at any visible spawn.

Update the aim block:

```js
if (spawns.length){
  let aimed = null, aimD = Infinity;
  for (const s of spawns) {
    const d0 = dStart[s.y*MAPW+s.x];
    if (d0 >= 3 && d0 < aimD && lineOfSight(start.x+0.5,start.y+0.5,s.x+0.5,s.y+0.5)) { aimed = s; aimD = d0; }
  }
  if (aimed) start.a = Math.atan2(...);
}
```

Also I want a visible enemy at start reliably: if none visible, maybe force spawn one in LOS: pick visible cell regardless of exit proximity (except exit). We can add a fallback that bypasses dExit<2 check for the first visible enemy. Let's restructure: create first visible spawn directly:

```js
if (visible.length) {
  const c = visible[0];
  if (c.x !== exitCell.x || c.y !== exitCell.y) spawns.push({x:c.x,y:c.y});
}
```
Visible cells have dStart>=3 so valid. Then general spawn selection with spacing.

Let's edit: replace `if (visible.length) trySpawn(visible[0], 3);` and aim block.

Also the lineOfSight diagonal corner leak: with 0.08 steps, a diagonal line passing exactly through corner cells could leak, but the screenshot facing wall means the aim was the issue, not LOS. Still, LOS leaks could let shooting through diagonal corners. To reduce, I could remove the 8-neighbor... For lineOfSight, minor. Let's add a check for diagonal-corner crossing: sample neighboring cells? Simpler: for each sample, also treat walls at floor positions; a diagonal through corner will at some sample hit one wall typically. With step 0.08 and corners, line at 45° passes exactly through corner points: sample at (2.0,1.99) etc. It may alternate. Risk is low but shooting through corners is an "occlusion" bug. Improve by checking the nearest grid points crossing: use step 0.05 and also check both cells offset by 0.5 in perpendicular? Overkill.

Actually if the ray passes exactly through a corner where two walls touch diagonally, checking only the point could snap. Use also sample at slight offsets. Let me just make lineOfSight check the point plus 2 points offset perpendicular by ±0.15? That could make small enemies behind doorways untargetable... Not a big issue. I'll instead check corner crossing by examining the two cells adjacent to the crossing point at each step: if both orthogonal neighbors are walls while the diagonal is open, it's not a valid passage. Hmm.

Actually simpler: in lineOfSight, sample at i/steps and if either of the two "edge" cells at that sample is wall AND the other is wall? If both orthogonal neighbors are walls, the corner is blocked. Implement:

```js
const cx = Math.floor(x0+dx*t), cy = Math.floor(y0+dy*t);
if (isWallCell(cx,cy)) return false;
```
Plus intermediate: check the cells at floor(x+eps)... skip.

Given time, keep it.

Fix the aiming now.

The enemy is visible but the sprite is enormous — because it's only 3 tiles away and hFrac 0.88 with wide texture. It looks like a giant green block face. The sprite texture is 16x16 pixel art scaled up; when close it fills view. The width equals height, making it look wide. Enemy at (4,1) is 3 tiles away; screen height = RH/3*0.88 = 88 px of 300 → should be about 30% of the screen height, which matches image (from y~370 to 480 of 800 display... roughly 40%). Sprite width = same 88/480*1200 = 220 px in display; image shows ~200 px wide. OK that's expected. It looks blocky because pixel art is 16x16 with 4px cells, but at this size blocks look chunky. Fine but the monster reads as a green blob. Improve sprite art with darker outline & horns maybe scaled. It's acceptable for Wolfenstein-style. But the sprite's face appears cut off at the top? No.

Hmm, it's really a big green square with eyes. Let's reduce hFrac to 0.8 and make the art more creature-like; also the sprite is centered vertically? It appears hovering mid-screen with feet at the floor, fine.

Maybe it's fine. But I'd like a more menacing look. The current art rows: row 5-9 is a big green mass. Could darken the outline and add shading. Let's add a 1-pixel dark shade under the eyes and body shading by using colors 'd' and 'B'. Might be worth a quick improvement: add a shading pass in makePixTex that darkens the bottom-right edges? Simpler: modify palette and grid.

Actually time budget: around 8-9 minutes left. Priorities: verify movement, collision, shooting, restart, win/lose. Visual polish secondary but the sprite is prominent.

I'll do a modest sprite improvement later if time permits. Let's test movement and shooting first.

Test: press W a couple times (moving toward enemy), screenshot; then space to shoot 3 times, check enemies count. Keys via browser action "key". Let's do W keydown/up? The key action probably sends key events with key name like "w". Let me try clicking canvas first for focus then key.

Use browser key with text "w"? The tool has "key" action with text. Let's try.

Interesting—the enemy is very close (attack happened, health 84). Wait the key action likely held the key for a while? It moved from 3 tiles to adjacent. It's fine—health dropped as designed, and there's a hurt flash (red overlay). Also the enemy sprite enlarged and changed tint due to red flash overlay; sprite appears yellowish because of the red overlay.

The enemy sprite is too wide/flat. The width equals height but the visual mass is broad. It's OK but let me improve: make the sprite world width narrower (0.75 of height) to look like a creature, and reduce hFrac to 0.82. Actually with creatures, width ≈ height is normal.

The bigger issue: pixel art chunky. Fine.

Let me test shooting: press space 3 times.

A shot was fired (muzzle flash visible) but health dropped further and enemies still 4. Did the shot hit? The enemy was directly in front — lateral offset: sprite is centered, crosshair at center. Maybe the shot didn't hit because the enemy is very close and depth < 0.25? Enemy at 1.25 or less; depth might be ~0.9 → fine. The lateral tolerance 0.45 should be met. But hp of the enemy is 100 and only one shot: needs 3. Enemy count stays 4 until dead, correct! The hurt flash on the enemy (white tint) isn't obvious because it's green-yellow due to hurt flash? Sprite is bright.

The muzzle flash looks good. But wait, the shot didn't visibly brighten the enemy (hurt=0.16). Maybe screenshot timing.

Health 76 due to melee attacks—rule working.

I don't see the visible hit feedback confirmation. Let me fire twice more and check enemy count.

Also the sprite is huge and flat; I'd like to improve art slightly. Let's first finish functional tests.

Fire 2 more shots (each key press fires once; auto-fire only while held — key action may be press only).

Enemy count still 4 after 3 shots? The space key presses might be too slow (0.30s cooldown) — but each key action triggers one shot; maybe the key event happens but fireCd wasn't yet elapsed between tool calls? The tool calls have time between them, likely > 0.3s. Hmm, or the shots are missing! The enemy sprite center is at screen center but its actual origin is at (4.5,1.5) while player at (1.5,1.5) facing 0 → dead center. Lateral = 0. LOS true. depth = 3. Should hit.

Wait, maybe `tryShoot` is called but keys[' '] gets set and the auto-fire in update immediately... no, still shoots.

Maybe the shoot hits but the kill count requires 3 hits of 40 → 120 dmg, so 3 shots should kill. We've fired 3 times total (one earlier plus 2). Enemies still 4 means misses or fewer shots registered.

Possibility: `e.stun` prevents... no.

Could the shots be hitting and enemy dead not reflected? The HUD updates each frame.

Alternatively, key action "space" via tool sends key event with text " " maybe mapped to key = " "? The muzzle flash appeared in the screenshot after the first press, so shooting happened.

Hmm, why no damage? Let me check `tryShoot`: `if (state.fireCd > 0) return; state.fireCd = 0.30;` Fine.

Enemy loop: `const depth = dx*dirX + dy*dirY;` with dirX=cos(0)=1, dy=0, dx=3 → depth 3. lateral = |dx*(-dirY) + dy*dirX| = 0. LOS: samples along the line player (1.5,1.5) → enemy (4.5,1.5), cells y=1, x from 1.5→4.5: cells (1,1),(2,1),(3,1),(4,1) — is map (2,1) a wall? Looking at the screenshot, there's an open corridor straight to the enemy. It's likely open.

But wait: is the enemy possibly at a different position than (4,1)? The console shows the level from initial load, and the enemy has moved toward the player since (it's now adjacent at ~1.2). The sprite is enormous, so it's within around 1.2-1.5 tiles. If depth > 0.25, fine.

Hmm, but maybe enemy is exactly in front at distance < 0.25? Player can't get that close due to separation... enemies stop at 1.25 to attack, so no.

Unless... `keys[' ']` is true and continuous fire happens, and the state fireCd is constantly reset — no, each call deals damage too.

Wait! Maybe the enemy in view belongs to a different spawn and our shots hit but the enemy has 100 hp and we fired 2 effective shots → count stays 4. Total presses: 3 (first press, second press, third press). Hmm, but the health drops each time (enemy attacking) so time passes.

Could the tool's key action be auto-repeating while held? That could produce several shots. Muzzle flash appears in both screenshots.

Let me check the DOM debug element (hidden) via inspect to see enemy hp? I don't log enemy hp. Add hp of enemies to dbg. Let me inspect current DOM: dbg isn't in the "dom" output because maybe it's empty/hidden? The dom string shows only visible text.

I need better verification. Add an enemies hp array to dbg and console log on each shot (hit or miss). Let's add console.log in tryShoot with target info, then reload and test.

Also improve the sprite. And maybe the enemy is too big — hFrac 0.88 at 1.2 distance → walls are 1 tile high so sprite nearly fills screen. It's correct perspective.

Wait, maybe there's a bug: sprite drawn with fog computed from tY. Fine.

Let me add debug logging.

This looks decent — the enemy is visible down a diagonal corridor, facing exactly. Now fire 3 shots.

Hit registered: hp 60. The enemy moved right up to the player (dist 1.23) and is huge. Now fire twice more to kill.

But the enemy at 1.23 is rendered huge covering the screen — expected in melee.

Also note the sprite is drawn at full brightness with hurt flash; looks okay.

Let me fire twice more, and verify kill + count 3.

The enemy has hp 20. One more shot kills. Enemy count then 3. Let's fire.

The dead enemy sprite is still displayed (death shrink) with full brightness — actually this is a leftover dead body drawn at scale near 1 due to deadT small? The enemy count went to 3, "ENEMY DOWN (3 LEFT)" toast shown. The dead sprite shrink happens over 0.5s, so this frame is right at death. Fine, but it looks alive. Add a death effect: fade/shrink + maybe red flash. It already shrinks over 0.5s and brightens; here it's shown big because only a frame passed. Fine.

But wait, the enemy sprite at death is still facing the player at full height. It's momentary.

Next: verify collision and turning. Turn right/left and move. Also verify restart.

Collision test: I'm at start (1.5,1.5) facing 1.107 (toward enemy at 2,3). Walls at map edges. Press S to back into the wall at x=1 / y=1. Debug shows position; I can inspect the hidden dbg element? The DOM string from inspect doesn't include dbg because it's display:none. Hmm. Instead log player position occasionally? I can read via console: add a periodic console log? Let's add a 'p' key debug log for position and collision state. Simpler: temporarily use console.log on key press for movement. Better: add a global debug function and press a key... Can't eval.

Add: when pressing 'p', console.log player position. Also print in dbg but inspect won't show hidden. Let me make dbg visible? No. Just add key 'p' logging.

Actually there's a simpler check: screenshot shows wall distance visually. Collision detection is straightforward code; but the task asks to check collision against a nearby wall. Add log on 'p' with x,y and also log blocked test? I'll log position each time P pressed.

Let me also test turning and strafing via screenshots.

Also I realize the sprite enemy "hurt" flash renders as brighter (as seen). Fine.

One visual improvement is worthwhile: the enemy death should look dead. I'll tint the dying sprite dark red and flatten it (already shrinks). Add a red tint by multiplying channel? My drawSprite supports brightness only. Could add tint args. Quick approach: for dead, use brightness 0.6, and it shrinks. Fine.

Another improvement: sprite has no shading — flat colors. Add simple shading in makePixTex? It's fine.

More important checks: win/lose states, restart. I can test restart now via R key: should restore health 100, enemies 4, initial viewpoint. Let's do that and screenshot.

Also add 'p' logging.

Now reload (fresh level), then test S movement into the wall behind and P log. At start (1.5,1.5), pressing S moves backward; if facing angle diagonal, it may not hit wall immediately. Use A/D etc.

Let's reload, press S several times, then P log to see position bounded >1.25 (radius 0.26 → min x/y ~1.26).

Good scene: corridor, wall textures (stone left, brick right), enemy visible ~4 tiles away. The enemy sprite looks a bit like a green blob but recognizable.

Now test movement forward W, then strafe into wall and log position.

The player faces +y (south) here; enemy at (1,4) 3 tiles. Moving W would approach. Test collision: press A (strafe left) into the wall at x=1 while at x=1.5 → should stop at ~1.26.

Note: pressing a key via browser may hold for some duration? The 'key' action probably dispatches keydown+keyup quickly. Earlier W moved a lot (from 3 tiles to melee) in one press, suggesting it held ~1s. Let's see.

Press A then P.

Hmm — pressing 'a' caused the enemy to come to melee and health dropped, but the view barely moved left. That suggests the key actions are held for a long time (~1s+), and enemies advance quickly. It also means the camera didn't strafe much? The left wall appears closer... Hard to tell.

Wait, health dropped 21 points in one keypress, meaning ~2 attacks. So the key was held for a while (or time passes between tool calls).

I need the position. Press p.

Position is still x=1.50, y=1.50 — so the A key press did NOT move the player at all! Wait, strafe left at angle 1.57 (facing +y) → right vector = (-sin, cos) = (-1, 0) → strafing left = +x... Actually 'a' gives strafe = -1, so mx = rightX*(-1) = +1 → move +x, away from wall. Yet x remained 1.50. So movement didn't happen at all.

Why? Because the `key` action likely sends a key event but the window listener isn't receiving? But space and p worked. Hmm — space and p have side effects on keydown. Movement requires keys[k] to remain true across frames. The tool's key action probably dispatches keydown immediately followed by keyup with no frames in between, so no movement occurs. The earlier "W" test appeared to move... did it? Actually in that earlier test, health went from 100 to 84 and the enemy came close — that was enemy movement, not player. So player never moved!

So the browser tool's key action is a quick tap, not a hold. To test movement I need a different approach: maybe there's no way to hold keys. I could add a debug/testing helper using a visible UI? Alternatively, use a temporary test harness in the page: e.g., support an auto-demo triggered by a key like 'T' that simulates holding W for 1.5s (setting keys['w']=true then timeout). That tests the movement path (though through the keys object rather than real key hold).

Simplest: add key 't' → simulate holding W for 1.2s; 'y' → simulate holding A for 1.2s. Hidden debug helpers are acceptable but shouldn't affect normal play. Or I can use a tiny test script embedded temporarily and remove it later. Since verification matters more than purity, I'll add temporary debug controls and maybe keep them undocumented (harmless).

Actually better: I can use `browser` action type text? No.

Let me add temp helpers: key '1' hold w 1s, '2' hold a 1s, '3' hold ArrowLeft 0.8s.

Then reload, tap 2 (strafe into left wall), p to log position. Expect x ~1.26 max.

Also this will verify turning.

Let me add:

```js
const hold = (k, ms) => { keys[k]=true; setTimeout(()=>{keys[k]=false;}, ms); };
if (k === 't') hold('w', 1200);
if (k === 'y') hold('a', 1200);
if (k === 'u') hold('arrowleft', 800);
```

Cross-check collision: from start (1.5,1.5), holding A (strafe left) moves toward +x? Wait facing 1.57 (+y): right = (-1,0); strafe -1 (A) → move (+1,0)?? That's away from the left wall. Hmm, strafing left when facing +y should move toward +x? In map coords x to the right, y down. Facing +y (down the screen in map). Left of facing = +x direction? If facing down (+y), your left is east (+x) in a standard x-right, y-down coordinate system? Think of map: x right, y down. Facing down (south), your left hand points east (+x). Yes. So A moves +x. In the view, that would be strafe left (screen left). Consistent.

To hit a wall with A from x=1.5 holding +x would move away from wall at x=1. Holding D would move toward x=1 wall (west). Let's test holding D (key y with 'd') to push into the wall at x=1 (start is at cell 1, wall at cell 0). Expect x ~1.26.

Alternatively hold S backward → moves toward y=1? Facing +y, backward is -y toward wall at y=0/1 cell? Start cell y=1 has wall below at y=0. Moving backward from y=1.5 → y=1.26. Use W/S test anyway.

Let me change helper: 'y' holds 'd' 1.2s. Also test 'u' arrowleft 0.8s.

Let's edit.

Now facing +x toward enemy at (4,1). Test movement 't' (hold W 0.9s), then log position. Should move ~2.4 tiles to x~3.9, near enemy, and possibly take damage. Collision not relevant here since corridor.

Then test 'y' (strafe D toward wall at y=0? facing +x, right = (0,1) i.e., +y; D moves +y into the wall at y=1 boundary? Player at y=1.5, cell 1; wall at cell y=0. Moving +y goes to cell 2 (open). Hmm. To test collision, use S backward toward... Let's instead do a long strafe to the right multiple times until wall; tile (x,2) may be open.

Better: use the existing logs and push against a wall by holding W while facing a wall. After moving forward W 0.9s to x~3.9 near enemy at (4,1)... enemy attacks and may block.

Alternative collision test: turn left to face y? Ugh.

Simplest robust test: strafe right (key y = hold d) for 1.5s and see if x/y stops at an integer+0.26 boundary. At start facing +x, D moves +y. Start y=1.5; y=2 cell? The map at (1,2) might be open (corridor). Continue strafing until a wall: position would stop at 2.74 (wall at y=3) or keep going through open cells. The log will show final position; collision is evident if y stays < some integer - 0.26.

Let me extend the hold to 1.5s and log after. Actually my helper holds 900ms ≈ 2.4 tiles of movement, enough to hit a wall in most directions.

Test: press y then p.

The enemy is now very close (took damage), suggesting the player moved toward it? Strafing +y wouldn't approach (4,1) much... Actually y movement of 1.5→? and the enemy has AI that closes in. That explains it.

I need the position log. Press p.

Player moved only 0.22 in y, not ~2.4. Why? Holding D 900ms should move 2.4 tiles but collision with a wall at y=2? It's at 1.72 which is mid-cell — that suggests it stopped due to a wall at cell (1,2) or (2,2) maybe: blockedCircle checks corners at x±0.26 → cell x=2 if x=1.5+0.26=1.76 floor 1; hmm at x=1.5, corners x-0.26=1.24 and x+0.26=1.76, both cell x=1. y+0.26=1.98, cell y=1 — fine, no wall there. y=1.72 doesn't hit an integer wall.

Wait — 0.22 in 900ms implies movement mostly blocked. The player at x=1.5, y=1.72, and D moves +y. Collision would stop at y where floor(y+0.26) is a wall: y=1.74 → cell 2. So cell (1,2) is a wall! That's why. Good, the strafe was blocked by the wall at y=2, and position capped at ~1.74. That verifies collision works (stopped at exactly one radius before the wall).

Also confirms movement works via keys (holding).

Now test turning with 'u' (arrowleft hold) and position log; view should rotate.

Then shoot to kill the adjacent enemy (3 shots) and check count → 3.

Then test R restart restores health 100, enemy count 4, initial view.

Win/lose states: I can't easily play through the maze. Could add debug keys to simulate win/lose: e.g., 'k' kill all enemies → verify unlock and portal (open), and 'l' damage player to 0 → game over. But those would be temporary debug cheats; better to verify win logic by teleporting the player to the exit via debug key. Let's add temporary debug: 'o' teleport to exit cell center (and kill all enemies?). Actually to verify win: press 'k' (kill all) then 'o' (teleport to exit) → win screen. And game over: 'l' → health 1? Use a debug key 'h' to set health 5 then let enemy hit. Simpler: 'x' sets health 1 and let enemy attack, but may take time. Or directly call gameOver via debug key 'g'.

I'll add temp debug keys, test, then remove them (keeping the p/t/y/u maybe also remove all debug helpers except p? Should remove test hooks for final cleanliness; they don't harm though. I'll remove t/y/u/o/k/g before finalizing but keep p? Remove all.)
 
Let me add now:
- 'k' → enemies.forEach(e=>{e.alive=false;e.deadT=1;}) and console.log.
- 'o' → player.x=level.exit.x+0.5, y=..., log.
- 'g' → state.health=0; gameOver().

These simulate reachable states to test UI. Then remove.

Also check restart via R now.

Now test R restart first from this state (health 58, enemy damaged) to verify restore.

Restart works: health 100, enemies 4, initial viewpoint restored, camera back to start angle.

The health bar's green fill is partially yellow due to transition animation at capture moment; fine.

Now test win: press 'k' (all dead) then 'o' (teleport exit) — should show win overlay. Note the toast may set. Let's do 'k', screenshot maybe shows portal open; then 'o'.

'k' didn't trigger all-dead. Because the key handler's early return `if (keys[k]) return;`? No, that's for held keys. Did the edit apply? Maybe the key press is being processed but the enemy... "ENEMIES 4", health 82 (enemy still attacking).

Wait — my debug code checks k === 'k'. e.key for "k" is 'k'. Should work. Unless my edit block was inserted after a `return`? Let me check the handler.

Actually, I inserted debug lines after 'u' line, and all within keydown. But earlier the keydown handler begins:
```
if (keys[k]) return;
keys[k] = true;
audioInit();
if (k === 'r') resetGame();
if (k === 'p') ...
...
```
Should work. But maybe the edit didn't get saved before reload? I edited after reload. Yes! I edited the file after the last reload? Let me check the order: I reloaded, pressed 'y', 'p', 'r' (all before adding k/o/g?). The k/o/g edit was made right after the p test, before r. So r reload? No, r just restarts, doesn't reload the page. The page hasn't been reloaded since the edit, so the new debug keys aren't loaded yet.

Reload and test again. But reload resets the level (fine).

Now the enemy is 3 tiles away (at 1,4, player at 1.5,1.5 facing +y). Walls look good. The sprite still reads as a blocky green monster, acceptable.

Now press k (all dead) then o (teleport).

Enemies count 0, exit OPEN. Good. Health 90 because the enemy got one hit in before dying.

Now teleport to exit (o) → should win.

Win state works. The portal is behind the player at the exit cell but the screen is showing the exit room. Overlay looks good.

Now test game over: press R to restart, then g for game over.

Restart restored the exact level/viewpoint/health. Good.

Now test game over with 'g'.

Game over works.

Now cleanup: remove debug keys k, o, g, t, y, u and the console.log in tryShoot, plus the dbg hidden element? I can keep 'p'? Better remove all debug hooks including the dbg element, and the hidden div. But the dbg element is only hidden text; harmless. Remove for cleanliness.

Also consider improving the enemy sprite look — it reads like a green face with horns; acceptable pixel art.

One concern: the game starts with an enemy in direct sight at ~3 tiles, which immediately closes in and attacks. That's fine but maybe players get attacked quickly. Health 100, each hit 7-12, 1.15s cooldown; the player has time to shoot.

Another concern: "Enemies must be occluded by walls; shots cannot damage an enemy through a wall." Rendering uses zBuf; hits require lineOfSight. Good. I could verify occlusion visually by looking at an enemy behind a wall—difficult, but code is standard.

Also verify turning via 'u' before removing; let me test turn left quickly and log 'p'.

Then remove debug helpers and reload one final time, take a screenshot to confirm the final file works.

Test 'u' now (page loaded with old code, still has u).

Turning doesn't happen when dead (expected). Restart then turn test — not necessary; turning code is straightforward and was partially exercised (aim angle changes). I'll do one quick check after restart and pressing u, reading the log 'p' to see angle change.

Actually let's skip: the dead mode blocks update. Restart, 'u', 'p'.

All debug removed. Now also consider removing `dbg` const references elsewhere (none). Check the keydown handler works and no stray syntax errors.

Now reload and screenshot final. Also verify no console errors.

One more improvement I should consider: the first enemy is quite close at spawn and can rush the player quickly, but it's playable.

Also potential issue: enemies can see and attack through diagonal wall corners due to LOS sampling. Minor.

Another possible issue: the exit portal might be rendered inside a wall? No, exit cell is open.

Let me reload and check console + screenshot.

This level has no enemy visible from start (none had LOS at spawn?). The rule: first visible spawn pushes; if none, aim at corridor. The start view faces a dead-end metal wall. Fine, but the initial view has no enemies. Not required, but the earlier samples had enemies. It varies per maze. It's okay.

But wait: the visible spawn should almost always exist in a corridor. Here spawns are 4; maybe the visible filter found none with LOS at d<=8 (unlikely). Possibly the enemy count check... The aim code only aims at visible; if none, faces corridor with the largest BFS distance among immediate neighbors. Here it faces a dead-end wall 2 tiles ahead? That corridor is a dead end. Hmm, the "largest dStart neighbor" is chosen among immediate open neighbors; if all neighbors are dead-ends aside from the entrance, we face a wall.

Better start orientation: face toward the exit path (the neighbor cell with the largest BFS distance from start is actually the best direction, but a dead end neighbor could still have high distance... BFS distance is shortest, so the dead end neighbor would have distance 1 while the corridor toward exit has distance 1 too. Ties. In this case the chosen neighbor leads to a wall 2 tiles away.

Improve: choose the neighbor that maximizes BFS distance to exit (i.e., walk toward exit). Pick neighbor with min dExit. That makes the player face the route to the exit. And if an enemy is visible, override.

Let me change the start angle selection to use dExit if available (computed after exit). Reorder: currently we compute start.a before BFS from exit? We have dExit available (computed right after exit). But the code computes start.a before spawns and has dExit in scope. Replace the neighbor-choice block with a direct evaluation using the four neighbors and dExit.

Simpler:
```js
let fx=..., fy=..., fd=Infinity;
for each of 4 neighbors open:
   const de = dExit[neighbor];
   if (de < fd) { fd = de; fx=nx; fy=ny; }
start.a = fd<Infinity ? atan2(...) : 0;
```

This faces the path toward the exit. Combined with aiming at a visible enemy if present.

But still, no visible enemy at start in this level. Could ensure one enemy is placed in view along the route? Not necessary; requirement only says visible enemies (they are, when in view).

However, for the verification "Sample the scene for stable wall rendering" it's fine. But a shooter starting with no enemy in sight is less impressive. I'd like the start always to have an enemy visible. Option: relax visible filter to d<=12, which likely exists in a corridor... In this map, maybe spawn selection never picked a visible cell? The code pushes visible[0] unconditionally (if not exit cell), so if visible were non-empty, we'd have one. So visible was empty: no open cell within BFS distance 3..8 with LOS from start. Because the start is in a corner with walls immediately around? The screenshot shows a wall ~2 tiles ahead. Hmm, actually the wall is 2.5 tiles ahead: could be a dead-end corridor of length 2. Then LOS cells exist at distance 2-3, outside the >=3 filter? LOS from start along the corridor... it faces a wall 2.5 tiles away, so the open cell at 2 tiles is visible (BFS distance 2) but filter requires >=3. Then no visible enemy.

Extend visible filter to d>=2? Enemy would spawn right next to the player (2 tiles) — playable but maybe harsh. Alternatively, if no visible spawn, rotate the start to a corridor with an enemy in LOS? Simpler: keep as is; not required.

Let me at least improve start facing toward exit route. Also lower visible distance min to 2 but spawn distance requirement is d>=3 in trySpawn; when pushing visible[0] directly we bypass. Fog. Eh.

Actually, gameplay-wise, facing a dead-end wall at start is a bit confusing. Let's fix the facing.

Then final: check restart button click works (tested via R; button click tested? not yet). Let me click the Restart button in the overlay after a game over? The overlay needs showing. Test quickly: press R? Already tested key. The button handler is simple. Maybe test by showing win via debug again — no debug now. Skip; key restart tested.

Let's edit start facing.

Also, visible spawn filter min 3 — fine.

Reload and take a final screenshot. Also check for console errors.

There's an enemy sprite at the left edge, partially cut off (green). Fine—enemy visible at start. It appears clipped by a wall along its left side (occlusion works, or just off-screen edge).

However, an issue: the enemy is visible but mostly cut. That's because the aim points to exit route and the enemy is in view along the left edge. Acceptable.

Hmm, the enemy sprite is at x near 0 of the screen and clipped to a rectangular chunk — is that a wall occlusion? It looks like a vertical slice. Fine.

One concern: the wall corners: the brick walls look nice. There's a visible odd vertical black line on the left brick wall (the texture seam at tile boundary?) Not an issue.

The gun still looks like a simple shape but acceptable.

Let me do a final quick interaction test: press space to see muzzle flash and confirm no console errors after final changes. Character remains.

Then final restart test with R (already fine). I'm at ~3 min left maybe. Also confirm file saved only index.html.

Actually one potential gameplay bug: when all enemies are dead and the player reaches the exit, win triggers. But also if the player was standing at the exit when killing the last enemy? check triggers in the same update. Fine.

Another possible bug: dead enemy bodies linger drawn while deadT<0.5, but `e.alive` false means the shooting loop skips them.

Enemy attacking through player collision? fine.

Let me test one shot quickly and screenshot.

Now the enemy is in melee and the sprite is huge and clearly a green blocky monster face. It's readable (horns, eyes, teeth) but cartoonish. The muzzle flash isn't visible in this frame (probably faded). Health dropped to 79 — the enemy reached melee quickly within the ~seconds between tool calls.

This might be a bit harsh: the enemy closes in fast while the player is idle (each tool call leaves the page running). In real play, the player engages. Health 100 vs 12 dmg per ~1.2s gives ~10 attacks. Fine.

The sprite is a bit comical but acceptable "Wolfenstein-inspired procedural sprite". Given limited remaining time, I could improve the sprite slightly (dark outline, shading) but risk breaking. The mouth white bar is very wide. Let me adjust to a more menacing look with a smaller mouth and claws? That's cosmetic. I'd rather verify all required behaviors are met and finalize.

One thing to double check: are shots able to hit the enemy here? It's in melee, aim center. Yes tested earlier.

Also, the enemy sprite drawn over the gun? Gun is drawn after, so gun overlays sprite. Fine.

Let me check the file for any leftover debug strings and make sure only index.html exists. Also final read of key sections for syntax. Node can syntax-check the inline script? Extract and run node --check.

Good (grep 0 matches exits 1). No debug logs.

Final check: restart button click. Let me trigger game over state? Not available without debug. I already tested R and the button handler is a direct resetGame. I'm reasonably confident.

One small bug risk: `if (visible.length)` pushes visible[0] even if it's adjacent to an existing... spawns empty then. Fine.

Another: after restart, the exit portal open state is computed from enemies alive; fine.

Also: are the enemies guaranteed 4? If the maze has fewer valid spawn cells, could be 3. There's a regeneration check only if <3. Requirement "at least three enemies". Good.

Let me do a final reload screenshot after pressing R (already verified) and finish. Actually the current page is in a melee; not needed. Final answer.

Summary of verified:
- Initial render, textured walls, perspective, floor, HUD, controls.
- Movement/collision via holding keys (D strafe stopped at wall ~1.72 = wall y=2 minus radius): collision works.
- Shooting: hit logs, enemy hp reduced 100→60→20→dead, count 4→3, toast.
- Enemy melee damage reduces health (100→84→76...), game over at 0 shown.
- Restart (R) restored health 100, 4 enemies, initial view.
- Win: all enemies dead → EXIT OPEN, reaching exit shows win overlay.
- No console errors.

Unverified: exit portal visuals when unlocked (teleport bypassed the sight of it in the winning frame), enemy occlusion behind walls by direct observation (code uses z-buffer), restart button click (R key works), line-of-sight shot blocking (code only, not directly tested), mouse (not implemented).