矩阵俄罗斯方块实战：从矩阵变换到游戏循环的完整实现

1. 项目缘起与整体设计思路

第一次看到 MatTris Arcade 这个标题，我脑子里蹦出来的第一反应是：这大概率是把矩阵运算和俄罗斯方块揉在一起的一个小项目。后来跟几个做前端和图形学的朋友聊，发现大家的直觉都差不多——Mat 指向 Matrix，Tris 指向 Tetris，Arcade 则暗示它不是一个孤零零的 Demo，而是一个带点“街机厅”味道的小合集。这个命名方式其实很聪明，它没有用那种“XX管理系统”或者“XX平台”的套路词，而是直接把技术内核和娱乐属性摆在台面上，让人一眼就能猜到它的气质。

从项目定位来看，MatTris Arcade 解决的是一个很实际的问题：很多做图形学、做游戏逻辑、做前端可视化的开发者，在学完基础 API 之后，手里缺一个既能练手、又能直接看到效果、还能不断往上叠功能的小型项目。市面上的教程要么太碎，要么太庞大，一个完整的游戏引擎动辄几万行代码，新手根本啃不动。MatTris Arcade 这种体量的东西刚好卡在中间——它足够小，小到一个人几天就能跑通核心逻辑；又足够大，大到可以塞进矩阵变换、碰撞检测、状态机、渲染循环、音效管理这些真正有用的知识点。

我个人的判断是，这个项目最适合三类人：第一类是刚学完一门语言、想找个东西练手但不想做增删改查的初学者；第二类是做前端或者图形方向、想补一补底层数学和渲染逻辑的开发者；第三类是想给自己攒一个“能拿得出手的小作品”的学生或者转行者。它不挑语言，JavaScript、Python、C++ 甚至 Rust 都能做，核心思路是通的。

在方案选型上，我倾向于把它拆成三个层次来设计。最底层是矩阵与变换层，负责处理方块的旋转、平移、缩放，以及坐标系的映射。中间层是游戏逻辑层，管方块生成、下落、消行、计分、难度递增。最上层是渲染与交互层，负责把数据画到屏幕上，并接收键盘或触摸输入。这样分层的好处是，每一层都可以单独测试，换渲染方案的时候不用动逻辑，换逻辑的时候不用重写渲染。很多新手一上来就把所有代码塞进一个update()函数里，写到后面自己都看不懂，这是我最想提醒避开的一个坑。

还有一个设计上的取舍值得说：MatTris Arcade 里的“Arcade”到底要不要做成多游戏合集？我的建议是，第一版只做矩阵俄罗斯方块这一个核心玩法，但把架构留出扩展口。比如定义一个GameMode接口，每个模式实现init、update、render、handleInput四个方法。这样以后想加贪吃蛇、打砖块，直接新增一个模式文件就行，不用重构主循环。这个思路我在好几个小项目里用过，实测下来非常稳，前期多花半小时设计接口，后期省下的是几倍的返工时间。

2. 核心细节解析与实操要点

2.1 矩阵变换到底用在哪里

很多人听到“矩阵俄罗斯方块”会懵，觉得俄罗斯方块不就是格子移动吗，跟矩阵有什么关系。这里我解释一下：标准俄罗斯方块的七种方块，每一种都有四个旋转状态。如果你用坐标数组硬编码，每个方块要写四组坐标，七种就是二十八组，改起来容易漏。而用矩阵旋转的方式，你只需要定义方块在 3x3 或 4x4 矩阵里的初始形态，旋转的时候对整个矩阵做一次转置加翻转，就能得到新状态。

具体来说，顺时针旋转 90 度的操作可以拆成两步：先沿主对角线转置，再水平翻转。用代码表达就是：

function rotateMatrix(matrix) { const n = matrix.length; const result = Array.from({ length: n }, () => Array(n).fill(0)); for (let i = 0; i < n; i++) { for (let j = 0; j < n; j++) { result[j][n - 1 - i] = matrix[i][j]; } } return result; }

这段代码看起来简单，但它是整个项目里最值得反复琢磨的部分。因为一旦你理解了矩阵旋转，后面做碰撞检测的时候，只需要把旋转后的矩阵叠加到棋盘坐标上，逐格判断是否越界或重叠就行，逻辑非常统一。

注意：方块的旋转中心一定要提前定好。3x3 矩阵的中心是(1,1)，4x4 矩阵没有绝对中心，通常取(1,1)或(2,2)作为旋转轴。如果中心选错，方块旋转时会出现“漂移”，看起来就像在屏幕上乱跳。我踩过这个坑，调了整整一个下午才发现是中心点偏移了一格。

2.2 碰撞检测的三种写法与选择

碰撞检测是俄罗斯方块的命门。我见过三种常见写法，各有优劣。

第一种是逐格检测法：把方块矩阵的每一个非零格，映射到棋盘坐标，判断该坐标是否超出左右下边界，或者棋盘对应位置是否已经有方块。这种写法最直观，代码量适中，适合新手。缺点是每次移动都要遍历整个矩阵，性能上有一点点浪费，但对于 10x20 的棋盘来说完全可以忽略。

第二种是边界预判法：先计算方块矩阵的包围盒，只检测包围盒的四条边。这种写法性能更好，但实现起来复杂，容易在旋转后的不规则形状上出错。

第三种是位运算压缩法：把每一行压缩成一个整数，用位运算做碰撞判断。这种写法性能极致，但可读性差，调试困难，除非你有特殊需求，否则不建议在第一版使用。

我的建议是直接用第一种，先把功能跑通。等游戏能玩了，再考虑优化。过早优化是很多小项目烂尾的主要原因。

2.3 游戏循环与时间控制

游戏循环看起来简单，其实藏着不少细节。最朴素的写法是用setInterval每隔固定时间让方块下落一格，但这样做有个问题：当你想实现“软降”（按住下键加速下落）或者“硬降”（按空格直接落底）的时候，setInterval的节奏会跟输入打架。

更稳妥的方案是使用基于时间戳的累加器模式。核心思路是：每一帧记录当前时间，算出距离上一帧过了多少毫秒，累加到一个变量里。当累加值超过下落间隔时，就让方块下落一格，并减去一个间隔值。这样无论帧率怎么波动，方块的下落速度都是稳定的。

let dropCounter = 0; let dropInterval = 1000; // 毫秒 let lastTime = 0; function update(time = 0) { const deltaTime = time - lastTime; lastTime = time; dropCounter += deltaTime; if (dropCounter > dropInterval) { dropPiece(); dropCounter = 0; } render(); requestAnimationFrame(update); }

这段代码我用了很多次，实测下来非常稳。dropInterval可以随着等级提升逐渐减小，比如每消十行减少 50 毫秒，最低不低于 100 毫秒，这样难度曲线比较平滑。

2.4 消行逻辑与计分规则

消行的核心是：遍历棋盘的每一行，如果该行所有格子都不为 0，就把这一行删掉，并在顶部补一行全 0。听起来简单，但实现的时候有个顺序问题——如果你从下往上遍历，删掉一行后上面的行会下移，索引会乱。正确的做法是从下往上遍历，遇到满行就删除，然后把当前索引之后的行整体下移。

计分规则我建议参考经典俄罗斯方块的设定：消一行 100 分，消两行 300 分，消三行 500 分，消四行 800 分。同时每消十行升一级，下落速度加快。这个规则经过几十年验证，节奏感很好，不会让玩家觉得太简单或者太挫败。

实操心得：消行的时候加一个短暂的闪烁动画，哪怕只是把满行变成白色持续 100 毫秒，玩家的爽感会提升一大截。这是我在做小游戏时发现的一个“低成本高回报”的技巧。

3. 实操过程与核心环节实现

3.1 环境搭建与项目结构

这个项目对环境的依赖极低，一个浏览器加一个文本编辑器就能跑。如果你想用构建工具，Vite 或者 Parcel 都行，但我建议第一版直接用原生 HTML + JavaScript，减少工具链的干扰。项目结构可以这样组织：

mattris-arcade/ ├── index.html ├── styles.css ├── src/ │ ├── main.js // 入口，启动游戏循环 │ ├── board.js // 棋盘数据结构与消行逻辑 │ ├── piece.js // 方块定义与矩阵旋转 │ ├── renderer.js // Canvas 渲染 │ ├── input.js // 键盘输入处理 │ └── score.js // 计分与等级 └── assets/ └── (音效文件，可选)

这个结构的好处是每个文件职责单一，改哪块找哪块。我见过有人把所有代码写在一个 2000 行的main.js里，后期加个功能要翻半天，非常痛苦。

3.2 棋盘初始化与数据结构

棋盘我用二维数组表示，board[row][col]，其中row从 0 到 19，col从 0 到 9。0 表示空格，非 0 表示已固定的方块颜色索引。初始化的时候全部填 0。

const COLS = 10; const ROWS = 20; function createBoard() { return Array.from({ length: ROWS }, () => Array(COLS).fill(0)); }

这里有个细节：Array(ROWS).fill(Array(COLS).fill(0))这种写法是错的，因为所有行会共享同一个数组引用，改一行会影响所有行。必须用Array.from或者循环来创建独立的行。这个坑我踩过，当时方块下落的时候整列一起变，排查了半天。

3.3 方块定义与生成

七种经典方块我用矩阵来定义，每种给一个初始形态和一个颜色。比如 T 方块：

const SHAPES = { T: { matrix: [ [0, 1, 0], [1, 1, 1], [0, 0, 0] ], color: '#a855f7' }, // 其他六种类似 };

生成新方块的时候，从七种里随机选一种，放到棋盘顶部中间位置。这里要注意：如果生成的位置已经被占用了，说明游戏结束。判断方法就是拿新方块的矩阵去跟棋盘做一次碰撞检测，如果碰撞，就触发 Game Over。

3.4 渲染层的实现选择

渲染可以用 Canvas，也可以用 DOM 表格，甚至可以用 WebGL。我的建议是 Canvas，因为它的绘制性能好，而且做动画和特效方便。核心渲染逻辑就是：先清空画布，画棋盘网格，画已固定的方块，画当前下落的方块，最后画分数和等级。

function drawCell(ctx, x, y, color, size) { ctx.fillStyle = color; ctx.fillRect(x * size, y * size, size - 1, size - 1); ctx.strokeStyle = 'rgba(255,255,255,0.2)'; ctx.strokeRect(x * size, y * size, size - 1, size - 1); }

每个格子留 1 像素的间隙，视觉上会有网格感，比实心色块好看很多。这个技巧是我从一个做像素游戏的朋友那里学来的，成本几乎为零，效果提升明显。

3.5 输入处理与手感调优

键盘输入主要处理四个方向加一个硬降。左箭头左移，右箭头右移，上箭头旋转，下箭头软降，空格硬降。这里的关键是按键重复延迟。浏览器默认的按键重复有延迟，按住左键不会立刻连续移动，手感很粘。解决办法是自己维护一个按键状态表，在游戏循环里根据按住的时间来决定是否重复触发。

const keyState = {}; document.addEventListener('keydown', (e) => { if (!keyState[e.code]) { keyState[e.code] = { pressed: true, time: 0 }; handleKeyPress(e.code); } }); document.addEventListener('keyup', (e) => { keyState[e.code] = { pressed: false, time: 0 }; });

然后在update里累加按住时间，超过阈值就重复触发移动。这个改动虽然只有几十行代码，但手感提升是质的飞跃。

注意：旋转的时候如果方块贴着墙或者贴着其他方块，旋转后可能会碰撞。这时候需要做一次“踢墙”尝试——先试着往左或往右挪一格再旋转，如果还不行就放弃这次旋转。这个机制在经典俄罗斯方块里叫 Wall Kick，不加的话玩家会觉得很别扭。

4. 常见问题与排查技巧实录

4.1 方块旋转后位置偏移

这是最高频的问题。原因通常是旋转矩阵的中心点跟方块的视觉中心不一致。解决办法是：在旋转之后，计算方块矩阵的包围盒，然后根据包围盒的位置做一次补偿平移。或者更简单粗暴一点，把方块矩阵统一成 4x4，旋转中心固定在(1,1)，这样所有方块的旋转行为都一致。

4.2 消行后上方方块不下落

这个问题一般是遍历顺序错了。如果你从下往上遍历，删掉一行后，上面的行索引会变化，导致漏掉某些行。正确的做法是：从下往上遍历，遇到满行就删除，然后把删除行以上的所有行整体下移一行，并且把当前索引加一（因为下移后当前位置是新的一行，需要重新检查）。

4.3 游戏速度越来越快但停不下来

这是dropInterval没有设下限导致的。每升一级减少 50 毫秒，如果不设下限，到后面会变成 0 甚至负数，方块瞬间落底。建议设一个最低值，比如 100 毫秒，保证游戏始终可玩。

4.4 常见问题速查表

4.5 独家避坑技巧

第一个技巧：把游戏逻辑和渲染分离。我早期做小游戏的时候，喜欢在渲染函数里直接改数据，结果调试的时候根本分不清是逻辑错了还是渲染错了。后来强制自己遵守“渲染只读数据，逻辑只改数据”的原则，排查效率至少提升一倍。

第二个技巧：加一个调试模式。按某个键（比如 F2）可以显示当前方块的矩阵、棋盘数组、下落计时器数值。这个功能在开发阶段非常有用，上线前隐藏掉就行。我每次做新游戏都会先加这个，后面省下的调试时间远超写它的时间。

第三个技巧：音效不要用大文件。用 Web Audio API 合成简单的方波或者正弦波，几行代码就能做出“嘀嗒”的旋转声和“哔”的消行声。这样项目体积小，加载快，而且不用担心版权问题。

5. 扩展方向与个人经验

MatTris Arcade 这个名字里的“Arcade”其实留了很大的想象空间。核心玩法跑通之后，你可以往几个方向扩展。第一个方向是增加游戏模式，比如限时模式、垃圾行模式、对战模式。第二个方向是增加视觉主题，比如霓虹风格、像素风格、极简风格，通过切换配色方案和绘制方式实现。第三个方向是增加数据持久化，把最高分存到 localStorage，下次打开还能看到。

我自己在实际操作中的体会是，这类小项目最大的价值不在于最终成品有多完整，而在于你在做的过程中被迫解决的那些具体问题。比如矩阵旋转逼你理解线性变换，碰撞检测逼你理清坐标系统，游戏循环逼你搞懂时间管理。这些东西看教程的时候觉得懂了，真正动手写的时候才发现到处都是坑。而每填一个坑，你对整个图形编程的理解就扎实一分。

最后再分享一个小技巧：如果你想让方块下落看起来更顺滑，可以在渲染的时候给方块加一个垂直方向的插值偏移。具体做法是记录方块距离下一格还有多少毫秒，然后按比例把绘制位置往下偏移一点点。这样方块就不是一格一格地跳，而是连续地滑下去，视觉体验会好很多。这个改动只需要在渲染函数里加一行偏移计算，但效果非常明显。