2048 · kimi-k3

Let me build a standard 2048 game in one index.html file. I'll implement grid state, move logic, spawn, animations via absolutely positioned tiles, input queue/lock during animation, win/game over overlays, New Game button, keep-playing after win.

Let me write the file, then test in browser.

Implementation plan:
- 4x4 grid, tile size ~100px with gap 12px.
- Tiles as absolutely positioned divs with transition on transform.
- Board model: array of 16, storing tile objects {value, id, merged flag?} for animation.
- On move: compute per line traversal, build list of moves (from, to) and merges. Apply to model, then animate: update tile positions, then after transition, spawn new tile, update DOM for merged values.
- Lock input during ~150ms animation; ignore moves while animating (queue one? just ignore is fine; requirement says prevent corruption — locking works).
- Score increments by merged values.
- Win when a tile reaches 2048 (first time), show overlay with continue and new game.
- Game over when no empty cells and no adjacent equal.
- preventDefault on arrow keys.

I'll render tiles from a dictionary keyed by tile id so animations work smoothly. Each tile object: {id, value, row, col}. On merge, the destination tile's value doubles and source tiles slide to it and are removed after animation.

Simpler approach: keep model as grid of tile objects. Move algorithm per line:

For direction left: for each row, take tiles in row in order, merge: standard algorithm producing new values array and also record animations.

To animate properly: iterate traversal order, for each tile find target position (farthest empty or merge with last placed tile if not already merged this move).

I'll write the code.

For DOM: container #board with 16 background cells, and #tile-container for tiles. Each tile div positioned via transform translate based on row/col.

Move handling:
```
function slide(dir) {
  if (animating) return;
  const result = computeMove(dir); // returns {moved, moves: [{tile, fromRow, fromCol, toRow, toCol, mergeInto?}], gained}
  if (!moved) return;
  animating = true;
  // update tile positions in model, apply transforms
  // for merges: two tiles move to same cell; mark the "kept" tile to double after animation
  setTimeout(() => { finalize: update merged values, remove absorbed tiles, spawn new tile, update score, check win/over, animating=false }, 160)
}
```

Let me just code it carefully.

Compute move per line: represent lines as arrays of cell indices in traversal order. For left: rows: [r*4+0..3]. For right: reversed. For up: columns top-down. For down: columns bottom-up.

Algorithm: for each line, collect tiles (non-null) in order. Then walk through building new line: for each tile, if last placed tile in new line has same value and wasn't merged this move, merge into it (mark), else place at next position.

I'll track: each tile gets target index in the line. Merged pair: second tile targets same index as first; the first tile stays and doubles (record pendingDouble), second gets removed after anim.

Implementation:

```
function buildTraversals(dir) {
  const lines = [];
  for (let i=0;i<4;i++){
    const line=[];
    for (let j=0;j<4;j++){
      let r,c;
      if(dir==='left'){r=i;c=j}
      else if(dir==='right'){r=i;c=3-j}
      else if(dir==='up'){r=j;c=i}
      else {r=3-j;c=i}
      line.push(r*4+c);
    }
    lines.push(line);
  }
  return lines;
}
```

Move:

```
function attemptMove(dir){
  if(state.animating||state.over) return;
  const lines = buildTraversals(dir);
  let moved=false, gained=0;
  const actions=[]; // {tile, toIdx, merge:boolean}
  const newGrid = new Array(16).fill(null);
  for(const line of lines){
    let writePos=0; let lastTile=null; let lastMerged=false; let lastIdx=-1;
    for(const idx of line){
      const t = grid[idx];
      if(!t) continue;
      const targetIdx = line[writePos];
      if(lastTile && !lastMerged && lastTile.value===t.value){
        // merge into lastTile
        actions.push({tile:t, toIdx:lastIdx, absorbed:true});
        lastTile.pendingValue = lastTile.value*2;
        gained += lastTile.value*2;
        moved = true;
        lastMerged = true;
      } else {
        actions.push({tile:t, toIdx:targetIdx, absorbed:false});
        if(targetIdx!==idx) moved=true;
        lastTile=t; lastMerged=false; lastIdx=targetIdx;
        writePos++;
      }
    }
  }
  if(!moved) return;
  ...
}
```

Wait: after a merge, writePos should not advance, and lastMerged=true means next tile can't merge with it again. Good.

Then apply: set animating, move all tile elements (update t.row/t.col from toIdx, set transform). For absorbed tiles set z-index lower so they slide under. After timeout: remove absorbed tile elements and delete from grid; for kept tiles with pendingValue, set value, update element class/text, pop animation. Rebuild grid: set grid all null then place remaining tiles by row/col. Then spawn random tile with appear animation. Update score. Check win (any tile 2048 and !won → show win overlay). Check game over.

New game resets.

Input lock: set animating=true during 140ms, ignore keydowns (or queue latest). Ignoring is fine and prevents corruption.

CSS: tile colors per value, classic 2048 palette. Font sans-serif.

Overlay: div with message and buttons. Win overlay: "You win!" with Continue and New Game. Game over: "Game Over" with New Game.

Score display and best maybe (no localStorage needed but fine; skip network only; localStorage is allowed but I'll skip to keep simple... actually best score via localStorage is fine and sandbox-safe. Keep it simple: just score.)

Let me write the file.

Tile rendering: 
```
.tile { position:absolute; width:100px; height:100px; transition: transform 130ms ease-in-out; }
.tile-inner { ... } // so pop animation doesn't conflict with transform
```
Use inner div for background/scale animations, outer for position transform. Good.

Container size: 4*100 + 5*12 = 460px.

Spawn: random empty cell, value 2 (90%) or 4.

Game over check: if any empty → moves possible. Else check adjacent equals.

Write and test with browser: press arrow keys via key action, screenshot, check console. The browser tool key action — I can send keys like "ArrowLeft". I'll do a sequence, screenshot, then click New Game and verify 2 tiles and score 0.

Let me write the HTML.

The DOM shows two "2" tiles in text but the screenshot doesn't show the tiles visually. The DOM shows "2\n2" at end — tiles exist. But screenshot shows empty board. Possibly tiles are rendered but the screenshot was taken before the appear animation? No — animation is 180ms with 60ms delay, screenshot after load should show them. Hmm, tiles might be positioned at translate but maybe placed under the background cells? z-index: tile-layer comes after cells in DOM, so it's on top. Wait — cells are position absolute within board, tile-layer is absolute inset 0, tiles inside. Should be on top.

Maybe screenshot was captured during appear animation backwards fill... animation: appear 180ms ease 60ms backwards — with backwards fill it starts at scale(0). If screenshot at +0ms (Frame 1, +0ms), tiles still at scale 0. That explains it. Let me take another screenshot after a moment.

Two tiles showing, score 0, no console errors. Now play a sequence of moves: ArrowLeft, ArrowUp, ArrowRight, ArrowDown etc. and verify tile count increases and merges update score.

The screenshot was taken mid-animation (bottom tile sliding left). DOM still shows 2 tiles because spawn happens after 140ms. Let me wait / take another screenshot, then continue pressing keys. Let me send a few more keys and then inspect.

Interesting: after ArrowLeft, the two 2s merged into a 4 (score 4), and a new 2 spawned. Now DOM shows tiles: 2 (top-left), 2 (bottom-left), 4 (bottom row). Wait — after ArrowLeft both 2s were in leftmost... actually the top 2 was already at left; bottom 2 slid left, but they are in different rows so no merge from ArrowLeft. Then score went 0→4. Hmm, actually the "4" appeared — maybe from ArrowUp merge? Let's reconstruct:

Initial: 2 at (0,0), 2 at (3,2).
ArrowLeft: 2 at (3,2) slides to (3,0). Spawn one tile.
ArrowUp pressed: screenshot captured mid-state. Score is 4 and there's a 4 tile at bottom row. So after ArrowLeft a spawn happened... then ArrowUp moved tiles up; the screenshot shows tiles mid-animation sliding up. Score 4 means a merge happened: two 2s merged. Possibly after ArrowLeft, spawn placed a 2, and ArrowUp merged two 2s in column 0 (the (0,0) and (3,0) tiles) into a 4... but the 4 shows at bottom row in screenshot — that's mid-animation? No, mid-animation tiles slide, the 4 would only appear after animation completes at top. Hmm, the 4 at bottom row column 3 area is light yellow (v4 color). Odd.

Actually wait — the screenshot was taken at "+0ms" — frame timing might vary. Maybe this screenshot is actually after ArrowUp completed: tiles slid up... but the 2s are at top-left and bottom-left? If ArrowUp completed, the 2 at (3,0) should have moved up and merged with (0,0) into 4 at (0,0). But screenshot shows 2 at (0,0) and 2 at (3,0) still, with a 4 at (3,2)-ish.

Alternative: the keypress ArrowUp may have been captured, and the screenshot taken before the move was processed (animation in progress from ArrowLeft finalize). Hmm.

Wait, but score=4 and DOM lists three tiles: 2, 2, 4. So a merge of 2+2→4 occurred somewhere and a new tile spawned. Sequence: after ArrowLeft: tiles 2@(0,0), 2@(3,0), plus spawn. If the spawn was a 2 at... ArrowUp: column 0 has 2@(0,0) and 2@(3,0) → merge into 4@(0,0), score 4. Screenshot should show 4 at top-left then. But screenshot shows 2 at top-left.

Unless the screenshot is stale relative to DOM. The tool seems to capture at +0ms each time — maybe the screenshot was taken right at keypress before rerender/animation. The "4" tile at bottom could be the spawned tile (10% chance of 4!) from the ArrowLeft move. Yes! Spawn is 2 with 90%, 4 with 10%. The 4 at bottom row is a spawned 4. But then why score 4?

Hmm, let me reconsider: maybe after ArrowLeft, tiles: 2@(0,0), 2@(3,0), spawned 4@(3,2)? Then ArrowUp: column 0: 2,2 merge → 4@(0,0), score=4; column 2: 4@(3,2) → moves to (0,2). Then spawn one more. DOM would have: 4@(0,0), 4@(0,2), new spawn. DOM text shows "2\n2\n4" though. That doesn't match.

Alternatively the DOM text order is by tile id creation order: "2, 2, 4" = original two tiles + ... no wait, merged tile keeps first tile's element and updates text to 4.

Let's not over-deduce from a possibly-mid-animation screenshot. The key observations: score updated to 4 consistent with a 2+2 merge, DOM has 3 tiles (2 merged away + 1 spawned from 3 previous? 2 tiles → after move with merge: 1 merged + spawn = 2 tiles; without merge: 3 tiles). We have 3 tiles and a merge happened... 2 initial + spawn after left = 3; ArrowUp merged 2 of them (3-1=2) + spawn = 3. Score 4 ✓. DOM shows 2,2,4 which fits: merged 4 plus two 2s.

The screenshot likely caught the animation mid-flight (tiles sliding up). Fine. Continue playing more moves and take a screenshot after settle.

Score 12 now: 4+8? Previous score 4, ArrowRight merged two 4s into 8 → 4+8=12 ✓. DOM shows 4,4,2 — hmm, if two 4s merged into 8 we'd expect an 8 tile. But DOM shows 4,4,2 and the screenshot shows two 4s sliding (mid-animation, the merge result 8 appears after animation). Wait DOM was captured at +0ms — the finalize timeout (140ms) hasn't fired yet, so DOM still shows pre-finalize state: two 4s sliding together and a 2. Score already incremented (score updates immediately). That matches mid-animation capture.

Let me take a screenshot after the animation settles to verify the 8 tile.

The two 4s merged into an 8 at top-right, a new 2 spawned, tiles slid right correctly. Board: 8@(0,3), 4@(1,2), 2@(1,3). Score 12 ✓.

Now test New Game reset. Click the New Game button at approximately (775, 117).

Score reset to 0 and DOM shows exactly 2 tiles. The screenshot was taken during the spawn appear-animation (tiles scale from 0), which is why they aren't visible yet. DOM confirms "2\n2".

Now let me test the win path and game-over logic quickly via logic — can't easily reach 2048 through gameplay in limited time. I could test by injecting via console? The browser tool doesn't have an evaluate option. I could temporarily test game over by playing many random moves, but that's time-consuming. The logic is straightforward and reviewed: 

- Win: reached2048 flag when a doubler hits 2048 → overlay "You win!" with Keep going → keepPlaying=true, hideOverlay. Note: while overlay shown and !keepPlaying, move() returns early — good, blocks moves until choice.
- Game over: checked after each finalized move via canMove(). Only shown when no moves remain. ✓
- No spawn after unchanged move: move returns early when !moved, before spawning ✓.
- preventDefault on arrows ✓.
- Input lock during animation: animating flag ✓.

One issue to double check: after win overlay shown and user keeps playing, if they later make another 2048 (a second one), `won` is already true so no re-show — fine.

Also: overlay "Keep going" hidden for game over ✓.

One subtle bug check: in move(), if user wins but overlay is up (won && !keepPlaying), we return early — but what if user presses New Game? newGame resets won/keepPlaying — fine.

Another check: after game over, move() returns due to over=true. New Game resets. ✓

Edge: the "merged" class pop animation z-index... fine.

Quick verification of merge-once semantics with [2,2,2,2] left: line traversal: first 2 placed (writePos 0→1, lastTile=2a), second 2 merges into 2a (lastMerged=true), third 2: lastMerged true so placed at writePos 1 (lastTile=2c, lastMerged=false), fourth 2 merges into 2c. Result [4,4,0,0] ✓. [2,2,4,0]: 2+2→4 at pos0, lastMerged=true; 4 placed at pos1 → [4,4,0,0] ✓.

Everything checks out. Let me take one final screenshot to confirm the new game board shows two tiles after animation, and maybe play one quick move to double-check reset board works.

After New Game, the two fresh 2s spawned in the same column; ArrowDown merged them (score 0→4 ✓, merge captured mid-animation sliding down). All core behaviors verified:

- Tiles slide ✓
- Valid move spawns a tile ✓
- Merges update score by merged value (4→+4, +8) ✓
- New Game resets board to 2 tiles, score 0 ✓
- No console errors ✓

Merge-once semantics verified by code review ([2,2,2,2]→[4,4] etc.). Win/Game-Over overlays not reachable in a short manual play session — verified by code logic review only. Done. Report.