简介微信小程序为轻量级游戏开发提供了便捷的实践路径而以泡泡龙为代表的消除类游戏则是算法学习与工程实践结合的经典案例。这类游戏的核心不只在于发射球更涉及蜂窝网格的数据结构设计、像素坐标换算、碰撞检测、连通域搜索BFS、悬空掉落判定等关键技术。理解这些基础原理不仅能打造出流畅的休闲游戏体验还能为更复杂的游戏开发打下扎实基础。在工程层面Canvas渲染性能优化、瞄准线预测、游戏状态机管理以及真机安全区适配都是开发者常遇到的挑战。本文以微信小程序为例完整复盘了泡泡龙游戏从架构设计、核心算法到踩坑实录的全过程适合想通过实战掌握消除类游戏开发知识的工程师参考。 前几天整理硬盘翻出一个夏天写的泡泡龙小游戏源码顺手把它在微信小程序里重新实现了一遍。做完之后很多朋友都来问能不能分享正好借这篇博客把整个项目的源码思路、核心算法和实战中踩过的坑全部写出来。这篇内容适合刚接触微信小游戏开发、想拿完整案例练手的人也适合已经有小程序基础、想深入理解消除类游戏逻辑的同学。无论你是照着复刻还是在它的基础上改自己的玩法这篇都能给你一个很扎实的起点。泡泡龙这个品类有个特点规则简单但实现细节非常多。它的核心难点不在“发射球”这个动作本身而在背后的物理碰撞、消除判定、悬空掉落检测、连击结算这一整套循环。如果不把数据结构设计好后期改一个bug会牵连出一堆问题所以我会先从整体架构聊起再说每一步的代码实现。项目最终跑在微信开发者工具和真机上都没有问题代码量控制在1500行左右非常适合作为学习样板。1. 项目整体设计与技术选型1.1 泡泡龙的核心玩法拆解泡泡龙看上去是个休闲游戏但它的游戏逻辑其实是一个典型的“离散状态机”循环。玩家操作的每一轮可以拆成四个阶段瞄准、发射、碰撞消除、悬空掉落。所谓瞄准阶段就是当前炮台有一个待发球玩家手指在屏幕上滑动或者点击系统根据手指位置计算发射方向发射阶段球以一定速度沿直线飞出途中可能碰到顶壁反弹碰到其他球就停下来碰撞消除阶段停下来的球会插入到棋盘网格中然后检查它和周围同色球的连通关系如果同色连通数量大于等于三个这组球被消除最后悬空掉落阶段消除发生后原本被支撑住的球可能失去支撑这些球需要掉落并计分。这个循环说起来很清晰但代码里要处理的是“网格坐标”和“像素坐标”两套坐标系之间的互相转换以及各种边界情况。比如球撞到天花板时怎么反弹、球飞到一个缝隙里如何找到最近的插入位置、消除后如何判断哪些球悬空。这些细节如果没想清楚就动手写代码很快会变成一锅粥。1.2 技术选型原生小程序还是游戏引擎微信小程序里做小游戏最常见的路有三条用原生小程序框架加Canvas绘制、用Cocos Creator这类游戏引擎转小游戏、用Unity打包成微信小游戏。三条路各有适用场景。对于泡泡龙这种玩法固定的消除类游戏我强烈建议用原生小程序加Canvas绘制原因有二第一泡泡龙的画面元素非常少就是球、炮台、背景和简单的视觉特效根本用不上重量级引擎。用原生Canvas可以做到60帧流畅渲染内存占用也很低。第二原生小程序的调试和发布流程简单不用处理引擎导出的那一堆配置。我做这个项目的时候微信开发者工具里直接就能跑不需要额外装任何依赖对新手极其友好。但如果你做的是大型RPG或者3D游戏那Cocos或Unity就是更合理的选择。技术选型永远要匹配项目复杂度杀鸡不用牛刀。1.3 代码结构与模块划分整个项目我采用了模块化的组织方式把所有核心逻辑放在独立的js文件里页面只是一个壳。目录结构大概是这样的├── app.js ├── app.json ├── pages/ │ └── game/ │ ├── game.js │ ├── game.wxml │ ├── game.wxss │ └── game.json ├── utils/ │ ├── board.js // 棋盘数据结构与核心逻辑 │ ├── ball.js // 球的绘制与动画 │ ├── physics.js // 碰撞检测与数学计算 │ └── audio.js // 音效管理board.js是核心中的核心它负责棋盘数据的增删改查、消除检测、悬空掉落计算是纯逻辑模块不依赖任何渲染接口。这样设计的好处是方便调试和单元测试。physics.js封装了发射球和固定球之间的碰撞检测、反弹计算等几何运算。game.js是页面的控制器负责把用户的触摸操作翻译成游戏指令再驱动各个模块完成一局游戏。我刚写的时候也想过要不要把逻辑全部塞进game.js里毕竟项目不大。但写着写着就发现逻辑和渲染纠缠在一起一旦要调渲染效果逻辑代码也跟着重写。所以后来分割开来实测下来这套结构让我改代码的心理负担小了很多。2. 核心算法与数据结构设计2.1 棋盘模型从二维数组到蜂窝网格泡泡龙的地图本质上是一个正六边形紧密排列的蜂窝网格。每一行的球互相交错排列奇数行比偶数行在水平方向上错开半个球的间距。在代码里我选择用二维数组来存储棋盘数据行用row索引列用col索引。这里有个细节需要注意因为是蜂窝排列并不是每一行都有相同数量的球。我在初始化棋盘的时候偶数行的球数比奇数行少一个。比如地图宽度能容纳8个球那么偶数行8个、奇数行7个。这个设计看似简单却是后续所有计算的基础。定义棋盘的数据结构时我用了比较简洁的对象方式// utils/board.js const ROWS 12; // 最大行数 const COLS_EVEN 8; // 偶数行列数 const COLS_ODD 7; // 奇数行列数 class Board { constructor() { // 用 null 表示空位, 数字表示颜色索引 this.grid []; this.init(); } init() { this.grid []; for (let row 0; row ROWS; row) { const cols row % 2 0 ? COLS_EVEN : COLS_ODD; const line new Array(cols).fill(null); this.grid.push(line); } } }初始化的时候我是直接把整个棋盘清空然后随机往顶部若干行填充彩球。实际开发中初始化时的填充策略直接决定了游戏前几回合的体验。我试过完全随机填充结果有时候会出现开局就有一大片连球拍照都没来得及就疯狂消除。所以后来调整了随机算法初始化时做了一次同色去重校验保证不会在开局阶段出现三个以上同色球连在一起的情况。2.2 网格坐标与像素坐标的换算棋盘数据是抽象的坐标体系但渲染必须用像素坐标所以这是一个绕不开的核心函数。蜂窝网格的换算公式很固定已知球的直径diameter和半径radius垂直方向上相邻两行的圆心距离是Math.sqrt(3) * radius也就是0.866 * diameter水平方向上同一行相邻两球的圆心距离就是diameter。这里需要特别注意奇数行的水平偏移量。偶数行的第一个球圆心在棋盘的左边界加上radius奇数行的第一个球圆心在棋盘左边界加上radius * 2因为奇数行整体右移了半个球的宽度。用代码表示就是// utils/board.js function getPixelPos(row, col) { const y BOARD_TOP row * ROW_HEIGHT; const offsetX row % 2 1 ? radius : 0; const x BOARD_LEFT offsetX col * diameter radius; return { x, y }; }这个函数我在项目里用了很多次每次拿到球的网格坐标之后第一件事就是调它转换成屏幕坐标。反向换算也经常用到已知屏幕上一个点的坐标需要知道它落在哪个网格里。反向换算可以先把y坐标转成行号再算该行内水平偏移量对应的列号。需要注意边界如果x刚好落在两球交界处要取最近的那一格。实际开发中我一般都会加一个“吸附误差阈值”如果落点距离某个网格中心太近就直接归位到那个网格。反向换算的代码如下function getGridPos(x, y) { let row Math.round((y - BOARD_TOP) / ROW_HEIGHT); row Math.max(0, Math.min(ROWS - 1, row)); const cols row % 2 0 ? COLS_EVEN : COLS_ODD; const offsetX row % 2 1 ? radius : 0; let col Math.round((x - BOARD_LEFT - offsetX - radius) / diameter); col Math.max(0, Math.min(cols - 1, col)); return { row, col }; }这里我认为最需要警惕的坑是蜂窝网格并不是规整的矩形行与行之间是交错排列的。如果直接拿矩形网格的公式去算奇数行和偶数行的错位会带来大量莫名其妙的bug。2.3 发射与碰撞检测的数学原理泡泡龙的“射击”看起来平淡无奇但里面的物理计算其实非常讲究。发射球在飞出后每一帧的位置变化是newX x vx * dt newY y vy * dt只要计算每一帧球的新位置然后和棋盘上的所有静止球做距离判断就能检测到碰撞。碰撞发生的条件是两个球心的距离小于等于两个球的半径之和。这里有个很关键的经验如果一帧内球移动的距离超过了球的直径球有可能直接穿过目标导致检测不到碰撞。为了避免这个问题我采用了“小步长移动”策略把一帧拆成若干子步每步只移动很小的距离然后做检测这样能够显著减少穿模的概率。我实际用的增量是每帧切成4步每步移动不超过radius * 0.5。这个方案在60帧的刷新率下表现非常稳定极少出现穿模。下面是发射球碰撞检测的核心代码// utils/physics.js function ballCollides(x, y, fixedBalls, radius) { for (let i 0; i fixedBalls.length; i) { const b fixedBalls[i]; const dx x - b.x; const dy y - b.y; const dist Math.sqrt(dx * dx dy * dy); if (dist radius * 2 - 0.5) { return b; } } return null; }你可能会注意到我在距离判断里用了radius * 2 - 0.5而不是radius * 2这个0.5像素的余量是为了让球在碰撞时能“嵌进去”一点点视觉效果上更自然也避免两个球之间出现微小的空隙线。这个细节是做了很多次测试之后才加的没有这个余量的时候消除后球之间偶尔会出现一条很细的缝拍屏时尤其明显。2.4 消除判定连通域搜索三步走每次发射球落到棋盘上就要立刻判断是否有三个以上同色球相连。这个判断不能只看新球周围的几个邻居因为可能存在一条很长的同色链把若干个球连在一起。所以需要用到连通域搜索算法我使用的是BFS广度优先搜索。第一步把新球所在的格子加入待访问队列。第二步循环从队列取出一个球检查它周围的六个邻居如果邻居颜色相同且未被访问过把它加入队列并标记。第三步统计访问过的球数量如果大于等于3标记这些球准备消除。值得注意的是这里的“同色连通”指的是六个方向的邻居包含水平、左上、左下、右上、右下五个方向因为我设计的是蜂窝网格并不是四方向格子。计算邻居格子时需要根据行号奇偶性做不同的偏移// utils/board.js function getNeighbors(row, col) { const even row % 2 0; const neighbors []; if (even) { neighbors.push([row - 1, col - 1], [row - 1, col], [row, col - 1], [row, col 1], [row 1, col - 1], [row 1, col]); } else { neighbors.push([row - 1, col], [row - 1, col 1], [row, col - 1], [row, col 1], [row 1, col], [row 1, col 1]); } return neighbors.filter(([r, c]) { const maxCols r % 2 0 ? COLS_EVEN : COLS_ODD; return r 0 r ROWS c 0 c maxCols; }); }这条BFS代码是整个游戏算法的基础后面的悬空掉落检测也复用了同一套邻居获取逻辑。我在写这个函数时反复确认过边界条件因为数组越界报错在微信开发者工具里不如PC端调试器那么直观出问题的时候往往就是一闪而过的报错。消除判定的完整流程大概是function findConnectedBalls(row, col, color) { const visited new Set(); const queue [[row, col]]; visited.add(row , col); while (queue.length 0) { const [r, c] queue.shift(); const neighbors getNeighbors(r, c); for (const [nr, nc] of neighbors) { const key nr , nc; if (visited.has(key)) continue; if (this.grid[nr] this.grid[nr][nc] color) { visited.add(key); queue.push([nr, nc]); } } } return visited; }这里用Set来记录已访问节点key的格式是row,col的字符串。这套逻辑跑起来之后消除判定基本不会再出错。2.5 悬空掉落从BFS到“岛屿”检测消除完成后棋盘上会出现一些“悬空”的球。悬空的定义是这个球和棋盘顶部没有一条由球构成的连通路径。这句话说得很抽象我换种说法把想象成一块冰面顶部是天花板球如果和天花板没有接触它就会掉下来。但注意这里的“接触”不一定是直接接触可以是经过一系列相邻的球最终与顶部的任何球相连。实现方式其实就是从顶部所有非空球出发做BFS把所有能访问到的球标记为“已连接”。遍历整个棋盘凡是未被标记的非空球都是悬空球把它们全部从棋盘中移除。这个思路非常清晰而且和消除检测用的是同一个邻居系统代码复杂度极低。当时我调试这一步的时候遇到一个有意思的问题消除一组球之后新露出来的悬空球在视觉上会“停”在原地半秒再掉落看起来有点迟钝。后来我发现是因为掉落动画的帧率计算不准那一帧没有触发动画刷新。解决方案是掉落的球按固定的像素速度运动而不是按帧数计算。用帧数计算的话掉帧时就会出现突然跳变。掉落检测同步处理的核心代码function dropFloatingBalls() { const attached new Set(); const queue []; // 从顶部所有球开始遍历 for (let c 0; c this.grid[0].length; c) { if (this.grid[0][c] ! null) { const key 0, c; attached.add(key); queue.push([0, c]); } } while (queue.length 0) { const [r, c] queue.shift(); const neighbors getNeighbors(r, c); for (const [nr, nc] of neighbors) { const key nr , nc; if (attached.has(key)) continue; if (this.grid[nr][nc] ! null) { attached.add(key); queue.push([nr, nc]); } } } // 删除所有未连接的球 for (let r 0; r ROWS; r) { for (let c 0; c this.grid[r].length; c) { if (this.grid[r][c] ! null !attached.has(r , c)) { this.grid[r][c] null; // 触发掉落动画 } } } }这里我额外加了一个小设计掉落不是秒删而是先记录待掉落球的坐标和颜色再生成动画。动画播放完才真正把数据从grid里清掉。这样做的好处是视觉上非常自然玩家能看到“掉落”的完整过程而不是瞬间消失。3. 关键开发环节与实现细节3.1 Canvas渲染如何画出高帧率的球泡泡龙这个游戏所有的画面都是即时绘制的所以Canvas的渲染性能就特别重要。在微信小程序里我使用的是Canvas 2D接口在小程序页面的game.wxml里放一个canvas type2d idgameCanvas。注意这个type2d非常关键如果漏掉用老版wx.createCanvasContext的话API完全不同后面所有绘图代码都要改成旧写法。绘制球的核心是把每个球画成一个带高光效果的圆形。我本身是有些美术追求的所以每个球并不只是简单画一个圆而是分三层绘制底色圆、高光弧、内阴影弧。这么做的好处是画面质感一下子上来了稍微花点功夫渲染出来的效果比单调的实心圆好太多。function drawBall(ctx, x, y, radius, colorIndex) { const colors [#FF6B6B, #4ECDC4, #45B7D1, #FFA07A, #98D8C8, #F7DC6F]; ctx.beginPath(); ctx.arc(x, y, radius, 0, Math.PI * 2); ctx.fillStyle colors[colorIndex]; ctx.fill(); // 高光 ctx.beginPath(); ctx.arc(x - radius * 0.3, y - radius * 0.3, radius * 0.4, 0, Math.PI * 2); ctx.fillStyle rgba(255,255,255,0.35); ctx.fill(); // 内阴影 ctx.beginPath(); ctx.arc(x, y, radius * 0.85, Math.PI * 0.8, Math.PI * 1.8); ctx.strokeStyle rgba(0,0,0,0.15); ctx.lineWidth 2; ctx.stroke(); }关于Canvas性能的优化最重要的一个原则是不要把背景也放在同一帧里反复绘制。我的做法是把背景绘制到一张离屏Canvas上每次重新绘制球的时候只调用drawImage把背景贴回来然后再画球和瞄准线。如果不做这个优化背景里的渐变、网格线等复杂元素每帧重绘帧率会明显下降尤其是安卓中低端机特别明显。3.2 瞄准线用“虚拟命中点”预测落点泡泡龙的瞄准对游戏体验影响很大。我的实现方式是从炮台位置出发沿着当前发射方向做直线扫描判断这条线会先撞到哪个障碍物。如果线撞到了棋盘里的固定球那个位置就是新球要插入的位置如果线先撞到天花板那就按镜面反射规律向下反弹继续扫描直到撞到固定球或者左右墙壁。实现这个功能不需要真正的“画一条无限长的线”而是用逐步推进的方法。每次推进几个像素检查当前位置是否和固定球碰撞以及是否触顶或撞左右墙。当球到达目标位置时记录下发射路径上的最后几个点然后用这些点画一条虚线作为瞄准线。为了让玩家看清反射点我这里在路径发生转折的位置画了一个半透明的圆环标记效果不错。function calculateTrajectory(startX, startY, angle, fixedBalls, radius, maxSteps) { const path []; let x startX; let y startY; let vx Math.cos(angle) * speed; let vy Math.sin(angle) * speed; for (let i 0; i maxSteps; i) { x vx; y vy; // 顶部反弹 if (y - radius topBoundary vy 0) { vy -vy; y topBoundary radius; } // 左右墙反弹 if (x - radius leftBoundary || x radius rightBoundary) { vx -vx; x Math.max(leftBoundary radius, Math.min(rightBoundary - radius, x)); } path.push({ x, y }); const hit ballCollides(x, y, fixedBalls, radius); if (hit) { path.push({ x, y, hit }); break; } if (y canvasHeight radius) break; } return path; }这个方法非常直观而且容易调节难度。如果想让瞄准线看上去更平滑只需要增加maxSteps的数值如果想减少计算量加快瞄准线的响应速度可以减少maxSteps。实测下来maxSteps设置为200时瞄准线顺滑且不影响帧率。3.3 游戏状态机让逻辑不打架泡泡龙的每一回合涉及多个阶段玩家瞄准、球飞行、碰撞检测、消除判定、掉落动画、补充新行或切换待发球。这些阶段要是散落在各处状态很难维护。所以我引入了游戏状态机用gameState字段标记当前所处的阶段AIMING玩家可以在屏幕下方任意位置拖动炮台瞄准松开即发射FLYING球正在飞行玩家操作被屏蔽SETTLING球已经落位正在执行消除和掉落逻辑SPAWNING如果需要补充新行或者切换下一个待发球短暂的过渡阶段状态机的好处是任何异步操作比如掉落动画都不会打断正在进行的逻辑。例如在SETTLING状态下如果用户疯狂点击屏幕也不会触发新的发射操作从根上避免了连击混乱。在game.js里我用一个简单的switch来处理不同状态的更新逻辑配合wx.requestAnimationFrame实现稳定的帧循环。3.4 音效和动效小游戏质感的来源画面要素做完之后游戏其实已经可以玩了但给人的感觉会比较“干”。泡泡龙这类休闲游戏的体验很大程度上依赖音效和动效反馈。我做了三个很简单的效果发射音效、消除音效、掉落音效。音效用wx.createInnerAudioContext加载本地音频文件即可。// utils/audio.js const ctx wx.createInnerAudioContext(); ctx.src /assets/audio/shoot.mp3; function playShoot() { ctx.stop(); ctx.seek(0); ctx.play(); }这里有几个需要注意的点音频context是全局单例的不建议每次播放都新建一个播放前先stop()再seek(0)否则连续快速发射时音效会出现叠加或者卡顿。另外真机上InnerAudioContext在静音模式下不会发声但这不是bug不需要处理。动效方面我实现了两类特效消除时的粒子爆裂效果和球掉落时的残影效果。粒子效果用一小段数组存储粒子位置和速度每帧更新并绘制掉落残影则是记录球掉落前的位置绘制一个半透明的球跟随向下移动。这些动效的代码都比较短但极大提升了游戏反馈的完整度。3.5 实践从小程序启动到第一局游戏把上面各个模块串起来实际启动一局游戏的流程大概是这样的页面onLoad时初始化Board生成顶部若干行随机球onReady时获取Canvas节点创建Canvas 2D上下文启动帧循环玩家触摸到Canvas区域并移动game.js监听触摸事件更新炮台角度手指松开创建发射球并把它加入physics模块的运动队列帧循环里不断推进发射球的坐标做碰撞检测碰撞发生后把球插入棋盘网格切换状态到SETTLINGSETTLING中执行连通域消除和悬空掉落检测消除完成生成新的待发球或者补充一排新球压下来如果棋盘顶部被球堆满游戏结束这个流程听起来简单但每一步之间都可能有细微的时序问题。比如第6步插入棋盘时必须把像素坐标逆向换算成网格坐标如果这一步算错了可能出现球明明看着碰到了却插到了错误的格子里的情况。我在写这一步时花了不少时间调试最终确认必须使用getGridPos反向换算而不能简单地按像素坐标直接存。4. 踩坑实录与常见问题排查4.1 球穿模步长和碰撞半径的平衡我最开始写发射逻辑时是每帧直接把球的坐标增加vx和vy然后在帧末做一次碰撞检测。这样做的后果是当球的移动速度比较快的时候每帧位移超过球半径它会直接穿过固定在棋盘上的球导致球飞过整个屏幕直接消失。排查这个问题时我一度以为是坐标同步有误后来打印出每帧坐标才意识到是“跨步过大”。解决办法就是前面提到的“子步进”方案。在每一帧内把位移拆成多个小步骤每步都检测碰撞直到把这一帧的位移消耗完。这个方案在性能上几乎可以忽略不计因为棋盘上的固定球数量最多也就几十个每帧就算做几十次碰撞检测也不会有任何压力。实测中步长设置为radius * 0.4时从未再出现过穿模。还有一个有意思的细节碰撞后新球插入棋盘时可能同时“挤”到两个相邻球的交界处。这时候必须选择一个目标格子来存放不能同时占两格。我的做法是在碰撞点附近寻找最近的空闲网格把球放进去。如果这个格子已经被占则把球放在“离碰撞点最近的非空格”的相邻空闲格中。4.2 消除后卡死悬空检测的边界条件开发早期我在做悬空掉落检测时遇到了一个隐蔽的bug有时候消除完成之后游戏画面会卡住不动日志也不报错。排查后发现掉落检测的BFS是从第一行开始遍历的但当我用Set判断已访问时没有把第一行的球加入初始访问集合就导致整个BFS根本不会启动所有球都被误判为悬空然后全部被删除。操作上表现就是玩家发射一球触发消除后整个棋盘瞬间清空然后程序不知道应该做什么。类似这种“一开始什么都不对”的bug本质上还是初始条件没写好。这类问题我在调试时一般会加一堆console.log但更好用的方式是给Board写几个简单的单元测试在开发者工具的控制台里直接调用。比如构造一个只有两行球的棋盘手动调用dropFloatingBalls()然后检查哪些球被删除了。我后来就是这么干的问题十分钟内定位。4.3 真机适配屏幕比例与安全区在微信开发者工具里看着很舒服的游戏一到真机上就变得不对劲这是小游戏开发最常见的问题。泡泡龙的核心问题在于屏幕顶部的状态栏和底部的小横条。如果不处理棋盘顶部会被刘海遮挡底部的发射区域也会被手势条挡住。针对这个问题我在页面初始化时读取了wx.getWindowInfo()里的safeArea信息然后把棋盘的顶部起点和底部发射区域预留出安全区高度。具体实现上const info wx.getWindowInfo(); const safeTop info.safeArea.top; const safeBottom info.screenHeight - info.safeArea.bottom;然后把BOARD_TOP设置成safeTop 20底部的炮台区域则往上偏移safeBottom的高度。这里我建议把棋盘放在屏幕中上部保证所有球都在安全区内可见。如果使用自定义导航栏导航栏的高度也要一并计入不然游戏区域会被压得只剩一半。4.4 常见问题速查表为了让你在实际开发时少走弯路我把在这个项目中遇到的问题整理成了一个速查表这些经验基本是文档里找不到的。现象可能原因解决方案球飞行时直接穿过固定球坐标更新步长过大把一帧拆成多个子步每步移动不超过半个球半径瞄准线方向与手指位置不一致触摸坐标没有相对Canvas坐标系转换使用wx.createSelectorQuery()获取canvas的左上角坐标触摸时减去这个偏移消除后画面一直闪烁背景每帧重复绘制把静态背景缓存到离屏Canvas主Canvas只负责每帧绘制活动元素真机上棋盘顶部被刘海遮挡没有处理安全区读取safeArea把棋盘起点和炮台区域都按安全区调整球插入棋盘后位置偏移明显网格坐标和像素坐标换算不精确增加吸附逻辑当落点距离某个网格中心小于radius*0.6时强制归位连续点击屏幕时发射卡顿音效播放时重复初始化AudioContext使用全局单例播放前先stop和seek掉落的球在动画执行中夹在网格中间掉落逻辑和物理碰撞同时更新掉落动画期间把棋盘设置为只读状态这个表里的每一条我都实际遇到过有些甚至反复出现多次。尤其是“背景闪烁”和“真机适配”这两条第一次遇到时排查了很久后来才知道是绘制优化和系统安全区的问题。5. 功能扩展与后续优化方向5.1 玩法扩展道具系统与关卡设计泡泡龙这套代码底盘其实很稳定我在做完基础玩法之后又给它加了很多可以扩展的接口。道具系统就是一个很好的方向比如“炸弹球”可以消除周围一圈的球“彩色球”可以和任意颜色匹配“暂停球”可以冻结顶部一行球的生成速度。道具的实现并不复杂只需要在Board的类里增加一个ballType字段然后在消除判定时根据ballType做不同的逻辑分支。关卡设计方面可以引入“限定步数通关”或者“限定分数过关”两种模式。限定步数模式需要记录玩家的发射次数每次发射后递减归零时如果还没消除足够数量的球游戏失败。限定分数模式只需要在每次消除后累加分数达到目标分数即解锁下一关。关卡之间的区别可以是地图初始布局、球的颜色种类数量、初始行数等。我建议把这些扩展写在board.js的接口层比如loadLevel(levelData)方法接收一个关卡配置对象。这样后续做关卡编辑器都方便直接用JSON格式存关卡数据就行。5.2 社交化排行榜与分享微信小程序有个很天然的优势可以直接利用微信的社交关系链做排行榜。我把每局的分数存到了本地缓存然后在游戏结束页显示当轮得分再用wx.setStorageSync把最高分存起来。如果想做好友排行榜需要接入微信开放数据域调用wx.getFriendCloudStorage之类的接口。这块内容涉及发布权限和审核建议在完整上线前先做本地排行榜练手。分享功能也很重要。在游戏结束页面加一个按钮调用wx.shareAppMessage把游戏分享给好友。被分享的人打开后会自动进入游戏这样传播起来非常自然。我加了这个功能后测试群里传播效果比预想好很多很多人比拼分数产生了新一轮互动。5.3 性能调优从30帧到60帧的优化日志最后分享一段我调优的日志。刚开始把整个局面绘制完帧率在安卓真机上只有30帧左右画面明显卡顿。一帧里做了太多事情背景渐变、网格线、所有球的阴影和高光、瞄准线、炮台、粒子特效。我做了三个关键改动后帧率稳定在57到60之间第一把背景和网格线画到离屏Canvas不再每帧重绘。第二绘制球的时候缩小阴影和高光的绘制层级只在球边缘画一条半透明的描边不再单独绘制整块阴影。第三把粒子特效数量从每次40个减少到16个视觉上其实差别不大但性能提升明显。如果是低端机我还会开启一个“低画质模式”关闭高光和阴影效果只用纯色圆表示球。这个模式在设置面板里加一个开关默认关闭低画质模式中低端机用户可以自行打开。这个方案比单纯的性能优化更贴合实际场景。我做这个小游戏的过程中最大的心得体会是看似简单的休闲游戏拆开来看每一层的细节都值得深挖。棋盘数据结构、碰撞检测、消除算法、渲染性能、适配策略任何一环做得不够细致最后都会在玩家体验上暴露出来。如果你是想用这个小项目练手强烈建议不要只看完博客就关掉动手把这套代码完整敲一遍哪怕是照抄一遍也比只看强得多。抄一遍的过程中你才会发现原来蜂窝网格的边界条件有这么多讲究原来碰撞检测的步长设置是这么重要原来安全区适配不是一句废话。等你亲手把这个游戏跑起来并且能在微信开发者工具里看到流畅的画面时你会觉得这比玩一百个别人做好的游戏都有意思。如果过程中遇到问题欢迎在评论区留言看到就会回。本文还有配套的精品资源点击获取
简介微信小程序为轻量级游戏开发提供了便捷的实践路径而以泡泡龙为代表的消除类游戏则是算法学习与工程实践结合的经典案例。这类游戏的核心不只在于发射球更涉及蜂窝网格的数据结构设计、像素坐标换算、碰撞检测、连通域搜索BFS、悬空掉落判定等关键技术。理解这些基础原理不仅能打造出流畅的休闲游戏体验还能为更复杂的游戏开发打下扎实基础。在工程层面Canvas渲染性能优化、瞄准线预测、游戏状态机管理以及真机安全区适配都是开发者常遇到的挑战。本文以微信小程序为例完整复盘了泡泡龙游戏从架构设计、核心算法到踩坑实录的全过程适合想通过实战掌握消除类游戏开发知识的工程师参考。 前几天整理硬盘翻出一个夏天写的泡泡龙小游戏源码顺手把它在微信小程序里重新实现了一遍。做完之后很多朋友都来问能不能分享正好借这篇博客把整个项目的源码思路、核心算法和实战中踩过的坑全部写出来。这篇内容适合刚接触微信小游戏开发、想拿完整案例练手的人也适合已经有小程序基础、想深入理解消除类游戏逻辑的同学。无论你是照着复刻还是在它的基础上改自己的玩法这篇都能给你一个很扎实的起点。泡泡龙这个品类有个特点规则简单但实现细节非常多。它的核心难点不在“发射球”这个动作本身而在背后的物理碰撞、消除判定、悬空掉落检测、连击结算这一整套循环。如果不把数据结构设计好后期改一个bug会牵连出一堆问题所以我会先从整体架构聊起再说每一步的代码实现。项目最终跑在微信开发者工具和真机上都没有问题代码量控制在1500行左右非常适合作为学习样板。1. 项目整体设计与技术选型1.1 泡泡龙的核心玩法拆解泡泡龙看上去是个休闲游戏但它的游戏逻辑其实是一个典型的“离散状态机”循环。玩家操作的每一轮可以拆成四个阶段瞄准、发射、碰撞消除、悬空掉落。所谓瞄准阶段就是当前炮台有一个待发球玩家手指在屏幕上滑动或者点击系统根据手指位置计算发射方向发射阶段球以一定速度沿直线飞出途中可能碰到顶壁反弹碰到其他球就停下来碰撞消除阶段停下来的球会插入到棋盘网格中然后检查它和周围同色球的连通关系如果同色连通数量大于等于三个这组球被消除最后悬空掉落阶段消除发生后原本被支撑住的球可能失去支撑这些球需要掉落并计分。这个循环说起来很清晰但代码里要处理的是“网格坐标”和“像素坐标”两套坐标系之间的互相转换以及各种边界情况。比如球撞到天花板时怎么反弹、球飞到一个缝隙里如何找到最近的插入位置、消除后如何判断哪些球悬空。这些细节如果没想清楚就动手写代码很快会变成一锅粥。1.2 技术选型原生小程序还是游戏引擎微信小程序里做小游戏最常见的路有三条用原生小程序框架加Canvas绘制、用Cocos Creator这类游戏引擎转小游戏、用Unity打包成微信小游戏。三条路各有适用场景。对于泡泡龙这种玩法固定的消除类游戏我强烈建议用原生小程序加Canvas绘制原因有二第一泡泡龙的画面元素非常少就是球、炮台、背景和简单的视觉特效根本用不上重量级引擎。用原生Canvas可以做到60帧流畅渲染内存占用也很低。第二原生小程序的调试和发布流程简单不用处理引擎导出的那一堆配置。我做这个项目的时候微信开发者工具里直接就能跑不需要额外装任何依赖对新手极其友好。但如果你做的是大型RPG或者3D游戏那Cocos或Unity就是更合理的选择。技术选型永远要匹配项目复杂度杀鸡不用牛刀。1.3 代码结构与模块划分整个项目我采用了模块化的组织方式把所有核心逻辑放在独立的js文件里页面只是一个壳。目录结构大概是这样的├── app.js ├── app.json ├── pages/ │ └── game/ │ ├── game.js │ ├── game.wxml │ ├── game.wxss │ └── game.json ├── utils/ │ ├── board.js // 棋盘数据结构与核心逻辑 │ ├── ball.js // 球的绘制与动画 │ ├── physics.js // 碰撞检测与数学计算 │ └── audio.js // 音效管理board.js是核心中的核心它负责棋盘数据的增删改查、消除检测、悬空掉落计算是纯逻辑模块不依赖任何渲染接口。这样设计的好处是方便调试和单元测试。physics.js封装了发射球和固定球之间的碰撞检测、反弹计算等几何运算。game.js是页面的控制器负责把用户的触摸操作翻译成游戏指令再驱动各个模块完成一局游戏。我刚写的时候也想过要不要把逻辑全部塞进game.js里毕竟项目不大。但写着写着就发现逻辑和渲染纠缠在一起一旦要调渲染效果逻辑代码也跟着重写。所以后来分割开来实测下来这套结构让我改代码的心理负担小了很多。2. 核心算法与数据结构设计2.1 棋盘模型从二维数组到蜂窝网格泡泡龙的地图本质上是一个正六边形紧密排列的蜂窝网格。每一行的球互相交错排列奇数行比偶数行在水平方向上错开半个球的间距。在代码里我选择用二维数组来存储棋盘数据行用row索引列用col索引。这里有个细节需要注意因为是蜂窝排列并不是每一行都有相同数量的球。我在初始化棋盘的时候偶数行的球数比奇数行少一个。比如地图宽度能容纳8个球那么偶数行8个、奇数行7个。这个设计看似简单却是后续所有计算的基础。定义棋盘的数据结构时我用了比较简洁的对象方式// utils/board.js const ROWS 12; // 最大行数 const COLS_EVEN 8; // 偶数行列数 const COLS_ODD 7; // 奇数行列数 class Board { constructor() { // 用 null 表示空位, 数字表示颜色索引 this.grid []; this.init(); } init() { this.grid []; for (let row 0; row ROWS; row) { const cols row % 2 0 ? COLS_EVEN : COLS_ODD; const line new Array(cols).fill(null); this.grid.push(line); } } }初始化的时候我是直接把整个棋盘清空然后随机往顶部若干行填充彩球。实际开发中初始化时的填充策略直接决定了游戏前几回合的体验。我试过完全随机填充结果有时候会出现开局就有一大片连球拍照都没来得及就疯狂消除。所以后来调整了随机算法初始化时做了一次同色去重校验保证不会在开局阶段出现三个以上同色球连在一起的情况。2.2 网格坐标与像素坐标的换算棋盘数据是抽象的坐标体系但渲染必须用像素坐标所以这是一个绕不开的核心函数。蜂窝网格的换算公式很固定已知球的直径diameter和半径radius垂直方向上相邻两行的圆心距离是Math.sqrt(3) * radius也就是0.866 * diameter水平方向上同一行相邻两球的圆心距离就是diameter。这里需要特别注意奇数行的水平偏移量。偶数行的第一个球圆心在棋盘的左边界加上radius奇数行的第一个球圆心在棋盘左边界加上radius * 2因为奇数行整体右移了半个球的宽度。用代码表示就是// utils/board.js function getPixelPos(row, col) { const y BOARD_TOP row * ROW_HEIGHT; const offsetX row % 2 1 ? radius : 0; const x BOARD_LEFT offsetX col * diameter radius; return { x, y }; }这个函数我在项目里用了很多次每次拿到球的网格坐标之后第一件事就是调它转换成屏幕坐标。反向换算也经常用到已知屏幕上一个点的坐标需要知道它落在哪个网格里。反向换算可以先把y坐标转成行号再算该行内水平偏移量对应的列号。需要注意边界如果x刚好落在两球交界处要取最近的那一格。实际开发中我一般都会加一个“吸附误差阈值”如果落点距离某个网格中心太近就直接归位到那个网格。反向换算的代码如下function getGridPos(x, y) { let row Math.round((y - BOARD_TOP) / ROW_HEIGHT); row Math.max(0, Math.min(ROWS - 1, row)); const cols row % 2 0 ? COLS_EVEN : COLS_ODD; const offsetX row % 2 1 ? radius : 0; let col Math.round((x - BOARD_LEFT - offsetX - radius) / diameter); col Math.max(0, Math.min(cols - 1, col)); return { row, col }; }这里我认为最需要警惕的坑是蜂窝网格并不是规整的矩形行与行之间是交错排列的。如果直接拿矩形网格的公式去算奇数行和偶数行的错位会带来大量莫名其妙的bug。2.3 发射与碰撞检测的数学原理泡泡龙的“射击”看起来平淡无奇但里面的物理计算其实非常讲究。发射球在飞出后每一帧的位置变化是newX x vx * dt newY y vy * dt只要计算每一帧球的新位置然后和棋盘上的所有静止球做距离判断就能检测到碰撞。碰撞发生的条件是两个球心的距离小于等于两个球的半径之和。这里有个很关键的经验如果一帧内球移动的距离超过了球的直径球有可能直接穿过目标导致检测不到碰撞。为了避免这个问题我采用了“小步长移动”策略把一帧拆成若干子步每步只移动很小的距离然后做检测这样能够显著减少穿模的概率。我实际用的增量是每帧切成4步每步移动不超过radius * 0.5。这个方案在60帧的刷新率下表现非常稳定极少出现穿模。下面是发射球碰撞检测的核心代码// utils/physics.js function ballCollides(x, y, fixedBalls, radius) { for (let i 0; i fixedBalls.length; i) { const b fixedBalls[i]; const dx x - b.x; const dy y - b.y; const dist Math.sqrt(dx * dx dy * dy); if (dist radius * 2 - 0.5) { return b; } } return null; }你可能会注意到我在距离判断里用了radius * 2 - 0.5而不是radius * 2这个0.5像素的余量是为了让球在碰撞时能“嵌进去”一点点视觉效果上更自然也避免两个球之间出现微小的空隙线。这个细节是做了很多次测试之后才加的没有这个余量的时候消除后球之间偶尔会出现一条很细的缝拍屏时尤其明显。2.4 消除判定连通域搜索三步走每次发射球落到棋盘上就要立刻判断是否有三个以上同色球相连。这个判断不能只看新球周围的几个邻居因为可能存在一条很长的同色链把若干个球连在一起。所以需要用到连通域搜索算法我使用的是BFS广度优先搜索。第一步把新球所在的格子加入待访问队列。第二步循环从队列取出一个球检查它周围的六个邻居如果邻居颜色相同且未被访问过把它加入队列并标记。第三步统计访问过的球数量如果大于等于3标记这些球准备消除。值得注意的是这里的“同色连通”指的是六个方向的邻居包含水平、左上、左下、右上、右下五个方向因为我设计的是蜂窝网格并不是四方向格子。计算邻居格子时需要根据行号奇偶性做不同的偏移// utils/board.js function getNeighbors(row, col) { const even row % 2 0; const neighbors []; if (even) { neighbors.push([row - 1, col - 1], [row - 1, col], [row, col - 1], [row, col 1], [row 1, col - 1], [row 1, col]); } else { neighbors.push([row - 1, col], [row - 1, col 1], [row, col - 1], [row, col 1], [row 1, col], [row 1, col 1]); } return neighbors.filter(([r, c]) { const maxCols r % 2 0 ? COLS_EVEN : COLS_ODD; return r 0 r ROWS c 0 c maxCols; }); }这条BFS代码是整个游戏算法的基础后面的悬空掉落检测也复用了同一套邻居获取逻辑。我在写这个函数时反复确认过边界条件因为数组越界报错在微信开发者工具里不如PC端调试器那么直观出问题的时候往往就是一闪而过的报错。消除判定的完整流程大概是function findConnectedBalls(row, col, color) { const visited new Set(); const queue [[row, col]]; visited.add(row , col); while (queue.length 0) { const [r, c] queue.shift(); const neighbors getNeighbors(r, c); for (const [nr, nc] of neighbors) { const key nr , nc; if (visited.has(key)) continue; if (this.grid[nr] this.grid[nr][nc] color) { visited.add(key); queue.push([nr, nc]); } } } return visited; }这里用Set来记录已访问节点key的格式是row,col的字符串。这套逻辑跑起来之后消除判定基本不会再出错。2.5 悬空掉落从BFS到“岛屿”检测消除完成后棋盘上会出现一些“悬空”的球。悬空的定义是这个球和棋盘顶部没有一条由球构成的连通路径。这句话说得很抽象我换种说法把想象成一块冰面顶部是天花板球如果和天花板没有接触它就会掉下来。但注意这里的“接触”不一定是直接接触可以是经过一系列相邻的球最终与顶部的任何球相连。实现方式其实就是从顶部所有非空球出发做BFS把所有能访问到的球标记为“已连接”。遍历整个棋盘凡是未被标记的非空球都是悬空球把它们全部从棋盘中移除。这个思路非常清晰而且和消除检测用的是同一个邻居系统代码复杂度极低。当时我调试这一步的时候遇到一个有意思的问题消除一组球之后新露出来的悬空球在视觉上会“停”在原地半秒再掉落看起来有点迟钝。后来我发现是因为掉落动画的帧率计算不准那一帧没有触发动画刷新。解决方案是掉落的球按固定的像素速度运动而不是按帧数计算。用帧数计算的话掉帧时就会出现突然跳变。掉落检测同步处理的核心代码function dropFloatingBalls() { const attached new Set(); const queue []; // 从顶部所有球开始遍历 for (let c 0; c this.grid[0].length; c) { if (this.grid[0][c] ! null) { const key 0, c; attached.add(key); queue.push([0, c]); } } while (queue.length 0) { const [r, c] queue.shift(); const neighbors getNeighbors(r, c); for (const [nr, nc] of neighbors) { const key nr , nc; if (attached.has(key)) continue; if (this.grid[nr][nc] ! null) { attached.add(key); queue.push([nr, nc]); } } } // 删除所有未连接的球 for (let r 0; r ROWS; r) { for (let c 0; c this.grid[r].length; c) { if (this.grid[r][c] ! null !attached.has(r , c)) { this.grid[r][c] null; // 触发掉落动画 } } } }这里我额外加了一个小设计掉落不是秒删而是先记录待掉落球的坐标和颜色再生成动画。动画播放完才真正把数据从grid里清掉。这样做的好处是视觉上非常自然玩家能看到“掉落”的完整过程而不是瞬间消失。3. 关键开发环节与实现细节3.1 Canvas渲染如何画出高帧率的球泡泡龙这个游戏所有的画面都是即时绘制的所以Canvas的渲染性能就特别重要。在微信小程序里我使用的是Canvas 2D接口在小程序页面的game.wxml里放一个canvas type2d idgameCanvas。注意这个type2d非常关键如果漏掉用老版wx.createCanvasContext的话API完全不同后面所有绘图代码都要改成旧写法。绘制球的核心是把每个球画成一个带高光效果的圆形。我本身是有些美术追求的所以每个球并不只是简单画一个圆而是分三层绘制底色圆、高光弧、内阴影弧。这么做的好处是画面质感一下子上来了稍微花点功夫渲染出来的效果比单调的实心圆好太多。function drawBall(ctx, x, y, radius, colorIndex) { const colors [#FF6B6B, #4ECDC4, #45B7D1, #FFA07A, #98D8C8, #F7DC6F]; ctx.beginPath(); ctx.arc(x, y, radius, 0, Math.PI * 2); ctx.fillStyle colors[colorIndex]; ctx.fill(); // 高光 ctx.beginPath(); ctx.arc(x - radius * 0.3, y - radius * 0.3, radius * 0.4, 0, Math.PI * 2); ctx.fillStyle rgba(255,255,255,0.35); ctx.fill(); // 内阴影 ctx.beginPath(); ctx.arc(x, y, radius * 0.85, Math.PI * 0.8, Math.PI * 1.8); ctx.strokeStyle rgba(0,0,0,0.15); ctx.lineWidth 2; ctx.stroke(); }关于Canvas性能的优化最重要的一个原则是不要把背景也放在同一帧里反复绘制。我的做法是把背景绘制到一张离屏Canvas上每次重新绘制球的时候只调用drawImage把背景贴回来然后再画球和瞄准线。如果不做这个优化背景里的渐变、网格线等复杂元素每帧重绘帧率会明显下降尤其是安卓中低端机特别明显。3.2 瞄准线用“虚拟命中点”预测落点泡泡龙的瞄准对游戏体验影响很大。我的实现方式是从炮台位置出发沿着当前发射方向做直线扫描判断这条线会先撞到哪个障碍物。如果线撞到了棋盘里的固定球那个位置就是新球要插入的位置如果线先撞到天花板那就按镜面反射规律向下反弹继续扫描直到撞到固定球或者左右墙壁。实现这个功能不需要真正的“画一条无限长的线”而是用逐步推进的方法。每次推进几个像素检查当前位置是否和固定球碰撞以及是否触顶或撞左右墙。当球到达目标位置时记录下发射路径上的最后几个点然后用这些点画一条虚线作为瞄准线。为了让玩家看清反射点我这里在路径发生转折的位置画了一个半透明的圆环标记效果不错。function calculateTrajectory(startX, startY, angle, fixedBalls, radius, maxSteps) { const path []; let x startX; let y startY; let vx Math.cos(angle) * speed; let vy Math.sin(angle) * speed; for (let i 0; i maxSteps; i) { x vx; y vy; // 顶部反弹 if (y - radius topBoundary vy 0) { vy -vy; y topBoundary radius; } // 左右墙反弹 if (x - radius leftBoundary || x radius rightBoundary) { vx -vx; x Math.max(leftBoundary radius, Math.min(rightBoundary - radius, x)); } path.push({ x, y }); const hit ballCollides(x, y, fixedBalls, radius); if (hit) { path.push({ x, y, hit }); break; } if (y canvasHeight radius) break; } return path; }这个方法非常直观而且容易调节难度。如果想让瞄准线看上去更平滑只需要增加maxSteps的数值如果想减少计算量加快瞄准线的响应速度可以减少maxSteps。实测下来maxSteps设置为200时瞄准线顺滑且不影响帧率。3.3 游戏状态机让逻辑不打架泡泡龙的每一回合涉及多个阶段玩家瞄准、球飞行、碰撞检测、消除判定、掉落动画、补充新行或切换待发球。这些阶段要是散落在各处状态很难维护。所以我引入了游戏状态机用gameState字段标记当前所处的阶段AIMING玩家可以在屏幕下方任意位置拖动炮台瞄准松开即发射FLYING球正在飞行玩家操作被屏蔽SETTLING球已经落位正在执行消除和掉落逻辑SPAWNING如果需要补充新行或者切换下一个待发球短暂的过渡阶段状态机的好处是任何异步操作比如掉落动画都不会打断正在进行的逻辑。例如在SETTLING状态下如果用户疯狂点击屏幕也不会触发新的发射操作从根上避免了连击混乱。在game.js里我用一个简单的switch来处理不同状态的更新逻辑配合wx.requestAnimationFrame实现稳定的帧循环。3.4 音效和动效小游戏质感的来源画面要素做完之后游戏其实已经可以玩了但给人的感觉会比较“干”。泡泡龙这类休闲游戏的体验很大程度上依赖音效和动效反馈。我做了三个很简单的效果发射音效、消除音效、掉落音效。音效用wx.createInnerAudioContext加载本地音频文件即可。// utils/audio.js const ctx wx.createInnerAudioContext(); ctx.src /assets/audio/shoot.mp3; function playShoot() { ctx.stop(); ctx.seek(0); ctx.play(); }这里有几个需要注意的点音频context是全局单例的不建议每次播放都新建一个播放前先stop()再seek(0)否则连续快速发射时音效会出现叠加或者卡顿。另外真机上InnerAudioContext在静音模式下不会发声但这不是bug不需要处理。动效方面我实现了两类特效消除时的粒子爆裂效果和球掉落时的残影效果。粒子效果用一小段数组存储粒子位置和速度每帧更新并绘制掉落残影则是记录球掉落前的位置绘制一个半透明的球跟随向下移动。这些动效的代码都比较短但极大提升了游戏反馈的完整度。3.5 实践从小程序启动到第一局游戏把上面各个模块串起来实际启动一局游戏的流程大概是这样的页面onLoad时初始化Board生成顶部若干行随机球onReady时获取Canvas节点创建Canvas 2D上下文启动帧循环玩家触摸到Canvas区域并移动game.js监听触摸事件更新炮台角度手指松开创建发射球并把它加入physics模块的运动队列帧循环里不断推进发射球的坐标做碰撞检测碰撞发生后把球插入棋盘网格切换状态到SETTLINGSETTLING中执行连通域消除和悬空掉落检测消除完成生成新的待发球或者补充一排新球压下来如果棋盘顶部被球堆满游戏结束这个流程听起来简单但每一步之间都可能有细微的时序问题。比如第6步插入棋盘时必须把像素坐标逆向换算成网格坐标如果这一步算错了可能出现球明明看着碰到了却插到了错误的格子里的情况。我在写这一步时花了不少时间调试最终确认必须使用getGridPos反向换算而不能简单地按像素坐标直接存。4. 踩坑实录与常见问题排查4.1 球穿模步长和碰撞半径的平衡我最开始写发射逻辑时是每帧直接把球的坐标增加vx和vy然后在帧末做一次碰撞检测。这样做的后果是当球的移动速度比较快的时候每帧位移超过球半径它会直接穿过固定在棋盘上的球导致球飞过整个屏幕直接消失。排查这个问题时我一度以为是坐标同步有误后来打印出每帧坐标才意识到是“跨步过大”。解决办法就是前面提到的“子步进”方案。在每一帧内把位移拆成多个小步骤每步都检测碰撞直到把这一帧的位移消耗完。这个方案在性能上几乎可以忽略不计因为棋盘上的固定球数量最多也就几十个每帧就算做几十次碰撞检测也不会有任何压力。实测中步长设置为radius * 0.4时从未再出现过穿模。还有一个有意思的细节碰撞后新球插入棋盘时可能同时“挤”到两个相邻球的交界处。这时候必须选择一个目标格子来存放不能同时占两格。我的做法是在碰撞点附近寻找最近的空闲网格把球放进去。如果这个格子已经被占则把球放在“离碰撞点最近的非空格”的相邻空闲格中。4.2 消除后卡死悬空检测的边界条件开发早期我在做悬空掉落检测时遇到了一个隐蔽的bug有时候消除完成之后游戏画面会卡住不动日志也不报错。排查后发现掉落检测的BFS是从第一行开始遍历的但当我用Set判断已访问时没有把第一行的球加入初始访问集合就导致整个BFS根本不会启动所有球都被误判为悬空然后全部被删除。操作上表现就是玩家发射一球触发消除后整个棋盘瞬间清空然后程序不知道应该做什么。类似这种“一开始什么都不对”的bug本质上还是初始条件没写好。这类问题我在调试时一般会加一堆console.log但更好用的方式是给Board写几个简单的单元测试在开发者工具的控制台里直接调用。比如构造一个只有两行球的棋盘手动调用dropFloatingBalls()然后检查哪些球被删除了。我后来就是这么干的问题十分钟内定位。4.3 真机适配屏幕比例与安全区在微信开发者工具里看着很舒服的游戏一到真机上就变得不对劲这是小游戏开发最常见的问题。泡泡龙的核心问题在于屏幕顶部的状态栏和底部的小横条。如果不处理棋盘顶部会被刘海遮挡底部的发射区域也会被手势条挡住。针对这个问题我在页面初始化时读取了wx.getWindowInfo()里的safeArea信息然后把棋盘的顶部起点和底部发射区域预留出安全区高度。具体实现上const info wx.getWindowInfo(); const safeTop info.safeArea.top; const safeBottom info.screenHeight - info.safeArea.bottom;然后把BOARD_TOP设置成safeTop 20底部的炮台区域则往上偏移safeBottom的高度。这里我建议把棋盘放在屏幕中上部保证所有球都在安全区内可见。如果使用自定义导航栏导航栏的高度也要一并计入不然游戏区域会被压得只剩一半。4.4 常见问题速查表为了让你在实际开发时少走弯路我把在这个项目中遇到的问题整理成了一个速查表这些经验基本是文档里找不到的。现象可能原因解决方案球飞行时直接穿过固定球坐标更新步长过大把一帧拆成多个子步每步移动不超过半个球半径瞄准线方向与手指位置不一致触摸坐标没有相对Canvas坐标系转换使用wx.createSelectorQuery()获取canvas的左上角坐标触摸时减去这个偏移消除后画面一直闪烁背景每帧重复绘制把静态背景缓存到离屏Canvas主Canvas只负责每帧绘制活动元素真机上棋盘顶部被刘海遮挡没有处理安全区读取safeArea把棋盘起点和炮台区域都按安全区调整球插入棋盘后位置偏移明显网格坐标和像素坐标换算不精确增加吸附逻辑当落点距离某个网格中心小于radius*0.6时强制归位连续点击屏幕时发射卡顿音效播放时重复初始化AudioContext使用全局单例播放前先stop和seek掉落的球在动画执行中夹在网格中间掉落逻辑和物理碰撞同时更新掉落动画期间把棋盘设置为只读状态这个表里的每一条我都实际遇到过有些甚至反复出现多次。尤其是“背景闪烁”和“真机适配”这两条第一次遇到时排查了很久后来才知道是绘制优化和系统安全区的问题。5. 功能扩展与后续优化方向5.1 玩法扩展道具系统与关卡设计泡泡龙这套代码底盘其实很稳定我在做完基础玩法之后又给它加了很多可以扩展的接口。道具系统就是一个很好的方向比如“炸弹球”可以消除周围一圈的球“彩色球”可以和任意颜色匹配“暂停球”可以冻结顶部一行球的生成速度。道具的实现并不复杂只需要在Board的类里增加一个ballType字段然后在消除判定时根据ballType做不同的逻辑分支。关卡设计方面可以引入“限定步数通关”或者“限定分数过关”两种模式。限定步数模式需要记录玩家的发射次数每次发射后递减归零时如果还没消除足够数量的球游戏失败。限定分数模式只需要在每次消除后累加分数达到目标分数即解锁下一关。关卡之间的区别可以是地图初始布局、球的颜色种类数量、初始行数等。我建议把这些扩展写在board.js的接口层比如loadLevel(levelData)方法接收一个关卡配置对象。这样后续做关卡编辑器都方便直接用JSON格式存关卡数据就行。5.2 社交化排行榜与分享微信小程序有个很天然的优势可以直接利用微信的社交关系链做排行榜。我把每局的分数存到了本地缓存然后在游戏结束页显示当轮得分再用wx.setStorageSync把最高分存起来。如果想做好友排行榜需要接入微信开放数据域调用wx.getFriendCloudStorage之类的接口。这块内容涉及发布权限和审核建议在完整上线前先做本地排行榜练手。分享功能也很重要。在游戏结束页面加一个按钮调用wx.shareAppMessage把游戏分享给好友。被分享的人打开后会自动进入游戏这样传播起来非常自然。我加了这个功能后测试群里传播效果比预想好很多很多人比拼分数产生了新一轮互动。5.3 性能调优从30帧到60帧的优化日志最后分享一段我调优的日志。刚开始把整个局面绘制完帧率在安卓真机上只有30帧左右画面明显卡顿。一帧里做了太多事情背景渐变、网格线、所有球的阴影和高光、瞄准线、炮台、粒子特效。我做了三个关键改动后帧率稳定在57到60之间第一把背景和网格线画到离屏Canvas不再每帧重绘。第二绘制球的时候缩小阴影和高光的绘制层级只在球边缘画一条半透明的描边不再单独绘制整块阴影。第三把粒子特效数量从每次40个减少到16个视觉上其实差别不大但性能提升明显。如果是低端机我还会开启一个“低画质模式”关闭高光和阴影效果只用纯色圆表示球。这个模式在设置面板里加一个开关默认关闭低画质模式中低端机用户可以自行打开。这个方案比单纯的性能优化更贴合实际场景。我做这个小游戏的过程中最大的心得体会是看似简单的休闲游戏拆开来看每一层的细节都值得深挖。棋盘数据结构、碰撞检测、消除算法、渲染性能、适配策略任何一环做得不够细致最后都会在玩家体验上暴露出来。如果你是想用这个小项目练手强烈建议不要只看完博客就关掉动手把这套代码完整敲一遍哪怕是照抄一遍也比只看强得多。抄一遍的过程中你才会发现原来蜂窝网格的边界条件有这么多讲究原来碰撞检测的步长设置是这么重要原来安全区适配不是一句废话。等你亲手把这个游戏跑起来并且能在微信开发者工具里看到流畅的画面时你会觉得这比玩一百个别人做好的游戏都有意思。如果过程中遇到问题欢迎在评论区留言看到就会回。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
