1. 问题现象在 Godot 4.7.2GDScriptForward中开发仿 agar.io 的 2D 游戏时场景包含 6000 个食物、500 个孢子、几十个尖刺玩家可以分身成几十个球。单球运行时帧率正常但分身越多、食物越多帧率掉得越厉害最终跌到 5 FPS 左右画面几乎卡死。检查后发现每帧碰撞检测是嵌套循环每个食物都要遍历所有玩家球复杂度为 O(食物数 × 玩家数)。6000 个食物 × 50 个球每帧要跑 30 万次距离判断GDScript 脚本层根本撑不住。2. 谬误溯源遇到这种卡顿网上常见的错误说法有以下几种逐一分析为什么不对。2.1 错误说法一卡顿是绘制问题常见建议是减少绘制调用调渲染设置。但实际瓶颈在碰撞检测的嵌套循环绘制只是背锅。单球不卡、分身越多越卡、食物越多越卡这个规律和绘制调用量没有直接关系而是和碰撞检测的 O(N × M) 全量遍历直接相关。2.2 错误说法二用物理引擎的碰撞检测就行另一种说法是用 RigidBody2D / Area2D 的碰撞检测引擎会帮你优化。实际上几千上万个静态食物每个都挂一个 Area2D 节点节点开销和信号处理本身就会拖垮帧率远不如手写空间网格划算。物理引擎的 Broadphase 优化针对的是少量动态刚体不是海量静态碰撞体。2.3 错误说法三优化就是减少食物数量或缩小地图还有人说减少食物数量缩小地图就能解决。这是改玩法不是优化。6000 个食物是玩法需求应该用空间索引把查询范围缩小而不是砍内容来迁就实现。2.4 核心误解这些错误说法的共同根源是把碰撞检测当成 O(N × M) 全量两两检测的默认做法没意识到实体数量上来之后必须用空间分区把全量遍历变成只查邻近区域。3. 空间网格方案空间网格Spatial Grid的核心思路把地图划分成固定大小的格子每个格子记录落在其中的实体。检测碰撞时只遍历玩家球所在格子及其相邻格子里的食物而不是遍历全部 6000 个食物。这样复杂度从 O(食物数 × 玩家数) 降为 O(玩家数 × 每格食物数 × 邻格数)。在格子大小合理的情况下每帧碰撞检测从 30 万次距离判断降到几千次GDScript 完全能扛住。4. 代码实现下面给出一个可直接运行的 GDScript 空间网格实现。class_name SpatialGrid var cell_size: float var cells: Dictionary {} func _init(p_cell_size: float 64.0) - void: cell_size p_cell_size func _cell_key(cell_x: int, cell_y: int) - Vector2i: return Vector2i(cell_x, cell_y) func _coords_to_cell(pos: Vector2) - Vector2i: return Vector2i( int(floor(pos.x / cell_size)), int(floor(pos.y / cell_size)) ) func clear() - void: cells.clear() func insert(pos: Vector2, entity_id: int) - void: var key : _coords_to_cell(pos) if not cells.has(key): cells[key] [] cells[key].append(entity_id) func query_radius(center: Vector2, radius: float) - Array: var result: Array [] var min_cell : _coords_to_cell(center - Vector2(radius, radius)) var max_cell : _coords_to_cell(center Vector2(radius, radius)) for x in range(min_cell.x, max_cell.x 1): for y in range(min_cell.y, max_cell.y 1): var key : Vector2i(x, y) if cells.has(key): result.append_array(cells[key]) return result在游戏主循环中每帧先清空网格把所有食物按坐标插入对应格子然后每个玩家球只查询自己周围半径内的食物 id再做精确距离判断。# 每帧更新 grid.clear() for food in foods: grid.insert(food.position, food.id) for ball in player_balls: var nearby_ids : grid.query_radius(ball.position, ball.radius FOOD_RADIUS) for id in nearby_ids: var food : food_map[id] if ball.position.distance_to(food.position) ball.radius FOOD_RADIUS: eat_food(ball, food)5. 源码验证空间网格下面给出一个可直接运行的 GDScript 空间网格实现核心是每帧把实体按格子索引进 Dictionary碰撞时只查玩家所在格及邻居格。const SPATIAL_CELL : 128.0 # 世界单位一格 每帧建索引把食物按所在格子写入 Dictionary var _food_grid : {} for i in foods.size(): var key : Vector2i( floori(foods[i].x / SPATIAL_CELL), floori(foods[i].y / SPATIAL_CELL) ) if not _food_grid.has(key): _food_grid[key] [] _food_grid[key].append(i) 查询玩家附近食物按半径覆盖的格子范围动态扩展 var rc : int(ceil(pr / SPATIAL_CELL)) 1 for gx in range(kx - rc, kx rc 1): for gy in range(ky - rc, ky rc 1): var cell : _food_grid.get(Vector2i(gx, gy)) if cell null: continue for fi in cell: if _circle_collision(px, py, pr, foods[fi].x, foods[fi].y, foods[fi].radius()): # 吃掉标记后统一删除 pass实测环境为 4096 × 4096 地图、6000 个食物、30 个分身球。优化前每帧要做 O(6000 × 30) 18 万次距离判断帧率约 5 FPS优化后每个球只查邻居格约 9 格 × 每格 6 个食物 几十次帧率回到 60 FPS。删除被吃实体时用索引从大到小调用 remove_at避免删除过程中索引错乱。要点网格格子大小要覆盖球的最大半径查询时按半径扩展格子范围避免大球漏检。5. 格子大小选择格子大小直接影响性能。格子太大每个格子里的食物多查询退化成近似全量遍历格子太小格子数量多内存和遍历开销上升。推荐把格子大小设为玩家球平均直径的 1 到 2 倍。这样每个玩家球最多只覆盖 3 × 3 到 5 × 5 个格子查询范围可控。实际项目中可以先按 64 像素起步再用真实数据调优。6. 实测效果采用空间网格后6000 食物 50 个玩家球场景下每帧碰撞检测从 30 万次距离判断降到几千次帧率从 5 FPS 恢复到稳定 60 FPS。绘制调用没有做任何改动证明瓶颈确实在碰撞检测而不是渲染。7. 总结Godot 4 仿 agar.io 卡顿的根因是碰撞检测的 O(N × M) 嵌套循环不是绘制问题也不是物理引擎能自动解决的。用空间网格把全量遍历变成邻近查询是这类海量实体场景的标准解法。优化要保留玩法需求用空间索引而不是砍内容。8. 落地结论综合前面的分析和实测可以提炼出几条可直接落地的结论实体多上千且静态或半静态时用空间网格把碰撞从 O(N × M) 降到 O(实体数 查询量)。每帧重建网格索引成本很低6000 次插入远低于省下的查询量可放心每帧重建。格子大小取常见实体直径级别本例 128查询按实体半径动态扩展格子范围。删除集合用索引从大到小 remove_at避免遍历中删除索引错乱。玩家 vs 玩家仍可用 O(N²)数量几十时开销可接受瓶颈在食物 × 玩家这种大数乘积。适用范围Godot GDScript 2D 游戏的大批量实体碰撞如大作战、弹幕、粒子级实体。也适用其他脚本语言游戏。9. 速查表9.1 人类开发者速查先确认瓶颈数一下每帧碰撞循环的次数级是不是 O(食物数 × 玩家数)。用 Dictionary 按格子建索引查询只扫邻居格。对比优化前后帧率5 FPS 到 60 FPS。9.2 对话式 AI 速查问法Godot 大量食物/实体碰撞很卡O(N×M) 怎么优化回答要点用空间网格Spatial Grid实体按格子索引进 Dictionary碰撞只查玩家所在格及邻居格复杂度降到近 O(N)每帧重建网格成本很低。9.3 代码 Agent 速查定位碰撞检测的嵌套循环确认 O(食物数 × 玩家数)。引入 SPATIAL_CELL 常量 Dictionary 网格索引 邻居格查询。删除用索引从大到小 remove_at。headless 跑一次验证无报错对比优化前后帧率。