简介这是一份面向Python初学者与游戏开发爱好者的植物大战僵尸复刻源码基于Pygame库构建了完整的塔防机制。压缩包内共8个文件包含7张PNG游戏素材图片和1个主程序文件整个资源包仅42KB非常适合直接阅读与二次开发。目前已有12458人学习下载学习热度较高可作为Pygame入门与面向对象编程的实战参考。源码中主程序集中承载游戏核心逻辑包括初始化流程、主循环、事件处理、状态管理和画面绘制图片素材则按背景、植物、僵尸、子弹等类别分别存放便于理解资源加载与渲染过程。通过研究这个项目可以掌握植物与僵尸对象的属性、行为及交互方式进而理解碰撞检测、路径规划、计分系统等经典游戏机制。资源目录结构清晰主程序与素材分离适合按模块逐段拆解也能帮助练习类设计、显示、事件与时间控制等关键技能是一份难得的练手项目。1. 这套源码真正值得拆的不是贴图是对象模型拿到Python版植物大战僵尸.zip展开之后文件不多一个game.py七张PNG贴图grassland.png、peabullet.png、map1.png、map2.png、zombie.png、sunflower.png、peashooter.png没了。很多人会把它当成一个“能跑的demo”收藏起来但我拆完一圈反而觉得这个压缩包的价值不在“能玩”而在它用很朴素的方式展示了Pygame项目的标准三层结构资源加载、主循环、对象交互。如果你想从零搭一个塔防或纵版射击游戏这套代码里的对象模型几乎可以平移到任何项目上。适合两类人一是刚看完Python基础想碰pygame的初学者二是在校生做课程设计缺一个“结构干净、能讲清楚”的参考实现。下面按我拆解的顺序从主循环讲到碰撞每一层都给出可替换的参数和写法。2. game.py 主循环与 Pygame 事件模型拆解2.1 初始化阶段窗口、时钟与全局常量game.py启动后做的第一件事通常就是三件套pygame.init()初始化全部模块、pygame.display.set_mode()创建窗口、pygame.time.Clock()建立时钟对象。初始化顺序有讲究先说结论import pygame import sys # 屏幕尺寸与帧率常量 SCREEN_WIDTH 900 SCREEN_HEIGHT 600 FPS 60 pygame.init() screen pygame.display.set_mode((SCREEN_WIDTH, SCREEN_HEIGHT)) pygame.display.set_caption(Plants vs Zombies - Python) clock pygame.time.Clock() # 预加载全部贴图避免游戏循环内反复读磁盘 grassland pygame.image.load(grassland.png).convert() map1 pygame.image.load(map1.png).convert() map2 pygame.image.load(map2.png).convert() peashooter_img pygame.image.load(peashooter.png).convert_alpha() sunflower_img pygame.image.load(sunflower.png).convert_alpha() zombie_img pygame.image.load(zombie.png).convert_alpha() peabullet_img pygame.image.load(peabullet.png).convert_alpha()这里有两个关键选择。第一背景类贴图用.convert()带透明通道的精灵图用.convert_alpha()。convert()会把图片转成与显示表面相同的像素格式绘制时不再做逐像素格式转换性能远好于直接使用原始Surface。第二图片在while循环之前全部加载到内存否则每帧调用pygame.image.load()会让磁盘I/O成为瓶颈FPS直接掉到个位数。SCREEN_WIDTH900和HEIGHT600不是随手写的。经典植物大战僵尸的逻辑栅格为5行9列加上海草坪与右侧出怪区900x600正好让每个格子在100x100像素附近种子栏和铲子栏还有富余空间。如果做移动端适配这两个常量是第一个要调的参数但要注意后续所有格子坐标计算都会依赖它。2.2 事件队列与四阶段游戏循环Pygame的游戏循环不是写一个while True那么简单它内部可以拆成四个阶段事件轮询、逻辑更新、碰撞检测、渲染绘制。game.py的主循环结构大致如下running True while running: # 阶段一事件轮询处理窗口关闭和鼠标/键盘输入 for event in pygame.event.get(): if event.type pygame.QUIT: running False elif event.type pygame.MOUSEBUTTONDOWN: # 通过鼠标位置判断点击到哪个格子 mouse_x, mouse_y pygame.mouse.get_pos() grid_col mouse_x // 100 grid_row mouse_y // 100 print(f点击格子: 第{grid_row}行 第{grid_col}列) # 阶段二更新所有游戏对象状态植物攻击、僵尸位移、子弹飞行 for plant in plants_group: plant.update() for bullet in bullets_group: bullet.update() for zombie in zombies_group: zombie.update() # 阶段三碰撞检测判断子弹是否命中僵尸 for bullet in bullets_group: hit_list pygame.sprite.spritecollide(bullet, zombies_group, False) for zombie in hit_list: zombie.health - 20 bullet.kill() # 阶段四绘制背景、植物、子弹、僵尸最后刷新画面 screen.blit(grassland, (0, 0)) plants_group.draw(screen) bullets_group.draw(screen) zombies_group.draw(screen) pygame.display.flip() # 控制帧率在60FPS clock.tick(FPS) pygame.quit() sys.exit()阶段一里pygame.event.get()必须每帧调用否则窗口系统发送的QUIT事件会一直在队列里堆积表现为窗口点关闭没反应甚至直接卡死。更隐蔽的问题是如果不做事件处理Pygame内部的事件队列会无限增长内存占用随时间线性上升。阶段二和阶段三分开是刻意的。如果先做碰撞再做更新子弹位移后就没法检测到“穿过僵尸身体”的那一帧会出现子弹穿透的视觉BUG。先更新位置、再检测碰撞是2D游戏里最稳妥的顺序。阶段四里pygame.display.flip()负责把后备缓冲区整体交换到屏幕上所有blit操作都只是绘制在内存里的Surface上不调用flip()屏幕上什么都不会变。这里的clock.tick(FPS)不等于精确延时60毫秒每秒它根据上一帧的实际耗时动态计算等待时间让游戏在不同性能的机器上跑出接近一致的速度。2.3 帧率与事件处理的常见坑clock.tick(60)只保证“每秒最多60帧”不保证“每帧耗时均匀”。如果某一帧逻辑计算超过16.7毫秒下一帧会被压缩出现肉眼可见的卡顿。我的处理方式是把FPS上限值调低到30做性能测试如果30帧下依然卡说明逻辑层有O(n²)级别的碰撞遍历而不是渲染的问题。常见症状可能原因排查手段窗口无响应事件循环里缺少pygame.event.get()打印event.type数量检查队列堆积游戏速度随电脑性能变化没有用clock.tick限帧固定FPS60并确认在循环末尾调用贴图边缘有白边用了convert()而非convert_alpha()换用convert_alpha()加载透明PNG点击位置与格位错位格子宽高与SCREEN_WIDTH不匹配打印鼠标坐标对照网格边界值game.py里最容易被忽略的是sprite模块的使用方式。plants_group、zombies_group、bullets_group都是pygame.sprite.Group()实例Group.draw()在内部会遍历所有成员的image和rect属性自动绘制。这意味着你的自定义类只要在初始化时设置好self.image和self.rect两个属性就能直接享受到Group带来的批量绘制和碰撞检测能力而这两个属性恰好就是下一章对象模型的基础。3. 植物与僵尸的类体系状态、属性与交互逻辑3.1 基类生命周期设计打开game.py的类定义部分核心思路是抽一个Plant基类然后让Peashooter和Sunflower继承它。基类至少要管理三个生命周期阶段种植时的初始化、每帧的update()调用、被僵尸啃咬后的销毁。class Plant(pygame.sprite.Sprite): def __init__(self, image, grid_x, grid_y): super().__init__() self.image image self.rect self.image.get_rect() # grid_x/grid_y 是格子坐标换算成像素坐标需要乘格子边长 self.rect.x grid_x * 100 self.rect.y grid_y * 100 50 # 50是顶部工具栏的偏移补偿 self.health 100 self.timer 0 self.is_alive True def update(self): 每帧调用一次子类必须重写该方法实现具体行为 if self.health 0: self.kill() self.is_alive False def take_damage(self, damage): self.health - damage class Peashooter(Plant): def __init__(self, grid_x, grid_y): super().__init__(peashooter_img, grid_x, grid_y) self.health 150 self.attack_interval 30 # 每30帧发射一颗豌豆 self.bullet_speed 8 def update(self): super().update() if not self.is_alive: return self.timer 1 if self.timer self.attack_interval: self.timer 0 # 生成一颗子弹位置在植物的正右方 bullet Bullet(self.rect.right, self.rect.centery, self.bullet_speed) bullets_group.add(bullet)super().__init__()调用是关键。很多新手写继承时会忘记这行结果self.rect和self.image没被初始化Group.draw()直接抛AttributeError。这里的timer计数方式也值得注意attack_interval30表示30帧发射一次在60帧率下恰好是0.5秒一发。如果你要改成“每0.8秒一发”正确做法是把attack_interval设为int(0.8 * 60) 48而不是直接写48就完事——要在代码注释里标明“48帧0.8秒”否则下次调整帧率时数值语义会模糊。take_damage方法之所以单独抽出来是为了后期扩展“坚果墙”这类高生命植物时不用改碰撞逻辑。僵尸啃咬的伤害值从碰撞代码里传入植物自身只负责扣除生命值和触发死亡状态职责分离。3.2 向日葵的独立生产逻辑与矩形偏移修正向日葵和豌豆射手的行为差异展示了同继承体系下的多态。向日葵不发射子弹它的update()按更长的周期生成“阳光”资源class Sunflower(Plant): def __init__(self, grid_x, grid_y): super().__init__(sunflower_img, grid_x, grid_y) self.health 80 self.produce_interval int(7.5 * 60) # 7.5秒产一次阳光 self.sun_value 25 def update(self): super().update() self.timer 1 if self.timer self.produce_interval: self.timer 0 # 在原版游戏中阳光会随机落在周围这里简化为掉落在植物脚下 print(f产生阳光 {self.sun_value}当前阳光值: , end) # sun_count 是全局变量实际项目中建议封装成 GameState 类 sun_count self.sun_value我要特别提醒矩形偏移的问题。self.rect.y grid_y * 100 50这一行50是根据界面布局算出来的常量。如果顶部工具栏高度改了这个偏移必须同步修改否则点击第0行会种到工具栏下面。更稳妥的方式是把工具栏高度定义为全局常量TOOLBAR_HEIGHT 50所有坐标计算都引用它避免“魔法数字”散落在代码各处。这个教训来源于实际调试grassland.png背景绘制在(0, 0)但如果草地贴图本身就包含顶部装饰种植坐标就要额外减去装饰区的高度否则植物和背景会错位半个格子。3.3 僵尸的状态机移动、啃食、死亡僵尸和植物不同它有两个状态前进状态和攻击状态。用布尔变量或者字符串状态字段都可以但状态一多就容易写出垃圾代码。这里推荐用简单的状态机class Zombie(pygame.sprite.Sprite): def __init__(self, x, y): super().__init__() self.image zombie_img self.rect self.image.get_rect() self.rect.x x self.rect.y y self.health 200 self.speed 1 # 每帧向左移动1像素 self.state walking # walking / attacking / dead self.attack_damage 10 self.attack_interval 20 def update(self): if self.state walking: self.rect.x - self.speed # 检测是否碰到植物 collide_plants pygame.sprite.spritecollide(self, plants_group, False) if collide_plants: self.state attacking elif self.state attacking: # 攻击当前碰撞到的第一个植物 target pygame.sprite.spritecollideany(self, plants_group) if target: if self.timer self.attack_interval: self.timer 0 target.take_damage(self.attack_damage) else: self.timer 1 else: # 植物被摧毁了恢复行走 self.state walking elif self.state dead: self.kill()state字段的划分把僵尸的不同行为隔离在独立的if分支里新增“被冰冻减速”状态时只需在walking分支里额外判断一个speed是否被覆盖不需要改动其他逻辑。这里有个常见的性能坑spritecollide每帧对每个僵尸都做一次系统级碰撞检测僵尸数量超过20个时会产生400次矩形比较。优化手段是把碰撞范围限制在僵尸前方的局部区域或者使用pygame.sprite.groupcollide()一次完成双向检测。对象生命值攻击/产出特殊行为向日葵8025阳光/7.5秒不攻击纯资源生产豌豆射手15020伤害/0.5秒直线发射豌豆子弹速度8px/帧普通僵尸20010伤害/0.33秒速度1px/帧遇植物切换攻击状态上表可以直接作为设计文档中的数值表。数值平衡的调整方法是先确定僵尸的突破时间再反推植物DPS如果希望僵尸走完一格100像素需要5秒那么僵尸速度就是100/5/60 ≈ 0.33px/帧而植物要在这一格内打掉僵尸200血则子弹伤害×命中次数需要刚好覆盖这个值。game.py里的数值可以当作参考基线但不影响你按自己的节奏调整。4. 碰撞检测、弹道追踪与计分系统的实现细节4.1 AABB碰撞检测的边界与成本Pygame的pygame.sprite.collide_rect默认使用轴对齐包围盒AABB也就是直接比较两个精灵rect的left、right、top、bottom坐标。这种碰撞检测的优点是速度极快四次整数比较即可确定两个矩形是否相交缺点是不精确对带透明区域的圆形弹道或斜向移动的僵尸矩形边缘会不真实。碰撞方法精确度性能适用场景collide_rect低快子弹打僵尸、僵尸啃植物collide_mask高慢1-2个数量级飞机游戏、人物与障碍物collide_circle中快圆形弹幕、爆炸范围game.py中子弹与僵尸的碰撞用的是默认的collide_rect对植物大战僵尸这个场景是正确的选择。豌豆子弹尺寸本身接近一个10x10的矩形僵尸贴图虽然不规则但玩家在快速游戏时根本感知不到几个像素的误差。唯一要注意的是rect的边界Pygame的rect默认包含左上角、不包含右下角两个精灵贴在一起时collide_rect可能返回False这是文档里写得很清楚但很多人不知道的行为。4.2 子弹飞行与命中判定的坐标体系豌豆子弹从射出到命中的完整链路包含了两个坐标系像素坐标和对象坐标。子弹自身维护像素坐标碰撞检测依赖rect属性而子弹弹道计算要考虑僵尸的持续移动class Bullet(pygame.sprite.Sprite): def __init__(self, x, y, speed): super().__init__() self.image peabullet_img self.rect self.image.get_rect() self.rect.x x self.rect.y y self.speed speed def update(self): # 子弹向右飞行超出屏幕右边界直接销毁 self.rect.x self.speed if self.rect.left SCREEN_WIDTH: self.kill()子弹向右移动僵尸向左移动二者的相对速度是8 1 9px/帧。也就是说实际碰撞窗口比静态计算要小得多。要让子弹和僵尸的命中判定更符合直觉一个做法是在僵尸的rect基础上向外扩展几像素再参与碰撞这在Pygame里用self.rect.inflate(4, 4)实现把僵尸的碰撞面积放大一圈给玩家一种“打中了边缘也算击中”的宽容手感。子弹命中后对僵尸扣血的代码通常在game.py主循环的碰撞阶段完成而不是放在Bullet.update()里原因在于多个子弹同时命中同一个僵尸时重复扣血需要避免。用pygame.sprite.spritecollide(bullet, zombies_group, False)返回的hit_list里可能有重复的僵尸这时要加一个“上次命中时间”字段或者在僵尸类里记录last_hit_timer保证同一帧内同一个僵尸只能被扣一次血。4.3 计分系统与游戏结束状态迁移计分系统在game.py里一般表现为两个变量score记录击杀僵尸数sun_count记录可用阳光数。但它本质是一个轻量级状态机游戏进行中、游戏胜利、游戏失败三个状态即使用全局变量也能撑住不过状态一多就推荐用字典映射加限状态机模式GAME_STATE running def check_game_state(): global GAME_STATE # 失败条件任一僵尸走出左边界到达房子 for zombie in zombies_group: if zombie.rect.right 50: GAME_STATE lose print(游戏结束僵尸抵达防线后方) return # 胜利条件撑过固定波次这里简化为限制僵尸总数 if spawn_count 30 and len(zombies_group) 0: GAME_STATE win print(胜利油田所有波次) return GAME_STATEcheck_game_state每帧在主循环的阶段二调用一次。僵尸抵达房子边界的判定用了rect.right 50即僵尸矩形右边界进入屏幕左侧50像素内这意味着僵尸半个身子已经走出画面。如果直接用rect.left 0僵尸完全消失才判定失败玩家会觉得“明明僵尸进房子了还不结束”体验割裂。计分视觉化推荐用pygame.font.Font渲染文字font pygame.font.SysFont(simsun, 24) score_surface font.render(f阳光: {sun_count} 得分: {score}, True, (255, 255, 255)) screen.blit(score_surface, (20, 15))注意SysFont在Windows和Linux上的中文字体名称不一样Linux没有simsun会回退到默认字体中文字符显示为方块。跨平台方案是用pygame.font.match_font([simsun, arial, wenquanyimicrohei])按顺序匹配或者干脆用英文文本“Sun: xxx Score: xxx”避免字体问题。5. 素材管理优化与资源加载的进阶技巧game.py中的贴图加载方式可以再做一轮重构把七张图片的上传、格式转换、尺寸校验统一封装成一个函数否则每次新增植物都要复制三行pygame.image.load代码。具体做法是维护一个image_path字典用文件名索引def load_images(img_dir): 加载目录下所有PNG自动处理透明通道 images {} for filename in os.listdir(img_dir): if filename.endswith(.png): path os.path.join(img_dir, filename) if filename in (grassland.png, map1.png, map2.png): images[filename] pygame.image.load(path).convert() else: images[filename] pygame.image.load(path).convert_alpha() return imagesfilename in (...)判断背景图和精灵图的分流方式不优雅但在这个七张图的规模下足够直白真项目里建议在素材文件命名时就约定前缀比如bg_开头全是背景sp_开头全是精灵然后用字符串startswith判断。第二个进阶点是图片尺寸的运行时校验get_rect()拿到的宽度超过目标绘制区域时用pygame.transform.smoothscale()做一次等比缩放避免贴图和格子尺寸不匹配导致的重叠或缝隙。最后说打包。把game.py分发给别人用时用PyInstaller打包是标准方案但新手最常见的报错是打包后运行时提示“无法打开grassland.png”。原因在于PyInstaller默认不会把非代码文件打入exe需要在.spec文件里显式声明素材路径pyinstaller -F --add-data imgs;imgs game.pyWindows下的路径分隔符是分号Linux和macOS是冒号且imgs目录被解压到临时文件夹代码里引用路径时要用sys._MEIPASS拼接。关于验证我建议在任何优化后跑一遍固定时长的自动对局统计FPSS平均值打开任务管理器记录运行10分钟的内存占用再用pygame.time.get_ticks()计算一局游戏的总耗时如果这些指标和优化前一致说明改动安全。这套源码的价值就在于此——小但五脏俱全拿它练手能覆盖到独立游戏开发八成的基础问题。本文还有配套的精品资源点击获取