第六章：“这套组件能跑多久” —— 棋牌源代码中的五类组件行为逻辑解析
在接手一份棋牌源代码类项目时，我们往往会看到几十种组件摆在面前：有的是“连线爆击型”，有的是“点击触发型”，还有的是“多阶段流程控制型”。
说实话，很多开发者看到这么一堆 prefab 会懵：这些 UI 究竟怎么搭？逻辑在哪里？数据走哪条线？
这一章，我们不讲 UI，而是讲每一个组件背后的行为逻辑和运行路径。也就是说，组件不是“长得像”，而是“怎么动”。
一、滚动类组件：一切从 Reel 开始
最典型的就是那类“横向或纵向滚动停止后展示图标”的组件，比如水果类。
它的结构非常统一：多个 Reel（卷轴），每个 Reel 上挂多个图标，图标按一定速度滚动，到达目标图案后减速停止。
我们在源码里通常会看到这样的结构：
GameScene/
├── ClickAreaGroup
│ ├── Area_1 (Script: TriggerArea.js)
│ ├── Area_2
│ └── Area_3
└── ResultPopup
逻辑一般在 Reel.js 中：
cc.Class({
extends: cc.Component,
properties: {
iconPrefab: cc.Prefab,
iconCount: 20
},
onLoad () {
this.icons = [];
this.initIcons();
},
initIcons () {
for (let i = 0; i < this.iconCount; i++) {
let icon = cc.instantiate(this.iconPrefab);
icon.y = i * 120;
this.node.addChild(icon);
this.icons.push(icon);
}
},
spin (targetIconIndex, callback) {
// 实际是先加速 → 匀速 → 减速 → 定位
// 假装有 easing 的 tween 动画
this.scheduleOnce(() => {
callback && callback();
}, 2.5);
}
});
然后每个 Reel 接收一个“目标图标 index”，通过动画过渡控制停止。
需要注意的是：
-
所有 Reel 的停止时间必须错开；
-
必须考虑帧率兼容（用 schedule 而非 setTimeout）；
-
停止逻辑要写 callback，统一触发“结算”。
二、点击触发型组件：用户操作即触发下一状态
这类组件的逻辑很清晰：用户点一个区域，逻辑就跑一段流程，通常用于“开宝箱”“点灯”“戳气球”一类玩法。
结构很轻：
GameScene/
├── ClickAreaGroup
│ ├── Area_1 (Script: TriggerArea.js)
│ ├── Area_2
│ └── Area_3
└── ResultPopup
逻辑结构：
cc.Class({
extends: cc.Component,
properties: {
animNode: cc.Node,
resultNode: cc.Node
},
onLoad () {
this.node.on('click', this.onClick, this);
},
onClick () {
this.animNode.getComponent(cc.Animation).play('open');
this.scheduleOnce(() => {
this.resultNode.active = true;
}, 1.5);
}
});
注意细节：
-
点击区域需要禁用二次点击（防连点）；
-
动画完成前不可再次触发；
-
通常需要配合服务端状态判断“是否还能点”。
三、流程驱动型组件：多阶段状态管理
这类组件比较复杂，通常有多个阶段：准备 → 开始 → 动画 → 结算 → 奖励 → 重置。
以多人互动为例，它们需要“服务端广播 → 前端切换状态 → 播放动画 → 请求下一步”。
我们会封装一个状态控制器：
const GameStatus = {
PREPARE: 0,
START: 1,
ANIMATING: 2,
RESULT: 3
};
let currentStatus = GameStatus.PREPARE;
function setGameStatus(status) {
currentStatus = status;
switch (status) {
case GameStatus.START:
playStartAnim();
break;
case GameStatus.RESULT:
showResultPopup();
break;
}
}
Socket 回调：
socket.on('status_change', (data) => {
setGameStatus(data.status);
});
服务端：
io.to(roomId).emit('status_change', { status: 1 });
最大难点：前后端状态必须精准对齐。
如果客户端先到了状态 2，服务端还在状态 1，就会出问题。
四、特效爆发型组件：动画优先、逻辑等待
有一些组件以视觉爆发为主，比如某些“全屏连击”、“高倍触发”的动画型模块。
这类组件有两个重点：
-
资源大，要预加载；
-
动画播放必须阻止逻辑继续。
我们曾经踩过一个坑：动画刚播放到一半，逻辑跳到下一阶段，导致画面混乱。
标准做法：
async function playBombEffect() {
return new Promise(resolve => {
this.node.getComponent(cc.Animation).play('bomb');
this.node.getComponent(cc.Animation).on('finished', resolve, this);
});
}
在流程中使用：
await playBombEffect();
this.enterNextPhase();
关键点：
-
异步执行统一管理；
-
动画中不要执行任何状态变更；
-
必要时锁定用户操作区域（防点击穿透）。
五、通用逻辑层封装：资源池、通用特效、组件解耦
如果你维护的是一个组件集合，最好的方式是“通用逻辑 + 插拔式组件”。
例如写一个资源池：
let objPool = [];
function getNodeFromPool(prefab) {
if (objPool.length > 0) {
return objPool.pop();
}
return cc.instantiate(prefab);
}
function returnToPool(node) {
node.removeFromParent();
objPool.push(node);
}
或者写一个全局弹窗控制器：
function showToast(msg) {
let toast = cc.instantiate(this.toastPrefab);
toast.getComponent(cc.Label).string = msg;
cc.find('Canvas').addChild(toast);
setTimeout(() => {
toast.destroy();
}, 2000);
}
这样你的组件可以做到逻辑分离、复用率高、维护压力小。
总结一下，如果你手上有棋牌源代码的组件库，一定要尝试抽象这些组件的行为特征，而不是照着 UI 修修补补。
只有把它们“想成行为、写成状态”，你才能更快地找到问题，复用逻辑，甚至批量生成组件组合。
下一章，我们会继续聊聊数据侧：组件中涉及的库存控制、AI 配合逻辑、胜负处理、控制逻辑等服务器机制设计——也是很多人在研究源码时最容易看不懂的那一块。