“Wizard Chess, 3D browser chess where captured pieces shatter”——这句项目描述翻译过来就是做一个能在浏览器里直接玩的3D国际象棋但重点不在“棋”而在“被吃掉的瞬间”。棋子不是被默默拿掉而是像被魔杖击中一样当场碎成一地小碎片带着微光飞溅出去。这个画面在哈利波特电影里是氛围感最强的几秒放到Web端来复刻玩法上其实还是一盘标准国际象棋视觉上却多了一层“棋子替你对打”的戏感。这篇文章不打算从“怎么装Node.js”讲起而是把一个可运行版本该怎么拆、怎么实现、会遇到哪些坑完整讲清楚。内容围绕Three.js场景搭建、规则引擎校验走子、碎片物理飞溅这三个核心模块展开。适合两类朋友一类是想做“带演出感的网页棋类游戏”的开发者另一类是已经会Three.js、想看看“碎裂动画加物理调优”怎么做的人。哪怕你只想要“碎片效果”这一段直接跳到第3章也完全读得懂。1. 项目拆解把一句话拆成三个可落地的需求1.1 “3D、浏览器、被吃棋子碎裂”分别决定了哪些技术选型项目描述里三个词每一个都在替你做技术决策。先说“3D”。它把技术范围直接锁定在Web 3D渲染。你可以用纯WebGL裸写但一个国际象棋游戏要做到“能看、能玩、有碎裂特效”至少要自己处理相机控制、几何体管理、坐标变换、阴影、透明排序裸写的开发成本会高到让人想放弃。Three.js在这里是第一个合理选择它提供完整的场景图、矩阵运算、材质系统和现成的相机控制器社区资料也足够多遇到问题搜一下基本都有答案。Babylon.js同样能做但Three.js配合cannon-es这套组合在中小型项目里更轻加载体积更友好所以我选了Three.js。再说“浏览器”。这个词意味着用户不需要安装客户端打开网页就能玩但也意味着你必须在加载体积和移动端性能上有所克制。你不能抱着“用户是游戏本”的心理预期去写代码。整个项目的棋盘、棋子、碎片三部分我一开始就做了分层设计棋盘是静态场景棋子是实例化渲染碎片是短生命周期的临时对象三者互不干扰。最后是“被吃棋子碎裂”。这句话定下了整个项目的难度顶点。它要求你有“分块”和“生命周期控制”的能力把单个网格拆成多块、为每块挂上物理属性、然后在恰当的时机放出去等动画播完再干净地回收内存。物理引擎在这一步就得提前入场否则后面再加会非常痛苦。我选cannon-es的理由特别朴实API直觉、体积小、纯JavaScript生态和Three.js配合不需要额外桥接层。1.2 玩法闭环与打磨目标从玩家视角看整局游戏的反馈链条应该是这样的选中棋子高亮可行走法点击目标格如果目标格上是对方的棋子触发碎裂。这条链条每一次都能闭环玩家才会觉得“有戏”。很多网页棋局游戏体验差就是因为点击后没有任何反馈玩家得靠猜来判断自己的操作有没有生效。所以我建议的开发优先级是规则引擎→渲染基础→交互反馈→碎裂特效→氛围打磨。先把“下的是一局标准国际象棋”这件事做扎实再让“吃子瞬间帅起来”。如果你一上来就扑到特效上把氛围铺满再回来修规则很容易被规则逻辑和视觉逻辑纠缠在一起带偏后面改一次规则就要连带调一次动画工期直接翻倍。当时给自己定的打磨目标有三条。第一碎裂瞬间要有清晰的“前摇”先让玩家看到“它要被吃了”再放大爆开的力度而不是毫无预兆直接炸。第二破碎后的残骸必须遵守物理不能穿进地板也不能飞向镜头糊一脸。第三整盘游戏过程不掉到30帧以上。这三条听起来简单实际每条都花了不少调试时间后面会逐一展开。2. 规则引擎先行让碎裂只发生在“合法的吃掉”之后2.1 棋盘数据结构与走法生成国际象棋用8x8二维数组存储局面就够了。每个格子可以存一个对象或者干脆存null表示空。对象里需要包含棋子类型兵、马、象、车、后、王、颜色、以及一些特殊状态标记比如“这个兵是否还没动过”“王和车是否已经移动过”——这两个状态直接关系到两格起步和易位的判定。走法生成是规则引擎最基础的部分重点在两件事步法表和路径阻挡。马和王是跳变式走法可以直接枚举相对坐标车、象、后则是直线扫射型需要沿着方向一格一格往前推遇到边界或棋子就停兵的规则最特殊直走一格、两格起步、斜吃子、吃过路兵、升变每一条都是独立逻辑。这里我强烈建议不要把所有验证塞进一个巨型函数里。我按三种能力拆了模块直行扫射型、跳点型、兵型。直行扫射处理“从起点沿方向走到尽头”跳点直接查坐标差兵则单独写一套带状态机的逻辑。这样代码量虽然看着多一点但调试时定位问题会非常快。// 伪走法生成骨架 function generatePseudoMoves(board, from) { const piece board[from.y][from.x]; const moves []; if (piece.type knight) { // 跳点型8个偏移量不检查路径 const offsets [[1,2],[1,-2],[-1,2],[-1,-2],[2,1],[2,-1],[-2,1],[-2,-1]]; for (const [dx, dy] of offsets) { const target { x: from.x dx, y: from.y dy }; if (inBoard(target) !occupiedBySelf(board, target, piece.color)) { moves.push(target); } } } else if (piece.type bishop) { // 直行扫射四个斜方向逐格推进直到阻挡 } return moves; }2.2 将军检测与合法性过滤伪走法集合不等于可走集合这是新手最容易忽略的一步。国际象棋有一条铁律任何走法都不能让自己的王处于被攻击状态。也就是说如果走完这一步对方某个棋子声称能吃掉你的王那这一步就是非法的。实现逻辑是两步先生成“攻击表”把对方所有棋子能攻击的格子全部标记出来再检查王的位置是否落在这个表里。注意马要按跳点加入攻击表兵要按斜吃方向加入攻击表而不是按直走方向——这里非常容易踩坑因为兵的“能攻击的格子”和“能移动的格子”是两套坐标。合法性过滤则需要在假想局面上做模拟。把棋子从from挪到to生成新局面评估isInCheck如果为真就删掉这个走法。对于王车易位还要额外检查王经过的格子是否有敌方攻击覆盖这个细节直接决定易位功能屠不屠Bug。function isSquareAttacked(board, square, byColor) { // 反查想覆盖一个格子需要判断 // 1. 该格周围是否有对方王 // 2. 该格所在横竖线上是否有对方的车/后 // 3. 该格所在斜线上是否有对方的象/后 // 4. 该格周边马的跳点是否有对方马 // 5. 该格周边兵的斜吃位置是否有对方兵 return true; // 具体实现略以上五类判断缺一不可 }2.3 点击交互状态机渲染层接收点击再把坐标交给逻辑层处理逻辑层需要一个状态机来管理交互节奏。我设了三个状态Idle、PieceSelected、Animating。Idle时点击棋盘格如果上面是己方棋子就进入PieceSelected并列出可行走法PieceSelected时点击高亮格则执行走子并进入AnimatingAnimating期间直接屏蔽一切新输入防止玩家连点导致棋子瞬移或者规则状态错乱。这个状态机虽然简单但保住了整个游戏的操作稳定感。实测下来去掉Animating屏蔽的那几天测试时连续快速点击能触发一堆诡异行为全部是输入竞态造成的。不要小看这个设计很多网页棋游体验差根子就在交互状态没有加锁。渲染层的高亮也依赖状态机PieceSelected时把可行走法格渲染成绿色半透明平面把可吃子格渲染成红色半透明平面再用一个光环贴在当前选中棋子脚下。高亮物件的数量很少用普通Mesh就能跑不需要上InstancedMesh。3. 碎裂效果实现渲染、物理与魔法感的三层配合3.1 预分割碎片替代实时切模换来稳定帧率运行中把整块棋子模型实时切成碎块这个方案技术上看着很酷但落地时是灾难。实时切网格通常要用CSG或BSP算法计算量大棋子模型只要是带弧面的切割后还容易出现破面、顶点重复和法线错乱。每吃一次子就算一次遇到连续交换连吃帧率直接崩。我的方案是预分割在Blender里提前把每个棋子按几条切割线切成6到10块导出成glTF运行时把这些碎块作为“潜在碎片”加载到内存里。棋子正常存活时碎块是整体显示的触发被吃时先隐藏完整棋子把碎片组实例化到棋子的位置上再交给物理引擎让它飞出去。预分割有一点要注意碎片要尽量闭合面数控制在几百个三角形以内。太精细的碎片会让物理碰撞计算变得昂贵太粗糙又看不出“摔碎”的效果。我最终调成每个棋子拆8块左右既有足够的细节PhysX阶段也不会拖累帧率。class ChessPieceMesh { constructor(model) { this.shatterShards model.shards; // 预置碎片组 } shatter() { this.activeMesh.visible false; this.shatterShards.forEach(shard shard.activate()); } }3.2 cannon-es刚体物理碎片顺着攻击方向炸开碎片飞散这一步用的物理引擎是cannon-es。每个碎片在进入物理世界前需要挂上碰撞形状。最精确的是ConvexPolyhedron凸包但碎片一多凸包的计算和解算开销很大实测下来对大多数小块用一个缩了大约15%的Box近似即可视觉上完全看不出区别结算成本却低得多。触发吃子时需要给碎片一个“攻击方向”。最简单的方案取攻击棋子到被吃棋子的水平向量归一化后作为主方向再向上加一点仰角分量最终叠加少量随机扰动。冲量大小需要反复调太大会导致碎片飞出棋盘视野太小又像轻轻推倒完全没有“炸开”的感觉。我最终调出的参考值是每个碎片冲量约0.02到0.04具体数值取决于棋子模型比例和场景缩放。物理步进也需要刻意控制。cannon-es的world.step如果每帧都调用低帧率机器上会出现物理时快时慢的问题。正确做法是固定时间步长比如每次step固定为1/60秒再根据真实delta累积精确次数这样碎片运动与渲染时钟始终保持同步不会出现残影抖动。world.gravity.set(0, -9.82, 0); shard.body.applyImpulse( new CANNON.Vec3( attackDir.x * 0.03 randomOffset.x, 0.12 randomOffset.y, attackDir.z * 0.03 randomOffset.z ), shard.body.position );3.3 粒子、光效与时间节奏把碎裂演出做足物理有了但只有物理还显得干巴巴。真正的“巫师感”来自三样东西发光材质、粒子粉尘、时间节奏。碎片材质不能用纯色Lambert我用了一个自带少量自发光和边缘发光的ShaderMaterial。碎片在翻滚时高光会跟着角度变化像玻璃渣被魔法光照亮。接下来加粒子粉尘用THREE.Points在破碎瞬间生成一批小光子初始速度与碎片方向一致但寿命很短0.3秒内透明度降到0模拟魔法消散。时间节奏是容易被忽略但极其重要的一环。被吃瞬间先让整体画面停顿约0.15秒让玩家“意识到发生了什么”然后碎片才爆发。这个短暂停顿会放大后续的爆发力让碎裂变成一个“有前摇的高潮”而不是随机爆炸。我当时在调试时发现只要去掉这0.15秒停顿整个演出就变成“莫名其妙炸成一堆”氛围大打折扣。音效方面不需要换音频文件用Web Audio API直接合成就行。低频轰鸣用OscillatorNode加一个快速衰减的gain碎片声用一小段白噪声再通过带通滤波器叠加起来非常有“玻璃碎裂加咒语”的感觉。成本只有几十行代码但对体验的提升非常明显。4. 工程优化与性能稳定60fps的关键操作4.1 棋盘和棋子的低开销渲染方案一个国际象棋场景里棋盘占64个格子初始32个棋子如果每个都用独立Meshdraw call很容易上百移动端直接卡。这里的优化手段有两招。第一招棋盘格合并。不再为64个格子各建一个Box顶面而是用一个PlaneGeometry在上面贴一张1024分辨率的棋盘纹理。这张纹理可以在初始化时用Canvas 2D动态绘制黑白格、边框、坐标都能画出来。一个平面就能带出整块棋盘draw call直接降到1。第二招棋子实例化。同类型同颜色的棋子共用一份几何体和材质用THREE.InstancedMesh渲染。16个白兵是一个InstancedMesh16个黑兵是另一个四个车、四个马、四个象各种颜色各占一个实例。32个棋子总共只需要约12个draw call比传统的32个独立Mesh节省一半以上。const whitePawns new THREE.InstancedMesh(pawnGeo, whiteMat, 16); for (let i 0; i 16; i) { const matrix new THREE.Matrix4(); matrix.compose(position, quaternion, scale); whitePawns.setMatrixAt(i, matrix); } scene.add(whitePawns);4.2 内存回收与物理步长的细节处理碎片效果最消耗的其实是内存。每次吃子生成一堆碎片Mesh如果只加进场景不清理游戏进行半小时后内存和GPU显存会缓慢膨胀帧率先掉后崩。所以每个碎片的生命周期必须管理从物理世界移除碰撞体、从场景移除Mesh、调用geometry.dispose()和material.dispose()。我建议做一个碎片池。初始化时预先创建一批可复用的碎片几何体和材质吃子时从池里取播放完毕还回去。池化后一是避免频繁创建Geometry造成的GC停顿二是让内存占用长期保持稳定。我当时用Chrome任务管理器里的“JavaScript内存”和“GPU内存”两条曲线观察池化后整体曲线变得很平稳不再有波浪形的持续抬升。固定步长的问题在这里也必须重申。物理step不要挂在requestAnimationFrame里直接跑而是用accumulator累积真实时间每次累积够1/60秒才执行一次step。渲染仍然每帧进行但物理位置和渲染位置之间可以加一层插值。这样即使帧率在50到70之间波动碎片的运动轨迹也不会有明显卡顿。let lastTime performance.now(); let accumulator 0; const fixedStep 1 / 60; function animate(time) { requestAnimationFrame(animate); const delta (time - lastTime) / 1000; lastTime time; accumulator delta; while (accumulator fixedStep) { world.step(fixedStep); accumulator - fixedStep; } renderer.render(scene, camera); }5. 开发期踩坑记录规则、物理与兼容性5.1 规则层面的经典Bug规则引擎的坑集中在小规则上我列几个最容易犯的。吃过路兵目标格是空的但走法合法只因为它旁边那颗兵刚刚走了两格。我一开始把“吃子”简单理解成“目标格非空才算吃”结果吃过路兵直接失效测试了很久才想起来这个特例。升变兵到达底线后必须马上变成一个别的棋子否则后续走法全是死路。我默认弹窗让玩家选后、车、象、马取消了直接升后的快捷设置虽然多一次点击但规则上不会出错。易位除了王和车没移动过、中间格子为空还必须检查王经过的格子不被攻击。这三个条件缺一个都不能易位漏掉任何一个都算规则Bug。5.2 物理表现层面的常见问题物理阶段最容易出现的是“碎片刚出生就飞出去”和“碎片穿地板”。碎片刚出生就飞出去原因一般有两个一是碎片Mesh初始位置没同步到cannon-es刚体的世界里物理引擎认为碎片在世界原点附近然后又被冲量推出很远二是冲量方向和大小没控制好给了一个朝镜头方向的水平分量。解决办法是先把刚体位置精确设置到碎片世界坐标再给冲量同时把水平分量限制在一个小范围内让碎片“向上炸开”而不是“向前砸向玩家”。碎片穿地板是最常见也最影响观感的Bug。cannon-es在快速运动的物体上容易发生隧穿即一帧内穿过地面碰撞体。提高步进频率是一个方向另一个更实用的方向是给地板碰撞体稍微加厚一点比如把碰撞盒的y方向厚度设为0.1给碎片一个“落地缓冲”的物理空间。我在代码里用了后者加上固定步长后几乎不再看到穿地现象。5.3 移动端与浏览器兼容性移动端测试时第一个问题是画质。手机屏幕小但默认pixelRatio可能高达3渲染压力直接翻三倍。我做了两件事把renderer.setPixelRatio限制在Math.min(window.devicePixelRatio, 2)把阴影贴图尺寸从2048降到1024。这样既能保证清晰度又不至于让手机GPU喘不过气。第二个问题是hover效果。桌面端鼠标悬停在棋子上时我加了一个浮起效果但触摸设备没有hover概念手指按上去会触发意外的高亮。处理方式是把hover效果限定在PointerEvents的mouse类型下触摸设备只保留点击选中反馈。第三个问题是实例化网格的兼容性。InstancedMesh在WebGL2下表现很好但如果用户浏览器只支持WebGL1数量大的实例化可能需要降级成普通Mesh。我的做法是启动时检测WebGL2如果不可用就把32个棋子拆成独立Mesh渲染虽然draw call会升高但至少功能可用不会被卡在入口。最后说点实在的做这个项目最大的体会是先让规则“稳”再让效果“炫”。如果走子合法性都没搞定碎裂特效做得再华丽玩家也会在下一回合就发现“刚才那颗子怎么不吃”整个魔法感瞬间崩塌。反倒是碎裂动画它其实不复杂核心就是预分割加物理冲量。真正花时间的不是“怎么让碎片动”而是“怎么让碎片停止后不留下杂物”。我的做法是给每个碎片绑定一个生命周期定时器6秒后无论是否还在运动都强制淡出并回到碎片池。这套逻辑稳定运行后我几乎不用再管内存问题。最后分享一个小技巧触发碎片动画时给整个棋盘加一个极快、极小的scale脉冲比如在0.1秒内把棋盘缩放从1.0到0.998再回弹到1.0。这个震动幅度肉眼几乎发现不了但配合碎片飞溅整体冲击感会明显提升一个档次就像整个棋盘都在为那颗棋子的消逝“呼吸了一下”。这个细节是额外摸索出来的比单纯把碎片物理调大有效得多强烈推荐试一下。