Snake · deepseek-v4.1-flash

Let me build the snake game. Let me write index.html.

Key requirements:
- 20x20 board canvas
- arrow keys, ignore reverse including rapid inputs (queue/pending direction)
- food in unoccupied cell
- eating grows, score+, new food
- walls and body collision ends game. Moving into a tail cell vacating on same non-growing step allowed.
- Start, Pause/Resume, Restart buttons. Restart resets all.
- Filling board shows win state.
- Display controls and score.
- prevent arrow scroll.

Let me implement with a direction queue approach to handle rapid inputs correctly.

Actually simplest robust: maintain `dir` and `pendingDirs` queue. On keydown, compute candidate based on last queued direction or current dir; if not opposite, push. At each step, shift one.

Also support WASD maybe, but required arrows.

Let's write the file.

Collision with tail: compute new head. If new head equals tail position and not eating (tail will move), it's allowed. Implementation: determine willGrow = newHead == food. If not grow, the tail cell is removed before checking? Standard: move head, if not grow pop tail, then check if head collides with body. But wall check always. Let's do: newHead; if out of bounds -> gameover. Check collision against body. If not eating, body excluding last segment (tail) is the set to check. If eating, check full body. Then apply.

Win: if snake length == 400 -> win. Also after eating, if length == total cells, win without spawning food. Set food = null.

Let me write.

Wait, there's an issue: after game over, arrow keys do nothing. Also `startBtn.disabled` when over — but restart is available. Fine.

One issue: restart button after game over works. Good.

Let me test in browser.

Initial render fine, though overlay covers the snake. That's fine.

Now test: click Start, then arrow up/left etc. Let me click Start.

Note: the overlay text renders snake under overlay; fine.

Let me click Start at ~ (410,741). Then press ArrowUp, check status. Then pause.

Actually testing movement: I'll press ArrowUp and let it run, then inspect positions via score/length. Let me click start.

Good. Now let me test rapid reverse prevention. Press ArrowLeft (reverse of moving right) — should be ignored. Then press ArrowUp. Then inspect after some time.

Let me press ArrowLeft, ArrowUp quickly. Then screenshot.

Actually to verify the reverse is ignored, I can check the snake still moves right/hasn't reversed. Hard to observe quickly. Let me instead test pause/resume and restart which are easier. But let me do a turn up and observe.

Hmm, Game Over happened quickly. That's suspicious. Why? Pressing ArrowLeft (reverse) should be ignored, ArrowUp changes to up. Snake started at mid (10,10) moving right. It shouldn't hit wall immediately.

Wait — the game over occurred, but at length 3. The snake in the image is at middle-right area partly hidden. Maybe by the time I pressed keys, the game had already run many steps and hit the wall? Actually pressing keys happened right after start but there's latency between tool calls. The snake moves every 130ms. Right wall is 10 cells away = 1.3s. The tool calls took >1.3s probably. So it hit the wall before ArrowUp was applied. Hmm, but the first key was ArrowLeft which is ignored, and ArrowUp applied after. If ArrowUp applied in time, it would go up and hit top wall 10 cells later. Either way, game over.

Actually the sequence: click Start, then two key calls. Time between could exceed 1.3s. So game over is plausible and not a bug. But I need to verify turns work. Let me restart and immediately send keys in same batch? The tools are sequential though. Better: reduce risk by restarting and pressing ArrowUp quickly. But tool latency inherent.

Alternative: I can test with a longer tick to verify. Actually let me just restart, then press key up soon. Let me click Restart then immediately (same message) no—dependent ordering. Let me do restart then key ArrowUp in the same block; they execute in order, hopefully fast. Actually I can't guarantee latency.

Let me just test pause quickly after start: Start then pause. But pause after 1.3s might game-over. Hmm.

Better to verify logic by reading, and use a temporary test harness? I could inject JS via browser? The browser tool doesn't have eval. I can only interact via DOM/keys.

Let me increase TICK_MS temporarily? But that changes final file. Actually I could test with the current timing by using Pause immediately. Clicking Restart then Pause requires running state. Restart sets ready, then Pause button disabled. So need Start then Pause.

Let me try: click Start then Pause in immediate succession. Tool latency maybe <1.3s? The previous batch took enough for game over, but that was between start-click and key press. Let me try.

Actually, the game-over occurred after I pressed left+up; the game likely ran ~10+ steps. That's ~1.3s. Not terrible.

Let me restart and press Up as first key, and check whether length stays 3 and direction changed (snake visible going up). Then pause.

Actually simpler: restart, then send ArrowUp key immediately. Let me do restart then key in one batch.

After restart, food moved to a new free cell (around x=6,y=9), score 0 length 3. Good. Then ArrowUp key started the game (state Playing) and snake still horizontal at that instant. Good.

Now let me quickly pause to freeze, then inspect. Send Space maybe. But by now it may have moved up. Let me pause immediately via key " ".

Actually let's just verify pause/resume. Send Space.

The space didn't pause? Status still "Playing". Interesting. Food moved again (now near x=14,y=16) — meaning game kept running. Wait, the image shows snake still horizontal at center. But status Playing.

Hmm, maybe the space key event's e.key is " " but the `type` action may not send a keydown for space properly? Actually `browser key` with text " " might send a literal space character via input, and e.key would be " ". Hmm.

Wait, actually maybe the game entered a new run? No. Let me look: the snake is at center (unchanged), food moved from (6,9) to (14,16). Food doesn't move on its own. Unless restart was triggered? No.

Hold on—the previous screenshot after ArrowUp: food at around (6,9)? Actually the first (after restart) food was at ~(6,7). The ArrowUp screenshot showed food at ~(5.5, 8) (x=360,y=383). Now food at (14,16). So between, game ran and... food couldn't move unless eaten or restart. The snake stayed at center, so it didn't eat. So something reset the food.

Oh! Maybe pressing space triggered startGame when state was... no. Hmm, or pressing space did pause then... no.

Wait, maybe the " " key triggered `startGame` because state was "ready" at the time? No, it was Playing.

Actually, wait: could the browser key action have sent a keyup that's interpreted differently? Let me reconsider. The food relocation to a random cell strongly suggests resetGame() or placeFood() was called. resetGame sets state ready and shows overlay. But state is Playing.

Hmm, unless the tool's inspect is showing stale/at different time. Actually, the sequence of images might be timing: after ArrowUp, game Playing. Then several ticks pass (snake moving up). But screenshot shows snake horizontal. That's odd—if ArrowUp applied, snake should be vertical.

Unless the ArrowUp key arrived while state was "ready" and my handler: `if (state === "ready") { pushDirection(DIRS[name]); startGame(); }`. pushDirection with ref=dir (RIGHT), next=UP -> valid, queued. startGame sets running. Next tick applies UP. Snake should go vertical.

But screenshot after ArrowUp shows horizontal snake. Hmm, maybe that screenshot was captured at the same instant before the first tick. And the space screenshot: snake still horizontal at exact same position? If it had gone up, it would differ. Unless Snake did not move at all because it's paused! State label says Playing though.

Wait maybe the game did reset. Let me re-examine: Restart click (786,741) — restart button. It reset. Then ArrowUp started. Then Space... 

Actually, maybe the issue: space key press caused page scroll or did nothing because e.key isn't " ". The `browser.key` with text " " might dispatch key value "Space" or e.code Space. My handler checks e.key === " " || e.code === "Space". Should work.

But the status still Playing and snake hasn't moved despite time passing. That suggests the game IS effectively frozen but state label not updated? No, state controls the timer.

Alternatively the tool screenshots may be captured very quickly and the game hasn't ticked due to setInterval throttling in the sandbox/iframe when not focused. Actually! The iframe might be throttling timers. But earlier the game over happened, so timers run.

Hmm, let me think about food change. Actually maybe the snake did move up and loop: Started moving right at (10,10). ArrowUp applied. It goes up. It could have hit top wall and game over, then... but status Playing.

Let me get a fresh inspect now with no action, and maybe screenshot after waiting.

Now Game Over. The snake is still horizontal at center, food at (14,16). So the snake died while horizontal? How? It moved right and hit the right wall. Because ArrowUp wasn't applied? The snake remaining horizontal suggests the ArrowUp direction wasn't applied.

Wait but the food changed. Hmm. Food change is strange. Unless... Oh! I see. Actually the restart happened and the food shown after restart was at (6,7) approx. Then ArrowUp screenshot showed food at different location (~360,383 => x=5.4,y=7.8). Actually maybe I misread; they could be the same cell. Let me not over-analyze.

Key concern: does ArrowUp turn the snake? The snake appears horizontal right up to game over. That suggests direction changes aren't being applied!

Let me check my code. pushDirection: `var ref = dirQueue.length ? dirQueue[dirQueue.length-1] : dir;`. Then ignore reverse/same. Push. Then step shifts dirQueue into dir. That looks right.

But wait: the keydown handler. For ArrowUp, `var name = KEY_DIRS[e.key]`. e.key for arrow up is "ArrowUp" -> "up". Good. If state ready, push and start. Good.

Then step: `if (dirQueue.length) dir = dirQueue.shift();`. Good.

Hmm, but maybe the issue is the space keydown fired BEFORE ArrowUp processed? No.

Actually wait, maybe the browser `key` action doesn't send e.key correctly. Let me test by checking whether the snake visually turns. The game over while horizontal strongly implies ArrowUp never registered.

Actually, there's another possibility: my restart click at (786,741) and then ArrowUp were sent as separate tool calls in the same batch. The click restarted, and the ArrowUp came. The screenshot after ArrowUp showed Playing and horizontal (just started). Then the space key screenshot showed still horizontal and Playing. Then inspect shows Game Over.

If ArrowUp had been queued, after ~1.3s the snake would be vertical. But the space screenshot may have been captured quickly after, and the inspect a bit later. It's possible the snake turned up and the "horizontal" is just the initial state captured before the first tick, then it went up and hit the top wall (10 cells). That's plausible too! In the space screenshot the score is 0, length 3, food at (14,16). In the game over screenshot food also (14,16) and snake horizontal at center. So the snake returned to center horizontal? No, game over leaves the snake at its last position. If it died at top wall, snake would be vertical at top.

The final image shows snake horizontal at center (same as start). That is exactly the start position. So the snake never moved. But game over triggered? That's contradictory unless game over came from a different cause.

OH. I think I understand. The screenshots may all be from "Frame 1" cached? No.

Wait, actually the final image shows the snake at center but the overlay dims it. Hmm, but the snake is horizontal exactly as at start. If it went up and hit wall, it would be at top.

Let me reconsider: maybe the game over is from the FIRST run, and the restart click didn't actually restart because... no, food moved.

Hmm, I wonder if the browser tool re-renders from the same DOM but the canvas snapshot is stale. The `inspect` returns images attached, likely a fresh screenshot each time. Yet all show the snake horizontal at center — because on game over, overlay appears and the canvas isn't cleared. If the snake went up, canvas would show it vertical.

Let me carefully re-examine the food: In the game over image, food is at around (748,520) => x = (748-323)/27.6 ≈ 15.4, y=(520-148)/27.5≈13.5. Hmm.

I think there may be a real bug where direction changes are ignored. Let me look again very carefully.

```
function pushDirection(next) {
    var ref = dirQueue.length ? dirQueue[dirQueue.length - 1] : dir;
    if (next.x === -ref.x && next.y === -ref.y) return;
    if (next.x === ref.x && next.y === ref.y) return;
    if (dirQueue.length < 2) dirQueue.push(next);
}
```
Fine.

step:
```
if (dirQueue.length) { dir = dirQueue.shift(); }
```
Fine.

Hmm, but there's a subtle bug: `dir` is assigned to a shared DIRS object. When we set `dir = dirQueue.shift()`, dir references UP object. Fine.

Wait, maybe the browser tool's key action sends key with text but doesn't dispatch a proper keydown event that our document listener catches because focus is on the iframe? It did trigger startGame though, since state went Playing after ArrowUp. Actually did it? Restart click set state ready. Then after ArrowUp, state became Playing. So the keydown WAS received. And if received, name="up", pushed. So it should turn.

Unless the keydown was for something else... Actually maybe the click at (786,741) hit Restart and then the key ArrowUp started. Then the space key. Then game over.

But snake staying horizontal is bizarre. Unless setInterval `step` isn't firing and the game over came from something else... but then how did state become Game Over?

Oh! Maybe the game WAS moving and the canvas snapshots are just not updating because the canvas is only redrawn on step, and these snapshots happened to catch it after a reset? No.

Let me just do a cleaner test: restart, then immediately pause (so it doesn't move), then check status. Actually pause button is disabled until running.

Alternative approach: Add a temporary on-screen debug of head position / dir to inspect. But editing the file and reloading resets state anyway. That's fine; I could add a debug line. Actually simpler: use `document.title`? Browser inspect gives DOM text. I could render dir/head in the status. But that changes file. I can add a small debug element, test, then remove. But time.

Actually, let me reconsider the timestamps: every tool result says "Frame 1, +0ms". That might mean the page isn't actually advancing frames between tool calls — i.e., the iframe is frozen/lazy and screenshots are captured only when the page is interacted with, and rendering happens. setInterval may be throttled heavily when the page isn't the active/focused document. So the game might only tick once per tool call. That would explain why the snake barely moved between screenshots! And game over after many calls because each call advances maybe a few ticks.

If timers are throttled, then between the ArrowUp call and space call the game moved only a little, snake might still look horizontal. And the ArrowUp direction may have been applied later.

I think the most reliable test is to add a debug readout. Let me add a temporary element showing dir and head coords, plus maybe a "steps" counter. Actually, I can add a hidden element updated each draw, and read via inspect DOM. Let me add it, reload, run a controlled test: ArrowUp then check dir text.

Let me add `document.title = state` etc. Hmm, the inspect gives DOM text of body, so a visible/hidden div works.

Let me add a debug div with id "dbg" and update in draw: dir name + head. I'll remove later.

Actually, to reduce effort, I'll add it permanently as part of status? No, remove.

Let me edit.

Add the dbg div inline after subtitle.

Now send ArrowUp and inspect immediately (before any tick ideally). Actually first test rapid reverse: from ready, send ArrowLeft (reverse) -> should be ignored (q stays 0), then ArrowUp -> q=1. But in ready state, pushDirection then startGame. If ArrowUp starts, q remains 1 until first tick. Let me send ArrowLeft first and inspect: q should be 0 and state ready (since only valid dirs start game? In ready, pushDirection happens then startGame regardless, even if the direction was ignored. So pressing ArrowLeft in ready would start the game with q=0, still going right). Hmm, that's a minor thing.

Let me instead do: press ArrowLeft while ready -> starts game; then check dir still 1,0. That tests reverse ignore.

Actually better test: after game running right, press ArrowLeft then ArrowUp rapidly, and check resulting head moves up not left. Let's do:
1. reload (done, ready).
2. Press ArrowRight? already going right. Let's just start with ArrowUp? That's a turn, valid.

Test reverse: while ready, press ArrowLeft. It should be ignored and game starts still going right. Then inspect: dir should be 1,0 and state running. This verifies reverse ignored.

Then press ArrowUp, inspect after a tick: dir should be 0,-1.

Let me do ArrowLeft.

Interesting: state says "ready" in dbg but status says "Playing". dbg was not updated after startGame because draw() isn't called on start. So dbg shows last draw (ready). That's fine. The reverse ArrowLeft was ignored (dir still 1,0, q=0). Good—reverse ignored, game started.

Now press ArrowUp and inspect. draw happens each tick, so dir should update.

dbg: state=running dir=1,0 head=19,10. So the snake ran all the way to the right wall and game over before the ArrowUp arrived. That means between my tool calls, the game runs to completion (about 9 ticks = 1.2s), and the key press arrives after game over. So timers ARE running fast; my tool latency is ~1.2s+. That explains everything. The ArrowUp during game-over is ignored (state over), so no turn.

So the game works; the issue is just test latency. I need a way to press keys with less delay or slow the game. To verify turn handling, I can temporarily increase TICK_MS to e.g. 1000ms, test, then restore to 130. That's reasonable.

Let me set TICK_MS = 1000 temporarily. Actually I could test with 800. Let me do it.

Now start with ArrowUp and let one tick, then inspect. Since tick is 1500ms, I have time.

Let me start by pressing ArrowUp, then inspect. The first tick after 1.5s. Tool latency might be ~1s. Let me press, then inspect soon. But the head will move after 1.5s. Either way dir should become 0,-1. Actually dir updates on first step.

Let me press ArrowUp then immediately inspect. Then also test rapid reverse: press ArrowLeft then ArrowDown quickly before tick? Let me first do a clean single test.

Plan:
1. ArrowUp (starts game, queues up)
2. Then immediately ArrowRight? That would set ref=UP (queued), RIGHT not opposite, queue [UP,RIGHT]. Then after two ticks dir goes up then right. Good test of rapid inputs.

But maybe simpler: just ArrowUp then inspect after tick -> dir=0,-1, head=10,9.

Let me do ArrowUp and inspect.

Now inspect again (a tick should have passed, ~1.5s). Let me inspect.

Now dir=0,-1 head=10,8. Wait head moved from 10,10 to 10,8? That's two cells. Because two ticks passed (each 1.5s) between calls. Fine. Snake vertical, going up. Turning works. 

Now test reverse prevention mid-game: currently dir=0,-1 (up). Press ArrowDown (reverse) then ArrowLeft quickly. Reverse should be ignored, left queued. Then after tick dir should be -1,0. Let me press ArrowDown then ArrowLeft in one batch. Note tools in a batch execute sequentially but fast.

Actually including ArrowDown then ArrowLeft: ref initially dir=UP. ArrowDown is reverse -> ignored. ArrowLeft: ref=UP, valid -> queue. Good. Then inspect, expect dir=-1,0.

But timing: 1.5s tick; batch should be under. Let's do.

Both screenshots identical and head=10,5 still. dir still 0,-1, q=0. The keys didn't register? Because the canvas/page may not have focus? Wait earlier ArrowUp worked. Hmm, but the down/left presses: the second screenshot identical to first—maybe both tool calls captured the same frame before processing? The dbg still shows head=10,5 q=0, meaning no tick occurred and no key registered.

Wait — reverse ArrowDown ignored (expected q=0), then ArrowLeft should push q=1. But q shows 0. So ArrowLeft wasn't received. Unless the key events are delivered but the page hadn't rendered a new draw (q only updated on draw, which happens on step). Right! `pushDirection` doesn't call draw, so q won't reflect until next step. And no step happened between the two rapid calls. So q shown is stale.

Hmm, so this test is inconclusive from dbg. I need to wait for a tick then inspect. But if I wait, the next tick applies left and head moves. Let me inspect now (after a tick). Expect dir=-1,0 if left was queued; or dir=0,-1 if not.

Wait, but actually there's a concern: after ArrowDown was ignored and ArrowLeft queued, the next step should apply LEFT. Let's inspect.

dir=-1,0, head=7,5. Snake turned left (ignored the reverse Down, applied Left). Head moved from 10,5 to 7,5 over 3 ticks. Movement is grid-aligned and direction changes work. 

Now test pause/resume. Press space. Since tick is slow, game at x=7,5 moving left. Press space -> should pause. Let me press space then inspect. Also verify that while paused, head doesn't change across inspections.

Paused. dbg still shows state=running because draw wasn't called on pause; but status shows Paused and overlay visible, button says Resume. Head=5,5. Good.

Note the snake is at x=5,5 near left wall. If I resume, it'll hit wall in 5 ticks. Let me test restart instead.

Now test Restart: click restart, then inspect: length 3, score 0, state ready, food in free cell. Let me click restart at (786,741).

Restart reset: state ready, head 10,10, dir right, length 3, score 0. But status still says "Paused"! Because resetGame calls updateHud and setStatus? Let me check resetGame: it calls updateHud(), updateControls(), showOverlay(...), draw(). It does NOT call setStatus. So status text remains "Paused" from before. That's a bug — restart should reset status to "Ready".

Let me fix: in resetGame, set setStatus("Ready").

Also the dbg will be removed later.

Now the food free-cell check: dbg doesn't show food. But visually food at (10,14) and snake at center, free. Fine.

Let me fix the status bug, remove debug, restore TICK_MS to 130. Also reconsider: after game over, Start button disabled; user must Restart. Fine.

Another thing: after win, resetGame from start? Start disabled on win. Restart available.

Also note: pressing arrow keys when state is "over"/"won" does nothing (since handler only handles ready/running/paused and doesn't preventDefault for arrows in over state — actually it does `if (name) { e.preventDefault(); ... }` so scroll prevented). Good.

One more: in `updateControls`, startBtn disabled when over/won. Good.

Let me also double check the tail-vacate logic. limit = willGrow ? snake.length : snake.length-1; loop over i<limit includes index 0..len-2 for non-grow, excluding last tail. Correct.

Edge: when snake length is 1? Never (starts 3). Fine.

Win condition: snake.length >= CELLS after unshift before pop; updates and endGame(true). Good. placeFood returning false also triggers win (shouldn't happen otherwise).

Now also the dbg is gone. Let me make edits.

Now reload and verify final. Also verify no leftover dbg. Let me reload and inspect.

I should also verify the "restart resets status" and food free. Quick test: reload (fresh ready), then click restart, status Ready. And test game over -> restart resets.

Let me reload and inspect.

Good. Now test the restart status reset. Click Start (runs), then click Restart, inspect status should be Ready.

Actually just click Restart directly from ready — status already Ready, wouldn't catch bug. Let me Start then Restart. Start button at (410,741), Restart (786,741). Do both in one batch.

Restart now resets status to "Ready". Good.

Now let me verify the win/game-over paths briefly and food consumption. Since runtime is real-time, I can't easily steer to food across tool latency. I already verified core logic by reading. Let me at least verify game over from wall with real speed happens and Restart resets. From the ready state, Start then wait -> snake runs right into wall -> Game Over. We saw this earlier. Good.

I should verify eating/food growth. Hard to steer. But I could temporarily shrink the board or place food in the path? Not worth. Logic is straightforward.

Actually I can verify food eating by placing the snake moving right and food happens to be in its row. On this reset, food is at (~1,10) left side, snake moving right - won't hit. Not helpful.

I'll trust the logic. Let me do one more: confirm no console errors. Console only had the sandbox warning, no errors. Good.

Let me also verify arrow key scroll prevention — page isn't scrollable vertically much, but preventDefault is in code.

Final file is clean. Let me do a final quick read of the key logic to ensure nothing broken by edits. Actually let me just grep the resetGame and confirm.

I'm fairly confident. Let me do a final reload to ensure it starts clean, and report.

Time budget fine. Let me report.

Done. Final report.