Wolfenstein raycaster · qwen3.8-flash

Let me start by exploring the working directory and then build the game.

Let me plan the implementation:

- Single index.html with inline CSS/JS.
- Canvas raycaster: DDA algorithm, textured walls (procedural textures generated to offscreen canvases/ImageData), floor/ceiling casting (maybe simple gradient or textured floor).
- Enemies: billboard sprites with procedural texture (guard figure), depth-sorted, occluded by walls (per-column z-buffer).
- Movement: W/S forward/back, A/D strafe, Left/Right turn, Space shoot. Mouse optional (pointer lock / click-to-turn).
- HUD: health, enemies remaining, controls.
- Level: small grid maze, exit tile reachable, ≥3 enemies.
- Shooting: hitscan ray, check line-of-sight to enemy, occlusion via DDA wall raycast; only front-most enemies; damage; kill.
- Enemy attack rule: if line of sight clear and within range, they move toward player and attack (damage) with cooldown, e.g., melee if distance < 1.5 or shoot.
- Game over on 0 health; win when all enemies dead and player reaches exit tile.
- Restart button restores everything.

Let me write clean, careful code.

Key details:
- Use a fixed internal resolution e.g. 480x300 or compute from canvas size, scale up with CSS. Raycast per column. Textures 64x64 procedural.
- Floor casting can be expensive; I'll do a simple flat floor + ceiling with distance shading, or textured floor casting at lower res. Let's do textured floor casting using pixel buffer approach for whole canvas (width x height) — at 480x300 that's 144k pixels per frame, fine.

Actually a cleaner approach: render everything into an ImageData of size W×H (e.g., 400×250) then draw scaled to the display canvas. That gives full control: floor/ceiling casting, wall columns, sprites.

Let me do: internal buffer W = 400, H = 250? Aspect for the display ~ 16:9. Let's use W=448, H=252 (16:9). Rendering cost: 113k pixels — fine.

Textures: generate as Uint32Array palettes with shading. Procedural: brick pattern, stone, moss, exit door, wood. Use per-texture Uint32Array of 64*64 with RGBA packed into 32-bit (little-endian: 0xAABBGGRR).

Wall shading: distance fog + side darkening. To do this efficiently, compute per-pixel multiply. Let's do: fetch texel color, apply shading via bit tricks: extract r,g,b, multiply by factor, repack. That's fine in JS for 113k pixels.

Floor/ceiling: textured floor casting per row (standard technique), with distance shading. Maybe simpler: floor cast at half resolution? Let's just do it — full pixel loop; total ~113k iterations with a few ops; at 60fps that's ~6.8M ops/s — fine.

Sprites: enemy billboards. Draw scaled with per-pixel loop, checking z-buffer per column for occlusion. Enemy texture 64x64 with alpha (color key 0 = transparent).

Enemy death animation: show a "dead" sprite variant (corpse) briefly or permanently. Keep simple: when killed, play a death animation over ~400ms using alternate frames, then remove (or keep corpse). Enemies remaining count decreases.

Weapon: procedural gun/grenade launcher drawn on canvas (vector-ish) at bottom, with bob and muzzle flash, recoil. Shooting: reduce enemy health; damage feedback: hit flash.

Minimap: optional nice touch — small map showing walls, player, exit (green when unlocked), enemies. That's fine (it's extra). Requirement: display controls, show health & enemy count.

HUD message line: e.g., "Exit locked — 3 guards remain", "Exit unlocked! Reach the green door", etc.

Also crosshair.

Let me design the level. Grid map, 24x24? "small level". Let's use 20x20 characters map with '#' wall, '.' floor, 'S' start, 'E' exit. Wall texture chosen by map char variant maybe: different wall types ('1','2','3'). Let me use a char map with digits for wall texture types.

Map design (must have reachable exit, at least 3 enemies). Let's craft:

```
########################
#S.....#.......#.......#
#......#...##..#...#...#
#..#####......#..#.#.#.#
#..#...##.##..#....#...#
#..#......#..##.####..##
#..##..#..#....#..#....#
#......#..#####..#..#..#
####.###......#..#...#.#
#....#.....#..####..#..#
#..#..####.#.....#..#..#
#..#..#..#..###..#..####
#.....#..#....#..#.....#
#.##..#..###..#..#..#..#
#..#..#.........#..#.#.#
##.#..#####.#####..#.#.#
#..#........#..##..#...#
#..#######..#......#...#
#.........#..####..#...E
########################
```
Hmm I need to be careful: 24 wide, 20 tall, consistent widths. Let me instead construct programmatically? Better hand-craft carefully with exact lengths.

Let me do a 20x16 map (20 wide, 16 tall) to keep small and easily verifiable, then check reachability with BFS in code at load (and I can test with node).

Design map rows of exactly 20 chars, 16 rows.

Row0:  "####################"
Row1:  "#S...#.....#......E#"  -> exit at right side... exit tile should be a door tile in a wall or a floor tile marked. I'll treat 'E' as a walkable exit cell with a special door texture on the surrounding? Simpler: exit is a cell whose floor is a green "EXIT" tile; render it as a wall-like glowing door? Classic Wolf3D has exit tiles as wall textures you walk into... Actually you press a button / walk onto the exit square. Let me make the exit a special wall tile (green glowing door) that becomes solid, and when unlocked, walking adjacent... hmm, "reaching it shows a win state" — simplest: exit is a floor cell marked EXIT; when the player's cell == exit cell → win. Render the exit cell floor with a bright glowing pattern (procedural) and also render walls around it with an "exit" texture. That's easy and clear.

Actually nicer: make the exit a wall tile with door texture that, once unlocked, opens (becomes walkable) and stepping in wins. Let me instead place the exit as a floor cell in a small alcove whose entrance is a wall tile of "door" texture... complexity. Keep: exit floor cell with pulsing green glow floor tile, plus walls around textured as "exit panel". Player reaches it → win if all enemies dead. If enemies alive → message "Exit sealed: N guards remain".

Hmm, but "Defeating all enemies unlocks the exit" — good.

Let me write the map:

```
0: ####################
1: #S....#.....#.....##
2: #.....#..#..#..#...##
...
```
Let me be very systematic. I'll build a 20x16 grid and verify with BFS via node after writing.

I'll write the map as strings; then in code: '#'=wall type 1, '2','3' other wall types, '.'=floor, 'S'=start, 'E'=exit, 'g'? enemies placed separately as coordinates.

Let me design with intent: start at (1,1) facing east/... A winding maze with a few rooms, exit at (18,14).

Map (rows top→bottom, y=0..15):

```
r0 : "####################"
r1 : "#S...#...2#......3E#"   hmm exit needs adjacency to floor.
```
Let's simplify: r1 col 18 = 'E'? Let me put exit in the bottom-right region.

Let me write out:

```
row  0: ####################
row  1: #S.....#.....#.....#
row  2: #.####.#.###.#.###.#
row  3: #.#2...#...#.#...#.#
row  4: #.#.####.#.#.###.#.#
row  5: #.#....#.#.#...#...#
row  6: #.####.#.#.###.#### 
```
Getting messy. Alternative: generate maze procedurally? No — deterministic handcrafted is better and easier to verify. Let me use a 20x16 map where I carefully write and then validate all rows length 20, borders walls, and BFS reachability of exit from start; plus enemies on floor cells reachable.

Attempt (each row exactly 20 chars, index 0..19):

```
y=0 : ####################
y=1 : #S...#....#..#...22#
y=2 : #.#..#.##.#..#.###.#
y=3 : #.#..#..#....#...#.2   -> must end with # 
```
OK let me be careful: I'll write with a plan. Use pattern: border of '#' everywhere. Interior 18x14 (x=1..18, y=1..14).

I'll design a simple structure: two rooms + corridors, using a grid of wall segments with gaps, ensuring connectivity.

Interior plan (x from 1..18, y from 1..14):

- Start area: top-left corner (1,1).
- Exit: bottom-right area (17,13) or (18,14).

Walls: use a few vertical/horizontal bars with gaps.

y=1 : #S . . . . # . . . . . # . . . . . #  → "#....#.....#......#" that's 1+4+1+5+1+6+1 = 19. Need 20. Let me count precisely for full rows instead of interior-only.

Full row of 20 chars, x=0..19, x=0 and x=19 are '#'.

Row y=1: x1..x18 = 18 chars.
Let me set: x1..x4 = "...." (with 'S' at x1 → "S..."), x5='#', x6..x10=".....", x11='#', x12..x18=".......", so total: '#' + "S..." + "#" + "....." + "#" + "......." + '#' = 1+4+1+5+1+7+1 = 20 ✓
→ "#S...#.....#.......#"? That's 1+4+1+5+1+7+1=20 chars: "#","S...","#",".....","#",".......","#". Let me just write it: `#S...#.....#.......#` — count: # S . . . # . . . . . # . . . . . . . # = 1+1+4... let me count characters in the literal string "#S...#.....#.......#": # (1) S(2) .(3) .(4) .(5) #(6) .(7) .(8) .(9) .(10) .(11) #(12) .(13) .(14) .(15) .(16) .(17) .(18) .(19) #(20). Yes 20 ✓.

Row y=2: `#.##.#.###.#.#####.#`? Let me instead make rows so corridors exist. This hand-crafting is error prone but let's just do it and verify with node BFS, adjusting as needed.

Plan layout (18x14 interior), think of it as corridors:

I'll do this structure:
```
y=1: #S...#.....#.....2.#
y=2: #.##.#.###.#####.###
y=3: #.#..#...#.......#.#
y=4: #.#.####.#####.#.#.#
y=5: #.#....#.....#.#...#
y=6: #.####.#####.#.###.#
y=7: #.#  ...
```
Honestly, let me write it in a way I can verify quickly, iterate with node. I'll write a candidate map, run node script for row length + BFS, fix.

Candidate:
```
"####################",
"#S........#......3.#",
"#.######..#..###...#",
"#.#....#..#....#...#",
"#.#.##.#.#####.#####",
"#...#....#...#.....#",
"###.####.#.#.#####.#",
"#...#..#...#.....#.#",
"#.###..##.######.#.#",
"#.....#..#.....#...#",
"####..#.####..###.##",
"#..#..#....#..#....#",
"#..#..####.#.#.##..#",
"#........#.#.#..#..#",
"#.######.#.#.#..#.E#",
"####################"
```
Hmm 16 rows of 20. Exit at (18,14). Need to verify connectivity and that it's not trivially open.

Wait — '3' in row 1 is a wall type digit; I said digits are wall textures. Let me use digits for walls: '1','2','3' wall types; '#' = type 1. In row1 I wrote "#S........#......3.#" — '3' means a wall of type 3 inside, fine (it's still solid). Ok.

Let me count each row's length via node. And BFS from S to E.

I'll write the file, then extract map via node to test.

Better: put map in JS and test with a small node script reading index.html? Simpler: write a temp node script with the map array and check.

Let me design more thoughtfully for gameplay: 3 rooms, some corridors, 4 enemies.

I'll go with the candidate and validate.

Now enemy definitions: array of {x, y, type}. Place at floor cells: e.g., (8,1) in start corridor? Keep enemies away from start (start (1,1)). Enemies at (15,3), (5,11), (10,8)? Must verify they're on floor.

Enemy behavior:
- type 'guard' with health 100, damage 8-15 per shot, range with LOS, cooldown ~900ms, projectile-less hitscan with visual tracer? Simpler & classic: enemy fires (hitscan with hit chance based on distance), player takes damage. Also melee if close.
- Attack rule stated in HUD/legend: "Enemies shoot you if they see you with a clear line of sight; they stop firing when you break line of sight." That's a clear rule.
- Enemy movement: if LOS and dist > 3, move toward player (simple: move along direction with collision, plus sidestep if blocked). If no LOS, wander/patrol slowly toward last known position? Keep simple: idle wander or stand still, activate when LOS. Let me implement: if LOS → approach to preferred range (2.5) and shoot with cooldown; if no LOS but alerted (player shot near / was seen) → move toward last known position. Keep it moderate.

Player shooting: Space. Hitscan along view direction; find nearest enemy whose billboard intersects the center ray with proper hit test: for each enemy, compute vector in camera space, check if the ray passes within enemy radius (0.35) and distance < wall distance along ray (using DDA wall hit distance) → hit nearest. Also require clear LOS. Damage 34-50 → kills in 2-3 shots. Muzzle flash, sound? No audio (can use WebAudio synth — allowed since no external assets! WebAudio oscillator for shot/hit sounds). Nice touch: procedural audio via AudioContext. That's allowed (no network). I'll add simple beeps/noise with try/catch and it only triggers after user gesture.

Health: 100, medkit pickups? Optional. Maybe add health pickups (good). Keep scope reasonable: 1-2 medkits that restore 25 when walked over. Not required but harmless. I'll add them — but requirement "Give the player health" satisfied.

Win state: overlay "MISSION COMPLETE" with restart.

Death: overlay "YOU ARE DEAD" with restart.

Rendering details:
- FOV 66°, raycast with DDA.
- Wall textures: 64x64 procedural: brick (type1), tiled/marble (type2), mossy stone/tech panel (type3), exit door? We use exit as floor glow.
- Floor/ceiling: procedural floor texture (checker/stone), ceiling texture (dark panels).
- Distance shading/fog.
- Sprites: guard (procedural pixel art drawn into texture), plus medkit sprite, plus corpse frames.
- Weapon: drawn with canvas 2D vector shapes after the buffer blit (not in buffer) so it can be crisp; use canvas drawing commands with scaling.

Implementation approach: 
1. `render()` writes into ImageData `frame` (W×H), then `ctx.putImageData(frame, 0,0)` on an offscreen canvas at internal resolution, then `ctx.drawImage(offscreen, 0, 0, canvasW, canvasH)` with imageSmoothingEnabled=false on the main canvas. Main canvas is at device size (e.g., 960x540 CSS, internal 960x540 or with dpr). Simpler: canvas element width/height set to internal size * scale factor integer. Let's set canvas internal = e.g. 480x270*... Let me do: buffer 400x240? Aspect 5:3.

Let's do: VW=440, VH=248? I'll pick VW=420, VH=236... Let me pick a base resolution and scale canvas: canvas.width = VW * SCALE, canvas.height = VH * SCALE, where SCALE chosen from container width. But putImageData requires 1:1 pixel; so: draw ImageData onto offscreen (VW×VH), then main ctx.drawImage(off, 0, 0, canvas.width, canvas.height) with smoothing off. Canvas size = 2x or 3x viewport fit. That works and looks crisp-pixelated (Wolf3D-ish).

Use VW = 320, VH = 200? That's very retro (Wolf3D was 320x200). Perf: 64k pixels — very fast. Might look too chunky when scaled to 960 wide (3x). Retro chunky is on-brand. Let's use VW=400, VH=250 (nice balance).

Floor casting: standard technique with per-row rowDistance.

Ceiling: dark gray-blue with panel texture; floor: brown-gray tile.

Let me write the code.

Core structures:

```js
const MAP = [...strings];
const MW = MAP[0].length, MH = MAP.length;
function cellAt(x,y){ if(x<0||y<0||x>=MW||y>=MH) return 1; const c = MAP[y|0][x|0]; if(c>='1'&&c<='9') return +c; if(c==='#') return 1; return 0; }
```
Exit cell coords stored from 'E' parse; 'S' start.

Textures: build Uint32Array(64*64) per texture with helper to pack colors: `pack(r,g,b,a=255) => (a<<24)|(b<<16)|(g<<8)|r`.

Generate:
- texBrick: brick pattern with mortar lines and noise shading, reddish-brown.
- texStone: gray blocks with noise (type2 = bluish steel panels).
- tech panel type3: green/olive metal with rivets.
- texFloor: dirt/tile brown.
- texCeil: dark concrete with beams.
- texExit... 

Enemy sprite texture: draw with 2D canvas then getImageData to Uint32Array (with alpha). Use a function that draws pixel art via a small string-based sprite definition? That's easy: define sprite as array of strings with palette chars, 24 wide x 32 tall scaled to 64x64? Better: define at native resolution 32x40 and blit with transparency in rendering. Store as Uint32Array of size sw*sh plus sw, sh.

I'll define sprites via ASCII art:
Guard: 
```
palette: '.' transparent, 'h' skin, 'H' helmet/dark, 'u' uniform, 'b' boot/dark, 'g' gun gray, 'e' eyes
```
Let me draw a 16x24 grid ASCII, and store texel size = 16x24 but render scaled up (nearest). Simpler to author, and nearest-neighbor scaling keeps retro look. Good.

Frames: guard standing, guard firing (arm raised + muzzle), guard hit?, dead (two frames: kneeling, corpse). Medkit sprite 12x12ish. Let's use uniform 16x24 canvas for all sprites including corpse (mostly transparent at bottom).

Let me author ASCII art for guard (16 wide, 24 tall). I'll write rows of exactly 16 chars.

```
guard:
"....HHHHHH......"  hmm need centering.
```
Let me design a soldier facing the player:
rows (24):
1: `................`
2: `....HHHHHHH.....`
3: `...HHHHHHHHH....`
4: `...HhhhhhhhH....`  face top
5: `...hsseSsess....`  eyes... 
Let me simplify to a chunky look:

```
 0: ................
 1: .....HHHHH......
 2: ....HHHHHHH.....
 3: ....HhhhhhH.....
 4: ....heHeheH.....   (eyes dark)
 5: ....hhhhhhh.....
 6: .....hmmmh......   (mouth/shadow)
 7: ...uuuuuuuuu....
 8: ..uuaaaaaaauu...
 9: ..uuAAAAAAAuuu..  ...
```
This is getting long. Alternative: draw the guard with canvas 2D primitives (rects, arcs) into a 32x48 texture — less authoring effort, and still procedural. I like that: use a draw function on an offscreen canvas with rects. E.g.:

```js
function makeEnemyTex(frame){ // 'stand','fire','die1','corpse'
  const c = document.createElement('canvas'); c.width=32; c.height=48;
  const g = c.getContext('2d');
  g.clearRect(...);
  // boots, legs, torso, arms, head, weapon
}
```
Then getImageData → Uint32Array + w/h. Yes, cleaner code and can vary per frame. Also can add a "hurt flash".

I'll do that: draw functions using rects with palette colors and a bit of shading (left lighter). Nice.

Sprite rendering: standard projection. For each sprite: transform relative to camera using inverse camera plane matrix. Build:
- dir vector (dirX, dirY), plane (planeX, planeY) = perpendicular, length tan(fov/2).
- transform: invDet = 1/(planeX*dirY - dirX*planeY); transformX = invDet*(dirY*dx - dirX*dy); transformY = invDet*(-planeY*dx + planeX*dy) where dx,dy = sprite - camera.
- spriteScreenX = (VW/2)*(1+transformX/transformY).
- height = VH/transformY (times vDiv scaling).
- Draw columns from stripe start..end, check zbuf[stripe] > transformY, and pixel alpha.
- Vertical offset: put feet on floor (classic): use vMove = 0 with object placed on floor: spriteHeight centered at eye level; to have feet on floor, shift by (VH/transformY)*(1 - spriteH/2)/2... I'll use parameters: for each sprite, `elev` (0 = centered at eye height, feet on floor means offset down by (VH/transformY)*(0.5 - hRatio/2)). Let me do generic: object has worldZ (height of its center above floor in units, 0.5 means center at half-wall height = eye level). For a guard of height 0.62 units? Wall height 1 = eye at 0.5. Guard height ~0.62 units? Actually classic Wolf guards look tall. Let's compute: sprite height in pixels = (VH / transformY) * spriteWorldHeight where spriteWorldHeight in wall units (1 = wall height = eye-to-floor... hmm).

Standard formula with wall height 1 and camera at z=0.5: A vertical object of world height h centered at z=0.5 spans pixels of height = (VH/transformY) * h... Let's define: for a wall (height 1, from z=0 to z=1) the projected span is exactly VH/transformY tall centered at VH/2 (horizon at eye level). So an object standing on the floor with world height h occupies (VH/transformY)*h pixels, and its bottom is at floor level → bottom pixel = VH/2 + (VH/transformY)*0.5, top = bottom - (VH/transformY)*h. Good, general and simple: bottom = horizon + (VH/transformY)*(0.5 - zBase) where zBase = height of object bottom above floor (0 for grounded). Let's define per sprite: hWorld (height), zBase.

For guard: texture 32x48 (aspect 2:3). If hWorld = 0.8 then width = hWorld * 32/48 = 0.533. Reasonable.

Weapon/hitscan test: cast ray DDA to get wallHitDist. For each alive enemy: compute perpendicular distance from ray... use the sprite transform approach: transformY is depth along view dir, transformX is lateral. Enemy hit if |transformX| <= halfWidthWorld (e.g., 0.28) and transformY > 0.15 and transformY < wallDist and transformY < shootRange. Choose min transformY. Damage.

Player movement collision: circle radius 0.24 against grid; separate axis movement (try x then y) with wall check.

Turn: arrows with rotation speed ~2.6 rad/s; also Q/E turn, and mouse optional (click canvas → pointer lock, movementX rotates). Also Strafe with A/D as required. Shift for run.

Space shoot: cooldown 350ms, semi-auto (per key press? Allow hold with cooldown — fine).

HUD: drawn as DOM overlay (health bar, enemy count, ammo?, message, controls list) — DOM is easier and crisp. Weapon drawn on canvas. Ammo not required; but "shots" could be limited — not required. Keep ammo as infinite with clip count? Skip ammo to reduce risk? Classic feel includes ammo. Requirement doesn't ask. I'll add ammo (bullets) with pickups? That adds failure states (out of ammo → can't kill → soft lock). Avoid: infinite ammo but rate limited. Mention "SHOTS: ∞". Fine — no, I'll add "ammo" as unlimited and not display it.

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

Messages/toasts: transient text in HUD.

Damage indicator: red vignette flash on canvas when hit.

Now performance and correctness: pixel loops with Uint32 writes to ImageData.data as Uint32Array view. Shading: compute factor = clamp(1 - dist/maxDist), multiply rgb. To avoid per-pixel rgb extraction cost, precompute for each texture a shaded version per distance level? Classic trick: build 16 shade levels per texture (16 * 4096 * 4 bytes = 256KB per texture, 6 textures = 1.5MB) — acceptable and fast. Let's do: textures stored as array of Uint32Array shades: tex.levels[i], with index by fog level computed from distance. For sprites too? Sprites need alpha; store levels with alpha preserved. Doable: shading preserves alpha.

That's a nice optimization: `shadeFor(dist) = min(N-1, floor(dist/ maxDist * N))`. Also side darkening for walls: pick a separate darker level for vertical sides — just use level + 3 extra steps darker. Let's do `level = min(N-1, fog + (side? 4:0))`.

N = 24 levels.

Implementation of texture creation: base Uint32Array; levels[k] = shaded with factor f = pow(1 - k/(N), ...) Actually factor from 1 down to ~0.06.

Floor casting: also uses shading — good, use levels.

OK, let me write it.

```js
// ---- buffer
const buf = ctxOff.createImageData(VW,VH);
const buf32 = new Uint32Array(buf.data.buffer);
const zbuf = new Float64Array(VW);
```

Render loop:
1. Ceiling & floor cast (per row):
```js
const rayDirX0 = dirX - planeX, rayDirY0 = dirY - planeY;
const rayDirX1 = dirX + planeX, rayDirY1 = dirY + planeY;
for (let y=0;y<VH;y++){
  const p = y - VH/2;
  const posZ = 0.5*VH;
  const rowDist = (p===0)?0.0001:(posZ/p);   // p>0 => floor
  // floorX = posX + rowDist*rayDirX0 ... 
}
```
Standard: for floor rows (y > VH/2), rowDistance = posZ / p where posZ = 0.5*VH. For ceiling rows (y < VH/2), p = VH/2 - y and it mirrors: can compute with same loop but ceiling uses rowDist = posZ / (VH/2 - y)? Actually the classic code handles floor for the lower half and mirrors to ceiling in the same loop:

```js
for(let y = 0; y < VH/2; y++){
  const p = y + 1 - VH/2 ... 
}
```
I'll write straightforwardly: iterate y from 0..VH-1; if y < horizon → ceiling rowDist = posZ/(horizon - y); if y > horizon → floor rowDist = posZ/(y - horizon). With horizon = VH/2 (+ pitch offset, keep 0 pitch, no vertical bobbing of horizon; weapon bob instead). Since no pitch, horizon = VH/2 exactly.

Per row: stepX = rowDist*(rayDirX1-rayDirX0)/VW; similarly stepY; floorX = posX + rowDist*rayDirX0; then loop x: texIdx from 64x64 texture using fractional part; write shaded color; floorX+=stepX.

Cost: 2 rows loop = VW*VH = 400*250 = 100k texel writes. Fine.

Careful: very close rows (p small) → huge rowDist? p small → rowDist huge (far away) → fine; large p (near bottom) → rowDist small → near. Actually rowDist = posZ/p with p = y - VH/2: for y just below center, p small → rowDist huge (far). Yes correct.

Distance-dependent stepX makes far rows have large steps — fine, but at extreme distance fog covers.

To limit cost, we could skip floor casting beyond fog max by filling with fog color for rows near horizon. Optimization: for rowDist > maxDist, fill row with fog color directly. Good.

2. Walls via DDA per column x: cameraX = 2*x/VW - 1; rayDir = dir + plane*cameraX. Standard DDA, get perpWallDist, wallX, texX, texture by map type. Draw vertical strip with texPos stepping. Use zbuf[x] = perpWallDist.

3. Sprites: sort by dist desc, draw with occlusion test.

4. putImageData → drawImage scaled → draw weapon + effects with 2D vector on main canvas (or into buffer? Weapon as vector on main canvas is fine and looks better).

Also muzzle flash light: increase brightness temporarily (apply as fog boost / or overlay a translucent radial gradient).

Exit rendering: exit floor cell glowing — with floor casting, check cell == exit and use a special "exit pad" texture (pulsing green). Nice: since floor cast is per-texel, we know map cell of the floor texel → choose texture per cell. But that adds a per-texel cell check... Since floor casting moves across cells, we compute mapX/mapY per texel only when crossing boundary. Simplify: use the cell of the floor position (integer parts) per texel — a cellAt lookup per texel is fine (100k lookups, cheap-ish). But then texture selection per texel: `tex = (cell===EXIT) ? exitTex : floorTex`. I'll track current cell and current levels array, updating when cell changes. That's efficient enough.

Also draw a big glowing "EXIT" sign on the wall above the exit cell? Optional. Skip; use pulsing pad + HUD arrow + minimap.

Hmm, actually more classic and clearer: make the exit a wall tile with a glowing "EXIT" door texture, and reaching it means walking adjacent... no, must be reachable cell. Pad approach is fine and clear (minimap marker + HUD says "reach the green exit pad").

5. Minimap: DOM canvas? Draw on main canvas corner (screen-space, small, scaled). Yes, draw in the HUD layer as separate small canvas element positioned in corner — simplest: separate <canvas id="map"> 120x90 CSS, internal resolution MW*6 x MH*6, drawn each frame (cheap: rects). Fine.

Enemy attack rule + LOS: implement `lineOfSight(ax,ay,bx,by)` using DDA sampling (march with small steps, 0.05, checking cellAt solid). Simple and adequate.

Enemy shooting: hitscan with accuracy: hitChance = clamp(0.85 - dist*0.06, 0.15, 0.85); if hit → damage 6..14. Show tracer/flash and player hurt flash + sound. Also melee if dist < 1.0: guaranteed damage 12 with cooldown 800ms.

Player damage cooldown per enemy.

Alert: if enemy sees player (LOS and dist < 12) → activate; moves toward player until dist < 3.2 then keeps position and shoots. If no LOS for > 3s → idle. Also enemies shouldn't overlap each other: separation check (skip for simplicity? add simple check with collision against other enemies).

Enemy movement collision with walls: use same circle collision.

Death: on health<=0 → state 'dead', stop enemy attacks, show overlay. On all enemies dead → exit unlocked: set exitUnlocked = true, message, HUD changes, sound.

Win: player cell == exit cell && exitUnlocked → 'won'. If not unlocked and player steps on exit → message "EXIT SEALED — N GUARDS LEFT".

Also: enemies remain count HUD; health HUD; controls panel.

Restart: reset player pos/angle/health, enemies to initial defs, exit locked, state playing.

Now write HTML/CSS layout: retro bezel, dark background, header "MAZE STRIKER", canvas centered with integer scaling (fit via CSS max-width; keep aspect via width:100%; image-rendering: pixelated). HUD strip below/over canvas: health bar, enemies, message line, controls list, restart button. Overlays for dead/won.

Canvas resolution: set element width = VW*SCALE where SCALE computed... Let's set fixed internal canvas size = VW*2 = 800 x VH*2 = 500 and CSS scale to fit container (image-rendering: pixelated keeps crisp). Good, avoids dynamic resizing complexity. Actually let me make main canvas internal size = VW x VH? No — weapon drawn vector at low res looks chunky but on-brand, and DOM overlay text stays crisp. Hmm: I'd rather draw the weapon in the buffer too for full retro consistency? Weapon as vector shapes into the main canvas at 2x gives smooth-ish look which conflicts. Simplest: internal canvas 800x500, blit scene scaled (pixelated), draw weapon with vector paths at that resolution (looks fine, like Wolf3D sprites are also high-ish res). Let's do that. And crosshair drawn there too.

imageSmoothingEnabled=false for the scene blit.

Let me now write the code carefully.

Texture generation code:

```js
const TEX = 64;
function makeTex(fn){ // fn(x,y) -> [r,g,b]
  const t = new Uint32Array(TEX*TEX);
  for(let y=0;y<TEX;y++)for(let x=0;x<TEX;x++){
    const c = fn(x,y); t[y*TEX+x] = pack(c[0],c[1],c[2]);
  }
  return t;
}
function shadeLevels(tex, n){
  const out=[];
  for(let k=0;k<n;k++){
    const f = k===0?1: Math.pow(1 - k/(n-1), 1.6)*0.96 + 0.04; // hmm
```
Better: f from 1.0 down to fogFloor(0.08): `f = 1 - k/(n-1)` then apply gamma-ish: `f = Math.pow(1 - k/(n-1), 1.7)*0.94 + 0.06`.

Also blend toward a slight blue tint in fog? Add tint: shade multiplies rgb by (f*rTint...) — keep simple: multiply with slight blue increase for darkness: r*=f*0.95, g*=f*0.97, b*=min(1,f*1.15). Fine.

Noise helper with hash function (deterministic).

Textures:
- brick: rows of 16, brick width 32, mortar 2px, base color (150,70,55)... Wolf3D-ish gray/brown. Use (131,66,47) brick with noise ±14, mortar (170,164,150).
- steel panels (type 2): bluish (96,104,120) with panel seams and rivets.
- concrete blocks (type 3?): gray (118,118,112) with block grid and speckle.
- mossy: dark green-gray with splotches.
- floor: (86,74,60) tiles with grout grid 32 and speckle.
- ceiling: (52,56,64) with beams every 32 and speckle.
- exitPad: green (30,180,90) with chevrons and pulsing (brightness modulated by time — do via choosing shade level offset by time? easier: at draw time multiply... no, using levels only. Alternative: precompute two exit pad textures and alternate, or use levels index shift by time). I'll compute exit pad with `timeLevel` chosen per frame by selecting from levels array: `exitLevels[(k + pulse) % levels]`. Simplest: choose shade level for exit floor as levelIdx = clamp(round(3 + 3*sin(t*4))) — a pulsing brightness. Works since shading levels apply.

Wall type mapping: '1'→brick, '2'→steel, '3'→concrete, '#'→brick. Also 'E' cell: floor with exit pad. Also maybe 'X' wall = exit door texture (skip).

Sprite drawing (enemy): function makeGuardSprite(pose) returns {w,h,data:Uint32Array with alpha}. Draw on 32x48 canvas with ctx; read ImageData; note premultiplication issues: getImageData gives non-premultiplied RGBA. Pack as-is (a<<24|b<<16|g<<8|r) and test alpha != 0 when drawing. Good.

Guard drawing details (facing viewer):
- boots: dark brown rects at bottom.
- legs: gray-green.
- torso: field-gray/green with belt.
- shoulders.
- arms holding rifle across chest; in 'fire' pose, rifle raised with muzzle flash rect.
- head: skin tone with helmet, dark eyes, small mustache (Wolf3D-ish).
- Add outline (darker) via drawing a slightly larger dark silhouette first: approach: draw silhouette in near-black with 1px expansion by drawing each rect offset? Simpler: skip outline, add shading.

Poses: 'stand', 'fire', 'hurt?', 'die1' (falling, kneeling), 'die2'/'corpse' (lying flat, low). For corpse: zBase 0, hWorld small (0.25) — since sprite drawn with the body lying in lower part of canvas and rest transparent; using same 32x48 canvas with hWorld=0.8 but body drawn near bottom works too — simpler: keep hWorld 0.8 for all poses, drawing corpse content in bottom rows. Yes! Then all sprites same size and bottom anchored to floor. 

Death animation: hit → 3 frames over ~700ms then corpse remains (or remove after 2s; keep corpse for atmosphere).

Enemy types: maybe 2 visual variants (guard/enemy with different uniform color and health). Keep: 'guard' (green uniform, hp 100), 'officer' (gray/blue, hp 60, faster, less damage). At least 3 enemies total; I'll place 5.

Medkits: sprite drawn as white/red box; walking over heals 25, disappears; sound.

Now the weapon view model: draw with vector shapes into main canvas (ctx 2D at 800x500). A chunky double-barrel-ish rifle pointing away, centered-bottom, with bob offset (sin of walkCycle) and recoil (kick up). Muzzle flash: bright polygon + radial gradient + lighten whole scene.

Hit feedback: enemy "blood" splat sprite at hit point? Skip; use enemy hurt flash (draw sprite with white tint → could precompute a flash level: use levels index 0 for a "bright" look). Alternative simpler feedback: screen-space "HIT!" marker + enemy flashes by drawing with reduced alpha? I'll add: on hit, set enemy.flash=0.12s; while flashing, draw sprite using a white-highlighted version of the texture (precompute a 'whiteish' levels[0] with boosted colors) — I'll precompute sprite levels like textures: levels array; for flash, use a special levels array where colors are clamped bright (mix 70% white). That's cheap to build.

Sound: WebAudio with noise burst for shot, square blip for hit/kill, low tone for player hurt, chord for win, descending for death. Only create AudioContext lazily on first input.

Let me also handle: preventDefault for arrow keys/space.

Also "Display the controls" — a fixed panel listing keys.

Let's write the file now. I'll be careful with code size but thorough.

One more: performance of per-pixel loop in JS with function-call-free code. Use local vars.

Now write.

Detailed raycast DDA:
```js
function castRay(px,py,rdx,rdy){
  let mapX=Math.floor(px), mapY=Math.floor(py);
  const dX = rdx===0?1e30:Math.abs(1/rdx), dY = rdy===0?1e30:Math.abs(1/rdy);
  let stepX, stepY, sideX, sideY;
  if(rdx<0){stepX=-1; sideX=(px-mapX)*dX;} else {stepX=1; sideX=(mapX+1-px)*dX;}
  if(rdy<0){stepY=-1; sideY=(py-mapY)*dY;} else {stepY=1; sideY=(mapY+1-py)*dY;}
  let side=0, hit=0, type=0, guard=0;
  while(!hit && guard++<64){
    if(sideX<sideY){sideX+=dX;mapX+=stepX;side=0;} else {sideY+=dY;mapY+=stepY;side=1;}
    type=cellAt(mapX,mapY); if(type) hit=1;
  }
  const dist = side===0? (sideX-dX):(sideY-dY);
  ...
}
```
Return {dist, side, mapX, mapY, type}.

LOS function: march from enemy eye (z=0.5) to player; sample step 0.06: if cellAt solid → blocked. Also treat exit pad as non-solid. Good.

Also need: shots cannot damage enemy through a wall → use castRay distance and compare to enemy transformY depth. ✔.

Player start angle: face +x (east) or direction where corridor open. From map start (1,1) with row1 open to the right: face east (dirX=1,dirY=0).

Let me finalize map. I'll write candidate and verify with node (row lengths, borders, BFS, enemy cells floor).

Candidate map (20x16):

```
y0  "####################"
y1  "#S...#.....#......."?  -- need care.
```

Let me lay out an intended maze visually on a 20x16 grid. I'll design corridors 1 cell wide with rooms.

I'll write rows using a mental model:

Row 0: `####################`
Row 1: `#S...#.....#...#...#`
Row 2: `#.##.#.###.###.#.#.#`  hmm x=2..3 walls.
Row 3: `#.#..#...#.....#.#.#`
Row 4: `#.#.##.#####.###.#.#`
Row 5: `#.#....#...#.#...#.#`
Row 6: `#.####.###.#.###.#.#`
Row 7: `#....#...#.#...#...#`
Row 8: `####.#.#.####.##.###`
Row 9: `#....#.#....#..#...#`
Row10: `#.####.####.##.#.#.#`
Row11: `#.#....#..#..#.#.#.#`
Row12: `#.#.##.#.##.##.#.#.#`
Row13: `#...#..#.....#...#.#`
Row14: `#.#####.#####.###.E#`  hmm x=18 is E, x=19 '#'. Row14: `#.####...###.#.##.E#`? Let's think exit needs neighbor open.
Row15: `####################`

I must verify connectivity. Let me just run node BFS on candidate and iterate. Rather than agonize, write script now.

Let me define the map with wall type digits for variety: some sections '2' and '3'. I'll do BFS with any nonzero-solid char.

Plan: write index.html with the map, then run node validation script extracting MAP from the file (or duplicate). I'll write the map into a separate file `map.txt`? Requirement: only index.html at the end. I'll create a temp check script and delete it (only index.html required at end... "End with index.html present" — temp files probably fine but let me clean up anyway).

Let me first quickly design+validate the map in a scratch node script, then write index.html. Good approach.

Let me start.

Let me write a map validation script and iterate on the maze design.

Wait, my solid() function treats digits as solid — I didn't use digits yet. Let me run.

Mostly good. Let me tune: 131 reachable of 138 floor cells — 7 isolated, acceptable but let me open a couple. And fix enemy positions to reachable floor cells. Let me look at the map with coordinates.

Let me print the map with a grid so I can pick positions.

The maze is fine. Isolated: (8,5),(9,5) - inside dead pocket; (10,5),(10,6),(10,7)? Wait "10,5 10,6 10,7" means x=10,y=5 etc. Row5 x=10 is '#'? Row 5: `#.#....#...#.#...#.#` → x10='.', x11='#'. Hmm the isolated list printed: "8,5 9,5 10,5 10,6 10,7 7,14 13,14" — but the join used ' ' so entries: 8,5 | 9,5 | 10,5 | 10,6 | 10,7 | 7,14 | 13,14. Wait actually the list came out as "8,5 9,5 10,5 10,6 10,7 7,14 13,14" which parses as 7 items: (8,5),(9,5),(10,5),(10,6),(10,7),(7,14),(13,14). Fine.

These are small isolated pockets; harmless (they're just sealed nooks). But (7,14) and (13,14) near bottom row — harmless dead ends.

Actually let me open up a couple so the maze looks more intentional, and importantly ensure the exit area is a small room rather than a single cell reachable from one corridor. Exit at (18,14): row14 x=17='.', so exit connects up? row13 x=18='.'. Row 13: `#...#..#.....#...#.#` → x18='.', x19='#'. So (18,13) is floor and (18,14) floor connects vertically. Row 12 x=18='.' too: `#.#.##.#.##.##.#.#.#` → x18='.'. So there's a vertical corridor at x=18 from y=9? Row 9: `#....#.#....#..#...#` x18='.'; row 10: `#.####.####.##.#.#.#` x18='.'; row11 x18='.'; So the right column x=18 is a long corridor from y=1 to y=14 except... row 8 x=18='#'? Row8: `####.#.#.####.##.###` → x16='#',x17='#',x18='#'? chars: index:0'#',1'#',2'#',3'#',4'.',5'#',6'.',7'#',8'.',9'#',10'#',11'#',12'#',13'.',14'#',15'#',16'.',17'#',18'#',19'#'. So x=16 '.' at row8, x=17,18 '#'. So right corridor x=18 is blocked at y=8. Above: y=7 x=18='.'? Row7: `#....#...#.#...#...#` → x15'#', x16'.',17'.',18'.',19'#'. Yes. So x=18 corridor runs y=1..7 and separately y=9..14.

Exit approach: from y=9..14 column x=18; how to get there? row 9 x16..x18 open (x15='#'? row9: 0'#',1'.',2'.',3'.',4'.',5'#',6'.',7'#',8'.',9'.',10'.',11'.',12'#',13'.',14'.',15'#',16'.',17'.',18'.',19'#'). So y=9 x=16,17,18 open, connecting to x=16 at row 8 (open) → row 8 x16 '.' connects to row 7 x16 '.' → row7 open corridor x16..x18 → connects left to row7 x13? row7: x13'.'? index13='.',14'.',15'#'. Hmm row7: 0'#',1'.',2'.',3'.',4'.',5'#',6'.',7'.',8'.',9'#',10'.',11'.',12'.',13'.',14'.',15'#',16'.',17'.',18'.',19'#'. OK.

Good, connectivity is verified by BFS anyway.

Now pick 5 enemy positions on reachable floor cells away from start: e.g., (16,9), (12,3), (5,13)? Let's verify each: I'll test candidates in the script.

Also medkit positions.

Let me also add wall type digits for texture variety: I'll replace some '#' with '2' and '3' in the final map (doesn't change connectivity). Also 'A' for... no.

Let me now finalize map with texture variants and validate enemy/medkit spots.

I broke the map — my digit substitutions overwrote floor cells in some rows (I retyped rows incorrectly). Let me only replace '#' characters with digits, keeping '.' positions identical to the validated map. Do it programmatically instead: take the validated base map and assign wall types deterministically (e.g., by region) at load time in JS, rather than embedding digits. That's simpler and safer: wall texture type chosen by (mapX+mapY) region or a hash — e.g., type = 1 + ((Math.floor(x/5)+Math.floor(y/5)) % 3). That gives varied textures with zero map-editing risk.

Let me revert to the validated base map and generate texture variety procedurally by position. Good.

Good. Enemy spots (reachable floor): (8,1), (13,1), (16,7), (6,9), (16,13), (8,13). Medkits: (1,9)? Let's check distance from start (1,1) — (1,9) is far. Others: (3,13), (8,13)... I'll place 2 medkits at (1,9) and (16,13)? but enemy at (16,13). Use (13,1) enemy... let me finalize:

Enemies (6 total, need ≥3):
1. guard at (8,1) center (8.5,1.5)
2. guard at (13,1)
3. officer at (16,7)
4. guard at (6,9)
5. officer at (16,13)
6. guard at (8,13)

Wait, enemy at (8,1) is in the same corridor as start row 1 (start x=1, corridor x=1..4 then wall at x=5). Row1: x=1..4 floor, x=5='#', x=6..10 floor, x=11='#', x=12..16 floor, x17='#', x18..x19? x18='.',x19='#'. So (8,1) is not visible from start (wall at x=5). Good — player has a safe start.

Medkits at (1,9) and (3,13)? (3,13) is floor and reachable. Also (18,11) is floor? Row11: `#.#....#..#..#.#.#.#` → x18='.'? index:0'#',1'.',2'#',3'.',4'.',5'.',6'.',7'#',8'.',9'.',10'#',11'.',12'.',13'#',14'.',15'#',16'.',17'#',18'.',19'#'. Yes x18 floor and part of the right lower corridor. Put a medkit near the exit at (18,12)? row12 x18: `#.#.##.#.##.##.#.#.#` → x18='.'. Good.

Medkits: (1,9), (18,12). Also one at (8,13)? Fine — 2 medkits.

Now, write the game. Let me write the full index.html.

I'll be careful with the code. Structure:

```html
<!DOCTYPE html>
<html lang="en"><head><meta charset="utf-8"><meta name="viewport" ...><title>MAZE STRIKER</title>
<style>...</style></head>
<body>
<div id="app">
 <header>title + status chips</header>
 <div id="stage">
   <canvas id="view" width="800" height="500"></canvas>
   <canvas id="mini" width="200" height="160"></canvas>  (positioned absolute bottom-right? or in side panel)
   <div id="overlay">...dead/won messages + restart button</div>
 </div>
 <div id="hud"> health bar, enemies remaining, message, controls list, restart btn </div>
</div>
<script>...</script>
</body></html>
```

Put minimap in a side panel with controls. Layout: grid with canvas left and panel right on wide screens, stacked on narrow.

Let's write JS.

```js
(() => {
'use strict';
const VW=400, VH=250, SCALE=2;
const cv=document.getElementById('view'), cx=cv.getContext('2d');
cv.width=VW*SCALE; cv.height=VH*SCALE;
cx.imageSmoothingEnabled=false;
const oc=document.createElement('canvas'); oc.width=VW; oc.height=VH;
const ox=oc.getContext('2d');
const img=ox.createImageData(VW,VH); const buf=new Uint32Array(img.data.buffer);
const zbuf=new Float32Array(VW);
```

Textures:

```js
const TN=64, SHADES=16;
const pack=(r,g,b,a=255)=>((a<<24)|(b<<16)|(g<<8)|r)>>>0;
function rnd(x,y,s){ let h=(x*374761393 + y*668265263 + s*1442695040888963407?) ... }
```
Use simple hash:
```js
function hash(x,y,s){let h=x*374761393+y*668265263+s*2147483647; h=(h^(h>>13))*1274126177; h=h^(h>>16); return (h>>>0)/4294967295;}
```
Careful with large int overflow (JS doubles but Math.imul safer):
```js
function hash(x,y,s){let h=Math.imul(x,374761393)^Math.imul(y,668265263)^Math.imul(s,1442695041); h=Math.imul(h^(h>>>13),1274126177); return ((h^(h>>>16))>>>0)/4294967296;}
```

makeTex(fn) → Uint32Array; then shade(tex) → array of SHADES Uint32Arrays.

Textures list object: WALLS[1..3] each {levels}, FLOOR, CEIL, PAD.

Level selection for walls by position: type = 1 + ((mx*7+my*11) % 3)? Deterministic.

Rendering functions. Let's write the full loop.

Sprites: build with a helper `sprite(w,h,drawFn)` → {w,h,levels, flash} where levels = shaded versions preserving alpha; flash version = whiten.

Guard drawing function with pose & palette:

```js
function drawGuard(g,W,H,pose,pal){
  // units in px
  ...
}
```
Canvas 32x48. Draw with rects, use helper px(x,y,w,h,color).

Design (facing camera), pixel coordinates with the sprite 32 wide, 48 tall, feet at y=47:
- helmet: y 6..11, x 10..21 (color pal.helmet)
- head: y 11..17, x 12..19 skin
- eyes: y 13..14 x 13..15 and 17..18 dark
- neck y17..18
- torso: y 18..31, x 9..22 uniform, with chest straps
- belt y 29..31
- arms: left x 6..9 y19..28, right x 22..25 y19..28
- hands: skin small rects near rifle
- legs: y 31..44: left x 11..15, right x 16..20
- boots: y 44..47 x 10..15, 16..21
- rifle: dark gray rect diagonal-ish: horizontal at y 24..26 x 2..28 for 'aim' pose, plus barrel.
- 'fire' pose: rifle raised to eye level y 20..22, plus muzzle flash bright yellow star at muzzle end, arms up.
- 'die1': body tilted/kneeling: shift head lower, legs bent.
- 'die2' (corpse): draw lying body in bottom 10 rows: horizontal dark shape + head at side.

To simplify: parameterize with `crouch` offset & `pose`.

I'll write reasonable pixel code, and visually verify via screenshot.

Also draw shadow ellipse at feet (semi-dark). Since alpha blending isn't supported in my blitter (I only do opaque/transparent), shadow should be opaque dark gray-green; on floor it looks fine. Actually I do support transparency partially: skip a==0. I could add blending for a<255... let's implement: if alpha >= 220 → opaque; 0<alpha<220 → blend (cost only when triggered). Nice, enables soft shadows/edges. I'll implement simple per-pixel blend for the middle range.

Blood splat sprite on hit? Use a "hit flash" screen marker instead. Also spawn corpse + optional blood decals — skip decals.

Now write everything. Also HUD updates via DOM (textContent), message toast queue.

Sound:
```js
let AC=null; function ac(){ if(!AC){ try{AC=new (window.AudioContext||window.webkitAudioContext)()}catch(e){} } return AC; }
function beep(freq, dur, type='square', gain=0.06, slide=0){...}
function noise(dur, gain, filterFreq){...}
```

Player state: {x,y,dir,plane? } store angle a; dirX=cos a; dirY=sin a; plane = perpendicular * tan(fov/2) with planeX = -dirY*t, planeY = dirX*t. Careful with sign convention: standard lodev uses planeX = -dirY*tan? In lodev's tutorial: dir=(-1,0), plane=(0,0.66). So plane = rotate(dir, +90°)*t = (-dirY, dirX)*t. Let's verify orientation: with screen x from 0..VW, cameraX = 2*x/W - 1 (left=-1, right=+1), rayDir = dir + plane*cameraX. At right edge cameraX=+1 → rayDir = dir + plane. With dir=(1,0) (east, angle 0), plane=(-0,1)*t=(0,t) → rayDir=(1,t) which points +y. In my map, +y is downward in map rows, and world y = map y. In screen space the maze is top-down with y down. So turning right (clockwise on screen when y is down) = +y direction. With angle increasing = rotating from +x toward +y = clockwise in map view with y down = turning right. ✓ So Left arrow decreases angle, Right increases. ✓

Minimap: draw with player as arrow.

Enemy AI update (dt clamped to ~0.05):
```js
for(e of enemies) if(e.alive){
  const dist = hypot; const los = hasLOS(e.x,e.y,p.x,p.y) && dist < 16;
  if(los) e.alert=1;
  if(e.alert){
    if(dist>e.prefer) move toward player (speed);
    else if(dist<e.prefer*0.6) back off? -> just stop
    e.cd -= dt; if(los && e.cd<=0){ attack(); e.cd=e.rate; }
  } else { idle slight turn }
}
```
Attack: hitChance based on dist: `0.9 - dist*0.05` clamp .2..0.9; damage 5..12 for guard, 3..8 officer but faster. Also melee when dist<1.1: guaranteed 10 dmg. Also enemy fire pose animation (e.pose='fire' for 0.25s).

Death of enemy: e.hp<=0 → e.dying=0.55s, then alive=false → count; check exit unlock.

Player shoot: cooldown 0.32s; muzzle flash 0.07; recoil; damage 30 + rand 25; hit test as described; if killed → sound, decrement, message when 0 left.

Win/death overlays.

Restart: R key or button; full reset including medkits picked up.

Let's also handle keyboard state with `keys` object using e.code, prevent default for Space/arrows.

Mouse optional: click canvas → requestPointerLock; mousemove turns if locked. Also mouse click = shoot? Not required; I'll make mousedown fire (harmless, optional).

Time to write the code. I'll write the whole file at once, carefully.

Let me write out the final map as constant (validated base) and put wall-type variety derived by coords.

Exit cell: (18,14) — floor with glowing pad. Ensure floor cast picks exit texture when cellX==exitX&&cellY==exitY.

Also for the exit, maybe add a bright "EXIT" sign drawn on the nearest wall? skip.

Also make the exit visible from a distance: the pad glows green and pulses. Plus HUD arrow? Add a compass hint: "EXIT: NW/SE" indicator in HUD showing direction to exit relative to view. Nice and cheap: compute angle diff and show one of 8 directions. Good extra.

Let me code.

Floor casting with per-cell texture switch:

```js
function drawFloorCeil(px,py,a... ){
 for(let y=0;y<VH;y++){
   const isFloor = y>horizon;
   const p = isFloor? (y-horizon) : (horizon-y);
   if(p<=0){ fill row with fog color; continue }
   const rowDist = posZ/p;   // posZ = 0.5*VH (eye height 0.5 of wall)
   if(rowDist>FOGD){ fill row with fog/ceiling color; continue }
   ...
 }
}
```
Hmm: with rowDist computed from perspective and eye height 0.5 of wall height, floor at rowDist→∞ near horizon. FOGD ~ 14. For rows near the horizon, rowDist big → fog → fill with fog color. 

Careful about `posZ/p` when p=0 (horizon row) — handled.

Also level index from rowDist: k = floor(rowDist/FOGD * SHADES) clamp.

For the wall side shading: additional level offset.

Write floor loop:

```js
const rdx0 = dirX - planeX, rdy0 = dirY - planeY;
const rdx1 = dirX + planeX, rdy1 = dirY + planeY;
for (x=0;x<VW;x++){
  ...
}
```
Standard: floorX = px + rowDist*rdx0; stepX = rowDist*(rdx1-rdx0)/VW.

Texture coord: cellX = floor(floorX), cellY=floor(floorY); if changed → pick texture levels (ceil/floor/pad). texX = ((floorX-cellX)*TN)&(TN-1) etc.

Let me write it.

Also for the ceiling: use CEIL tex.

Wall rendering: for x: cameraX, DDA, perpWallDist, wallX. Draw column from drawStart to drawEnd where:
lineHeight = VH/perpWallDist (wall height 1 in world units, projected: lineHeight = VH/perpWallDist? In lodev: lineHeight = (int)(VH/perpWallDist) with the projection plane distance = VW/2 ... yes, standard: lineHeight = (int)(h / perpWallDist) where h = screen height, since wall height is 1 and camera at 0.5.
drawStart = -lineHeight/2 + VH/2 + pitch (0).

texX selection:
```js
wallX = side==0 ? py + perpWallDist*rayY : px + perpWallDist*rayX;
wallX -= Math.floor(wallX);
texX = (int)(wallX*TN);
if(side==0 && rayDirX>0) texX = TN-1-texX; if(side==1&&rayDirY<0) texX=TN-1-texX;
```
Step:
```js
step = 1.0*TN/lineHeight;
texPos = (drawStart - VH/2 + lineHeight/2)*step;
```
Then for y from max(0,drawStart) to min(VH-1,drawEnd): y0 adjust texPos accordingly. Simpler: compute step then texPos = (yStart - (VH/2 - lineHeight/2))*step where yStart = max(0,drawStart).

Level from perpWallDist.

Sprites: after walls. Compute transform via invDet. Draw columns.

Then blit: ox.putImageData(img,0,0); cx.drawImage(oc,0,0,cv.width,cv.height).

Weapon drawn in cx with coordinates scaled by SCALE... but the weapon coords should be in screen pixels of the main canvas (800x500). Fine: draw with sizes relative to cv.width/cv.height.

Damage vignette: after everything, if hurtTimer>0 fill translucent red rect over canvas.

Muzzle flash: lighten by drawing an additive yellowish radial gradient with globalCompositeOperation='lighter' briefly.

Crosshair at center.

Now the enemy sprite pose selection: 'stand','fire','die','corpse'. Build levels for both palettes (guard green, officer blue-gray) × 4 poses. 8 sprites × (SHADES levels) — memory: each 32*48*4B=6KB × 16 = ~100KB. Fine.

Blood/flash texture per sprite: precompute a 'white' variant for flash. Let me implement sprite.levels and sprite.flash (a levels array [0] replaced with whiten only). Simpler: sprite.white = Uint32Array whitened version, used when flashing at level index 0. I'll just do: if e.flashT>0 use `spr.white` else use `spr.levels[level]`.

Death animation: dying timer decreasing → pose 'die' then 'corpse'.

Enemy hit test uses halfW = 0.3 * (sprite aspect?) Let's compute from world height & aspect: hWorld=0.85, wWorld = hWorld*32/48? No — sprite 32x48 aspect → width = hWorld * (32/48) = 0.567. Half = 0.28. Good. Officer slightly smaller.

Now the vertical extent for hit test: also require the ray at eye level hits (player ray z = 0.5, guard spans 0..0.85 → 0.5 is inside) ✓.

Let's write out the file now. Also include an intro/instructions panel.

Also handle window blur → clear keys.

Let me write.

Also HUD: health bar width %, "GUARDS: n", "EXIT: LOCKED/OPEN", compass to exit, message line, controls.

Overlay for dead/won with big text and Restart button.

Write the file.

One more consideration: initial viewpoint must be stable — after restart, player at start facing east.

Let me code the JS carefully now, then test in browser.

For performance in the pixel loops, avoid function calls; precompute arrays.

Let me now write index.html.

Let me test in the browser quickly and fix essential issues. I know there are a couple of bugs:
1. In renderScene floor loop, `const c=lvArr[(ty<<6)|tx]` — ty is fractional multiplication `(fy-gy)*TN & (TN-1)` — bitwise & on float coerces to int, ok.
2. `if(c!==0 || true)` — silly but harmless; remove.
3. dirName logic is broken/nonsense. Fix to simple.
4. drawMini has a garbage line with `(dx-(-dy)*0.6)` — remove.
5. Exit cell in floor: cellType returns 0 for exit cell since it's '.'—handled by explicit EXIT check. ok.
6. LEVEL_OF function declared after use inside loop — function declaration hoisting within the same function scope, fine.

Let me run the browser to check console, then fix.

Rendering works. Issues visible:
1. There's an enemy sprite directly in front of the player at the start?! A guard appears right in front (the tall thing in the middle-bottom). Actually that's the gun view model... it looks like a guard sprite standing in the center — hmm, the shape with helmet + eyes at top and hands... That's actually the gun drawn as vector? The gun is drawn at bottom center — the thing at center appears to be a guard sprite (helmet, eyes, torso, hands). Wait, at start facing east along row 1, wall at x=5 should block. The corridor shows a wall ahead (steel panels) — and in front of it there's a "guard" figure. That's likely a guard at (8,1)? No, wall at x=5 blocks.

Look closer: the object in center has a helmet, dark eyes, torso, and tan hands — that IS a guard sprite. But it could be the gun view model rendered weirdly? The gun has receiver + barrel + wooden grip + hands (tan rects) — yes! The gun drawing: R(-52,-96,104,96,mid) receiver, barrel up, wooden bands, and two tan "hands". The top part with "eyes" is the `R(-8,-178,16,10,"#0c0e11")` slot and `R(-11,-196,22,14,lite)`. So it's the gun, but it reads like a person. It's fine-ish but ugly. The gun occupies a big part of the screen. Let me make the gun narrower/lower so it doesn't look like a guard: reduce receiver width, move down, and make it read as a weapon.

2. The scene looks good otherwise. Wall textures visible, floor/ceiling textured.

3. Exit bearing "FWD-RIGHT" — my dirName is buggy but produces plausible output; fix it properly.

4. Minimap: the extra fan line code is garbage but seems invisible; remove.

Time is short (~4 min). Let me do quick essential fixes: gun shape, dirName, remove junk lines. Then test movement/shoot via keyboard events and reload + screenshot.

Fix dirName: compute screen-relative bearing: angle 0 = ahead. 
```js
function dirName(a){ normalize to [-PI,PI]; const names=["AHEAD","FWD-RIGHT","RIGHT","BACK-RIGHT","BEHIND","BACK-LEFT","LEFT","FWD-LEFT"]; return names[Math.round(((a+Math.PI)/(Math.PI*2))*8)%8]; }
```
With a = atan2 target - player.a. Note: positive a = to the right (since y down and clockwise positive). Index: ((a+PI)/(2PI))*8 → a=0 → index 4 → "BEHIND". Need mapping so a=0 → AHEAD. Use idx = Math.round((a + Math.PI*2) / (Math.PI/4)) % 8 with names starting at AHEAD going right: names=["AHEAD","FWD-RIGHT","RIGHT","BACK-RIGHT","BEHIND","BACK-LEFT","LEFT","FWD-LEFT"]; a=0→0 AHEAD ✓; a=PI/2 (target to the right) → 2 RIGHT ✓; a=-PI/2 → 6 LEFT ✓. Good.

Gun: make it look like a rifle from first person: narrow barrel, V-shaped body at bottom corners. Let me redraw:
- body: trapezoid from bottom center widening down.
- barrel: narrow vertical rect centered, from y=-150 to -60, width 26.
- muzzle sight at top.
- hands at sides lower.

I'll rewrite drawGun's rect list with a slimmer profile and lower position (translate to gy = H + 30).

Also the muzzle flash origin should be at the barrel tip: my = H - 196*s → with new barrel top at -170, keep mx = W*0.5 + bob, my = H - 172*s.

Let me apply edits.

Note: `void set;` line remains and `const cxCell`/`set` unused — harmless. Also I left `let texX` etc fine.

Now test: reload, screenshot, then simulate keys (W forward, arrows, space) and check console + health/HUD.

The browser tool's `key`/`type` action: I can send key text. Let me reload and test: press Space (fire), press W a few times (hold not possible; use repeated key events — my code reads keys map on keydown/keyup; the harness 'key' action likely dispatches a keydown+keyup, so a single frame of movement). Better: use `type` with repeated chars? For movement verification, I can sample scene stability and check the HUD after firing.

Let me do: reload → screenshot; then key Space → screenshot (muzzle flash may be gone by then, but recoil/scene changes); then check console errors.

Time is short. Priorities: verify no console errors, verify shooting works (guards count decreases eventually?), verify restart. Let me do a quick automated check instead: use the browser 'key' action with arrows and screenshot.

The gun now reads as a weapon (slim barrel pointing away). Good.

Now test movement/turning/collision and shooting. The harness `key` action sends one key press; my movement is continuous based on held keys, so a single press+release yields ~1 frame of movement. To verify movement meaningfully, I can use `type` with many characters (each generates keydown/keyup) — e.g., text "wwwwwwwwww" would generate rapid key events; movement per frame is small (2.6*dt ≈ 0.04 units/frame) so 10 presses ≈ 0.4 units. Might be visible.

Better verification approach: temporarily drive the game state? I shouldn't add debug hooks to the final file. But I can check via the browser: use `key` repeatedly and take a motion screenshot to see if the scene changes.

Given ~3 minutes left, let me do: press ArrowRight a few times + screenshot (turning changes view noticeably), then press Space (fire) with screenshot to see muzzle/recoil + HUD message "Missed", then check that guards count stays 6 and no console errors. Then finish.

Actually a good check of shooting: turn toward the wall ahead and fire — message "Missed" appears in HUD. To hit a guard, need LOS. Let me instead verify hit logic by moving forward into the corridor... too long.

Let me just do key presses and check the DOM text for the message + no console errors.

Turning works (view rotated slightly right; minimap arrow rotated; bearing message changed). Now test firing and movement. Let me use `type` to hold keys: type "wwwwwwwwwwwwwwwwwwww" — 20 keydowns. Then screenshot. Also fire with space.

Note: exit bearing says FWD-RIGHT which is correct (exit is far right/ahead? player at (1.5,1.5) facing east, exit at (18.5,14.5) → target angle atan2(13,17)=0.65 rad vs player.a≈0.04 → a≈0.61 → index round(0.61/0.785)=1 → FWD-RIGHT ✓).

Let me fire and move.

No movement occurred — the `type` action probably dispatched key events but the player is blocked by the wall at x=5 directly ahead (player at x=1.5, wall at x=5 → can move ~3.2 units). The minimap player dot hasn't moved and the view is identical to before. So `type` likely didn't send W keydowns to the window (maybe it types into focused element / no key events with e.code). Hmm, the earlier ArrowRight key press DID work (view rotated). So `key` works but `type` may not produce e.code='KeyW' events.

Let me use several `key` presses of "w" — each produces small movement (~0.04/frame, only during the frame(s) between keydown and keyup, likely 1 frame). 20 presses would give ~0.8 units. Let me try 12 key calls... that's many tool calls. Instead, do 3 key presses and screenshot with `motion` to see change? Time is very limited (~2 min).

Alternative: verify movement logic by node-side reasoning — the moveEntity/canStand code is straightforward and collision is proven by the fact that pressing 'w' didn't push through the wall ahead... but that's not proof of movement working.

Let me do a quick sequence: 4 key "w" calls in one block (independent calls allowed in parallel), then screenshot.