拓冰网站定制 
1. 从物体重叠到游戏逻辑碰撞检测到底在解决什么问题做游戏开发的人大概率都有过这种经历玩家明明没有碰到敌人血条却掉了子弹从怪物体内穿过去判定却没触发或者角色卡在墙里出不来。这些看似八竿子打不着的问题最终排查下来十有八九都出在碰撞检测上。碰撞检测Collision Detection说白了就是判断两个物体有没有发生重叠或接触这件事听起来简单做起来牵扯到的东西却不少。我在用Python写游戏的时候尤其是从纯逻辑Demo过渡到真正能玩的游戏时碰撞检测的精度和性能直接决定了手感的好坏。这篇文章不打算堆理论而是把我实际做项目时真正用得上、踩过坑的那些方案拿出来聊。包括常见的矩形碰撞AABB、圆形碰撞、像素级碰撞以及处理大量物体时的性能优化思路。如果你正在用Pygame、Pyglet或者纯Python写游戏或者在做一个需要检测物体是否重叠的交互应用这篇文章应该能帮你少走不少弯路。我默认你已经有了一点Python基础会写类和函数但对碰撞检测只有模糊概念。下面所有内容我都是从如何真正落地的角度来讲。2. 坐标系与两个物体的定义方式碰撞检测的地基在聊具体算法之前必须先搞清楚一件事代码里的物体是怎么表示的。不同表示方式决定了后面用哪种碰撞检测算法也决定了精度上限。2.1 一切检测的前提物体先得有形状游戏里的物体在内存里并不是一张连续的画面而是一堆数据和属性。要做碰撞检测首先要给物体定义一个可供计算的形状。最常用的有三种轴对齐包围盒AABBAxis-Aligned Bounding Box用一个不旋转的矩形框住物体存左上角坐标x, y和宽高width, height。这是最省计算量的表示方式绝大多数2D游戏的基础碰撞都用它。圆形Circle存圆心坐标cx, cy和半径r。旋转不影响判断而且距离计算非常快。像素遮罩Mask按像素级别记录物体的不透明区域精度最高但计算成本也最高。这三种表示方式对应着三种核心判断算法矩形与矩形、圆与圆、像素与像素或者混合类型。实际项目中很少只用一种。比如角色用矩形子弹用圆形地形用矩形组合特效用遮罩——混合检测才是常态。提示在做碰撞检测之前最好先在代码里给物体建立统一的位置-形状数据结构。我习惯定义一个Entity基类把绘制和碰撞属性分开存。我在项目里通常这样初始化一个可碰撞的物体import pygame class Entity: def __init__(self, x, y, width, height): self.x x # 左上角x坐标 self.y y # 左上角y坐标 self.width width # 宽度 self.height height # 高度 property def rect(self): # 每次动态生成pygame.Rect方便复用pygame内置碰撞函数 return pygame.Rect(self.x, self.y, self.width, self.height)用一个rect属性实时生成矩形而不是在__init__里固定一个rect对象是因为游戏里物体随时在移动固定rect需要反复同步坐标容易漏更。动态生成虽然多了一点计算但在物体数量不多时几乎可以忽略。2.2 为什么绝不要用中心点距离判断两个矩形是否碰撞很多刚入门的朋友会犯一个错计算两个矩形的中心点距离如果小于某个阈值就认为碰撞了。这个思路对圆形勉强说得通对矩形就行不通了——矩形不是各向同性的宽高不同时中心距离根本不能代表实际边界关系。举个例子两个100×10的长条矩形上下叠在一起中心点距离小于50的时候其实已经重叠了但如果是100×100的正方形重叠判定距离就到了70.7左右。用一个固定阈值去套所有矩形结果必然是一会儿穿透一会儿误报。正确的做法是把判断问题转化为区间重叠问题。两个矩形在X轴上各自占据一个区间在Y轴上也各自占据一个区间。只有X和Y方向上都重叠两个矩形才算碰撞。def check_aabb(rect1, rect2): # rect1, rect2 分别是 (x, y, width, height) x1, y1, w1, h1 rect1 x2, y2, w2, h2 rect2 overlap_x (x1 x2 w2) and (x2 x1 w1) overlap_y (y1 y2 h2) and (y2 y1 h1) return overlap_x and overlap_y这套逻辑就是标准的AABB碰撞检测。pygame里有现成的Rect.colliderect()方法但搞清楚底层逻辑很重要因为后面做性能优化或者移植到其他框架时你总要自己实现一遍。而且colliderect在某些极端情况下比如一个物体完全包含另一个物体时的行为不同版本的pygame表现略有差异懂原理才知道怎么排查。2.3 坐标系里的方向坑y轴正方向是往下Python的2D图形库pygame、tkinter等遵循屏幕坐标系原点在左上角x轴向右递增y轴向下递增。这和数学课上的坐标系是反的。做碰撞检测时这个方向性影响很大尤其是涉及碰撞方向判断时——比如角色头顶撞到砖块或者脚底踩到地面。我早期写平台跳跃游戏时判断角色是否落地用的是player_rect.bottom ground_rect.top但没考虑到y轴向下增长bottom其实是数值更大的那一边。结果角色全程浮空怎么都落不了地。后来把所有判断都换成数值比较而非视觉上、下来理解才彻底理顺。这是一个很基础但非常容易阴沟翻船的细节。建议你在代码里加注释的时候不要写上、下直接写y值小的一侧、y值大的一侧避免自己把自己绕晕。3. 逐帧检测还是实时检测为什么你的子弹会穿透墙壁玩过FPS游戏的读者对子弹穿透应该不陌生但2D游戏里同样有这个问题。一个高速移动的子弹每帧移动了50像素而一面墙只有30像素厚。如果只在每帧结束时检查有没有重叠子弹可能上一帧还在墙左边下一帧就到了墙右边中间的碰撞过程完全没被捕捉到。3.1 离散检测的局限游戏循环的本质是离散的——每一帧计算一次位置然后刷新画面。碰撞检测天然有盲区它只检查当前时刻的重叠状态而不关心两个物体之间某个瞬间是否交叉而过。这个问题在物理模拟里有个专门的名字隧穿效应Tunneling。物体速度越快、帧率越低、障碍物越薄隧穿越容易发生。3.2 常用的三种应对方案方案一限制最大速度最简单粗暴让物体的每帧位移小于最小碰撞体的厚度。比如墙壁厚度是30像素帧率恒定60FPS那么物体速度要控制在30 × 60 1800像素/秒以内。这种方案适合控制节奏的游戏但遇到加速、冲刺技能就失灵了。方案二细分时间片子步进Sub-stepping把一帧内的移动拆成几个小步每一步都做一次碰撞检测。帧之间位移为50像素那就拆成5步每步只移动10像素这样就不会跳过30像素厚的墙了。代价是碰撞检测调用次数变多性能开销上升。def move_with_collision(entity, dx, dy, obstacles, substeps5): step_x dx / substeps step_y dy / substeps for _ in range(substeps): entity.x step_x entity.y step_y for obs in obstacles: if check_aabb(entity.rect, obs.rect): # 处理碰撞把物体推回去 resolve_collision(entity, obs)这个方案的优点是逻辑简单容易理解几乎所有2D游戏引擎包括一些3D引擎都支持类似配置。缺点是需要预估最大可能位移步长太密会浪费性能太疏又可能漏检。方案三连续碰撞检测CCDContinuous Collision Detection把物体的运动轨迹看作一条线段检测这条线段是否与障碍物相交。这是物理引擎如Box2D、Bullet的常规做法精确度高但实现复杂度也高。2D游戏里如果要用射线与矩形的相交判断会牵扯到参数方程和区间求解。我在真实项目里的建议是大部分情况下用方案一配合方案二只在子弹、激光这类极高速物体上用CCD。不要一上来就全场景CCD计算量翻倍不说调试起来也麻烦。3.3 修正后的子弹移动检测模板我用pygame写过一套高速子弹检测的模板核心思路就是细分步进 AABB检测 碰撞点修正import pygame def move_bullet(bullet, dx, dy, solid_objects): # bullet.rect 是子弹当前矩形bullet.speed 越大越需要细分步进 distance max(abs(dx), abs(dy)) if distance 0: return False # 每步移动不超过 2 像素避免隧穿 steps max(1, int(distance / 2)) step_dx dx / steps step_dy dy / steps for _ in range(steps): bullet.rect.x step_dx bullet.rect.y step_dy hit_index bullet.rect.collidelist(solid_objects) if hit_index ! -1: # 碰到的物体是 solid_objects[hit_index] # 这里可以记录碰撞点用于生成特效或者伤害判定 return True return Falsecollidelist是pygame提供的方法返回第一个碰撞的物体索引没有则返回-1。但要注意它返回的是第一个碰撞对象如果物体重叠严重可能不是你想撞的那个。在高精度需求下我建议遍历所有固体对象找出重叠面积最大的那个作为实际碰撞对象。4. 圆形碰撞与混合碰撞当球撞上矩形数学就不一样了很多游戏里角色和子弹的碰撞体不都是矩形。比如玩家角色用圆形更贴合子弹用小矩形或小圆地形又是矩形。这时就需要混合碰撞检测。4.1 圆与圆直接算距离圆和圆的碰撞检测是最直观的两个圆心之间的距离小于等于半径之和就算碰撞。import math def check_circle_collision(cx1, cy1, r1, cx2, cy2, r2): dx cx1 - cx2 dy cy1 - cy2 distance_sq dx * dx dy * dy radius_sum r1 r2 return distance_sq radius_sum * radius_sum注意我用的是平方距离比较没有调用math.sqrt()。半径之和的平方不会超过距离平方的比较结果省掉开根号在高频调用里能省不少计算量。这一点在下面讲性能优化时还会再提。4.2 圆与矩形把矩形膨胀成圆角矩形圆和矩形的碰撞检测比圆与圆复杂一点但也不难。思路是找到矩形上离圆心最近的点算这个点到圆心的距离如果小于半径就算碰撞。这个最近点怎么找把圆心坐标分别钳位clamp到矩形的左右边界和上下边界之间def check_circle_rect(circle_cx, circle_cy, radius, rect_x, rect_y, rect_w, rect_h): # 钳位将圆心坐标限制在矩形范围内 closest_x max(rect_x, min(circle_cx, rect_x rect_w)) closest_y max(rect_y, min(circle_cy, rect_y rect_h)) dx circle_cx - closest_x dy circle_cy - closest_y distance_sq dx * dx dy * dy return distance_sq radius * radius这段代码听起来玄乎用生活化的类比就是你在一个房间里找离窗外某棵树最近的点树在窗左边最近点就是窗框左缘树在窗上方最近点就是窗框上缘树正好在窗子里最近点就是树本身的位置。如果圆心的x坐标在矩形x范围内且圆心的y坐标也在矩形y范围内那最近点就是圆心自己距离为0必然碰撞——这种情况对应圆心在矩形内部。4.3 圆形碰撞体在实际项目中的应用我在做俯视角2D射击游戏时玩家和敌人的碰撞体都用了圆形原因是角色的各个朝向视觉宽度差异不大圆形判定比矩形更公平玩家操控时不容易出现明明看着躲过了却被判定击中的憋屈感。后来加Boss战Boss是一个大型矩形机甲玩家子弹是圆形就用check_circle_rect来做子弹与Boss的判定实测稳定。实战中碰撞体类型的选择有个经验法则角色对角色、子弹对角色优先用圆形判定平滑、玩家体验好角色对地形、子弹对墙体优先用矩形AABB贴合地图格子便于做格子碰撞像素级美术的手绘物体比如不规则洞穴考虑像素遮罩但只限于数量很少的场景要物体5. 像素级碰撞检测什么时候真的需要怎么用才不卡说了半天矩形和圆形这两种方案的精度上限就是形状近似。当两个物体的视觉形状和矩形差异过大时比如一个星形的收集品、一个不规则的云朵平台用矩形碰撞就会出现明显违和星星明明没碰到却判定收集云朵有透明区域却像实心墙一样挡住角色。5.1 pygame.mask从Surface生成遮罩pygame里提供了pygame.mask模块可以从一张带透明通道的图片Surface中生成像素遮罩Mask对象里记录了这个图片的哪些像素是不透明的。然后可以用overlap()方法检查两个遮罩有没有重叠的不透明像素。import pygame sprite_surface pygame.image.load(star.png).convert_alpha() sprite_mask pygame.mask.from_surface(sprite_surface) enemy_surface pygame.image.load(enemy.png).convert_alpha() enemy_mask pygame.mask.from_surface(enemy_surface) # 放置两个精灵的位置左上角坐标 sprite_pos (100, 100) enemy_pos (105, 102) # offset 是 enemy 相对于 sprite 的坐标偏移 offset (enemy_pos[0] - sprite_pos[0], enemy_pos[1] - sprite_pos[1]) if sprite_mask.overlap(enemy_mask, offset): print(像素级碰撞发生)这里最关键的是offset的计算逻辑。overlap(other_mask, offset)方法中offset表示的是把other_mask放在当前mask的什么相对位置上。官方文档里写的是offset是other_mask相对于self_mask的偏移量。我每次写这个代码都要在草稿纸上画一遍坐标不然方向很容易搞反。如果你把精灵和敌人的位置都用左上角坐标表示那么offset就是(enemy_x - sprite_x, enemy_y - sprite_y)。5.2 性能问题两万个像素的代价像素级碰撞最让人头疼的是性能。一张200×100的贴图遮罩就有2万个像素。如果两个遮罩做overlap检测最坏情况要逐像素比较几千组物体同屏的时候能把CPU吃满。所以我的经验是像素级碰撞只用于高频接触中的少数关键物体。具体来说可以做一个两级检测策略先用AABB粗检测。如果两个物体的矩形包围盒都不重叠直接跳过根本不做像素检测。只有AABB检测通过了才去做像素级overlap。这样可以过滤掉绝大多数远距离不相干的物体对。def precise_collide(sprite1, pos1, sprite2, pos2): # 第一级AABB粗判断 rect1 pygame.Rect(pos1[0], pos1[1], sprite1.get_width(), sprite1.get_height()) rect2 pygame.Rect(pos2[0], pos2[1], sprite2.get_width(), sprite2.get_height()) if not rect1.colliderect(rect2): return False # 第二级像素级精确判断 mask1 pygame.mask.from_surface(sprite1) mask2 pygame.mask.from_surface(sprite2) offset (pos2[0] - pos1[0], pos2[1] - pos1[1]) return mask1.overlap(mask2, offset) is not None5.3 每帧都生成masks是最大的性能杀手一个常见的致命错误是在每一帧里调用pygame.mask.from_surface()。这个函数的开销很大因为它要遍历所有像素构建mask数据。同样的图生成一次就够了然后缓存起来反复使用。class Sprite: _mask_cache {} def __init__(self, image_path, x, y): self.image pygame.image.load(image_path).convert_alpha() self.x x self.y y if image_path not in Sprite._mask_cache: Sprite._mask_cache[image_path] pygame.mask.from_surface(self.image) self.mask Sprite._mask_cache[image_path]用类级别的字典做缓存同一张图的mask只生成一次。如果你的游戏里有大量重复素材大量相同的小怪、大量相同的弹壳这个缓存能省掉巨量的CPU开销。5.4 像素级碰撞的调试技巧像素级碰撞的bug很隐蔽因为肉眼几乎看不出到底是哪里判定重叠了。我调试的时候会在碰撞发生的位置画一个标记点# 找到重叠区域的中心点粗略 overlap_mask mask1.overlap_mask(mask2, offset) # 得到重叠区域的mask overlap_rect overlap_mask.get_bounding_rects() for rect in overlap_rect: pygame.draw.rect(screen, (255, 0, 0), (rect.x pos1[0], rect.y pos1[1], rect.w, rect.h), 1)overlap_mask返回的是两个mask重叠的那一部分mask然后get_bounding_rects()拿到重叠区域的边界矩形列表绘制成红色线框。这样在屏幕上可以直观看到碰撞点到底在哪排查精度问题会很高效。6. 分离轴定理SAT多边形碰撞的进阶方案如果你做的不只是矩形和圆的碰撞比如三角形状的敌人、六边形的地形格或者任意凸多边形物体之间的碰撞前面几节的内容就不够用了。这时需要引入游戏物理中更通用的方案——分离轴定理Separating Axis TheoremSAT。6.1 SAT的核心思想SAT的内容用一句话概括如果两个凸多边形不相交那么一定存在一条直线分离轴使得两个多边形在这条直线上的投影互不重叠。如果对所有候选轴都检查一遍都能找到一条分离轴那这两个多边形就不碰撞。反过来只要有任何一条轴上投影重叠并且所有轴都重叠那么两个多边形就是碰撞的。听起来抽象实际操作起来就是取出两个多边形的所有边计算每条边的法向量垂直向量作为候选轴。把两个多边形的所有顶点分别投影到每条轴上得到两个区间min, max。比较两个区间是否重叠。如果任何一条轴上区间不重叠则没有碰撞如果所有轴都重叠则碰撞。为什么是所有边而不是所有顶点因为只有边的法向量才能表示出两个多边形的物理边界方向。顶点本身不是方向不能作为分离轴。6.2 SAT的代码实现基础版下面是一份简化的SAT实现用于检测两个凸多边形是否碰撞import math def project_polygon(axis, vertices): # 把多边形所有顶点投影到axis上返回(min, max) dots [vec_dot(v, axis) for v in vertices] return min(dots), max(dots) def vec_dot(v1, v2): return v1[0] * v2[0] v1[1] * v2[1] def get_axes(vertices): axes [] n len(vertices) for i in range(n): p1 vertices[i] p2 vertices[(i 1) % n] edge (p2[0] - p1[0], p2[1] - p1[1]) # 法向量垂直向量 normal (-edge[1], edge[0]) axes.append(normal) return axes def check_polygon_collision(verts1, verts2): axes1 get_axes(verts1) axes2 get_axes(verts2) axes axes1 axes2 # 合并两个多边形的所有候选轴 for axis in axes: min1, max1 project_polygon(axis, verts1) min2, max2 project_polygon(axis, verts2) if max1 min2 or max2 min1: return False # 存在一条分离轴未碰撞 return True # 所有轴都重叠碰撞这份代码里我又用了一个平方根都省掉的版本吗没有。这里的法向量不需要归一化因为区间重叠判断只关心相对位置法向量的长度不影响是否重叠的布尔结果。但如果需要计算碰撞深度和方向就必须把法向量归一化。6.3 SAT的边界条件凹多边形怎么办SAT只适用于凸多边形。如果你有L形、U形这种凹多边形直接套SAT可能会漏报。原因在于凹多边形的分离轴不一定是边的法向量它可能有缺口导致无法用单一投影轴表示。处理方式有两种把凹多边形拆分成多个凸多边形三角剖分或矩形分解分别做碰撞检测。用像素遮罩替代。第一种方案的精度高、性能也可控但需要额外的几何分解工具第二种方案实现简单但性能开销大。我项目里的做法是地图碰撞体都构建成凸多边形组合角色、道具保持圆形或矩形尽量不引入凹多边形碰撞。6.4 SAT的工程实践理论上说SAT适合任意凸多边形碰撞但我实际使用中很少把所有游戏物体都做成凸多边形。一个例外是六边形网格游戏比如战棋、模拟经营里的六边形地块。六边形地块之间的碰撞判断如果用AABB两个倾斜的边会有明显的多余判定区域如果用圆形又没法贴合六边形的形状。这时SAT就非常合适六边形只有6条边投影轴最多12条两个六边形各6条性能开销完全可以接受。def generate_hexagon(center_x, center_y, size): # 生成正六边形顶点坐标 vertices [] for i in range(6): angle_deg 60 * i - 30 # 平顶六边形偏移30度 angle_rad math.radians(angle_deg) x center_x size * math.cos(angle_rad) y center_y size * math.sin(angle_rad) vertices.append((x, y)) return vertices配合上面的SAT检测函数就能实现六边形单位之间的精确碰撞判定。这也是我推荐的SAT使用场景形状确定、数量可控、需要精确边界。7. 当碰撞检测遇上大量物体空间分区与性能优化你写的游戏如果只是几个物体互撞那前面所有内容已经够用了。但一旦进入子弹横飞、满地掉落物、大量敌人的场景性能问题会扑面而来。我印象最深的一次是把一个俯视角射击游戏的子弹数量从100提升到500帧率直接掉了一半定位后发现全部耗在了两两碰撞检测上。7.1 暴力两两检测的时间复杂度假设有N个物体两两检测的次数是N * (N - 1) / 2。当N100时是4950次N500时是124750次翻了25倍。每一帧要做12万多次碰撞检测Python这样解释型语言根本扛不住。这时候需要的不是优化单次碰撞检测的算法而是减少需要检测的物体对数量。7.2 空间网格Spatial Hashing最经典的2D空间分区空间网格的思想非常朴素把游戏世界划分成大小相等的格子每个格子记录它包含的物体列表。物体移动时更新自己所在的格子列表。做碰撞检测时只需要检查同一格子内的物体以及相邻格子内的物体不需要和全屏所有物体做两两检测。class SpatialGrid: def __init__(self, cell_size): self.cell_size cell_size self.grid {} def _cell_coords(self, x, y): return (int(x // self.cell_size), int(y // self.cell_size)) def add(self, entity): coords self._cell_coords(entity.x, entity.y) self.grid.setdefault(coords, []).append(entity) def clear(self): self.grid.clear() def get_nearby(self, entity): # 获取物体所在格及周围8个格子里的所有物体 cx, cy self._cell_coords(entity.x, entity.y) nearby [] for dx in (-1, 0, 1): for dy in (-1, 0, 1): cell self.grid.get((cx dx, cy dy)) if cell: nearby.extend(cell) return nearby每个格子的大小怎么定一般是取场景中物体平均尺寸的1到2倍。格子太小物体跨格频繁更新开销大格子太大每个格子里塞的物体太多加速效果减弱。我项目中有一个俯视角射击关卡地图全尺寸是2000×2000子弹和敌人数量合计约400个用80像素的格子划分后每帧碰撞检测次数降到不到原来的十分之一帧率恢复稳定。7.3 四叉树Quadtree更精细的动态分区如果物体尺寸差异特别大有全屏Boss也有微小的子弹均匀网格就不太合适了。大物体会霸占很多格子导致相邻格子重复计算严重。这时候可以考虑四叉树Quadtree。四叉树把空间递归分成四等份每个节点最多存储一定数量的物体超过阈值就继续分裂。查询时从根节点往下走只检查与查询区域相交的子树。四叉树实现比网格复杂很多调试也费劲。我的建议是除非物体尺寸差异确实很大否则先上空间网格。网格简单、可预测性强、出bug好排查。四叉树属于有必要再上的优化方案普通2D游戏90%的场景用网格就够了。7.4 避免重复检测只检测一次每一对就算用了空间分区同一个格子里仍然可能存在A和B互相检测两次的情况——A检测BB又检测A。对于布尔碰撞检测来说这是纯浪费。一个经典做法是给物体加一个自增ID只让ID较小的物体负责对ID较大的物体做检测def check_pair(entity_a, entity_b): if entity_a.id entity_b.id: return False # 由ID小的负责检测避免重复 # 执行具体碰撞判断 return do_collision(entity_a, entity_b)7.5 优化不要过早进行最后说一句经验之谈性能优化一定要用数据说话不要凭感觉优化一切。我用cProfile分析后发现很多时候卡顿的根源不在碰撞检测本身而在于每帧刷新了太多不需要刷新的像素级surface或者每帧都创建了新对象导致垃圾回收频繁。做性能优化的正确顺序是先用cProfile找到热点函数确认碰撞检测确实是瓶颈再上空间分区、避免重复检测等手段每做一步都重新测量帧率变化不要一上来就写几百行四叉树代码最后发现碰撞检测只占CPU的10%白白浪费时间。8. 碰撞发生之后响应与反弹检测到碰撞只是第一步游戏手感好不好全看碰撞之后怎么响应。如果你只是打印一行日志告诉玩家你撞到墙了那这个游戏肯定没法玩。碰撞响应要解决的核心问题是碰撞之后物体应该停在哪儿、速度怎么变、是否反弹或销毁。8.1 最小平移向量MTV碰撞后要把物体推出去需要知道两个物体重叠部分的最小平移方向这个向量叫最小平移向量Minimum Translation VectorMTV。方向是分离的方向长度是最小的穿透深度。计算MTV需要知道两个碰撞体的详细几何信息。AABB计算MTV相对简单——比较X轴和Y轴的重叠量哪个轴重叠更少就沿哪个轴方向推开def get_mtv_aabb(rect1, rect2): overlap_x min(rect1.right - rect2.left, rect2.right - rect1.left) overlap_y min(rect1.bottom - rect2.top, rect2.bottom - rect1.top) if overlap_x overlap_y: # 沿X轴推开 direction 1 if rect1.centerx rect2.centerx else -1 return (direction * overlap_x, 0) else: # 沿Y轴推开 direction 1 if rect1.centery rect2.centery else -1 return (0, direction * overlap_y)不过我实际用下来在平台跳跃游戏里用MTV直接推容易让角色卡在墙边尤其是同时撞到两面墙的时候。更常用的做法是分轴处理先沿X轴移动并检测碰撞解决X方向碰撞后再沿Y轴移动并检测。def move_and_collide(entity, dx, dy, obstacles): # X轴移动 entity.x dx entity.rect.x entity.x for obs in obstacles: if entity.rect.colliderect(obs.rect): if dx 0: entity.x obs.rect.left - entity.width elif dx 0: entity.x obs.rect.right entity.rect.x entity.x # Y轴移动 entity.y dy entity.rect.y entity.y for obs in obstacles: if entity.rect.colliderect(obs.rect): if dy 0: entity.y obs.rect.top - entity.height elif dy 0: entity.y obs.rect.bottom entity.rect.y entity.y这个分轴方案虽然比MTV笨但在2D平台游戏里非常稳不会出现斜向移动时被卡在墙角的情况。原因在于它把二维碰撞问题拆成了一维问题每次只处理一个方向逻辑清晰且基本没有歧义。8.2 反弹与能量衰减如果做的是打砖块、弹球这类游戏碰撞后还需要反弹。边界反弹很简单if ball.left 0 or ball.right screen_width: ball.vx -ball.vx if ball.top 0: ball.vy -ball.vy if ball.bottom screen_height: # 球掉了处理生命或游戏结束但如果球和挡板、砖块之间是任意角度碰撞就需要按碰撞法线方向做反射def reflect(velocity, normal): # velocity 是当前速度向量 (vx, vy) # normal 是碰撞法向量单位向量 dot velocity[0] * normal[0] velocity[1] * normal[1] return (velocity[0] - 2 * dot * normal[0], velocity[1] - 2 * dot * normal[1])这个反射公式是反射定理的直接应用把速度向量沿法线方向翻转一次就能得到反弹后的速度。记得加上能量衰减乘以0.8之类否则球越弹越快游戏会变得不可控。8.3 避免抖动碰撞后的位置修正碰撞响应里最烦人的问题是物体抖动或穿模。物体被推出碰撞体后如果下一帧又因为重力或移动量再次陷入就会产生高频的抖动。解决思路是在碰撞修正后给物体的速度加上一个沿碰撞方向的分量清零处理。比如角色在平台上落地时把y方向速度归零否则下一帧重力又把角色拉回平台内部。if entity.rect.bottom ground.rect.top and entity.vy 0: entity.y ground.rect.top - entity.height entity.vy 0 # 落地后竖直速度清零 entity.on_ground True这个细节看起来简单却是平台跳跃游戏手感好与坏的巨大分水岭。很多新手写完碰撞检测后没做速度归零角色会在接触地面的一瞬间反复弹跳动作极不自然。9. 七条我踩过的坑和调试技巧这一节我把自己这几年做Python游戏碰撞检测踩过最深的坑和对应的解决技巧集中整理一下全部是能直接帮你少加班的东西。9.1 Rect对象是整型坐标注意精度损失pygame的pygame.Rect有一个隐藏特性它的坐标和大小都是整数。当你把entity.x赋值为100.7时entity.rect.x会变成100小数部分被截断。在做高精度物理模拟时这个误差会积累导致物体位置长期运行后漂移。解决方法是核心逻辑用浮点数存坐标只在需要绘制和碰撞检测时才同步到Rect。我实际做项目时的做法是Entity类维护自己的x, y浮点坐标rect属性每次都从浮点坐标生成整数Rect这样既保留了物理精度又兼容了pygame的整型Rect。9.2 collidelist的第一个碰撞对象陷阱前面提过collidelist只返回第一个碰撞对象但在物体密集场景下第一个很可能是你根本不想撞到的那个。比如子弹应该撞到最近的墙但因为墙A在列表里排前面子弹先和毛茸茸的队友碰撞了。稳妥做法是遍历所有候选碰撞体计算重叠面积或穿透深度选择最小的那个作为碰撞对象。def get_closest_collision(rect, obstacles): best_index -1 best_overlap float(inf) for i, obs in enumerate(obstacles): if rect.colliderect(obs.rect): overlap_area compute_overlap_area(rect, obs.rect) if overlap_area best_overlap: best_overlap overlap_area best_index i return best_index9.3 碰撞回调里不要修改正在遍历的列表这是Python开发里特别经典的一个坑你在遍历bullet_list做碰撞检测发现子弹碰到敌人后直接bullet_list.remove(bullet)然后Python的for循环可能会跳过下一个元素或者直接抛RuntimeError: dictionary changed size during iteration。我的经验做法是碰撞处理不立即修改列表先记录需要销毁的物体遍历结束后统一处理。to_remove [] for bullet in bullet_list: if bullet_collides_with_enemy(bullet): to_remove.append(bullet) # 给敌人减血、生成特效等 for bullet in to_remove: bullet_list.remove(bullet)9.4 使用分层碰撞掩码避免不相关物体做检测如果游戏有玩家子弹只攻击敌人、敌人子弹只攻击玩家、道具只能被玩家拾取这些规则你的碰撞检测循环里会做大量无效判断。一个轻量级方案是给物体加一个collision_layer属性检测前先判断两层是否匹配。class Layer: PLAYER 1 ENEMY 2 PLAYER_BULLET 4 ENEMY_BULLET 8 ITEM 16 # 使用位掩码表示响应的碰撞层 entity.collision_mask Layer.PLAYER | Layer.ITEM def can_collide(a, b): return bool(a.collision_layer b.collision_mask)这种分层方案在处理复杂交互时优势明显也方便后续扩展比如增加陷阱只伤害玩家和敌人的新规则只需添加一个层位。9.5 帧率独立下的碰撞表现使用delta time如果游戏循环的帧率不稳定有的电脑跑144帧有的只有30帧碰撞检测在高帧率下会过于灵敏低帧率下又过于迟钝。这涉及一个根本问题物理模拟的步长和渲染帧率的耦合。标准解法是引入delta time上一帧到这一帧的实际时间把速度的单位从像素/帧改成像素/秒。高速物体的位移就变成了speed * dt再配合前面讲到的子步进方案可以保证不同帧率下碰撞行为基本一致。dt clock.tick(60) / 1000.0 # 单位秒 bullet.x bullet.speed_x * dt bullet.y bullet.speed_y * dt9.6 可视化调试器才是碰撞检测的好朋友碰撞检测是个看不见摸不着的逻辑过程纯靠print输出调试效率极低。我这几年养成的习惯是在游戏窗口里直接画出所有碰撞体# 调试模式画出所有碰撞矩形 for entity in all_entities: pygame.draw.rect(screen, (0, 255, 0), entity.rect, 1) # 画出碰撞点标记为红色 for collision_point in collision_points: pygame.draw.circle(screen, (255, 0, 0), collision_point, 3)把碰撞体可视化后很多问题一目了然碰撞体比贴图大一圈导致空气判定、碰撞体位置偏移导致模型和判定错位、多个碰撞体重叠导致多层碰撞等等。建议在项目的开发期始终保留这个可视化开关调试起来非常方便。9.7 负数坐标与屏幕外边界如果你的游戏世界比屏幕大有滚动的摄像机物体可能出现在负坐标或超出屏幕边界的位置。pygame的Rect处理负数坐标完全没问题但空间网格和碰撞检测代码里用整数除法//处理负数坐标时要小心方向。# 当 x -10, cell_size 80 时 # int(-10 // 80) -1在Python里是向下取整 # 如果在C语言里x / 80 0向零取整结果完全不同 # 所以用Python时负数坐标的格子索引是负数这是正常的 # 但如果你把索引传给数组记得做偏移或归一化空间网格的字典key存的是元组(cx, cy)不要直接把cx当数组下标用用字典就不会有负数索引问题。10. 一个完整的小例子玩家避开圆形陷阱并拾取道具为了把这些内容串起来我写了下面这个自认为是最小可用的示例。场景玩家矩形需要移动避开圆形陷阱圆形碰到圆形道具圆形时拾取。用到了AABB碰撞、圆形碰撞、圆与矩形混合碰撞、空间网格简单版、delta time移动。import pygame import math import random pygame.init() screen pygame.display.set_mode((800, 600)) clock pygame.time.Clock() class Player: def __init__(self, x, y): self.x float(x) self.y float(y) self.width 40 self.height 40 self.speed 200 # 像素/秒 property def rect(self): return pygame.Rect(int(self.x), int(self.y), self.width, self.height) class Trap: def __init__(self, x, y, radius): self.x float(x) self.y float(y) self.radius radius def collide_with_rect(self, rect): return check_circle_rect(self.x, self.y, self.radius, rect.x, rect.y, rect.width, rect.height) class Item: def __init__(self, x, y, radius): self.x float(x) self.y float(y) self.radius radius self.collected False def collide_with_rect(self, rect): # 找到矩形离圆心最近的点 closest_x max(rect.x, min(self.x, rect.x rect.width)) closest_y max(rect.y, min(self.y, rect.y rect.height)) dx self.x - closest_x dy self.y - closest_y return dx * dx dy * dy self.radius * self.radius def check_circle_rect(cx, cy, r, rx, ry, rw, rh): closest_x max(rx, min(cx, rx rw)) closest_y max(ry, min(cy, ry rh)) dx cx - closest_x dy cy - closest_y return dx * dx dy * dy r * r # 生成道具和陷阱 items [] for _ in range(5): items.append(Item(random.randint(100, 700), random.randint(100, 500), 20)) traps [] for _ in range(4): traps.append(Trap(random.randint(100, 700), random.randint(100, 500), 35)) player Player(50, 300) running True font pygame.font.SysFont(Arial, 24) collected_count 0 while running: dt clock.tick(60) / 1000.0 for event in pygame.event.get(): if event.type pygame.QUIT: running False keys pygame.key.get_pressed() dx, dy 0, 0 if keys[pygame.K_LEFT]: dx -player.speed * dt if keys[pygame.K_RIGHT]: dx player.speed * dt if keys[pygame.K_UP]: dy -player.speed * dt if keys[pygame.K_DOWN]: dy player.speed * dt # 分轴移动并限制在窗口内 player.x dx player.x max(0, min(player.x, 800 - player.width)) player.y dy player.y max(0, min(player.y, 600 - player.height)) # 陷阱碰撞检测碰到则重置位置 player_rect player.rect for trap in traps: if trap.collide_with_rect(player_rect): player.x, player.y 50, 300 break # 道具碰撞检测拾取 for item in items: if not item.collected and item.collide_with_rect(player_rect): item.collected True collected_count 1 # 绘制 screen.fill((30, 30, 30)) for trap in traps: pygame.draw.circle(screen, (220, 50, 50), (int(trap.x), int(trap.y)), trap.radius) for item in items: if not item.collected: pygame.draw.circle(screen, (50, 220, 100), (int(item.x), int(item.y)), item.radius) pygame.draw.rect(screen, (70, 130, 240), player.rect) # 显示得分 text font.render(fCollected: {collected_count}/5, True, (255, 255, 255)) screen.blit(text, (10, 10)) if collected_count 5: end_text font.render(You Win! Press R to restart, True, (255, 255, 255)) screen.blit(end_text, (250, 250)) pygame.display.flip() pygame.quit()这段代码的运行逻辑不复杂玩家用方向键移动碰红色圆陷阱就回到起点碰绿色圆道具就拾取。注意道具和陷阱的碰撞检测用的是同一种check_circle_rect函数只是应用场景不同。实际项目里你可以给不同的碰撞事件挂不同的回调这样代码组织会更清晰。在添加新的碰撞组合时我的建议是先把所有碰撞体的形状类型抽成枚举然后在统一的地方分发到对应的检测函数。这样后续要加三角形陷阱胶囊形状的角色只需要新增一个分支不需要改动上层逻辑。11. 版本、引擎与库的选择建议聊了这么多实操最后简单说说Python做游戏碰撞检测可以借助的底层库和引擎。很多人纠结于我用pygame好还是用arcade还是要上Godot?11.1 pygame自己动手的经典选择pygame是我用得最多的库它的Rect、Sprite、mask等模块提供了碰撞检测的基础工具但不会替你处理复杂物理。适合想理解游戏底层逻辑、对碰撞检测有定制需求的开发者。缺点是你需要自己实现空间分区、碰撞响应等高级功能。11.2 arcade内置更高级的物理和碰撞处理arcade是一个比pygame更现代化的2D游戏库内置了精灵列表SpriteList的碰撞检测支持空间哈希加速也提供了简单的物理引擎重力、摩擦力、平台支持。如果你不想从头写碰撞响应arcade能帮你省掉不少时间。但它的社区和教程数量比pygame少一些遇到冷门问题排查起来会费劲。11.3 pygame pymunk需要真实物理效果时的组合如果你的游戏需要更真实的物理模拟——有质量、速度、弹性系数、摩擦力——自己手写碰撞响应的成本会急剧上升。这时可以用pymunk一个2D物理引擎底层是Chipmunk2D配合pygame绘制。把pymunk当作物理计算核心pygame当作渲染层。这也是我做物理类原型时常用的组合。11.4 自定义碰撞检测 vs 游戏引擎很多刚接触游戏开发的朋友会问我用Pygame还是Unity/Godot我的建议是如果你学习Python的目标是理解编程逻辑和算法用Pygame自己实现碰撞检测是宝贵的训练。它逼着你把数学、数据结构和算法串起来一本书读三遍都不如亲手实现一次AABB和SAT来得深刻但如果你只想快速做出一个游戏Demo不想在底层细节上花时间直接用Godot或Unity的现成物理系统效率高得多。不要有我用Pygame写碰撞检测所以我很硬核的虚荣心选择工具的标准始终是项目目标和时间成本。我自己做商业项目时如果时间紧会直接用Unity做教学演示或算法验证才会用Python手写。12. 写在最后的个人体会碰撞检测这个模块技术上不算难但做好它涉及的面非常广——数学、数据结构、性能优化、用户手感、代码架构每一项都能单独写一篇文章。我在做项目时发现真正让游戏好玩的很多时候不是那些炫酷特效而是碰撞手感打磨得是否细腻。角色撞墙会不会卡住、子弹飞行稳不稳定、敌人攻击判定是否公平这些微小的体验最终决定了玩家对这个游戏的评价。在我自己写的所有碰撞检测方案里最简单可靠的反而是AABB加分轴移动复杂方案只在特定场景才值得引入。遇到碰撞问题我会提醒自己先做最小复现、画可视化调试框、确认几何表示方式再考虑要不要上更复杂的算法。大多数时候问题并不是算法不够高级而是坐标算错了一个像素或者忘记清零了速度。希望这篇文章里那些踩坑记录和调试思路能给你的Python游戏开发省下几个加班的晚上。动手写起来把例子跑起来再改成你自己的游戏规则——碰撞检测这东西只有亲手调过才知道里面的门道。 Python 2D游戏碰撞检测全攻略：从AABB到性能优化
1. 从物体重叠到游戏逻辑碰撞检测到底在解决什么问题做游戏开发的人大概率都有过这种经历玩家明明没有碰到敌人血条却掉了子弹从怪物体内穿过去判定却没触发或者角色卡在墙里出不来。这些看似八竿子打不着的问题最终排查下来十有八九都出在碰撞检测上。碰撞检测Collision Detection说白了就是判断两个物体有没有发生重叠或接触这件事听起来简单做起来牵扯到的东西却不少。我在用Python写游戏的时候尤其是从纯逻辑Demo过渡到真正能玩的游戏时碰撞检测的精度和性能直接决定了手感的好坏。这篇文章不打算堆理论而是把我实际做项目时真正用得上、踩过坑的那些方案拿出来聊。包括常见的矩形碰撞AABB、圆形碰撞、像素级碰撞以及处理大量物体时的性能优化思路。如果你正在用Pygame、Pyglet或者纯Python写游戏或者在做一个需要检测物体是否重叠的交互应用这篇文章应该能帮你少走不少弯路。我默认你已经有了一点Python基础会写类和函数但对碰撞检测只有模糊概念。下面所有内容我都是从如何真正落地的角度来讲。2. 坐标系与两个物体的定义方式碰撞检测的地基在聊具体算法之前必须先搞清楚一件事代码里的物体是怎么表示的。不同表示方式决定了后面用哪种碰撞检测算法也决定了精度上限。2.1 一切检测的前提物体先得有形状游戏里的物体在内存里并不是一张连续的画面而是一堆数据和属性。要做碰撞检测首先要给物体定义一个可供计算的形状。最常用的有三种轴对齐包围盒AABBAxis-Aligned Bounding Box用一个不旋转的矩形框住物体存左上角坐标x, y和宽高width, height。这是最省计算量的表示方式绝大多数2D游戏的基础碰撞都用它。圆形Circle存圆心坐标cx, cy和半径r。旋转不影响判断而且距离计算非常快。像素遮罩Mask按像素级别记录物体的不透明区域精度最高但计算成本也最高。这三种表示方式对应着三种核心判断算法矩形与矩形、圆与圆、像素与像素或者混合类型。实际项目中很少只用一种。比如角色用矩形子弹用圆形地形用矩形组合特效用遮罩——混合检测才是常态。提示在做碰撞检测之前最好先在代码里给物体建立统一的位置-形状数据结构。我习惯定义一个Entity基类把绘制和碰撞属性分开存。我在项目里通常这样初始化一个可碰撞的物体import pygame class Entity: def __init__(self, x, y, width, height): self.x x # 左上角x坐标 self.y y # 左上角y坐标 self.width width # 宽度 self.height height # 高度 property def rect(self): # 每次动态生成pygame.Rect方便复用pygame内置碰撞函数 return pygame.Rect(self.x, self.y, self.width, self.height)用一个rect属性实时生成矩形而不是在__init__里固定一个rect对象是因为游戏里物体随时在移动固定rect需要反复同步坐标容易漏更。动态生成虽然多了一点计算但在物体数量不多时几乎可以忽略。2.2 为什么绝不要用中心点距离判断两个矩形是否碰撞很多刚入门的朋友会犯一个错计算两个矩形的中心点距离如果小于某个阈值就认为碰撞了。这个思路对圆形勉强说得通对矩形就行不通了——矩形不是各向同性的宽高不同时中心距离根本不能代表实际边界关系。举个例子两个100×10的长条矩形上下叠在一起中心点距离小于50的时候其实已经重叠了但如果是100×100的正方形重叠判定距离就到了70.7左右。用一个固定阈值去套所有矩形结果必然是一会儿穿透一会儿误报。正确的做法是把判断问题转化为区间重叠问题。两个矩形在X轴上各自占据一个区间在Y轴上也各自占据一个区间。只有X和Y方向上都重叠两个矩形才算碰撞。def check_aabb(rect1, rect2): # rect1, rect2 分别是 (x, y, width, height) x1, y1, w1, h1 rect1 x2, y2, w2, h2 rect2 overlap_x (x1 x2 w2) and (x2 x1 w1) overlap_y (y1 y2 h2) and (y2 y1 h1) return overlap_x and overlap_y这套逻辑就是标准的AABB碰撞检测。pygame里有现成的Rect.colliderect()方法但搞清楚底层逻辑很重要因为后面做性能优化或者移植到其他框架时你总要自己实现一遍。而且colliderect在某些极端情况下比如一个物体完全包含另一个物体时的行为不同版本的pygame表现略有差异懂原理才知道怎么排查。2.3 坐标系里的方向坑y轴正方向是往下Python的2D图形库pygame、tkinter等遵循屏幕坐标系原点在左上角x轴向右递增y轴向下递增。这和数学课上的坐标系是反的。做碰撞检测时这个方向性影响很大尤其是涉及碰撞方向判断时——比如角色头顶撞到砖块或者脚底踩到地面。我早期写平台跳跃游戏时判断角色是否落地用的是player_rect.bottom ground_rect.top但没考虑到y轴向下增长bottom其实是数值更大的那一边。结果角色全程浮空怎么都落不了地。后来把所有判断都换成数值比较而非视觉上、下来理解才彻底理顺。这是一个很基础但非常容易阴沟翻船的细节。建议你在代码里加注释的时候不要写上、下直接写y值小的一侧、y值大的一侧避免自己把自己绕晕。3. 逐帧检测还是实时检测为什么你的子弹会穿透墙壁玩过FPS游戏的读者对子弹穿透应该不陌生但2D游戏里同样有这个问题。一个高速移动的子弹每帧移动了50像素而一面墙只有30像素厚。如果只在每帧结束时检查有没有重叠子弹可能上一帧还在墙左边下一帧就到了墙右边中间的碰撞过程完全没被捕捉到。3.1 离散检测的局限游戏循环的本质是离散的——每一帧计算一次位置然后刷新画面。碰撞检测天然有盲区它只检查当前时刻的重叠状态而不关心两个物体之间某个瞬间是否交叉而过。这个问题在物理模拟里有个专门的名字隧穿效应Tunneling。物体速度越快、帧率越低、障碍物越薄隧穿越容易发生。3.2 常用的三种应对方案方案一限制最大速度最简单粗暴让物体的每帧位移小于最小碰撞体的厚度。比如墙壁厚度是30像素帧率恒定60FPS那么物体速度要控制在30 × 60 1800像素/秒以内。这种方案适合控制节奏的游戏但遇到加速、冲刺技能就失灵了。方案二细分时间片子步进Sub-stepping把一帧内的移动拆成几个小步每一步都做一次碰撞检测。帧之间位移为50像素那就拆成5步每步只移动10像素这样就不会跳过30像素厚的墙了。代价是碰撞检测调用次数变多性能开销上升。def move_with_collision(entity, dx, dy, obstacles, substeps5): step_x dx / substeps step_y dy / substeps for _ in range(substeps): entity.x step_x entity.y step_y for obs in obstacles: if check_aabb(entity.rect, obs.rect): # 处理碰撞把物体推回去 resolve_collision(entity, obs)这个方案的优点是逻辑简单容易理解几乎所有2D游戏引擎包括一些3D引擎都支持类似配置。缺点是需要预估最大可能位移步长太密会浪费性能太疏又可能漏检。方案三连续碰撞检测CCDContinuous Collision Detection把物体的运动轨迹看作一条线段检测这条线段是否与障碍物相交。这是物理引擎如Box2D、Bullet的常规做法精确度高但实现复杂度也高。2D游戏里如果要用射线与矩形的相交判断会牵扯到参数方程和区间求解。我在真实项目里的建议是大部分情况下用方案一配合方案二只在子弹、激光这类极高速物体上用CCD。不要一上来就全场景CCD计算量翻倍不说调试起来也麻烦。3.3 修正后的子弹移动检测模板我用pygame写过一套高速子弹检测的模板核心思路就是细分步进 AABB检测 碰撞点修正import pygame def move_bullet(bullet, dx, dy, solid_objects): # bullet.rect 是子弹当前矩形bullet.speed 越大越需要细分步进 distance max(abs(dx), abs(dy)) if distance 0: return False # 每步移动不超过 2 像素避免隧穿 steps max(1, int(distance / 2)) step_dx dx / steps step_dy dy / steps for _ in range(steps): bullet.rect.x step_dx bullet.rect.y step_dy hit_index bullet.rect.collidelist(solid_objects) if hit_index ! -1: # 碰到的物体是 solid_objects[hit_index] # 这里可以记录碰撞点用于生成特效或者伤害判定 return True return Falsecollidelist是pygame提供的方法返回第一个碰撞的物体索引没有则返回-1。但要注意它返回的是第一个碰撞对象如果物体重叠严重可能不是你想撞的那个。在高精度需求下我建议遍历所有固体对象找出重叠面积最大的那个作为实际碰撞对象。4. 圆形碰撞与混合碰撞当球撞上矩形数学就不一样了很多游戏里角色和子弹的碰撞体不都是矩形。比如玩家角色用圆形更贴合子弹用小矩形或小圆地形又是矩形。这时就需要混合碰撞检测。4.1 圆与圆直接算距离圆和圆的碰撞检测是最直观的两个圆心之间的距离小于等于半径之和就算碰撞。import math def check_circle_collision(cx1, cy1, r1, cx2, cy2, r2): dx cx1 - cx2 dy cy1 - cy2 distance_sq dx * dx dy * dy radius_sum r1 r2 return distance_sq radius_sum * radius_sum注意我用的是平方距离比较没有调用math.sqrt()。半径之和的平方不会超过距离平方的比较结果省掉开根号在高频调用里能省不少计算量。这一点在下面讲性能优化时还会再提。4.2 圆与矩形把矩形膨胀成圆角矩形圆和矩形的碰撞检测比圆与圆复杂一点但也不难。思路是找到矩形上离圆心最近的点算这个点到圆心的距离如果小于半径就算碰撞。这个最近点怎么找把圆心坐标分别钳位clamp到矩形的左右边界和上下边界之间def check_circle_rect(circle_cx, circle_cy, radius, rect_x, rect_y, rect_w, rect_h): # 钳位将圆心坐标限制在矩形范围内 closest_x max(rect_x, min(circle_cx, rect_x rect_w)) closest_y max(rect_y, min(circle_cy, rect_y rect_h)) dx circle_cx - closest_x dy circle_cy - closest_y distance_sq dx * dx dy * dy return distance_sq radius * radius这段代码听起来玄乎用生活化的类比就是你在一个房间里找离窗外某棵树最近的点树在窗左边最近点就是窗框左缘树在窗上方最近点就是窗框上缘树正好在窗子里最近点就是树本身的位置。如果圆心的x坐标在矩形x范围内且圆心的y坐标也在矩形y范围内那最近点就是圆心自己距离为0必然碰撞——这种情况对应圆心在矩形内部。4.3 圆形碰撞体在实际项目中的应用我在做俯视角2D射击游戏时玩家和敌人的碰撞体都用了圆形原因是角色的各个朝向视觉宽度差异不大圆形判定比矩形更公平玩家操控时不容易出现明明看着躲过了却被判定击中的憋屈感。后来加Boss战Boss是一个大型矩形机甲玩家子弹是圆形就用check_circle_rect来做子弹与Boss的判定实测稳定。实战中碰撞体类型的选择有个经验法则角色对角色、子弹对角色优先用圆形判定平滑、玩家体验好角色对地形、子弹对墙体优先用矩形AABB贴合地图格子便于做格子碰撞像素级美术的手绘物体比如不规则洞穴考虑像素遮罩但只限于数量很少的场景要物体5. 像素级碰撞检测什么时候真的需要怎么用才不卡说了半天矩形和圆形这两种方案的精度上限就是形状近似。当两个物体的视觉形状和矩形差异过大时比如一个星形的收集品、一个不规则的云朵平台用矩形碰撞就会出现明显违和星星明明没碰到却判定收集云朵有透明区域却像实心墙一样挡住角色。5.1 pygame.mask从Surface生成遮罩pygame里提供了pygame.mask模块可以从一张带透明通道的图片Surface中生成像素遮罩Mask对象里记录了这个图片的哪些像素是不透明的。然后可以用overlap()方法检查两个遮罩有没有重叠的不透明像素。import pygame sprite_surface pygame.image.load(star.png).convert_alpha() sprite_mask pygame.mask.from_surface(sprite_surface) enemy_surface pygame.image.load(enemy.png).convert_alpha() enemy_mask pygame.mask.from_surface(enemy_surface) # 放置两个精灵的位置左上角坐标 sprite_pos (100, 100) enemy_pos (105, 102) # offset 是 enemy 相对于 sprite 的坐标偏移 offset (enemy_pos[0] - sprite_pos[0], enemy_pos[1] - sprite_pos[1]) if sprite_mask.overlap(enemy_mask, offset): print(像素级碰撞发生)这里最关键的是offset的计算逻辑。overlap(other_mask, offset)方法中offset表示的是把other_mask放在当前mask的什么相对位置上。官方文档里写的是offset是other_mask相对于self_mask的偏移量。我每次写这个代码都要在草稿纸上画一遍坐标不然方向很容易搞反。如果你把精灵和敌人的位置都用左上角坐标表示那么offset就是(enemy_x - sprite_x, enemy_y - sprite_y)。5.2 性能问题两万个像素的代价像素级碰撞最让人头疼的是性能。一张200×100的贴图遮罩就有2万个像素。如果两个遮罩做overlap检测最坏情况要逐像素比较几千组物体同屏的时候能把CPU吃满。所以我的经验是像素级碰撞只用于高频接触中的少数关键物体。具体来说可以做一个两级检测策略先用AABB粗检测。如果两个物体的矩形包围盒都不重叠直接跳过根本不做像素检测。只有AABB检测通过了才去做像素级overlap。这样可以过滤掉绝大多数远距离不相干的物体对。def precise_collide(sprite1, pos1, sprite2, pos2): # 第一级AABB粗判断 rect1 pygame.Rect(pos1[0], pos1[1], sprite1.get_width(), sprite1.get_height()) rect2 pygame.Rect(pos2[0], pos2[1], sprite2.get_width(), sprite2.get_height()) if not rect1.colliderect(rect2): return False # 第二级像素级精确判断 mask1 pygame.mask.from_surface(sprite1) mask2 pygame.mask.from_surface(sprite2) offset (pos2[0] - pos1[0], pos2[1] - pos1[1]) return mask1.overlap(mask2, offset) is not None5.3 每帧都生成masks是最大的性能杀手一个常见的致命错误是在每一帧里调用pygame.mask.from_surface()。这个函数的开销很大因为它要遍历所有像素构建mask数据。同样的图生成一次就够了然后缓存起来反复使用。class Sprite: _mask_cache {} def __init__(self, image_path, x, y): self.image pygame.image.load(image_path).convert_alpha() self.x x self.y y if image_path not in Sprite._mask_cache: Sprite._mask_cache[image_path] pygame.mask.from_surface(self.image) self.mask Sprite._mask_cache[image_path]用类级别的字典做缓存同一张图的mask只生成一次。如果你的游戏里有大量重复素材大量相同的小怪、大量相同的弹壳这个缓存能省掉巨量的CPU开销。5.4 像素级碰撞的调试技巧像素级碰撞的bug很隐蔽因为肉眼几乎看不出到底是哪里判定重叠了。我调试的时候会在碰撞发生的位置画一个标记点# 找到重叠区域的中心点粗略 overlap_mask mask1.overlap_mask(mask2, offset) # 得到重叠区域的mask overlap_rect overlap_mask.get_bounding_rects() for rect in overlap_rect: pygame.draw.rect(screen, (255, 0, 0), (rect.x pos1[0], rect.y pos1[1], rect.w, rect.h), 1)overlap_mask返回的是两个mask重叠的那一部分mask然后get_bounding_rects()拿到重叠区域的边界矩形列表绘制成红色线框。这样在屏幕上可以直观看到碰撞点到底在哪排查精度问题会很高效。6. 分离轴定理SAT多边形碰撞的进阶方案如果你做的不只是矩形和圆的碰撞比如三角形状的敌人、六边形的地形格或者任意凸多边形物体之间的碰撞前面几节的内容就不够用了。这时需要引入游戏物理中更通用的方案——分离轴定理Separating Axis TheoremSAT。6.1 SAT的核心思想SAT的内容用一句话概括如果两个凸多边形不相交那么一定存在一条直线分离轴使得两个多边形在这条直线上的投影互不重叠。如果对所有候选轴都检查一遍都能找到一条分离轴那这两个多边形就不碰撞。反过来只要有任何一条轴上投影重叠并且所有轴都重叠那么两个多边形就是碰撞的。听起来抽象实际操作起来就是取出两个多边形的所有边计算每条边的法向量垂直向量作为候选轴。把两个多边形的所有顶点分别投影到每条轴上得到两个区间min, max。比较两个区间是否重叠。如果任何一条轴上区间不重叠则没有碰撞如果所有轴都重叠则碰撞。为什么是所有边而不是所有顶点因为只有边的法向量才能表示出两个多边形的物理边界方向。顶点本身不是方向不能作为分离轴。6.2 SAT的代码实现基础版下面是一份简化的SAT实现用于检测两个凸多边形是否碰撞import math def project_polygon(axis, vertices): # 把多边形所有顶点投影到axis上返回(min, max) dots [vec_dot(v, axis) for v in vertices] return min(dots), max(dots) def vec_dot(v1, v2): return v1[0] * v2[0] v1[1] * v2[1] def get_axes(vertices): axes [] n len(vertices) for i in range(n): p1 vertices[i] p2 vertices[(i 1) % n] edge (p2[0] - p1[0], p2[1] - p1[1]) # 法向量垂直向量 normal (-edge[1], edge[0]) axes.append(normal) return axes def check_polygon_collision(verts1, verts2): axes1 get_axes(verts1) axes2 get_axes(verts2) axes axes1 axes2 # 合并两个多边形的所有候选轴 for axis in axes: min1, max1 project_polygon(axis, verts1) min2, max2 project_polygon(axis, verts2) if max1 min2 or max2 min1: return False # 存在一条分离轴未碰撞 return True # 所有轴都重叠碰撞这份代码里我又用了一个平方根都省掉的版本吗没有。这里的法向量不需要归一化因为区间重叠判断只关心相对位置法向量的长度不影响是否重叠的布尔结果。但如果需要计算碰撞深度和方向就必须把法向量归一化。6.3 SAT的边界条件凹多边形怎么办SAT只适用于凸多边形。如果你有L形、U形这种凹多边形直接套SAT可能会漏报。原因在于凹多边形的分离轴不一定是边的法向量它可能有缺口导致无法用单一投影轴表示。处理方式有两种把凹多边形拆分成多个凸多边形三角剖分或矩形分解分别做碰撞检测。用像素遮罩替代。第一种方案的精度高、性能也可控但需要额外的几何分解工具第二种方案实现简单但性能开销大。我项目里的做法是地图碰撞体都构建成凸多边形组合角色、道具保持圆形或矩形尽量不引入凹多边形碰撞。6.4 SAT的工程实践理论上说SAT适合任意凸多边形碰撞但我实际使用中很少把所有游戏物体都做成凸多边形。一个例外是六边形网格游戏比如战棋、模拟经营里的六边形地块。六边形地块之间的碰撞判断如果用AABB两个倾斜的边会有明显的多余判定区域如果用圆形又没法贴合六边形的形状。这时SAT就非常合适六边形只有6条边投影轴最多12条两个六边形各6条性能开销完全可以接受。def generate_hexagon(center_x, center_y, size): # 生成正六边形顶点坐标 vertices [] for i in range(6): angle_deg 60 * i - 30 # 平顶六边形偏移30度 angle_rad math.radians(angle_deg) x center_x size * math.cos(angle_rad) y center_y size * math.sin(angle_rad) vertices.append((x, y)) return vertices配合上面的SAT检测函数就能实现六边形单位之间的精确碰撞判定。这也是我推荐的SAT使用场景形状确定、数量可控、需要精确边界。7. 当碰撞检测遇上大量物体空间分区与性能优化你写的游戏如果只是几个物体互撞那前面所有内容已经够用了。但一旦进入子弹横飞、满地掉落物、大量敌人的场景性能问题会扑面而来。我印象最深的一次是把一个俯视角射击游戏的子弹数量从100提升到500帧率直接掉了一半定位后发现全部耗在了两两碰撞检测上。7.1 暴力两两检测的时间复杂度假设有N个物体两两检测的次数是N * (N - 1) / 2。当N100时是4950次N500时是124750次翻了25倍。每一帧要做12万多次碰撞检测Python这样解释型语言根本扛不住。这时候需要的不是优化单次碰撞检测的算法而是减少需要检测的物体对数量。7.2 空间网格Spatial Hashing最经典的2D空间分区空间网格的思想非常朴素把游戏世界划分成大小相等的格子每个格子记录它包含的物体列表。物体移动时更新自己所在的格子列表。做碰撞检测时只需要检查同一格子内的物体以及相邻格子内的物体不需要和全屏所有物体做两两检测。class SpatialGrid: def __init__(self, cell_size): self.cell_size cell_size self.grid {} def _cell_coords(self, x, y): return (int(x // self.cell_size), int(y // self.cell_size)) def add(self, entity): coords self._cell_coords(entity.x, entity.y) self.grid.setdefault(coords, []).append(entity) def clear(self): self.grid.clear() def get_nearby(self, entity): # 获取物体所在格及周围8个格子里的所有物体 cx, cy self._cell_coords(entity.x, entity.y) nearby [] for dx in (-1, 0, 1): for dy in (-1, 0, 1): cell self.grid.get((cx dx, cy dy)) if cell: nearby.extend(cell) return nearby每个格子的大小怎么定一般是取场景中物体平均尺寸的1到2倍。格子太小物体跨格频繁更新开销大格子太大每个格子里塞的物体太多加速效果减弱。我项目中有一个俯视角射击关卡地图全尺寸是2000×2000子弹和敌人数量合计约400个用80像素的格子划分后每帧碰撞检测次数降到不到原来的十分之一帧率恢复稳定。7.3 四叉树Quadtree更精细的动态分区如果物体尺寸差异特别大有全屏Boss也有微小的子弹均匀网格就不太合适了。大物体会霸占很多格子导致相邻格子重复计算严重。这时候可以考虑四叉树Quadtree。四叉树把空间递归分成四等份每个节点最多存储一定数量的物体超过阈值就继续分裂。查询时从根节点往下走只检查与查询区域相交的子树。四叉树实现比网格复杂很多调试也费劲。我的建议是除非物体尺寸差异确实很大否则先上空间网格。网格简单、可预测性强、出bug好排查。四叉树属于有必要再上的优化方案普通2D游戏90%的场景用网格就够了。7.4 避免重复检测只检测一次每一对就算用了空间分区同一个格子里仍然可能存在A和B互相检测两次的情况——A检测BB又检测A。对于布尔碰撞检测来说这是纯浪费。一个经典做法是给物体加一个自增ID只让ID较小的物体负责对ID较大的物体做检测def check_pair(entity_a, entity_b): if entity_a.id entity_b.id: return False # 由ID小的负责检测避免重复 # 执行具体碰撞判断 return do_collision(entity_a, entity_b)7.5 优化不要过早进行最后说一句经验之谈性能优化一定要用数据说话不要凭感觉优化一切。我用cProfile分析后发现很多时候卡顿的根源不在碰撞检测本身而在于每帧刷新了太多不需要刷新的像素级surface或者每帧都创建了新对象导致垃圾回收频繁。做性能优化的正确顺序是先用cProfile找到热点函数确认碰撞检测确实是瓶颈再上空间分区、避免重复检测等手段每做一步都重新测量帧率变化不要一上来就写几百行四叉树代码最后发现碰撞检测只占CPU的10%白白浪费时间。8. 碰撞发生之后响应与反弹检测到碰撞只是第一步游戏手感好不好全看碰撞之后怎么响应。如果你只是打印一行日志告诉玩家你撞到墙了那这个游戏肯定没法玩。碰撞响应要解决的核心问题是碰撞之后物体应该停在哪儿、速度怎么变、是否反弹或销毁。8.1 最小平移向量MTV碰撞后要把物体推出去需要知道两个物体重叠部分的最小平移方向这个向量叫最小平移向量Minimum Translation VectorMTV。方向是分离的方向长度是最小的穿透深度。计算MTV需要知道两个碰撞体的详细几何信息。AABB计算MTV相对简单——比较X轴和Y轴的重叠量哪个轴重叠更少就沿哪个轴方向推开def get_mtv_aabb(rect1, rect2): overlap_x min(rect1.right - rect2.left, rect2.right - rect1.left) overlap_y min(rect1.bottom - rect2.top, rect2.bottom - rect1.top) if overlap_x overlap_y: # 沿X轴推开 direction 1 if rect1.centerx rect2.centerx else -1 return (direction * overlap_x, 0) else: # 沿Y轴推开 direction 1 if rect1.centery rect2.centery else -1 return (0, direction * overlap_y)不过我实际用下来在平台跳跃游戏里用MTV直接推容易让角色卡在墙边尤其是同时撞到两面墙的时候。更常用的做法是分轴处理先沿X轴移动并检测碰撞解决X方向碰撞后再沿Y轴移动并检测。def move_and_collide(entity, dx, dy, obstacles): # X轴移动 entity.x dx entity.rect.x entity.x for obs in obstacles: if entity.rect.colliderect(obs.rect): if dx 0: entity.x obs.rect.left - entity.width elif dx 0: entity.x obs.rect.right entity.rect.x entity.x # Y轴移动 entity.y dy entity.rect.y entity.y for obs in obstacles: if entity.rect.colliderect(obs.rect): if dy 0: entity.y obs.rect.top - entity.height elif dy 0: entity.y obs.rect.bottom entity.rect.y entity.y这个分轴方案虽然比MTV笨但在2D平台游戏里非常稳不会出现斜向移动时被卡在墙角的情况。原因在于它把二维碰撞问题拆成了一维问题每次只处理一个方向逻辑清晰且基本没有歧义。8.2 反弹与能量衰减如果做的是打砖块、弹球这类游戏碰撞后还需要反弹。边界反弹很简单if ball.left 0 or ball.right screen_width: ball.vx -ball.vx if ball.top 0: ball.vy -ball.vy if ball.bottom screen_height: # 球掉了处理生命或游戏结束但如果球和挡板、砖块之间是任意角度碰撞就需要按碰撞法线方向做反射def reflect(velocity, normal): # velocity 是当前速度向量 (vx, vy) # normal 是碰撞法向量单位向量 dot velocity[0] * normal[0] velocity[1] * normal[1] return (velocity[0] - 2 * dot * normal[0], velocity[1] - 2 * dot * normal[1])这个反射公式是反射定理的直接应用把速度向量沿法线方向翻转一次就能得到反弹后的速度。记得加上能量衰减乘以0.8之类否则球越弹越快游戏会变得不可控。8.3 避免抖动碰撞后的位置修正碰撞响应里最烦人的问题是物体抖动或穿模。物体被推出碰撞体后如果下一帧又因为重力或移动量再次陷入就会产生高频的抖动。解决思路是在碰撞修正后给物体的速度加上一个沿碰撞方向的分量清零处理。比如角色在平台上落地时把y方向速度归零否则下一帧重力又把角色拉回平台内部。if entity.rect.bottom ground.rect.top and entity.vy 0: entity.y ground.rect.top - entity.height entity.vy 0 # 落地后竖直速度清零 entity.on_ground True这个细节看起来简单却是平台跳跃游戏手感好与坏的巨大分水岭。很多新手写完碰撞检测后没做速度归零角色会在接触地面的一瞬间反复弹跳动作极不自然。9. 七条我踩过的坑和调试技巧这一节我把自己这几年做Python游戏碰撞检测踩过最深的坑和对应的解决技巧集中整理一下全部是能直接帮你少加班的东西。9.1 Rect对象是整型坐标注意精度损失pygame的pygame.Rect有一个隐藏特性它的坐标和大小都是整数。当你把entity.x赋值为100.7时entity.rect.x会变成100小数部分被截断。在做高精度物理模拟时这个误差会积累导致物体位置长期运行后漂移。解决方法是核心逻辑用浮点数存坐标只在需要绘制和碰撞检测时才同步到Rect。我实际做项目时的做法是Entity类维护自己的x, y浮点坐标rect属性每次都从浮点坐标生成整数Rect这样既保留了物理精度又兼容了pygame的整型Rect。9.2 collidelist的第一个碰撞对象陷阱前面提过collidelist只返回第一个碰撞对象但在物体密集场景下第一个很可能是你根本不想撞到的那个。比如子弹应该撞到最近的墙但因为墙A在列表里排前面子弹先和毛茸茸的队友碰撞了。稳妥做法是遍历所有候选碰撞体计算重叠面积或穿透深度选择最小的那个作为碰撞对象。def get_closest_collision(rect, obstacles): best_index -1 best_overlap float(inf) for i, obs in enumerate(obstacles): if rect.colliderect(obs.rect): overlap_area compute_overlap_area(rect, obs.rect) if overlap_area best_overlap: best_overlap overlap_area best_index i return best_index9.3 碰撞回调里不要修改正在遍历的列表这是Python开发里特别经典的一个坑你在遍历bullet_list做碰撞检测发现子弹碰到敌人后直接bullet_list.remove(bullet)然后Python的for循环可能会跳过下一个元素或者直接抛RuntimeError: dictionary changed size during iteration。我的经验做法是碰撞处理不立即修改列表先记录需要销毁的物体遍历结束后统一处理。to_remove [] for bullet in bullet_list: if bullet_collides_with_enemy(bullet): to_remove.append(bullet) # 给敌人减血、生成特效等 for bullet in to_remove: bullet_list.remove(bullet)9.4 使用分层碰撞掩码避免不相关物体做检测如果游戏有玩家子弹只攻击敌人、敌人子弹只攻击玩家、道具只能被玩家拾取这些规则你的碰撞检测循环里会做大量无效判断。一个轻量级方案是给物体加一个collision_layer属性检测前先判断两层是否匹配。class Layer: PLAYER 1 ENEMY 2 PLAYER_BULLET 4 ENEMY_BULLET 8 ITEM 16 # 使用位掩码表示响应的碰撞层 entity.collision_mask Layer.PLAYER | Layer.ITEM def can_collide(a, b): return bool(a.collision_layer b.collision_mask)这种分层方案在处理复杂交互时优势明显也方便后续扩展比如增加陷阱只伤害玩家和敌人的新规则只需添加一个层位。9.5 帧率独立下的碰撞表现使用delta time如果游戏循环的帧率不稳定有的电脑跑144帧有的只有30帧碰撞检测在高帧率下会过于灵敏低帧率下又过于迟钝。这涉及一个根本问题物理模拟的步长和渲染帧率的耦合。标准解法是引入delta time上一帧到这一帧的实际时间把速度的单位从像素/帧改成像素/秒。高速物体的位移就变成了speed * dt再配合前面讲到的子步进方案可以保证不同帧率下碰撞行为基本一致。dt clock.tick(60) / 1000.0 # 单位秒 bullet.x bullet.speed_x * dt bullet.y bullet.speed_y * dt9.6 可视化调试器才是碰撞检测的好朋友碰撞检测是个看不见摸不着的逻辑过程纯靠print输出调试效率极低。我这几年养成的习惯是在游戏窗口里直接画出所有碰撞体# 调试模式画出所有碰撞矩形 for entity in all_entities: pygame.draw.rect(screen, (0, 255, 0), entity.rect, 1) # 画出碰撞点标记为红色 for collision_point in collision_points: pygame.draw.circle(screen, (255, 0, 0), collision_point, 3)把碰撞体可视化后很多问题一目了然碰撞体比贴图大一圈导致空气判定、碰撞体位置偏移导致模型和判定错位、多个碰撞体重叠导致多层碰撞等等。建议在项目的开发期始终保留这个可视化开关调试起来非常方便。9.7 负数坐标与屏幕外边界如果你的游戏世界比屏幕大有滚动的摄像机物体可能出现在负坐标或超出屏幕边界的位置。pygame的Rect处理负数坐标完全没问题但空间网格和碰撞检测代码里用整数除法//处理负数坐标时要小心方向。# 当 x -10, cell_size 80 时 # int(-10 // 80) -1在Python里是向下取整 # 如果在C语言里x / 80 0向零取整结果完全不同 # 所以用Python时负数坐标的格子索引是负数这是正常的 # 但如果你把索引传给数组记得做偏移或归一化空间网格的字典key存的是元组(cx, cy)不要直接把cx当数组下标用用字典就不会有负数索引问题。10. 一个完整的小例子玩家避开圆形陷阱并拾取道具为了把这些内容串起来我写了下面这个自认为是最小可用的示例。场景玩家矩形需要移动避开圆形陷阱圆形碰到圆形道具圆形时拾取。用到了AABB碰撞、圆形碰撞、圆与矩形混合碰撞、空间网格简单版、delta time移动。import pygame import math import random pygame.init() screen pygame.display.set_mode((800, 600)) clock pygame.time.Clock() class Player: def __init__(self, x, y): self.x float(x) self.y float(y) self.width 40 self.height 40 self.speed 200 # 像素/秒 property def rect(self): return pygame.Rect(int(self.x), int(self.y), self.width, self.height) class Trap: def __init__(self, x, y, radius): self.x float(x) self.y float(y) self.radius radius def collide_with_rect(self, rect): return check_circle_rect(self.x, self.y, self.radius, rect.x, rect.y, rect.width, rect.height) class Item: def __init__(self, x, y, radius): self.x float(x) self.y float(y) self.radius radius self.collected False def collide_with_rect(self, rect): # 找到矩形离圆心最近的点 closest_x max(rect.x, min(self.x, rect.x rect.width)) closest_y max(rect.y, min(self.y, rect.y rect.height)) dx self.x - closest_x dy self.y - closest_y return dx * dx dy * dy self.radius * self.radius def check_circle_rect(cx, cy, r, rx, ry, rw, rh): closest_x max(rx, min(cx, rx rw)) closest_y max(ry, min(cy, ry rh)) dx cx - closest_x dy cy - closest_y return dx * dx dy * dy r * r # 生成道具和陷阱 items [] for _ in range(5): items.append(Item(random.randint(100, 700), random.randint(100, 500), 20)) traps [] for _ in range(4): traps.append(Trap(random.randint(100, 700), random.randint(100, 500), 35)) player Player(50, 300) running True font pygame.font.SysFont(Arial, 24) collected_count 0 while running: dt clock.tick(60) / 1000.0 for event in pygame.event.get(): if event.type pygame.QUIT: running False keys pygame.key.get_pressed() dx, dy 0, 0 if keys[pygame.K_LEFT]: dx -player.speed * dt if keys[pygame.K_RIGHT]: dx player.speed * dt if keys[pygame.K_UP]: dy -player.speed * dt if keys[pygame.K_DOWN]: dy player.speed * dt # 分轴移动并限制在窗口内 player.x dx player.x max(0, min(player.x, 800 - player.width)) player.y dy player.y max(0, min(player.y, 600 - player.height)) # 陷阱碰撞检测碰到则重置位置 player_rect player.rect for trap in traps: if trap.collide_with_rect(player_rect): player.x, player.y 50, 300 break # 道具碰撞检测拾取 for item in items: if not item.collected and item.collide_with_rect(player_rect): item.collected True collected_count 1 # 绘制 screen.fill((30, 30, 30)) for trap in traps: pygame.draw.circle(screen, (220, 50, 50), (int(trap.x), int(trap.y)), trap.radius) for item in items: if not item.collected: pygame.draw.circle(screen, (50, 220, 100), (int(item.x), int(item.y)), item.radius) pygame.draw.rect(screen, (70, 130, 240), player.rect) # 显示得分 text font.render(fCollected: {collected_count}/5, True, (255, 255, 255)) screen.blit(text, (10, 10)) if collected_count 5: end_text font.render(You Win! Press R to restart, True, (255, 255, 255)) screen.blit(end_text, (250, 250)) pygame.display.flip() pygame.quit()这段代码的运行逻辑不复杂玩家用方向键移动碰红色圆陷阱就回到起点碰绿色圆道具就拾取。注意道具和陷阱的碰撞检测用的是同一种check_circle_rect函数只是应用场景不同。实际项目里你可以给不同的碰撞事件挂不同的回调这样代码组织会更清晰。在添加新的碰撞组合时我的建议是先把所有碰撞体的形状类型抽成枚举然后在统一的地方分发到对应的检测函数。这样后续要加三角形陷阱胶囊形状的角色只需要新增一个分支不需要改动上层逻辑。11. 版本、引擎与库的选择建议聊了这么多实操最后简单说说Python做游戏碰撞检测可以借助的底层库和引擎。很多人纠结于我用pygame好还是用arcade还是要上Godot?11.1 pygame自己动手的经典选择pygame是我用得最多的库它的Rect、Sprite、mask等模块提供了碰撞检测的基础工具但不会替你处理复杂物理。适合想理解游戏底层逻辑、对碰撞检测有定制需求的开发者。缺点是你需要自己实现空间分区、碰撞响应等高级功能。11.2 arcade内置更高级的物理和碰撞处理arcade是一个比pygame更现代化的2D游戏库内置了精灵列表SpriteList的碰撞检测支持空间哈希加速也提供了简单的物理引擎重力、摩擦力、平台支持。如果你不想从头写碰撞响应arcade能帮你省掉不少时间。但它的社区和教程数量比pygame少一些遇到冷门问题排查起来会费劲。11.3 pygame pymunk需要真实物理效果时的组合如果你的游戏需要更真实的物理模拟——有质量、速度、弹性系数、摩擦力——自己手写碰撞响应的成本会急剧上升。这时可以用pymunk一个2D物理引擎底层是Chipmunk2D配合pygame绘制。把pymunk当作物理计算核心pygame当作渲染层。这也是我做物理类原型时常用的组合。11.4 自定义碰撞检测 vs 游戏引擎很多刚接触游戏开发的朋友会问我用Pygame还是Unity/Godot我的建议是如果你学习Python的目标是理解编程逻辑和算法用Pygame自己实现碰撞检测是宝贵的训练。它逼着你把数学、数据结构和算法串起来一本书读三遍都不如亲手实现一次AABB和SAT来得深刻但如果你只想快速做出一个游戏Demo不想在底层细节上花时间直接用Godot或Unity的现成物理系统效率高得多。不要有我用Pygame写碰撞检测所以我很硬核的虚荣心选择工具的标准始终是项目目标和时间成本。我自己做商业项目时如果时间紧会直接用Unity做教学演示或算法验证才会用Python手写。12. 写在最后的个人体会碰撞检测这个模块技术上不算难但做好它涉及的面非常广——数学、数据结构、性能优化、用户手感、代码架构每一项都能单独写一篇文章。我在做项目时发现真正让游戏好玩的很多时候不是那些炫酷特效而是碰撞手感打磨得是否细腻。角色撞墙会不会卡住、子弹飞行稳不稳定、敌人攻击判定是否公平这些微小的体验最终决定了玩家对这个游戏的评价。在我自己写的所有碰撞检测方案里最简单可靠的反而是AABB加分轴移动复杂方案只在特定场景才值得引入。遇到碰撞问题我会提醒自己先做最小复现、画可视化调试框、确认几何表示方式再考虑要不要上更复杂的算法。大多数时候问题并不是算法不够高级而是坐标算错了一个像素或者忘记清零了速度。希望这篇文章里那些踩坑记录和调试思路能给你的Python游戏开发省下几个加班的晚上。动手写起来把例子跑起来再改成你自己的游戏规则——碰撞检测这东西只有亲手调过才知道里面的门道。