简介这是一份面向Python初学者的游戏项目源码学习包围绕《Python编程从入门到实践》中的“外星人入侵”案例进行优化与重构适合想通过小游戏理解事件循环、对象建模与交互设计的读者参考。项目重点包括用start_game函数控制按P键启动的流程、增加计分板文字显示、调整外星人屏幕布局与生成策略并在代码组织上采用模块化与面向对象方式管理飞船、子弹、外星人等对象同时涉及pygame资源加载、画面更新与性能取舍。当前包体信息显示文件总数为0、主要文件类型明细暂无数据压缩包大小约23KB目录与文件构成需以实际下载内容为准。已有310人浏览学习可作为游戏逻辑拆分、重构思路和基础性能优化的对照材料读者可据此对照启动流程、计分刷新、外星人移动边界与对象状态更新等实现思路理解小项目从可玩到易维护的改造路径。1. 一个能跑通的打外星人小游戏为什么不敢改跟着教程写出来的外星人入侵通常会在某个时刻到达一个奇怪的临界点游戏完全能跑方向键能左右移动空格能发射子弹外星人一排排往下压撞到底线就掉命功能一个不缺。但只要你起了「加一个分裂母舰」或者「三连发散射弹」的念头代码立刻开始跟你作对——速度参数散在四五个文件里碰撞检测写死在主循环深处精灵的创建、销毁和状态修改互相纠缠你调高一点子弹上限外星人下移的速度跟着变了。这不是水平问题是这类教学项目的结构本来就只为止步于「能玩」而设计。所谓优化重构要解决的就是两件事一是不改变任何可见的游戏表现把配置、状态、渲染、碰撞四块职责拆开让新增功能只需要动一个地方二是把白白烧在主循环里的 CPU 时间找回来让子弹打到三百发、外星人有八十八个的时候依然稳在 60 帧。这篇内容适合已经写完第一版、想把它变成能继续加功能的底座的人。如果还没写过第一版先去写一遍跳过这步直接看重构只会更迷糊。2. 先量后改给一局外星人入侵做一次性能体检动手改代码之前先得知道时间花在哪。没有基线数据的重构本质上是凭感觉搬家具搬完发现路更堵了也说不清是哪一步造成的。这一章的全部目的是建立一套可重复执行的测量方法让后面每一处改动都能被量化验证。2.1 帧率数字会骗人把 16.7ms 的预算拆开看60 帧意味着每帧 16.67 毫秒的总预算。这个预算要分给四件事事件处理pygame.event.get()把队列里的输入事件取出来、逻辑更新精灵位置、碰撞、状态机、绘制把所有 Surface 贴到帧缓冲上、以及display.flip()或display.update()提交。绝大多数人只盯着最后那个帧率数字但帧率在开启垂直同步的情况下会被强行量化成 60 或者 30中间过程全被吞掉了——它只告诉你「达标」或「没达标」不告诉你离崩溃还有多远。我一般的做法是先关掉垂直同步让帧率自由浮动这样任何一次性能回退都会直接在数字上体现出来。然后把主循环的四段分别计时输出每段的毫秒数。实测下来有一个很反直觉的结论很多新手版本的瓶颈根本不在更新逻辑而在每帧对全屏背景做一次未缓存的缩放或者在blit里对几百个精灵逐个做 alpha 混合。还有一种情况是convert()忘了调用导致每次贴图都要做一次像素格式转换这种开销在精灵数量少的时候看不出来一旦子弹上到两百发就原形毕露。另一个容易被忽略的指标是单帧时间的分布。平均 8ms 听起来很宽裕但如果其中夹着若干个 30ms 的尖刺玩家感受到的就是周期性的卡顿。所以测量时至少要收集 p50、p95 和最大值三个数只看平均值等于给自己喂安慰剂。2.2 用 cProfile 抓热点一次被子弹拖垮的 300 发场景确定了要测哪几段之后下一步是找出具体是哪个函数在吃时间。Python 自带的cProfile对这类 Pygame 项目完全够用前提是你能在没有窗口的情况下跑起来——因为开着窗口时flip()会阻塞采样结果会被垂直同步严重污染。import cProfile import pstats import io from game_core import build_scene, step_scene # 场景构建与单步推进 def run_headless(frames600): 无窗口连续推进 frames 帧用于性能采样 scene build_scene(bullets300, alien_rows8, alien_cols11) for _ in range(frames): step_scene(scene, dt1.0 / 60.0) # 固定步长保证结果可比 def profile(frames600): pr cProfile.Profile() pr.enable() run_headless(frames) pr.disable() buf io.StringIO() # tottime 看函数自身耗时cumulative 看含子调用的总耗时 pstats.Stats(pr, streambuf).sort_stats(tottime).print_stats(20) print(buf.getvalue()) if __name__ __main__: profile(600)这段代码的逻辑很直白先把场景构建成和实际游戏一致的规模300 发子弹、8×11 的外星人阵然后固定dt推进 600 帧让整个过程的负载稳定可复现。dt固定成1/60是关键如果按真实时钟取值每帧的移动距离都不一样采样结果的方差会大到没法比较。参数上有两个地方需要调。第一个是sort_stats的排序字段排查「谁最慢」用tottime因为它排除了子调用的干扰能把真正吃 CPU 的那个函数顶到最前面如果你关心的是「哪个入口导致了一整条慢链路」换成cumulative更合适。第二个是采样帧数600 帧对应 10 秒游戏时间对于稳定态足够了但如果你想观察外星人整排下移、命中特效爆发这类瞬时峰值帧数要往上加到 1800 甚至更多否则这些尖刺会被平均掉。还有一个实操细节cProfile本身有大概 1.5 到 3 倍的额外开销所以它给出的绝对耗时不能直接当成真实帧时间用。它的价值在于相对排名——如果表面重建占了 60% 的采样那它就是首先要消灭的对象这个结论不受 profiler 开销影响。2.3 搭一个能反复回放的基准场景有了热点排名还不够还得有办法在改完之后证明「确实变快了」。这就要求基准场景本身是确定性的同样的输入跑出来的结果必须一模一样否则你没法区分是代码改好了还是运气好。import random import time def build_benchmark(scene, seed20240501, bullets300): 构造一个固定种子的压力场景保证每次运行完全一致 rng random.Random(seed) # 独立随机源不污染全局 for _ in range(bullets): x rng.uniform(0, scene.screen_w) y rng.uniform(0, scene.screen_h * 0.5) scene.spawn_bullet(x, y) scene.freeze() # 冻结外部输入排除键盘干扰 return scene def measure(scene, frames600): 逐帧计时返回分位数而不是平均值 samples [] for _ in range(frames): t0 time.perf_counter() scene.step(dt1.0 / 60.0) samples.append((time.perf_counter() - t0) * 1000.0) samples.sort() n len(samples) return { p50: round(samples[n // 2], 3), p95: round(samples[int(n * 0.95)], 3), max: round(samples[-1], 3), }build_benchmark里用独立的random.Random(seed)而不是全局random.seed()原因是全局种子会影响到游戏里所有随机行为爆炸方向、音效选择之类一旦你后续在别处加了随机调用基准场景就变了历史数据全部作废。把随机源隔离出来等于给基准测试加了一道保险。measure返回三个分位数其中 p95 是最值得盯的那个数。p50 反映的是常态性能max 反映的是一次抖动可能来自垃圾回收或者操作系统调度而 p95 正好落在「经常发生但不算极端」的区间最能代表玩家实际手感。我通常把 p95 控制在 8ms 以内才认为这一轮重构合格留出接近一半的余量给后续功能扩张。scene.freeze()这个方法是自己加的作用是把输入源切成固定值比如「一直按住右键」避免每次跑基准时因为鼠标焦点位置不同导致飞船移动路径不一样。这类小细节不做测出来的数据自己都不敢信。提示基准脚本要和游戏主程序共用同一套step()入口不要为了测试单独抄一份逻辑。抄出来的那份一定会和主流程逐渐分叉最后测的根本不是同一个东西。3. 拆掉全局的 settings配置、状态、渲染三层怎么分性能数据拿到手之后先别急着优化热点先把结构理顺。原因是很多所谓的热点本质上是结构问题在性能上的投影——比如每帧重建精灵往往是因为配置和状态混在一起导致没法安全地复用对象。3.1 一个 settings 文件里塞六十个变量之后新手版的典型结构是这样的一个settings.py里从上到下排着六十多个模块级变量速度、窗口尺寸、颜色、初始命数、外星人分值、下移像素……主循环里到处import settings然后直接读。刚开始很好用改数值只需要动一个文件。但随着功能增加问题会一个接一个冒出来。第一是初始化顺序失控。某个变量依赖另一个变量的计算结果比如外星人横向间距要基于屏幕宽度算写成模块级常量时两者的定义先后就成了隐含契约谁在后面插一行前面的计算就变成旧值出错时不报错只是游戏里外星人阵奇怪地挤在一起。第二是状态和配置混在一起命数既在配置文件里定义了初值又在主循环里被反复赋值想加一个「重新开始」功能时你不知道该重置哪些变量只好把全部六十个都赋一遍。第三是没法测试因为模块级变量在导入时就被求值一次两个测试用例之间会互相污染。结构重构要解决的就是这个把「一局游戏内不会变」的数值配置和「每局都会变」的运行时状态彻底分开。3.2 用 dataclass 冻结配置用状态对象承载一局游戏Python 的dataclass配合frozenTrue是做这件事最省事的工具。冻结之后任何赋值都会抛异常等于把「配置在运行期被意外改写」这个坑从语言层面堵死了。from dataclasses import dataclass, field, asdict dataclass(frozenTrue) class Balance: 平衡性数值一局之内不变改数值只改这里 screen_w: int 1280 screen_h: int 720 ship_speed: float 320.0 # 像素/秒 fire_cooldown: float 0.18 # 秒最小开火间隔 bullet_speed: float 780.0 bullet_limit: int 6 # 屏幕上同时存在的子弹上限 alien_speed_base: float 42.0 alien_drop: float 24.0 # 触边后整排下移的像素 alien_speedup: float 1.18 # 每下移一次的速度倍率 dataclass class RunState: 一局游戏的运行时状态可整体存盘、回放、重置 score: int 0 lives: int 3 level: int 1 ship_x: float 0.0 # 用浮点存避免低速时取整抖动 cooldown: float 0.0 alien_dir: int 1 # 1 向右-1 向左 alien_offset_x: float 0.0 # 舰队整体横向偏移 alien_offset_y: float 0.0 speed_scale: float 1.0 def reset(self): self.score 0 self.lives 3 self.level 1 self.cooldown 0.0 self.alien_dir 1 self.alien_offset_x 0.0 self.alien_offset_y 0.0 self.speed_scale 1.0 def snapshot(self) - dict: 存盘或回放用的扁平字典 return asdict(self)Balance里所有速度都写成「像素每秒」而不是「像素每帧」这是一个关键决定。按帧写速度的话一旦你哪天想让游戏跑在 120Hz 屏幕上所有数值都得乘 2而且逻辑里到处是「每帧加 3 像素」这种硬编码。改成秒制之后update(dt)里统一乘以dt帧率变化对游戏速度完全没有影响。RunState里的alien_offset_x和alien_offset_y用的是舰队整体偏移而不是每个外星人各自的坐标。这个设计后面会看到它让「整排下移」变成了一个数字加法而不是遍历八十多个精灵逐个改坐标——这既是结构上的清晰也是性能上的优化。reset()和snapshot()两个方法是刻意加的。前者让「重新开始」变成一行调用后者让存档、回放、调试期状态对比都变成可能。写游戏的时候不一定用得上但当你需要复现一个「第 37 秒才出现的碰撞 bug」时能存能读的状态对象就是救命稻草。3.3 用 Sprite 子类和 Group 收敛更新循环结构分好之后主循环里剩下的应该是清清爽爽的几个调用而不是几十行缩进很深的if。Pygame 的Sprite和Group本身就是为此设计的可惜很多新手版本只用了它们的绘制功能更新逻辑还是自己手写循环。import pygame class Bullet(pygame.sprite.Sprite): __slots__ (pos_y, speed) # 减少属性字典开销大量实例时有意义 def __init__(self, x, y, speed): super().__init__() self.image BULLET_IMG # 预加载好的 Surface不要每帧新建 self.rect self.image.get_rect(midbottom(x, y)) self.pos_y float(y) # 浮点位置取整只发生在赋值给 rect 时 self.speed speed def update(self, dt): self.pos_y - self.speed * dt self.rect.y int(self.pos_y) # 只在渲染前取整一次 if self.rect.bottom 0: self.kill() # 从所有所属 Group 中移除自己 class Explosion(pygame.sprite.Sprite): __slots__ (timer, frames, age) def __init__(self, center, frames, fps24): super().__init__() self.frames frames self.age 0.0 self.timer 1.0 / fps self.image frames[0] self.rect self.image.get_rect(centercenter) def update(self, dt): self.age dt idx int(self.age * 24) if idx len(self.frames): self.kill() return self.image self.frames[idx] # 帧动画只换引用不复制 SurfaceBullet.update里那个「浮点位置 渲染前取整」的写法值得多说两句。如果直接用self.rect.y - speed * dt因为rect的属性是整数每帧的位移 0.7 像素会被截断成 0 或者 1表现出来就是子弹在低速时一顿一顿地抖。这个现象在 60 帧下不明显一旦帧率降下来或者速度调低就变成肉眼可见的玄学抖动。把真实位置存在浮点属性里只在赋值给rect时取整视觉上就顺滑了。__slots__在子弹这种可能同时存在几百个的类上是值得加的。Python 的普通实例每个都有一个__dict__几百个实例就是几百个字典对象内存和属性查找开销都不小。加了__slots__之后实例变成定长的创建和访问都会快一些代价是不能动态添加属性——对于结构固定的精灵类这笔交易很划算。Explosion的做法是把预渲染好的帧序列传进来update里只切换image引用。新手常见写法是在update里调pygame.transform.scale或者新建Surface来画爆炸那每一帧都在分配内存粒子一多直接把帧率打穿。所有能用同一份 Surface 的地方都不要复制。4. 碰撞与精灵组把 O(n×m) 的检测压下来子弹和三排外星人的碰撞是整个游戏里唯一一个天然的平方级开销。300 发子弹乘 88 个外星人等于 26400 次矩形相交判断这个量级在 C 实现里还行但一旦你加上「我方子弹」「敌方子弹」「道具」「护盾块」几类对象乘起来就顶不住了。4.1 spritecollide 内部到底在干什么pygame.sprite.groupcollide(group_a, group_b, dokilla, dokillb)的实现是两层嵌套循环外层遍历 a 组的每个精灵内层遍历 b 组的每个精灵逐个调rect.colliderect。它是纯 C 写的单次判断非常快所以在你只有几十个对象的时候任何「聪明」的优化都不如它。问题在于复杂度是乘法对象数量翻倍耗时翻四倍。还有一个隐藏成本groupcollide在dokillaTrue的时候会调用kill()而kill()要从每个所属的 Group 里做一次列表移除。如果同一次调用里命中了很多个移除操作本身的开销会累积起来尤其在精灵同时属于多个 Group比如「所有精灵」组加「外星人」组的时候。所以优化的思路不是「不用 groupcollide」而是「别让它一次面对全部对象」。按类别分组先缩小候选集再用 C 实现做精确判定这是性价比最高的一条路。4.2 角色分组子弹、外星人、特效各归各的组最基础的一步是把pygame.sprite.Group按角色切开同时保留一个用于统一绘制的层组。import pygame class World: def __init__(self, balance): self.balance balance self.bullets pygame.sprite.Group() self.aliens pygame.sprite.Group() self.booms pygame.sprite.Group() self.ship pygame.sprite.GroupSingle() # LayeredUpdates 保证绘制顺序稳定避免精灵闪烁 self.drawer pygame.sprite.LayeredUpdates() def add(self, sprite, layer): self.drawer.add(sprite, layerlayer) def step(self, dt, input_state): self.ship.update(dt, input_state) self.bullets.update(dt) self.aliens.update(dt) self.booms.update(dt) # 只有子弹和外星人之间需要判定特效完全不参与 hits pygame.sprite.groupcollide( self.bullets, self.aliens, True, True ) for bullet, alien_list in hits.items(): for alien in alien_list: self.spawn_explosion(alien.rect.center) self.score alien.value # 分值挂在外星人身上不散在主循环 def draw(self, surface): self.drawer.draw(surface)这里有几个决定值得说明。第一把分值挂到外星人对象上alien.value而不是在主循环里按「是哪种外星人就加多少分」写一串if。这样加新外星人类型时不需要改主循环。第二LayeredUpdates用来保证绘制顺序普通Group的遍历顺序取决于插入顺序子弹和爆炸粒子混在一起时会出现半帧闪烁层组能把这个不确定消掉。第三spawn_explosion是延迟添加而不是在碰撞循环里直接add因为「遍历 Group 的同时修改它」在 Pygame 里行为未定义轻则少画一个重则直接抛异常。4.3 按列分桶只在同一列附近做精确判定做到分组之后如果外星人数量还会继续涨比如加了增援波次可以再加一层空间分桶。核心观察是外星人排成整齐的网格横向间距固定子弹在竖直方向飞只有落在同一列或相邻列的子弹才可能真正撞上。def build_columns(aliens, bucket_width): 按列分桶返回 {列号: [外星人...]} table {} for alien in aliens: key alien.rect.centerx // bucket_width table.setdefault(key, []).append(alien) return table def collide_by_column(bullets, table, bucket_width): 只检查同列及左右各一列返回 (bullet, alien) 对 pairs [] for bullet in bullets: key bullet.rect.centerx // bucket_width for k in (key - 1, key, key 1): # 相邻列兜住跨列边界的精灵 for alien in table.get(k, ()): if bullet.rect.colliderect(alien.rect): pairs.append((bullet, alien)) break return pairsbucket_width的取值有一个硬约束必须大于单个精灵的宽度否则一个精灵会跨越两个桶而你的相邻列兜底只查三列边缘情况可能漏判。实际操作里取外星人宽度的 1.5 到 2 倍比较稳妥桶太细查找快但兜底范围要放大桶太粗就退化成暴力比较了。还有一点必须讲清楚这个表每帧都要重建。因为外星人一直在移动上一帧的桶信息这一帧就失效了。重建成本是 O(n)n 是外星人数88对比暴力比较的 300×8826400收益仍然巨大。但如果你外星人只有 30 个、子弹只有 20 发重建字典的 Python 层开销反而会超过 C 实现的暴力比较——这就是下一章要细说的翻车点。5. 避坑与排查重构外星人入侵时最常翻的 5 次车重构这类项目的坑有一个共同特征它们不会让程序崩溃只会让游戏「看起来有点不对」于是你会在错误的方向上排查很久。下面五条是我和身边人反复踩过的按「现象 → 原因 → 解决」整理。5.1 子弹从外星人身上穿过去没打中现象很直观屏幕上子弹明明划过了外星人身体却什么也没发生直接飞过去消失了。原因通常有两个。第一个是更新顺序错了。如果主循环写成「先碰撞、后移动」那么碰撞判定用的是上一帧的位置对于高速子弹780 像素每秒单帧位移 13 像素会出现视觉上的错位。第二个是坐标取整的副作用把浮点位置直接赋给rect.x或rect.yPython 会截断小数部分连续几帧都在同一像素上判定时机的窗口被压缩了。解决方法是把主循环的顺序固定成「输入 → 移动 → 碰撞 → 判定死亡 → 绘制」任何一次改动都不要打乱这个次序最好写进注释里。同时把坐标拆成浮点属性加rect两层浮点负责累加rect只做渲染和判定用的整数量。如果子弹速度还要往上提可以额外加一次「线段中点采样」在上一帧位置和这一帧位置之间插一个判定点成本很低但能堵住绝大多数穿透。5.2 整排外星人触边下移时瞬移现象是外星人舰队碰到屏幕边缘一帧之内整体往下掉了一大截有时候直接掉到底线判负。原因是每个外星人各自判断「我是否碰到边缘」然后各自执行反向和下移。八十多个精灵在同一帧里都判断为真于是下移量被累加了八十多次而且反向后它们可能仍然处于越界状态下一帧继续触发形成连锁。解决方法是把边缘判定提升到舰队级别一帧只判定一次。用一个整体的alien_offset_x累加横向移动量越界时反转方向并对偏移做钳制把它压回合法范围的边界值再执行一次下移。这样无论舰队有多少个成员触边行为永远只发生一次下移量也永远是配置里那一个数字。5.3 优化完帧率反而掉了这条最气人花了一晚上写的空间分桶跑基准测试发现 p95 从 6.2ms 涨到了 9.8ms。原因是把 C 实现换成了 Python 实现。groupcollide内部是编译好的循环虽然复杂度是平方但常数极小。自己写的分桶每帧要重建字典、对每个子弹做三次字典查找、再走一遍 Python 的 for 循环这些解释器开销在对象数量不大时完全盖过了算法复杂度的优势。经验阈值大概在两百个对象以下手工分桶几乎没有胜算。解决方法是「先量再换」。基准测试里如果暴力方案已经能稳在 8ms 以内就别动它。真要做分桶必须用同一套基准脚本做前后对比而且要在最大负载子弹打满、外星人最多的场景下对比不能用平均情况糊弄自己。如果确实需要还可以考虑把分桶表做成每 N 帧重建一次而不是每帧重建代价是精度略降。5.4 长时间运行内存缓慢上涨现象是跑二十分钟之后进程内存从 80MB 涨到几百 MB帧率随之掉下去。原因几乎总是资源在循环里被反复创建。爆炸粒子每帧pygame.Surface(...)新建一个、子弹图像每次都pygame.image.load、或者kill()之后仍有别的列表持有引用导致对象无法回收。还有一种是精灵被kill()了但还挂在自定义的self.pending列表里越积越多。解决方法是把资源加载集中到初始化阶段一次完成做一张资源字典按名字取用。爆炸动画用预渲染帧序列粒子用对象池预先创建固定数量用完归还而不是销毁。同时检查所有自定义容器确认精灵被kill()时那些容器也会清理——kill()只负责从Group里移除管不到你自己的 list。5.5 松开方向键飞船还在飘现象是按键松开后飞船继续滑行一段距离才停下或者在某些按键组合下直接卡住不动。原因是输入处理混用了两套机制。事件队列pygame.event.get()里的KEYDOWN/KEYUP是离散的如果某一帧因为卡顿丢了几帧KEYUP事件可能被挤在队列里没及时处理而pygame.key.get_pressed()是实时查询按下和松开立刻反映。两套混用状态就会打架。解决方法是明确分工方向这类需要持续状态的全部用get_pressed()轮询每帧读一次暂停、开火、切场景这类一次性动作才走事件队列。同时get_pressed()必须在每帧开头读一次并缓存下来而不是在多个函数里反复调用后者在多处逻辑下会产生「同帧内状态不一致」的诡异问题。6. 重构收尾一份自检清单和一个能带走的骨架改到这个阶段代码应该已经能通过三个问题的检验调数值是不是只动一个文件、单帧内的执行顺序是不是处处一致、出问题时能不能靠snapshot()复现出同一帧的状态。这三条都过不了的话说明结构还没拆干净别急着加新功能。检查项不合格的表现合格标准配置集中度改一个速度要搜三个文件只改Balance里的字段帧顺序碰撞在移动之前执行顺序写死并加注释状态可复现出了问题只能靠感觉猜snapshot()能存能读资源创建循环里出现Surface()或load全部在初始化阶段完成基准数据只有「感觉变快了」p95 有前后对比数字最后留一个能直接抄走的骨架把前面几章的东西串起来def main_loop(world, balance, clock): dt 0.0 while world.running: # 1. 事件只处理一次性动作 for event in pygame.event.get(): if event.type pygame.QUIT: world.running False elif event.type pygame.KEYDOWN and event.key pygame.K_p: world.toggle_pause() # 2. 轮询持续状态每帧读一次 keys pygame.key.get_pressed() # 3. 更新dt 上限兜底防止窗口拖动后一次性大跳 dt min(clock.tick(60) / 1000.0, 0.05) if not world.paused: world.step(dt, keys) # 4. 绘制与提交 world.draw(world.surface) pygame.display.flip()clock.tick(60)的返回值是上一帧到这一帧的毫秒数直接除以 1000 就是秒。给它套一个min(..., 0.05)是血泪经验——拖动窗口或者机器休眠之后这个值可能是好几秒不做上限保护一帧之内所有精灵会瞬移出屏幕碰撞判定全部错乱表现出来就是「切回来游戏就崩了」。这类 bug 很难在正常测试里碰到但用户一定会碰到。另外要提醒的是重构过程中千万给自己留后悔药。我见过最惨的一种情况是改到一半发现新结构反而更难扩展回头想找能跑的版本发现早就覆盖了。哪怕不用版本管理工具也至少把跑通的那一版复制一份改名保留每次只在一个方向上推进改完跑一次基准数据不对就退回去。希望帮到你。本文还有配套的精品资源点击获取
简介这是一份面向Python初学者的游戏项目源码学习包围绕《Python编程从入门到实践》中的“外星人入侵”案例进行优化与重构适合想通过小游戏理解事件循环、对象建模与交互设计的读者参考。项目重点包括用start_game函数控制按P键启动的流程、增加计分板文字显示、调整外星人屏幕布局与生成策略并在代码组织上采用模块化与面向对象方式管理飞船、子弹、外星人等对象同时涉及pygame资源加载、画面更新与性能取舍。当前包体信息显示文件总数为0、主要文件类型明细暂无数据压缩包大小约23KB目录与文件构成需以实际下载内容为准。已有310人浏览学习可作为游戏逻辑拆分、重构思路和基础性能优化的对照材料读者可据此对照启动流程、计分刷新、外星人移动边界与对象状态更新等实现思路理解小项目从可玩到易维护的改造路径。1. 一个能跑通的打外星人小游戏为什么不敢改跟着教程写出来的外星人入侵通常会在某个时刻到达一个奇怪的临界点游戏完全能跑方向键能左右移动空格能发射子弹外星人一排排往下压撞到底线就掉命功能一个不缺。但只要你起了「加一个分裂母舰」或者「三连发散射弹」的念头代码立刻开始跟你作对——速度参数散在四五个文件里碰撞检测写死在主循环深处精灵的创建、销毁和状态修改互相纠缠你调高一点子弹上限外星人下移的速度跟着变了。这不是水平问题是这类教学项目的结构本来就只为止步于「能玩」而设计。所谓优化重构要解决的就是两件事一是不改变任何可见的游戏表现把配置、状态、渲染、碰撞四块职责拆开让新增功能只需要动一个地方二是把白白烧在主循环里的 CPU 时间找回来让子弹打到三百发、外星人有八十八个的时候依然稳在 60 帧。这篇内容适合已经写完第一版、想把它变成能继续加功能的底座的人。如果还没写过第一版先去写一遍跳过这步直接看重构只会更迷糊。2. 先量后改给一局外星人入侵做一次性能体检动手改代码之前先得知道时间花在哪。没有基线数据的重构本质上是凭感觉搬家具搬完发现路更堵了也说不清是哪一步造成的。这一章的全部目的是建立一套可重复执行的测量方法让后面每一处改动都能被量化验证。2.1 帧率数字会骗人把 16.7ms 的预算拆开看60 帧意味着每帧 16.67 毫秒的总预算。这个预算要分给四件事事件处理pygame.event.get()把队列里的输入事件取出来、逻辑更新精灵位置、碰撞、状态机、绘制把所有 Surface 贴到帧缓冲上、以及display.flip()或display.update()提交。绝大多数人只盯着最后那个帧率数字但帧率在开启垂直同步的情况下会被强行量化成 60 或者 30中间过程全被吞掉了——它只告诉你「达标」或「没达标」不告诉你离崩溃还有多远。我一般的做法是先关掉垂直同步让帧率自由浮动这样任何一次性能回退都会直接在数字上体现出来。然后把主循环的四段分别计时输出每段的毫秒数。实测下来有一个很反直觉的结论很多新手版本的瓶颈根本不在更新逻辑而在每帧对全屏背景做一次未缓存的缩放或者在blit里对几百个精灵逐个做 alpha 混合。还有一种情况是convert()忘了调用导致每次贴图都要做一次像素格式转换这种开销在精灵数量少的时候看不出来一旦子弹上到两百发就原形毕露。另一个容易被忽略的指标是单帧时间的分布。平均 8ms 听起来很宽裕但如果其中夹着若干个 30ms 的尖刺玩家感受到的就是周期性的卡顿。所以测量时至少要收集 p50、p95 和最大值三个数只看平均值等于给自己喂安慰剂。2.2 用 cProfile 抓热点一次被子弹拖垮的 300 发场景确定了要测哪几段之后下一步是找出具体是哪个函数在吃时间。Python 自带的cProfile对这类 Pygame 项目完全够用前提是你能在没有窗口的情况下跑起来——因为开着窗口时flip()会阻塞采样结果会被垂直同步严重污染。import cProfile import pstats import io from game_core import build_scene, step_scene # 场景构建与单步推进 def run_headless(frames600): 无窗口连续推进 frames 帧用于性能采样 scene build_scene(bullets300, alien_rows8, alien_cols11) for _ in range(frames): step_scene(scene, dt1.0 / 60.0) # 固定步长保证结果可比 def profile(frames600): pr cProfile.Profile() pr.enable() run_headless(frames) pr.disable() buf io.StringIO() # tottime 看函数自身耗时cumulative 看含子调用的总耗时 pstats.Stats(pr, streambuf).sort_stats(tottime).print_stats(20) print(buf.getvalue()) if __name__ __main__: profile(600)这段代码的逻辑很直白先把场景构建成和实际游戏一致的规模300 发子弹、8×11 的外星人阵然后固定dt推进 600 帧让整个过程的负载稳定可复现。dt固定成1/60是关键如果按真实时钟取值每帧的移动距离都不一样采样结果的方差会大到没法比较。参数上有两个地方需要调。第一个是sort_stats的排序字段排查「谁最慢」用tottime因为它排除了子调用的干扰能把真正吃 CPU 的那个函数顶到最前面如果你关心的是「哪个入口导致了一整条慢链路」换成cumulative更合适。第二个是采样帧数600 帧对应 10 秒游戏时间对于稳定态足够了但如果你想观察外星人整排下移、命中特效爆发这类瞬时峰值帧数要往上加到 1800 甚至更多否则这些尖刺会被平均掉。还有一个实操细节cProfile本身有大概 1.5 到 3 倍的额外开销所以它给出的绝对耗时不能直接当成真实帧时间用。它的价值在于相对排名——如果表面重建占了 60% 的采样那它就是首先要消灭的对象这个结论不受 profiler 开销影响。2.3 搭一个能反复回放的基准场景有了热点排名还不够还得有办法在改完之后证明「确实变快了」。这就要求基准场景本身是确定性的同样的输入跑出来的结果必须一模一样否则你没法区分是代码改好了还是运气好。import random import time def build_benchmark(scene, seed20240501, bullets300): 构造一个固定种子的压力场景保证每次运行完全一致 rng random.Random(seed) # 独立随机源不污染全局 for _ in range(bullets): x rng.uniform(0, scene.screen_w) y rng.uniform(0, scene.screen_h * 0.5) scene.spawn_bullet(x, y) scene.freeze() # 冻结外部输入排除键盘干扰 return scene def measure(scene, frames600): 逐帧计时返回分位数而不是平均值 samples [] for _ in range(frames): t0 time.perf_counter() scene.step(dt1.0 / 60.0) samples.append((time.perf_counter() - t0) * 1000.0) samples.sort() n len(samples) return { p50: round(samples[n // 2], 3), p95: round(samples[int(n * 0.95)], 3), max: round(samples[-1], 3), }build_benchmark里用独立的random.Random(seed)而不是全局random.seed()原因是全局种子会影响到游戏里所有随机行为爆炸方向、音效选择之类一旦你后续在别处加了随机调用基准场景就变了历史数据全部作废。把随机源隔离出来等于给基准测试加了一道保险。measure返回三个分位数其中 p95 是最值得盯的那个数。p50 反映的是常态性能max 反映的是一次抖动可能来自垃圾回收或者操作系统调度而 p95 正好落在「经常发生但不算极端」的区间最能代表玩家实际手感。我通常把 p95 控制在 8ms 以内才认为这一轮重构合格留出接近一半的余量给后续功能扩张。scene.freeze()这个方法是自己加的作用是把输入源切成固定值比如「一直按住右键」避免每次跑基准时因为鼠标焦点位置不同导致飞船移动路径不一样。这类小细节不做测出来的数据自己都不敢信。提示基准脚本要和游戏主程序共用同一套step()入口不要为了测试单独抄一份逻辑。抄出来的那份一定会和主流程逐渐分叉最后测的根本不是同一个东西。3. 拆掉全局的 settings配置、状态、渲染三层怎么分性能数据拿到手之后先别急着优化热点先把结构理顺。原因是很多所谓的热点本质上是结构问题在性能上的投影——比如每帧重建精灵往往是因为配置和状态混在一起导致没法安全地复用对象。3.1 一个 settings 文件里塞六十个变量之后新手版的典型结构是这样的一个settings.py里从上到下排着六十多个模块级变量速度、窗口尺寸、颜色、初始命数、外星人分值、下移像素……主循环里到处import settings然后直接读。刚开始很好用改数值只需要动一个文件。但随着功能增加问题会一个接一个冒出来。第一是初始化顺序失控。某个变量依赖另一个变量的计算结果比如外星人横向间距要基于屏幕宽度算写成模块级常量时两者的定义先后就成了隐含契约谁在后面插一行前面的计算就变成旧值出错时不报错只是游戏里外星人阵奇怪地挤在一起。第二是状态和配置混在一起命数既在配置文件里定义了初值又在主循环里被反复赋值想加一个「重新开始」功能时你不知道该重置哪些变量只好把全部六十个都赋一遍。第三是没法测试因为模块级变量在导入时就被求值一次两个测试用例之间会互相污染。结构重构要解决的就是这个把「一局游戏内不会变」的数值配置和「每局都会变」的运行时状态彻底分开。3.2 用 dataclass 冻结配置用状态对象承载一局游戏Python 的dataclass配合frozenTrue是做这件事最省事的工具。冻结之后任何赋值都会抛异常等于把「配置在运行期被意外改写」这个坑从语言层面堵死了。from dataclasses import dataclass, field, asdict dataclass(frozenTrue) class Balance: 平衡性数值一局之内不变改数值只改这里 screen_w: int 1280 screen_h: int 720 ship_speed: float 320.0 # 像素/秒 fire_cooldown: float 0.18 # 秒最小开火间隔 bullet_speed: float 780.0 bullet_limit: int 6 # 屏幕上同时存在的子弹上限 alien_speed_base: float 42.0 alien_drop: float 24.0 # 触边后整排下移的像素 alien_speedup: float 1.18 # 每下移一次的速度倍率 dataclass class RunState: 一局游戏的运行时状态可整体存盘、回放、重置 score: int 0 lives: int 3 level: int 1 ship_x: float 0.0 # 用浮点存避免低速时取整抖动 cooldown: float 0.0 alien_dir: int 1 # 1 向右-1 向左 alien_offset_x: float 0.0 # 舰队整体横向偏移 alien_offset_y: float 0.0 speed_scale: float 1.0 def reset(self): self.score 0 self.lives 3 self.level 1 self.cooldown 0.0 self.alien_dir 1 self.alien_offset_x 0.0 self.alien_offset_y 0.0 self.speed_scale 1.0 def snapshot(self) - dict: 存盘或回放用的扁平字典 return asdict(self)Balance里所有速度都写成「像素每秒」而不是「像素每帧」这是一个关键决定。按帧写速度的话一旦你哪天想让游戏跑在 120Hz 屏幕上所有数值都得乘 2而且逻辑里到处是「每帧加 3 像素」这种硬编码。改成秒制之后update(dt)里统一乘以dt帧率变化对游戏速度完全没有影响。RunState里的alien_offset_x和alien_offset_y用的是舰队整体偏移而不是每个外星人各自的坐标。这个设计后面会看到它让「整排下移」变成了一个数字加法而不是遍历八十多个精灵逐个改坐标——这既是结构上的清晰也是性能上的优化。reset()和snapshot()两个方法是刻意加的。前者让「重新开始」变成一行调用后者让存档、回放、调试期状态对比都变成可能。写游戏的时候不一定用得上但当你需要复现一个「第 37 秒才出现的碰撞 bug」时能存能读的状态对象就是救命稻草。3.3 用 Sprite 子类和 Group 收敛更新循环结构分好之后主循环里剩下的应该是清清爽爽的几个调用而不是几十行缩进很深的if。Pygame 的Sprite和Group本身就是为此设计的可惜很多新手版本只用了它们的绘制功能更新逻辑还是自己手写循环。import pygame class Bullet(pygame.sprite.Sprite): __slots__ (pos_y, speed) # 减少属性字典开销大量实例时有意义 def __init__(self, x, y, speed): super().__init__() self.image BULLET_IMG # 预加载好的 Surface不要每帧新建 self.rect self.image.get_rect(midbottom(x, y)) self.pos_y float(y) # 浮点位置取整只发生在赋值给 rect 时 self.speed speed def update(self, dt): self.pos_y - self.speed * dt self.rect.y int(self.pos_y) # 只在渲染前取整一次 if self.rect.bottom 0: self.kill() # 从所有所属 Group 中移除自己 class Explosion(pygame.sprite.Sprite): __slots__ (timer, frames, age) def __init__(self, center, frames, fps24): super().__init__() self.frames frames self.age 0.0 self.timer 1.0 / fps self.image frames[0] self.rect self.image.get_rect(centercenter) def update(self, dt): self.age dt idx int(self.age * 24) if idx len(self.frames): self.kill() return self.image self.frames[idx] # 帧动画只换引用不复制 SurfaceBullet.update里那个「浮点位置 渲染前取整」的写法值得多说两句。如果直接用self.rect.y - speed * dt因为rect的属性是整数每帧的位移 0.7 像素会被截断成 0 或者 1表现出来就是子弹在低速时一顿一顿地抖。这个现象在 60 帧下不明显一旦帧率降下来或者速度调低就变成肉眼可见的玄学抖动。把真实位置存在浮点属性里只在赋值给rect时取整视觉上就顺滑了。__slots__在子弹这种可能同时存在几百个的类上是值得加的。Python 的普通实例每个都有一个__dict__几百个实例就是几百个字典对象内存和属性查找开销都不小。加了__slots__之后实例变成定长的创建和访问都会快一些代价是不能动态添加属性——对于结构固定的精灵类这笔交易很划算。Explosion的做法是把预渲染好的帧序列传进来update里只切换image引用。新手常见写法是在update里调pygame.transform.scale或者新建Surface来画爆炸那每一帧都在分配内存粒子一多直接把帧率打穿。所有能用同一份 Surface 的地方都不要复制。4. 碰撞与精灵组把 O(n×m) 的检测压下来子弹和三排外星人的碰撞是整个游戏里唯一一个天然的平方级开销。300 发子弹乘 88 个外星人等于 26400 次矩形相交判断这个量级在 C 实现里还行但一旦你加上「我方子弹」「敌方子弹」「道具」「护盾块」几类对象乘起来就顶不住了。4.1 spritecollide 内部到底在干什么pygame.sprite.groupcollide(group_a, group_b, dokilla, dokillb)的实现是两层嵌套循环外层遍历 a 组的每个精灵内层遍历 b 组的每个精灵逐个调rect.colliderect。它是纯 C 写的单次判断非常快所以在你只有几十个对象的时候任何「聪明」的优化都不如它。问题在于复杂度是乘法对象数量翻倍耗时翻四倍。还有一个隐藏成本groupcollide在dokillaTrue的时候会调用kill()而kill()要从每个所属的 Group 里做一次列表移除。如果同一次调用里命中了很多个移除操作本身的开销会累积起来尤其在精灵同时属于多个 Group比如「所有精灵」组加「外星人」组的时候。所以优化的思路不是「不用 groupcollide」而是「别让它一次面对全部对象」。按类别分组先缩小候选集再用 C 实现做精确判定这是性价比最高的一条路。4.2 角色分组子弹、外星人、特效各归各的组最基础的一步是把pygame.sprite.Group按角色切开同时保留一个用于统一绘制的层组。import pygame class World: def __init__(self, balance): self.balance balance self.bullets pygame.sprite.Group() self.aliens pygame.sprite.Group() self.booms pygame.sprite.Group() self.ship pygame.sprite.GroupSingle() # LayeredUpdates 保证绘制顺序稳定避免精灵闪烁 self.drawer pygame.sprite.LayeredUpdates() def add(self, sprite, layer): self.drawer.add(sprite, layerlayer) def step(self, dt, input_state): self.ship.update(dt, input_state) self.bullets.update(dt) self.aliens.update(dt) self.booms.update(dt) # 只有子弹和外星人之间需要判定特效完全不参与 hits pygame.sprite.groupcollide( self.bullets, self.aliens, True, True ) for bullet, alien_list in hits.items(): for alien in alien_list: self.spawn_explosion(alien.rect.center) self.score alien.value # 分值挂在外星人身上不散在主循环 def draw(self, surface): self.drawer.draw(surface)这里有几个决定值得说明。第一把分值挂到外星人对象上alien.value而不是在主循环里按「是哪种外星人就加多少分」写一串if。这样加新外星人类型时不需要改主循环。第二LayeredUpdates用来保证绘制顺序普通Group的遍历顺序取决于插入顺序子弹和爆炸粒子混在一起时会出现半帧闪烁层组能把这个不确定消掉。第三spawn_explosion是延迟添加而不是在碰撞循环里直接add因为「遍历 Group 的同时修改它」在 Pygame 里行为未定义轻则少画一个重则直接抛异常。4.3 按列分桶只在同一列附近做精确判定做到分组之后如果外星人数量还会继续涨比如加了增援波次可以再加一层空间分桶。核心观察是外星人排成整齐的网格横向间距固定子弹在竖直方向飞只有落在同一列或相邻列的子弹才可能真正撞上。def build_columns(aliens, bucket_width): 按列分桶返回 {列号: [外星人...]} table {} for alien in aliens: key alien.rect.centerx // bucket_width table.setdefault(key, []).append(alien) return table def collide_by_column(bullets, table, bucket_width): 只检查同列及左右各一列返回 (bullet, alien) 对 pairs [] for bullet in bullets: key bullet.rect.centerx // bucket_width for k in (key - 1, key, key 1): # 相邻列兜住跨列边界的精灵 for alien in table.get(k, ()): if bullet.rect.colliderect(alien.rect): pairs.append((bullet, alien)) break return pairsbucket_width的取值有一个硬约束必须大于单个精灵的宽度否则一个精灵会跨越两个桶而你的相邻列兜底只查三列边缘情况可能漏判。实际操作里取外星人宽度的 1.5 到 2 倍比较稳妥桶太细查找快但兜底范围要放大桶太粗就退化成暴力比较了。还有一点必须讲清楚这个表每帧都要重建。因为外星人一直在移动上一帧的桶信息这一帧就失效了。重建成本是 O(n)n 是外星人数88对比暴力比较的 300×8826400收益仍然巨大。但如果你外星人只有 30 个、子弹只有 20 发重建字典的 Python 层开销反而会超过 C 实现的暴力比较——这就是下一章要细说的翻车点。5. 避坑与排查重构外星人入侵时最常翻的 5 次车重构这类项目的坑有一个共同特征它们不会让程序崩溃只会让游戏「看起来有点不对」于是你会在错误的方向上排查很久。下面五条是我和身边人反复踩过的按「现象 → 原因 → 解决」整理。5.1 子弹从外星人身上穿过去没打中现象很直观屏幕上子弹明明划过了外星人身体却什么也没发生直接飞过去消失了。原因通常有两个。第一个是更新顺序错了。如果主循环写成「先碰撞、后移动」那么碰撞判定用的是上一帧的位置对于高速子弹780 像素每秒单帧位移 13 像素会出现视觉上的错位。第二个是坐标取整的副作用把浮点位置直接赋给rect.x或rect.yPython 会截断小数部分连续几帧都在同一像素上判定时机的窗口被压缩了。解决方法是把主循环的顺序固定成「输入 → 移动 → 碰撞 → 判定死亡 → 绘制」任何一次改动都不要打乱这个次序最好写进注释里。同时把坐标拆成浮点属性加rect两层浮点负责累加rect只做渲染和判定用的整数量。如果子弹速度还要往上提可以额外加一次「线段中点采样」在上一帧位置和这一帧位置之间插一个判定点成本很低但能堵住绝大多数穿透。5.2 整排外星人触边下移时瞬移现象是外星人舰队碰到屏幕边缘一帧之内整体往下掉了一大截有时候直接掉到底线判负。原因是每个外星人各自判断「我是否碰到边缘」然后各自执行反向和下移。八十多个精灵在同一帧里都判断为真于是下移量被累加了八十多次而且反向后它们可能仍然处于越界状态下一帧继续触发形成连锁。解决方法是把边缘判定提升到舰队级别一帧只判定一次。用一个整体的alien_offset_x累加横向移动量越界时反转方向并对偏移做钳制把它压回合法范围的边界值再执行一次下移。这样无论舰队有多少个成员触边行为永远只发生一次下移量也永远是配置里那一个数字。5.3 优化完帧率反而掉了这条最气人花了一晚上写的空间分桶跑基准测试发现 p95 从 6.2ms 涨到了 9.8ms。原因是把 C 实现换成了 Python 实现。groupcollide内部是编译好的循环虽然复杂度是平方但常数极小。自己写的分桶每帧要重建字典、对每个子弹做三次字典查找、再走一遍 Python 的 for 循环这些解释器开销在对象数量不大时完全盖过了算法复杂度的优势。经验阈值大概在两百个对象以下手工分桶几乎没有胜算。解决方法是「先量再换」。基准测试里如果暴力方案已经能稳在 8ms 以内就别动它。真要做分桶必须用同一套基准脚本做前后对比而且要在最大负载子弹打满、外星人最多的场景下对比不能用平均情况糊弄自己。如果确实需要还可以考虑把分桶表做成每 N 帧重建一次而不是每帧重建代价是精度略降。5.4 长时间运行内存缓慢上涨现象是跑二十分钟之后进程内存从 80MB 涨到几百 MB帧率随之掉下去。原因几乎总是资源在循环里被反复创建。爆炸粒子每帧pygame.Surface(...)新建一个、子弹图像每次都pygame.image.load、或者kill()之后仍有别的列表持有引用导致对象无法回收。还有一种是精灵被kill()了但还挂在自定义的self.pending列表里越积越多。解决方法是把资源加载集中到初始化阶段一次完成做一张资源字典按名字取用。爆炸动画用预渲染帧序列粒子用对象池预先创建固定数量用完归还而不是销毁。同时检查所有自定义容器确认精灵被kill()时那些容器也会清理——kill()只负责从Group里移除管不到你自己的 list。5.5 松开方向键飞船还在飘现象是按键松开后飞船继续滑行一段距离才停下或者在某些按键组合下直接卡住不动。原因是输入处理混用了两套机制。事件队列pygame.event.get()里的KEYDOWN/KEYUP是离散的如果某一帧因为卡顿丢了几帧KEYUP事件可能被挤在队列里没及时处理而pygame.key.get_pressed()是实时查询按下和松开立刻反映。两套混用状态就会打架。解决方法是明确分工方向这类需要持续状态的全部用get_pressed()轮询每帧读一次暂停、开火、切场景这类一次性动作才走事件队列。同时get_pressed()必须在每帧开头读一次并缓存下来而不是在多个函数里反复调用后者在多处逻辑下会产生「同帧内状态不一致」的诡异问题。6. 重构收尾一份自检清单和一个能带走的骨架改到这个阶段代码应该已经能通过三个问题的检验调数值是不是只动一个文件、单帧内的执行顺序是不是处处一致、出问题时能不能靠snapshot()复现出同一帧的状态。这三条都过不了的话说明结构还没拆干净别急着加新功能。检查项不合格的表现合格标准配置集中度改一个速度要搜三个文件只改Balance里的字段帧顺序碰撞在移动之前执行顺序写死并加注释状态可复现出了问题只能靠感觉猜snapshot()能存能读资源创建循环里出现Surface()或load全部在初始化阶段完成基准数据只有「感觉变快了」p95 有前后对比数字最后留一个能直接抄走的骨架把前面几章的东西串起来def main_loop(world, balance, clock): dt 0.0 while world.running: # 1. 事件只处理一次性动作 for event in pygame.event.get(): if event.type pygame.QUIT: world.running False elif event.type pygame.KEYDOWN and event.key pygame.K_p: world.toggle_pause() # 2. 轮询持续状态每帧读一次 keys pygame.key.get_pressed() # 3. 更新dt 上限兜底防止窗口拖动后一次性大跳 dt min(clock.tick(60) / 1000.0, 0.05) if not world.paused: world.step(dt, keys) # 4. 绘制与提交 world.draw(world.surface) pygame.display.flip()clock.tick(60)的返回值是上一帧到这一帧的毫秒数直接除以 1000 就是秒。给它套一个min(..., 0.05)是血泪经验——拖动窗口或者机器休眠之后这个值可能是好几秒不做上限保护一帧之内所有精灵会瞬移出屏幕碰撞判定全部错乱表现出来就是「切回来游戏就崩了」。这类 bug 很难在正常测试里碰到但用户一定会碰到。另外要提醒的是重构过程中千万给自己留后悔药。我见过最惨的一种情况是改到一半发现新结构反而更难扩展回头想找能跑的版本发现早就覆盖了。哪怕不用版本管理工具也至少把跑通的那一版复制一份改名保留每次只在一个方向上推进改完跑一次基准数据不对就退回去。希望帮到你。本文还有配套的精品资源点击获取
