Cocos Creator游戏开发实战：碰撞检测与状态管理实现合成大西瓜

1. 项目概述与核心价值

上次我们聊完了“合成大西瓜”案例的前半部分，主要搭建了基础场景、实现了水果的生成与物理下落。今天这后半部分，才是真正让游戏“活”起来的关键。如果说前半部分是搭好了舞台和道具，那后半部分就是编写剧本、设计互动，让玩家能真正玩起来。核心就两件事：碰撞合成逻辑与游戏状态管理。听起来简单，但里面藏着不少决定游戏手感和成败的细节。比如，两个葡萄碰到一起，怎么精准判断并变成一个樱桃？水果堆叠时，新水果的生成位置怎么定才自然？游戏失败的条件是顶线还是时间？这些处理不好，游戏要么合成起来“卡顿”不流畅，要么判定诡异让玩家骂街。

这个案例之所以经典，是因为它几乎涵盖了休闲小游戏所有核心模块：物体交互、状态转换、分数计算、界面反馈。无论你是想用Cocos Creator做微信小游戏、抖音小游戏，还是简单的H5，这套逻辑都是相通的。通过拆解它，你不仅能学会如何实现一个具体玩法，更能掌握一套设计可扩展游戏系统的思路。接下来，我们就深入代码层，看看怎么把这些想法变成屏幕上流畅运行的互动。

2. 碰撞检测与合成逻辑的实现

碰撞合成是整个游戏的灵魂，它直接决定了游戏的核心体验是流畅爽快还是别扭难受。在Cocos Creator中，我们通常使用物理引擎的碰撞组件来实现。

2.1 碰撞组件的精细配置

首先，不是所有物体都需要参与合成碰撞。比如，地面和墙壁（边界）只需要提供物理碰撞，让水果不会掉出屏幕，但它们本身不应该触发合成事件。这就需要用到碰撞分组（Group）。

在项目设置 -> 物理 -> 碰撞矩阵中，我会进行如下配置：

1. 创建分组：通常我会创建至少三个分组：FRUIT（水果）、WALL（边界墙壁）、DEFAULT（默认，给地面等用）。
2. 设置碰撞矩阵：只勾选FRUIT与FRUIT之间的碰撞。这意味着水果只会和水果发生物理碰撞并触发回调，而水果与墙壁、地面之间只有物理碰撞效果（阻挡），不会触发我们的业务逻辑回调。这一步非常重要，能大幅减少不必要的函数调用，提升性能。

// Fruit.ts - 在水果预制体的根节点上挂载此脚本 import { _decorator, Component, Collider2D, IPhysics2DContact, Node } from 'cc'; const { ccclass, property } = _decorator; @ccclass('Fruit') export class Fruit extends Component { // 水果等级，例如：1-葡萄，2-樱桃，3-橘子... @property level: number = 1; // 是否正在参与合成（防止重复触发） private _isMerging: boolean = false; start() { // 获取碰撞组件并监听回调 const collider = this.getComponent(Collider2D); if (collider) { collider.on('begin-contact', this.onBeginContact, this); } } onBeginContact(selfCollider: Collider2D, otherCollider: Collider2D) { // 关键判断：如果自己正在合成中，直接返回，避免一帧内多次触发 if (this._isMerging) { return; } const otherFruit = otherCollider.node.getComponent('Fruit'); // 确认碰撞对方也是水果组件，且等级相同 if (otherFruit && otherFruit.level === this.level) { // 再次验证：对方也不在合成状态（防止双向触发） if (!otherFruit._isMerging) { this._isMerging = true; otherFruit._isMerging = true; // 触发合成事件，通常由游戏管理器统一处理 this.node.emit('fruit-merge', this.node, otherCollider.node, this.level); } } } }

注意：这里我用了on('begin-contact')而不是on('collision-enter')。在Cocos Creator的2D物理中，begin-contact是物理引擎内部更精确的碰撞开始回调，对于快速连续碰撞的场景比collision-enter更稳定。这是很多新手容易忽略的性能和稳定性细节。

2.2 合成事件的处理与水果生成

当两个相同水果碰撞后，我们发射了一个fruit-merge事件。游戏管理器（比如GameManager.ts）需要监听并处理它。

处理的核心逻辑包括：

1. 计算合成位置：通常取两个水果节点的中心点。但直接取平均可能会让新水果出现在奇怪的位置。我的经验是，取质量更大（或后碰撞的）的水果位置作为基准更自然，或者取两者连线的中点，并做一个轻微随机偏移，避免水果永远生成在一条直线上。
2. 销毁旧水果：立即将两个旧水果节点从场景中销毁（destroy）。但这里有个坑：直接销毁可能导致物理引擎这一帧还没处理完，引发内部错误。稳妥的做法是先将它们的碰撞器禁用（collider.enabled = false），然后延迟一帧再销毁，或者使用scheduleOnce在下一帧执行销毁。
3. 创建新水果：根据当前等级，从预设的水果预制体资源池中取出下一个等级的水果。强烈建议使用节点池（NodePool），而不是每次instantiate。合成大西瓜过程中会产生大量水果对象的创建和销毁，节点池能极大减少GC（垃圾回收）压力，避免游戏玩到后面越来越卡。

// GameManager.ts - 部分代码 import { _decorator, Component, NodePool, Prefab, instantiate, Vec3 } from 'cc'; const { ccclass, property } = _decorator; @ccclass('GameManager') export class GameManager extends Component { // 水果预制体数组，索引对应等级 @property([Prefab]) fruitPrefabs: Prefab[] = []; // 节点池字典，以等级为key private _fruitPools: Map<number, NodePool> = new Map(); start() { // 初始化节点池 for (let i = 0; i < this.fruitPrefabs.length; i++) { this._fruitPools.set(i + 1, new NodePool('Fruit')); } // 监听合成事件 this.node.on('fruit-merge', this.onFruitMerge, this); } onFruitMerge(fruitA: Node, fruitB: Node, level: number) { // 1. 计算新位置（取A的位置，并加一点随机偏移） const pos = fruitA.worldPosition.clone(); pos.x += (Math.random() - 0.5) * 10; // 10像素内的随机偏移 pos.y += 5; // 稍微向上一点，模拟“合成弹跳”的感觉 // 2. 异步销毁旧水果（禁用碰撞器后延迟销毁） this.scheduleOnce(() => { fruitA.destroy(); fruitB.destroy(); }, 0); // 3. 从池中获取或创建新水果 const nextLevel = level + 1; let newFruitNode: Node | null = null; const pool = this._fruitPools.get(nextLevel); if (pool && pool.size() > 0) { newFruitNode = pool.get(); } else { if (this.fruitPrefabs.length >= nextLevel) { newFruitNode = instantiate(this.fruitPrefabs[nextLevel - 1]); } } if (newFruitNode) { newFruitNode.setWorldPosition(pos); this.node.addChild(newFruitNode); // 可以在这里给新水果一个初始向上的小速度，增强合成反馈 const rigidBody = newFruitNode.getComponent(RigidBody2D); if (rigidBody) { rigidBody.linearVelocity = new Vec2(0, 300); } } // 4. 增加分数 this.addScore(level * 10); // 分数可以根据等级设计 } }

实操心得：合成瞬间的视觉和听觉反馈至关重要。除了生成新水果，一定要同时播放一个合并音效，并在两个旧水果位置播放一个简单的粒子特效（如星星爆炸）。这小小的投入，对游戏爽快感的提升是巨大的。粒子可以用Cocos自带的粒子组件做，也可以用一个缩放+渐隐的动画序列代替。

3. 游戏状态与流程管理

一个完整的游戏需要明确的状态机来管理不同阶段的行为，比如“准备中”、“进行中”、“暂停”、“结束”。对于合成大西瓜，状态可以简化为PLAYING和GAME_OVER。

3.1 失败条件判定：顶线检测

最常见的失败条件是下一个水果生成时，已有水果堆叠高度超过了屏幕顶部的一条“警戒线”。如何检测？

方法一：实时遍历计算每一帧（或每次新水果生成前），遍历所有水果节点，找出Y坐标最大的一个，判断其顶部是否超过顶线。这种方法逻辑简单，但水果多了以后每帧遍历所有节点，比较耗性能。

方法二：触发区域检测在顶线位置放置一个不可见的矩形碰撞体（BoxCollider2D），将其分组设为SENSOR（传感器）。当任何水果（FRUIT分组）与该传感器发生碰撞时，即判定为游戏结束。这是更高效、更符合物理引擎思维的做法。

我推荐方法二。具体实现如下：

1. 在场景中顶线位置创建一个空节点，挂载Sprite组件（设为透明）和BoxCollider2D组件。
2. 在Collider2D组件中，勾选Sensor。传感器不会产生物理碰撞效果，但会触发碰撞回调。
3. 将该节点的碰撞分组设为SENSOR，并在碰撞矩阵中设置SENSOR与FRUIT可以触发回调。
4. 在该节点上挂载一个脚本，监听begin-contact事件，一旦触发，就通知GameManager游戏结束。

// TopLineSensor.ts import { _decorator, Component, Collider2D, IPhysics2DContact } from 'cc'; const { ccclass, property } = _decorator; @ccclass('TopLineSensor') export class TopLineSensor extends Component { start() { const collider = this.getComponent(Collider2D); if (collider) { collider.on('begin-contact', this.onTouchTopLine, this); } } onTouchTopLine(selfCollider: Collider2D, otherCollider: Collider2D) { // 通知游戏管理器 this.node.emit('game-over'); // 也可以在这里做一些效果，比如红线闪烁 } }

在GameManager中监听game-over事件，切换到游戏结束状态，弹出结算界面。

3.2 分数、连击与数据持久化

分数计算：合成大西瓜的分数增长通常是非线性的，合成越高等级的水果，得分越高。可以设计一个指数增长的公式，比如基础分 * (等级^2)。每次合成成功时累加。

连击系统：为了增加刺激感，可以加入连击（Combo）。在短时间内连续合成，连击数递增，获得的分数有倍数加成。实现需要一个计时器，记录最后一次合成的时间。如果下一次合成在设定的时间窗口内（比如2秒），则连击数+1，分数乘以连击系数。如果超时，连击数重置为1。

// GameManager.ts - 连击相关片段 private _combo: number = 1; private _lastMergeTime: number = 0; private readonly COMBO_TIME_WINDOW: number = 2.0; // 连击时间窗口2秒 onFruitMerge(fruitA: Node, fruitB: Node, level: number) { const currentTime = Date.now() / 1000; // 当前时间（秒） // 判断连击 if (currentTime - this._lastMergeTime < this.COMBO_TIME_WINDOW) { this._combo++; // 播放连击增加的特效或音效 } else { this._combo = 1; } this._lastMergeTime = currentTime; // 计算分数（基础分 * 等级平方 * 连击系数） const baseScore = 10; const scoreToAdd = baseScore * (level * level) * this._combo; this.addScore(scoreToAdd); // ... 其余合成逻辑 }

数据持久化：对于小游戏，通常需要保存最高分（localStorage）。在游戏结束时，比较当前得分与历史最高分，如果更高则更新并保存。也可以在游戏主界面显示历史最高分。

// 保存最高分 saveHighScore(score: number): void { const oldScore = this.getHighScore(); if (score > oldScore) { // 使用平台提供的存储API，或直接使用cc.sys.localStorage if (cc.sys.localStorage) { cc.sys.localStorage.setItem('HIGH_SCORE', score.toString()); } // 如果是微信小游戏环境，则使用 wx.setStorageSync // @ts-ignore if (typeof wx !== 'undefined' && wx.setStorageSync) { // @ts-ignore wx.setStorageSync('HIGH_SCORE', score); } } } getHighScore(): number { // 同理，从相应平台读取 let score = 0; if (cc.sys.localStorage) { score = parseInt(cc.sys.localStorage.getItem('HIGH_SCORE')) || 0; } // @ts-ignore if (typeof wx !== 'undefined' && wx.getStorageSync) { // @ts-ignore score = wx.getStorageSync('HIGH_SCORE') || 0; } return score; }

注意事项：不同平台（Web、微信小游戏、抖音小游戏）的存储API可能不同。为了代码的兼容性，最好做一层封装或条件判断。另外，存储敏感数据（如用户ID）时，需要了解并遵守各平台的隐私政策。

4. 性能优化与调试技巧

当水果数量增多，物理计算和渲染压力会变大。以下是一些针对性的优化手段。

4.1 节点池与对象复用

前面提到了节点池，这里再强调其重要性。对于频繁创建和销毁的对象（水果、特效粒子），必须使用节点池。创建池时，建议根据游戏难度预估一个初始大小，避免一开局就频繁扩容。

// 扩展GameManager中的池初始化 initFruitPools() { for (let i = 0; i < this.fruitPrefabs.length; i++) { const level = i + 1; const pool = new NodePool('Fruit'); const initCount = this.getInitPoolCountByLevel(level); // 根据等级决定初始数量 for (let j = 0; j < initCount; j++) { const node = instantiate(this.fruitPrefabs[i]); pool.put(node); } this._fruitPools.set(level, pool); } }

4.2 物理引擎优化

1. 使用固定时间步长：在项目设置的物理模块中，建议使用固定时间步长（Fixed Timestep），比如1/60，这能使物理模拟更稳定，避免帧率波动导致物理行为异常。
2. 简化碰撞体：对于圆形水果，使用CircleCollider2D比PolygonCollider2D性能更好。如果水果形状不规则，尽量用多个简单碰撞体（圆、矩形）组合来近似，而不是一个复杂的多边形。
3. 休眠（Sleeping）：确保物理刚体启用了休眠。当物体速度几乎为零并持续一段时间后，物理引擎会将其置为“休眠”状态，不再计算其运动，直到它被再次唤醒。这能极大减少静止堆叠水果的计算开销。在Cocos Creator中，RigidBody2D组件默认是开启休眠的。

4.3 渲染优化

1. 合批（Batching）：确保水果精灵（Sprite）使用的纹理在同一张图集（Atlas）中。Cocos Creator会自动对使用相同材质的静态精灵进行合批，减少Draw Call。动态物体（如正在下落的水果）合批条件苛刻，但保证纹理集统一总是好的。
2. 减少Overdraw：虽然合成大西瓜场景不复杂，但也要注意避免不必要的全屏覆盖层。UI界面尽量使用裁剪节点（Mask）或九宫格拉伸，而不是巨大的单色精灵。
3. 特效管理：合成特效粒子播放完毕后，要及时将其回收到对象池，而不是放任其自行销毁。

4.4 调试与问题排查

开发过程中，你肯定会遇到各种奇怪的问题。分享几个我常用的调试技巧：

1. 物理调试绘制：在Cocos Creator编辑器的场景面板中，点击“调试”->“物理调试”，可以显示所有碰撞体的轮廓和刚体质心。这对于检查碰撞体位置、大小是否正确非常直观。
2. 使用console.log的时机：在碰撞回调、合成函数开始处加入带条件的console.log，可以帮你理清逻辑流程。但记得在发布前移除或禁用它们。
3. 性能分析器（Profiler）：Cocos Creator内置的性能分析器是神器。在游戏运行时打开它（编辑器 -> 项目 -> 性能分析器），重点关注：
   • CPU：查看脚本、物理、渲染的耗时。如果物理耗时突然飙升，检查是否同时激活了大量刚体。
   • 内存：查看节点数、纹理内存。如果节点数只增不减，很可能对象池没起作用导致内存泄漏。
   • Draw Call：确认Draw Call数量是否在合理范围。一个简单的2D游戏，Draw Call最好控制在几十以内。
4. 常见问题速查表：

5. 构建发布与平台适配

完成开发后，最后一步是打包发布到目标平台。不同平台有各自的配置和要求。

5.1 通用构建优化

在构建发布面板中，有几个关键设置：

1. 合并图集（Auto Atlas）：勾选此选项，Cocos Creator会自动将散图打包成图集，这是降低Draw Call最有效的手段之一。可以设置图集最大尺寸（如2048x2048）。
2. MD5 Cache：给资源文件名加上MD5戳，有利于浏览器缓存。发布Web或小游戏时建议开启。
3. 压缩纹理：根据目标平台选择纹理压缩格式（如Web平台用PVRTC、ETC等）。这能显著减少包体和内存占用，但需要测试显示效果。
4. 引擎裁剪：如果项目确定只用到了2D物理，可以在“功能裁剪”中勾掉3D物理、3D粒子等未用模块，能减小引擎核心包大小。

5.2 微信/抖音小游戏适配

1. 主域与开放数据域：如果游戏有排行榜（需要展示好友数据），必须使用开放数据域。这是一个独立的、隔离的JavaScript环境，用于安全地处理敏感数据。主域游戏与开放数据域通过postMessage通信。这是小游戏开发特有的概念，需要仔细阅读官方文档来搭建。
2. 文件系统：小游戏环境没有传统的FileAPI，资源加载需使用wx.getFileSystemManager()或平台提供的相关API。Cocos Creator构建时已经帮我们处理了大部分，但如果有自定义的本地配置文件读取需求，需要注意。
3. 启动性能：小游戏对首包大小有严格限制（如微信小游戏4M）。除了引擎裁剪和资源压缩，还可以考虑使用资源分包，将非必要的场景或资源放在分包中，运行时动态加载。
4. 登录与授权：调用wx.login()和wx.getUserProfile()获取用户信息。注意用户头像和昵称的展示规范，需要用户授权。

5.3 真机调试与问题定位

编辑器里运行流畅，真机上可能卡成幻灯片。真机调试必不可少。

1. 微信开发者工具：可以模拟小游戏环境，并提供了性能面板、调试器等。但注意，其性能表现与真机仍有差异，真机测试才是金标准。
2. VConsole：在代码中引入vConsole库，可以在手机屏幕上唤起一个控制台，查看console.log信息，对于排查真机上的逻辑错误非常有用。
3. 内存与性能监控：在微信开发者工具的“性能”面板，或使用wx.getPerformance()API，可以监控真机的内存、帧率等。重点关注内存是否持续增长（内存泄漏），以及帧率是否稳定在60fps左右。

踩坑实录：有一次我的游戏在安卓机上很卡，但在iOS和模拟器上很流畅。用性能分析器发现是某个粒子特效的capacity设置过大，每一帧都在更新上百个不显示的粒子。在真机上，尤其是中低端安卓机，GPU填充率是瓶颈，过量的粒子计算和Overdraw会直接拖垮帧率。解决方案是严格控制粒子数量，并确保粒子在不可见时停止发射。这个教训告诉我，性能优化必须有真机数据支撑，不能只看编辑器。

6. 总结与扩展思路

走到这里，一个具备完整玩法的“合成大西瓜”游戏核心就已经实现了。从场景搭建、物理交互、碰撞合成、状态管理到性能优化，我们走完了一个典型休闲小游戏开发的全流程。回顾一下，最关键的技术点其实就几个：物理碰撞与分组管理、基于事件驱动的合成逻辑、节点池对象复用以及面向平台的数据与发布管理。掌握这些，你就能应对大部分同类型游戏的开发。

这个案例的代码和设计模式具有很强的扩展性。比如，你可以很容易地把它改造成“合成大蟠桃”、“合成大南瓜”，只需要换一套美术资源。你还可以增加更多玩法：

• 特殊水果：添加一个“炸弹”水果，合成后消除周围一定范围内的其他水果。
• 道具系统：下一块预览、指定消除、瞬间下落等。
• 关卡目标：不再是无限玩，而是要求在规定步数内合成出指定等级的水果。
• 多人竞技：实时或异步的PK模式，看谁先合成出大西瓜。

游戏开发，尤其是小游戏，三分在技术，七分在设计和调优。手感、节奏、数值（分数、合成概率）需要反复测试和调整。我建议你先把基础版本跑通，然后找几个朋友试玩，收集他们的第一手反馈：哪里卡住了？哪里觉得不爽？合成反馈够不够明显？这些来自真实玩家的意见，比你自己埋头苦调要宝贵得多。

最后，关于Cocos Creator 3.x，虽然我们这个案例是基于2D的，但3.x版本对2D的支持已经非常完善，且带来了更好的编辑器体验和性能。如果你是从2.4.x版本迁移过来，需要注意一些API的变化（比如节点位置从position改为setPosition），但核心思路是完全一致的。拥抱变化，持续学习，才是我们开发者该有的状态。希望这个系列能帮你打开Cocos小游戏开发的大门，剩下的，就靠你的创意和代码去实现了。