简介基于cocos2d-x引擎制作的糖果消除游戏完整工程面向希望通过实际项目学习跨平台二维游戏开发的初学者和中级开发者。项目中已附带可在视窗系统下直接运行的执行程序以及对应的全套源代码核心逻辑覆盖了随机糖果棋盘的生成、相邻糖果交换操作、三消或更多同色连通的判定、消除时动画特效的播放、剩余步数或分数统计以及关卡切换等常见玩法模块。压缩包一共包含四十三个文件整体体积约三点四六兆字节除了主要的工程文件和源码头文件之外还收集了游戏所用到的界面贴图、属性列表配置、字体文件以及程序运行所需要的动态链接库解压后即可在开发环境中打开并对照源码进行学习。目前这套资源已有两百零八人浏览学习比较适合刚接触休闲游戏开发又想弄清三消游戏背后实现逻辑的读者既可以从头搭建相似玩法也能在此基础上继续扩展特殊糖果、道具系统甚至联机对战等内容。1. 一个用 cocos2d-x 写的 candy crush把三消源码拆到能直接改玩法再上线的程度用 cocos2d-x 写的 candy crush 三消玩法核心亮点是整套可复现的“交换-匹配-消除-掉落”状态机。适合两类人想把三消逻辑移植到自研引擎的开发者和想在自己项目里加消除玩法但不想从零写算法的同事。它把糖果网格抽象成二维数据数组用回溯式的匹配检测不用看几百个文件才能跑起来把核心的“棋盘”类提出来就能用。我拿到这套资源后习惯是先跑效果再一行行拆匹配与连锁逻辑比对着文档啃效率高很多。三消玩法的爽感来自连锁而这套代码的连锁判定写在数据层调试时可以直接打印棋盘状态非常直观。2. 三消核心算法从棋盘建模到匹配、消除、掉落的状态机闭环2.1 棋盘建模二维数组与精灵节点的对应关系糖果消消乐的核心不是渲染是棋盘模型。常见做法是把棋盘定义为一个 M×N 的二维数组每个格子存一个糖果类型。经典布局是 8 行 8 列初始用例 5 或 6 种类型按算法随机填入但必须保证初始局面没有现成的三连——否则玩家还没动手就开始连锁消除关卡节奏直接失控。这套源码在生成棋盘时用了洗牌式填充每填一个格子都回看左侧两格和上方两格发现三连就换一个类型再填。这样做的好处是生成结果可控不会出现大面积的预置匹配。代价是生成效率略低但 8×8 的棋盘规模下完全无感。// BoardData.h enum CandyType { CandyNone -1, CandyRed 0, CandyBlue, CandyGreen, CandyYellow, CandyPurple, CandyOrange }; struct CandyData { CandyType type; int row; int col; bool markedForClear; CandyData() : type(CandyRed), row(0), col(0), markedForClear(false) {} }; class BoardData { public: BoardData(int rows, int cols); void generate(); void swap(int r1, int c1, int r2, int c2); std::vectorstd::pairint,int findMatches(); void clearMarked(); void applyGravity(); void refill(); private: bool hasMatchAt(int r, int c); int rows; int cols; std::vectorstd::vectorCandyData grid; };逻辑说明grid是棋盘的全部家底swap只交换两个格子的 type不直接动精灵节点。真正的视觉交换由上层控制层完成棋盘层只负责数据一致。findMatches返回所有需要消除的格子坐标集合applyGravity负责让糖果下落补齐空格refill负责在顶部生成新糖果。数据层独立于引擎还有一个隐性好处你能不依赖任何渲染代码给棋盘写单元测试后面加障碍物、改关卡配置时回归测试的成本会低很多。参数说明rows 和 cols 决定棋盘尺寸难度高时可以调到 9×9 甚至 10×10但要注意屏幕适配。糖果类型数量建议 57 种类型太少容易频繁出现三消玩家会觉得局面失控类型太多则匹配难度偏高消除节奏拖沓。这个枚举里用的是 6 种类型加一个空类型实际调整枚举数量就能控制初始局面的匹配密度。2.2 匹配检测回溯式扫描与标记-消除解耦三消检测的思路直接但容易写错对每个格子向右连续扫描同类型糖果再向下连续扫描统计连续数量。数量等于或多于 3 就标记。边界是最容易翻车的地方——扫描到最右侧或最下方时连续段刚好结束在边界上如果不做一次收尾判断会漏掉一整行或一整列。std::vectorstd::pairint,int BoardData::findMatches() { std::vectorstd::pairint,int matches; bool matched[8][8] {false}; // 横向扫描统计连续同色段 for (int r 0; r rows; r) { int streak 1; for (int c 1; c cols; c) { if (grid[r][c].type grid[r][c-1].type) { streak; } else { if (streak 3) { for (int k c - streak; k c; k) { matched[r][k] true; } } streak 1; } } // 处理行尾的连续段 if (streak 3) { for (int k cols - streak; k cols; k) { matched[r][k] true; } } } // 纵向扫描统计连续同色段 for (int c 0; c cols; c) { int streak 1; for (int r 1; r rows; r) { if (grid[r][c].type grid[r-1][c].type) { streak; } else { if (streak 3) { for (int k r - streak; k r; k) { matched[k][c] true; } } streak 1; } } if (streak 3) { for (int k rows - streak; k rows; k) { matched[k][c] true; } } } for (int r 0; r rows; r) { for (int c 0; c cols; c) { if (matched[r][c]) { matches.push_back({r, c}); } } } return matches; }逻辑说明这里用了一个临时的matched二维布尔数组先标定需要消除的格子再统一转成坐标列表而不是边扫边消除。边扫边消除会出大问题——某一行消除后格子空了下一行扫描同一列时类型对不上连锁判定直接乱掉。标记和消除分开是这套源码里最值得抄的设计。注意上面代码的bool matched[8][8]是默认尺寸写法如果要通用化应当改成vectorvectorbool matched(rows, vectorbool(cols, false))否则换棋盘尺寸时就崩了。参数说明streak是连续计数大于等于 3 就触发标记。如果想做“只消除恰好 3 个”的变体玩法把判断改成streak 3即可想支持 4 连、5 连触发特殊糖果保留不变。主线玩法里是标准配置因为 4 连和 5 连会生成特殊糖果这一章后面会展开。2.3 消除、下落与连锁用循环把状态跑完整消除和下落是紧密相连的两步。消除把格子清空下落把上空格的糖果整体往下移顶部生成新糖果。做完后必须重扫一次棋盘看新补入的糖果是否形成新的三连——这就是连锁连击。连锁是得分弹跳的主要来源也是新手容易写崩的地方。void BoardData::clearMarked() { for (int r 0; r rows; r) { for (int c 0; c cols; c) { if (grid[r][c].markedForClear) { grid[r][c].type CandyNone; // 空类型等待下落补位 grid[r][c].markedForClear false; } } } } void BoardData::applyGravity() { for (int c 0; c cols; c) { int writeRow rows - 1; // 从底部向上扫描把非空糖果搬到底部空位 for (int r rows - 1; r 0; r--) { if (grid[r][c].type ! CandyNone) { grid[writeRow][c].type grid[r][c].type; if (writeRow ! r) { grid[r][c].type CandyNone; } writeRow--; } } } } void BoardData::refill() { for (int r 0; r rows; r) { for (int c 0; c cols; c) { if (grid[r][c].type CandyNone) { // 随机生成一种糖果类型 grid[r][c].type (CandyType)(rand() % (CandyOrange 1)); } } } }逻辑说明applyGravity的下落通过“从底部向上扫描、把非空格子往底部空位搬”的方式实现没有复杂的下落速度模拟数据层瞬间完成。refill只在所有下落结束时调用生成随机类型。为了防止新生成糖果立刻形成三连有些实现会在 refill 后做一次 findMatches 检查发现匹配就重生成该格直到没有匹配为止。这套源码里没做这层强校验改为在 generate 阶段兜底。参数说明CandyNone是特殊空类型不能是玩家可见的糖果。不要用CandyRed充当“空”否则下落逻辑会把所有红色糖果当成空处理。随机范围CandyOrange 1是类型数量后续增加新糖果类型时这里要跟着加最好直接用kCandyTypeCount这类常量化写法免得枚举改了这里忘了改。连锁判定的入口通常长这样交换两个糖果 → 检测 → 有匹配就消除 → 下落 → 补位 → 再检测直到某一次检测找不到匹配局面才稳定。新手容易把这里的循环写成“先消除再检测”漏掉“消除后糖果还没下落就再次检测”的时序导致连锁判定永远少算一轮。bool BoardLayer::executeResolveChain() { bool anyMatch true; int comboCount 0; while (anyMatch) { auto matches board-findMatches(); if (matches.empty()) { anyMatch false; } else { comboCount; board-markMatches(matches); board-clearMarked(); board-applyGravity(); board-refill(); // 动画与数据分开先同步数据再刷新精灵位置 refreshCandySprites(); // 连锁分数第一次 50第二次 100第三次 200 scoreSystem-addComboScore(comboCount, matches.size()); } } return comboCount 0; }逻辑说明executeResolveChain是整套消除流程的主入口。每轮先找匹配没有匹配就退出有匹配就计数、标记、消除、下落、补位、刷新精灵然后进入下一轮。comboCount 每轮加 1分数结算可以按“第一次消除 50 分、第二次 100 分、第三次 200 分”这种递进规则来做不需要额外的状态机。要注意刷新精灵位置必须等数据层全部完成后再做否则玩家会看到糖果下落到一半、新糖果已经出现的割裂画面。参数说明连锁分数的递增倍率是控制数值爽感的关键。我一般用底数 50、倍率 2 的指数递增最多触发 5 次连锁否则分数膨胀太快也可以用线性递增适合更休闲的玩法。如果棋盘上加了障碍物这里的 refill 要改成带权重生成的版本先预置障碍物坐标和解锁条件再决定新糖果能否落在障碍物上。3. 把触控和动画做对三消手感从数据到画面的最后一公里3.1 触摸事件的坐标换算从屏幕点到棋盘格的映射数据层写得再好触摸换算不对玩家照样觉得“手感差”。三消的操作手感很大程度在这个换算公式上触摸点是屏幕坐标棋盘数据是行列号。核心公式是row (touchY - originY) / cellSize、col (touchX - originX) / cellSize但 origin 的取值才是翻车高发区——它到底是棋盘左下角还是中心取决于节点锚点没有统一约定前不要写换算函数。bool GameScene::onTouchBegan(Touch* touch, Event* event) { auto pos touch-getLocation(); auto boardOrigin boardSprite-getPosition(); Size cellSize boardSprite-getContentSize() / GRID_COUNT; // 锚点居中时origin 是左下角坐标所以要减去一半棋盘尺寸 int col (pos.x - boardOrigin.x cellSize.width / 2) / cellSize.width; int row (pos.y - boardOrigin.y cellSize.height / 2) / cellSize.height; if (row 0 || row GRID_COUNT || col 0 || col GRID_COUNT) { return false; } selectedStart {row, col}; return true; }逻辑说明换算的关键是锚点。boardSprite 是整个棋盘的容器节点位置是它的锚点所在处。如果锚点设为(0.5, 0.5)origin 底部值要用“中心坐标减半棋盘尺寸”得出如果锚点是(0, 0)直接用 getPosition 当 origin 就行。这套源码里用的是锚点居中所以公式里加了半格偏移把触摸点归到最近的格子中心。参数说明cellSize 是格子尺寸用棋盘精灵的 contentSize 除以 GRID_COUNT 得到。触摸点到格子中心的偏差超过半格时会被归到相邻格子这个“判定阈值”直接决定手感。玩家反映“点了没反应”时优先检查返回 false 的范围判断反映“总是点偏一格”时优先检查半格偏移的正负号。3.2 滑动方向判定与交换动画时序分清楚意图和抖动cocos2d-x 触摸系统里玩家按住、滑动、松手通常用 onTouchMoved 持续收到 move 事件。这里不能每个事件都触发交换否则手稍微一抖就会反复交换同一对糖果。标准做法是记录触摸开始点位移超过一个阈值后才认为是一次滑动意图再执行交换。void GameScene::onTouchMoved(Touch* touch, Event* event) { auto delta touch-getDelta(); accumulatedDistance sqrt(delta.x * delta.x delta.y * delta.y); // 位移不足一格宽度的三分之一忽略这次移动 if (accumulatedDistance SWIPE_THRESHOLD) { return; } accumulatedDistance 0.0f; auto startPos convertToBoardCoord(touchStartPos); auto curPos convertToBoardCoord(touch-getLocation()); int dr curPos.row - startPos.row; int dc curPos.col - startPos.col; // 只处理位移最大的方向防止斜滑同时触发两个方向 if (abs(dr) abs(dc)) { performSwap(startPos.row, startPos.col, startPos.row (dr 0 ? 1 : -1), startPos.col); } else if (abs(dc) 0) { performSwap(startPos.row, startPos.col, startPos.row, startPos.col (dc 0 ? 1 : -1)); } }逻辑说明accumulatedDistance累计的是每次 move 事件的位移量超过阈值才响应把“滑动意图”和“触摸抖动”区分开。方向判定里abs(dr) 与 abs(dc) 谁大就往哪个方向交换避免斜向滑动同时触发两个方向的歧义。convertToBoardCoord内部就是 3.1 里的换算公式触摸结束点不一定回到开始点的格子所以这里用当前坐标重新计算一次行列。参数说明SWIPE_THRESHOLD 一般设为一格宽的三分之一到二分之一。格子 80 像素时阈值 30 像素左右比较合适偏小会频繁误触发偏大则玩家划完整格都没反应。若反馈“划得很用力但就是不换”优先调小阈值若“不想换却换了”优先调大阈值。3.3 交换、消除、下落动画的时序编排先给反馈再算结果数据层交换之后视觉层要做三个动画失败的交换要换回去成功的消除要给一个渐隐缩小的反馈落下的糖果要移动到新位置。cocos2d-x 里处理这种序列动画的惯用方式是Sequence MoveTo CallFunc回调嵌在动画结束点上保证下一步逻辑启动时画面已经就位。void GameScene::performSwap(int r1, int c1, int r2, int c2) { board-swap(r1, c1, r2, c2); auto sprite1 candySprites[r1][c1]; auto sprite2 candySprites[r2][c2]; auto target1 sprite2-getPosition(); auto target2 sprite1-getPosition(); auto seq1 Sequence::create( MoveTo::create(0.15f, target1), CallFunc::create([this, r1, c1, r2, c2]() { onSwapAnimationDone(r1, c1, r2, c2); }), nullptr ); sprite1-runAction(seq1); sprite2-runAction(MoveTo::create(0.15f, target2)); }逻辑说明两个精灵同时执行 MoveTo动画时长必须一致一只先到、另一只后到会产生明显的卡顿感。回调只绑在 sprite1 上保证数据层下一轮检测启动前两个精灵都已经到位。cocos2d-x 里没有“等待两段动画都结束”的原生 API常见做法是用 DelayTime 兜底但更稳妥的还是把回调绑在时长相同的那一个上用一套时长值控制两端。参数说明0.15f 是交换动画时长单位秒。追求“爽快”手感可以用 0.1想突出“糖果软弹”质感可以在 MoveTo 之外再加一个 ScaleTo 动画先放大到 1.05 再缩回 1.0。这套源码做了取舍没有加弹性缩放保持动画逻辑轻量消除和下落两个阶段用不同时长来制造节奏差。消除动画和下落动画的编排遵循同样的模式消除阶段对标记过的糖果精灵做 FadeOut 加 ScaleTo动画结束后立刻把对应位置的引用置空下落阶段对每个有位移的精灵做 MoveTo时长按位移距离等比计算保证下落速度恒定而不是简单用固定时间。void GameScene::playClearAnimation(std::vectorstd::pairint,int cleared) { for (auto pos : cleared) { auto sprite candySprites[pos.first][pos.second]; auto seq Sequence::create( Spawn::create(ScaleTo::create(0.2f, 0.1f), FadeOut::create(0.2f), nullptr), CallFunc::create([this, pos]() { candySprites[pos.first][pos.second] nullptr; }), nullptr ); sprite-runAction(seq); } }逻辑说明Spawn 让 ScaleTo 和 FadeOut 同时开始同时结束消除质感是“糖果一边缩小一边变透明”比先后执行更干脆。这里最容易被忽略的是动画结束后的引用置空。如果不置空后续刷新棋盘时会继续操作已失效的节点轻则报空指针重则在低端机上直接崩。这个习惯应该在写第一版时就养好不要等出问题了再补。参数说明FadeOut 时长如果长于 ScaleTo糖果会先缩到很小、再渐渐透明观感像“化掉”反过来则像“闪没”。0.2f 是两个时长相同的平衡点。平板这类大屏设备上建议按格子实际尺寸等比拉长到 0.250.3f否则大格子上动画会显得太快。3.4 特殊糖果生成与作用范围四连、五连和 L/T 形消除四连、五连在匹配检测阶段就能识别。四连生成直线消除糖果消除整行或整列五连生成彩色糖果可与任意颜色配对触发全局消除L 形、T 形匹配生成炸弹型糖果。识别方式很直接在 findMatches 结果里统计每一行每一列的连续长度等于 4 生成直线等于 5 生成彩色等于 3 的 L 形或 T 形组合生成十字炸弹。void GameScene::spawnSpecialCandy(int r, int c, SpecialType type) { auto sprite Sprite::create(special_candy.png); sprite-setTag(type); sprite-setPosition(getPositionForCell(r, c)); candySprites[r][c] sprite; addChild(sprite); // 用脉冲动画提示玩家这个糖果不普通 auto pulse RepeatForever::create(Sequence::create( ScaleTo::create(0.4f, 1.15f), ScaleTo::create(0.4f, 0.95f), nullptr )); sprite-runAction(pulse); }逻辑说明特殊糖果生成后在视觉上必须和普通糖果有明显区别。常见做法是换一套贴图资源再叠加一个脉冲动画。这块代码里 SpecialType 通过 Tag 存在精灵节点上后续作用范围判定直接读 Tag。Tag 是整型为避免与引擎内部节点 Tag 冲突建议从 1000 开始分配别用 1、2、3 这种容易撞的值。作用范围的实现可以统一用“范围计算器”来做直线糖果消除整行或整列十字炸弹消除触发点为中心的区域彩色糖果消除当前棋盘上所有同色糖果。范围计算和消除动作分开方便复用和测试。std::vectorstd::pairint,int GameScene::getSpecialEffectRange(SpecialType type, int r, int c) { std::vectorstd::pairint,int range; switch (type) { case SpecialRowClear: // 整行消除 for (int cc 0; cc GRID_COUNT; cc) range.push_back({r, cc}); break; case SpecialColClear: // 整列消除 for (int rr 0; rr GRID_COUNT; rr) range.push_back({rr, c}); break; case SpecialBomb5x5: // 以触点为中心的 5×5 范围 for (int dr -2; dr 2; dr) { for (int dc -2; dc 2; dc) { int nr r dr; int nc c dc; if (nr 0 nr GRID_COUNT nc 0 nc GRID_COUNT) { range.push_back({nr, nc}); } } } break; default: break; } return range; }逻辑说明这个函数只做范围计算不做实际消除职责分离让它可以独立复用。消除动作统一走 clearMarked 那条链取值超界时直接过滤掉避免数组越界。直线消除整行会让该行所有格子瞬间清空下落补位后视觉上会出现“横穿一排空洞”的观感某些变体玩法因此只消除该行连续段所在的整行而不是跨列整行具体取舍看节奏设计。参数说明5×5 炸弹范围是常见设定半径 2 格就是 5×5半径 3 格就是 7×7。范围越大连锁概率越高分数也越高。8×8 棋盘上 5×5 已经很大再往上很容易直接把整局打破新关卡设计时尽量从 3×3 起步测试。4. 避坑排查从坐标翻车到连锁崩溃六条血泪经验这一章专门记录我在拆这套源码和复刻三消玩法时踩过的坑。这些坑可以归成数据层、节点层、适配层三类数据层的坑表现为逻辑错乱靠打印日志最直接节点层的坑表现为渲染异常或内存异常靠看节点树最直接适配层的坑最隐蔽通常只在真机上暴露。下面六条都是我回滚过、重写过、在测试机上复现过的真实问题。4.1 现象点击糖果没反应但触摸回调明明触发了排查时监听 onTouchBegan发现 return true 了但点击位置总是偏一格。用日志输出转化后的行列号对比实际点击的糖果位置发现行列数总差一行或一列。原因出在锚点棋盘精灵锚点是 (0,0) 时可以直接用 getPosition 当 origin但代码里把精灵设成了锚点 (0.5,0.5)origin 用的却是“锚点 (0,0) 时才有意义”的值。坐标系一偏所有行列换算全盘偏移。解决把精灵锚点与坐标换算逻辑对齐。要么统一锚点 (0,0)用 getPosition 直接做 origin要么锚点居中用getPosition() - boardSize / 2换算。从那以后我创建棋盘节点时都会写注释注明锚点约定换算函数入口加断言origin getPosition() - boardSize / 2一旦有人改了锚点调试期立刻暴露。4.2 现象消除后棋盘上残留半透明糖果残影视觉上消除动画执行了但糖果精灵没有真正销毁或者残影在新棋盘上还能看到。原因有两个一个是回调里只把动画跑完没把精灵从父节点移除节点还挂在场景树里另一个是精灵引用没置空后续刷新棋盘时旧引用被新精灵覆盖旧节点没人管就成了残留。解决在消除动画的 CallFunc 回调里节点执行removeFromParent()并把 candySprites 对应位置置空。这一步不能省残留节点不单是视觉问题还会参与触摸检测——点击到已消除的位置会触发意外的交换。排查时可以用引擎的节点树调试功能把所有还挂着糖果纹理的节点列出来看父节点和时间戳。4.3 现象棋盘数据被交换操作搞乱出现“凭空多出的糖果”数据层 swap 之后如果玩家操作的是不相邻的格子手势划歪了数据层没做相邻性校验就会强行交换两块不相邻的糖果画面出现错乱。排查后发现 swap 调用前确实没有检查abs(r1-r2) abs(c1-c2) 1。解决在 performSwap 入口加上相邻性判断不相邻直接 return false不触发动画和数据变更。另外滑动结束时触摸点可能落在棋盘外也要在 touchEnd 时做范围过滤。这个校验看似多余实则是防手滑误触的最后一道闸。4.4 现象下落补位后棋盘出现大小不一的空洞或顶部糖果堆叠到棋盘外下落的实现没有处理列内连续空格的移动只是简单把非空糖果往下搬结果一列里存在两个连续空格时第二个空格没有被后续糖果补上。本质是 applyGravity 遍历顺序写反了——从上往下搬会把上方的空格“搬下去”正确方向是自底向上扫描。解决严格按 2.3 里的 applyGravity 写法底部向上扫描。这个方向的本质区别在于从底部找第一个可写入的空位作为落点而不是从顶部找空格去填。后来我把这个函数写成独立单测输入一个中间有空洞的列断言落点顺序每次改动前先跑一遍基本没有再犯过。void testGravity() { // 构造一列[空, 红, 空, 蓝] // 期望下落结果[空, 空, 红, 蓝] BoardData board(1, 4); board.setCell(0, 0, CandyNone); board.setCell(0, 1, CandyRed); board.setCell(0, 2, CandyNone); board.setCell(0, 3, CandyBlue); board.applyGravity(); assert(board.getCell(0, 0) CandyNone); assert(board.getCell(0, 1) CandyNone); assert(board.getCell(0, 2) CandyRed); assert(board.getCell(0, 3) CandyBlue); }逻辑说明这个测试覆盖了单列双空洞的场景是最容易出问题的输入。一个空格的列大概率不会写错连续两个空格才是分水岭。自底向上实现通过 writeRow 指针保证每个非空糖果都能落到该列最下面的空位。4.5 现象连锁消除执行到一半程序直接崩溃连锁过程里第一次消除触发下落下落后的新布局又产生三连于是递归或循环调用。如果实现用的是递归函数而不是循环连锁 5 次以上时调用栈会爆掉。崩溃日志里能看到 resolveChain 反复压栈直到栈溢出有的版本还会表现为连锁次数突然卡住不动那是死循环而非爆栈。解决把递归改为 while 循环或用队列保存待处理的消除集合每轮循环处理一个集合。这套源码里用的是 while 循环方案链越深越安全。同时要检查循环退出条件是否包含“本次无匹配”判断——如果糖果类型种类数设置太少棋盘上始终存在三连循环永远不会退出那就是死循环。4.6 现象不同分辨率下列表和棋盘对齐错位按钮文字显示不全cocos2d-x 老项目的适配方案五花八门固定分辨率加 letterbox 的、按比例直接缩放的都有。按固定分辨率设计的源码在宽屏机型上棋盘会被裁掉一部分或整体偏到边上。排查时先看 DesignResolutionSize 设了什么值再看 Resize 策略是 FixedHeight 还是 FixedWidth。真机上比模拟器更明显模拟器宽高比固定真机刘海屏、挖孔屏差异很大。解决统一用 FixedHeight 加合理宽边距的方案。棋盘居中放四周留出固定间隙小屏上间隙会被压缩但棋盘不裁切。如果项目还依赖旧版的自适应缩放接口迁移到 3.x 后要重新写适配层不要直接沿用老代码。另有一个容易忽略的点按钮和分数标签的定位要用相对百分比或相对棋盘位置不要写死绝对坐标否则换一台设备按钮就可能跑到屏外。5. 进阶从硬编码棋盘到关卡数据驱动5.1 用 JSON 描述一关的目标和步数玩法逻辑跑通后值得做的是把每关的目标步数、目标分数、目标消除量、棋盘尺寸和特殊障碍从代码里抽出来。常见做法是用 JSON 描述关卡cocos2d-x 项目里 JSON 解析库多且稳定。一个典型的关卡配置长这样{ levelId: 1, boardRows: 8, boardCols: 8, targetScore: 8000, moveLimit: 15, candyTypes: 6, startingPattern: normal, obstacles: [ { type: jelly, count: 6, dropWeight: 0.1 }, { type: ice, count: 4, dropWeight: 0.05 } ], comboScoreBase: 50, comboMultiplier: 2 }逻辑说明这套资源原本把棋盘尺寸和糖果类型数量写死在代码里我后来把全部字段抽到 JSON每关加一个配置文件不动编译逻辑。目标分数、移动步数和障碍物配置是最常用的三个字段前两个控制难度第三个开始引入“消除受限格子”的玩法层次。dropWeight 是生成时投放障碍物的权重0.1 表示大约每 10 个新糖果会产出 1 个被障碍覆盖的格子。参数说明moveLimit 在 1525 之间是休闲关卡区间偏低会让玩家频繁失败偏高则失去挑战性。candyTypes 影响匹配概率5 和 6 是常见值。targetScore 要和 comboScoreBase、comboMultiplier 联调先跑一局脚本看实际得分的分布再定目标值不要拍脑袋。5.2 验证一关能不能通调试开关做成菜单项数据驱动让关卡数量快速扩充同时带来新风险怎样验证一个关卡是可解的完全依赖人工试玩费时费力至少可以做两个自动化检查第一步用无界步数自动按规则打出一个最高分确认分数能超过 targetScore第二步限制步数回放同一策略看是否仍有解。后者是搜索算法的活前者已经能筛掉大部分设计过难的关卡。我一般会在 Debug 构建里加一个 Automation 模式用脚本控制 BoardLayer 的 executeResolveChain 无限次调用同时打印最高分和剩余步数。这一步不做进日常发布包只在关卡测试时打开。配置文件的合法性检查也在加载阶段做掉——字段缺失、步数为负数、障碍物总数超过棋盘格数都直接报错不让错误藏到运行时。一个值得养成的习惯是每次增加新关卡字段先写一份最小可用的 JSON跑一局看数据层行为再逐步加入障碍物等复杂字段。数据驱动的玩法最容易翻车的不是算法本身而是配置字段的疏漏——漏一个字段运行时表现出的问题往往又怪又隐蔽单靠试玩很难定位到是配置的问题。话说回来我从做这套三消源码的复刻以后每写一次消除逻辑都会强制走一遍“数据层单元测试、动画回调置空、坐标锚点约定”这三件事。这三件事分别对应找匹配、清节点、定坐标是三消玩法最容易翻车的三个位置。希望这篇拆解能帮你在拿到源码后少走几步弯路。本文还有配套的精品资源点击获取