简介面向Cocos Creator开发者和棋类游戏爱好者的一款中国象棋单机游戏完整工程电脑AI采用经典Alpha-Beta剪枝算法依据搜索深度与评估函数差异提供简单、普通、困难三档棋力适合课程设计、毕业答辩或作为游戏AI算法入门参考。整套资源共730个文件压缩包约17.89MB文件构成以70个prefab场景预制件、49个js逻辑脚本、184个png图片素材、219个json配置为主另有map、plist、ttf字体、mp4演示等分别承担界面布局、游戏逻辑、美术资源、数据配置和效果展示。已有1275人学习下载。工程实现从棋盘渲染、走子合法性校验到Alpha-Beta搜索层层递进Prefab与逻辑脚本分离结构清晰便于二次开发当前困难模式棋力已具备较强战力描述中提到一般人难以取胜且仍保留优化空间。通过源码可直观理解博弈树裁剪、评估函数设定、搜索深度等AI调参思路是结合Cocos Creator实战与棋类AI入门的好素材。 去年年底接了个私活用 Cocos Creator 做一款中国象棋小游戏要求能跑在微信小游戏上后续还要能打包成安卓 APK。说实话市面上现成的中国象棋开源项目不少但真到自己从零开始搭一套干净、能二次开发的工程还是有不少门道。这篇文章把我整个开发过程、核心系统的设计思路、AI 算法选型以及最后打 APK 时踩的坑都记录下来给准备用 Cocos Creator 做棋牌类项目或者想自己写一款象棋的朋友一个完整参考。1. 项目概述与整体思路1.1 为什么选择 Cocos Creator 做中国象棋先说结论如果目标是快速上线微信小游戏、抖音小游戏或者要同时覆盖安卓和 iOSCocos Creator 是目前综合成本最低的方案。做中国象棋这种 2D 棋盘游戏核心需求是场景管理、事件交互、动画过渡和跨平台打包Cocos Creator 的组件化开发模式、内置的 2D 渲染能力和一键发布到多端的工作流能省去大量底层适配时间。我最初也考虑过用纯 HTML5 Canvas 做个 H5 版本但后来发现几个绕不开的问题音频管理需要自己封装触摸事件的兼容性在不同浏览器上表现不一致而且后续要接微信小游戏 SDK 时DOM 操作会被砍掉一大截还得重写。用 LayaBox 也考虑过但社区活跃度和文档质量这几年明显不如 Cocos。最终选了 Cocos Creator 2.4.x LTS 版本原因很简单稳定、资料多、遇到问题基本都能搜到解决方案。1.2 项目功能范围与开发路线这次的目标是做一款功能完整的中国象棋单机版加上人人对战模式具体功能清单如下标准 9×10 棋盘绘制红黑双方 32 枚棋子的完整逻辑全部棋子的走法规则校验包括蹩马腿、塞象眼、将帅对脸、兵卒过河等细节胜负判定将死、困毙、认输单机对战同一设备双人轮流操作简单 AI 对战电脑走棋采用极大极小值搜索 Alpha-Beta 剪枝走棋音效、选中高亮、可行走位置提示最后导出 Android APK开发路线分三个阶段第一阶段搭建棋局数据核心和规则引擎不写界面先用日志验证所有规则正确第二阶段做场景和 UI 交互把棋局数据绑定到可视化棋盘上第三阶段加 AI、音效和打包配置。这个顺序非常关键规则引擎如果没测透就急着写界面后面排查 bug 会非常痛苦。2. 游戏核心系统架构设计2.1 棋局数据结构的建模方式中国象棋的棋盘是 9 列 10 行最直观的数据结构就是用一个二维数组 board[10][9] 来表示。数组下标从 0 开始board[0][0] 对应棋盘左上角。每个格子的值用整数表示0 表示无棋子正数表示红方棋子负数表示黑方棋子用绝对值区分棋子类型。比如我用 1 到 7 分别代表帅、仕、相、马、车、炮、兵那么红车就是 4黑车就是 -4。这种编码方式的优势在于判断归属方时只需要检查正负号判断棋子类型时取绝对值效率高且语义清晰。// 棋子类型常量 const PIECE { KING: 1, // 帅/将 ADVISOR: 2, // 仕/士 BISHOP: 3, // 相/象 KNIGHT: 4, // 马 ROOK: 5, // 车 CANNON: 6, // 炮 PAWN: 7 // 兵/卒 }; // 棋盘二维数组 private board: number[][] [];初始化时按照标准布局填充数组第 0 行是黑方车马象仕将仕象马车第 2 行是黑方炮第 3 行是黑方卒第 9 行是红方车马相仕帅仕相马车第 7 行是红方炮第 6 行是红方兵。这里有一个容易踩的坑数组的行列顺序。如果你把 board[row][col] 和屏幕坐标搞反整个棋盘的落子位置会全部错乱。我的做法是统一在逻辑层只用 row 和 col 两个整数和 UI 坐标的换算集中在单独的工具函数里业务逻辑绝不直接操作像素坐标。2.2 棋子走法规则校验的实现思路规则引擎是整个游戏的核心不能有半点马虎。我把它拆成两层第一层是生成某个棋子的所有合法落子位置第二层是校验某一步具体的走法是否合法。两层共用同一个getLegalMoves(row, col)函数AI 也复用它一举两得。每一种棋子的走法逻辑如下车沿上下左右四个方向直线行走遇到第一个棋子挡住去路时停止如果那个棋子的颜色与己方不同则该格可以吃。马走日字但需要检查蹩马腿。比如马从 (4,4) 走到 (3,2)需要确保 (4,3) 位置没有棋子。相/象走田字不能过河需要检查塞象眼。相从 (4,4) 走到 (2,2)需要确保 (3,3) 位置没有棋子。仕/士在九宫格内走斜线每次一步九宫格范围是列 3 到 5红方行 7 到 9黑方行 0 到 2。帅/将在九宫格内走直线上下左右一步规则上还有一个特殊判定帅和将不能在同一条竖线上直接照面中间没有其他棋子时属于非法局面。炮移动时和车一样走直线吃子时必须隔一个棋子炮架。兵/卒未过河时只能向前走一步过河后可以向前或左右走一步但永远不能后退。生成合法走子的伪代码如下方展示以马的为例function getKnightMoves(row: number, col: number): number[][] { const moves []; const directions [ { deltaRow: -2, deltaCol: -1, legDx: 0, legDy: -1 }, { deltaRow: -2, deltaCol: 1, legDx: 0, legDy: 1 }, { deltaRow: -1, deltaCol: -2, legDx: -1, legDy: 0 }, { deltaRow: -1, deltaCol: 2, legDx: 1, legDy: 0 }, { deltaRow: 1, deltaCol: -2, legDx: -1, legDy: 0 }, { deltaRow: 1, deltaCol: 2, legDx: 1, legDy: 0 }, { deltaRow: 2, deltaCol: -1, legDx: 0, legDy: -1 }, { deltaRow: 2, deltaCol: 1, legDx: 0, legDy: 1 } ]; for (const dir of directions) { const horseLegRow row dir.legDx; const horseLegCol col dir.legDy; // 蹩马腿判断 if (getPiece(horseLegRow, horseLegCol) ! 0) continue; const targetRow row dir.deltaRow; const targetCol col dir.deltaCol; if (isOutside(targetRow, targetCol)) continue; const targetPiece getPiece(targetRow, targetCol); if (targetPiece ! 0 sameSide(targetPiece, getPiece(row, col))) continue; moves.push([targetRow, targetCol]); } return moves; }规则校验我还加了一个非常重要的防御层走完一步后立即判断己方的帅是否被对方攻击。也就是说每一步走棋都会先模拟走子、再检测将军状态如果走到某个位置导致己方帅直接暴露在对方火力下这个落子位置必须过滤掉。这一步代码量不大但极大减少了后续 AI 搜索时判断合法局面的复杂度。3. 完整实操从创建项目到能玩的一盘棋3.1 场景搭建与资源准备在 Cocos Creator 里新建项目后我直接把场景分成三层结构背景层棋盘底图、棋子层32 个棋子节点、UI 层当前回合提示、按钮、胜负弹窗。棋盘底图我用的是美术给的一张 1080×1200 的 PNG这样在不同分辨率的屏幕上也能保持清晰。棋子的显示是关键。我用了一个棋子 Prefab每个棋子节点挂载一个PieceView组件组件上存着逻辑坐标 row 和 col以及棋子类型和归属方。为什么不用 32 个不同的图片素材因为用一张雪碧图 动态设置 SpriteFrame 的方式可以大幅减少资源体积对微信小游戏包体很友好。具体做法是项目 assets 里放一张包含所有棋子图案的图集红帅、红仕、红相……黑将、黑士、黑象一共 14 个图案排成一排每个棋子 Prefab 根据类型和颜色从这个图集里取对应的 SpriteFrame配合setSpriteFrame动态设置。// 棋子视图组件核心逻辑 const spriteFrames { red: [redKing, redAdvisor, redBishop, redKnight, redRook, redCannon, redPawn], black: [blackKing, blackAdvisor, blackBishop, blackKnight, blackRook, blackCannon, blackPawn] }; setPieceVisual(pieceType: number, isRed: boolean) { const index Math.abs(pieceType) - 1; const list isRed ? spriteFrames.red : spriteFrames.black; this.getComponent(Sprite).spriteFrame list[index]; }3.2 坐标换算从数组索引到像素位置这一步是新手最容易搞混的地方。棋盘矩阵的行列是整数但 Cocos 场景里节点坐标是浮点数而且锚点默认在中心。我的方案是写一个静态工具类BoardUtil负责两套坐标系统的互转const BOARD_ORIGIN_X -460; // 棋盘左上角在场景中的 x 坐标 const BOARD_ORIGIN_Y 480; // 棋盘左上角在场景中的 y 坐标 const CELL_WIDTH 115; // 每个格子的宽度 const CELL_HEIGHT 115; // 每个格子的高度 function boardToWorld(row: number, col: number): Vec2 { return new Vec2( BOARD_ORIGIN_X col * CELL_WIDTH, BOARD_ORIGIN_Y - row * CELL_HEIGHT ); } function worldToBoard(worldX: number, worldY: number): Vec2 { const col Math.round((worldX - BOARD_ORIGIN_X) / CELL_WIDTH); const row Math.round((BOARD_ORIGIN_Y - worldY) / CELL_HEIGHT); return new Vec2(row, col); }注意BOARD_ORIGIN_X和BOARD_ORIGIN_Y是根据棋盘底图在实际运行中的位置测量出来的。更稳妥的做法是直接读取棋盘节点的getPosition()方法动态取值而不是写死常数。我后来重构时把它改成了基于棋盘节点位置的相对计算这样换不同分辨率的棋盘底图时不需要改代码。3.3 触摸交互与回合管理交互逻辑用到了 Cocos Creator 的节点事件系统。每个棋子节点上注册了Node.EventType.TOUCH_START事件手指或鼠标点击棋子后先判断当前是不是该方回合如果是就高亮选中棋子并调用getLegalMoves获取所有可走位置在可走位置上生成半透明红色圆点提示。点击棋盘空白处时判断当前是否处于“已选中棋子”的状态如果是则尝试走棋。走棋前先判断点击的位置是否在合法走子列表里如果在就执行移动如果没有则取消选中状态。回合管理这块我用了最简单的单例模式一个GameController组件挂在 Canvas 节点上持有当前回合标识currentTurn初始值为红方。每次成功走棋后切换currentTurn。真正做 AI 对战时只需要在切换回合时判断当前回合是不是 AI 方如果是则延迟 0.5 秒后调用 AI 搜索接口。需要注意的一点在移动棋子时不要直接操作 worldPosition而是先更新逻辑数组board再根据新的 row、col 调用boardToWorld来设置节点位置。先更新逻辑再刷新视图可以保证数据和显示永远一致避免两个系统之间的状态不同步。4. AI 对战功能的实现思路4.1 走法生成与局面评估函数做 AI 之前必须先有一个评估函数来打分。我的评估函数分两部分基础子力价值加上位置调整值。子力价值参考了象棋圈一些开源引擎的做法车 1000 分、马 450 分、炮 500 分、相 200 分、仕 200 分、兵 100 分、帅 10000 分。位置调整值则根据不同棋子在不同位置的威胁程度粗略定义比如车在开阔地带加分兵过河后加分。评估函数返回的值是红方视角的分值如果返回正数表示红方占优负数表示黑方占优。这个符号方向要和 AI 的搜索逻辑配合好。4.2 极小极大值算法与 Alpha-Beta 剪枝AI 搜索我采用了经典的极小极大值算法加 Alpha-Beta 剪枝。通俗理解红方走棋时会选择对自己最有利的分支黑方走棋时会选择对红方最不利的分支。但在 32 个棋子的局面下搜索树的节点数量是巨大的所以需要剪枝来砍掉不值得搜索的分支大幅缩小搜索空间。深度我设置的是 3 层红方走一步、黑方走一步、红方再走一步并在叶节点调用评估函数。这个深度在实际运行时大概需要 200 到 500 毫秒的反应时间对休闲棋类游戏来说正好。function alphaBeta(depth: number, alpha: number, beta: number, isRedTurn: boolean): number { if (depth 0) { return evaluate(); } const moves generateAllMoves(isRedTurn); if (moves.length 0) { // 无棋可走返回极端分数 return isRedTurn ? -100000 (MAX_DEPTH - depth) : 100000 - (MAX_DEPTH - depth); } if (isRedTurn) { let maxEval -Infinity; for (const move of moves) { makeMove(move); const evalScore alphaBeta(depth - 1, alpha, beta, false); unmakeMove(move); maxEval Math.max(maxEval, evalScore); alpha Math.max(alpha, evalScore); if (beta alpha) break; // 剪枝 } return maxEval; } else { let minEval Infinity; for (const move of moves) { makeMove(move); const evalScore alphaBeta(depth - 1, alpha, beta, true); unmakeMove(move); minEval Math.min(minEval, evalScore); beta Math.min(beta, evalScore); if (beta alpha) break; } return minEval; } }这里有个关键优化generateAllMoves里要先把所有合法走法按当前局面的静态评估排序从优到劣排列因为 Alpha-Beta 剪枝的效率高度依赖于搜索顺序越早发现最优走法剪掉的无效分支就越多。我在实现时先对每个走法做了个粗略排序速度提升了将近一倍。深度和性能之间是个平衡。3 层搜索在主力机上表现不错但在低端安卓手机上可能略卡。如果后续要加深到 4 层或 5 层可以考虑引入置换表来缓存已经算过的局面评分或者在走法排序上做得更精细一点。5. 打包安卓 APK 的完整踩坑指南5.1 环境配置与 Cocos Creator 构建流程很多人在 Cocos Creator 里写好游戏后卡在打包 APK 这一步。先说下我这边成功跑通的配置环境Cocos Creator 2.4.9Android Studio 4.2 以上Android SDKAPI Level 21 到 30Android NDK r21eGradle 6.5 以上在 Creator 里点击“项目” - “构建发布”平台选择“Android”填好包名和应用名称后构建生成一个 Gradle 工程。关键的一步是需要在构建面板里配置好 SDK 和 NDK 路径。很多小白会直接在 Creator 里默认路径找不到 SDK这里可以在“偏好设置”里手动指定 SDK 路径。5.2 构建过程中的常见报错与解决方案我这次打包过程中遇到的几个比较典型的报错具体如下第一个是NDK 版本不匹配。Cocos Creator 2.4.x 对高版本 NDK 的兼容性并不好我一开始用了 NDK r23编译时直接报“unknown option”之类的错误。换成 NDK r21e 后问题立刻消失。提醒一下不要在 “local.properties” 或环境变量里同时配两套 SDK 路径否则 Gradle 会直接混乱。第二个是Gradle 下载依赖超时。国内网络环境从 Maven Central 或 Google 仓库下载依赖经常失败。解决方法是把 Gradle 的仓库地址换成阿里云镜像。在build.gradle里把google()和mavenCentral()后面加上阿里云的镜像地址allprojects { repositories { google() mavenCentral() maven { url https://maven.aliyun.com/repository/public } maven { url https://maven.aliyun.com/repository/google } } }这样构建速度立马上来。第三个是打包后安装到手机闪退。这个问题大概率是架构和 SDK 版本不匹配导致的。在构建发布面板中CPU 类型记得勾选 armabi-v7a 和 arm64-v8a对得上现在绝大多数主流手机。签名相关配置建议直接用 Android Studio 生成一个 keystore然后在构建发布面板里配置好避免后期要做正式发布时再来补签名。注意打包 APK 之前一定要先在浏览器和微信开发者工具里分别跑一遍完整流程确认无编译错误和资源加载问题再开始走原生打包流程否则一旦混在一起排错会让你怀疑人生。6. 常见问题与优化心得6.1 走棋逻辑的经典 Bug被将军仍能走棋整个项目中我遇到的最典型的逻辑 bug也是刚写规则引擎时最容易犯的错误游戏中被将军的一方仍然可以走一步毫不相关的棋。原因是没有在规则校验中加上“走完不能让自己被将军”这一层判断。后来我在movePiece方法里加了一个统一的校验先模拟走子再用攻击检测函数判断当前方的帅将是否处于被攻击的状态如果是则判定这步棋非法。这样所有走法都自动带上了“不能送将”的属性规则完整性大幅提升。6.2 资源加载与内存管理的优化建议Cocos Creator 中如果每次动态创建棋子节点而不回收长时间对战后内存会缓慢增长。我的方案是初始创建 32 个棋子节点放到一个节点池Node Pool里走棋时只要更新棋子的位置和 SpriteFrame不销毁节点。吃掉的棋子不做 destroy而是隐藏并标记为不可见需要悔棋功能时直接改位置显示即可省去了反复创建的开销。用节点池配合隐藏显隐整体内存表现很稳定即使连续玩十局也不会有明显卡顿。6.3 适配不同屏幕比例的布局方案在手机横屏下不同机型的长宽比差别很大同一个棋盘底图可能被拉伸变形。我的经验是不用 Widget 组件把棋盘撑满全屏而是固定棋盘节点大小保持不变让 UI 辅助元素按钮和提示文字随屏幕宽度做适配。这样棋盘是真实物理尺寸棋子点击区域不会因拉伸而错位。这个方案在 iPhone 和主流安卓机型上测试下来都很稳定。最后再分享一下我个人的实测感触用 Cocos Creator 开发中国象棋这类逻辑密集型小游戏真正花时间的不是界面写不出来而是规则和 AI 的调试比预期繁琐得多。建议你也按照“逻辑先行界面后置”的顺序来做前期花一两天把规则引擎测透后面所有功能都可以在这个坚实的地基上快速搭建。另外写代码时一定要把旧棋局的悔棋、胜负判定、同分局面这些边界场景提前考虑进去我就是在开局判定上卡了半天后来才发现是一个数组越界问题。希望这篇文章能帮你少走一些弯路。本文还有配套的精品资源点击获取