1. 项目概述从“玩”到“懂”的跨越上次我们动手把“合成大西瓜”的架子搭了起来让水果能掉、能碰、能合成游戏算是能跑了。但不知道你有没有这种感觉代码是跑通了可心里还是有点虚总觉得只是照猫画虎里面的门道并没摸清。比如为什么物理碰撞的代码要那么写cc.Node和cc.Component到底啥关系事件监听绑来绑去到底谁在监听谁如果我想加个新功能比如让西瓜合成时有爆炸特效该从哪儿下手这就是我们这次要解决的核心问题。光把游戏做出来不算完我们得把它“拆开”看看每个零件是怎么运转的。Cocos Creator 的强大很大程度上就体现在它这套基于组件的架构上。你把一个复杂的游戏看成是由一个个功能单一、可以拼装的“组件”构成的开发思路瞬间就清晰了。今天我们就聚焦在“合成大西瓜”这个案例里把几个关键组件——物理碰撞、用户输入、动画状态管理——的原理掰开揉碎了讲。目标不是让你记住 API而是理解其设计思想以后无论遇到什么需求你都能自己设计出合适的组件来应对。2. 核心组件原理深度拆解2.1 物理与碰撞组件不只是“碰一下”在“合成大西瓜”里水果下落、相互堆叠、碰撞后合成这一切的基础都是物理引擎。Cocos Creator 内置了两种物理系统基于 Box2D 的物理系统和基于 Cannon.js 的物理系统。对于我们的 2D 游戏默认且最常用的就是 Box2D。2.1.1 RigidBody 与 Collider 的职责分离这是理解物理系统的第一个关键点。很多新手会把它们混为一谈其实它们各司其职RigidBody刚体组件它定义了物体的“物理属性”。你可以把它想象成物体的“内在品质”。它负责回答这个物体有多重质量受到重力影响大吗重力缩放它是动态的会自己动还是静态的呆在那儿类型摩擦力、弹性怎么样Collider碰撞体组件它定义了物体的“形状和边界”。你可以把它想象成物体的“外在轮廓”。它只关心一件事我的物理形状是什么样矩形、圆形、多边形等。碰撞检测是基于这个形状来计算的。在我们的游戏里每个水果节点上都同时挂载了RigidBody2D和CircleCollider2D因为水果近似圆形。RigidBody2D让水果具有质量、受重力下落CircleCollider2D则告诉物理引擎“请按一个圆形来检测我与其他物体的碰撞”。2.1.2 物理世界的同步与更新这里有一个至关重要的概念物理世界独立于渲染世界。游戏画面每帧渲染一次比如60帧每秒但物理计算可以以不同的频率进行通常也是60次每秒但可以设置。RigidBody组件的位置和旋转是由物理引擎计算出来的。为了让画面能正确显示Cocos Creator 在每一帧渲染前会自动将物理引擎中刚体的位置、旋转数据“同步”到对应节点的position和angle属性上。你可能会在代码里看到rigidBody.syncPositionToNode()或rigidBody.syncRotationToNode()这是在手动触发同步。但在大多数情况下引擎的自动同步就足够了。理解这一点你就不会困惑为什么直接修改node.position有时无法影响物理运动了。2.1.3 碰撞检测与回调流程当两个带有Collider的物体接触时物理引擎会检测到碰撞。但检测到之后如何通知我们的游戏逻辑呢这就是碰撞回调函数的作用。流程如下物理引擎计算Box2D 检测到两个碰撞体A和B发生接触。生成碰撞信息引擎生成一个包含碰撞点、法向量等信息的IPhysics2DContact对象。回调触发Cocos Creator 会依次触发挂载在对应节点上的碰撞回调函数。触发顺序是onBeginContact碰撞开始时触发一次。onPreSolve在碰撞反应被计算前触发每帧都可能触发你可以在这里修改碰撞参数如摩擦力。onPostSolve在碰撞反应被计算后触发可以获取碰撞冲量等信息。onEndContact碰撞结束时触发一次。在我们的合成逻辑里主要用到onBeginContact。当两个水果碰撞时我们在这个回调里判断它们是否是同一种水果如果是则销毁当前两个在合适位置生成一个更高级的水果。实操心得在onBeginContact里进行合成判断时一定要小心“重复触发”问题。因为两个水果可能在一段时间内持续接触物理引擎可能会在连续几帧都报告“开始接触”。一个常见的做法是在合成发生后立即给其中一个或两个水果添加一个“已标记待销毁”的标签或者在组件里设置一个_isProcessing布尔值防止同一对水果在单次接触中被多次处理。2.2 输入与控制组件事件驱动的游戏交互用户怎么控制水果的生成这涉及到输入事件的处理。Cocos Creator 提供了全局的输入系统input。2.2.1 鼠标/触摸事件的分发对于鼠标点击或触摸屏幕最常见的是使用node.on(cc.Node.EventType.TOUCH_START, callback, this)。这里有一个关键原理事件冒泡。当你在屏幕上点击时事件会从最底层的节点可能是个UI按钮开始逐级向上层父节点“冒泡”直到根节点。每个节点都有机会处理这个事件。如果你在回调函数中调用了event.propagationStopped()那么事件冒泡就会停止不再传递给父节点。这常用于UI按钮的点击处理防止点击了按钮还触发后面背景的逻辑。在我们的案例中通常是在Canvas节点或者一个专门的游戏控制节点上监听TOUCH_START事件根据点击的X坐标计算生成水果的位置。2.2.2 键盘与重力感应输入除了触摸键盘输入也是调试和扩展功能的好帮手。通过cc.systemEvent.on(cc.SystemEvent.EventType.KEY_DOWN, callback, this)可以监听键盘事件。比如你可以用空格键快速生成一个测试水果。对于移动设备还可以利用重力感应加速度计。通过cc.systemEvent.setAccelerometerEnabled(true)开启并在cc.SystemEvent.EventType.DEVICEMOTION事件回调中获取event.acc对象包含 x, y, z 三个方向的加速度。你可以用这个数据来轻微影响游戏世界比如让水果堆微微倾斜增加趣味性。但要注意处理这类输入时通常需要乘以一个系数并做平滑滤波防止画面抖动过于剧烈。2.2.3 输入管理与防抖在“合成大西瓜”中玩家连续快速点击可能会意外生成多个水果。从组件设计角度一个良好的实践是创建一个InputManager单例组件。这个组件专门负责所有输入的监听和预处理。例如在InputManager的touchStart回调中你可以加入一个简单的防抖逻辑记录上次生成水果的时间戳如果与当前时间间隔小于某个阈值如0.5秒则忽略此次输入。这样游戏逻辑组件如GameManager只需从InputManager获取“干净”的、经过处理的输入指令职责更加清晰。// 伪代码示例InputManager 中的简单防抖 export class InputManager extends cc.Component { private _lastSpawnTime: number 0; private _spawnInterval: number 0.5; // 生成间隔0.5秒 start() { this.node.on(cc.Node.EventType.TOUCH_START, this.onTouchStart, this); } onTouchStart(event: cc.Event.EventTouch) { let currentTime Date.now() / 1000; // 转换为秒 if (currentTime - this._lastSpawnTime this._spawnInterval) { return; // 间隔太短忽略输入 } this._lastSpawnTime currentTime; // 处理有效的触摸事件例如计算位置并通知游戏管理器 let touchPos event.getLocation(); // ... 坐标转换逻辑 ... // 通过自定义事件或直接调用方法通知 GameManager 生成水果 this.gameManager.spawnFruitAt(worldPos); } }2.3 动画与状态组件让合成更有“感觉”水果合成时如果只是“啪”一下旧水果消失、新水果出现会非常生硬。加入动画和状态管理体验立刻提升一个档次。2.3.1 使用 Animation 组件处理合成特效Cocos Creator 的cc.Animation组件可以播放序列帧动画或属性动画。对于合成特效一个典型的做法是创建一个名为Explosion或MergeEffect的预制体Prefab。在这个预制体的节点上添加cc.Animation组件并制作一个动画剪辑AnimationClip。这个剪辑可以包含缩放从0变大再变小、透明度变化从0到1再到0、以及可能的一些粒子效果。在合成逻辑中当两个水果满足条件时先不立即销毁它们。而是计算新水果应该出现的位置通常是两个旧水果的中点。实例化这个特效预制体cc.instantiate(effectPrefab)并设置到计算好的位置。播放特效动画effectNode.getComponent(cc.Animation).play(‘explode’)。监听动画播放完成事件或使用cc.tween延时在回调函数里再执行销毁旧水果、生成新水果的逻辑。2.3.2 通过自定义组件管理水果状态水果在整个生命周期中有多种状态IDLE待生成、FALLING下落中、SETTLED已静止、MERGE_PENDING等待合成、MERGE_COMPLETE已合成。用一个简单的枚举来管理这些状态会让逻辑清晰很多。我们可以创建一个FruitState组件挂载在每个水果上// FruitState.ts export enum EFruitState { IDLE 0, FALLING, SETTLED, MERGE_PENDING, // 已标记要合成等待特效播放等 MERGE_COMPLETE } ccclass(‘FruitState’) export class FruitState extends cc.Component { private _currentState: EFruitState EFruitState.IDLE; get state(): EFruitState { return this._currentState; } set state(newState: EFruitState) { let oldState this._currentState; this._currentState newState; // 状态改变时可以触发一些逻辑例如更新显示 this.onStateChanged(oldState, newState); } private onStateChanged(oldState: EFruitState, newState: EFruitState) { // 例如当状态变为 SETTLED 时可以播放一个轻微的弹跳动画 if (newState EFruitState.SETTLED oldState EFruitState.FALLING) { cc.tween(this.node) .to(0.1, { scale: 1.1 }) .to(0.1, { scale: 1.0 }) .start(); } // 当状态变为 MERGE_PENDING 时可以改变颜色或透明度提示玩家 if (newState EFruitState.MERGE_PENDING) { this.node.color cc.Color.GRAY; } } }然后在GameManager的合成逻辑里就可以这样写let fruitStateA fruitA.getComponent(FruitState); let fruitStateB fruitB.getComponent(FruitState); if (fruitStateA.state EFruitState.SETTLED fruitStateB.state EFruitState.SETTLED fruitA.fruitType fruitB.fruitType) { // 标记状态防止重复处理 fruitStateA.state EFruitState.MERGE_PENDING; fruitStateB.state EFruitState.MERGE_PENDING; // 播放合成特效... // 特效播放完成后再执行实际合成并将新水果状态设为 FALLING }这种状态驱动的方式使得复杂的交互逻辑变得条理清晰易于调试和扩展。3. 游戏逻辑核心合成与分数系统实现3.1 合成判定逻辑的优化基础的合成判定很简单碰撞的两个水果类型相同则合成下一个等级的水果。但这里有几个细节需要优化它们直接影响到游戏体验的“手感”。3.1.1 位置计算不仅仅是取中点最简单的做法是在两个旧水果的中点生成新水果。但这在堆叠紧密时可能有问题新水果可能“嵌”进其他静止的水果里导致非预期的连锁合成。更稳健的做法是计算中点位置。从这个中点位置向上Y轴正方向发射一条短的射线使用物理系统的PhysicsRayCast。如果射线没有碰到任何碰撞体就在中点生成。如果射线碰到了其他静止的水果则在中点上方一定距离例如新水果的半径一点间隙生成确保新水果落在堆叠的顶部。3.1.2 合成链与延迟处理当一次合成发生后新生成的水果可能立刻与下方另一个同类型水果接触触发第二次合成这就是“合成链”。为了正确且流畅地处理合成链我们需要引入“延迟处理”机制。我们不能在onBeginContact回调里立即销毁和生成因为这会改变物理世界可能影响同一帧内其他尚未处理的碰撞。一个标准的做法是在onBeginContact里只将满足合成条件的一对水果信息如它们的节点ID或引用添加到一个“待合成队列”中。在每帧更新结束时例如在lateUpdate函数中统一处理这个队列。处理时从队列中取出一对执行销毁、播放特效、生成新水果的逻辑。生成新水果后检查它是否与任何现有水果接触可以通过物理查询PhysicsCircleCast如果接触且类型相同则将新的一对也加入“待合成队列”等待下一帧处理。这样无论多复杂的连锁反应都能被有序、稳定地处理避免了同一帧内对物理世界和节点树的频繁、交错修改可能引发的错误。3.2 分数与连击系统的组件化设计分数系统看似简单但设计得好能极大提升游戏的正反馈。我们将其拆分为几个组件3.2.1 ScoreManager数据核心这是一个单例组件负责存储和更新当前分数、连击数、历史最高分等数据。它提供增加分数的方法并负责将数据变化通过事件通知给UI。// ScoreManager.ts ccclass(‘ScoreManager’) export class ScoreManager extends cc.Component { private _currentScore: number 0; private _combo: number 0; private _maxCombo: number 0; // 自定义事件名 public static readonly EventScoreUpdated ‘score-updated’; public static readonly EventComboUpdated ‘combo-updated’; public addScore(baseValue: number, isCombo: boolean false) { let addedScore baseValue; if (isCombo this._combo 0) { // 连击加成例如每连击一次额外获得20%分数 addedScore * (1 this._combo * 0.2); } this._currentScore Math.floor(addedScore); // 派发事件通知UI更新 cc.systemEvent.emit(ScoreManager.EventScoreUpdated, this._currentScore); } public increaseCombo() { this._combo; if (this._combo this._maxCombo) { this._maxCombo this._combo; } cc.systemEvent.emit(ScoreManager.EventComboUpdated, this._combo); } public resetCombo() { this._combo 0; cc.systemEvent.emit(ScoreManager.EventComboUpdated, this._combo); } }3.2.2 UIScoreDisplay表现层这是一个挂在UI分数文本节点上的组件。它只做一件事监听ScoreManager发出的事件并更新文本显示。它不关心分数怎么算只负责展示。// UIScoreDisplay.ts ccclass(‘UIScoreDisplay’) export class UIScoreDisplay extends cc.Component { property(cc.Label) scoreLabel: cc.Label null; property(cc.Label) comboLabel: cc.Label null; onLoad() { // 监听分数更新事件 cc.systemEvent.on(ScoreManager.EventScoreUpdated, this.onScoreUpdated, this); cc.systemEvent.on(ScoreManager.EventComboUpdated, this.onComboUpdated, this); } onScoreUpdated(score: number) { this.scoreLabel.string 分数${score}; // 可以添加一个简单的动画如缩放一下 cc.tween(this.scoreLabel.node) .to(0.1, { scale: 1.2 }) .to(0.1, { scale: 1.0 }) .start(); } onComboUpdated(combo: number) { if (combo 1) { this.comboLabel.string 连击 x${combo}; this.comboLabel.node.active true; } else { this.comboLabel.node.active false; } } }3.2.3 连击的逻辑集成连击的逻辑与合成判定紧密相关。在GameManager处理一次合成后它需要通知ScoreManager增加连击数increaseCombo()。同时需要一个计时器或状态来判断连击是否中断。例如可以设定如果3秒内没有新的合成发生则连击中断resetCombo()。这个计时器可以放在GameManager或ScoreManager中。这种组件化的设计将数据ScoreManager、逻辑GameManager中的合成判定、表现UIScoreDisplay清晰地分离符合“单一职责原则”使得代码易于维护和扩展。如果你想更换分数显示样式只需修改UIScoreDisplay组件完全不影响核心逻辑。4. 性能优化与高级技巧当游戏中的水果越来越多特效越来越复杂时性能就可能成为问题。以下是一些针对“合成大西瓜”这类游戏的优化思路。4.1 节点池cc.NodePool的深度应用我们之前提到了用节点池来管理水果的生成和回收避免频繁的cc.instantiate和destroy。这里再深入几个使用技巧4.1.1 为不同类型对象使用多个节点池不要把所有水果都塞进一个池子。为每种水果预制体单独创建一个节点池。这样在获取get时你得到的就是确定类型的水果无需额外的类型判断或重置操作。export class FruitPoolManager extends cc.Component { private _poolMap: Mapnumber, cc.NodePool new Map(); // key: 水果类型 value: 对应的节点池 initPool(prefab: cc.Prefab, fruitType: number, poolSize: number) { let pool new cc.NodePool(); for (let i 0; i poolSize; i) { let newNode cc.instantiate(prefab); // 可以在这里给节点挂上初始组件或设置初始数据 newNode.getComponent(‘Fruit’).fruitType fruitType; pool.put(newNode); } this._poolMap.set(fruitType, pool); } getFruit(fruitType: number): cc.Node { let pool this._poolMap.get(fruitType); if (pool pool.size() 0) { return pool.get(); } else { // 池为空动态实例化一个应尽量避免走到这里 console.warn(Pool for fruitType ${fruitType} is empty, instantiating new one.); // ... 根据类型获取预制体并实例化 ... } } putFruit(node: cc.Node, fruitType: number) { let pool this._poolMap.get(fruitType); if (pool) { // 放回池子前重置节点状态非常重要 node.position cc.v3(0, 0); node.scale 1; node.active false; // 重置物理状态如果有RigidBody let rb node.getComponent(cc.RigidBody2D); if (rb) { rb.linearVelocity cc.v2(0, 0); rb.angularVelocity 0; rb.awake false; // 让刚体“睡眠”减少物理计算 } pool.put(node); } else { node.destroy(); } } }4.1.2 池化对象的“重置”至关重要对象放回池子前必须将其状态重置到初始值。这包括变换属性position,rotation,scale。节点活性active false。组件状态如FruitState组件中的状态机重置为IDLERigidBody的速度清零并设置为睡眠状态。可视化状态color,opacity等恢复默认。忘记重置是导致节点池复用对象时出现各种诡异 Bug 的最常见原因。4.2 渲染优化Draw Call 与合批Cocos Creator 在渲染时会尝试将使用相同材质和纹理的节点进行“合批”以减少 GPU 的绘制调用Draw Call。Draw Call 越少渲染效率越高。4.2.1 检查与优化 Draw Call在编辑器运行时可以打开调试 - 显示 Draw Call来查看当前场景的 Draw Call 数量。对于“合成大西瓜”所有水果如果使用同一张图集Texture Atlas那么它们很可能被合批只产生1个或很少的 Draw Call。如果每个水果是单独的图片文件则可能产生大量 Draw Call。优化建议使用图集将所有水果精灵Sprite的图片打包到一张或少数几张图集中。这是减少 2D 游戏 Draw Call 最有效的手段。注意渲染顺序合批通常要求节点在渲染队列中是连续的。如果两个使用相同材质的节点之间插入了一个使用不同材质的节点比如一个半透明的遮罩层可能会打断合批。可以通过调整节点的zIndex或修改Sprite组件的renderOrder来尝试优化渲染顺序。谨慎使用 Mask 和 Graphicscc.Mask和cc.Graphics组件会打断合批。如果非用不可尽量将其影响范围控制在小区域内。4.2.2 动态与静态节点的分离对于已经静止、不会再移动或改变状态的水果即状态为SETTLED的可以考虑将其从动态物理世界“冻结”。虽然 Cocos Creator 的物理引擎会对睡眠的刚体进行优化但我们还可以从渲染层面思考。一个进阶思路是将静止的水果“烘焙”到一张动态生成的纹理上然后用一个大的Sprite节点来显示这张纹理同时将原来的大量静止水果节点隐藏或移出渲染树。这能极大地减少节点数量和 Draw Call。但这属于比较高级的优化实现复杂需要权衡收益和开发成本。对于“合成大西瓜”这个体量的游戏通常使用图集并确保合批不被意外打断就足够了。4.3 内存与资源管理4.3.1 纹理资源的加载与释放使用cc.resources.load或 Asset Bundle 动态加载资源时务必注意释放。对于在游戏过程中不再需要的资源比如低等级水果的纹理在游戏后期几乎不会出现可以在合适的时机调用cc.resources.release进行释放。一个常见的模式是根据水果的等级将纹理分组到不同的 Asset Bundle 中。当游戏进行到中后期可以异步卸载低等级水果所在的 Bundle释放内存。4.3.2 避免内存泄漏事件监听与节点引用这是 JavaScript/TypeScript 项目的老问题但在 Cocos 中尤为突出事件监听使用node.on或systemEvent.on监听事件后必须在组件销毁时onDestroy生命周期使用node.off或systemEvent.off取消监听。否则回调函数中可能持有对组件或节点的引用导致它们无法被垃圾回收。节点引用避免在全局对象或长生命周期的对象中持有大量临时节点的引用。当节点不再需要时确保没有其他地方引用它以便节点池能正常回收或引擎能销毁它。养成在onDestroy中进行清理的习惯onDestroy() { // 取消事件监听 this.node.off(cc.Node.EventType.TOUCH_START, this.onTouchStart, this); cc.systemEvent.off(cc.SystemEvent.EventType.KEY_DOWN, this.onKeyDown, this); // 如果监听了自定义事件也要取消 cc.systemEvent.off(ScoreManager.EventScoreUpdated, this.onScoreUpdated, this); // 清空对其它节点的引用如果是临时引用 this._someReferenceNode null; }5. 常见问题排查与调试技巧即使理解了原理实际开发中还是会遇到各种问题。这里记录一些典型问题的排查思路。5.1 物理碰撞相关疑难杂症问题1水果偶尔会“穿模”或重叠在一起没有触发碰撞。可能原因1刚体类型设置错误。确保下落的水果刚体类型是Dynamic动态而静止的边界或地面的刚体类型是Static静态。Kinematic运动学类型需要代码控制移动不适合自由落体。可能原因2碰撞体形状或大小不匹配。检查CircleCollider2D的radius是否与水果精灵的视觉大小匹配。可以在编辑器中将碰撞体的edit属性勾选上在场景中查看绿色的碰撞体轮廓线。可能原因3物理步长问题。如果物体速度过快比如一帧移动了很长的距离可能会“穿越”另一个薄薄的碰撞体。可以尝试在cc.PhysicsManager的工程设置中增加物理更新的频率减小fixedTimeStep或者启用useFixedTimeStep。更根本的解决方法是限制水果生成时的初始速度。排查工具使用物理调试绘制。在代码中调用cc.director.getPhysicsManager().enabledDebugDraw true;可以在场景中看到所有碰撞体的轮廓和刚体的速度向量非常直观。问题2合成时新水果的位置总是不对有时会卡进墙里。原因如3.1.1节所述简单取中点可能不靠谱。解决方案实现更健壮的位置计算逻辑结合射线检测。确保生成位置是“合法”的。调试方法在生成新水果的代码处临时绘制一个标记比如实例化一个小红点到计算出的目标位置观察它是否如你所愿。5.2 动画与特效播放异常问题合成特效播放一次后再次播放时不起作用或显示异常。可能原因1节点池复用导致的状态残留。特效节点也应用节点池管理。放回池子前必须重置cc.Animation组件状态animation.stop(); animation.setCurrentTime(0);。同时要确保cc.Sprite或其他渲染组件的属性如color,opacity被重置。可能原因2动画剪辑AnimationClip的 WrapMode 设置。确保特效动画的WrapMode设置为Normal播放一次而不是Loop循环播放。或者在播放动画时指定播放次数animation.play(‘explode’, 0)表示播放一次。排查方法在特效播放的开始和结束回调中加入console.log确认播放流程是否按预期执行。5.3 性能问题快速定位问题游戏运行一段时间后水果很多时变得卡顿。第一步定位瓶颈。使用浏览器的开发者工具F12中的Performance或Profiler面板录制一段卡顿时的操作。查看时间线是 JavaScript 执行时间长Scripting还是渲染时间长Rendering或者是物理计算Physics耗时多。第二步针对性优化。Scripting 耗时高检查自己的游戏逻辑尤其是update函数中是否有复杂的循环或频繁的查找操作。考虑使用空间分区如网格来优化“查找周围水果”这类操作。Rendering 耗时高检查 Draw Call 数量方法见4.2.1。如果 Draw Call 过高优先检查图集和渲染顺序。同时减少不必要的cc.Sprite节点比如隐藏已静止且不再变化的水果的阴影效果。Physics 耗时高检查场景中活跃的Dynamic刚体数量。确保静止的水果刚体进入了睡眠状态awake为false。如果一堆水果已经稳定堆叠可以考虑将它们“合并”为一个大的静态碰撞体但这会极大增加逻辑复杂度需谨慎评估。5.4 移动端适配要点问题在手机上触摸不灵敏或水果生成位置有偏差。触摸坐标转换event.getLocation()获取的是基于屏幕的坐标。必须使用canvas.node.convertToNodeSpaceAR将其转换为游戏世界坐标系下的坐标才能正确使用。onTouchStart(event: cc.Event.EventTouch) { let touchPos event.getLocation(); // 屏幕坐标 let worldPos cc.Camera.main.getScreenToWorldPoint(touchPos); // 世界坐标 let nodePos this.canvasNode.convertToNodeSpaceAR(worldPos); // 画布节点坐标 // 使用 nodePos.x 来决定在何处生成水果 }多点触控默认情况下TOUCH_START会响应所有手指的触摸。如果只需要第一个触点可以在回调开始时判断event.getID() 0。高DPI屏幕确保游戏画布的分辨率策略设置正确如Fit Height或Fit WidthUI 使用锚点进行布局以适应不同尺寸和分辨率的屏幕。回过头看把一个“合成大西瓜”游戏做出来真正的价值不在于复现了这个玩法而在于通过它我们像解剖麻雀一样把 Cocos Creator 的核心工作流程和组件化思想实实在在地走通了一遍。从最基础的节点、组件、预制体到物理碰撞、输入事件、动画系统再到性能优化和问题排查这些知识点是通用的。下次当你再面对一个“让物体动起来、碰起来、响起来”的需求时脑子里自然会浮现出这套经过验证的组件组合拳。这才是从“照着做”到“想着做”的关键一步。游戏开发里没有银弹但有了清晰的组件化思维和扎实的原理理解无论炮弹从哪个方向来你都知道该用什么姿势去接。
1. 项目概述从“玩”到“懂”的跨越上次我们动手把“合成大西瓜”的架子搭了起来让水果能掉、能碰、能合成游戏算是能跑了。但不知道你有没有这种感觉代码是跑通了可心里还是有点虚总觉得只是照猫画虎里面的门道并没摸清。比如为什么物理碰撞的代码要那么写cc.Node和cc.Component到底啥关系事件监听绑来绑去到底谁在监听谁如果我想加个新功能比如让西瓜合成时有爆炸特效该从哪儿下手这就是我们这次要解决的核心问题。光把游戏做出来不算完我们得把它“拆开”看看每个零件是怎么运转的。Cocos Creator 的强大很大程度上就体现在它这套基于组件的架构上。你把一个复杂的游戏看成是由一个个功能单一、可以拼装的“组件”构成的开发思路瞬间就清晰了。今天我们就聚焦在“合成大西瓜”这个案例里把几个关键组件——物理碰撞、用户输入、动画状态管理——的原理掰开揉碎了讲。目标不是让你记住 API而是理解其设计思想以后无论遇到什么需求你都能自己设计出合适的组件来应对。2. 核心组件原理深度拆解2.1 物理与碰撞组件不只是“碰一下”在“合成大西瓜”里水果下落、相互堆叠、碰撞后合成这一切的基础都是物理引擎。Cocos Creator 内置了两种物理系统基于 Box2D 的物理系统和基于 Cannon.js 的物理系统。对于我们的 2D 游戏默认且最常用的就是 Box2D。2.1.1 RigidBody 与 Collider 的职责分离这是理解物理系统的第一个关键点。很多新手会把它们混为一谈其实它们各司其职RigidBody刚体组件它定义了物体的“物理属性”。你可以把它想象成物体的“内在品质”。它负责回答这个物体有多重质量受到重力影响大吗重力缩放它是动态的会自己动还是静态的呆在那儿类型摩擦力、弹性怎么样Collider碰撞体组件它定义了物体的“形状和边界”。你可以把它想象成物体的“外在轮廓”。它只关心一件事我的物理形状是什么样矩形、圆形、多边形等。碰撞检测是基于这个形状来计算的。在我们的游戏里每个水果节点上都同时挂载了RigidBody2D和CircleCollider2D因为水果近似圆形。RigidBody2D让水果具有质量、受重力下落CircleCollider2D则告诉物理引擎“请按一个圆形来检测我与其他物体的碰撞”。2.1.2 物理世界的同步与更新这里有一个至关重要的概念物理世界独立于渲染世界。游戏画面每帧渲染一次比如60帧每秒但物理计算可以以不同的频率进行通常也是60次每秒但可以设置。RigidBody组件的位置和旋转是由物理引擎计算出来的。为了让画面能正确显示Cocos Creator 在每一帧渲染前会自动将物理引擎中刚体的位置、旋转数据“同步”到对应节点的position和angle属性上。你可能会在代码里看到rigidBody.syncPositionToNode()或rigidBody.syncRotationToNode()这是在手动触发同步。但在大多数情况下引擎的自动同步就足够了。理解这一点你就不会困惑为什么直接修改node.position有时无法影响物理运动了。2.1.3 碰撞检测与回调流程当两个带有Collider的物体接触时物理引擎会检测到碰撞。但检测到之后如何通知我们的游戏逻辑呢这就是碰撞回调函数的作用。流程如下物理引擎计算Box2D 检测到两个碰撞体A和B发生接触。生成碰撞信息引擎生成一个包含碰撞点、法向量等信息的IPhysics2DContact对象。回调触发Cocos Creator 会依次触发挂载在对应节点上的碰撞回调函数。触发顺序是onBeginContact碰撞开始时触发一次。onPreSolve在碰撞反应被计算前触发每帧都可能触发你可以在这里修改碰撞参数如摩擦力。onPostSolve在碰撞反应被计算后触发可以获取碰撞冲量等信息。onEndContact碰撞结束时触发一次。在我们的合成逻辑里主要用到onBeginContact。当两个水果碰撞时我们在这个回调里判断它们是否是同一种水果如果是则销毁当前两个在合适位置生成一个更高级的水果。实操心得在onBeginContact里进行合成判断时一定要小心“重复触发”问题。因为两个水果可能在一段时间内持续接触物理引擎可能会在连续几帧都报告“开始接触”。一个常见的做法是在合成发生后立即给其中一个或两个水果添加一个“已标记待销毁”的标签或者在组件里设置一个_isProcessing布尔值防止同一对水果在单次接触中被多次处理。2.2 输入与控制组件事件驱动的游戏交互用户怎么控制水果的生成这涉及到输入事件的处理。Cocos Creator 提供了全局的输入系统input。2.2.1 鼠标/触摸事件的分发对于鼠标点击或触摸屏幕最常见的是使用node.on(cc.Node.EventType.TOUCH_START, callback, this)。这里有一个关键原理事件冒泡。当你在屏幕上点击时事件会从最底层的节点可能是个UI按钮开始逐级向上层父节点“冒泡”直到根节点。每个节点都有机会处理这个事件。如果你在回调函数中调用了event.propagationStopped()那么事件冒泡就会停止不再传递给父节点。这常用于UI按钮的点击处理防止点击了按钮还触发后面背景的逻辑。在我们的案例中通常是在Canvas节点或者一个专门的游戏控制节点上监听TOUCH_START事件根据点击的X坐标计算生成水果的位置。2.2.2 键盘与重力感应输入除了触摸键盘输入也是调试和扩展功能的好帮手。通过cc.systemEvent.on(cc.SystemEvent.EventType.KEY_DOWN, callback, this)可以监听键盘事件。比如你可以用空格键快速生成一个测试水果。对于移动设备还可以利用重力感应加速度计。通过cc.systemEvent.setAccelerometerEnabled(true)开启并在cc.SystemEvent.EventType.DEVICEMOTION事件回调中获取event.acc对象包含 x, y, z 三个方向的加速度。你可以用这个数据来轻微影响游戏世界比如让水果堆微微倾斜增加趣味性。但要注意处理这类输入时通常需要乘以一个系数并做平滑滤波防止画面抖动过于剧烈。2.2.3 输入管理与防抖在“合成大西瓜”中玩家连续快速点击可能会意外生成多个水果。从组件设计角度一个良好的实践是创建一个InputManager单例组件。这个组件专门负责所有输入的监听和预处理。例如在InputManager的touchStart回调中你可以加入一个简单的防抖逻辑记录上次生成水果的时间戳如果与当前时间间隔小于某个阈值如0.5秒则忽略此次输入。这样游戏逻辑组件如GameManager只需从InputManager获取“干净”的、经过处理的输入指令职责更加清晰。// 伪代码示例InputManager 中的简单防抖 export class InputManager extends cc.Component { private _lastSpawnTime: number 0; private _spawnInterval: number 0.5; // 生成间隔0.5秒 start() { this.node.on(cc.Node.EventType.TOUCH_START, this.onTouchStart, this); } onTouchStart(event: cc.Event.EventTouch) { let currentTime Date.now() / 1000; // 转换为秒 if (currentTime - this._lastSpawnTime this._spawnInterval) { return; // 间隔太短忽略输入 } this._lastSpawnTime currentTime; // 处理有效的触摸事件例如计算位置并通知游戏管理器 let touchPos event.getLocation(); // ... 坐标转换逻辑 ... // 通过自定义事件或直接调用方法通知 GameManager 生成水果 this.gameManager.spawnFruitAt(worldPos); } }2.3 动画与状态组件让合成更有“感觉”水果合成时如果只是“啪”一下旧水果消失、新水果出现会非常生硬。加入动画和状态管理体验立刻提升一个档次。2.3.1 使用 Animation 组件处理合成特效Cocos Creator 的cc.Animation组件可以播放序列帧动画或属性动画。对于合成特效一个典型的做法是创建一个名为Explosion或MergeEffect的预制体Prefab。在这个预制体的节点上添加cc.Animation组件并制作一个动画剪辑AnimationClip。这个剪辑可以包含缩放从0变大再变小、透明度变化从0到1再到0、以及可能的一些粒子效果。在合成逻辑中当两个水果满足条件时先不立即销毁它们。而是计算新水果应该出现的位置通常是两个旧水果的中点。实例化这个特效预制体cc.instantiate(effectPrefab)并设置到计算好的位置。播放特效动画effectNode.getComponent(cc.Animation).play(‘explode’)。监听动画播放完成事件或使用cc.tween延时在回调函数里再执行销毁旧水果、生成新水果的逻辑。2.3.2 通过自定义组件管理水果状态水果在整个生命周期中有多种状态IDLE待生成、FALLING下落中、SETTLED已静止、MERGE_PENDING等待合成、MERGE_COMPLETE已合成。用一个简单的枚举来管理这些状态会让逻辑清晰很多。我们可以创建一个FruitState组件挂载在每个水果上// FruitState.ts export enum EFruitState { IDLE 0, FALLING, SETTLED, MERGE_PENDING, // 已标记要合成等待特效播放等 MERGE_COMPLETE } ccclass(‘FruitState’) export class FruitState extends cc.Component { private _currentState: EFruitState EFruitState.IDLE; get state(): EFruitState { return this._currentState; } set state(newState: EFruitState) { let oldState this._currentState; this._currentState newState; // 状态改变时可以触发一些逻辑例如更新显示 this.onStateChanged(oldState, newState); } private onStateChanged(oldState: EFruitState, newState: EFruitState) { // 例如当状态变为 SETTLED 时可以播放一个轻微的弹跳动画 if (newState EFruitState.SETTLED oldState EFruitState.FALLING) { cc.tween(this.node) .to(0.1, { scale: 1.1 }) .to(0.1, { scale: 1.0 }) .start(); } // 当状态变为 MERGE_PENDING 时可以改变颜色或透明度提示玩家 if (newState EFruitState.MERGE_PENDING) { this.node.color cc.Color.GRAY; } } }然后在GameManager的合成逻辑里就可以这样写let fruitStateA fruitA.getComponent(FruitState); let fruitStateB fruitB.getComponent(FruitState); if (fruitStateA.state EFruitState.SETTLED fruitStateB.state EFruitState.SETTLED fruitA.fruitType fruitB.fruitType) { // 标记状态防止重复处理 fruitStateA.state EFruitState.MERGE_PENDING; fruitStateB.state EFruitState.MERGE_PENDING; // 播放合成特效... // 特效播放完成后再执行实际合成并将新水果状态设为 FALLING }这种状态驱动的方式使得复杂的交互逻辑变得条理清晰易于调试和扩展。3. 游戏逻辑核心合成与分数系统实现3.1 合成判定逻辑的优化基础的合成判定很简单碰撞的两个水果类型相同则合成下一个等级的水果。但这里有几个细节需要优化它们直接影响到游戏体验的“手感”。3.1.1 位置计算不仅仅是取中点最简单的做法是在两个旧水果的中点生成新水果。但这在堆叠紧密时可能有问题新水果可能“嵌”进其他静止的水果里导致非预期的连锁合成。更稳健的做法是计算中点位置。从这个中点位置向上Y轴正方向发射一条短的射线使用物理系统的PhysicsRayCast。如果射线没有碰到任何碰撞体就在中点生成。如果射线碰到了其他静止的水果则在中点上方一定距离例如新水果的半径一点间隙生成确保新水果落在堆叠的顶部。3.1.2 合成链与延迟处理当一次合成发生后新生成的水果可能立刻与下方另一个同类型水果接触触发第二次合成这就是“合成链”。为了正确且流畅地处理合成链我们需要引入“延迟处理”机制。我们不能在onBeginContact回调里立即销毁和生成因为这会改变物理世界可能影响同一帧内其他尚未处理的碰撞。一个标准的做法是在onBeginContact里只将满足合成条件的一对水果信息如它们的节点ID或引用添加到一个“待合成队列”中。在每帧更新结束时例如在lateUpdate函数中统一处理这个队列。处理时从队列中取出一对执行销毁、播放特效、生成新水果的逻辑。生成新水果后检查它是否与任何现有水果接触可以通过物理查询PhysicsCircleCast如果接触且类型相同则将新的一对也加入“待合成队列”等待下一帧处理。这样无论多复杂的连锁反应都能被有序、稳定地处理避免了同一帧内对物理世界和节点树的频繁、交错修改可能引发的错误。3.2 分数与连击系统的组件化设计分数系统看似简单但设计得好能极大提升游戏的正反馈。我们将其拆分为几个组件3.2.1 ScoreManager数据核心这是一个单例组件负责存储和更新当前分数、连击数、历史最高分等数据。它提供增加分数的方法并负责将数据变化通过事件通知给UI。// ScoreManager.ts ccclass(‘ScoreManager’) export class ScoreManager extends cc.Component { private _currentScore: number 0; private _combo: number 0; private _maxCombo: number 0; // 自定义事件名 public static readonly EventScoreUpdated ‘score-updated’; public static readonly EventComboUpdated ‘combo-updated’; public addScore(baseValue: number, isCombo: boolean false) { let addedScore baseValue; if (isCombo this._combo 0) { // 连击加成例如每连击一次额外获得20%分数 addedScore * (1 this._combo * 0.2); } this._currentScore Math.floor(addedScore); // 派发事件通知UI更新 cc.systemEvent.emit(ScoreManager.EventScoreUpdated, this._currentScore); } public increaseCombo() { this._combo; if (this._combo this._maxCombo) { this._maxCombo this._combo; } cc.systemEvent.emit(ScoreManager.EventComboUpdated, this._combo); } public resetCombo() { this._combo 0; cc.systemEvent.emit(ScoreManager.EventComboUpdated, this._combo); } }3.2.2 UIScoreDisplay表现层这是一个挂在UI分数文本节点上的组件。它只做一件事监听ScoreManager发出的事件并更新文本显示。它不关心分数怎么算只负责展示。// UIScoreDisplay.ts ccclass(‘UIScoreDisplay’) export class UIScoreDisplay extends cc.Component { property(cc.Label) scoreLabel: cc.Label null; property(cc.Label) comboLabel: cc.Label null; onLoad() { // 监听分数更新事件 cc.systemEvent.on(ScoreManager.EventScoreUpdated, this.onScoreUpdated, this); cc.systemEvent.on(ScoreManager.EventComboUpdated, this.onComboUpdated, this); } onScoreUpdated(score: number) { this.scoreLabel.string 分数${score}; // 可以添加一个简单的动画如缩放一下 cc.tween(this.scoreLabel.node) .to(0.1, { scale: 1.2 }) .to(0.1, { scale: 1.0 }) .start(); } onComboUpdated(combo: number) { if (combo 1) { this.comboLabel.string 连击 x${combo}; this.comboLabel.node.active true; } else { this.comboLabel.node.active false; } } }3.2.3 连击的逻辑集成连击的逻辑与合成判定紧密相关。在GameManager处理一次合成后它需要通知ScoreManager增加连击数increaseCombo()。同时需要一个计时器或状态来判断连击是否中断。例如可以设定如果3秒内没有新的合成发生则连击中断resetCombo()。这个计时器可以放在GameManager或ScoreManager中。这种组件化的设计将数据ScoreManager、逻辑GameManager中的合成判定、表现UIScoreDisplay清晰地分离符合“单一职责原则”使得代码易于维护和扩展。如果你想更换分数显示样式只需修改UIScoreDisplay组件完全不影响核心逻辑。4. 性能优化与高级技巧当游戏中的水果越来越多特效越来越复杂时性能就可能成为问题。以下是一些针对“合成大西瓜”这类游戏的优化思路。4.1 节点池cc.NodePool的深度应用我们之前提到了用节点池来管理水果的生成和回收避免频繁的cc.instantiate和destroy。这里再深入几个使用技巧4.1.1 为不同类型对象使用多个节点池不要把所有水果都塞进一个池子。为每种水果预制体单独创建一个节点池。这样在获取get时你得到的就是确定类型的水果无需额外的类型判断或重置操作。export class FruitPoolManager extends cc.Component { private _poolMap: Mapnumber, cc.NodePool new Map(); // key: 水果类型 value: 对应的节点池 initPool(prefab: cc.Prefab, fruitType: number, poolSize: number) { let pool new cc.NodePool(); for (let i 0; i poolSize; i) { let newNode cc.instantiate(prefab); // 可以在这里给节点挂上初始组件或设置初始数据 newNode.getComponent(‘Fruit’).fruitType fruitType; pool.put(newNode); } this._poolMap.set(fruitType, pool); } getFruit(fruitType: number): cc.Node { let pool this._poolMap.get(fruitType); if (pool pool.size() 0) { return pool.get(); } else { // 池为空动态实例化一个应尽量避免走到这里 console.warn(Pool for fruitType ${fruitType} is empty, instantiating new one.); // ... 根据类型获取预制体并实例化 ... } } putFruit(node: cc.Node, fruitType: number) { let pool this._poolMap.get(fruitType); if (pool) { // 放回池子前重置节点状态非常重要 node.position cc.v3(0, 0); node.scale 1; node.active false; // 重置物理状态如果有RigidBody let rb node.getComponent(cc.RigidBody2D); if (rb) { rb.linearVelocity cc.v2(0, 0); rb.angularVelocity 0; rb.awake false; // 让刚体“睡眠”减少物理计算 } pool.put(node); } else { node.destroy(); } } }4.1.2 池化对象的“重置”至关重要对象放回池子前必须将其状态重置到初始值。这包括变换属性position,rotation,scale。节点活性active false。组件状态如FruitState组件中的状态机重置为IDLERigidBody的速度清零并设置为睡眠状态。可视化状态color,opacity等恢复默认。忘记重置是导致节点池复用对象时出现各种诡异 Bug 的最常见原因。4.2 渲染优化Draw Call 与合批Cocos Creator 在渲染时会尝试将使用相同材质和纹理的节点进行“合批”以减少 GPU 的绘制调用Draw Call。Draw Call 越少渲染效率越高。4.2.1 检查与优化 Draw Call在编辑器运行时可以打开调试 - 显示 Draw Call来查看当前场景的 Draw Call 数量。对于“合成大西瓜”所有水果如果使用同一张图集Texture Atlas那么它们很可能被合批只产生1个或很少的 Draw Call。如果每个水果是单独的图片文件则可能产生大量 Draw Call。优化建议使用图集将所有水果精灵Sprite的图片打包到一张或少数几张图集中。这是减少 2D 游戏 Draw Call 最有效的手段。注意渲染顺序合批通常要求节点在渲染队列中是连续的。如果两个使用相同材质的节点之间插入了一个使用不同材质的节点比如一个半透明的遮罩层可能会打断合批。可以通过调整节点的zIndex或修改Sprite组件的renderOrder来尝试优化渲染顺序。谨慎使用 Mask 和 Graphicscc.Mask和cc.Graphics组件会打断合批。如果非用不可尽量将其影响范围控制在小区域内。4.2.2 动态与静态节点的分离对于已经静止、不会再移动或改变状态的水果即状态为SETTLED的可以考虑将其从动态物理世界“冻结”。虽然 Cocos Creator 的物理引擎会对睡眠的刚体进行优化但我们还可以从渲染层面思考。一个进阶思路是将静止的水果“烘焙”到一张动态生成的纹理上然后用一个大的Sprite节点来显示这张纹理同时将原来的大量静止水果节点隐藏或移出渲染树。这能极大地减少节点数量和 Draw Call。但这属于比较高级的优化实现复杂需要权衡收益和开发成本。对于“合成大西瓜”这个体量的游戏通常使用图集并确保合批不被意外打断就足够了。4.3 内存与资源管理4.3.1 纹理资源的加载与释放使用cc.resources.load或 Asset Bundle 动态加载资源时务必注意释放。对于在游戏过程中不再需要的资源比如低等级水果的纹理在游戏后期几乎不会出现可以在合适的时机调用cc.resources.release进行释放。一个常见的模式是根据水果的等级将纹理分组到不同的 Asset Bundle 中。当游戏进行到中后期可以异步卸载低等级水果所在的 Bundle释放内存。4.3.2 避免内存泄漏事件监听与节点引用这是 JavaScript/TypeScript 项目的老问题但在 Cocos 中尤为突出事件监听使用node.on或systemEvent.on监听事件后必须在组件销毁时onDestroy生命周期使用node.off或systemEvent.off取消监听。否则回调函数中可能持有对组件或节点的引用导致它们无法被垃圾回收。节点引用避免在全局对象或长生命周期的对象中持有大量临时节点的引用。当节点不再需要时确保没有其他地方引用它以便节点池能正常回收或引擎能销毁它。养成在onDestroy中进行清理的习惯onDestroy() { // 取消事件监听 this.node.off(cc.Node.EventType.TOUCH_START, this.onTouchStart, this); cc.systemEvent.off(cc.SystemEvent.EventType.KEY_DOWN, this.onKeyDown, this); // 如果监听了自定义事件也要取消 cc.systemEvent.off(ScoreManager.EventScoreUpdated, this.onScoreUpdated, this); // 清空对其它节点的引用如果是临时引用 this._someReferenceNode null; }5. 常见问题排查与调试技巧即使理解了原理实际开发中还是会遇到各种问题。这里记录一些典型问题的排查思路。5.1 物理碰撞相关疑难杂症问题1水果偶尔会“穿模”或重叠在一起没有触发碰撞。可能原因1刚体类型设置错误。确保下落的水果刚体类型是Dynamic动态而静止的边界或地面的刚体类型是Static静态。Kinematic运动学类型需要代码控制移动不适合自由落体。可能原因2碰撞体形状或大小不匹配。检查CircleCollider2D的radius是否与水果精灵的视觉大小匹配。可以在编辑器中将碰撞体的edit属性勾选上在场景中查看绿色的碰撞体轮廓线。可能原因3物理步长问题。如果物体速度过快比如一帧移动了很长的距离可能会“穿越”另一个薄薄的碰撞体。可以尝试在cc.PhysicsManager的工程设置中增加物理更新的频率减小fixedTimeStep或者启用useFixedTimeStep。更根本的解决方法是限制水果生成时的初始速度。排查工具使用物理调试绘制。在代码中调用cc.director.getPhysicsManager().enabledDebugDraw true;可以在场景中看到所有碰撞体的轮廓和刚体的速度向量非常直观。问题2合成时新水果的位置总是不对有时会卡进墙里。原因如3.1.1节所述简单取中点可能不靠谱。解决方案实现更健壮的位置计算逻辑结合射线检测。确保生成位置是“合法”的。调试方法在生成新水果的代码处临时绘制一个标记比如实例化一个小红点到计算出的目标位置观察它是否如你所愿。5.2 动画与特效播放异常问题合成特效播放一次后再次播放时不起作用或显示异常。可能原因1节点池复用导致的状态残留。特效节点也应用节点池管理。放回池子前必须重置cc.Animation组件状态animation.stop(); animation.setCurrentTime(0);。同时要确保cc.Sprite或其他渲染组件的属性如color,opacity被重置。可能原因2动画剪辑AnimationClip的 WrapMode 设置。确保特效动画的WrapMode设置为Normal播放一次而不是Loop循环播放。或者在播放动画时指定播放次数animation.play(‘explode’, 0)表示播放一次。排查方法在特效播放的开始和结束回调中加入console.log确认播放流程是否按预期执行。5.3 性能问题快速定位问题游戏运行一段时间后水果很多时变得卡顿。第一步定位瓶颈。使用浏览器的开发者工具F12中的Performance或Profiler面板录制一段卡顿时的操作。查看时间线是 JavaScript 执行时间长Scripting还是渲染时间长Rendering或者是物理计算Physics耗时多。第二步针对性优化。Scripting 耗时高检查自己的游戏逻辑尤其是update函数中是否有复杂的循环或频繁的查找操作。考虑使用空间分区如网格来优化“查找周围水果”这类操作。Rendering 耗时高检查 Draw Call 数量方法见4.2.1。如果 Draw Call 过高优先检查图集和渲染顺序。同时减少不必要的cc.Sprite节点比如隐藏已静止且不再变化的水果的阴影效果。Physics 耗时高检查场景中活跃的Dynamic刚体数量。确保静止的水果刚体进入了睡眠状态awake为false。如果一堆水果已经稳定堆叠可以考虑将它们“合并”为一个大的静态碰撞体但这会极大增加逻辑复杂度需谨慎评估。5.4 移动端适配要点问题在手机上触摸不灵敏或水果生成位置有偏差。触摸坐标转换event.getLocation()获取的是基于屏幕的坐标。必须使用canvas.node.convertToNodeSpaceAR将其转换为游戏世界坐标系下的坐标才能正确使用。onTouchStart(event: cc.Event.EventTouch) { let touchPos event.getLocation(); // 屏幕坐标 let worldPos cc.Camera.main.getScreenToWorldPoint(touchPos); // 世界坐标 let nodePos this.canvasNode.convertToNodeSpaceAR(worldPos); // 画布节点坐标 // 使用 nodePos.x 来决定在何处生成水果 }多点触控默认情况下TOUCH_START会响应所有手指的触摸。如果只需要第一个触点可以在回调开始时判断event.getID() 0。高DPI屏幕确保游戏画布的分辨率策略设置正确如Fit Height或Fit WidthUI 使用锚点进行布局以适应不同尺寸和分辨率的屏幕。回过头看把一个“合成大西瓜”游戏做出来真正的价值不在于复现了这个玩法而在于通过它我们像解剖麻雀一样把 Cocos Creator 的核心工作流程和组件化思想实实在在地走通了一遍。从最基础的节点、组件、预制体到物理碰撞、输入事件、动画系统再到性能优化和问题排查这些知识点是通用的。下次当你再面对一个“让物体动起来、碰起来、响起来”的需求时脑子里自然会浮现出这套经过验证的组件组合拳。这才是从“照着做”到“想着做”的关键一步。游戏开发里没有银弹但有了清晰的组件化思维和扎实的原理理解无论炮弹从哪个方向来你都知道该用什么姿势去接。
