简介这是一款基于Cocos Creator开发的双人回合制对战小游戏源码包面向游戏开发初学者与前端工程师聚焦游戏系统设计、状态管理与交互逻辑实现等核心能力训练。资源包含完整可运行项目涵盖战斗流程控制、角色属性计算、技能释放判定及UI响应机制等典型小游戏模块适合用于课程实践、自学复现或二次开发参考。压缩包共553个文件含36个JavaScript逻辑脚本实现游戏主循环与事件驱动、150张PNG素材图、52个plist图集配置、14个Prefab预制体及若干JSON配置与Fire场景文件整体27.82MB结构清晰便于按功能模块快速定位学习。已有74人下载学习配套说明材料详实覆盖环境搭建VSCodeNode.jsCocos Creator、项目导入、关键代码注释与运行调试要点助力开发者高效理解回合制游戏架构设计与工程落地路径。 做游戏开发尤其是想做联机对战类游戏的人十有八九会卡在“环境配好了吗”这一步。今天我用一个小项目——基于 VSCode CocosCreator Node.js 的双人对战回合制战斗游戏——把整条链路完整走一遍。客户端用 CocosCreator 搭场景和界面服务端用 Node.js 写 WebSocket 战斗仲裁VSCode 作为代码编辑和调试中枢最后实现两个浏览器进入同一房间、轮流出招、血条实时同步、胜负结算的完整对战闭环。这套组合适合刚学完基础语法、想找一个完整项目练手的新手也适合已经会 CocosCreator 但没碰过服务端联机的人。项目不大但该踩的坑一个不少。1. “简单”不等于简陋先把双人回合制的功能边界砍出来我先说一种很常见的失败模式新手想做“一个简单的回合制游戏”动手之后功能越加越多技能表、装备栏、地图切换、多角色切换最后项目烂在“功能堆了一堆、一次都没跑起来”的状态。我自己做这个项目时给自己定了三条硬约束后续所有设计都围绕它们展开。一局游戏不超过三分钟玩家不需要存档也不用考虑中途退出。双方用四则运算就能算清所有数值属性只保留 HP、攻击力、防御值外加一个恢复技能。不引入任何美术资源用 CocosCreator 自带的基础图形和色块就能完成表现。在这个约束下我圈定了一组最小可行功能功能说明必须/可选角色属性HP、攻击力、防御值必须回合操作攻击、防御、恢复必须回合顺序双方轮流行动服务端仲裁必须胜负判定HP 归零即判负必须房间匹配两名玩家进入同一局必须战斗表现血条变化、战斗日志、简单动画可选断线重连掉线后恢复战局可选第一版不做把“可选”项往后放不代表偷懒而是让核心链路先跑通。第一版把必须项做扎实后面加功能其实很快。很多项目烂尾不是能力问题是需求根本没收敛。1.1 一回合到底包含什么“回合”是整个战斗系统的最小单元这个概念必须定义清楚否则客户端和服务端的逻辑都会乱成一团。我这里的定义是一回合等于双方各行动一次。行动顺序固定开局时由服务端随机决定谁先手。玩家A行动完服务端结算并广播结果再切到玩家B行动B行动完结算这一回合才算结束。这个定义的好处是数据结构非常纯粹。服务端只要维护一个currentTurn: a | b字段等待当前行动方把指令发过来校验通过后执行战斗计算再翻转字段。不需要行动点、优先度、速度值这些概念整个战斗仲裁逻辑可以收敛在几十行代码以内。1.2 功能可以砍但这些硬需求不能省有些东西看着像“可选”其实是底线。服务端校验。哪怕只有两个玩家也不能让客户端算完伤害直接广播。否则有人打开 DevTools 改一行代码就能把自己血量改成无限。防连点。客户端要锁定按钮服务端也要做幂等校验——同一个回合重复收到的指令直接忽略。双方状态同步。一方血条变化必须实时出现在另一方屏幕上这要求通信协议带完整的结算数据而不是只发一个触发信号。这三条不是功能膨胀而是帮你省掉后面排错的返工时间。第一版就做好后面加功能不用回头补地基。2. 为什么是这三件套VSCode、CocosCreator、Node.js 的项目分工很多人的第一反应是CocosCreator 自带代码编辑器为什么还要用 VSCodeNode.js 在项目里到底干嘛我把这套组合拆开讲清楚。2.1 VSCode 负责“写代码”这一层CocosCreator 内置的代码编辑器体验比较基础补全和跳转都一般。我的做法是用 VSCode 直接打开 CocosCreator 的项目根目录所有 TypeScript 脚本在 VSCode 里写保存后切回 CocosCreator 按 CtrlR 刷新预览。CocosCreator 3.x 会自动监测到脚本变化并重新编译不需要手动触发。VSCode 这边要做几个配置安装 ESLint 和 Prettier 插件统一代码风格避免两个玩家指前端两个客户端看着不同缩进的代码头皮发麻。确认项目根目录存在tsconfig.json。CocosCreator 3.x 生成的 tsconfig 默认把路径别名映射到assetsVSCode 会读取这个配置代码里的import { xxx } from /scripts/xxx才能正常跳转。调试不用 VSCode 的复杂 attach 配置直接开浏览器 DevTools。CocosCreator 预览页的脚本是运行时加载的在 Sources 面板里能看到assets下的源码打断点比 IDE 集成更直接。2.2 CocosCreator 负责“看得见”的部分我用的是 Cocos Creator 3.8.x这个版本对 TypeScript 的支持比较完整。它在这个项目里承担三件事场景搭建、组件系统、最终构建发布。场景搭建就是把 Canvas 下的节点摆好——玩家信息、血条、按钮、战斗日志面板全都是可视化操作。组件系统是指每个 UI 区域挂一个继承Component的脚本各管各的。构建发布则是最后打包成 Web 版部署。这里有个经验之谈不要在编辑器里堆一堆组件引用再在某个巨型脚本里把所有节点串起来。组件之间用事件或者共享的客户端状态管理器通信后面维护会轻松很多。项目虽小但代码组织方式会直接影响你冲刺阶段的心情。2.3 Node.js 负责当裁判双人对战要联网就必须有一个角色当裁判它知道双方血量、当前轮到谁、攻击造成了多少伤害。这个裁判放在客户端里是不可能的因为两个客户端各自为政没有统一的事实来源。所以需要 Node.js 写一个 WebSocket 服务器充当权威仲裁方。为什么是 WebSocket 而不是普通 HTTP 接口回合制战斗交互虽然不频繁但双方需要实时感知对方的状态——血条、是否正在行动、是否掉线。WebSocket 的全双工通道天然适合“一方的操作立刻推送到另一方”。HTTP 需要客户端轮询最差情况下会有一回合的延迟代码复杂度也更高要处理请求竞态和轮询状态机。Node.js 在 WebSocket 生态上非常成熟ws库是事实标准API 简洁到几乎没有学习成本。2.4 三件套的日常协作流VSCode 里同时打开两个目录CocosCreator 客户端项目assets/scripts和服务端项目server。整个开发流是VSCode 里写服务端代码和客户端代码服务端跑node index.js监听一个端口我用的 8080CocosCreator 启动预览浏览器打开游戏页再开一个浏览器标签页模拟第二名玩家两个人就能对战本地验证没问题用 CocosCreator 构建 Web 版部署到任意静态服务器Node.js 服务端部署到云主机就变成一个真实可访问的联机游戏。3. 战斗核心出招流程、状态机与数值公式的设计过程战斗系统是项目里最值得细讲的部分。它不只是一堆 if/else而是一个有状态、有时序、有边界条件的系统。状态机理不清楚后面加动画、加校验都会乱成一团。3.1 服务端和客户端各自的状态机服务端维护每个房间的战斗状态enum BattleState { WaitForPlayer 0, // 房间已创建等待第二名玩家 PlayerA_Turn 1, // 轮到玩家A行动 PlayerB_Turn 2, // 轮到玩家B行动 RoundSettled 3, // 回合结算中过渡状态 GameOver 4 // 游戏结束 }我把“回合结算”也作为一个独立状态虽然它可能只持续几毫秒。这是为了防止结算过程中客户端新指令进来造成竞态——服务端在结算状态直接忽略一切行动消息简单粗暴且有效。客户端状态机会复杂一点因为要管输入锁定和动画播放type ClientState | { phase: idle } // 等待自己操作 | { phase: waiting_server } // 已出招等结算 | { phase: playing_animation } // 正在播放动画 | { phase: waiting_opponent } // 等待对方出招 | { phase: game_over, winner: number }; // 游戏结束客户端状态转移规则idle-waiting_server点击攻击/防御/恢复按钮发出指令waiting_server-playing_animation收到服务端结算广播playing_animation-waiting_opponent或idle动画播放完毕根据nextTurn判断是否轮到自己任意状态 -game_over收到gameOver: true。3.2 一回合的完整出招链路以玩家A攻击玩家B为例完整消息流是这样的玩家A点击“攻击”按钮客户端把所有按钮置灰发送{ type: action, action: attack }服务端收到后先校验当前状态是否是 PlayerA_Turn该连接是否属于玩家A都通过才执行战斗计算。服务端算完把结算结果广播给双方{ type: battle_result, round: 1, actor: a, action: attack, damage: 12, targetHp: 38, targetMaxHp: 50, nextTurn: b, gameOver: false }两个客户端同时收到这条消息各自播放表现。玩家A播攻击动画和敌方掉血玩家B播受击动画和己方掉血。这里的关键是双方使用的是完全相同的结算数据不需要任何一方去猜对方状态。这个设计避免了大量同步 bug。3.3 数值公式不能一轮刮痧也不能一轮秒人这个项目只有三种行动数值设计就非常重要否则很容易出现“防御没用”“恢复太强”的体验问题。我采用的公式如下攻击damage max(1, attacker_attack - defender_defense)防御本回合不造成伤害受到的下一次攻击伤害减半只抵挡一次。服务端用defending true标记结算时检测到防御方带标记伤害减半并清除标记。恢复heal round(maxHp * 0.15)本回合不能攻击。恢复有“机会成本”——选了恢复就不能输出等于白送对方一个输出窗口。初始属性双方hp50, attack21, defense5。验证一下平衡性普攻伤害是max(1, 21-5)16三刀带走半血节奏合适如果连续防御攻击方第一回合打 16第二回合触发减伤只能打 8两回合共 24防御方不至于被一波带走恢复一次加 8 点血换来一回合放弃输出。从数学上看恢复在低血量时性价比很高但释放时机很难拿捏这就是策略深度。这种简单公式的好处是即使不写单元测试手动跑几局也能感知到平衡性。真要写测试也容易构造边界用例比如连续防御一百回合。3.4 防御状态不要跨回合残留这里有一个我踩过的小坑defending标记如果不在回合结束清理就会出现“玩家A上回合点了防御结果这回合攻击力也减半”的诡异情况。我的处理是任何行动被执行后先采集对方当前是否有 defending 标记再计算伤害最后无论是否触发减伤都清除标记。也就是说防御效果只持续到“对方下一次成功的行动结算”为止。这个逻辑看起来简单但实现时一定要放在仲裁函数的最前面而不是散落在各个分支里否则很容易漏掉某条路径。4. Node.js 服务端用 WebSocket 从零搭一个房间仲裁器服务端是这个项目的发动机也是很多纯前端开发者最陌生的一块。我第一次用 Node.js 写 WebSocket 服务时最大的困惑是到底要建几个文件代码长什么样4.1 项目结构与依赖按职责拆三个文件不要全部塞进index.jsserver/ package.json index.js // 创建 WebSocketServer处理连接生命周期 roomManager.js // 房间管理等待配对、创建房间、销毁房间 battleSystem.js // 战斗计算纯函数不依赖 WebSocket 对象package.json只需要一个依赖{ name: battle-server, version: 1.0.0, main: index.js, dependencies: { ws: ^8.16.0 } }启动命令是node index.js。不需要构建工具不需要 babelNode 18 直接跑。为什么用ws而不是socket.io因为socket.io虽然用了很爽但协议较重对这个小项目来说属于杀鸡用牛刀。ws能让开发者理解 WebSocket 协议的底层细节学到的东西更多。4.2 战斗计算必须拆成纯函数这是我最想强调的设计战斗仲裁逻辑不要依赖任何 WebSocket 连接对象。原因很简单战斗计算是项目里最需要被反复测试的逻辑一旦它和网络层耦合在 Node 环境里跑单元测试都困难。我把battleSystem.js写成纯函数模块输入是双方属性和行动输出是结算结果。// battleSystem.js简化版 function settle(battleState, action) { const attacker battleState.currentTurn a ? battleState.playerA : battleState.playerB; const defender battleState.currentTurn a ? battleState.playerB : battleState.playerA; const result { type: battle_result, round: battleState.round, actor: battleState.currentTurn, action: action.type, damage: 0, nextTurn: null, gameOver: false }; if (action.type attack) { // 先看防御标记再算伤害 let damage Math.max(1, attacker.attack - defender.defense); if (defender.defending) { damage Math.max(1, Math.floor(damage / 2)); } defender.hp Math.max(0, defender.hp - damage); defender.defending false; result.damage damage; result.targetHp defender.hp; result.targetMaxHp defender.maxHp; } else if (action.type defend) { attacker.defending true; result.targetHp attacker.hp; result.targetMaxHp attacker.maxHp; } else if (action.type heal) { const heal Math.round(attacker.maxHp * 0.15); attacker.hp Math.min(attacker.maxHp, attacker.hp heal); result.heal heal; result.targetHp attacker.hp; result.targetMaxHp attacker.maxHp; } if (defender.hp 0) { result.gameOver true; result.winner battleState.currentTurn; } else { // 翻转回合 battleState.round 1; battleState.currentTurn battleState.currentTurn a ? b : a; result.nextTurn battleState.currentTurn; } return result; }注意这是简化版正式接入时还要补消息格式校验。但这个纯函数可以直接在 Node 里用node battleSystem.test.js跑几秒钟出结果不用启动服务器、不用开浏览器排错效率完全不一样。分层之后问题定位也清晰战斗数值不对先看纯函数网络连不上再查 WebSocket 生命周期。两类问题互不干扰。4.3 房间管理双人配对的实现配对逻辑非常朴素class RoomManager { constructor() { this.waitingPlayer null; // 等待中的玩家 socket this.rooms new Map(); // roomId - 房间对象 } addPlayer(socket) { if (this.waitingPlayer) { const room this.createRoom(this.waitingPlayer, socket); this.rooms.set(room.roomId, room); this.waitingPlayer null; return room; } this.waitingPlayer socket; socket.send(JSON.stringify({ type: waiting })); return null; } }有一个细节很影响体验玩家A进入等待后服务端要给他发一条{ type: waiting }消息客户端收到后显示“正在匹配对手……”否则玩家A会以为游戏卡死了。第二个玩家进来后服务端广播game_start消息里面包含各自的角色编号a 或 b、对方昵称、初始血量。从这条消息开始双方进入战斗流程。4.4 消息路由与三道校验服务端收到一条消息大致流程是收到消息 - JSON.parse 包一层 try/catch - 按 type 分发 - action 类型消息 - 找到对应房间 - 调用 battleSystem.settle - 把结果广播给房间内两个 socket消息分发之前必须做三个校验这是服务端权威的核心连接不在任何房间直接拒绝行动指令不是当前轮次忽略并回一条{ type: error, message: not_your_turn }同一回合重复行动例如连点导致的重复消息。因为服务端已经进入“等待指令”状态第二次进来时battleState.currentTurn已经翻转到另一方校验会自然拦截。提示客户端可以做到防连点但本文还有配套的精品资源点击获取 使用VSCode、CocosCreator和Node.js开发双人回合制对战游戏
简介这是一款基于Cocos Creator开发的双人回合制对战小游戏源码包面向游戏开发初学者与前端工程师聚焦游戏系统设计、状态管理与交互逻辑实现等核心能力训练。资源包含完整可运行项目涵盖战斗流程控制、角色属性计算、技能释放判定及UI响应机制等典型小游戏模块适合用于课程实践、自学复现或二次开发参考。压缩包共553个文件含36个JavaScript逻辑脚本实现游戏主循环与事件驱动、150张PNG素材图、52个plist图集配置、14个Prefab预制体及若干JSON配置与Fire场景文件整体27.82MB结构清晰便于按功能模块快速定位学习。已有74人下载学习配套说明材料详实覆盖环境搭建VSCodeNode.jsCocos Creator、项目导入、关键代码注释与运行调试要点助力开发者高效理解回合制游戏架构设计与工程落地路径。 做游戏开发尤其是想做联机对战类游戏的人十有八九会卡在“环境配好了吗”这一步。今天我用一个小项目——基于 VSCode CocosCreator Node.js 的双人对战回合制战斗游戏——把整条链路完整走一遍。客户端用 CocosCreator 搭场景和界面服务端用 Node.js 写 WebSocket 战斗仲裁VSCode 作为代码编辑和调试中枢最后实现两个浏览器进入同一房间、轮流出招、血条实时同步、胜负结算的完整对战闭环。这套组合适合刚学完基础语法、想找一个完整项目练手的新手也适合已经会 CocosCreator 但没碰过服务端联机的人。项目不大但该踩的坑一个不少。1. “简单”不等于简陋先把双人回合制的功能边界砍出来我先说一种很常见的失败模式新手想做“一个简单的回合制游戏”动手之后功能越加越多技能表、装备栏、地图切换、多角色切换最后项目烂在“功能堆了一堆、一次都没跑起来”的状态。我自己做这个项目时给自己定了三条硬约束后续所有设计都围绕它们展开。一局游戏不超过三分钟玩家不需要存档也不用考虑中途退出。双方用四则运算就能算清所有数值属性只保留 HP、攻击力、防御值外加一个恢复技能。不引入任何美术资源用 CocosCreator 自带的基础图形和色块就能完成表现。在这个约束下我圈定了一组最小可行功能功能说明必须/可选角色属性HP、攻击力、防御值必须回合操作攻击、防御、恢复必须回合顺序双方轮流行动服务端仲裁必须胜负判定HP 归零即判负必须房间匹配两名玩家进入同一局必须战斗表现血条变化、战斗日志、简单动画可选断线重连掉线后恢复战局可选第一版不做把“可选”项往后放不代表偷懒而是让核心链路先跑通。第一版把必须项做扎实后面加功能其实很快。很多项目烂尾不是能力问题是需求根本没收敛。1.1 一回合到底包含什么“回合”是整个战斗系统的最小单元这个概念必须定义清楚否则客户端和服务端的逻辑都会乱成一团。我这里的定义是一回合等于双方各行动一次。行动顺序固定开局时由服务端随机决定谁先手。玩家A行动完服务端结算并广播结果再切到玩家B行动B行动完结算这一回合才算结束。这个定义的好处是数据结构非常纯粹。服务端只要维护一个currentTurn: a | b字段等待当前行动方把指令发过来校验通过后执行战斗计算再翻转字段。不需要行动点、优先度、速度值这些概念整个战斗仲裁逻辑可以收敛在几十行代码以内。1.2 功能可以砍但这些硬需求不能省有些东西看着像“可选”其实是底线。服务端校验。哪怕只有两个玩家也不能让客户端算完伤害直接广播。否则有人打开 DevTools 改一行代码就能把自己血量改成无限。防连点。客户端要锁定按钮服务端也要做幂等校验——同一个回合重复收到的指令直接忽略。双方状态同步。一方血条变化必须实时出现在另一方屏幕上这要求通信协议带完整的结算数据而不是只发一个触发信号。这三条不是功能膨胀而是帮你省掉后面排错的返工时间。第一版就做好后面加功能不用回头补地基。2. 为什么是这三件套VSCode、CocosCreator、Node.js 的项目分工很多人的第一反应是CocosCreator 自带代码编辑器为什么还要用 VSCodeNode.js 在项目里到底干嘛我把这套组合拆开讲清楚。2.1 VSCode 负责“写代码”这一层CocosCreator 内置的代码编辑器体验比较基础补全和跳转都一般。我的做法是用 VSCode 直接打开 CocosCreator 的项目根目录所有 TypeScript 脚本在 VSCode 里写保存后切回 CocosCreator 按 CtrlR 刷新预览。CocosCreator 3.x 会自动监测到脚本变化并重新编译不需要手动触发。VSCode 这边要做几个配置安装 ESLint 和 Prettier 插件统一代码风格避免两个玩家指前端两个客户端看着不同缩进的代码头皮发麻。确认项目根目录存在tsconfig.json。CocosCreator 3.x 生成的 tsconfig 默认把路径别名映射到assetsVSCode 会读取这个配置代码里的import { xxx } from /scripts/xxx才能正常跳转。调试不用 VSCode 的复杂 attach 配置直接开浏览器 DevTools。CocosCreator 预览页的脚本是运行时加载的在 Sources 面板里能看到assets下的源码打断点比 IDE 集成更直接。2.2 CocosCreator 负责“看得见”的部分我用的是 Cocos Creator 3.8.x这个版本对 TypeScript 的支持比较完整。它在这个项目里承担三件事场景搭建、组件系统、最终构建发布。场景搭建就是把 Canvas 下的节点摆好——玩家信息、血条、按钮、战斗日志面板全都是可视化操作。组件系统是指每个 UI 区域挂一个继承Component的脚本各管各的。构建发布则是最后打包成 Web 版部署。这里有个经验之谈不要在编辑器里堆一堆组件引用再在某个巨型脚本里把所有节点串起来。组件之间用事件或者共享的客户端状态管理器通信后面维护会轻松很多。项目虽小但代码组织方式会直接影响你冲刺阶段的心情。2.3 Node.js 负责当裁判双人对战要联网就必须有一个角色当裁判它知道双方血量、当前轮到谁、攻击造成了多少伤害。这个裁判放在客户端里是不可能的因为两个客户端各自为政没有统一的事实来源。所以需要 Node.js 写一个 WebSocket 服务器充当权威仲裁方。为什么是 WebSocket 而不是普通 HTTP 接口回合制战斗交互虽然不频繁但双方需要实时感知对方的状态——血条、是否正在行动、是否掉线。WebSocket 的全双工通道天然适合“一方的操作立刻推送到另一方”。HTTP 需要客户端轮询最差情况下会有一回合的延迟代码复杂度也更高要处理请求竞态和轮询状态机。Node.js 在 WebSocket 生态上非常成熟ws库是事实标准API 简洁到几乎没有学习成本。2.4 三件套的日常协作流VSCode 里同时打开两个目录CocosCreator 客户端项目assets/scripts和服务端项目server。整个开发流是VSCode 里写服务端代码和客户端代码服务端跑node index.js监听一个端口我用的 8080CocosCreator 启动预览浏览器打开游戏页再开一个浏览器标签页模拟第二名玩家两个人就能对战本地验证没问题用 CocosCreator 构建 Web 版部署到任意静态服务器Node.js 服务端部署到云主机就变成一个真实可访问的联机游戏。3. 战斗核心出招流程、状态机与数值公式的设计过程战斗系统是项目里最值得细讲的部分。它不只是一堆 if/else而是一个有状态、有时序、有边界条件的系统。状态机理不清楚后面加动画、加校验都会乱成一团。3.1 服务端和客户端各自的状态机服务端维护每个房间的战斗状态enum BattleState { WaitForPlayer 0, // 房间已创建等待第二名玩家 PlayerA_Turn 1, // 轮到玩家A行动 PlayerB_Turn 2, // 轮到玩家B行动 RoundSettled 3, // 回合结算中过渡状态 GameOver 4 // 游戏结束 }我把“回合结算”也作为一个独立状态虽然它可能只持续几毫秒。这是为了防止结算过程中客户端新指令进来造成竞态——服务端在结算状态直接忽略一切行动消息简单粗暴且有效。客户端状态机会复杂一点因为要管输入锁定和动画播放type ClientState | { phase: idle } // 等待自己操作 | { phase: waiting_server } // 已出招等结算 | { phase: playing_animation } // 正在播放动画 | { phase: waiting_opponent } // 等待对方出招 | { phase: game_over, winner: number }; // 游戏结束客户端状态转移规则idle-waiting_server点击攻击/防御/恢复按钮发出指令waiting_server-playing_animation收到服务端结算广播playing_animation-waiting_opponent或idle动画播放完毕根据nextTurn判断是否轮到自己任意状态 -game_over收到gameOver: true。3.2 一回合的完整出招链路以玩家A攻击玩家B为例完整消息流是这样的玩家A点击“攻击”按钮客户端把所有按钮置灰发送{ type: action, action: attack }服务端收到后先校验当前状态是否是 PlayerA_Turn该连接是否属于玩家A都通过才执行战斗计算。服务端算完把结算结果广播给双方{ type: battle_result, round: 1, actor: a, action: attack, damage: 12, targetHp: 38, targetMaxHp: 50, nextTurn: b, gameOver: false }两个客户端同时收到这条消息各自播放表现。玩家A播攻击动画和敌方掉血玩家B播受击动画和己方掉血。这里的关键是双方使用的是完全相同的结算数据不需要任何一方去猜对方状态。这个设计避免了大量同步 bug。3.3 数值公式不能一轮刮痧也不能一轮秒人这个项目只有三种行动数值设计就非常重要否则很容易出现“防御没用”“恢复太强”的体验问题。我采用的公式如下攻击damage max(1, attacker_attack - defender_defense)防御本回合不造成伤害受到的下一次攻击伤害减半只抵挡一次。服务端用defending true标记结算时检测到防御方带标记伤害减半并清除标记。恢复heal round(maxHp * 0.15)本回合不能攻击。恢复有“机会成本”——选了恢复就不能输出等于白送对方一个输出窗口。初始属性双方hp50, attack21, defense5。验证一下平衡性普攻伤害是max(1, 21-5)16三刀带走半血节奏合适如果连续防御攻击方第一回合打 16第二回合触发减伤只能打 8两回合共 24防御方不至于被一波带走恢复一次加 8 点血换来一回合放弃输出。从数学上看恢复在低血量时性价比很高但释放时机很难拿捏这就是策略深度。这种简单公式的好处是即使不写单元测试手动跑几局也能感知到平衡性。真要写测试也容易构造边界用例比如连续防御一百回合。3.4 防御状态不要跨回合残留这里有一个我踩过的小坑defending标记如果不在回合结束清理就会出现“玩家A上回合点了防御结果这回合攻击力也减半”的诡异情况。我的处理是任何行动被执行后先采集对方当前是否有 defending 标记再计算伤害最后无论是否触发减伤都清除标记。也就是说防御效果只持续到“对方下一次成功的行动结算”为止。这个逻辑看起来简单但实现时一定要放在仲裁函数的最前面而不是散落在各个分支里否则很容易漏掉某条路径。4. Node.js 服务端用 WebSocket 从零搭一个房间仲裁器服务端是这个项目的发动机也是很多纯前端开发者最陌生的一块。我第一次用 Node.js 写 WebSocket 服务时最大的困惑是到底要建几个文件代码长什么样4.1 项目结构与依赖按职责拆三个文件不要全部塞进index.jsserver/ package.json index.js // 创建 WebSocketServer处理连接生命周期 roomManager.js // 房间管理等待配对、创建房间、销毁房间 battleSystem.js // 战斗计算纯函数不依赖 WebSocket 对象package.json只需要一个依赖{ name: battle-server, version: 1.0.0, main: index.js, dependencies: { ws: ^8.16.0 } }启动命令是node index.js。不需要构建工具不需要 babelNode 18 直接跑。为什么用ws而不是socket.io因为socket.io虽然用了很爽但协议较重对这个小项目来说属于杀鸡用牛刀。ws能让开发者理解 WebSocket 协议的底层细节学到的东西更多。4.2 战斗计算必须拆成纯函数这是我最想强调的设计战斗仲裁逻辑不要依赖任何 WebSocket 连接对象。原因很简单战斗计算是项目里最需要被反复测试的逻辑一旦它和网络层耦合在 Node 环境里跑单元测试都困难。我把battleSystem.js写成纯函数模块输入是双方属性和行动输出是结算结果。// battleSystem.js简化版 function settle(battleState, action) { const attacker battleState.currentTurn a ? battleState.playerA : battleState.playerB; const defender battleState.currentTurn a ? battleState.playerB : battleState.playerA; const result { type: battle_result, round: battleState.round, actor: battleState.currentTurn, action: action.type, damage: 0, nextTurn: null, gameOver: false }; if (action.type attack) { // 先看防御标记再算伤害 let damage Math.max(1, attacker.attack - defender.defense); if (defender.defending) { damage Math.max(1, Math.floor(damage / 2)); } defender.hp Math.max(0, defender.hp - damage); defender.defending false; result.damage damage; result.targetHp defender.hp; result.targetMaxHp defender.maxHp; } else if (action.type defend) { attacker.defending true; result.targetHp attacker.hp; result.targetMaxHp attacker.maxHp; } else if (action.type heal) { const heal Math.round(attacker.maxHp * 0.15); attacker.hp Math.min(attacker.maxHp, attacker.hp heal); result.heal heal; result.targetHp attacker.hp; result.targetMaxHp attacker.maxHp; } if (defender.hp 0) { result.gameOver true; result.winner battleState.currentTurn; } else { // 翻转回合 battleState.round 1; battleState.currentTurn battleState.currentTurn a ? b : a; result.nextTurn battleState.currentTurn; } return result; }注意这是简化版正式接入时还要补消息格式校验。但这个纯函数可以直接在 Node 里用node battleSystem.test.js跑几秒钟出结果不用启动服务器、不用开浏览器排错效率完全不一样。分层之后问题定位也清晰战斗数值不对先看纯函数网络连不上再查 WebSocket 生命周期。两类问题互不干扰。4.3 房间管理双人配对的实现配对逻辑非常朴素class RoomManager { constructor() { this.waitingPlayer null; // 等待中的玩家 socket this.rooms new Map(); // roomId - 房间对象 } addPlayer(socket) { if (this.waitingPlayer) { const room this.createRoom(this.waitingPlayer, socket); this.rooms.set(room.roomId, room); this.waitingPlayer null; return room; } this.waitingPlayer socket; socket.send(JSON.stringify({ type: waiting })); return null; } }有一个细节很影响体验玩家A进入等待后服务端要给他发一条{ type: waiting }消息客户端收到后显示“正在匹配对手……”否则玩家A会以为游戏卡死了。第二个玩家进来后服务端广播game_start消息里面包含各自的角色编号a 或 b、对方昵称、初始血量。从这条消息开始双方进入战斗流程。4.4 消息路由与三道校验服务端收到一条消息大致流程是收到消息 - JSON.parse 包一层 try/catch - 按 type 分发 - action 类型消息 - 找到对应房间 - 调用 battleSystem.settle - 把结果广播给房间内两个 socket消息分发之前必须做三个校验这是服务端权威的核心连接不在任何房间直接拒绝行动指令不是当前轮次忽略并回一条{ type: error, message: not_your_turn }同一回合重复行动例如连点导致的重复消息。因为服务端已经进入“等待指令”状态第二次进来时battleState.currentTurn已经翻转到另一方校验会自然拦截。提示客户端可以做到防连点但本文还有配套的精品资源点击获取