玩过《超级马里奥》或者《王者荣耀》的人都知道，角色碰到敌人会掉血，撞到墙壁就走不通。这些看似简单的反应，背后其实是一套精密的机制在起作用——这就是游戏碰撞检测开发。
碰撞检测到底在做什么
简单说，碰撞检测就是判断两个或多个物体是否发生了接触。比如你控制的角色跳起来踩扁了怪物，系统得立刻算出“脚底”和“怪头”是不是在同一位置。如果判断不准，轻则穿模，重则让人觉得这游戏“假得很”。
在电脑性能有限的情况下，频繁做这种计算很容易拖慢运行速度。尤其是在动作类或多人在线游戏中，几十个对象同时移动，每秒要检测上百次碰撞，CPU稍不注意就飙到100%。
常见的几种检测方式
最基础的是AABB（Axis-Aligned Bounding Box），也就是用矩形框包裹物体，只看它们有没有重叠。这种方法计算快，适合大多数2D游戏。
bool checkCollision(Rect A, Rect B) {
return A.x < B.x + B.w &&
A.x + A.w > B.x &&
A.y < B.y + B.h &&
A.y + A.h > B.y;
}这个函数每次调用都只做几次比较，效率高。但问题是，人物不是方块，有时候明明没碰上，却被判定为“撞了”，体验就差了。
更精细的做法是用圆形检测，适合子弹、技能范围这类场景。计算时用勾股定理判断两点距离是否小于半径之和。虽然多了一步平方运算，但在现代处理器上影响不大。
如何减少不必要的计算
别小看每一次检测，积少成多就会卡顿。优化的第一步是“别瞎算”。比如地图左上角的角色，根本不可能和右下角的敌人发生关系，还去比对就是浪费资源。
这时候可以用空间分区法，把地图分成格子，每个物体只跟所在格子里的其他物体做检测。类似快递分拣中心按区域投递，省时省力。
另一种方法是延迟检测频率。比如爆炸效果持续1秒，没必要每一帧都扫一遍周围所有目标。可以设定0.1秒检查一次，既能保证命中率，又能减轻负担。
实际开发中的坑
有个新手常犯的错误：把所有碰撞逻辑写在主循环里，随着对象增多，代码越来越慢。后来才发现应该用事件驱动模式——只有当物体靠近时才启动检测，远离就挂起。
还有些人喜欢用像素级检测，追求极致精准。结果一开调试工具发现，帧率直接掉一半。其实大多数情况下，视觉误差只要控制在几个像素内，玩家根本察觉不到。
真正好的碰撞系统，不是算得最准的那个，而是能在准确性和性能之间找到平衡点。