2048 · deepseek-v4.1-flash

Let me build the 2048 game. I'll write a clean self-contained index.html.

Let me plan the implementation:
- 4x4 grid of tiles, absolute positioning with transforms for animation.
- Tile objects with id, value, row, col, merged flag.
- Board state as 2D array of tile objects or values.
- Move logic: for each row/column, compact and merge.
- Animation via CSS transforms and transitions.
- Input locking during animation.
- Score, win message, game over, new game.

Let me write it.

I'll use a DOM-based approach with tile elements positioned absolutely, using transitions on transform.

Design:
- Board container size 400px (or responsive). Grid cells drawn as background.
- Each tile has absolute position computed from row/col.
- On move, compute new positions, update tile transforms, then after transition, remove merged tiles and spawn new tile.

Let me implement carefully.

State: `grid` 4x4 of tile objects {id, value, el, r, c}. Actually simpler: maintain tiles list.

Move algorithm for left:
For each row r:
  get tiles in row sorted by c.
  Build result positions: iterate, if current tile value equals next tile value and neither merged, merge.
  
Let me do a standard approach producing target positions.

I'll represent grid as array of 16 slots each null or tile object.

Move left:
for each row:
  collect tiles = cells in row with tile, ordered by col.
  let target = 0; let lastMerged = null;
  Actually simpler:
  let newRow = []; // list of {tile, value}
  for each tile in order:
    if newRow not empty and newRow[last].value === tile.value and !newRow[last].merged:
       merge: newRow[last].value *= 2; newRow[last].merged = true; score += newRow[last].value; mark tile to be removed, its position moves to target col.
    else:
       newRow.push({tile, value: tile.value, merged:false})
  
Then assign columns 0..n-1.

For animation: 
- The surviving tile moves to target position. The consumed tile also moves to target position then is removed.
- Merged value: we can update the surviving tile's value after movement completes, or immediately with a pop animation. Better: keep displayed value until movement completes, then update to merged value with pop.

Let me track each tile's el. On merge, the "keeper" is the first tile, the other tile is consumed. Both animate to the same cell. After transition, remove consumed element, update keeper's value/display and add pop.

Changed detection: if any tile moved or merged.

Spawn: after move, if changed, pick random empty cell, create tile with value 2 (90%) or 4, with appear animation.

Input lock: `animating` flag, set true on move, release after transition (e.g., 120ms). Use setTimeout.

Let me write the code.

Cell size: board padding and gap. I'll use CSS variables.

Board 460px with 4 cells. Let's compute: cell = 100px, gap = 12px, padding = 12px. board = 12*2 + 100*4 + 12*3 = 24 + 400 + 36 = 460. Good.

Position: left = padding + c*(cell+gap) = 12 + c*112. top similarly.

Use transform: translate(x, y) for tiles for GPU animation. Tile positioned at 0,0 with width/height cell.

Let me write HTML:

```html
<div class="game">
  <div class="header">
    <h1>2048</h1>
    <div class="scores">
      <div class="score-box"><span>SCORE</span><strong id="score">0</strong></div>
      <button id="new-game">New Game</button>
    </div>
  </div>
  <div class="board" id="board">
    <div class="grid-bg">... 16 cells ...</div>
    <div class="tile-layer" id="tile-layer"></div>
    <div class="overlay" id="overlay">
       <div class="overlay-content">
         <h2 id="overlay-title"></h2>
         <p id="overlay-msg"></p>
         <div class="overlay-buttons">
           <button id="keep-going">Keep Going</button>
           <button id="try-again">Try Again</button>
         </div>
       </div>
    </div>
  </div>
  <p class="hint">Use arrow keys to move tiles.</p>
</div>
```

Overlay for win and game over.

Let me write JS.

```js
const SIZE = 4;
const CELL = 100, GAP = 12, PAD = 12;
const STEP = CELL + GAP;

let grid; // 2D array [r][c] = tile or null
let tiles; // not needed, derive from grid
let score = 0;
let tileId = 0;
let animating = false;
let won = false;
let keepGoing = false;
let gameOver = false;

const tileLayer = document.getElementById('tile-layer');
const scoreEl = document.getElementById('score');
const overlay = ...
```

createTile(value, r, c, isNew):
```js
function makeTile(value, r, c, spawn) {
  const el = document.createElement('div');
  el.className = 'tile tile-' + value;
  el.textContent = value;
  el.style.transform = pos(r,c);
  if (spawn) el.classList.add('tile-new');
  tileLayer.appendChild(el);
  const tile = {value, r, c, el};
  grid[r][c] = tile;
  return tile;
}
```

pos(r,c) => `translate(${PAD + c*STEP}px, ${PAD + r*STEP}px)`.

Actually better to use translate with cell units? px fine.

Move function:

```js
function move(dir) {
  if (animating || gameOver) return;
  const vectors = {
    left: {dr:0, dc:-1}, right:{dr:0,dc:1}, up:{dr:-1,dc:0}, down:{dr:1,dc:0}
  };
  const {dr, dc} = vectors[dir];
  let changed = false;
  let gained = 0;
  const removals = [];
  const merges = []; // {tile, value}

  // Traverse order: for left, process cells left to right; for right, right to left; etc.
  const rows = [...Array(SIZE).keys()];
  const cols = [...Array(SIZE).keys()];
  const rOrder = dr > 0 ? [...rows].reverse() : rows;
  const cOrder = dc > 0 ? [...cols].reverse() : cols;
  ...
}
```

Hmm, the standard algorithm: for each line, traverse from the direction edge. Let me do line-by-line.

For each line (row for horizontal, col for vertical), gather tiles in order from the edge toward which we move. E.g., moving left, gather from col 0 to 3. Moving right, gather from col 3 to 0.

Then process the list with merge logic, assigning to target positions starting at the edge.

Let me write generic:

```js
function move(dir) {
  if (animating || gameOver) return;
  const horiz = (dir === 'left' || dir === 'right');
  const forward = (dir === 'left' || dir === 'up'); // gather from low index
  let changed = false;
  let gained = 0;
  const removals = [];
  const mergeUpdates = [];

  for (let line = 0; line < SIZE; line++) {
    // gather tiles
    let cells = [];
    for (let i = 0; i < SIZE; i++) {
      const idx = forward ? i : SIZE - 1 - i;
      const r = horiz ? line : idx;
      const c = horiz ? idx : line;
      if (grid[r][c]) cells.push(grid[r][c]);
    }
    // process
    const result = [];
    for (let i = 0; i < cells.length; i++) {
      const t = cells[i];
      if (result.length && result[result.length-1].value === t.value && !result[result.length-1].merged) {
        const keeper = result[result.length-1];
        keeper.merged = true;
        keeper.newValue = keeper.value * 2;
        keeper.consumed = t;
        gained += keeper.newValue;
      } else {
        result.push({value: t.value, tile: t, merged: false});
      }
    }
    // assign positions
    result.forEach((entry, i) => {
      const idx = forward ? i : SIZE - 1 - i;
      const r = horiz ? line : idx;
      const c = horiz ? idx : line;
      // clear old grid
      ...
    });
  }
}
```

This is getting complicated with grid updates. Let me first clear grid, then process.

Simpler: build new grid from scratch.

```js
function move(dir) {
  if (animating || gameOver) return;
  const horiz = dir === 'left' || dir === 'right';
  const forward = dir === 'left' || dir === 'up';
  const newGrid = emptyGrid();
  let changed = false, gained = 0;
  const removals = [];
  const mergeUpdates = [];

  for (let line = 0; line < SIZE; line++) {
    const cells = [];
    for (let i = 0; i < SIZE; i++) {
      const idx = forward ? i : SIZE - 1 - i;
      const r = horiz ? line : idx;
      const c = horiz ? idx : line;
      const t = grid[r][c];
      if (t) cells.push(t);
    }
    const result = [];
    for (const t of cells) {
      const last = result[result.length - 1];
      if (last && last.value === t.value && !last.merged) {
        last.merged = true;
        last.consumed = t;
        gained += last.value * 2;
        last.newValue = last.value * 2;
      } else {
        result.push({ value: t.value, tile: t, merged: false });
      }
    }
    result.forEach((entry, i) => {
      const idx = forward ? i : SIZE - 1 - i;
      const r = horiz ? line : idx;
      const c = horiz ? idx : line;
      const t = entry.tile;
      if (t.r !== r || t.c !== c) changed = true;
      // update grid
      newGrid[r][c] = t;
      t.r = r; t.c = c;
      if (entry.merged) {
        mergeUpdates.push({ tile: t, value: entry.newValue, consumed: entry.consumed });
        changed = true;
      }
      if (entry.consumed) {
        removals.push(entry.consumed);
      }
    });
  }

  if (!changed) return;

  grid = newGrid;

  // Animate all tiles to their new positions
  for (const t of allTiles()) {
    t.el.style.transform = pos(t.r, t.c);
  }
  // consumed tiles also move to keeper position
  for (const u of mergeUpdates) {
    u.consumed.el.style.transform = pos(u.tile.r, u.tile.c);
    u.consumed.el.style.zIndex = 1;
    u.tile.el.style.zIndex = 2;
  }

  animating = true;
  score += gained;
  // update score after? show immediately maybe.
  ...
  setTimeout(() => {
    // remove consumed
    for (const u of mergeUpdates) {
      u.consumed.el.remove();
      u.tile.value = u.value;
      u.tile.el.textContent = u.value;
      u.tile.el.className = 'tile tile-' + u.value + ' tile-merged';
      // remove pop class after
    }
    ...
    spawnTile();
    animating = false;
    checkState();
  }, MOVE_MS);
}
```

Wait, there's an issue: consumed tile's grid reference removed already since newGrid only holds keeper. Good.

allTiles: iterate newGrid.

Actually the consumed tiles need to be animated. They're not in newGrid, but I have references via mergeUpdates. Good.

But also there might be tiles that didn't merge but moved — they're in newGrid.

Score display: I'll update score after animation or immediately. Let's update immediately so user sees. Actually let me animate score count? Keep simple: set immediately.

MOVE_MS = 120.

checkState: if any tile === 2048 and !won -> win. If no moves -> game over.

Spawn only after changed move. Good.

Need to ensure spawn happens after animation. Yes.

But rapid input: animating flag prevents. However, keyboard repeat could queue. Since we ignore while animating, fine.

Actually, a subtlety: if input comes during animation, we ignore. Good.

Win: show overlay, allow keep going. When win overlay shown, game not over; keepGoing button hides overlay and sets keepGoing=true so it doesn't show again. During win overlay, moves still possible? Overlay blocks. That's fine.

Game over: overlay with Try Again.

Let me also handle the case where board is full but merges possible -> not game over. movesAvailable checks any adjacent equal or empty.

Now the grid background: 16 cells.

CSS tile colors for 2,4,8,...,2048,4096,8192. Use classes.

Let me write the full file.

For animation of new tile: scale from 0 to 1. `.tile-new { animation: appear 150ms ease; }` with keyframes from transform... but transform is used for position! Conflict. Use scale on inner element or use a wrapper. Better: tile element positioned with transform translate, and inner `.tile-inner` for scale/pop. Let me restructure: tile el has transform translate; inside a `.tile-inner` div with the value and background. Then animate inner scale.

Actually simpler: set `left`/`top` for positioning and `transform: scale()` for animation? Transitions on left/top are less performant but fine for 16 tiles. But transform transitions are smoother. Let me use wrapper approach.

Tile structure:
```html
<div class="tile" style="transform: translate(...)">
  <div class="tile-inner tile-2">2</div>
</div>
```
Tile el: position absolute, width/height CELL, transition transform 120ms ease. Inner: width/height 100%, display flex, border-radius, background per value, transition transform for pop.

For new tile, inner starts scale(0) then scale(1). For merged, inner does pop (scale 1 -> 1.15 -> 1).

But we set the value/class on inner after merge. Good.

Hmm but the class for colors — I'll put on inner. Let me use `data-value` attribute and CSS attribute selectors, or classes. Classes simpler: `v2`, `v4`, etc.

Let me write.

For new tile appear animation, I need to trigger after adding to DOM. Use requestAnimationFrame or a class that has animation defined. CSS animation on `.tile-inner.appear` with keyframes scale 0 to 1. Since we add class at creation, animation runs. Good.

For merge pop: after transition, add `.pop` class to inner, then remove after animation. But changing value class also. Use animation.

Actually careful: `.appear` animation and `.pop` both animate transform on inner. Fine.

Let me define:
```css
@keyframes appear { from { transform: scale(0); opacity:0 } to { transform: scale(1); opacity:1 } }
@keyframes pop { 0%{transform:scale(1)} 50%{transform:scale(1.18)} 100%{transform:scale(1)} }
.tile-inner.appear { animation: appear 150ms ease; }
.tile-inner.pop { animation: pop 160ms ease; }
```

Now, when a merged tile gets value updated and we add pop, also need to ensure the inner class for color updates. Fine.

Let me now also handle that consumed tiles might have z-index. Set keeper higher.

Let me write the code fully.

One more: board should be responsive? Fixed 460px is fine but on small screens might overflow. I'll add a scale via CSS max-width with transform scale? Keep simple, maybe use a container width and clamp. Let me just make it fixed and allow page to be fine. Actually viewport 1200x800, fine.

Let me use CSS variables to compute positions in JS reading from a constant.

Let me write.

Game over detection:
```js
function movesAvailable() {
  for (let r=0;r<SIZE;r++) for (let c=0;c<SIZE;c++){
    const t = grid[r][c];
    if (!t) return true;
    if (c+1<SIZE && grid[r][c+1] && grid[r][c+1].value===t.value) return true;
    if (r+1<SIZE && grid[r+1][c] && grid[r+1][c].value===t.value) return true;
  }
  return false;
}
```

Win check: any tile value>=2048 and !won.

Let me write the file now.

Position function: `translate(${PAD + c*STEP}px, ${PAD + r*STEP}px)`.

I'll define CSS custom props for cell/gap/pad and compute in JS as constants. Keep consistent.

Let me write index.html.

Let me run the browser to check.

Initial state: two tiles (2 and 2), score 0. Good.

Now let me test moves. I need to test deterministic behavior. The randomness makes it tricky. Let me instead run a JS test via the browser? I don't have an eval tool directly, but I can use the `type`/`key` actions. Let me test a merge: initial two 2s are at row 2, col 0 and col 1 (from screenshot: they appear in third row). Moving left merges them into a 4, score 4.

Let me press ArrowLeft.

Hmm, screenshot taken during animation (the two 2s overlapping). The score updated to 4. The DOM still shows "2\n2" because the merge finalization happens after 120ms. The screenshot was taken at +0ms so mid-animation. Wait but score updated immediately. The DOM shows the tile layer with 2 and 2 still. Actually after the timeout, it should become 4 and spawn a new tile.

Let me take another screenshot to see the settled state.

Merge worked: [2,2] left -> [4], score +4, and a new tile (2) spawned. 

Now let me test rapid input safety and New Game. Let me test multiple rapid keys. Also test that an unchanged move doesn't spawn.

Let me test New Game first. Click New Game button. Coordinates: around x=774, y=185.

Actually, let me test more behavior. Let me verify unchanged move: with tiles 4 at (2,0) and 2 at (3,1), pressing left: 4 stays at col0, 2 moves to col0. That changes. Hmm.

Let me just do New Game and confirm two tiles, score 0. Then test a sequence.

Let me click New Game.

New Game reset: score 0, two tiles. Good.

Now let me test rapid input safety. I'll press several arrow keys quickly. But the `key` tool may have delays. Let me try sending multiple in one call? Each call is one action. Let me do a few rapidly.

Actually, the more important concern is correctness. Let me think about a subtle bug: when a move changes board and we spawn a tile, but the spawn could land and then during animation another key press... we lock. Good.

One concern: if the player presses a key while animating, it's ignored. That's acceptable.

Another potential bug: In the merge finalization, I set inner className to `tile-inner v... pop`. But the `.appear` class might still be present on a tile that was just spawned and then merged in the next move? Since MOVE_MS=120 and appear animation is 140ms, a tile spawned could still have `appear` class when merged? No—after spawn, animating=false immediately after spawn. A new key press could come before appear animation ends, but the tile would be moved. The `appear` class remains but gets overwritten on merge. Fine.

Another issue: score updates before animation completes, but that's cosmetic.

Let me test a quick sequence of moves to verify no corruption. Press ArrowUp, ArrowDown, ArrowLeft, ArrowRight quickly.

Actually let me verify no console errors. Console only has the sandbox warning. Good.

Let me test rapid input with motion frames perhaps. Let me send a few keys.

Interesting. The sequence shows intermediate states. Let me trace: initial two 2s (some positions). ArrowUp: score 0, still 2 tiles. Hmm the first result shows score 0 and two 2s. Then ArrowRight gave score 4 and tiles 2,2,2. Then ArrowDown gave 4,2,2. Then ArrowLeft gave 4,2,2,4.

Wait, but the four key calls were made in parallel. The results show progressive states. The screenshots attached seem to correspond to each result but ordering is confusing. Let me not over-analyze; no corruption evident, board always valid (4 tiles after moves). Score consistent.

Actually wait, one thing: after ArrowRight, score 4 with three tiles (2,2,2). That means a merge occurred (two 2s -> 4) and a spawn. The DOM showed "2 2 2" — but score 4 means a 4 exists. The screenshot shows two 2s and a 2, not a 4. Hmm. Let me look: second image shows row0: 2, 2; row2: 2. That's three 2s, no 4, but score 4. That's mid-animation where merge finalization hasn't happened yet? But the image shows the two 2s side by side, not overlapping. Odd.

Actually, the sequence of parallel calls: the results are captured at different times. The DOM text and images may be at slightly different moments. The key point: no console errors and board remains sane.

Hmm, but there's a concern: could rapid input cause a spawn to be lost? Let me examine. During animation, `move` returns early. The spawn happens in the setTimeout. So no issue.

But wait—there's a real subtle bug. When `move` is called and it computes `changed=false`, it returns without setting animating. Good.

Let me consider the merge + spawn and the state after ArrowLeft in the last image: tiles 2 (row3 col0), 4 (row3 col2), 2 (row3 col3), 4 (row2 col3). Score 4. That's 4 tiles. Valid.

But hold on: initial two tiles, then 4 moves should add up to at most 6 tiles if each changed and no merges; merges reduce. Score 4 means one merge of 2s. Tile count 4 seems plausible.

Actually the intermediate images might be showing animation frames. Fine.

Now I want to verify the "no spawn after unchanged move" behavior. Hard to test reliably via random. But logic clearly returns before spawn when !changed. Good.

Let me verify the win and game over logic. Hard to reach 2048 quickly. But I can test game over by filling board? Not easily. The logic is standard.

Let me double check a subtle correctness issue with the merge-once rule: [2,2,2,2] left. cells = [2,2,2,2]. result: first 2 -> result=[2]. second 2: last.value===2 and !merged -> merge, last.merged=true, newValue=4. third 2: last.value is still 2 (we didn't change last.value) and last.merged is true -> so push new entry {value:2}. fourth 2: last (the new entry) value 2, !merged -> merge -> 4. Result: two 4s. Correct! Good, because we keep last.value unchanged and use `newValue` separately.

[2,2,4,0] left -> cells [2,2,4]. result: [2]; second merges to 4 (newValue). third value 4: last.value===2 (unchanged) !==4, push {value:4}. Result: [4(merged), 4] -> positions col0 and col1. Correct [4,4,0,0].

Great.

One thing: after merge, the keeper's `value` property stays old until finalization. During the animation, if another move were somehow triggered it's blocked. Good.

Now, a potential bug: `last.value` for a merged entry remains the pre-merge value, which is correct for preventing double merges with following equal tiles. But what if after merge there's a tile equal to the merged value? e.g. [2,2,4]: first two merge to 4, then third 4. last.value=2 !== 4 so pushed separately. Result two 4s. Correct (shouldn't merge again).

Now let me verify the score display with count-up? No.

Let me also check preventDefault works (page doesn't scroll). Board fits in viewport so scrolling isn't an issue anyway.

I think the implementation is solid. Let me do one more check: the `appear` class combined with `pop` when a newly spawned tile merges. Fine.

Let me verify there's no issue with tile z-index after merge: keeper zIndex reset to "". Good.

I'm fairly confident. Let me also confirm the win overlay via a quick simulated test by temporarily... no, can't easily. I'll trust the logic.

Actually, let me test the game-over/win logic more rigorously by injecting via the browser? I could use a devtools-like eval, but the browser tool doesn't have eval. I could temporarily add a test hook. But time budget. The logic is straightforward.

Let me do a final check of the current state and confirm no errors, then report.

Actually, I realize there might be an issue with the win overlay: when won, we show overlay but `gameOver` remains false and moves still possible after "Keep Going". Good. But while the win overlay is displayed, pressing arrow keys still triggers `move` (keydown not blocked by overlay), which would mutate the board behind the overlay. That could be weird but not corrupt. Also the overlay doesn't stop key events. Minor. Since overlay is displayed, user likely clicks. Acceptable, but could be considered a bug: after winning, arrow keys keep playing while overlay shown. Not harmful. I'll leave it, or better, block moves while overlay shown. Let me add a check: if overlay is showing (win not dismissed), ignore moves. Actually the game-over case already blocked by gameOver. For win, let me block while overlay shown and !keepGoing.

Let me add `if (overlay.classList.contains("show")) return;` at start of move. That prevents moves under the win overlay. Good improvement.

Let me make that edit.

Now let me test the win and game-over overlays by adding a temporary debug hook? I have limited time. Let me instead create a quick separate test by temporarily modifying the file to start near-win, screenshot, then revert. That might be worth it to verify overlays.

Actually, I can verify the overlay rendering without triggering the game logic by temporarily setting a tile value to 2048 via a script injected... but no eval. 

Alternative: I could write a temporary copy of index.html with a modified newGame that spawns a 1024 and 1024, then move to merge into 2048 to trigger win. Let me do that quickly in a temp file, test, then delete. But the browser tool runs index.html specifically? It probably serves the current directory. Let me check—it said "Run index.html". Likely fixed to index.html. I'd have to modify index.html itself and revert. 

Given time, let me do a quick test: temporarily change the spawn to always 1024 and place two, then test. Actually simpler: temporarily hardcode newGame to create 1024 at (0,0) and 1024 at (0,1). Then ArrowLeft triggers 2048 win. Then revert.

Let me make a backup and edit.

I need to set window.__TEST_WIN__ before newGame() runs. newGame() is called at the end. I need to inject the flag before. Let me add it right before `newGame();` at the bottom.

Also gridBg innerHTML got reset? No, only tileLayer. Good. But gridBg stays.

Let me edit the bottom.

Score updated to 2048 (merge of 1024+1024). Wait, score should be 2048, correct. Mid-animation. Let me wait and screenshot to see the win overlay.

Win overlay works. "Keep Going" button. The 2048 tile is shown faded behind overlay, and a 2 spawned. Good.

Now restore the original file from backup, which removes test hooks and includes the overlay move-block edit? Wait, the backup was made AFTER the overlay block edit. Let me check: I made the overlay edit, then copied to .bak. Yes, the backup includes the overlay-block edit and no test hooks. Good.

Let me restore.

Restored clean (0 test hooks, 1 overlay block). Let me do a final reload and quick sanity check.

Final clean state: score 0, two tiles. Everything works.

Let me write the final report.