1024 小游戏开发

项目概述

本项目是一个基于纯 HTML/CSS/JavaScript 的 1024 数字合并小游戏，灵感来源于经典的 2048 游戏，但将目标数字调整为 1024，降低了通关难度，更适合休闲体验。整个项目仅用一个 index.html 文件完成，零外部依赖，打开即玩。

技术实现要点

1. 数据结构：二维数组驱动一切

游戏核心是一个 4×4 的二维数组 grid[4][4]，每个元素存储当前格子的数值（0 表示空格）。所有游戏逻辑——滑动、合并、判胜、判负——都建立在这个数组之上。

let grid = Array.from({length: 4}, () => Array(4).fill(0));

心得：保持数据模型简单，是游戏开发的第一原则。很多新手会想用 DOM 节点直接存储状态，但这样会让逻辑和渲染耦合，后续加动画、判状态都会变得困难。数据与视图分离，数组是数据，DOM 是视图，render() 函数负责桥接。

2. 滑动合并：一行逻辑，四个方向复用

最关键的算法是「单行滑动合并」。以向左滑动为例：

1. 过滤掉空格（0），得到紧凑数组
2. 从左到右扫描，相邻相同则合并（左边的值翻倍，右边的删除）
3. 末尾补 0 对齐到 4 位

function slide(row) {
  let arr = row.filter(v => v !== 0);
  for (let i = 0; i < arr.length - 1; i++) {
    if (arr[i] === arr[i + 1]) {
      arr[i] *= 2;
      score += arr[i];
      arr.splice(i + 1, 1);
    }
  }
  while (arr.length < 4) arr.push(0);
  return arr;
}

心得：不要为上下左右四个方向各写一套逻辑。只写「向左滑」一行，其他方向通过翻转/转置数组来复用。代码量从 4 份降到 1 份，bug 也只会在一个地方出现。

3. 动画：CSS transition + class 切换

动画没有用 JS 动画库，而是利用 CSS 的 transition 和 @keyframes：

• 新方块出现：添加 .new class，触发 pop-in 缩放动画
• 合并弹跳：添加 .merged class，触发 merge-pop 弹性动画

@keyframes pop-in {
  0% { transform: scale(0); opacity: 0; }
  100% { transform: scale(1); opacity: 1; }
}

心得：JS 负责状态计算和 class 切换，CSS 负责视觉过渡。这种分工让动画调试变得直观——改 CSS 就能调效果，不用动逻辑代码。能用 CSS 解决的动画，不要用 JS。

4. 触摸支持：起点-终点向量判定

移动端操作通过 touchstart / touchend 事件对实现：

1. 记录触摸起点坐标
2. 触摸结束时计算 Δx、Δy
3. 取绝对值较大的轴作为滑动方向
4. 设定 20px 最小阈值，防止误触

心得：触摸操作的核心就三个字——判方向。不需要复杂的手势库，一个向量比较就够了。但阈值很重要：太小会误触，太大会不灵敏，20px 是实测下来比较舒适的值。

5. 视觉设计：毛玻璃 + 渐变背景

界面没有用任何 UI 框架，纯手写 CSS：

• 背景：linear-gradient(135deg, #667eea, #764ba2) 紫蓝渐变
• 卡片：backdrop-filter: blur(10px) 毛玻璃效果
• 数字配色：每个数值对应独立颜色，从暖棕（2/4）到橙红（8/16/32/64）到金黄（128/256/512/1024）

心得：backdrop-filter: blur() 是做现代 UI 的利器，一行 CSS 就能让半透明背景产生高级感。但要注意兼容性——Safari 需要加 -webkit- 前缀，部分旧浏览器不支持。

踩过的坑

坑 1：合并顺序问题

最初实现 slide() 时，从左到右逐对合并，遇到 2-2-4-4 会先合并左边的 2+2=4，然后新产生的 4 又和右边的 4 合并成 8——一次滑动合并了三次，这不符合 2048 系列的规则。

修复：合并后 splice 掉被吃掉的元素，并跳过 i++（因为 splice 已经缩短了数组，下一轮自然对齐）。这样 2-2-4-4 向左滑只会产生 4-8-0-0，每次合并只发生一次。

坑 2：CodeArts ACP 会话超时

最初尝试通过 CodeArts ACP 服务自动生成代码，但会话在 8 分钟内无任何输出（日志停留在 skill 加载阶段），最终判定为超时断开。

教训：ACP 是异步长连接，4 分钟做健康探针、8 分钟做重连是合理的超时策略。但对于简单任务（单文件 HTML），直接手写比等 ACP 响应更高效。工具是手段，不是目的。

坑 3：render() 中的 DOM 操作顺序

最初在 render() 里直接修改已有 DOM 节点的 textContent 和 style，但新增方块时需要创建节点，删除方块时又需要清空，逻辑分支多且容易遗漏。

修复：改为每次 render 先删除所有 .cell 节点，再统一重新创建。虽然看起来"暴力"，但 16 个格子的 DOM 操作量极小，性能完全不是问题。简单粗暴但正确，优于精巧但有 bug。

架构反思

为什么用单文件？

• 零配置部署：一个文件丢到任何静态服务器就能跑，不需要构建工具、不需要 npm install
• 分享友好：直接发文件就能玩，不依赖网络
• 适合小项目：代码量 < 400 行时，拆文件反而增加维护成本

如果要扩展呢？

如果未来要加排行榜、联机对战等功能，单文件就会变得臃肿。这时候应该：

1. 拆分 game.js（逻辑）、render.js（视图）、style.css（样式）
2. 引入轻量构建工具（Vite）做打包
3. 用 WebSocket 实现联机

心得：架构不是一开始就设计出来的，是随需求演进出来的。YAGNI 原则（You Aren’t Gonna Need It）——不要为"可能的需求"提前复杂化。

关键收获