Wolfenstein raycaster · claude-haiku-5.5

I'm planning to work efficiently within a 15-minute budget, building a single HTML file with a raycaster, maze, and enemies. I'm designing a hand-crafted 15x15 grid map, making sure the exit is reachable from the start.

Still designing the maze layout...

I'll verify reachability with a quick node script instead of manual tracing, then move to enemy logic: four enemies placed in open cells with simple AI that chases the player when visible within range and attacks at close distance with a cooldown. Shooting will use a hitscan check along the player's facing ray, comparing enemy distance to wall distance and checking angular alignment to determine hits.

For sprite occlusion I'll use a per-column zbuffer so enemies only render where they're closer than the wall, with a separate line-of-sight sampling check for AI awareness. Rendering uses a fixed internal canvas resolution with DDA raycasting, procedurally generated wall textures, flat shaded floor/ceiling, side-darkening for walls, and simple procedural enemy sprites scaled by distance. Player movement handles forward/strafe with axis-separated collision against walls, plus arrow-key rotation, and now I'm setting up the shooting mechanic.

Shooting uses spacebar with a cooldown, muzzle flash, and hit feedback, with unlimited ammo and a red screen flash when the player takes damage. I'm figuring out enemy health (two hits to kill) and designing the exit: I want it locked until all enemies are dead, rendered distinctly as a wall-like tile, and win-triggered by proximity when the player gets close enough while unlocked.

I'm settling on treating the exit as a solid "door" wall type that shows red when locked and opens visually once all enemies are dead, with the HUD displaying "Exit locked" status. For enemies, I'm defining AI that idles until it spots the player within range and line of sight, then chases and attacks with a cooldown and damage value, only landing hits when it has clear LOS. I'm also laying out game states for playing, winning, and dying, each triggering an overlay with a message and restart option.

Now I'm working through the raycasting math—camera plane vectors, DDA stepping, texture coordinate mapping—and planning to procedurally generate wall textures (brick, stone, door variants) into a pixel buffer that gets scaled up to the canvas, while skipping a minimap to save time and adding a debug hook for testing reachability.

I'm figuring out how to render floors and ceilings via per-row distance casting with checkerboard stone textures, apply distance-based fog shading, and draw sprites directly into the same pixel buffer so they composite correctly with the z-buffer.

Writing wall height calculations...

I'm planning procedural textures for bricks, stone, doors, floor and ceiling tiles using noise-based color variation, plus a simple humanoid enemy sprite drawn with alpha transparency outside its silhouette, and setting up the inverse-camera-matrix math to project sprites into screen space based on their position relative to the player.

For gameplay logic, I'm sketching collision detection using a small radius check against map tiles, enemy movement that homes toward the player with basic collision fallback, hit-flash tinting for damaged enemies, and a shot-detection system using forward/lateral vector projection to determine if a ray hits an enemy within a radius threshold.

I'm also designing LOS checks for enemy AI by sampling points between entities for walls, confirming zbuffer handles sprite occlusion, and planning a DOM-based HUD overlay for health, kill count, and muzzle flash effects alongside the pixel canvas rendering.

I'm setting up input handling with keydown/keyup state tracking, preventing default on movement keys, and adding restart logic. Now I'm drafting the 16x16 level grid, making sure to validate reachability and placing the exit marker, though I need to double check that the exit's position works properly within the border walls.

Still mapping out grid rows...

Still verifying each row's bit count...

This is getting messy — I keep second-guessing the exit placement since borders can't have openings. I'll just lay out the grid as planned and run through it manually afterward to verify connectivity and fix any issues.

Confirming r13 lines up with X's north neighbor as open, then moving on to placing enemies in valid open cells, checking row 3 and row 8 coordinates against the grid to find safe spots.

Settling on four enemy positions after verifying each against the maze rows, then setting the player's start at (1,1) facing east into an open corridor.

Now I'm writing the HTML structure and CSS for the maze shooter page, setting up the canvas, overlay, and flash elements with a dark pixelated styling theme.

Writing procedural texture generators...

Still defining textures...

For sprites I'll make a generic texture function returning RGBA with alpha for transparency. The enemy guard sprite needs a skin-toned head and brown uniform body shape drawn with simple geometric regions.

Now I'm setting up the game state object and figuring out the internal canvas resolution dimensions.

Writing raycasting logic...

For shooting I'm fine using Euclidean sideDist with unit-length ray directions, but for rendering I need to stick to the standard DDA perpendicular wall distance using the non-unit rayDir, since that's what cancels out the fisheye distortion correctly.

Writing the raycasting render loop...

I'm shading floor and ceiling based on distance for fog, then moving to sprites: transforming each enemy's position into camera space, projecting it to screen coordinates, and computing its scaled width and height based on depth for billboard rendering.

For drawing, I'm clamping the sprite's screen bounds and texturing it column by column, checking the z-buffer so sprites are occluded by walls, and sampling the 32x32 texture per pixel with alpha blending for shading. I'm also planning a hit-flash effect, swapping to a whitened texture variant briefly when an enemy takes damage.

Now I'm working out the sign convention for the camera plane vector relative to the direction vector, making sure strafing direction and the perpendicular plane stay consistent so the rendered view isn't mirrored incorrectly.

I'll define right as (-dirY, dirX) so strafing D moves along that vector, keeping things consistent with my earlier convention. For rotation, since y is down-oriented, increasing angle turns clockwise on screen, so the right arrow key should increase the angle. I also need the inverse determinant formula for sprite transforms, using planeX*dirY - dirX*planeY.

Working through the sprite projection math confirms the matrix inverse convention matches my ray setup, so screen x scales correctly with the camera plane direction. Now I'm writing the enemy AI update function, starting with health/cooldown checks and distance-to-player calculations to determine line of sight.

Still writing enemy AI logic...

For damage I'm applying player health loss with a red flash overlay, triggering death state when health hits zero. For shooting I'm computing a hitscan ray against the nearest wall distance, then checking each alive enemy's forward and lateral offset relative to the player's view direction to find the closest one within a narrow cone, applying damage to whichever enemy is hit first.

Enemies have 2 hp and get removed on death, decrementing the remaining count; I'm distinguishing feedback messages for hit, kill, miss, and shots blocked by a wall between the player and target. The exit unlocks once all enemies are dead, and I'm figuring out the win condition by checking the player's distance to the exit tile's center or bounding box.

Collision detection checks all four corners of the player's hitbox against solid tiles, treating the exit as solid until reached. I'm planning the HUD elements—health bar, enemy counter, message log, overlays for game over and victory—plus a restart function that resets enemies from their spawn list, and exposing a debug object on the window for testing.

For the gun and muzzle flash, I'll draw simple shapes directly on the canvas rather than using separate DOM elements, with a brief yellow flash circle when firing. Now I'm setting up the canvas and 2D rendering context...

Writing texture generation code...

Still writing texture functions...

Still defining sprite geometry...

Now I'm setting up the map grid, dimensions, and enemy spawn points for the game code.

Still writing map rows...

Setting up the player's starting position facing east, then writing a newGame function that initializes player stats, enemy spawns with health and alert states, and resets the HUD.

I'm handling movement in the update loop—calculating direction from the angle, applying turn rate for arrow keys, and computing forward/strafe velocity from WASD input that gets normalized before passing to a collision-aware moveBox function shared by player and enemies.

I unify player state onto S with x, y, and ang fields, and canStand checks all four corners of the bounding box against floor tile data to prevent clipping through walls. The rest of update handles cooldown timers, enemy logic, win/death conditions, shooting input on spacebar, restart keys, and finally rendering with a gun overlay, crosshair, red damage tint, and HUD elements for health, enemy count, and status messages.

Now I'm setting up the raycasting render loop, computing direction and camera plane vectors for a 66-degree field of view, then looping through screen rows to project floor and ceiling distances using the standard perspective formula based on height above the horizon, applying fog shading as distance increases, and stepping through world coordinates per pixel to sample the floor texture.

I'm writing a color shading helper that unpacks the packed RGB values from a pixel and scales them by a lighting factor before repacking into a uint32 color, then applying it per-pixel for walls and floors with a side-wall darkening factor. After the pixel buffer is filled I handle sprite depth sorting for enemies, then draw the 2D overlay layer on top including the gun sprite, muzzle flash circle, crosshair lines, and flash effects for hits and damage taken.

Now I'm writing the sprite rendering loop, projecting each enemy's position into screen space, computing its screen size and bounds based on distance, then looping over its pixel columns and rows to sample the sprite texture and blend it into the frame buffer while respecting the depth buffer and alpha transparency.

I'm handling flash effects for hit enemies, verifying the texture coordinate math stays within bounds, and confirming the perpendicular distance calculation matches the depth buffer so sprites occlude correctly behind walls. Now I'm wiring up the HUD update function and exit door texture logic based on lock state.

For wall rendering, I'll keep things simple by using brick texture for all wall tiles rather than mixing in stone, since the map only uses tile 1 for walls. I'm also generalizing the texture-making helper to support different sizes for sprites versus walls, then plan to write the file and verify pathfinding and rendering stability with a quick test before checking it in the browser with screenshots.

I'm starting with an empty directory, so I'll build an index.html file for a maze-style game using a grid-based map with walls, a start position, and an exit cell, rendered on a canvas sized to fit the viewport.

For the maze layout, I'm hand-designing a 15x15 grid with walls and open paths, planning to verify reachability from start to exit with a BFS check. I'm also sketching out enemy behavior: tracking position, health, and attack cooldowns, having them chase the player when there's line of sight within range, and dealing melee damage when close enough, while figuring out hitscan shooting logic based on ray distance and the enemy's offset from the player's view direction.

Now I'm planning the rendering pipeline using DDA raycasting per column, with procedurally generated wall textures sampled per column, solid-color floor and ceiling, and billboard enemy sprites depth-tested against a wall zBuffer for proper occlusion. I'm also adding a weapon sprite with recoil and muzzle flash animations, a cooldown timer, and visual hit feedback like flashing enemies white when struck.

I'm designing a locked exit tile that renders red and blocks movement until all enemies are dead, then turns green and walkable, which gives meaning to pathfinding checks between start and exit. For movement I'm setting player speed and turn rate with circle-based collision sampled on x and y axes separately, and giving enemies similar wall collision plus a simple state machine: idle until the player enters line-of-sight within range, then chase, with HP and damage values tuned so two shots kill an enemy.

I'm defining enemy attack behavior as ranged with a line-of-sight check, firing cooldown, and damage per hit, plus win/lose/dead game states with a restart overlay and HUD controls. I'm also exposing a read-only game state object on the window for testing, and now I'm working out the raycasting renderer details—canvas resolution, field of view, DDA wall distance calculation, and texture coordinate mapping for the walls.

For performance I'm switching from per-pixel fillRect calls to writing directly into a Uint32Array backing the canvas's ImageData, applying shading for side walls and distance-based fog. I'm generating 64x64 pixel textures procedurally for different wall types (brick, metal, doors) and figuring out how to render enemy sprites per-column with proper depth testing against the wall distances.

For sprites, I'm calculating screen-space dimensions and position using the standard raycasting camera transform (inverse determinant with plane/direction vectors), drawing them after the wall ImageData is placed so they layer correctly, with separate tinted canvas variants for hit-flash effects. I'm also handling enemy line-of-sight by stepping along the line to the player in small increments and checking for solid walls, and starting to work out the shooting raycast logic.

Shooting works by casting a ray along the player's facing direction to get wall distance, then checking each alive enemy's forward/perpendicular offset from that ray against a hit radius, picking the nearest valid hit while walls occlude anything beyond them -- so shots and enemy attacks both respect line-of-sight through walls. I'm defining win/loss conditions (HP depletion for game over, reaching the exit tile once all enemies are dead unlocks it) and setting up player movement collision using a radius check against solid tiles on each axis separately.

For enemies, I'm giving them an alert state triggered by line-of-sight and proximity, after which they chase the player using axis-separated collision so they don't get permanently stuck, and I'll place them carefully in rooms away from the player spawn. I'm planning a DOM-based HUD overlay for health, enemy count, and messages, plus a game-over/win overlay with a restart button, alongside keyboard handling for movement, shooting with cooldown, and visual feedback like muzzle flash, recoil, hit/miss messages, and a red damage flash. I'll drive everything with a capped-delta animation loop and expose a global game object for testing purposes.

Now I'm hand-designing the maze layout as a grid of walls, start, and exit points, but since manual design is error-prone, I plan to verify reachability from start to exit using a BFS check extracted from the file via script before finalizing enemy placement positions throughout the rooms.

I'm writing the texture generator next, packing RGBA pixel colors into little-endian Uint32Array buffers for stone brick, metal panel, red brick, and locked/unlocked exit door textures, then working out the raycasting math for mapping texture columns and rows onto wall slices during rendering...

For shading, I'm applying a brightness factor based on wall side and distance, keeping it cheap enough to run per-pixel at 640x400 resolution. For the floor and ceiling, I'm computing distance-based darkening per row and filling each row efficiently with a single color using array fill, skipping a full checkerboard floor texture for performance but keeping some tonal variation across rows.

For sprites, I'm drawing enemies on an offscreen canvas using basic shapes—a head, body, dark uniform, and red eyes—with a hit-flash variant made by overlaying white at partial opacity. The gun is drawn on the main canvas with recoil offset and a muzzle flash circle, and I'm setting the internal canvas resolution with a responsive CSS size and a 16:10 aspect ratio.

Writing map data...

I'm defining tile codes for walls, exits, and spawn points, embedding enemy positions directly in the map strings using an 'X' marker so I can parse and place them later, and writing a solidity check that treats the exit tile as passable only when unlocked. Now I'm implementing the DDA raycasting algorithm following the Lodev approach—computing step directions and side distances for X and Y, stepping through the grid until hitting a solid tile, with a safety iteration cap to avoid infinite loops.

For hit detection I'll use a simple sample-based march along the ray checking for solid tiles at small intervals, which is simpler than exact DDA for line-of-sight purposes. I'm also working out the camera plane math for rendering each column—computing ray direction from the player's facing angle plus a perpendicular plane vector scaled by the field of view, making sure the sign conventions for sine/cosine stay consistent with how Lodev's reference implementation handles direction and plane vectors.

Now I'm reasoning through strafing and turning direction conventions: defining the "right" vector as the normalized plane vector so strafing keeps consistent with screen orientation, and checking that increasing the player's angle correctly rotates the view so left/right arrow presses turn the camera the expected way on screen.

I'm sketching player movement with wall-collision checks on each axis independently and enemy AI logic, including alert states triggered by line-of-sight and distance, chase behavior toward the player, attack cooldowns and damage, and handling cases where an enemy loses sight of the player.

For shooting, I'm figuring out the hitscan logic: computing forward and perpendicular distances from the player to each enemy to detect hits within a narrow cone, applying damage and flash effects on hit, and showing feedback messages like "HIT," "MISS," or "KILL" without needing complex wall impact decals.

Once all enemies are dead, the exit unlocks with a message, and reaching that tile wins the game; restarting fully reparses the map to reset everything cleanly. I'm also planning the render order—floor/walls, sprites by distance, gun, then overlays—and adding a small minimap in the corner showing walls, player, enemies, and exit for extra clarity.

Writing sprite projection math...

I also want the gun to have a recoil kick and a muzzle flash gradient when firing, plus a damage flash overlay when the player gets hit.

For the HUD, I'm setting up DOM elements for health, enemy count, status messages, and a controls panel, plus an overlay with a title and restart button for game-over states.

I'm mapping keyboard controls (WASD/arrows for movement, space for firing, R for restart) using a keys set so holding space auto-fires via cooldown, and I'll expose a debug object on window so I can inspect game state while testing.

Now I'm sketching out the 15x15 grid maps as string arrays, carefully counting characters per row to make sure each is exactly 15 wide, placing the start, exit, and enemy positions, and planning to verify row lengths and reachability with a BFS check once the code runs.

Writing the HTML page structure and styles for the HUD, health bar, and canvas container...

Finishing the controls hint text, then starting the JS logic: setting up the canvas buffers, raycasting constants, and a map parser that converts the ASCII grid into tile data while recording spawn points, enemy spawns, and the exit location.

Now I'm writing a texture generator using a seeded RNG to create procedural brick patterns, packing RGB values into 32-bit integers for the pixel buffer.

Still writing texture code...

I'm defining metal panel and exit door textures using striped and bordered patterns, then sketching an enemy sprite on an offscreen canvas with legs, a uniform-colored body, arms, and a head drawn with basic shape fills.

Finishing the enemy sprite with a helmet, red eyes, and gun, plus a tint function to flash the sprite white when hit. I'm also setting up core game state (player stats, enemies array, exit/game state flags, crosshair flash) and starting the reset function to reinitialize spawn position and health.

Continuing reset to populate the enemy array with spawn points, cooldowns, and health, then reset game state and show a message about clearing enemies before the exit unlocks. Now I'm writing the update loop handling player turning via arrow keys and forward/strafe movement based on facing angle, with keys tracked in a lowercased set.

Writing collision-aware movement and shooting logic, enemy AI updates, exit-unlock checks tied to alive enemy count, player death handling, and a line-of-sight raycast function that steps along the line checking for solid tiles.

Now I'm fleshing out enemy behavior: alerting when they spot the player within range, chasing when alerted, and attacking with a cooldown-gated damage rule once close enough. I'm also adding visual feedback like attack flashes, then starting on the player's fire function with recoil kick, muzzle flash timing, and a ray cast along the facing direction to detect hits...

Writing hit detection logic...

Now I'm working out the rendering function—shading the floor and ceiling with distance-based brightness, then casting rays per screen column using the camera plane direction to compute wall distances for the raycasting projection.

Writing wall rendering logic...

For the exit tile, I'm picking texture 4 or 5 depending on whether it's open. When open, the tile is walkable so rays pass straight through without hitting a wall there, so I need some other visual cue like a glowing floor to mark it instead of relying on wall rendering.

The simplest fix is to keep the exit cell solid for rendering purposes always, while only making it passable for collision when unlocked—so rays always draw it as a wall (red when locked, green when open), but the player can walk through once it's open.

The player collides into the door cell when it's open, winning on entry; I'm mapping tile types to textures, swapping in the open-door sprite when the exit is unlocked.

For sprites, I'm sorting enemies by distance and projecting them into camera space using the inverse determinant transform from the raycasting matrix, then computing each sprite's screen position, height, and width based on perspective depth, and iterating over the visible columns to draw the sprite texture (or a hit-flash variant) column by column.

I'm checking the z-buffer per column so sprites get occluded correctly by walls and layered properly against each other, then moving to drawing the gun sprite with a kick offset for recoil.

For the minimap I'm weighing whether to show enemy positions — that could make the game too easy by revealing them before exploration, so I'm leaning toward limiting what the minimap reveals.

I'm setting up the HUD update loop to refresh health, enemy count, and exit status each frame, plus a message system that displays text for a set duration before fading. Then I define the game-over and win overlays with their titles and messages, and wire up the main animation loop to call update and render each frame while exposing a debug object on the window for inspecting player state during testing.

For input, I'm adding keyboard listeners that track pressed keys, normalize key names, and trigger a restart on "R", along with a restart button that calls reset directly. I need to make sure focused buttons don't accidentally trigger clicks when spacebar is used for movement.

Now I'm sketching out the 15x15 maze grid row by row, carefully counting characters per row to keep each one exactly 15 cells wide, placing the start, exit, and enemy markers, and planning to verify connectivity with a BFS pathfinding check in Node afterward.

Checking row12 col13, it's 0, which connects down to row13 col13 where E sits, so the exit is reachable from above.

I'm locating the enemy positions by checking the grid rows, finding four 'X' markers at specific coordinates. Now I'll write out the final file with these mappings.

I spot a leftover unused line that's harmless but messy, so I should remove it. I also want to double-check map reachability for the exit and confirm the exit door tile correctly blocks raycasts.

I realize my BFS excluded the exit cell itself, so I need to check reachability of cells adjacent to E instead. Looking at the exit's neighbors in the grid, I'm checking which surrounding cells are open paths rather than walls.

Now I need to redo the BFS properly across the floor cells, tracking which enemy positions are reachable from the start, since my earlier count might be wrong.

My coordinates for X are off, so I need to recompute by carefully indexing each character in the map row string to find where the enemy actually sits relative to the start tile.

Tracing through the walls and open paths row by row, I realize my BFS reachability check was buggy — it only treated '0' as passable, but enemy tiles marked 'X' and 'E' also need to count as passable since they're not actual walls. The fix is to treat anything that isn't '1' as walkable.

Confirming the exit position checks out and all enemies are reachable, with the exit tile only becoming walkable once unlocked. Time to test this in the browser.

The screenshot confirms rendering works, but I spot a bug: the health bar fill isn't showing green because the span is inline by default, so width doesn't apply—I need to set it to display:block to fix that.

Beyond that fix, I should double check the message box and confirm the sandbox warning is harmless. With limited time, I'll apply the fix, re-verify quickly with a screenshot, and test movement with key actions since the player starts at (1.5,1.5) facing east down a corridor.

The health bar shows and the player moved forward, but enemies aren't visible yet, which concerns me since they might be spawned behind walls or not triggering. Given the limited time, I'll quickly check the maze state via JS to verify firing, collisions, and restart functionality instead of visually inspecting every frame.

The miss message likely already expired by the time I inspected the DOM, so no shot feedback was visible — the crosshair stayed white either way. With about 15 minutes left in my time budget, I should keep moving.

I've covered a good amount of testing, but I still haven't checked restart behavior, enemy occlusion, collision, or game-over state, and I should be upfront about that gap rather than claim more coverage than I have. Given the limited budget remaining, I'll stop testing now and report my findings.