[技术探讨] 网页 2D 高刷屏防穿模碰撞检测的实践
最近在业余时间用 Phaser 3 折腾一个 2D Web 游戏练手时，遇到了一个几乎所有做物理游戏都会遇到的“世纪难题”——高速物体穿模（Tunneling Effect）。
起初，我尝试引入现成的重量级物理引擎来解决，但发现对于纯粹的街机几何反弹来说，那些引擎带来的性能开销和“泥泞”的摩擦力反馈简直是灾难。为了追求极致的性能和 120Hz/144Hz 高刷屏下的丝滑手感，我干脆移除了所有第三方物理依赖，纯手写并优化了底层碰撞逻辑。
为了验证这套底层逻辑的稳定性，我顺手把经典游戏《打砖块》给重构了一遍。今天想和大家分享一下实现过程中的几个技术踩坑点，也欢迎各位大佬轻喷。
弹力球打砖块
🛠️ 核心难点 1：逻辑与帧率解耦 & 防穿模实现
在现代的高刷显示器下，如果依然按照传统的 60FPS 也就是16.6ms去锁定物理步长，高速运动的小球极其容易在一帧之内直接跨过较薄的砖块。
为了解决这个问题，我重写了基础的 Arcade 碰撞：
- 渲染与物理分离：引入了自适应的频率检测，物理更新步长不再死死绑定
requestAnimationFrame的回调频率。 - 高频子步进 (Sub-stepping)：针对极速状态下的小球，将其单帧的长距离位移在底层拆分成多次微小步长进行 AABB 射线预判。实测目前版本无论赋予小球多高的初速度，都绝对不会发生卡进砖块缝隙或飞出屏幕的 Bug。
🧠 核心难点 2：复杂实体与状态机管理
原版打砖块逻辑很简单，但为了测试引擎的承载力，我加入了一套比较复杂的实体与状态连锁系统：
- 多级爆炸逻辑：引入了“爆炸砖块💥”，击碎时需递归结算 3x3 范围内的实体销毁，并处理好碰撞组的即时注销，防止引发空指针。
- 物理材质重写：设计了“烈火球🔥”状态。常规碰撞会计算法线并反转速度向量，而烈火球状态下需要通过 Flag 拦截反弹事件，强制执行穿透并触发对应砖块的销毁回调。
- 对象池性能考验：当吃下“分裂球💠”道具后，场上实体呈指数级增长。这要求底层的内存管理必须极其干净，不能有任何垃圾回收（GC）引起的瞬时掉帧。
📱 核心难点 3：移动端的操控防遮挡
在处理多端输入（Input）适配时，PC 端传统的监听A/D键或pointermove绑定挡板中心点非常简单。
但到了移动端，如果让挡板严格跟随触控点，玩家的手指必定会挡住视线。为此，我写了一层相对坐标偏移映射：玩家的手指可以在屏幕的任意空白区域滑动，引擎只提取deltaX增量并应用到挡板上，完美实现了盲操。
🎮 在线 Demo 与源码
光说不练假把式，游戏我已经打包部署了，纯前端无后端依赖，点开即玩。欢迎大家用各种极端的极限操作去测试一下这套物理检测会不会出现 Bug（比如把球速拉到最高）。
- 🔗在线测试地址：brick.qizhen.xyz
- 📦完整源码 (GitHub)：https://github.com/ruanqizhen/brick.git
目前包含了 20 个关卡，难度循序渐进。代码基于 MIT 协议开源，如果对 2D 游戏底层碰撞逻辑感兴趣的朋友，可以拉下来跑一下npm run dev看看。
也欢迎大家在帖子里反馈遇到的 Bug，或者交流讨论 Phaser 3 相关的开发经验！