Wolfenstein raycaster · mimo-v2.6-pro

Let me build the game in index.html.

Key parts: raycaster with procedural textures (canvas-generated texture atlas), sprite enemies, shooting with line-of-sight check, health, enemy AI (chase + attack when close/visible), exit tile, win/game over, restart.

Let me write the code carefully.

Plan:
- Grid map, e.g. 16x16, walls 1, exit tile value 2.
- Player start position, angle.
- Textures: generate 64x64 canvases for wall types (stone brick, mossy, exit door). Use per-column texture sampling into an ImageData for the 3D view.
- Rendering: canvas 3D view width ~640 (internal resolution e.g. 480x270 scaled? Let's use internal 640x360 and CSS scale). Use DDA raycasting with texture coordinates.
- Floor/ceiling: simple gradient or flat colors with shading, plus textured floor optional — flat colors fine ("textured grid maze" required for walls).
- Enemies: billboard sprites drawn procedurally onto offscreen canvas (guard with face, gun). Draw with per-column depth check against z-buffer.
- Weapon: drawn procedurally (pistol/hand sprite) at bottom with muzzle flash and bobbing.
- Shooting: hitscan — check enemies in a small angle cone, nearest, with wall occlusion via ray march/DDA distance comparison.
- Enemy attack: if distance < some range and line of sight, do damage on cooldown with a clear rule shown in HUD/instructions.
- Health bar, enemy count, exit lock message.
- Exit: tile 2, if all enemies dead and player steps on exit -> win.
- Restart button and R key.
- Controls display.

Collision: circle vs grid, check cells with radius.

Let me write it now. Keep code robust.

Textures: create function makeTexture(type) returning ImageData/array of pixels 64x64 RGBA. I'll create Uint32Array? Simpler: build offscreen canvas per texture and use getImageData to get data array, then sample per pixel with shading multiply.

Rendering approach: create ImageData for the view once, fill pixels each frame with per-pixel wall column shading and floor/ceiling gradients. For sprites, drawing procedurally scaled onto the main canvas after putImageData — need sprite occlusion via z-buffer per column. Easiest: draw sprites using drawImage per column strip (1px wide source column scaled), skipping columns where sprite distance > zbuffer. That's straightforward: for each screen column within sprite bounds, if spriteDist < zbuf[col], drawImage(spriteCanvas, srcX, 0, 1, h, col, drawStartY, 1, drawH). That's up to a few hundred drawImage calls per sprite — fine for a handful of sprites.

Actually to be safe with perf, internal width 480, height 270? Let's use 512x288 internal, CSS scale up with image-rendering pixelated. Good Wolfenstein look.

Shooting feedback: muzzle flash, weapon recoil, hit flash on enemy (red flash / enemy death animation — falling sprite). Keep it simple: enemy has state alive/hitFlash/dying(deadTimer -> removed as corpse? just keep dead sprite or remove). Enemy count = alive.

Enemy sprites: generate a few frames: guard standing, guard firing, guard hit, guard dead. I'll draw with canvas 2D shapes: body (uniform), head, eyes, gun. Function drawGuard(ctx, opts).

Also minimap? Not required. Skip, or small minimap helps testing. I'll add a small minimap top-right — helpful for verification, optional. Keep it: shows walls, player, enemies, exit. Fine.

Let me write.

Raycasting details:
- FOV 60°, plane from direction.
- Standard Lodev algorithm, storing perpWallDist in zbuffer.

Texture sampling: texX from wallX; texY = ((y*2 - height + lineHeight) * texH/lineHeight)/2... standard.

Shading: distance fog — darken with depth: shade = clamp(1 - dist/maxDist) etc. Plus side shading (NS walls darker).

Floor/ceiling: fill with vertical gradient per scanline computed once into a lookup, or just fill two gradients via ctx before putImageData? putImageData overwrites everything. So do floor/ceiling in the ImageData fill loop: for each y above horizon use ceiling color gradient, below horizon floor color. Precompute row colors array.

Ok. Let's write the pixel loop:

for y in 0..h: if y < horizon -> color = ceilingRow[y] else floorRow[y]. Fill whole row via Uint32Array fill. Then draw walls columns over it.

Use Uint32Array view of ImageData.data with little-endian ABGR packing.

Textures as Uint32Array 64*64.

Let me define textures:
1. Stone brick: base gray with brick pattern, mortar lines, noise.
2. Mossy stone: greenish patches.
3. Metal/tech wall: dark with rivets.
4. Exit door: with glowing "EXIT" green stripes.

Map: let's design 16x16 with border walls, interior corridors, exit at far corner.

Map layout (1 = wall, 0 = floor, 2 = exit):

```
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1
1 0 1 1 0 0 1 0 1 1 1 0 1 1 0 1
1 0 0 1 0 0 0 0 0 0 1 0 0 1 0 1
1 1 0 1 0 1 1 1 1 0 1 1 0 1 0 1
1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1
1 0 1 1 1 1 0 1 1 1 1 1 0 1 1 1
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1
1 1 1 0 1 1 0 1 0 1 1 1 1 1 0 1
1 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1
1 0 1 0 1 0 1 1 1 1 1 1 0 1 0 1
1 0 1 0 0 0 0 0 0 0 0 1 0 0 0 1
1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1
1 0 1 1 1 1 1 1 0 1 1 1 1 0 2 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
```

Hmm exit tile at (14,14) — value 2 is walkable floor with exit texture on walls? Better: exit is a floor tile marked as exit zone, and the wall behind is exit door texture. Actually simpler: exit tile is a wall-type tile you reach... "reaching it shows a win state" — so it should be walkable. Make tile 2 a walkable exit pad; when player enters tile and all enemies dead -> win. Render the tile floor differently? Since floor is flat colored, I could render exit pad in minimap and draw an overlay glow when near. Let's make the exit a walkable pad and place a door wall texture adjacent... Simpler: exit tile value 2 is walkable floor; render floor color for that region? Not per-pixel easy with flat floor... Actually I can do per-pixel floor shading cheaply? Flat fill is per row; checking cell for each pixel would cost. Alternative: after drawing the 3D view, project the exit pad as a sprite-like billboard (glowing green marker floating) at the exit location with z-buffer occlusion. That works and looks nice — a floating "EXIT" sign/pad glow. And minimap shows exit.

Hmm but "Textured grid maze" walls satisfy texture requirement. Fine.

Actually simplest robust: make exit a wall tile (2) rendered with door texture, and reaching = within 1.2 tiles in front... "reaching it shows a win state" — walking into it. I'll do walkable pad + billboard beacon + minimap. When all enemies dead, beacon turns green and player walking onto exit tile triggers win. When locked, beacon red and message "Exit locked — eliminate all enemies".

Enemies: at least 3, place 5. AI: if line of sight and dist < 12, move toward player (with simple collision), and attack when dist < 6 and LOS and cooldown: deal 8 damage, with a brief attack flash + sound-less. Show "under attack" red vignette.

Enemy movement: move toward player if LOS, avoid walls by axis-separated movement. Also keep min distance ~1.2 to avoid overlap.

Shooting: fire rate limit 0.25s. Raycast: find enemies within angle threshold atan(size/dist) and LOS clear and closest; damage 34 (3 shots). Also muzzle flash + tracer? Recoil animation and crosshair flash.

Let's write the code now. I'll be careful with the game loop, delta time, and key handling.

Health: 100, damage per attack 10, attack cooldown 1.2s per enemy.

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

Restart: reset player pos/angle, health, enemies from spawn list, state to playing.

Mouse optional: add pointer-lock-free mouse look on mousemove when pointer locked via click. Optional — I'll add simple mouse turn when clicking canvas (drag-free) but ensure keyboard works. Maybe skip mouse entirely to avoid bugs. The requirement says optional. I'll add minimal: mousedown+drag to turn? Skip; keep keyboard + mention optional mouse not implemented. Actually a small mouse look with requestPointerLock is nice but risk. I'll include pointer-lock mouse turn guarded in try/catch — low risk. Let's include it minimally.

Now write out the file.

Details for rendering loop:

```js
const VW = 512, VH = 288;
```
FOV: dir vector and plane: planeLen = tan(30°) = 0.577.

DDA:
```
for x in 0..VW-1:
  cameraX = 2*x/VW - 1
  rayX = dirX + planeX*cameraX; rayY = dirY + planeY*cameraX
  mapX = floor(px), mapY = floor(py)
  deltaX = abs(1/rayX) ...
```
Standard.

wallX = (side==0) ? py + perp*rayY : px + perp*rayX; wallX -= floor(wallX).

texX = floor(wallX*texW); flip if (side==0 && rayX>0) || (side==1 && rayY<0).

lineHeight = floor(VH / perp); drawStart = -lineHeight/2 + VH/2 (+ pitch? no pitch). Add a small horizon offset for bobbing? keep 0.

texture sampling per pixel:
```
step = texH/lineHeight; texPos = (drawStart - VH/2 + lineHeight/2)*step;
for y = max(0,drawStart) .. min(VH-1, drawEnd):
   texY = floor(texPos) & (texH-1); texPos += step;
   color = tex[texY*texW+texX]
   shade: factor = fog
```
Shade computed per column (cheap): brightness = side==1 ? 0.7 : 1.0, times distance fog: fog = clamp(1.15 - perp/14, 0.25, 1). Also flicker? no.

Apply shading by multiplying RGB channels — do with bit ops on the packed uint32.

Little-endian packing: 0xAABBGGRR.

shadeColor(c, f): r = (c & 255)*f | 0 etc.

Sprites: for each enemy sorted by distance desc, compute transform using inverse camera matrix:
```
invDet = 1/(planeX*dirY - dirX*planeY)
transformX = invDet*(dirY*spriteX - dirX*spriteY)
transformY = invDet*(-planeY*spriteX + planeX*spriteY)
spriteScreenX = (VW/2)*(1 + transformX/transformY)
spriteH = |VH/transformY| * scale
```
Then per-column drawImage strips with zbuffer check.

For the exit beacon sprite, same mechanism.

Weapon: draw after everything with ctx.drawImage of a generated weapon canvas, plus muzzle flash overlay (radial gradient) and screen flash.

Damage vignette: red overlay with alpha decaying.

HUD: HTML overlay divs with health bar, enemy count, message, controls list, and buttons Restart. Game over / win overlay with Restart button.

Now the sprite generation: draw guard at 64x96 canvas.

drawGuard(ctx, w, h, state):
- legs: dark gray rects
- body: uniform (blue-gray) with belt
- arms holding gun
- head: skin tone circle with helmet, eyes, mouth
- gun: dark rect in front
- hit state: red tint overlay (use globalCompositeOperation 'source-atop' fill red alpha)

I'll write a function that draws with parameters and returns canvas.

Also dead sprite: flattened shape (blood pool + fallen body). Simple.

Enemy object: {x, y, hp, state:'alive'|'dead', hitFlash, attackCd, animT}.

Let's now write out the whole file. I'll write carefully then test in browser.

Controls display: a panel listing W/S move, A/D strafe, ←/→ turn, Space shoot, R restart.

Also add touch? No.

Time to write. Aim for correctness.

One thing: performance of per-pixel loop at 512x288 = 147k pixels — fine.

Let me handle "delta" in animation: requestAnimationFrame with dt clamped.

Enemy line-of-sight: ray march from enemy to player step 0.15 checking isWall.

Player collision: try move x and y separately; radius 0.25; check cells at (x±r, y±r).

isWallCell(x,y): map cell != 0 (and exit tile 2 is walkable, treat as floor). Map values: 0 floor, 1 wall, 2 exit floor. Wall texture index derived from position for variety: texId = (mapX*7 + mapY*13) % 3 ... or store a separate texture map. Simpler: texId = ((mapX + mapY) % 2 == 0) ? 0 : 1, plus border walls use 2 (metal). Let's compute: if mapX==0||mapY==0||mapX==W-1||mapY==H-1 -> 3 (metal/dark). else (mapX*3+mapY*5)%3 -> 0,1,2 variants. Fine.

Now writing the file.

For minimap: draw on separate small canvas via JS each frame (e.g., 8px per cell, 16x16 -> 128px). Include player direction line, enemies red dots, exit green.

Let me write everything.

Regarding pointer lock mouse look: 
```js
canvas.addEventListener('click', ()=>{ if(state==='playing' && canvas.requestPointerLock) canvas.requestPointerLock().catch(()=>{}); });
document.addEventListener('mousemove', e=>{ if(document.pointerLockElement===canvas){ player.angle += e.movementX*0.0025; } });
```
requestPointerLock may return undefined in some browsers -> guard.

Shooting also on mousedown? Space required; add mouse click to shoot too when locked — but click also requests lock. Fine: on mousedown shoot.

Careful: clicking Restart button shouldn't shoot — check event target.

Now write.

Win check: when player's tile == exit tile and aliveEnemies==0 -> state 'win'. If aliveEnemies>0 and player on exit -> message "Exit locked!".

Message display: HTML element updated.

I'll write the code now in full.

Text on walls? skip.

Code sketch of main loop:

```js
function update(dt){ ... }
function render(){ ... }
function frame(t){ dt = min(0.05,(t-last)/1000); last=t; if(state==='playing') update(dt); render(); requestAnimationFrame(frame);}
```
Even in gameover/win we still render (frozen scene) with overlay.

Also weapon bob: bobT accumulates with movement; weapon offset = sin.

Muzzle flash: flashT decays; draw radial gradient at gun tip.

Hit feedback: crosshair turns red briefly when hit enemy; also "hitmarker".

Fire logic:
```js
function shoot(){
  if(state!=='playing' || fireCd>0) return;
  fireCd = 0.28; flashT = 0.09; recoil = 1;
  // hitscan
  let best=null, bestDist=1e9;
  for(const e of enemies){ if(e.state!=='alive') continue;
    const dx=e.x-player.x, dy=e.y-player.y; const dist=Math.hypot(dx,dy);
    const ang=Math.atan2(dy,dx)-player.angle; normalize to [-PI,PI]
    const halfWidth = Math.atan2(0.42, dist);
    if(Math.abs(ang) < halfWidth + 0.03){ if(dist<bestDist && hasLOS(player.x,player.y,e.x,e.y)){best=e;bestDist=dist;} }
  }
  if(best){ best.hp -= 34; best.hitFlash=0.25; hitmarker=0.2; if(best.hp<=0){best.state='dead'; best.deadT=0; } }
}
```
Since shot requires LOS, no wall shooting through.

hasLOS: step along the segment checking isWallCell.

Enemy attack rule: "If an enemy has line of sight to you and is within 7 tiles, it fires every 1.4s dealing 9 damage (with a brief red flash)." Also show this rule in the controls panel so it's "clear".

Enemy movement: if LOS and dist > 2.2 and dist < 14: move toward player at speed 1.6 (slow-ish). Also maybe strafe slightly. Keep simple.

Now finalize numbers: player speed 3.0 units/s, strafe 2.6, rotation 2.4 rad/s.

Let me write the file.

Empty dir. Write index.html.

Now test in the browser. Let's load and screenshot, inspect console.

Note a potential issue: `frameLoop` calls `render` which references `player`, fine. Also `resetGame()` calls `updateHUD()` which uses `aliveCount` — fine.

Potential issue: in render sprites, glow is drawn even for enemies? s.glow only for exit. Fine.

Another: drawing sprite stripes with drawImage 1px source columns — with imageSmoothingEnabled default true, scaled drawImage of 1px wide column to 1px wide dest = fine.

Issue: `pixels.fill(c, row, row+VW)` — Uint32Array fill works.

Issue: the floor/ceiling are drawn first, then walls overwrite. Good.

Let's load in browser.

Now run the browser tool. Let's screenshot first.

Error: "rng is not a function" — in makeTexture painters, I call `rng()` but rng is an object `{s:...}`. I defined `rnd(seedObj)` function but used `rng()`. Fix: make painter use `rnd(rng)`. Simplest: change the object to a function-with-state. Let me change `rnd` usage: replace `rng()` with `rnd(rng)` in painters. Occurrences: in TEX_BRICK, TEX_MOSS, TEX_METAL, TEX_TECH.

Actually simpler: define `function makeRng(seed){ let s=seed; return ()=>{ s=(s*1664525+1013904223)>>>0; return s/4294967296; };}` and use `const rng = makeRng(12345);`. But then the `rnd` function unused. Let me edit.

Also the RESTART button overlaps the ENEMIES box — I set margin-top 64px but the top buttons div is at top 3.4% right 2.2%. The enemyBox height ~ 90px at this scale. Move topButtons to below with more margin, e.g. top: 3.4%; margin-top: 120px? The box height depends on viewport. Better: place RESTART button at bottom center-left? Or put it in the controls bar area. Simplest: position topButtons at right: 2.2%; bottom: 3.2% ... but minimap is there. Put RESTART in the top-left area? Health box is there. Let's place restart button at bottom-right above the minimap? Or place it left-bottom above controls.

Alternative layout: put RESTART inside the enemyBox panel area as a button below it with a fixed offset relative to the box. Use a container flex column in top-right: wrap enemyBox and button in a div with flex column gap. Let me restructure: create a wrapper div positioned top-right containing enemyBox and the restart button.

Also minimap appears empty/black in screenshot — that's because render crashed before renderMinimap. Fine after fix.

Also game canvas appears black due to crash.

Let me apply edits.

Also `#enemyBox` rule had position absolute properties; now `#rightCol #enemyBox{position:static}` overrides. But `.bar` has `position:absolute` — overridden. Good.

Also enemyBox width:24% -> overridden to 100%.

Reload browser.

Rendering works. Issues visible:

1. There's an enemy right at the start (x=4.5,y=1.5) visible — that's fine, but it's very close and odd: it looks like the enemy is overlapping a wall?? Actually the enemy appears at center partially behind the wall corner — that's occlusion working (looks a bit odd but fine).

2. The weapon sprite is huge and mostly weirdly placed — I see beige hands at the bottom right, and gray blocks in the middle. The weapon scale 1.55 * 320 wide = 496 px wide of 512 — too big and the drawing looks wrong: the weapon appears to be drawn with dark shapes in the center and hands at bottom. Actually the visible big grey rectangles center-bottom look like the weapon body but drawn too high/large. Let me reconsider: wH = 200*1.55 = 310, wy = 288 - 310*0.86 = 288-266 = 22... so the weapon covers nearly the whole screen height. Too big. Reduce scale to ~1.0 and anchor at bottom: wy = VH - wH*0.92.

Also the weapon art: the top of the sprite (barrel at y=38-100) is at the screen center. That's roughly where a gun should point. But it looks like the gun is drawn as a plain gray rectangle — my drawing is quite crude but acceptable. However the hands at the bottom (beige) look cut off oddly. Let me improve the weapon sprite drawing a bit and scale it better.

3. Minimap: rendering fine, shows walls, enemies, player.

4. The wall textures look decent though mossy texture is heavily noisy (black speckles) — the "crack" pattern gives black dots everywhere. Look at right wall: lots of black speckles. The crack condition `((x*7 + y*13 + ((x*y)%11)) % 29) < 2` — that's fine but the noise `n` variance and moss threshold produce speckles. Actually the black speckles are the crack lines which come out as isolated pixels — ugly. Improve: make cracks rarer and draw as connected lines, reduce noise.

5. Floor/ceiling: the ceiling looks near black at the top and there's a weird horizontal band. Actually looks OK-ish.

6. Enemy at start is extremely close — player at (1.5,1.5) facing +x, enemy at (4.5,1.5) — 3 tiles ahead in the same corridor. It's already attacking. That's fine but for testing movement near start it's fine. Maybe move that enemy a bit further/into another room to give a calmer start: move to (4.5, 5.5)? Row 5 col 4 is floor (row5: 1,0,0,0,0,1,... => index 4 = 0). Let's move the first enemy to (4.5,3.5)? row3 col4 = 0 (row3: 1,0,0,1,0,...). Hmm keep one enemy visible ahead for "visible enemies" verification but a bit further: (5.5, 1.5) is 4 tiles ahead — visible at start. Actually the corridor row 1 is open from x=1..5, wall at x=6. So an enemy at 5.5 would be right against the wall. Let's place first enemy at (4.5, 1.5) but it starts shooting right away. Alternatively place at (3.5,1.5)? Closer. Keep it visible but maybe that's fine — it demonstrates enemies visible & attacking. But for "test movement near starting area" it's fine.

Hmm, but the enemy at 3 tiles distance is basically on the player at start. I'll move it to (5.5, 5.5)?? Not visible at start. Let's think about "visible enemies" requirement — it just means enemies are rendered in the view. Having one visible at start is good verification. I'll keep one visible at start but a bit further: place at (5.4, 1.5) is 3.9 tiles. Wall at x=6 so it stands near the wall. Fine — but the sprite may look clipped against the wall. Instead put it in the corridor to the south: at start the player faces +x; enemy at (2.5, 5.5)? not visible.

Compromise: enemy at (5.2, 3.2)? row 3 col 5 = 0. From player at (1.5,1.5) facing +x with FOV 66°, direction to (5.2,3.2) is atan2(1.7, 3.7) = 24.6° — within 33° half-FOV. Visible! Good, and it's ~4 tiles away. Let me use that.

7. The enemy sprite looks like a grey figure — the head is barely visible? In the screenshot, the enemy's head area looks like a grey block with a small skin-colored arm. The sprite is 96x144 drawn with shapes — looks okay but the helmet arc: `g.arc(w*0.5, h*0.19, w*0.16, Math.PI, 0)` draws upper half circle — fine. In the screenshot at small scale it looks blocky. Acceptable.

Actually wait — the sprite in the screenshot looks wrong: I see a tan/beige diagonal block near the top of the figure, and the figure's "head" is not obvious. Let me zoom by rendering the sprite at large scale... I could just improve the drawing. Let me check by taking a screenshot of a debug? Simpler: trust the shapes, but the "gun arm" dark rect at 0.6-0.82 x might read oddly. The beige diagonal is likely the face circle at (0.5,0.22) with radius 0.15*96=14 — that's the head, which appears at the top... but in the screenshot the beige is offset to the left at the top of the figure. Hmm, that beige diagonal shape at (570,340) — this is probably the head, but the figure looks like the head is at upper-left. Actually it might be the exit beacon? No.

Let me look more carefully: the figure in the center: dark grey tall rectangle, with a smaller grey square above. Looks like the sprite columns are being drawn at wrong widths... Actually could be the sprite strip loop: srcX computed as `Math.floor((stripe - startX) / Math.max(1, spriteW) * s.img.width)` — correct. drawImage height Math.ceil(spriteH) at y=startY. Since spriteH for dist ~4 is VH/tY ~ 288/4 * 0.92 ≈ 66 px tall, and spriteW = 66*(96/144)=44. Hmm, in the screenshot the figure looks ~120px tall at display scale (display is 2.3x), so ~50px internal. OK.

But the shapes: at 50px tall, the head circle radius 14/144*50 ≈ 5px. The screenshot at 2.3x → 11px radius. The beige blob is about that size. So it IS the head, and the figure looks right-ish, just crude and the head appears offset left... whatever, it's at x center 0.5*96=48 of 96 → centered. In the screenshot, the beige blob is at the left edge of the dark figure. Hmm.

Wait — maybe the sprite is being drawn twice: once with the fog overlay loop. No.

Possibility: the enemy is partially occluded by the wall at the center of the screen! The wall column (grey block in center) is drawn over the sprite center — the wall is closer. So we see the enemy's left half and the wall covers the middle-right. Looking at the screenshot: there's a grey vertical block in the center covering the figure's right part. Yes! That's a wall column between player and enemy — occlusion working correctly. And the sprite's visible left part shows head+body. OK good.

So the main real fixes: weapon size/placement, texture noise, enemy start position slightly further.

Also "RESTART" button now top-right below enemy box — visible and not overlapping. Good.

Let me also double check the muzzle flash position: fy = wy + 52. With the new scale I'll compute muzzle at the barrel tip: tip at sprite y≈44/200 → wy + 44*wScale.

Let me redo weapon placement: scale 1.25 → wW=400, wH=250. wy = VH - 250*0.92 = 288-230 = 58. Then the gun occupies the lower 220px of a 288px screen — still big. Wolf-style weapons do occupy a large lower portion. But the gun's barrel tip at y=44*1.25=55 → screen y=113, which is near the vertical center. That's fine for a pistol held up.

Hmm, actually with the weapon art having lots of empty space at top (barrel at y 38-100 in a 200-tall canvas = middle), scaling the whole 320x200 canvas means the empty bottom gets cut off. Let me instead redesign the weapon sprite to be bottom-anchored and simpler: a pistol centered, barrel pointing up.

New weapon canvas 320x200:
- barrel: vertical rect x 150-170, y 40-120
- slide: x 138-182, y 90-140
- body/grip: x 140-180, y 140-200
- hands gripping: two rounded rects around grip.

And place: wScale 1.3, wy = VH - wH*1.0 (bottom aligned), so gun tip at 40*1.3 = 52 above bottom → screen y = 288-260+52 = 80. Fine.

Actually simpler: draw the weapon procedurally each frame instead of a sprite? Sprite is fine, just anchor to bottom.

Let me redraw the weapon sprite more like a classic Wolf pistol:

canvas 320x200:
- Hand (right) big: rounded rect x 120-210, y 130-200, skin.
- Grip: dark rect x 145-185, y 110-165.
- Slide: dark rect x 132-198, y 70-115, with lighter top edge.
- Barrel/front sight: x 152-178, y 55-75; sight nub x 160-170, y 45-55.
- Left hand fingers: rects over the grip.

Muzzle tip at y≈45.

Placement: wScale = 1.35; wW = 432, wH = 270; wy = VH - wH (bottom edge at VH) = 18. Then muzzle at screen y = 18 + 45*1.35 ≈ 79. OK.

Recoil: kick moves weapon down by recoil*26 — usually recoil moves up. Let's move it up: wy - kick... Actually a kick should move the gun up/back. Use `wy - kick` and slight scale. Fine.

Also add slight weapon sway with mouse? no.

Now the mossy texture speckles: reduce. Change crack to a smooth function and lower noise amplitude.

Let me rewrite the moss texture painter:
- base gray-brown stone
- large-scale moss patches via sin/cos smooth
- occasional dark crack lines along x for specific rows (fewer)

Let me just simplify: 
```
const n = (rng()-0.5)*14;
const mossField = Math.sin(x*0.13)*0.6 + Math.cos(y*0.17)*0.5 + Math.sin((x+y)*0.07)*0.7;
const moss = mossField > 0.75;
const crack = ((y*3 + Math.floor(Math.sin(x*0.2)*3)) % 37) === 0;
```
Good enough.

Also, ceiling looks very dark near the top — fine (dark ceiling).

Also add: pressing Space held down should auto-fire? Currently keydown repeats fire via fireCd — key repeat fires repeatedly since keydown repeats fire when held. Actually auto-repeat keydown events fire at OS repeat rate, so holding space fires at that rate, capped by fireCd. Better: track `keys['Space']` and call shoot() in update when held. Let me add that in update: `if (keys['Space']) shoot();` — shoot() respects fireCd. And keep keydown shoot for immediate response.

Now let me also verify enemy attack: at start, an enemy in LOS within 7 tiles will shoot immediately. Fine.

Let me apply edits.

Reload and check quickly, then finish.

Note: I added `if (keys['Space']) shoot();` before the `if (fireCd > 0) fireCd -= dt;`? Let me check order — I replaced "if (fireCd > 0) fireCd -= dt;" with both lines: fireCd decrement then shoot. Fine.

Reload browser and check.

Weapon now bottom-anchored but it's too large / hands dominate and the gun body appears as a big grey block in the middle of the screen (the sprite's slide+grip at scale 1.3 is huge and centered). The grey block at center covers the enemy. Problem: the weapon sprite canvas is 320x200 scaled 1.3 = 416x260, so nearly whole screen; the gun drawn at x 132-190 of 320 → centered but appears large.

Reduce wScale to ~0.85 and draw the gun bigger within the canvas? Simplest: shrink sprite scale so the gun reads as a hand weapon at bottom-center: wScale = 0.95 → 304x190 canvas, gun occupies x 132-214 → ~120px wide on a 512 screen. And hands at bottom. wy = VH - wH = 288-190=98. Muzzle at y=98+42*0.95≈138 — just below center. Good.

But the hands look like a giant beige slab. In the sprite, the hand polygon goes from y=122 to 200 and x 96-214 → at 0.95 scale it's ~112x78 px on screen — reasonable.

Also, the enemy is hidden behind the weapon. With a smaller weapon it'll be visible.

Also the enemy at (5.2,3.2) — I see a faint figure at center behind the weapon? There's a grey block at center = the weapon slide.

Let me set wScale = 0.95 and reload. Time is short — one edit + reload + verify movement/turn/shoot/restart via browser actions.

Also test collision and shoot: I'll use browser key presses.

But with wScale 0.95 and wy = VH - wH + bobY + kick, the weapon bottom is at VH, so the hands are cut at bottom edge — fine.

Also the weapon art's gun is drawn at x 132-214 in a 320 canvas → centered at 173 which is right of center (160). Slight offset, fine.

Reload and test keys.

Better. The gun reads as a dark pistol with hands at bottom. It's a bit translucent-looking (the shading gradient overlay makes it washed out) but acceptable.

I don't see the enemy clearly at start — the enemy at (5.2,3.2) may be behind the wall corner or just off. There's a figure? At center around x=590 there's a grey shape which is the gun. Hmm, the enemy should be visible at 24° right of center... The right side shows the mossy wall — enemy may be occluded by the wall to the right? From (1.5,1.5) to (5.2,3.2): passes cells... at x=3, y≈2.35 → cell (3,2) is wall (row2: 1,0,1,1,0,... index3 = 1). Yes! Occluded by the wall at (3,2). So the enemy is hidden. Requirement says "visible enemies" — they are visible in the maze generally (minimap shows them). Better to place a start-visible enemy so I can verify sprite rendering. Let me place the first enemy at (4.5, 1.5) again — straight down the corridor, no walls between (cells (2,1),(3,1),(4,1) are 0). Yes row1: 1,0,0,0,0,0,1 → x=2,3,4,5 are 0. So (4.5,1.5) is visible from start, 3 tiles ahead. Good for verification.

Then quickly verify movement (W), collision (turn left and walk into wall? or hold W to walk into enemy/wall), shoot (Space → muzzle flash + enemy hit), and Restart.

Time is short. Do: edit enemy spawn, reload, screenshot, then key presses for W/turn/Space, screenshots, then click Restart button and check health 100.

Let me batch: edit now.

Now I want to verify game logic headlessly too: I can run the game logic in node? Not easy since it's DOM-bound. Instead use the browser tool with key presses.

Plan of browser checks (fast):
1. reload + screenshot → enemy visible at start, health 100.
2. press key W (hold?) — browser `key` action presses a key. Then screenshot to see movement.
3. press Space → screenshot showing muzzle flash / hit marker.
4. click RESTART → screenshot: health 100, enemies 5.

Let's do reload + screenshot first.

Enemy guard visible at start (helmet, face, eyes, torso) — good. Now test movement/turning and shooting.

Press W a few times then screenshot to verify movement. Then Space for shooting feedback.

Note the browser key action sends a single keydown/keyup probably — movement with dt may be tiny. Let me press W multiple times, or use key action with text "w"? Let's just do a few presses.

Interesting — the key press apparently held for a while (time passed between frames?). Health dropped to 37 (enemies attacked, damage flash visible red). The player seems to have moved forward slightly (enemy closer, and its fire animation shown with orange eyes + firing arm). Enemy attack rule works and damage flash works.

But health dropped a lot quickly — 63 damage. That was over some seconds of real time (the tool frames show +0ms but real time passed). Multiple enemies attacking. Fine.

Now test shooting: press Space and capture screenshot. The browser key action screenshot might miss the flash (0.085s). Let's press space and immediately screenshot — the tool returns a screenshot after the action. Likely captures within the flash window if fast. Let's try.

Also I want to verify shooting kills an enemy (3 shots) and count decreases. I can press space 3 times with small delays... Each `key` call is a separate request; the delay between calls might be > fireCd (0.26s), so shots register.

Let me press space 3 times targeting the enemy straight ahead (player is facing it).

Oops, that was a filler. Let me actually press Space keys. Actually I should just do the browser key calls. Note that time passes between tool calls, so the player may die meanwhile (enemies attacking every 1.4s for 9 damage; with 1 enemy in range it'd take ~15s to die; but multiple could be in range). Let's act fast: press space 3x.

Actually the key action probably dispatches a keydown+keyup immediately, and `shoot()` is called on keydown. Good.

But careful: `update()` calls `shoot()` when keys['Space'] is true — since keyup fires immediately, no auto-fire. Fine.

Game Over triggered correctly at 0 health (player was killed by enemy fire while idle). The Game Over overlay works.

But this reveals a balance problem: standing still, the player dies in ~15 s from enemy fire — that's OK gameplay-wise (they must fight). But the initial enemy at 3 tiles attacking immediately makes the start harsh. Damage of 9 per 1.4s from potentially several enemies at once is quite punishing. Let me reduce: attack range 5 tiles, damage 7, and give the enemies a "first shot delay" and slightly longer cooldown (1.8s). Also add a spawn grace: enemies can't attack for the first 1.5 seconds.

Also update the controls text rule to match ("within 5 tiles ... every 1.8 s for 7 damage").

Also the player gets hit even behind walls? No — requires LOS.

Let me quickly make these balance edits, then verify Restart restores (click the Game Over RESTART button), and check shooting feedback via a fast sequence.

Edits:
1. In update: `if (sees && dist < 7 && e.attackCd <= 0)` → `dist < 5`, cooldown 1.8, damage 7.
2. Rules text update.
3. Add grace period: `gameTime` variable; enemies only attack if gameTime > 1.5. Simpler: initial attackCd values 1.5 + i*0.35 (already 0.6+i*0.25). Change to 1.4 + i*0.4.

Let me apply.

The spawnEnemies line: let me check exact text.

In spawnEnemies: `hitFlash: 0, attackCd: 0.6 + i * 0.25, fireAnim: 0, deadT: 0`. Let me read the file region.

The edit failed for edits[1] because of leading whitespace? Line 509 has 4 spaces indent: "    hitFlash: 0, attackCd: 0.6 + i * 0.25, fireAnim: 0, deadT: 0". I used exactly that... Hmm, maybe the issue is the whole call was rejected because of a conflict? Actually it said edits[1] not found — maybe my oldText had different spacing. Let me just do it with exact text from grep.

Also note: since the edit failed entirely (atomic?), edits[0] and [2] may not have been applied. Let me re-apply all three with correct text.