基于Cocos Creator与Node.js的双人对战回合制游戏开发实战

简介这是一款基于Cocos Creator开发的双人回合制对战小游戏源码包面向游戏开发初学者与前端工程师聚焦游戏系统设计与交互逻辑实现的学习实践。资源包含完整可运行项目涵盖角色状态管理、回合控制、技能判定、UI反馈等核心模块配套说明文档便于理解整体架构与关键逻辑。压缩包共553个文件主体为36个JavaScript脚本实现游戏逻辑、150张PNG资源图角色、UI、特效、52个plist纹理图集优化渲染、14个prefab预制体场景对象复用及若干JSON配置与Fire组件文件总大小27.82MB。已有74人下载学习适合通过阅读源码、调试运行、修改扩展等方式掌握Cocos Creator工作流与回合制游戏开发范式尤其利于理解事件驱动、状态机切换与资源加载机制。1. 项目整体设计与技术选型分析我最初拿到这个项目标题的时候脑子里先冒出来的问题是为什么一个简单的回合制游戏要同时用到 Cocos Creator 和 Node.js 两个东西当年我自己做这类双人对战项目时第一个版本只用了 Cocos Creator 的本地模拟数据把对战双方写死在同一个场景里结果做到一半发现根本绕不开服务端——因为你没法让两个玩家“各自”操作同一个角色的数据。所以这个项目把 Node.js 拉进来不是为了凑技术栈而是真实地解决了两个客户端之间的同步问题。1.1 技术栈分工客户端与服务器的职责边界这类回合制战斗游戏最典型的技术架构是Cocos Creator 负责所有玩家可见的界面、动画、操作反馈Node.js 则作为独立的战斗仲裁服务器接收两名玩家的指令判定回合结果再把结果广播出去。拿这个项目来说客户端要处理的核心事情包括战斗场景里的角色立绘、血条、技能按钮、战斗日志滚动、受击动画和数值飘字。而服务端需要处理的事情是接收两边的行动指令、判断出手顺序、计算伤害、同步双方血量和状态、判定胜负和回合轮转。我见过很多新手把伤害计算和回合逻辑写在客户端里面这在本地测试时没问题但一旦改成真正的双人对战两个客户端的“本地真相”就会冲突玩家A客户端判定自己赢了玩家B客户端可能判定自己还没死。避免这个问题的唯一办法就是把裁决权集中到服务端客户端只是“展示器”和“指令输入器”。1.2 选型思路Cocos Creator 与 Node.js 各自的优势Cocos Creator 能成为这类项目客户端首选最核心的原因还是它的编辑器对 2D 格斗、策略、卡牌场景支持相当成熟美术资源可以直接拖拽进场景UI 组件和动画系统基本够用一个新手用一两周就能把战斗场景搭起来。相比 UnityCocos Creator 更轻量导出微信小游戏、Web 版本也方便而且它对 JavaScript/TypeScript 的原生支持让前后端语言栈保持一致省掉了跨语言的心智负担。Node.js 这边选用它做服务端主要是两个理由第一事件驱动的单线程模型天然适配这种低并发、回合制、指令-响应模式的游戏不需要像实时对战 FPS 那样处理高频多人同步第二Node.js 和 Cocos Creator 都用 JavaScript/TypeScript协议结构甚至可以定义一份代码、两端共用省去大量联调时间。这个项目用 Node.js 的另一个隐性好处是部署门槛低。开发机上装了 Node.js 就能跑不需要额外装 Tomcat 或者 Nginx本地测试阶段直接node server.js就能起服务配合 VSCode 的调试面板可以断点看协议数据。如果后续要上线也很容易部署到国内厂商的云服务器上。我个人的建议是如果你的比赛或毕设只要求“能运行、能演示”用 Node.js 自带的http模块或ws模块就够了不需要引入 Express如果后续打算扩展大厅、匹配、房间管理等功能再升级到 Express 或 Socket.IO 也不迟。分清阶段别一上来就过度设计。2. 客户端开发VSCode Cocos Creator 环境搭建与场景实现2.1 开发环境配置要点这个项目的开发环境是 VSCode Cocos Creator Node.js我按实际踩过的坑一个个说清楚。Node.js 方面我推荐安装 LTS 版本不需要追最新版。这个项目本身对 Node 版本没有硬性要求但如果你现场装的是 v24.xnpm 默认策略可能会导致一些旧依赖报错。实际操作时建议下载官方 LTS 版本安装时全部默认选项安完在终端里执行node -v和npm -v能正常打印版本号就算装好了。环境变量在 Windows 下安装器会自动配置不需要手动设置。Cocos Creator 方面注意版本匹配。Cocos Creator 3.x 和 2.x 的项目结构差异很大如果你打开项目时看到的是 2D 还是 3D 的区别多半是版本不一致导致的。这类双人对战小游戏2.4.x 版本已经足够而且 2.4.x 对 JavaScript 的兼容性更好网上教程资料也更多。如果你团队用的是 3.8.x那必须保持全员统一版本否则打开项目会直接失败。VSCode 配置时核心工作是让 Cocos Creator 的代码跳转和补全生效。Cocos Creator 在编辑器中可以设置“外部脚本编辑器”把它指向 VSCode 的安装路径在 VSCode 中则建议安装官方推荐的扩展比如 ESLint 和 JavaScript/TypeScript 语法支持。我第一次配置时没设置外部编辑器结果项目脚本在 VSCode 里打开全是一片空白也没有代码高亮折腾了半小时才发现是关联问题。2.2 场景搭建与战斗 UI 核心结构打开 Cocos Creator 后新建一个 2D 场景把 Canvas 的分辨率设置成你目标平台的比例比如 Web 版就适配 1280x720。然后在这个场景里按从底到顶的顺序搭建背景层一张战斗背景图可以后续换成暗色渐变色块占位角色层左右两侧各放一个角色节点挂上立绘精灵设置好锚点和缩放血条层每个角色头顶放一个进度条用ProgressBar组件实现初始设为满值日志层战斗日志用只读的ScrollView或Label列表记录每回合的行动描述操作层底部放四个技能按钮每个按钮绑定一个技能 ID这里有个容易忽略的细节Cocos Creator 的 UI 节点默认使用 UITransform 组件如果你想让血条按比例减少需要给 ProgressBar 设置好 Bar Sprite 的方向比如从右侧向左侧收缩。之前有学员把方向设反了结果回血的时候进度条反而是反向的。技能按钮的事件绑定也很重要。Cocos Creator 的 Button 组件自带Click Events数组可以直接把目标节点和对应的脚本方法拖进去。我这边的做法是给每个按钮设置Name属性为skill_1、skill_2等然后在脚本里用node.on(click, this.onSkillClick, this)统一监听再根据按钮名分辨技能 ID这样比每个按钮都单独绑定方法好维护得多。2.3 客户端战斗流程脚本设计客户端脚本的核心职责是“表达服务端下发的状态变化”而不是自己计算战斗。大概流程是页面加载后通过 WebSocket 连接服务端发送join消息服务端返回match_ready界面进入“准备战斗”状态玩家点击技能按钮客户端立即在本机播放一个“选择中”的 UI 反馈比如按钮变灰把技能 ID 封装成消息发送给服务端收到服务端round_result后按数据结构刷新双方血条、蓝量、状态和战斗日志这段脚本里最容易出问题的地方在第 5 步。因为服务端返回的是一个完整的战斗状态快照而不是增量变化所以客户端做状态刷新时应该用全量覆盖式写法直接this.hpLabel.string msg.hp.toString()而不是this.hp - msg.damage。一旦用了累减逻辑如果中间丢了一条协议客户端状态就和服务端对不上了后面每一轮都是错的。我这边给客户端脚本拆成三个文件NetworkMgr.ts专门管 WebSocket 连接和消息收发BattleView.ts管 UI 刷新和动画BattleData.ts管本地缓存的战斗状态。这样分工有个好处后续如果要加“断线重连”或“回放系统”只需要改NetworkMgr和BattleData两个文件UI 层代码几乎不用动。3. 服务端开发Node.js 回合判定与状态同步服务端是整个项目的大脑也是代码量看似不多但逻辑最密集的部分。这个项目中“双人对战”四个字的核心其实就是服务端维护一局战斗的状态机从WAITING到BATTLE到FINISHED中间每一回合的判定都必须清晰无误。3.1 搭建最小可用的 WebSocket 服务如果你只是做本地联调不需要上 Socket.IO直接用ws这个轻量库就能满足需求。先用npm init -y初始化项目然后npm install ws写一个简单的 server 入口const WebSocket require(ws); const wss new WebSocket.Server({ port: 8080 }); const rooms new Map(); // roomId - { players: [], state: {} } wss.on(connection, (socket) { socket.on(message, (data) { const msg JSON.parse(data.toString()); handleMessage(socket, msg); }); socket.on(close, () { handleDisconnect(socket); }); });注意几个细节。第一port不要用 80 或 443避免权限问题第二handleMessage里一定要做 JSON.parse 的 try-catch不然收到非法消息整个进程会直接崩掉第三rooms这个 Map 可以用roomId作为 keyvalue 里再保存两个玩家各自的 socket 对象和当前战斗状态。如果要让两个玩家匹配到同一局最简单的做法是服务端维护一个“等待队列”数组第一个玩家连上后先放进去第二个玩家连上时从队列头部取一个配对然后新建一个房间把两个 socket 都放进房间。这样实现的大厅逻辑虽然简陋但确实能在演示阶段跑通双人对战。3.2 回合状态机与伤害计算逻辑回合制战斗的状态机是这个项目的灵魂。我推荐把整个流程定义成七个阶段ROUND_START广播本回合开始重置本回合标记WAIT_ACTION等待两名玩家提交指令超时则按“防御”处理RESOLVE_ACTION解析两人提交的行动确定先后手通常速度高者先动EXECUTE_SKILL依次执行技能效果计算伤害、治疗、附加状态CHECK_DEATH检查血量是否归零归零则进入FINISHEDSYNC_STATE将最新战斗状态广播给双方NEXT_ROUND回合数加一回到ROUND_START实际编码时用 switch-case 或状态模式都可以但关键是每一轮的状态变更必须在服务端串行执行不要为了“提升性能”去异步并发处理两个人的行动指令。回合制游戏本身就不追求并发串行执行反而容易保证正确性。伤害计算部分我这边用的是经典公式物理伤害 攻击力 * 技能倍率 - 防御力 * 0.5保底伤害为 1。这个公式看着简单但放在服务端有一个特别重要的点是不要用随机数裸奔。如果你直接用Math.random()服务端崩溃重启后同样的输入可能产生完全不同的战斗结果导致回放功能失效。稍微稳妥的做法是在房间创建时生成一个随机种子之后每回合的随机数都从这个种子按固定算法派生。function calculateDamage(attacker, target, skill) { const base attacker.atk * skill.multiplier - target.def * 0.5; const variance getPseudoRandom(room.seed, room.round) * 0.1; return Math.max(1, Math.round(base * (1 variance))); }这里getPseudoRandom是一个纯函数输入种子里和回合数输出一个固定值。这样即使服务端中途挂了只要用相同种子重建房间战斗可以精确回放。3.3 超时处理与掉线应对回合制联机游戏最常见的体验问题就是“对手不行动”。如果你不做超时机制一局游戏会因为一个人挂机而永远卡住。我建议在WAIT_ACTION阶段设置一个 15 秒的定时器超时后自动提交一个“跳过”动作相当于防御然后进入下一阶段。实践中这个超时判定写在服务端比写在客户端靠谱得多因为客户端靠不住用户可能直接锁屏。掉线处理稍微复杂一点。服务端在socket.close事件里应该清理该玩家所属房间并给对手广播opponent_left消息。这里有个经验消息广播要带一个房间内玩家标识比如playerId这样对手接到掉线通知时可以显示“敌方中断连接你赢了”。如果不区分玩家掉线时你根本不知道是谁掉的处理起来就会很混乱。4. 脚本联调协议设计、数据同步与调试技巧前后端联调是整个项目最费时间也最容易出坑的阶段但这个项目把前后端语言统一成 JavaScript/TypeScript 之后联调工作已经轻松了很多。4.1 通信协议格式设计协议设计要遵循“结构稳定、字段清晰、方便扩展”三个原则。我这边定义了一套基础的消息格式{ type: round_result, data: { round: 3, attacker: player_1, skillId: 2, damage: 157, player1: { hp: 843, mp: 30, state: normal }, player2: { hp: 620, mp: 45, state: poisoned } } }type字段决定客户端走哪个处理函数data是具体载荷。注意服务端广播给双方的消息应该是一致的不要给玩家A发一份改了数值的消息又给玩家B发另一份这会导致双方看到的结果不一样演示时非常尴尬。哪怕是只有自己知道的信息比如对方的技能冷却也应该在服务端先用统一的逻辑算好再发给双方展示。为了避免前后端协议字段对不上我建议在项目根目录建一个protocol.js文件专门维护消息常量和方法客户端和服务端同时引用同一份定义。比如const MSG_JOIN join两边的switch-case都用这个常量这样每次改协议只需要改一个地方。4.2 浏览器端网络调试三板斧这个项目联调时VSCode Chrome 开发者工具是我最常用的调试组合。Chrome 的 Network 面板里可以查到 WebSocket 的帧信息每一条消息的收发都能看到。我在实际排查中总结了三招第一招看帧级别。Network 面板下选择 WS 类型点开具体连接可以看到每个 message 帧的时间戳和 payload。如果客户端点击技能后没有对应帧发出去说明按钮点击或事件绑定有问题如果发送了帧但服务端没回说明服务端处理逻辑或路由有问题。第二招加日志指纹。在协议消息里加一个自增的seq字段前后端都打印出来。一旦发现客户端发出的最后一条 seq 和服务端收到的最后一条不一致就知道消息在传输中丢失了可以快速定位是发送端还是接收端的问题。第三招强打轮询。WebSocket 不像 HTTP 那样有请求-响应一一对应关系所以调试时最容易出现“不知道服务端挂在哪一步”。我通常的做法是在消息处理的每个关键阶段都打一行带当前房间号、回合号、玩家号的日志这样打开服务端控制台一眼看过去整个流程跟看状态机流水线一样。4.3 双开本地验证与演示技巧本地演示时没有两台电脑怎么办最省事的办法是打开两个浏览器窗口分别登录两个角色。这里有个坑要提醒如果两个页面用同一个浏览器完全相同的 ProfileWebSocket 连接可能会复用同一个 Session导致服务端把两次连接当成同一个玩家处理。我建议用“普通窗口 隐私窗口”的组合因为隐私窗口的 Session 完全独立相当于两个不同的客户端。如果是在同一个浏览器里双开还要注意 Cocos Creator 预览时的资源缓存问题。两个预览窗口同时打开同一个比赛开发者工具的 console 里可能会出现各种跨域或缓存警告这不一定影响逻辑正确性但会干扰你排查错误。我这边更推荐的做法是一个窗口用 Cocos Creator 预览发开者模式运行另一个窗口直接编译成 Web 版本用 Chrome 打开 dist/index.html。两条路径互不干扰调试信息也更清晰。5. 常见问题与排查技巧实录5.1 VSCode 和 Cocos Creator 的联调配置问题先说说 VSCode 相关的最典型问题。很多小伙伴在 VSCode 里打开 Cocos Creator 项目的assets文件夹时发现代码高亮和补全都不生效。这通常不是代码问题而是你打开项目的方式不对Cocos Creator 的脚本不应该单独以文件方式打开而是应该把整个项目文件夹作为 VSCode 的根目录打开这样 Cocos Creator 生成的.meta文件和 tsconfig 配置才能被 VSCode 正确加载。另一个常见问题是 VSCode 里node命令无法识别报node 不是内部或外部命令。这多半是安装 Node.js 时没把安装目录加到系统 PATH或者 VSCode 没重启。按我几次帮别人解决的经验装完之后一定要完全关闭 VSCode 再重新打开终端才会加载新的环境变量。同理如果你用 nvm 管理多个 Node 版本需要在终端里确认当前版本是你想要的nvm list查看已安装版本nvm use 22.13.0切换版本。5.2 Node.js 版本与依赖安装的坑这个项目的服务端依赖相对简单主要就是ws一般不会遇到大的安装障碍。但如果你在npm install时看到node-gyp或visual studio build tools报错多半是某些依赖需要本地编译。这一类问题在这个项目里比较少见真碰上可以试试npm install --ignore-scripts绕过。还有一个小细节如果你用 npm 安装了ws后发现报警告比如Unhandled Promise Rejection这通常不是 ws 的问题而是你自己的socket.on(message)回调里抛了异常。把所有 JSON 解析和后续逻辑包在 try-catch 里能避免很大一部分“莫名其妙崩溃”的现场。我第一次做的时候没加 try-catch只要客户端发一个残缺的 JSON 字符串服务端进程直接退出场面十分狼狈。5.3 战斗同步不一致的排查思路如果遇到两个玩家看到血量不一致的情况我建议按照这个顺序排查先看服务端的日志确认广播给两个玩家的round_result消息内容是否相同再分别在两个客户端的 Network 面板里查看收到的消息内容是否相同如果客户端收到的内容一致但显示不一致那就是客户端刷新逻辑的问题了。这里我再强调一遍客户端刷新务必用全量快照而不是增量计算。增量计算意味着你默认“所有消息都到达并且按顺序到达”这在局域网环境下问题不大但在真正的公网环境里TCP 虽然保证消息不丢不乱序但 WebSocket 连接的中断和重连却可能导致状态脱节。全量快照的做法是哪怕客户端中途断线一秒重连后同步一次快照就恢复正确状态。5.4 演示现场最容易翻车的三个环节项目答辩或演示现场最容易出问题的地方有三个我每个都吃过亏写出来给大家避雷。第一个是端口被占用。在教室或宿舍演示时如果有其他服务占了 8080 端口Node.js 会直接报EADDRINUSE。开跑之前先netstat -ano | findstr 8080查一下或者直接换一个不常用的端口比如 9527。第二个是防火墙拦截。如果客户端连不上服务端但你用telnet 127.0.0.1 8080本机测试却是通的那就要检查 Windows 防火墙是否拦截了 Node.js 进程的入站连接。最省事的办法是允许 Node.js 通过防火墙或者在演示环境的局域网内临时关闭防火墙具体看演示网络的要求。第三个是电脑休眠导致连接中断。演示时如果电脑自动休眠WebSocket 连接一定会断。开始演示前把电源计划改成“从不休眠”或者外接电源连好这个小细节能让你避免一次大型事故。6. 扩展思路从简单对战到完整游戏框架这个项目的代码写完跑通之后完全可以作为后续更复杂游戏的骨架。如果只需要顺利交付上面的内容已经足够但如果你想再多做一些优化和扩展下面几个方向都是低成本高收益的。6.1 接入更完整的消息中间层现在房间和战斗逻辑都写在server.js里代码量大了之后会很难维护。一个自然的优化方向是把“匹配-房间-战斗”三层拆开匹配模块负责把两名玩家放在同一个房间房间模块负责维护连接生命周期战斗模块负责状态机和伤害计算。用模块化思路抽取之后后续加入观战、机器人、录像回放都会容易很多。6.2 增加本地存档和战斗日志导出很多课程设计或比赛项目都有“演示后提交日志”或“复盘战斗”的要求。现在服务端可以把每一回合的round_result按 JSON 格式追加写入文件做成一个简单的 CSV 或 JSONL 日志文件。这个日志文件既可以用来做自动化测试也可以直接作为项目报告的“数据支撑材料”比截图有说服力得多。6.3 补充 AI 机器人模式单机演示时如果找不到第二个真人玩家可以交给服务端做一个简单的 AI 机器人机器人每回合随机选择技能或者按固定策略优先用回复技能。AI 机器人逻辑其实不需要写在客户端直接在 Node.js 服务端模拟一个“虚拟玩家”即可这样前端代码完全不用改只要在匹配时允许机器人入房即可。我自己在实际操作中的体会是这类项目的核心价值不是“特效多华丽”而是前后端数据流转是否顺畅、逻辑是否自洽、演示是否稳定。把这三点做好哪怕 UI 朴素一点评委和用户都会觉得“这确实是一个能跑的双人对战游戏”而不是一个“看起来很酷但一操作就崩”的假把式。最后再分享一个小技巧把 Node.js 服务端启动命令写死成一个 npm script在package.json里配置start: node server.js每次演示前只要npm start就能起服务。配上 VSCode 的集成终端全程不用切窗口现场演示特别流畅。本文还有配套的精品资源点击获取