从零实现Web消除游戏：核心逻辑与避坑指南-北京尧图网络

消除类游戏是很多人入门前端开发时最想动手做、又最容易半途而废的一类项目。看起来规则简单——点两下、凑三个、消掉——但真正写起来从棋盘数据结构、匹配检测、下落填充到连锁反应每一块都有坑。我自己第一次写三消的时候光消除后元素怎么下落这个问题就卡了大半天写出来的逻辑跑起来像抽风一样消完一层下面全是空洞。后来反复重构了几遍才把整套流程理顺。这篇内容就是把我从零做一个Web消除游戏的完整思路、关键代码结构和踩过的坑摊开来讲适合有一点HTML/CSS/JavaScript基础、想通过一个完整小项目把前端基本功串起来的朋友。不管你是刚学完DOM操作想找个练手项目还是做过几个静态页面想挑战带交互逻辑的小游戏下面这套方案都能直接参考复现。核心关键词就三个消除游戏、Web技术、从零实现全文围绕它们展开不跑偏。1. 整体设计与技术选型思路动手写代码之前先把这个游戏到底由哪些部分组成想清楚比上来就敲键盘重要得多。消除游戏看着简单本质是一个状态机加渲染循环的组合体棋盘是一个二维数组每次玩家操作改变数组状态然后根据新状态重新计算匹配、执行消除、触发下落、补充新元素最后把数组渲染成画面。想明白这条主线后面所有代码都是围绕它服务的。1.1 为什么用原生Web技术而不是游戏引擎市面上做2D小游戏的选择不少游戏引擎、Canvas绘图库、甚至一些低代码平台都能干这活。但我坚持用原生HTMLCSSJavaScript来做理由很实在。第一是学习收益最大化。消除游戏的核心难点不在渲染而在数据结构和算法逻辑——匹配检测、下落填充、连锁判定。这些用原生JS写一遍你对数组操作、循环嵌套、状态同步的理解会上一个台阶。用引擎的话很多底层逻辑被封装掉了你只是调API学不到东西。第二是调试成本低。原生方案里棋盘状态就是一个普通的二维数组你随时可以在控制台打印出来看哪一格是什么值一目了然。引擎里的对象结构往往层层嵌套排查问题时要在文档和源码之间来回翻。第三是部署零门槛。三个文件往服务器一放就能跑不需要构建工具、不需要打包配置分享给别人也方便。对于练手项目来说这种轻量性是巨大优势。具体技术分工上我用HTML搭骨架、CSS做布局和动画、JavaScript管全部逻辑。棋盘用CSS Grid来排每个格子是一个DOM元素通过切换class来表现不同颜色和选中状态。有人会问为什么不用Canvas答案是消除游戏的元素数量有限通常8×8共64格DOM完全扛得住而且DOM天然支持CSS过渡动画做消除缩放、下落位移这些效果比Canvas手写动画循环省事太多。这是典型的用对工具而不是用牛刀的取舍。1.2 棋盘数据结构的设计取舍棋盘用什么数据结构存直接决定了后面所有逻辑的写法。我见过几种常见方案这里对比一下。方案结构优点缺点一维数组arr[i*colsj]内存紧凑行列换算到处写易错二维数组board[row][col]行列直观逻辑清晰稍微多一层嵌套对象映射{ 0-0: type }查找灵活遍历麻烦性能差我选二维数组board[row][col]的形式。原因很简单消除游戏的所有操作都是按行按列进行的——检测横向三连要遍历行检测纵向三连要遍历列下落填充是同一列内元素往下挪。二维数组的行列语义和这些操作天然对齐写起来脑子不用做额外换算。一维数组虽然省内存但每次访问都要row * cols col代码里这种换算一多出bug的概率直线上升。数组里存什么我存的是整数类型ID比如0到5代表六种不同的元素。不直接存颜色字符串是因为整数比较快、方便做随机生成、也便于后续扩展比如加特殊道具时用特定ID标记。颜色和ID的映射关系单独放一个配置数组里渲染时查表即可。这种数据与表现分离的做法后面改配色、换图标都不用动核心逻辑。1.3 游戏主循环的拆解消除游戏没有传统意义上的每帧更新循环它的驱动是玩家操作。一次完整的回合流程是这样的玩家点击第一个格子记录选中状态玩家点击相邻格子交换两者数据检测交换后是否产生匹配有匹配则执行消除无匹配则换回来消除后执行下落填充下落填充后再次检测匹配连锁重复5、6直到没有新匹配回合结束等待下一次操作这个流程里第5到第7步是递归或循环结构也是新手最容易写错的地方。很多人只处理了一次消除就完事结果玩家看到消掉三个后上面悬空着不落体验直接崩掉。正确的做法是把检测匹配→消除→下落→再检测包成一个循环直到某一轮检测不到匹配为止。这个循环就是消除游戏爽感的来源——连锁消除越多分数越高玩家越上头。2. 核心模块拆解与关键实现细节把整体框架想清楚后接下来逐个模块攻破。这一章我按数据初始化→渲染→交互→匹配→消除下落的顺序讲每个模块都给出关键代码和背后的思考你可以照着顺序一步步搭起来。2.1 棋盘初始化与随机填充的讲究初始化要做两件事建一个空棋盘然后随机填满元素。听起来简单但有个隐藏的坑——初始棋盘不能一上来就有现成的三连。如果开局就自带匹配玩家还没操作游戏就自己消起来了逻辑会乱套。我的处理办法是填充时做一次检查每填一个格子看它左边两个和上边两个是不是同类型如果是就重新随机一个类型直到不构成三连为止。代码大概长这样const ROWS 8, COLS 8, TYPES 6; let board []; function initBoard() { board []; for (let r 0; r ROWS; r) { board[r] []; for (let c 0; c COLS; c) { let type; do { type Math.floor(Math.random() * TYPES); } while ( (c 2 board[r][c-1] type board[r][c-2] type) || (r 2 board[r-1][c] type board[r-2][c] type) ); board[r][c] type; } } }这段do...while是精髓。它保证了填充过程中不会产生横向或纵向的三连。注意判断条件里c 2和r 2的边界处理前两列和前两行不需要检查因为凑不齐三个。这种边填边校验的思路比填完再整体扫描重排要高效也避免了死循环风险。提示随机类型数量别设太少。如果只有3种类型棋盘上同色元素密度太高随便一换就是三连游戏会变得毫无挑战。我实测6到7种类型比较平衡既有足够的匹配机会又不至于太容易。2.2 用CSS Grid渲染棋盘并绑定坐标渲染层我选CSS Grid因为它天生就是干这个的。给容器设display: gridgrid-template-columns按列数均分每个格子自动排布不用手动算位置。#board { display: grid; grid-template-columns: repeat(8, 1fr); gap: 4px; width: 480px; } .cell { aspect-ratio: 1; border-radius: 8px; cursor: pointer; transition: transform 0.15s ease; }aspect-ratio: 1保证每个格子是正方形这个属性现在浏览器支持已经很好了比过去用padding-bottom百分比的老办法干净得多。transition给后续的选中缩放、消除动画留了接口。渲染函数负责把board数组同步到DOM。我的做法是初始化时一次性创建所有格子元素之后每次状态变化只更新每个格子的class对应颜色而不是重建整个DOM。重建DOM虽然代码简单但会丢失动画状态、性能也差属于典型的能跑但不好的写法。function render() { for (let r 0; r ROWS; r) { for (let c 0; c COLS; c) { const cell document.querySelector([data-r${r}][data-c${c}]); cell.className cell type-${board[r][c]}; } } }每个格子用>let selected null; function onCellClick(r, c) { if (!selected) { selected { r, c }; highlight(r, c); return; } if (selected.r r selected.c c) { selected null; clearHighlight(); return; } if (isAdjacent(selected, { r, c })) { trySwap(selected, { r, c }); selected null; clearHighlight(); } else { clearHighlight(); selected { r, c }; highlight(r, c); } } function isAdjacent(a, b) { return Math.abs(a.r - b.r) Math.abs(a.c - b.c) 1; }isAdjacent用曼哈顿距离判断横竖相邻距离为1斜对角距离为2会被排除。这个判断比写一堆if-else清爽得多。注意点击同一个格子要能取消选中这是符合直觉的细节很多新手会漏掉。交换逻辑本身很简单就是数组里两个值互换。但交换后必须验证是否产生匹配没匹配要换回来。这里有个体验细节换回来的时候最好加个短暂的动画或延迟让玩家看到哦这两个不能换而不是瞬间闪一下什么都没发生。我用setTimeout延迟150毫秒再换回配合CSS过渡视觉上就自然了。2.4 匹配检测横向纵向扫描的正确姿势匹配检测是整个游戏的心脏。目标很明确找出所有横向或纵向连续三个及以上同类型的格子。我的实现是分别扫描行和列用一个连续计数器的思路。function findMatches() { const matched new Set(); // 横向扫描 for (let r 0; r ROWS; r) { let run 1; for (let c 1; c COLS; c) { if (c COLS board[r][c] board[r][c-1] board[r][c] ! null) { run; } else { if (run 3) { for (let k c - run; k c; k) matched.add(${r},${k}); } run 1; } } } // 纵向扫描同理交换 r 和 c 的角色 return matched; }这里用Set存匹配坐标键是行,列字符串。为什么用Set而不是数组因为横向和纵向扫描可能命中同一个格子比如一个十字形的匹配用Set自动去重省得后面再手动判重。这是个很小但很关键的选择。扫描的边界处理是易错点。注意内层循环条件写成c COLS而不是c COLS多跑一次是为了在行末尾触发收尾结算——当连续段延伸到最后一列时需要一个额外的迭代来把这段匹配记录下来。如果不这么写行末尾的三连就会漏掉。我第一次写的时候就栽在这调试了半天才发现最后一列的匹配永远不生效。注意判断相等时一定要排除null。消除后的空格子我用null标记如果不加board[r][c] ! null这个条件两个空格子会被当成相同类型连成一片导致误判。2.5 消除、下落与补充的连锁处理检测出匹配集合后依次做三件事把匹配格子置为null消除、让上方元素下落填补空缺、在顶部补充新元素。这三步要循环执行直到某一轮检测不到匹配。下落逻辑是重点。对每一列从下往上扫描遇到null就把上面最近的非null元素挪下来。我用的是一种双指针压实的写法function applyGravity() { for (let c 0; c COLS; c) { let writeRow ROWS - 1; for (let r ROWS - 1; r 0; r--) { if (board[r][c] ! null) { board[writeRow][c] board[r][c]; if (writeRow ! r) board[r][c] null; writeRow--; } } // 剩余空位从顶部补新元素 for (let r writeRow; r 0; r--) { board[r][c] Math.floor(Math.random() * TYPES); } } }writeRow指针从底部开始遇到非空元素就写到writeRow位置然后上移。这样所有元素自然沉底顶部空出来的位置统一补新。这种压实算法比冒泡式一个个往下挪效率高而且不会出现元素错位。整个连锁流程用一个while包起来function resolveBoard() { let matches findMatches(); while (matches.size 0) { matches.forEach(key { const [r, c] key.split(,).map(Number); board[r][c] null; }); applyGravity(); render(); matches findMatches(); } }每轮消除后重新检测直到没有匹配。这就是连锁消除的实现。实际跑起来一次操作可能触发两三轮连锁分数蹭蹭涨玩家体验非常好。但要注意加个连锁上限保护防止极端情况下比如随机补充总是凑成三连陷入死循环。我一般设个最大连锁次数比如20次超过就强制结束本轮。3. 完整实操流程与关键参数落地前面拆的是模块这一章把它们串成一条完整的搭建路径从建文件到跑起来每一步都给出可落地的操作和参数。你照着走一遍一个能玩的消除游戏就成型了。3.1 项目文件结构与基础骨架搭建项目结构保持极简三个文件足够game/ ├── index.html ├── style.css └── game.jsindex.html负责骨架核心就是一个棋盘容器加一个分数显示区div idhud span分数/spanspan idscore0/span /div div idboard/divstyle.css里除了前面说的Grid布局还要定义各类型的颜色。我用type-0到type-5六个class对应六种颜色配色上刻意选了对比度高、饱和度适中的色系避免玩家看久了眼睛累。这里给个参考配色思路红、蓝、绿、黄、紫、橙每种颜色亮度接近保证在深色背景上都能看清。game.js按常量配置→初始化→渲染→交互→匹配→消除的顺序组织代码。我习惯把常量放最上面方便调参const ROWS 8; const COLS 8; const TYPES 6; const SWAP_DELAY 150; const MAX_CASCADE 20;这些参数不是随便定的。8×8是消除游戏的经典尺寸格子够多能玩出策略又不至于太密看不清。SWAP_DELAY控制换回动画的时长150毫秒是实测下来能看清但不拖沓的甜点值。MAX_CASCADE是连锁保护前面提过。3.2 事件绑定与坐标读取的实操事件绑定我推荐用事件委托把监听器挂在棋盘容器上而不是给64个格子各绑一个。这样DOM操作少、内存占用低而且后续如果棋盘尺寸变了也不用重新绑。document.getElementById(board).addEventListener(click, (e) { const cell e.target.closest(.cell); if (!cell) return; const r Number(cell.dataset.r); const c Number(cell.dataset.c); onCellClick(r, c); });closest(.cell)保证点到格子内部的任何元素都能正确找到格子本身dataset读取坐标。这套组合是DOM事件处理的标准范式值得记牢。初始化时创建格子元素把坐标写进datasetfunction buildDOM() { const boardEl document.getElementById(board); boardEl.innerHTML ; for (let r 0; r ROWS; r) { for (let c 0; c COLS; c) { const cell document.createElement(div); cell.className cell; cell.dataset.r r; cell.dataset.c c; boardEl.appendChild(cell); } } }先建DOM再render()填颜色顺序不能反。我见过有人先render再建DOM结果querySelector全返回null白屏半天找不到原因。3.3 分数计算与连锁加成的参数设计分数系统是驱动玩家继续玩的核心激励。我的设计是基础分按消除数量算连锁轮次给倍率加成。具体规则消除数量基础分连锁倍率第n轮3个30×n4个60×n5个及以上100×n也就是说第一轮消3个得30分第二轮连锁消3个得60分第三轮得90分以此类推。这个设计让连锁的价值远高于单次大消除鼓励玩家布局制造连锁。参数你可以自己调但核心原则是让连续比量大更值钱这样游戏才有策略深度。实现上在resolveBoard的循环里维护一个cascadeCount每轮加一算分时乘上去let cascadeCount 0; while (matches.size 0) { cascadeCount; const base matches.size 5 ? 100 : matches.size 4 ? 60 : 30; score base * cascadeCount; // ...消除下落逻辑 }注意matches.size是去重后的格子总数不是几组三连。这个口径要统一否则分数会算乱。3.4 动画过渡的落地技巧纯逻辑跑通后加动画是提升质感的关键一步。消除游戏最需要三种动画选中放大、消除缩小消失、下落位移。选中放大最简单给选中的格子加个classCSS里写transform: scale(1.1)配合transition即可。消除动画稍微麻烦点因为元素是瞬间置null的DOM上要有个先缩小再消失的过程。我的做法是消除时先给对应格子加vanishing类等动画结束用transitionend或setTimeout再真正更新数据和渲染。下落动画是难点。DOM元素位置是Grid自动排的你没法直接让它从上面滑下来。我的简化方案是下落时不做逐格位移动画而是给整个棋盘一个短暂的刷新闪烁效果或者用CSS的keyframes给新补充的顶部元素做一个淡入。这样虽然不如逐格滑动精致但实现成本低、不会引入复杂的坐标计算对练手项目来说性价比很高。如果追求更细腻的效果就得改用绝对定位手动计算每个元素位置那是另一个复杂度层级了建议先把基础版跑通再考虑。提示动画时长别超过300毫秒。消除游戏节奏快动画拖沓会让操作有延迟感玩家会觉得卡。我实测消除动画200毫秒、下落补充150毫秒左右整体手感最跟手。4. 常见问题排查与避坑经验实录代码能跑不代表没问题。这一章整理我在开发和调试过程中真实遇到过的典型故障附上排查思路和解决办法做成速查表方便你对照。4.1 匹配检测类问题速查匹配检测是最容易出bug的地方症状往往很隐蔽——游戏能玩但某些情况下该消的不消或者不该消的消了。症状可能原因排查与解决行末尾的三连不消除扫描循环边界写错漏了收尾结算内层循环条件用确保末尾触发结算空格子被误判为匹配相等判断没排除null加! null条件十字形匹配只消了一部分用数组存匹配导致重复覆盖改用Set去重纵向匹配完全失效行列变量写反检查纵向扫描里r和c的位置我印象最深的一次是行末尾三连不消。当时盯着代码看了半天逻辑怎么看都对最后把每一轮的run值打印出来才发现最后一列的连续段根本没进入结算分支。原因就是循环写成了c COLS最后一列之后没有额外迭代去触发else分支。改成c COLS立刻就好了。这种边界问题光看代码很难发现打印中间变量是最快的定位手段。4.2 下落填充类问题排查下落逻辑的bug通常表现为消完后棋盘出现空洞或者元素错位重叠。空洞问题的根源一般是下落算法没压实到底。检查你的writeRow指针是不是从ROWS - 1开始、每次写入后正确递减。如果指针初始值或递减时机错了就会留下没填的空位。元素错位则多半是边读边写导致的。在同一个数组上既读又写时如果读取位置和写入位置交叉可能读到已经被覆盖的值。我前面给的压实算法里writeRow始终在r的下方或相等位置读取的board[r][c]在被覆盖前已经用过了所以安全。但如果你自己改逻辑一定要留意这个读写顺序。还有一种情况是补充新元素时补充的数量算错了。正确做法是下落完成后从writeRow位置往上到第0行全部补新。如果只补了一部分顶部就会缺元素。这个用打印每列填充后的结果很容易验证。4.3 交互与状态同步的坑交互层的bug最影响体验因为玩家直接能感知到点了没反应或反应不对。最常见的是选中状态没清干净。比如交换失败换回后selected没置null导致下一次点击行为异常。我的原则是任何一次完整的操作结束无论成功失败都要把selected重置。代码里每个分支结束都显式清空别指望下次点击会覆盖。另一个坑是快速连点导致的竞态。玩家手快在动画还没结束时就点下一个格子可能触发两次交换逻辑棋盘状态就乱了。解决办法是加一个isAnimating或isBusy标志位处理回合期间忽略新的点击输入回合结束再放开。这个锁机制在带异步动画的交互里几乎是必备的。let isBusy false; function onCellClick(r, c) { if (isBusy) return; // ...正常逻辑 } function trySwap(a, b) { isBusy true; // ...交换、检测、消除 // 全部结束后 isBusy false; }这个标志位看着不起眼但能挡掉一大类莫名其妙的bug。我早期版本没加测试时手速一快就出问题加了之后世界清净了。4.4 性能与体验的优化心得8×8的棋盘性能压力很小但有些写法会无谓地拖慢体验值得注意。第一避免在循环里频繁操作DOM。render()应该在一轮逻辑全部算完后调用一次而不是每消除一个格子就调一次。DOM操作是相对昂贵的批量更新永远优于零散更新。第二用class切换而不是内联样式。改颜色时切class让浏览器走样式表比直接改style.backgroundColor性能好代码也更整洁。第三随机补充的分布要均匀。Math.random()本身够用但如果你发现某种颜色出现频率明显偏高检查是不是类型数量TYPES和颜色class数量对不上导致某些类型映射到了同一个颜色。这种看起来是随机问题其实是配置问题的情况我遇到过不止一次。注意调试阶段可以在控制台暴露board变量随时console.table(board)看棋盘状态。二维数组用console.table打印出来是表格形式比console.log直观十倍排查匹配和下落问题效率极高。这个习惯强烈建议养成。5. 功能扩展方向与二次开发建议基础版跑通后这个项目还有很大的扩展空间。这一章给几个我实际尝试过的扩展方向每个都说明改动点和注意事项你可以挑感兴趣的往下做。5.1 加入特殊消除道具的思路普通三消玩久了会腻加特殊道具能大幅提升策略性。常见的做法是四连消生成一个整行消除道具五连消生成一个同色全消道具。实现上在findMatches里除了记录匹配坐标还要判断连续长度达到阈值就在特定位置标记一个特殊类型ID。消除时如果命中特殊类型触发对应的范围清除逻辑。这里的关键是特殊道具的触发要纳入连锁计算。比如整行消除后新产生的匹配要继续参与连锁不能消完就停。改动点主要在resolveBoard的循环里把特殊道具的效果也当成一次消除来处理然后照常走下落和再检测。逻辑上不难但要小心别把特殊道具的标记和普通类型ID搞混建议用负数或大于TYPES的值来区分。5.2 计时模式与关卡目标的落地纯无限模式缺乏目标感加个计时或步数限制能显著提升紧张感。计时模式最简单开局启动一个setInterval倒计时时间到就弹结算。步数模式则是每次有效交换减一减到零结束。关卡目标可以设计成在N步内达到X分或消除特定数量的某色元素。后者需要在消除时统计各类型的消除数量改动点在消除循环里加个计数器。这类目标系统能让游戏有明确的进度感是把它从demo变成能玩一阵子的小游戏的关键一步。5.3 移动端适配的几个要点桌面能玩不代表手机能玩。移动端适配主要抓两点触摸事件和尺寸自适应。触摸方面click事件在移动端有约300毫秒延迟体验发闷。改用pointerdown或touchstart能明显改善响应速度。不过要注意防止误触和滚动冲突必要时加touch-action: manipulation。尺寸方面棋盘宽度别写死像素用min(90vw, 480px)这种写法让它在小屏上自动缩。格子用aspect-ratio: 1保持正方形整体布局就不会变形。字体和间距也建议用相对单位保证不同屏幕下观感一致。5.4 代码组织与可维护性建议项目虽小但如果不注意组织几百行代码堆在一个文件里也会变得难维护。我的建议是按职责拆函数initBoard、render、findMatches、applyGravity、resolveBoard、onCellClick各管一摊主流程清晰可读。状态变量集中声明在顶部别散落在各个函数里。常量单独放一块方便调参。如果后续要加道具、关卡这些功能可以考虑把棋盘逻辑抽成一个独立的模块对象渲染和交互分开这样扩展时改动面小、不容易牵一发动全身。这套组织习惯等你做更复杂的项目时会感谢现在的自己。我在实际做这个消除游戏的过程中最大的体会是逻辑和渲染一定要彻底分开。早期我图省事在消除循环里直接操作DOM结果动画和状态经常对不上改一处崩一片。后来狠心重构让所有逻辑只改board数组渲染统一由render()负责世界立刻清爽了加功能也顺手。另外就是别怕推倒重来第一版写得糙很正常把核心流程跑通后再逐步优化结构和动画比一开始就追求完美架构要务实得多。这个项目最值钱的地方不是最终成品而是你在反复调试匹配和下落逻辑时对数组操作和状态管理建立起来的直觉——那个东西看多少教程都换不来。

从零实现Web消除游戏：核心逻辑与避坑指南

相关推荐

t3code 技术解析：Electron 与 CLI 混合架构及 Homebrew/winget 安装指南

Linux进程程序替换原理与exec函数族实战指南

Linux进程程序替换原理与应用实践

更多资讯

AI投研工具的核心竞争力：不在模型数量，而在数据与框架

GeoXCP：空间解释不确定性量化框架解析与应用

Stable Diffusion 3.0企业级应用与品牌视觉模型实践

独角兽发卡系统源码部署与自动发货配置实战

润滑数值计算方法与程序：Reynolds方程求解及EHL代码实践

图片格式转换技术全解析与应用实践

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？