1. 项目概述与技术选型1.1 先拆清楚需求我们做的到底是什么做小游戏最怕一上来就写代码。PixiJS跳棋小游戏听起来简单但“跳棋”这个词在不同语境下指的东西完全不同。我做的是中国跳棋的简化版本也就是那个六角星棋盘、双方各十颗棋子、隔着子跳的经典玩法。在动手之前先把需求拆成了三层第一层是“能跑”也就是棋盘能画出来、棋子能点选、能落子第二层是“有规则”要走子合法、跳跃合法、胜负结果判得清楚第三层是“有点意思”至少有一个能跟你下几回合的简单电脑对手。这个拆法很关键。很多初学者一上来就想着做完整AI、做双人联机、做华丽的棋子拖拽动画结果做到一半卡死在基础交互上。我这次给自己定的范围就一个核心目标单机双人模式 一个弱AI。所有功能都围绕“在一套可靠规则引擎之上做渲染和交互”展开而不是反过来被渲染效果牵着走。适合参考这份实践记录的人是那种已经能写基本的前端代码但对PixiJS还不熟、想拿一个带完整交互逻辑的小游戏练手的朋友。如果你只想看引擎API怎么调那官方文档更全但如果你想看“一套小游戏项目从棋盘坐标到AI落子是怎么串起来的”这篇应该对你有用。1.2 渲染引擎选型PixiJS的取舍逻辑选PixiJS而不是原生Canvas或者纯DOM最核心的原因是PixiJS把“场景树管理”和“交互事件”这两件最繁琐的事封装好了。你可以把PixiJS理解成一个专门为2D场景设计的调度器它用Graphics画矢量图形、用Sprite做位图渲染、用Container做层级管理再用统一的ticker驱动重绘。对于跳棋这种大量重复图形、高频交互的小游戏省掉的代码量非常可观。对比来看原生Canvas不是不行但你需要自己维护脏矩形、自己做点击命中测试、自己管理重绘节奏这些听起来不难真做起来全是细节。DOM方案就更不用说了几十个棋子节点做动画移动还能扛住但一旦加了棋盘格高亮、路径预览、AI推算这些动态表现DOM的布局引擎会成为瓶颈。PixiJS则是一套GPU加速的渲染管线绘制几十个圆形和方块对它是基本零压力这就给后面加功能留出了余地。不过选型也有代价。PixiJS v7以后事件系统改成了EventSystemAPI和v6不完全兼容网上很多旧文章在interactive和pointerdown上直接让你踩坑。此外PixiJS本身不提供任何游戏逻辑能力规则、AI、状态管理全都是你自己写。这个边界一定要搞清楚——PixiJS负责“让画面出现、让点击响应”不等于你有了一个游戏。2. 整体架构与游戏设计2.1 目录结构与模块划分一个跳棋游戏代码量看起来不大但如果不分模块写到AI那一步基本就乱套了。我这次把工程按职责拆成了五个部分入口初始化、棋盘数据、规则判定、渲染层、AI决策。这里贴一下目录结构方便你对照着看后文。src/ ├── main.js // PixiJS应用初始化、启动游戏 ├── config.js // 棋盘尺寸、格子半径、颜色、层级常量 ├── core/ │ ├── board.js // 棋盘数据结构格点生成、坐标换算 │ ├── rules.js // 走子判定、跳跃判定、胜负判定 │ └── ai.js // 评估函数与搜索策略 ├── render/ │ ├── boardView.js // 棋盘图形绘制、格子高亮 │ ├── pieceView.js // 棋子的创建、选中态、移动动画 │ └── interaction.js // 点击事件绑定、选中流程控制 └── state/ └── gameState.js // 当前回合、选中的棋子、当前可选落点这个拆分最核心的意图是渲染层绝对不能直接改游戏数据。比如说你点击了一个棋盘格interaction模块只负责“发出意图”真正的状态变更必须经过rules模块校验再由gameState统一更新最后反过来通知view层刷新。这样做的直接好处是AI和玩家共用同一套规则引擎不存在“AI走了一步换玩家时状态不一致”的恶心问题。2.2 游戏状态机把规则关进笼子里棋类游戏最适合用状态机来管。我定义的几个状态是最小够用的一组WAITING_PLAYER等待玩家选子、PIECE_SELECTED棋子已选中等待选目标、AI_THINKINGAI计算中、GAME_OVER分胜负。每个状态里能做的事是被严格限制的这比用一堆布尔标记来管流程可靠得多。举个例子玩家在PIECE_SELECTED状态下点击另一个自己的棋子应该切换选中到新棋子上但点击一个空格子且该格子不在可走范围内就应该视为无效点击不产生任何变化。如果不用状态机每次点击都要写两三个if判断很容易漏。状态机把“当前允许的操作”收敛成几张明确的表实现和查错都轻松。我在实现上做了一个小机关状态迁移统一收敛到一个transition(state, action, payload)方法里。每次玩家点击、AI落子都走这一个入口状态变更的前后都会打印日志方便调试。这个习惯在排错阶段救了我好几次。3. 渲染核心棋盘和棋子的实现3.1 棋盘定位坐标的计算网格才是骨架跳棋棋盘不像国际象棋那样是规整矩形。中国跳棋的棋盘是一个六角星由121个格点组成每个格点与周围六个方向的格点相邻。如果直接用美术素材贴图做交互时坐标系会非常痛苦——你需要反向算出“点击位置的像素坐标对应棋盘的哪个交叉点”。我的做法是棋盘完全用程序生成格点坐标统一用逻辑坐标行号、列号表示渲染时再换算为像素。这里的关键是坐标换算公式。以棋盘中心为原点我定义列方向为x轴行方向为y轴。每个格点存储一组逻辑坐标(row, col)在六边形网格里它的像素位置是function hexToPixel(row, col, gridSize) { const x col * gridSize * Math.sqrt(3) (row % 2) * gridSize * Math.sqrt(3) / 2; const y row * gridSize * 1.5; return { x, y }; }为什么横坐标要加row % 2修正因为奇数行的格点在水平方向上正好错开半个网格间距这也是六边形网格看起来有“蜂窝”感的来源。颜色上我直接把有效格点画成棋盘表面无效格点不渲染这样视觉上就自动形成了六角星轮廓不需要额外处理形状裁剪。基于程序生成棋盘还有一个隐形收益边框、网格线、高亮区域这些视觉元素全部可以通过同一个坐标系统换算不存在“美术图上棋盘格和真实可点区域不一致”的问题。这是我在项目里坚持不用纯贴图的根本原因。3.2 棋子从图形到精灵的落地细节棋子的渲染我用了Graphics而不是Sprite原因很简单棋子就是带高光的圆没有复杂的纹理用矢量绘制代码量更少、颜色调整更灵活。每个棋子我封装成一个PieceView类它内部包含一个Graphics实例和一个逻辑位置。棋子状态有三种渲染形态默认、选中加亮边框、轻微放大、目标落点提示周围画虚线圆。用Graphics绘制棋子有一个必须注意的点每次修改图形属性都要调用重绘方法。我最早在这里犯了个错——直接修改某个棋子的填充颜色变量但是忘了重绘结果屏幕上死活不变。后来在PieceView内部统一了update()方法每次状态变化都走“清空-重绘-更新交互区域”的流程才算稳定下来。另外PixiJS里Graphics的hitArea在事件命中时是按图形实际绘制内容来算的。对棋子这种带半透明高光的图形来说hitArea如果用默认的像素命中在某些抗锯齿边缘会出现“点了没反应”的错觉。稳妥做法是给每个棋子容器手动设置一个矩形hitArea稍微大出几个像素点击手感会明显改善。3.3 交互点击选中的几个隐蔽坑PixiJS v7的交互系统核心变化就是必须显式设置eventMode为static或dynamic否则容器默认不监听事件。这和v6的interactive true写法完全不同是新手在升级版本后最容易踩的坑没有之一。其次是事件派发层级。棋盘上既有棋盘格container又有棋子container还有高亮落点提示。如果都监听点击事件很容易出现连点一次却触发多个handler的情况。我的处理方式很粗暴让棋子处理点击事件时把棋盘格的高亮响应暂时屏蔽。具体做法是给棋盘底下的棋盘格容器设置eventMode static并监听pointerdown但是只有当当前没有选中棋子、或者点击的是有效可走位置时才响应用户的意图。所有这些逻辑都收敛到interaction模块避免在视图类里散落一堆业务判断。还有一个容易被忽略的点pointerdown和pointertap的区别。在快速连点时pointertap会更稳定因为它自带了几像素的移动容差手指轻微抖动不会误触。我最终全项目统一用pointertap做落点选择避免了移动端测试时“我明明点到了却选错格子”的惨痛经验。4. 规则与AI逻辑4.1 走子与跳跃判定不要忘了递归跳棋的规则核心就两条相邻空格可以走一步隔一个棋子跳到对方后方空格可以连续跳。听起来简单实现时真正复杂的是“连续跳跃的可能性展开”。我设计的数据结构是棋盘格点邻接表。每个有效格点预先算好六个方向的邻居存储在一个字典里。走一步的合法性判断只需要查表目标格点在当前格点的邻居列表中、且目标格点为空。跳跃判断就要麻烦一些。canJump(from, to)不仅要判断“from和to之间隔着且只隔着一个棋子”还需要考虑“跳到to之后下一步还能不能继续跳”。这里要是用循环写连跳步数一多就会乱。我换成递归写法function findJumps(pos, visited, results) { for (const dir of DIRECTIONS) { const over neighborAt(pos, dir, 1); const jumpPos neighborAt(pos, dir, 2); if (over jumpPos isOccupied(over) !isOccupied(jumpPos) !visited.has(jumpPos.id)) { const newVisited new Set(visited); newVisited.add(jumpPos.id); findJumps(jumpPos, newVisited, results); } } results.push(pos); }这段代码里visited集合是关键。它避免了一个棋子在同一回合里反复跳回同一个位置导致死循环。注意我不是简单记录“已经跳过哪些棋子”而是记录“已经停留过哪些格点”两者在规则语义上是有差别的同一条路径上不能重复落点但不同分支可以穿过同一颗棋子。递归的终止条件就是“没有可跳的相邻方向了”。收集完所有可能落点之后玩家能走的位置就是“一步相邻空位 所有可达跳跃落点”。这套算法在游戏里用到两个地方玩家交互时计算可走高亮AI决策时枚举全部走法。一次实现两处复用很划算。4.2 电脑对手最小可行AI方案做一个能跟人下棋的电脑对手很多人第一反应是上蒙特卡洛树搜索或者深度学习。实话说十颗棋子规模下的跳棋一个几百行代码的极小化极大搜索配合良好的评估函数就已经能打得新手很难受了。我这次做的AI设计思路是先让评估函数靠谱再做一层有限搜索。评估函数是AI唯一的“智力来源”。跳棋的目标是让己方所有棋子到达对方阵营。我用三个维度评分function evaluatePosition(board, side) { let score 0; for (const piece of board.pieces) { const progress side red ? piece.row : (maxRow - piece.row); score progress * 1.0; if (piece.isInTargetZone(side)) score 5.0; if (piece.isBlocked()) score - 2.0; } return score; }第一个维度是“进度”棋子越靠近对方营地评分越高这是主力权重。第二个维度是“已经到达目标区的棋子数”对胜利起到关键引导作用。第三个维度是“是否被堵死”如果一颗棋子的六个邻居全被占满、又没有可跳路径这棋子在短期内基本废了必须给予负分。搜索策略我用的是固定深度二层的极小化极大。为什么只做两层因为两步以内的搜索只需要枚举“我方走一步、对方走一步”的所有组合计算量还在可接受范围再往下加深全盘121个格点的扩展量会指数级增长再加上跳跃路径的递归展开帧率会肉眼可见地掉。对于移动端的弱AI需求两层搜索加一个干净的评估函数已经能做到“有威胁、会堵截、偶尔下出好棋”的观感了。还有一个细节AI落子之后要做的第一件事不是刷新画面而是检查自己是否“被困在逻辑状态里”。我早年吃过一次亏AI枚举了所有走法都是死路直接返回null导致游戏卡死。后来在AI模块里加了兜底逻辑如果当前没有任何合法走法就强制让AI跳过回合。这个兜底放在棋类游戏里永远不该省。5. 性能优化与多端适配5.1 渲染优化图形缓存和对象复用跳棋小游戏场景里就几十个图形对象性能压力并不大但“不大”不代表可以胡写。PixiJS的Graphics每次调用beginFill、drawCircle都会动态生成几何数据如果每帧都在重复创建新的Graphics即使对象量小也会引发不必要的内存分配和GC停顿。我做的第一层优化是缓存静态网格。棋盘背景、有效格点区域、边缘轮廓这些元素在游戏过程中完全不变我在初始化时一次性画到独立的Container里之后不再重绘移动或高亮时只移动它的引用。棋子的图形定义也做了缓存复用颜色、描边、高光路径全部是构造时确定的后续只改位置和可见性。第二层优化是尽量复用对象而非无限新建。每个PieceView在创建时把Graphics实例固定下来状态切换时只调整图形属性并标记重绘而不是销毁旧的再new一个。这套“创建-复用-复绘”的模式对后续想加棋子入场动画、移动轨迹动画也非常友好因为对象句柄一直是同一个。另外我保留了PixiJS的自动渲染机制没有手动调用renderer.render()。对大多数小项目来说Application.ticker驱动的自动渲染已经足够高效过早自己写渲染调度反而容易引入“某些帧漏更新”的不确定性。5.2 窗口缩放与高清屏适配跳棋棋盘是正方形风格布局在设计分辨率下看起来正好但换到不同比例的浏览器窗口或者手机上就容易出现棋盘画不全或者留大片空白的问题。我的适配思路是统一走“等比缩放”策略先确定一个设计分辨率我用的是960 x 960把整个游戏场景放入一个Container里窗口变化时用CSS的min(宽高比)计算缩放比例然后同时设置Container的scale和位置居中。这样做的视觉效果等级有点像是看地图时用固定视野比例缩放永远不改排版只改缩放。高清屏的问题单独处理。PixiJS在初始化Application时如果不设置resolution默认用设备像素比1。在iPhone那种3倍屏上图形边缘会发虚。正确做法是初始化时读取window.devicePixelRatio并在resize时叠加这个系数。注意坑点在于渲染分辨率提升后所有坐标和点击精度也要跟着对应直接把resolution调大但scale不变会导致事件坐标错位。这里有个简单的换算公式app.renderer.resize(cssWidth * dpr, cssHeight * dpr); view.scale.set(cssWidth / designWidth, cssHeight / designHeight);实测下来这一套在PC、平板和手机上都能在加载后自动适应不需要别的插件。不过Android不同浏览器对devicePixelRatio的返回时机略有差异稳妥做法是初始化后延迟半秒在resize事件里统一校正一次我就遇到过初始化时dpr还是1、加载完变2的情况。6. 常见问题与排错记录6.1 高频问题速查表这里把开发过程中常见的问题整理成一张表都是我亲身踩过或者朋友做类似项目时问过我的直接抄作业就好。现象根本原因解决办法点击棋子无任何反应容器没设eventMode或事件绑定在子元素上但没冒泡给需要交互的容器设置eventModestatic棋子能选但选不中落点高亮落点的container在棋盘底图下面被遮挡检查zIndex和sortableChildren让高亮层在上棋盘错位、棋子位置怪六边形网格的奇数行偏移忘了算检查hexToPixel中row % 2修正逻辑连续跳跃的路径反复横跳递归时未记录已有落点使用visited集合记录已停留格点高DPI屏幕棋子模糊未设置resolution或分辨率与scale不一致初始化传入resolution: window.devicePixelRatioAI有时会卡住AI枚举走法后所有结果均为null在AI返回null时强制跳过本回合重新开局后旧状态残留没有重建棋盘数据的干净实例重新初始化board对象而非清空数组移动端点击偏移使用了pointermove或未适配缩放后的坐标映射统一用pointertap并基于全屏坐标换算6.2 现场排错一个诡异Bug同一颗棋子跳了没完有一个bug我排查了整整半小时很典型。现象是第一步点击一颗棋子高亮落点正常选一个跳位过去之后这颗棋子突然又进入了选中状态而且棋盘上出现了一堆离谱的可跳位置。初看以为是递归跳跃的判定出了问题但我打印路径后发现递归本身没毛病。最后定位到是交互流程的问题我处理“跳到新位置”时修改了棋子的逻辑坐标并同步更新渲染坐标但交互层检测“当前是否有点击了新棋子”时被点中的那颗棋子的位置已经移动了事件命中区域还停留在旧位置导致未结束的点击状态被错误地当成“点击了同一颗棋子”。修复方案是加一个状态判断当玩家完成一步落子后强制将state切回WAITING_PLAYER并清除所有选中高亮。同时我把交互层的点击目标句柄从“棋子当前视图形状”改成了“棋子容器持久引用”事件目标识别不再依赖图形位置彻底杜绝了坐标偏移带来的误判。排这个bug的核心教训只有一句话交互状态和逻辑状态的切换时序一定要同步。代码逻辑正确不一定代表交互体验正确渲染层和状态层的微小脱节会在真实操作中无限放大。最后分享一点实际体会做这个PixiJS跳棋小游戏最大的收获不是学会了某个具体API而是把“渲染、交互、逻辑、决策”这四层清晰地分开后整个项目到了后期几乎没再出现牵一发动全身的重构。很多功能在架构正确的前提下改动都发生在局部模块里比如给AI增强搜索深度时我完全不用碰渲染层。如果你想在这个项目基础上继续扩展我个人建议优先做三件事第一给棋盘格增加“可走路径预览”的连接线绘制这个视觉效果会让游戏观感提升一个档次第二把静止的AI评估函数升级成带微调的权重配置界面方便调试棋力第三考虑把棋盘坐标系统抽象出来方便未来替换成国际跳棋或黑白棋的格点模型一旦几何坐标层独立换玩法比想象中快得多。