Wolfenstein raycaster · qwen3.8-27b

Let's build a single-file raycasting maze shooter. Plan:

- Grid map (e.g., 16x16), walls as 1.
- Raycaster using DDA, textured walls (procedural canvas textures), floor/ceiling shading.
- Sprites (enemies) drawn with depth-buffer occlusion, drawn as procedural sprites (drawn on offscreen canvas).
- Exit tile that lights up when all enemies are defeated; stepping on it wins.
- Enemies: simple AI — if in range and line-of-sight to player, chase/attack; attack rule: attack within distance, with cooldown, dealing damage.
- Shooting: spacebar fires, raycasts to nearest enemy with line-of-sight check, damages; muzzle flash; hit feedback.
- HUD: health, enemy count, control description.
- Game over/win screens, restart button.

Write the file, test in browser, check console, click restart, etc.

Let's write the code carefully.

Map: 16x16, 1=wall, 0=empty, 2=exit. Ensure reachability.

Textures: brick, stone, door/exit texture, generated on an offscreen canvas.

Sprite rendering: standard Wolf3D sprite projection with zBuffer per column.

Weapon: draw gun at bottom-center of screen (canvas drawing), recoil animation, muzzle flash.

Enemy AI: state machine — idle, chase (when line-of-sight + in range), attack with cooldown when within ~1.5 units. Damage ~10 per hit, with a short attack cooldown and maybe a flash on the player (red screen flash).

Collision: circle vs grid (check both axes).

Shoot: spacebar with cooldown; find enemy closest to player within FOV? Classic approach: cast a ray at center, check wall distance, find enemy whose projection is close to screen center and whose distance is less than wall distance. Compute each enemy's projected screen X position and check |sx - W/2| < enemyWidth/2, and depth < wall distance.

LOS check for enemy attack: use DDA line-of-sight function.

Let's write it.

Code structure:

- const MAP = [...strings]
- textW = 64; generate textures.
- game state object: player {x,y,dir}, health, enemies[], gameState 'playing'|'over'|'won', exitOpen.
- reset() to initialize.
- input: keydown/keyup set keys.
- loop: dt, update player (move with collision), update enemies, render.
- render: ceiling/floor fill, cast rays (W is maybe a low internal resolution like 320, scale via CSS to draw... better: internal canvas 480x300, scale via CSS). Actually for performance: internal resolution ~400x300, scale to full width.

Draw textured walls: for each screen column x, ray, DDA, side, texture sample column, draw with drawImage from texture canvas: ctx.drawImage(tex, texX, 0, 1, 64, x, drawStart, 1, lineH).

zBuffer[x] = perpDist.

Sprites: sort by distance, project relative to camera plane. Camera: dir vector, plane 0.66.

Enemy sprite: drawn on offscreen canvas (64x64): demon-like face. Two frames (idle/hit) or flash white on hit.

Update loop at fixed dt via rAF with dt clamp.

Enemy movement: simply — chase the player if LOS and distance < 8, move toward player with collision, speed 1.5. Otherwise wander. If distance < 1.6 and cooldown is 0, attack → player health -= 10, set attackTimer for flash, cooldown 1 sec. Also red flash on the screen.

Exit: tile 'E' — when the player's position is within 0.4 of the center of an exit tile and exitOpen → win.

HUD: top-left "HP: 100" as a bar, "Enemies: 3", plus control line at bottom or top-right. Overlay div for the message and restart button.

Gun: drawn procedurally on the main canvas: simple rectangle, moves with bob when walking.

Let's write it all.

Textures:
- Brick: rows of bricks with mortar lines, color variations.
- Stone: noisy gray.
- Exit: gold with symbol.
- Also an alternate red brick.

Wall map characters: '1' brick, '2' stone, '3' metal, 'E' exit (rendered as exit texture, passable — is the exit tile a floor tile with a glowing decal? More simply: the exit is a special textured wall, and when open the player touches an adjacent tile? That's awkward. Better: the exit is an open area marked with a floor marker. When open, draw a green decal on that tile's floor (skip per-pixel floor rendering for performance — just fill the floor; skip the decal). Or make the exit a wall texture that can be entered when open: when the player is adjacent to the open exit tile, check player distance < 1 → win. Actually the simplest and most reliable: exit tile E is passable; when the player steps onto an E tile and it's open, win. Render E as a low "gate" — just render as an empty tile and add a beacon? Keep it simple: when closed, render E as a special wall (barrier texture); when open, the same raycast treats E as passable, and stepping onto it wins. That's clean: in DDA and collision, if cell is 'E' and exitOpen → passable.

Collision function isSolid(x,y): cell != 0 and !(cell=='E' && exitOpen).

Enemy placement: pick empty cells with LOS not required.

Shoot hit effect: enemy flashes white (hitFlash timer), enemy hp 34 → dies in 3 shots, or hp 100 damage 35. Let's do enemy hp 50, damage 25 → 2 shots.

Sound: WebAudio beeps optional — add small beeps for shoot/hit (no external assets). Keep it simple, wrap in try/catch.

Alright, let's write index.html.

Next I'll test it in the browser. But before that, let me confirm reachability on the map in my head... no, actually let me verify it with a simple script: BFS from the starting point to all enemy positions and the exit.

Wait, the exit is at column 1, row 1 (character 'E' at index 1 of the second row). The starting point is (2,2). Let me check: MAPSTR row 1 = "1E00010000022201" — E is at x=1, y=1. Row 2 = "1E01010111020001" — E is at x=1, y=2. But BFS shows (1,2) as blocked. Let me verify: row 2, index 1 = 'E', passable. Hmm, but BFS started from [1,2]? I passed q=[[1,2]], which is [x,y] = x=1, y=2. MAP[2][1] = 'E'. OK, so start is fine.

Why is (0,1) blocked? (0,1) — MAP[1][0] = '1'. The exit's E is at (1,1) and (1,2), not at (0,1). My target label was wrong — the exit tile is at x=1, y=1. Let me re-check with the correct coordinate (1,1).

Enemy positions: e1 x=13.5 → floor 13, y=3.5 → floor 3. MAP[3][13] = row 3 "1001000100020031", index 13 = '3'? Let me count: index: 0:'1',1:'0',2:'0',3:'1',4:'0',5:'0',6:'0',7:'1',8:'0',9:'0',10:'0',11:'2',12:'0',13:'0',14:'3',15:'1'. So (13,3) is '0'. But the spawn is at (13.5, 3.5), which means the center of tile (13,3)? x=13.5 is tile 13, yes. But it's showing blocked. Hmm, wait, is e1 blocked? Let me redo it: maybe I messed up the index. Actually, let me just print out the reachable set and the map.

Issues:
- The E1 tile (13,3) is unreachable (it's in a sealed-off region).
- E3 (3,12) is unreachable: row 12 = "1111011101011101" — the region around (3,12) is blocked by walls.
- Also, there are unreachable regions at the bottom-left (0-2, 13-14) and the top-right.

Proposed fix: change the enemy spawns to reachable locations, and adjust a few walls to open up the pockets (nice-to-have). Pick enemy spawns from reachable tiles. Pick E2 (8,10), E4 (14,14), and add another reachable tile, e.g. (12,5)? Row 5 = "1000000000000031" — (12,5) is '0', and probably reachable. And (14,8)? Row 8 = "1010020111011111", index 14='1'. (6,7)? Row 7 "1000020000010001" index 6='0'. Reachable? Probably, via row 5. Let me fix the walls to open up the dead regions (improving the level), and pick spawn points:

Fixes to the map:
- Top-right pocket (12-14, 1-3): open a passage. Row 2 index 12: "1E01010111020001" → change to 0? Row 2: idx 11='2', 12='0', 13='0', 14='0'. Hmm, row 2 already has 12, 13, 14 as 0? Wait, the unreachable ones are 12, 2 / 13, 2 / 14, 2. Row 2 = "1E01010111020001": idx: 0:'1', 1:'E', 2:'0', 3:'1', 4:'0', 5:'1', 6:'0', 7:'1', 8:'1', 9:'1', 10:'0', 11:'2', 12:'0', 13:'0', 14:'0', 15:'1'. So (12,2) is open but unreachable, because row 1 idx 12-14 = "222"? Row 1 = "1E00010000022201": idx 11='2', 12='2', 13='2', 14='0'. And the right side is the wall at column 15. How do you enter the (12,2) region from below? Row 3 idx 12, 13, 14 = '0','0','3'. Row 4 = "1011110101111131": idx 14='3'. Hmm, row 5 idx 14='3'. The wall of the '3' column is… actually, the pocket is surrounded: rows 1-2 columns 11-14, the right column 15, below it rows 3-4 with '3' at column 14? Row 3 idx 13='0', 14='3'. Row 4 idx 14='3', 13='1'. So open up (13,3)? That's '0'. Is (13,3) adjacent to (13,2)? Yes, and (13,3) is listed as unreachable. What's blocking it? The region above (12-14, 2) connects to (13,3) at (13,2)-(13,3). And (14,3) '0'… row 3 idx 13='0'? Recounting row 3 "1001000100020031": idx 0:'1', 1:'0', 2:'0', 3:'1', 4:'0', 5:'0', 6:'0', 7:'1', 8:'0', 9:'0', 10:'0', 11:'2', 12:'0', 13:'0', 14:'3', 15:'1'. So (12,3), (13,3) are open. Their neighbors: (12,4)? Row 4 idx 12='1', 13='1', 14='3', 15='1'. (11,3)='2'. So the region {12,13,14 × 1,2,3} is sealed in by '2'/'3' at column 11 and by '1'/'3' on the row 4 side. To open it: change row 3 idx 11 from '2' to '0'? (11,3) connects to (11,2)? Row 2 idx 11='2'. Hmm. Simplest way: open (11,4)? Row 4 "1011110101111131" idx 11='1'→'0', and open (11,3)? Actually (11,3) is '2'. Let me just change two cells: row 3 idx 12 from '0' to… no, that's already open. Change row 4 idx 12 '1' → '0': then (12,3) connects to (12,4), and the pocket opens.

But do we need this pocket for enemies? We could just move the enemy to a reachable tile. But open dead regions are fine (a Wolfenstein-like dead-end). However, if there are unreachable floor tiles, the player can't reach the win… no, the win only requires the exit. No problem, but better to open the dead regions so the player doesn't find unreachable floors. Dead-end rooms are fine as long as you can walk in. Let's open them:

- Top-right pocket: change row 4 idx 12 '1'→'0' ("1011110101111131" → idx 12: let me count row 4: 0:'1', 1:'0', 2:'1', 3:'1', 4:'1', 5:'1', 6:'0', 7:'1', 8:'0', 9:'1', 10:'1', 11:'1', 12:'1', 13:'1', 14:'3', 15:'1'. Change idx 12→'0').

- Bottom-left pocket {(0-2,13),(0-2,14)? and (1,13)}: row 13 = "0011000100000101": idx 0:'0', 1:'0', 2:'1', 3:'1', 4:'0', 5:'0', 6:'0', 7:'1', 8:'0', 9:'0', 10:'0', 11:'0', 12:'0', 13:'1', 14:'0', 15:'1'. Row 14 = "0001111111101101": idx 0:'0', 1:'0', 2:'0', 3:'1'… so the pocket {(0,13), (1,13), (0,14), (1,14), (2,14)}: (2,14) is adjacent to (3,14)='1', (2,13)='1'. Open (3,14) '1'→'0'? Then (2,14)-(3,14) connects to row 14, which is open further right at idx 4? Row 14 idx 4='1'… wait "0001111111101101": idx 4-10 are '1'. Hmm, row 14 idx 11='0', 12='1', 13='1', 14='0'. So if we open (3,14), the pocket connects to the row 13 path at (4,13). Good: row 14 idx 3 '1'→'0'.

- Bottom-left corner row 14 idx 0-2 is the same pocket, opened via (2,14).

- Top-right of rows 1-3 column 14, also (14,1) '0': part of the same pocket, solved by opening (12,4).

- (14,6), (12,7), (13,7), (14,7): row 6 = "1022220111011101": idx 14='0'. Row 7 = "1000020000010001": idx 12='0', 13='0', 14='0'. Row 8 = "1010020111011111": idx 12='1', 13='1', 14='1'. Row 5 = "1000000000000031": idx 13='3', 14='3'. So pocket {(14,6), (12,7), (13,7), (14,7)} is sealed by the '1's in row 8. Open row 8 idx 13 '1'→'0'.

Then enemy spawns: E1 (13.5, 3.5) becomes reachable after the fix. E3 (3.5, 12.5) tile (3,12): row 12 = "1111011101011101": idx 3='1'? 0:'1', 1:'1', 1… let me recount: "1111011101011101" → idx 0:'1', 1:'1', 2:'1', 3:'1', 4:'0', 5:'1', 6:'1', 7:'1', 8:'0', 9:'1', 10:'0', 11:'1', 12:'1', 13:'0', 14:'1', 15:'1'. So (3,12) is a wall! Bad spawn — the enemy would end up stuck inside a wall. Move E3 to (4.5, 12.5) tile (4,12) '0'. Reachable? After fixing the bottom-left… (4,12): row 12 idx 4='0'; neighbor (4,13) row 13 idx 4='0', open. Probably reachable via the main area. Good.

Also, the start (2,2) is near the exit at (1,1) — the exit is right next to the start, which is fine (locked until all enemies are dead).

Wait, the player start is x=2.5, y=2.5 (START.x+0.5 = 2.5). Tile (2,2) '0'. Good.

Also confirming: enemy e1 (13.5, 3.5) — after opening (12,4), (13,3) is reachable: path via (12,3)→(12,4)→… yes.

Also confirming enemies aren't spawning on top of the player. No problem.

New MAPSTR:
Row 3: "1001000100020031" — keep as is? idx 11='2'. OK, keep it.
Row 4: "1011110101111131" → idx 12 '1'→'0': "1011110101101131"? Careful: the original string: indices 0-15: 1 0 1 1 1 1 0 1 0 1 1 1 1 1 3 1. New idx 12 = '0': 1 0 1 1 1 1 0 1 0 1 1 1 0 1 3 1 → "1011110101110131".
Row 8: 1 0 1 0 0 2 0 1 1 1 0 1 1 1 1 1 → idx 13→'0': 1 0 1 0 0 2 0 1 1 1 0 1 1 0 1 1 → "1010020111011011".
Row 14: 0 0 0 1 1 1 1 1 1 1 1 0 1 1 0 1 → idx 3→'0': "0000111111101101".

Let me run BFS again.

Wait a sec, it's showing 5 unreachable ones, yet it's also showing "passable 117 reachable 117"? It's a bug in my counting: `ok++` is always being executed (because it's outside the if). Whatever — 5 unreachable tiles remain: the pocket at the bottom-left corner {(0,13),(1,13),(0,14),(1,14),(2,14),(3,14)}. I opened up (3,14), but its neighbor: (3,14) is adjacent to (4,14)? Row 14 idx 4='1'. And above (3,13) is '1'. So it's still sealed off. I'll open (4,14): row 14 idx 4 '1'→'0': "0000011111101101". That way (3,14)-(4,14) will connect to (4,13).

All reachable. Next, I'll update index.html with the corrected map and the third enemy spawn point (4.5, 12.5).

Wait, the original spawn was 4 entries (3+... the requirement is "at least 3 enemies" — 4 is fine). But wait, does the enemy at (13.5, 3.5) have direct line-of-sight (LOS) to the player at the start point? Player (2.5, 2.5), far away. No problem.

Next, test in the browser.

The player is staring at a brick wall — since they're facing direction 0 (+x), they're facing the wall at (3,2)? Wait, row 2 of the player at (2.5,2.5) = "1E01010111020001": idx2='0', idx3='1'. Yes, there's a wall at x=3. That's fine, but it'd be better if the starting direction faced an open area. The opening in row 2: (2,2) is '0', and it connects to (2,1) '0' and (2,3) '0'. Row 1 = "1E00010000022201": (2,1) is '0'. So the starting direction should be -y (i.e., facing upward = -y direction, dir = -PI/2). Let's set START's dir to -Math.PI/2 so the player faces the corridor.

Actually, let me test turning: pressing ArrowRight increases the direction... the starting direction 0 is facing the wall — the test asks to "test movement and turning near the start area" — it's playable, but it's better to start facing an open corridor. Set dir = -Math.PI/2 (facing -y, the corridor to (2,1)). Confirming: dir=-π/2 → dirX=cos(-π/2)=0, dirY=-1. Good.

Change START's dir.

Wait a sec — the spawn enemy at (13.5, 3.5)... it's far from the player. Okay. Reload and test: move with W, collision detection, turn, shoot.

The EXIT gate is visible on the left side (pulsing gold), with a brick wall in front. The ceiling is dark. It looks good.

Next, I'll test movement: press W to move forward (up the corridor). Use the keyboard. The browser tool has a "key" action. Let me try inputting "w"... probably it sends a keydown event once. Movement is key state-based, so it'll only move for one frame's worth. Hmm. It's better to test by dispatching a keydown, waiting, then keyup via evaluate—but the browser tool doesn't have evaluate. What's available: reload, inspect, screenshot, motion, click, drag, key, type, scroll.

I can test movement by pressing "w"—it becomes one keydown event, and the key remains pressed in the `keys` map until keyup... Actually, a single "key" press probably fires keydown+keyup, so the player moves a tiny bit (one frame). That's a weak test.

Alternative: dispatch a keydown without keyup via keyboard event dispatch... can't be done without evaluate.

Better approach: test the game logic by temporarily calling functions in a browser console? No evaluate action available. But I can use "key" multiple times. Each press moves about 1 frame (16ms → 0.05*3.4 ≈ 0.17 units... actually dt per frame is about 0.016, so 3.4*0.016 = 0.054 units per press). Pressing W 30 times moves about 1.6 units. That's slow.

Hmm, or the motion action (animation frames) might be useful for seeing a gun bob or a pulsing exit. Let me try pressing W several times and taking a screenshot to confirm position changes. Also press arrow keys to turn, and shoot with space.

Actually, I can dispatch a keydown without keyup using keyboard event dispatch... can't be done without evaluate.

Alternative: simulate with repeated "key" calls. Let me press "w" 10 times, take a screenshot, then press "d" a few times, take a screenshot, and press space to shoot and confirm muzzle flash.

Note: does the "key" action send text or keys? The signature has a "text" parameter. Let me try action "key", text "w".

The view appears to be the same — a single keypress might not have moved the player (the keydown+keyup happened between frames). To check whether the movement code works, I need a stronger test. Options: repeatedly press w, e.g., 30 times. Let me batch several key calls. However, tool calls within the same block execute in parallel — that's fine for keypresses (they're independent).

No wait: maybe the "key" action is holding down the key? The screenshot looks exactly the same. Let me try pressing "w" about 20 times in parallel, then take a screenshot.

The player moved up the corridor (the exit gate on the left gradually receded behind), and hit a brick wall at (2,1)? The corridor: from (2,2) going up to (2,1), then the wall above at row 1? Row 1 idx2='0', row 0 idx2='1'. The player advanced about 1 unit and stopped at the wall in row 0. Good: collision is working (the view stopped at the wall).

Next, test turning and enemy visibility. Turn right (ArrowRight) to face +x? Current orientation is -π/2. Turn to look around. Let's press ArrowRight multiple times (each press is one keydown; since it's state-based rotation, each press rotates slightly — each rotation is 2.6*dt for one frame ≈ 0.045 rad ≈ 2.6°). 10 presses ≈ 26°. Hmm, a bit slow. Let's try 20 presses to turn roughly 52°.

Actually, let's turn right 30 times to face east (from -90° to 0°, a 90° turn requires 34.6 presses). Too many. Alternative: test rotation with 10 presses and confirm the view changes; that's enough to verify rotation works (it actually is working — W's movement already changed the view... no, that was movement).

Let's try 12 ArrowRight presses.

Rotation is working — 12 presses turned about 30° to the right, and the view panned along the brick wall toward the corner (the ceiling became visible in the last frame). The player is facing the wall at (3,2)? The player moved to (2.5, ~1.0). The wall to the right is at x=3.

Next, test shooting: press space to see if the muzzle flash appears. After that, test restart.

Also, I want to verify that the enemy sprites and the game flow (killing enemies, opening the exit, win, game over) work. Since there's no JS evaluation tool, can I write a small headless test harness in Node that simulates the game logic? The logic is embedded in the HTML. Alternative: duplicate the combat code in Node and unit-test the core functions (wallDist, hasLOS, shoot targeting)? That's a duplication, not a test.

Better approach: test in the browser. The "type" action might hold down the key for a while. Let me try shooting and then taking a screenshot immediately afterward — the muzzle flash lasts 0.12 seconds, and with the tool's round-trip, catching it is unlikely. The message "HIT!" lasts 2.5 seconds, but shooting a distant wall won't hit anything.

Can I place an enemy near the player to see a sprite and try shooting? I can't run JS.

Alternative verification: use a temporary debug hook? I could add an auto-test that runs when a URL hash is present (e.g., #autotest): simulate shooting and report via console.log. This way, without modifying the game, I can run logic checks in the browser. Actually, it's fine to leave a small debug hook in the artifact. Let me add a lightweight test mode: if location.hash === "#autotest", after initialization, run scripted checks and log the results to the console. Then inspect the console.

Check items:
1. Shoot an enemy with LOS in front → hp decreases, enemy flash.
2. Shooting with a wall between → enemy takes no damage.
3. Kill all enemies → exitOpen becomes true; move player to the exit tile → win (gameState "won").
4. Damage to player: place enemy next to player → after update tick, hp < 100; hp 0 → game over.
5. Reset: restore hp 100, 4 enemies.

Implement in the page: call reset(), teleport the player and enemies, call update(0.016) a few times, or call shoot() directly. Log the results.

Let me add the code. Insert it before the final requestAnimationFrame.

const hash = location.hash;
if (hash === "#autotest") {
  // Test 1: shooting through a wall does no damage
  ...
}

Note: shoot() uses player and enemies, so no problem.

Test plan in autotest:
- reset()
- t1: place enemy at (3.5,2.5)? Wall is (3,2). Place at (4.5,2.5)? Row 2: idx4='0', yes, and wall (3,2) between player (2.5,2.5) and enemy (4.5,2.5). Wait, wall row 2 idx3='1' yes. hasLOS is false; wallDist ~1.0 < d. Shoot → enemy hp stays at 50. Log.
- t2: move enemy to (2.5,3.5)? Row 3 idx2='0'. Directly below player, LOS clear. Shoot twice (set shootCd=0) → hp 0, alive false. Log.
- t3: kill all: set each enemy.alive=false, except... actually, set hp of remaining 3 enemies to 0 and check exitOpen via the shoot path? Simpler: kill enemies one by one with shoot? They're far away. Easier: set exitOpen directly? No — I want to verify the unlock logic: set all enemies' hp=1, then shoot each? Need LOS/aim. Easier: call the logic: for each enemy: e.hp=0; e.alive=false — but the unlock check happens inside shoot() only when best dies. To test, manually set hp=1, and... the unlock is checked in shoot() when the target dies. I could simulate: place one enemy in front of the player (same as t2), set the other 3 to alive=false, and kill the one in front with shoot → expect exitOpen to be true and enemycount to be 0.
- t4: victory: set player to (1.5,1.5) on the exit tile, call update(0.016) → gameState 'won'. Log.
- t5: game over: reset(); player.hp=5; place enemy at (3.0,2.5)? That's a wall. Place enemy adjacent to player: (2.5,3.0), with LOS; enemy attack range is 1.5 — distance 0.5 <1.5, LOS true → update(0.016) → player hp 5-10 → -5 → 0 → game over. Log.
- t6: restart: reset() → hp 100, 4 alive, exitOpen false, gameState playing. Log.
- t7: collision: set player to (2.5,2.5) and tryMove to the wall: simulate moving +x into (3,2): tryMove(player, 3.4, 2.5, 0.25) → x should not cross 2.75. Check player.x <= 2.75. Log.

Then screenshot after autotest (ends with a reset → the initial viewpoint is restored).

Add the code, reload with #autotest, and check the console.

I'll run the autotest one time in the browser, check the console, and then exit. I'll reload it with the hash #autotest appended.

Autotest didn't run (no AUTOTEST in the console) — because the hash #autotest isn't attached. The reload probably reset the URL to the base one. Since the browser tool doesn't let me specify a URL with a hash, I can't set the hash. Options: run autotest only when the hash is present, or as a fallback... the simplest is: run it when the hash is present, or expose it as a global and trigger it with a key combination? The easiest is: run autotest only when the hash is present, and for verification, run the game logic headlessly in Node — extract the script and stub out the DOM. A bit of work, but it'll finish quickly: the script uses document/canvas a lot. Alternative: change the condition to `location.hash === "#autotest" || window.__autotest`, then dispatch the key... but I still can't set window variables.

Fastest and most robust check: run it in Node using minimal DOM stubs. What the script uses: document.getElementById (for hpfill/hptext/enemycount/overlay/msg/restartBtn), canvas with getContext and many 2D calls, createElement('canvas'), window.addEventListener, requestAnimationFrame, performance.now, location.hash, AudioContext. A stub via a Proxy that returns no-ops should work.

Let me extract the contents of <script> from index.html, wrap it with stubs, and run it in Node. Set location.hash = "#autotest". Capture the console.log output.

Time budget is 5 minutes — feasible in one shot. Let me write a Node test script.

Thinking: T2 failed: enemy is at (2.5,3.5), player at (2.5,2.5). Shoot: rdx=cos(-π/2)=0, rdy=sin(-π/2)=-1. Enemy is at dy=+1 (opposite direction!). Player is facing up (-y); enemy is below (at +y). Angle diff = π — outside the aim cone. Bug in my test: enemy is in the opposite direction. Place enemy in front of player: (2.5,1.5)? Row 1 idx2='0', yes, that's the corridor the player is facing. Also T1: enemy at (4.5,2.5), facing -y, horizontal distance 2, angle π/2 — this too is outside the cone → "blocked" would trivially pass. Fix the test: T1's enemy at (2.5, 1.5) is in front but... no wall in between. T1 needs a wall in between: the wall in front is (2,1)? No — (2,1) is open, (2,0) is a wall. Place enemy at (2.5, 0.5)?? That's inside the wall in row 0 (not possible).

Better approach: rotate player to face +x: player.dir=0. Then the wall is (3,2) directly in front, enemy at (4.5,2.5) is behind the wall. T1 is valid. T2: move enemy to (2.5,3.5)? Facing +x, the enemy below is outside the cone. Move enemy to (4.5? no there's a wall there)... facing +x from (2.5,2.5), the wall (3,2) blocks everything in the +x direction. Rotate to -y: enemy at (2.5,1.5): in front, no wall in between (row 1 is open). Good.

Update the autotest: before T1, player.dir=0; before T2, player.dir=-Math.PI/2, enemy at (2.5,1.5). T3: enemy is at (2.5,1.5) with LOS, alive, hp 1.

Also check the aim cone formula: da > 0.22 + 0.9*0.5/max(d,0.5). At d=1: 0.22+0.45=0.67 rad — cone is fairly wide, no problem.

hasLOS(2.5,2.5 → 2.5,1.5): tiles (2,2),(2,1) are open. Good.

Fix the test, and additionally verify that the shot reaches the exit tile? E.g., T1's enemy behind the gate: place enemy at (1.5,1.5)? That's the exit tile (1,1), and when the gate is locked it's impassable → wallDist counts it. But is the enemy on the exit tile inside the "wall"? The enemy is behind the E gate at (1,1). Player is at (2.5,2.5) facing -y: the ray goes along x=2.5 passing through (2,1), then (2,0) is a wall... it doesn't pass through (1,1). Never mind, T1's wall test is sufficient, plus the LOS check is already covered.

Fix and rerun.

Also, in T2, shoot() is called immediately twice — shootCd gets set to 0.35 on the first shot, and the second shoot() gets blocked by shootCd>0! shoot() checks `if (shootCd > 0) return;`. Need to reset shootCd=0 between shots. Fix: shoot(); shootCd=0; shoot(); same for T1, no problem there.

Also T3: shoot() — the previous shootCd is already reset (after T2's 2nd shot it becomes 0.35; shoot() sets shootCd=0.35, and on return it stays at 0.35). In T3, shoot() will end up returning immediately. Add shootCd=0 before that. Also T5: reset() resets it, so no problem. Fix T3.

But wait — T3: after T2, the enemy is at (2.5,1.5), dead. In T3, the other enemies are forcibly killed, then e=enemies[1] is revived at (2.5,1.5). shootCd is 0.35 from the previous shoot, but it's already reset. OK. Run it again.

Still failing. Enemy (2.5,1.5), player (2.5,2.5), direction -π/2 (facing -y). Aim cone: ang = atan2(dy,dx) - dir; dy = -1, dx = 0 → atan2(-1,0) = -π/2. da = 0. No problem there.

wallDist in the (0,-1) direction: from (2.5,2.5), mapX=2, mapY=2. rdx=0 → dDX=1e9. rdy<0 → stepY=-1, sY=(2.5-2)*1=0.5? dDY=1/1=1. Loop: sX (1e9) vs sY (0.5): advance y. mapY=1, side=1, cell (2,1)='0'. sY=1.5, advance y: mapY=0, cell (2,0)='1' → hit. Returns sY - dDY = 0.5. Wait — wall distance 0.5?? That means tile (2,0) is 0.5 away? The player is at y=2.5, and the wall in row 0 is at y=1... no wait, mapY=1 is the tile at y∈[1,2), distance from y=2.5 is 0.5? No! From y=2.5 to the boundary at y=2 is 0.5, and then tile (2,1) spans [1,2). Then mapY=0 tile spans [0,1). The ray reaches y=1 at distance 1.5. DDA: initial sY = (mapY+1 - py)... rdy<0: sY = (py - mapY)*dDY = (2.5-2)*1 = 0.5 → reaches y=2.0 at t=0.5 (tile boundary, correct). Then sY=1.5 → y=1.0, mapY=0 → wall, distance = sY - dDY = 0.5?? Bug: when a side advances and hits, the distance to the hit wall is the *next* step's distance minus the step? No wait: sX after adding dDX = distance to the *next* cell boundary in that axis. When we advance into the hit cell, the ray entered that cell at distance (sX - dDX)? Hmm.

Standard DDA: after stepX/side update, the perpendicular distance to the hit face is (if side==0) (sX - dDX), where sX is the value after adding dDX. I return `side===0 ? sX-dDX : sY-dDY`, and that is s after adding — no wait, in the code: `if (sX < sY){ sX+=dDX; mapX+=stepX; side=0; }` then check cell; if hit, return `side===0 ? sX-dDX : sY-dDY`. sX-dDX = s before addition = correct distance to the face where the hit cell was entered. In this trace: when hitting (2,0), the sequence is: iteration 1: sX=1e9 vs sY=0.5 → sY=1.5, mapY=1, cell '0'. Iteration 2: sY=1.5 < 1e9 → sY=2.5, mapY=0, cell '1' → returns sY-dDY = 1.5. Correct!

So the wall distance is 1.5, the enemy at distance 1.0 is within range. Next, hasLOS is OK. Next, the angle: no problem. So why no damage? Hmm... maybe the enemy was found but hp: 50-25=25, then another shot → 0 → death. Should work. Let me debug: maybe `shootCd` is >0 from the immediately preceding T1 shoot? T1: shoot() sets shootCd=0.35. Then T2: shoot() → return (cooldown!). shootCd=0; shoot() → only 1 hit → hp 25, not dead. That's the bug in my test. The first `shoot(); shootCd = 0; shoot();` — the first shoot got eaten by the cooldown from T1's shot. So the enemy took 25, 25... wait, after the first shoot() is eaten (no shot), set cd=0, second shoot does 25 damage → hp 25, still alive. Fails.

Fix: set shootCd=0 before each shoot in T2/T3.

T4 also failed because T2/T3 failed (the enemy was still alive → exitOpen was false → update() didn't win). T4 was checking gameState === 'won'. After fixing T2/T3 it should pass. Also T4 sets the player's position to (1.5,1.5) and calls update — but is the exit tile (1,1)? MAP[1][1]='E', yes, floor(1.5)=1. Good.

Re-run.