简介：这是一份基于Python与pygame库的“外星人入侵”2D射击游戏完整码源，适合Python初学者、游戏开发入门者以及需要课程设计参考的学习者。项目通过真实的游戏开发流程，帮助读者掌握类与继承、事件处理、碰撞检测、计时器与音效加载等关键知识点。资源包采用zip格式，整体约182KB，内部以Python源码文件为主，代码中配有大量注释，便于逐行理解。目前已有660人学习下载，是一份被验证过的练习资源。压缩包内包含了完整的项目实现，从pygame初始化、主循环搭建，到Player、Alien等类的设计、子弹与外星人碰撞反应均有清晰呈现；读者可以直接运行体验，也可在此基础上扩展为更完整的射击游戏，用以巩固面向对象编程与游戏开发基础。
1. 外星人入侵之前：先搞清这个Python项目到底让你练什么
一个刚学完 Python 基础语法的人，最难受的不是变量、循环、函数不会写，而是不知道这些语法拼在一起能做什么。外星人入侵这个实践项目之所以近十年里一直排在 Python 入门推荐榜前列，因为它把「面向对象」、「事件循环」、「碰撞检测」、「文件存储」这些概念揉进了一个画面会一直动的游戏里，练完之后你会突然理解：原来函数是这样拆的，类是这样协作的，循环是这样驱动一整个程序的。
这个项目的玩法人人都懂——控制飞船躲避并击落下坠的外星人，背后却是一个最小但完整的游戏开发回路。适合刚装好 Python、只写过命令行程序的人，也适合想补一份拿得出手的练手作品、但不想一上来啃图形学的人。它的好不在于画面，在于恰好每一行代码都在解决一个真实问题，改一个参数就能看到行为变化。这份码源最大的价值不是让你抄一遍跑起来，而是给你一个能拆、能改、能加功能的地基。
2. 环境与最小复现：装好 Pygame 并用一个最简单的窗口先跑起来
2.1 为什么选 Pygame 而不是 Turtle 或 Pygame Zero
很多 Python 入门者在搜索引擎里同时看到Turtle和Pygame，容易误以为都能做游戏就随便选。Turtle是 Python 标准库自带的绘图工具，画线、画圆、做简单动画足够，但它的画面刷新方式和坐标体系是为教学设计的，一旦需要同时管理十几个对象、检测对象之间的重叠，就会写出一堆难以维护的代码。外星人入侵里要同时处理飞船、子弹、整队外星人，Turtle 的效率明显跟不上。
Pygame 是更贴近真实游戏开发的 2D 框架，核心抽象是「精灵（Sprite）」和「精灵组（Group）」，天然支持大批量对象的更新与绘制。Pygame Zero 虽然更友好，但它是建立在 Pygame 之上的一层封装，隐藏了事件循环和初始化细节，对「想搞懂原理」的人来说反而少了一段必须走的路。我做这个项目时会选原生 Pygame——教程代码最通用、出问题时搜到的解答最多、以后想继续做 2D 游戏也无缝迁移。
2.2 从零搭环境：Python 版本与 pip 安装
如果你刚搜过python安装、python环境变量配置这类问题，说明环境可能还没完全跑通。第一件事不是急着装游戏库，先把 Python 版本确认好。常见做法是安装 Python 3.10 或 3.11，这两个版本在 Pygame 生态里踩坑最少，python下载安装教程里搜索到的许多报错也都集中在 3.12 之后的部分预编译包缺失问题上。
安装 Pygame 之前，建议先用python -m pip --version确认 pip 可用，再执行安装命令：
pip install pygame如果下载慢，就用清华镜像源：
pip install pygame -i https://pypi.tuna.tsinghua.edu.cn/simple这里说一个多数新手会忽略的细节：不要在系统全局 Python 里直接装库，而是新建一个虚拟环境。这样不同的项目依赖互相不污染，换电脑迁移时只需要一份requirements.txt：
python -m venv alien_envWindows 上激活：
alien_env\Scripts\activatemacOS / Linux 上激活：
source alien_env/bin/activate激活后命令行提示符会变成(alien_env)，再用pip install pygame，库就只装在这个环境里。项目写完了，一句pip freeze > requirements.txt就能把这套环境完整带走。这套流程是玩 Python 项目的基本功，比急着写游戏代码更能救命。
2.3 最小窗口：验证 Pygame 是否装好
装好库之后，不要一上来就粘贴外星人入侵的完整代码。先写一个只有窗口的骨架，确认图形环境没问题、运行不报错，再往上叠加逻辑。这是做任何图形项目的习惯：最小可运行版本是一切信心的来源。
import pygame pygame.init() screen = pygame.display.set_mode((1200, 800)) pygame.display.set_caption("Alien Invasion") clock = pygame.time.Clock() running = True while running: for event in pygame.event.get(): if event.type == pygame.QUIT: running = False screen.fill((230, 230, 230)) pygame.display.flip() clock.tick(60) pygame.quit()这段代码虽然短，但它是整个游戏循环的骨架。逻辑说明如下：
pygame.init()只需要调用一次，负责初始化显示、音频、事件等所有底层模块；pygame.display.set_mode((1200, 800))创建窗口，返回值是我们画图用的 Surface 对象，所有画面内容都绘制在这个面上；pygame.display.flip()把内存里的画面一次性推到显示器上，不加这一行，窗口只会是一片空白。
clock.tick(60)是帧率控制器，让循环每秒最多跑 60 次。在外星人入侵里，移动速度都是按「每帧移动多少像素」来设计的，所以帧率必须稳定，否则速度会随电脑性能忽快忽慢。运行这段代码能正常弹窗、退出，就说明 Pygame 环境已经就绪，后面才可以继续加飞船和外星人。
3. 游戏循环与精灵体系：把「一直动的画面」拆成可控状态
3.1 三段式循环：输入、更新、绘制
有了窗口骨架之后，接下来要理解一件事：游戏画面看起来像在动，实质上是静止图像快速切换。外星人入侵的每一帧都要做完三件事——读取键盘和鼠标输入、更新所有对象的位置和状态、把最新状态画到屏幕上。这三件事缺一不可，顺序也不能乱，这就是所谓的「游戏循环」。
实际代码里，三段式循环通常长这样：
while running: # 第一段：读取输入事件 for event in pygame.event.get(): if event.type == pygame.QUIT: running = False elif event.type == pygame.KEYDOWN: # 按下方向键，移动标志置为 True if event.key == pygame.K_RIGHT: ship.moving_right = True # 第二段：更新逻辑 ship.update() bullets.update() # 第三段：绘制画面 screen.fill((230, 230, 230)) ship.draw() bullets.draw(screen) pygame.display.flip()第一段里pygame.event.get()取出本帧积累的全部事件，比如按键按下、松开、鼠标点击。注意它取的是「事件」，不是「当前按键状态」，所以像「飞船一直向右移动」这类操作不能只在事件里处理——一个按键按下事件只发生一次，这帧结束了就没有了。需要用一个标志位，按一下K_RIGHT就把moving_right置为 True，一直带到后续每一帧的update()里去判断。
第三段里screen.fill((230, 230, 230))先用纯色清空整个屏幕，然后依次画上飞船和子弹。为什么必须清空？如果不清空，上一帧的飞船残影会留在原地，整个画面会变成一堆重叠的影子。Pygame 用「后缓冲」机制，你画的每一帧都在看不见的层上完成，flip()之后才整体呈现，所以画面不会闪烁，但不清空一样会乱套。
3.2 精灵类：让飞船、子弹、外星人共用一套逻辑
外星人入侵这个项目里飞船、子弹、外星人都有一个共同点：它们都有位置、有图像、要移动、要画出来、要检测是否被击中。与其给每个对象写一套重复代码，不如用 Pygame 的Sprite基类统一描述。
from pygame.sprite import Sprite class Ship(Sprite): def __init__(self, screen): super().__init__() self.screen = screen self.image = pygame.image.load("images/ship.bmp") self.rect = self.image.get_rect() self.screen_rect = screen.get_rect() self.rect.midbottom = self.screen_rect.midbottom def blitme(self): self.screen.blit(self.image, self.rect)self.image是加载的位图对象，self.rect是图像的外框矩形。Pygame 里几乎所有位置和碰撞检测都靠矩形rect完成，而不是靠像素精确判断——因为矩形运算速度远高于像素级检测，对入门项目完全够用，这也是游戏开发里非常常用的取舍。
self.rect.midbottom = self.screen_rect.midbottom这行把飞船放在整个窗口底部中央，用的是相对定位而不是写死坐标。这样窗口尺寸一改，飞船位置自动跟着窗口走，画布适配不用再调代码。
精灵类的好处在于，当对象数量增多时，可以塞进Group统一管理：
aliens = pygame.sprite.Group() for alien in aliens: alien.update() aliens.draw(screen)一个Group可以对内部所有精灵批量调用update()和draw()。外星人入侵里一屏通常有二三十个外星人，如果用普通列表，每次都要手动循环画、手动循环更新、手动处理删除，代码会迅速膨胀到不可维护。精灵和精灵组的配合是这个项目最重要的代码组织方式。
3.3 坐标系与移动速度：为什么这个项目不用 delta time
有些人从 Unity 或 Godot 转到 Python 项目，第一反应是「时间步长不能用固定值，要乘 delta time」。在外星人入侵里，我不建议你这么做。原因很简单：Pygame 的tick(fps)已经把帧率钉死，每帧间隔是稳定的约 16 毫秒，固定像素移动就能得到匀速运动。
如果非要用 delta time，速度单位从「像素/帧」变成「像素/秒」，刚开始会觉得更专业，但后面调参时要换算，教程里的所有速度参数也都要重写，对入门项目来说是在给自己制造不必要的麻烦。项目里可以直接用「每帧移动 1.5 像素」这样的写法，视觉上就是很舒服的缓慢移动。
| 移动速度写法 | 单位 | 适用场景 |
|---|---|---|
self.x += 1.5 | 像素/帧 | 帧率锁定为 60 时，速度稳定，推荐 |
self.x += speed * dt | 像素/秒 | 帧率不稳定或引擎需要时，入门项目不推荐 |
另外一个小细节：位置用浮点数存，赋值给rect时再转成整数。
self.x = float(self.rect.x) def update(self): self.x += self.speed self.rect.x = self.x把self.rect.x的原始值先存到self.x浮点变量里，每次移动累加浮点值，再把结果转换回rect.x。因为rect.x只接受整数，如果直接对它做+= 1.5，小数部分会丢失，飞船速度在游戏里会看到一顿一顿的跳变，这在 Pygame 社区里是老生常谈的玄学坑之一。
4. 飞船控制与子弹发射：事件轮询和状态管理的落地写法
4.1 键盘输入：用布尔标志位解决「长按不连续」问题
飞船移动的代码，新手最容易写成的样子是「按一下方向键走一步」。但在游戏里，玩家期望的是按住右键就一直向右移动，松开才停。Pygame 的事件模型里，KEYDOWN只在按键刚按下那一帧触发，长按期间不会有持续的事件流，所以必须在事件之外维护状态。
class Ship: def __init__(self, screen): # 原有初始化代码... self.moving_right = False self.moving_left = False def update(self): if self.moving_right and self.rect.right < self.screen_rect.right: self.x += self.speed if self.moving_left and self.rect.left > 0: self.x -= self.speed self.rect.x = self.x对应在主循环里：
for event in pygame.event.get(): if event.type == pygame.KEYDOWN: if event.key == pygame.K_RIGHT: ship.moving_right = True elif event.key == pygame.K_LEFT: ship.moving_left = True elif event.type == pygame.KEYUP: if event.key == pygame.K_RIGHT: ship.moving_right = False elif event.key == pygame.K_LEFT: ship.moving_left = FalseKEYDOWN把对应标志置为 True，KEYUP置为 False，update()每帧检查标志位。这套机制比「在事件里直接改坐标」多了一步，但它才是游戏循环的正确思路——事件是瞬间的，状态是持续的。
边界判断也要放在update()里：self.rect.right < self.screen_rect.right保证飞船右边缘不超过窗口右边，self.rect.left > 0保证左边缘不越出窗口左侧。注意这里判断的是rect.right和rect.left，不是rect.x——因为rect.right等于rect.x + rect.width，用rect.x判断会让飞船撞出屏幕一半。
4.2 子弹：用精灵组管理生命周期
子弹是典型的「快速产生、快速消失」对象，如果用普通列表，删除时不能直接del，因为循环过程中改列表长度会跳过元素。用Group配合内置的update()和碰撞检测，可以省掉大量手动管理细节。
class Bullet(Sprite): def __init__(self, screen, ship): super().__init__() self.screen = screen self.rect = pygame.Rect(0, 0, 3, 15) self.rect.midtop = ship.rect.midtop self.y = float(self.rect.y) self.speed = 3.0 def update(self): self.y -= self.speed self.rect.y = self.y主循环里，每按一次空格键就生成一颗子弹放进bullets组：
if event.type == pygame.KEYDOWN and event.key == pygame.K_SPACE: if len(bullets) < 5: bullets.add(Bullet(screen, ship))用pygame.Rect(0, 0, 3, 15)直接创建一个矩形，不加载图片，游戏里看起来就是一条竖直的亮线。这里的速度单位是「像素/帧」，负数方向是向上——因为 Pygame 坐标原点在窗口左上角，y 轴向下为正。
子弹飞出屏幕后需要从组里移除，不然会一直累积占用内存。常见做法是在主循环里给bullets.update()之后加一句清理：
for bullet in bullets.copy(): if bullet.rect.bottom <= 0: bullets.remove(bullet)为什么要用.copy()？因为循环中直接移除bullets的元素会破坏迭代器内部结构，导致「在遍历时修改容器」的运行时错误。copy()复制一份迭代对象，原 group 怎么改都不影响这个副本的遍历。这也是后来接触 Pygame 项目时最容易翻车的一行。
4.3 控制射击频率：限弹数而不是限时间
很多教程用时间间隔控制射击频率，但实现起来要维护一个时间戳变量，判断当前帧距上次射击是否超过多少毫秒。外星人入侵这个级别用更朴素的方式就够了：限制场上同时存在的子弹数。
示例代码里len(bullets) < 5表示最多 5 发子弹同时在屏幕上。玩家即使疯狂按空格，也只会保留最新发出的 5 发，屏幕上的子弹数有限，绘制和性能压力也就有限。这个方法简单、稳定、易于理解，等以后做更复杂的射击游戏时再改用冷却时间机制也不迟。
5. 碰撞、计分与重启：外星人入侵的四个常见翻车点
5.1 碰撞检测没反应：先查精灵组的draw顺序
现象：子弹明明穿过了外星人的图像，外星人却没有消失，也没有任何得分变化。
原因：大概率不是碰撞检测本身出错，而是绘制顺序有问题。外星人的Group.draw(screen)如果排在子弹绘制之前，飞船和外星人都会被画上去，但飞船又画了一遍，视觉上没问题；真正的问题往往是碰撞检测生成了结果，但没有从所有组里把被击中的对象移除掉。
解决：碰撞检测要同时处理子弹和外星人两个组。
collisions = pygame.sprite.groupcollide(bullets, aliens, True, True)groupcollide的参数逐一说清楚：第一个True表示碰撞发生时删除子弹，第二个True表示碰撞发生时删除外星人。返回值是字典，键是击中的子弹，值是被击中的外星人列表。如果只删外星人不删子弹，子弹就会穿肠而过继续撞下一批，场面看着像「法外狂徒」。这行代码是这个项目里默认的碰撞处理方式，也是最可靠的方式。
5.2 外星人编队不整体移动：边缘检测与方向标志
现象：外星人单个都能动，但它们不会作为一个团队左右移动，也没有到达边缘后集体下移的动作。
原因：整个编队的移动逻辑不能放在某个外星人自己的update()里，而必须由主循环统一计算编队的最左边缘和最右边缘。
解决：在Alien类里增加一个类属性direction，表示当前整体移动方向：
class Alien(Sprite): direction = 1 # 1 表示向右，-1 表示向左 def update(self): self.x += self.speed * Alien.direction self.rect.x = self.x然后在每次更新编队后检查边缘：
aliens.update() for alien in aliens: if alien.rect.right >= screen_rect.right or alien.rect.left <= 0: Alien.direction *= -1 for alien_in_group in aliens: alien_in_group.rect.y += 20 break判断逻辑是：遍历所有外星人，任意一个碰到屏幕边缘，就把方向乘以-1，同时所有外星人向下移 20 像素。注意这里direction用的是类属性而不是实例属性——如果每个外星人各记各的方向，它们就会在移动中互相走散，编队立刻解体。类属性是所有实例共享的一份数据，天然适合表达「整个编队的方向」。
5.3 游戏重置：最容易漏掉的黑匣子状态
现象：飞船被外星人撞毁后，游戏提示重新开始，但重新开始时仍然残留上一局的外星人、子弹和分数，看起来像是旧的游戏画面被硬生生续了一张。
原因：新游戏开始时只把飞船放回了底部中间，却忘了清空aliens组和bullets组，也没重置分数。
解决：把「初始化一局新游戏」的代码集中成一个函数，每次调用都从干净的组开始：
def start_new_game(): bullets.empty() aliens.empty() create_fleet() ship.center_ship() stats.score = 0 stats.level = 1Group.empty()清空全部精灵。center_ship()把飞船移回底部中间。分数、等级这些全局状态也要在同一处重置。很多做外星人入侵的人会卡在「游戏能玩但不能重玩」，正是因为重置逻辑散落在各个位置，漏了一个状态位没回到初始值。把「重新开始必须要做的事」写成一个函数，是这个项目里最值得学到的组织方式之一。
5.4 其他高频坑：路径、全屏、事件循环阻塞
现象一：代码运行后报错pygame.error: Couldn't open xxx.bmp，但文件明明在项目目录里。
原因：工作目录不是项目根目录。比如从桌面启动终端、代码在别的文件夹，pygame.image.load("images/ship.bmp")相对路径解析失败。
解决：不在代码里拼路径，而是先用os.chdir切到项目目录，或直接使用绝对路径。更稳的是在项目根目录下建一个main.py，所有资源路径都相对于根目录写，启动方式固定为在根目录执行python main.py。
现象二：窗口显示后立刻卡死，点关闭按钮没反应。
原因：clock.tick()没有运行，主循环没有刷帧，事件消息没有及时处理，操作系统判断窗口未响应。
解决：任何阻塞型操作（如input()、time.sleep()大间隔等待）都不要放进主循环。tick(60)本身已经让循环每 16 毫秒睡眠一次，不要再额外加长睡眠。
现象三：外星人图像带黑底或白底，像贴了一张方块纸。
原因：加载的位图背景色没有做透明处理。
解决：用以下代码把某一种颜色设为透明：
ship.set_colorkey((255, 255, 255)) ship = ship.convert_alpha()如果源图片背景不是纯色，需要先处理图片本身，这是美工问题，不是 Pygame 的问题。.convert_alpha()把图像转换成显示格式相同的内存布局，绘制速度会快很多。
6. 从复现到改造：记分、难度曲线与把你的版本留给下一个人
6.1 给游戏加记分牌：文件读写练手机会
外星人入侵跑通后，第一件值得加的功能是记分。分数变化来自击中外星人，每击中一个加一定分数；击落一批外星人后再生成新的一批，分数可以累加。这里会用到 Python 的文件读写知识——把最高分存到本地文件，游戏重启后还能读出来。
def read_high_score(): try: with open("high_score.txt", "r", encoding="utf-8") as f: return int(f.read().strip()) except FileNotFoundError: return 0 def save_high_score(score): with open("high_score.txt", "w", encoding="utf-8") as f: f.write(str(score))try/except处理文件不存在的情况，避免游戏首次运行因缺少记录文件而崩溃。int(f.read().strip())读取字符串后转整型，strip()去掉多余换行。文件读写在这里不是独立的「文件操作习题」，而是嵌在游戏里的实用环节——游戏结束判断if score > high_score时就把分数写回文件。
6.2 参数化的难度曲线：改数据而不是改逻辑
游戏做多了以后，你会发现一个反直觉的规律：多处代码里写死的速度数值，会让调难度变得非常痛苦。比如想每过一关就让外星人移动快一点，却要在Alien类、Bullet类、Ship类里分别找到那个数字改一遍。更好的做法是把这套速度抽成配置参数，一处修改全局生效。
| 参数 | 初始值 | 作用 |
|---|---|---|
ship_speed | 1.5 | 飞船左右移动速度 |
bullet_speed | 3.0 | 子弹向上飞行速度 |
alien_speed | 0.5 | 外星人编队左右移动速度 |
alien_drop_speed | 20 | 编队触边后下移的距离 |
fleet_direction | 1 | 编队初始方向，1 右 -1 左 |
score_alien | 10 | 击落一个外星人的得分 |
把这些值集中放在一个Settings类或字典里，升级难度时只改数值：
class Settings: def __init__(self): self.ship_speed = 1.5 self.bullet_speed = 3.0 self.alien_speed = 0.5 self.alien_drop_speed = 20 self.score_alien = 10每一局开始时让alien_speed *= 1.2、score_alien += 5，就形成了一条简单的难度曲线。后期想调平衡，只看配置不看逻辑，这就是参数化的实际价值。
6.3 三个验证方法：跑通之后如何确认它真的稳定
第一个方法是速度试炼：把alien_speed调到 3.0 以上，如果游戏仍然流畅、碰撞准确、没有漏检，说明你的基础逻辑是可靠的；如果某个环节卡顿或穿模，问题会在高速下暴露得更明显。第二个方法是注释法：把draw相关代码全部注释掉，程序仍然能运行，只是画面黑屏。如果注释后程序报错或事件循环卡死，说明你的逻辑更新和画面渲染耦得太紧，后续扩展会受限。第三个方法是计数输出：在碰撞检测代码后临时加一句print(len(aliens))，观察屏幕上剩余外星人数量是否符合预期。这三个方法配合使用，可以覆盖大部分隐藏问题。
我做这个项目时还有一个习惯：代码里所有速度值都放在一个Settings类里，并且每次从最简单的窗口骨架开始搭建，而不是直接贴一整段别人的完整代码。从骨架到船、从船到子弹、从子弹到敌人，每加一层都先跑一遍再写下一层。这个习惯让我在后来做更复杂的 Pygame 项目时翻车率直线下降——每一次只引入一个新的可变因素，出了错很快能定位到刚加的那几十行。希望帮到你。
本文还有配套的精品资源，点击获取
