2048 · mimo-v2.5

Let me build the game. Single file index.html with inline CSS/JS. Let me write it carefully.

Key features:
- 4x4 board, HTML/CSS tiles
- Arrow keys move, merges, score
- Spawn tile after changed move
- Animations without corrupting state (lock during animation, or just apply instantly with CSS transitions on absolutely positioned tiles)
- Prevent arrow key scroll
- Win at 2048, continue allowed
- Game over when no valid moves
- New Game button

Implementation approach: absolute positioned tiles with CSS transform transitions. Tiles have unique ids. On move, compute new positions, animate transforms, remove merged tiles after transition, spawn new tile with pop animation.

Let me write the code.

Grid4x4, cell size ~100px with gap. Container size 4x4 cells + gaps.

Let me write it.

Data model: board = 2D array of tile objects or null. Each tile: {id, value, row, col, el}.

Move algorithm: for each line in direction order, compact and merge. Track changed.

Animation: after computing move, set transform for each moved tile; merged tiles: both move to same cell, then one removed and value updated with pop.

Simpler: use requestAnimationFrame/transitionend with a lock flag (~100-150ms). During lock, ignore input.

Let me write full code.

Layout: board container with padding, background cells behind.

I'll use CSS variables for size.

Tile colors: standard 2048 palette.

Let me write it now.

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

Score: current score + best score in localStorage maybe (optional, fine).

Let me code.

For animation of merges: after computing destination, for merging pairs, the two source tiles move onto target cell; then on transition end, remove both source elements and update the target tile element value with a "pop" class.

Implementation details:

function move(dir):
 if locked or over or (won && !continuing) -> return... actually win overlay blocks input until continue clicked.
  
  build traversal order.
  For each row (depending on dir), process cells.
  
Let me implement with tile objects:

board = grid[r][c] = tile or null, tile = {id, value, el}

move(dir):
  vectors: left: for each row r, traverse c from 0..3; etc.
  standard algorithm with merged flag per target cell.
 Record moves: for each tile that moves, record new r,c. If merged, mark tile as merging into the other; the target tile's value doubles after animation.
 Keep list of merged pairs: {tileA (removed), tileB (updated to new value)}.

  If nothing changed, return false.
 Locked = true.
  Apply transforms immediately (CSS transition handles animation).
  After ANIM_MS, commit: remove merged-away tiles from DOM and board, update merged tile values and DOM text/classes, spawn new tile with pop, check win/gameover, unlock.

Wait but board state during animation: need to be careful. Better: compute final board immediately (state correct), but DOM animation lags. Set locked during animation so input ignored. Actually to make movement smooth: apply transforms right away, then after transition, do DOM cleanup.

Let me code it:

function computeMove(dir) returns {moved, ops} where ops list of {tile, r, c, merged:bool}

Algorithm:
```
const vectors = {left:{r:0,c:-1}, right:{r:0,c:1}, up:{r:-1,c:0}, down:{r:1,c:0}};
function buildTraversals(){
  rows = [0,1,2,3]; cols=[0,1,2,3];
  if dir is right -> cols.reverse(); down -> rows.reverse();
}
moved=false;
mergedCells = new Set();
removed = [];
updates = [];
for r of rows for c of cols:
  tile = board[r][c]; if !tile continue;
  let {farR, farC} = findFarthest(r,c,vector);
  const nr = farR + vector.r, nc = farC + vector.c;
  if inBounds && board[nr][nc] && board[nr][nc].value === tile.value && !mergedCells.has(key(nr,nc)):
     // merge
     board[r][c] = null;
     const target = board[nr][nc];
     mergedCells.add(key(nr,nc));
     tile.row=nr; tile.col=nc;
     moved=true;
     updates.push({target, newValue: target.value*2});
     removed.push(tile);
  else if farR!==r || farC!==c:
     board[r][c]=null; board[farR][farC]=tile; tile.row=farR; tile.col=farC; moved=true;
```
findFarthest: keep going while in bounds and cell empty.

Then apply positions to all tile elements via transform. Merged-away tiles also animate to target cell (they get removed after animation). Set z-index: removed ones below.

Score: sum of updates newValue added.

After anim: remove removed elements from DOM, update target elements: set value, class, add pop.

Then spawn.

Win check: any tile value >= 2048 and not already won -> show win overlay.
Game over: no empty cells and no adjacent equal -> show game over.

Good. Let's write CSS.

Colors: 
- empty: #cdc1b4
- 2: #eee4da, 4: #ede0c8
- 8: #f2b179, 16: #f59563, 32: #f67c5f, 64: #f65e3b
- 128: #edcf72, 256: #edcc61, 512: #edc850, 1024: #edc53f, 2048: #edc22e
- super: #3c3a32

Text color white for >=8.

Let me write the file.

Board size: 4 cells * 100px + 5 gaps * 10px = 450. Use CSS var --size: 100px, --gap: 10px.

Tile positioning: left: gap + c*(size+gap); top similarly. Use transform translate for animation: position tiles at top-left with transform translate(x,y). Initial spawn also animated with pop.

Write HTML:

```
<div class="game">
  <div class="header">
    <h1>2048</h1>
    <div class="scores">
      <div class="score-box">Score <span id=score>0</span></div>
      <div class="score-box">Best <span id=best>0</span></div>
    </div>
  </div>
  <div class="controls">
    <button id=newGame>New Game</button>
 <p class="hint">Use arrow keys to move</p>
  </div>
  <div class="board-wrap">
    <div class="grid">16 background cells </div>
    <div id="tiles"></div>
    <div id="overlay" class="overlay hidden">...</div>
  </div>
</div>
```

Touch support: optional, but nice; add swipe handlers. Cheap to add.

Also WASD maybe. Fine.

Locking: also handle rapid input — lock during animation ~100ms. Set ANIM=110ms.

Also "keep playing" after win: set keepPlaying=true, hide overlay.

Game over only when no valid move remains — check after spawn.

Also add score delta popup maybe. Optional, small "+4" floating. Let's add simple score bump.

Let me write the file now.

localStorage may be unavailable in sandbox — wrap in try/catch.

Write code.

Then verify with browser tools: play arrow key sequence, check score, new game.

Let me write.

Let me test in the browser. First check initial state, then do keyboard moves.

Note: measureCSS uses a probe with width:var(--cell) — does that work? Setting style.cssText with var() should work in modern browsers. Let me check via browser.

Tiles exist (DOM shows two "2" tiles) but they're not visible in the screenshot. The tile transform uses translate with px values — probably CSS_SIZE measured fine, but tiles have no z-index relative to grid? Grid is absolute inset with cells drawn, tiles container is after it in DOM so should be on top. But tile appears at 0,0 translate? Screenshot shows empty board. Maybe the spawn animation `appear` with `backwards` fill... animation lasts 0.18s + 0.08s delay, screenshot is later. Hmm.

Wait — the tiles' transform is set inline, but the spawn animation `appear` animates transform: scale(...) which OVERRIDES the inline transform during animation, and after animation ends (fill default), it reverts to inline transform. That should be fine.

Actually maybe the issue: the tile `.tile` has `transition: transform 0.1s` and setting transform immediately at creation — fine.

Let me inspect DOM to see tile positions.

Tiles are rendering but positioned slightly off: the tile at (0,3) appears shifted up-left relative to the cell, and the tile at (3,1) also off. Actually the issue: tile's transform translate positions it relative to #tiles which is inset by gap — but posOf adds gap again? #tiles is `position:absolute; inset: var(--gap)`. Grid cells are at inset: var(--gap) too, with gap 10 between. Cell (0,0) is at (gap, gap) from board-wrap. #tiles origin is at (gap, gap), so tile at index 0 should be at translate(0,0), but posOf(0) = gap = 10. So tiles are offset by +10px in both directions. That's the observed offset (tiles appear shifted up-left by ~10px... actually shifted down-right by 10px, which makes them overlap the gap and be cut off at right edge).

Fix: posOf(index) = index * (size + gap), without the leading gap. Also the spawn animation scale is applied after? The transform includes translate plus class animation `appear` overrides transform with scale(0) — that would reset translate! `.tile.spawn { animation: appear }` animates transform scale, which overrides the inline transform... but animation fill forwards is not set, so after animation ends, inline transform applies. During animation, translate is lost — the tile pops at 0,0 then jumps. Hmm, in the screenshot it looks fine, so animation already finished. But during the 0.18s spawn, the tile would appear at the top-left corner scaling. That's a visible bug. Better: apply spawn animation on inner wrapper, or use scale via a different approach. Simplest: make .tile have an inner element? Or change appear animation to only animate opacity + use CSS `scale` property? Modern browsers support the `scale` property independent of `transform`. Use `@keyframes appear { from { scale: 0; opacity:0 } to { scale: 1 } }` and `pop { 0%{scale:1} 50%{scale:1.22} 100%{scale:1} }`. That composes with transform translate. Since sandbox browser is modern Chromium, that's fine.

Also zIndex for merged tiles: removed tiles get zIndex 1 but placeTile... fine.

Let me fix posOf and keyframes.

Note: `.grid` is `position:absolute; inset: var(--gap)` — the grid cells start at inset. `#tiles` is `inset: var(--gap)`. So both align. Good.

Now reload and test moves.

The screenshot was taken before spawn animation finished (delay 0.08s + backwards fill keeps scale 0). That's the issue — the spawn animation has `backwards` fill so tiles are invisible until 0.08s delay passes. Screenshot is captured at reload time. Let me wait and screenshot again.

Board now correctly aligned with two "2" tiles at (0,0) and (1,1). Now play moves. Let's press Left, then Down, etc., checking that tiles slide and a new tile spawns.

The second tile slid left (from col 1 to col 0), mid-animation. Wait for it to settle and the spawn. Then press another direction.

Move left: tiles slid, spawned a new 2 at row 2, col 2. Now board:2 at (0,0), 2 at (1,0), 2 at (2,2). Press Left again → merges (0,0)+(1,0) → 4, score +4.

Mid-animation again (the row-2 tile is sliding left). Wait, then check.

Interesting — the two 2s in column 0 did NOT merge. Instead a 4 spawned. Wait — the board shows 2,2,2 in col 0 and a 4 at (2,1). Score is still 0? Let's check the DOM: "SCORE 0 BEST 0" and tiles "2 2 2 4".

Hmm, why didn't (0,0) and (1,0) merge? My traversal processes rows [0,1,2,3] for left. For row 0: tile at (0,0) can't move. Row 1: tile at (1,0), can't move (ahead is (1,-1) out of bounds). So no merge — correct, they were already at the left edge with tiles at (0,0) and (1,0) adjacent... wait merging for left move requires them in the same ROW, not column! (0,0) and (1,0) are in different rows. Left move: they can't merge. Correct behavior.

The 4 at (2,1) is odd — the row-2 tile was at (2,2) after first left move? Actually first move: original tiles at (0,0) and (1,1). Left move: (1,1) → (1,0). Spawned at (2,2). Second left move: (2,2)→(2,0). Then spawn... but the screenshot shows a "4" at (2,1) and "2" at (2,0). Spawn should be a 2 with 90%, 4 with 10% — so a 4 spawn at (2,1) is possible! And score 0 is right since no merge occurred. Good — actually that's consistent.

Wait, but in the first screenshot after the merge attempt the row-2 tile slid from (2,2) to (2,0) — but screenshot showed it at (2,2)→ moving. Then it landed at (2,0), and the 4 spawned at (2,1). Correct.

But hold on — did I want the row1 tile to merge with row 0? Not in a left move. Right. My move logic is per-row for left/right. Correct.

Let me now do an Up move to get merges, or better test a deterministic merge. Press Up: col0 has 2,2,2 → up: rows processed [0,1,2,3]. Row0 (0,0) stays. Row1 (1,0): ahead is (0,0)=2, merge →4 at (0,0), gained 4. Row2 (2,0): ahead is (1,0) now empty... wait after merge, (1,0) is set to null. So (2,0) slides up to (1,0). Score +4.

Let's test that, then check score = 4.

Mid-animation (tiles moving up). Wait, then verify the merge result and score.

Merge worked: two 2s merged into 4, score = 4 (exactly the merged value), one new tile spawned (the 2 at row 2, col 3 — wait, there were three2s in col 0: after Up, top two merged to 4, third2 slid up to row 1. And the 4 that was at (2,1) slid up to (1,1). Then a new 2 spawned at (2,3)). Board: 4 at (0,0), 4 at (0,1)?? Wait — the 4 that was at (2,1) should slide up to (1,1), not (0,1). Let me look: screenshot shows 4 at (0,0), 4 at (0,1), 2 at (1,0), 2 at (2,3).

Hmm. Column 1 had only the 4 at row 2. On Up it slides to row 0 (empty cells above). Correct — column 1 was empty in rows 0,1. So 4 goes to (0,1). Correct!

Column 0: 2(0), 2(1), 2(2) → merge2+2→4 at row 0, third 2 at row 1. Correct.

Score = 4. Exactly the merged value. 

Now test: unchanged move shouldn't spawn. Press Up — nothing at row 0 can move except... 4 at (0,0) stays, 4 at (0,1) stays, 2 at (1,0) would slide to (0,0)? No — (0,0) occupied by 4, equal? No, 4≠2, so blocked. 2 at (2,3) slides up to (0,3). That changes the board, so it would spawn. Not a good unchanged test. Press Up then Up again — the second Up would be unchanged. Let's do: press Up (spawn happens), press Up again quickly and verify no spawn and no crash.

Also test rapid input locking — mash keys quickly.

Let me press Up twice rapidly.

Board is mid-slide (2 at col3 moving up from row 2 to row 0). After it settles, board: 4,4,_,_ / 2,_,_,_ /2,_,_,_ / _ ... wait the 2 at (2,3) slides to (0,3). Then spawn happens. Let me wait, screenshot, then press Up again to test unchanged move.

Board: row0: 4,4,_,2 ; row1: 2 ; row2: 2. Now press Up again — nothing can move (4,4 at top row can't merge with anything above; 2 at (0,3) blocked; 2s at (1,0),(2,0) blocked by 4 at (0,0)). So unchanged move — should not spawn a tile and should not change the count (5 tiles remain).

Board unchanged — still 5 tiles, no spawn. Correct.

Now test rapid input (mash keys) to ensure no corruption, then test merge-once-per-tile ([2,2,2,2] left → [4,4,0,0]). I can't easily set up a specific board from outside since the game state is in an IIFE closure. But I can test by pressing keys rapidly and checking the board stays consistent (tile count matches DOM).

Rapid input test: send several keys in quick succession without waiting.

Then New Game test.

Let me mash: press Down, Right, Down, Right quickly.

Down move: 2s in col 0 merged: (1,0) and (2,0) both 2 → merge into 4 at bottom, and top4 slid down. Score 8 (+4 for the merge). Correct: 4+4... wait, col0 was4,2,2 from top. Down: bottom two 2s merge into 4 at row3, and the 4 slides to row2. Score went 4→8 (+4). Correct.

Tiles count: 5 (4,4,2 in top area + 4 + 2 at bottom). DOM shows "4 4 4 2 2" — 5 tiles. Correct.

Now mash keys rapidly. The browser tool sends one key per call; I can call multiple key actions in one block quickly. Let me send several key presses in a single parallel block — but parallel calls may execute nearly simultaneously, which is exactly the rapid-input test.

The rapid keys produced sequential valid moves (they were serialized by the tool calls). Score 16, tiles 8,4,2,2,2,2 — no corruption, tile count consistent. The4+4 merged into 8 giving +8 (8→16). Correct: 4+4=8 merge adds 8 to score.

Wait — earlier score was 8, then it's 16 now, meaning +8 from a 4+4 merge. Correct behavior.

Now the last screenshot shows a 2 tile spawning at top row mid-animation. Board is consistent: 6 tiles in DOM = 6 shown.

Now test New Game.

New Game worked: score reset to 0, two tiles (4 and 2 — valid starting tiles), best kept at 20 (interesting, score got to 20 at some point — one of the moves merged). Board shows two tiles. The screenshot was taken during the spawn animation (tiles at scale 0), but DOM confirms exactly two tiles and score 0. Let me take one more screenshot to confirm visual reset, then verify the win/continue flow and game over. Those are harder to trigger via play; I can at least sanity-check the code path. Optionally I can test win by temporarily... no, don't modify. The win path: reached2048 computed from merges; overlay shows; continue hides overlay. Game over checked via movesAvailable().

One potential bug: after win, `keepPlaying = true` is set when showing win overlay, and the check `if (reached2048 && !keepPlaying)`. Fine.

Another: after continueBtn clicked, overlay hidden — subsequent moves work since move() checks overlay hidden. Good.

Potential issue: in move(), the check `!overlay.classList.contains("hidden")` blocks input while win overlay is shown — good.

Also the score-add popup: appended to scoreBox which has position relative? .score-box has position: relative — yes.

Let me do a final screenshot after the spawn animation and verify tiles align properly.

Everything checks out. Board reset shows two tiles (4 and 2 — 4 spawn is the 10% case), score 0, best preserved at 20.

One remaining consideration: the `4` spawn at start — valid (10% chance). Also verify page doesn't scroll on arrow keys — keydown preventDefault handles it; the page isn't scrollable vertically much anyway.

The file is saved. I'm done. Let me write the final report.