Python+Pygame吃豆人小游戏毕设全流程：从选题拆解到答辩实战

每年毕业设计季，都会有师弟师妹跑来问我：想用Python写个小游戏，什么题目既拿得出手又不容易翻车？我一般会推荐吃豆人小游戏。这个选题听起来很经典，好像满大街都是，但真正做下来你会发现，它把游戏开发里的地图设计、角色控制、碰撞检测、简单AI、状态切换、资源打包这些东西全串起来了，而且每一项都有可以展开讲的空间。作为Python方向的毕设，它不会难到让你写不下去，也不会简单到答辩时无话可说，属于典型的“入门不难、深入有料”的项目类型。这篇内容我就围绕吃豆人小游戏，完整拆一遍从选题拆解到技术实现、再到答辩汇报的实操思路，适合选了类似题目但还没有具体方案的同学直接照着搭。

1. 为什么选吃豆人：毕设选题的价值与需求拆解

1.1 这个题目到底考察什么

吃豆人的游戏规则很简单：玩家操控角色在迷宫里移动，吃到所有豆子就算过关，过程中要躲避幽灵，吃到大力丸后可以反过来吃掉幽灵。但“规则简单”不代表“实现简单”。从计算机专业的角度看，这个项目至少覆盖了这么几个核心能力点：

• 面向对象设计：玩家、幽灵、地图、游戏控制器是需要抽象成类的，类之间的关系怎么划分，是答辩时最容易问到的点。
• 数据结构应用：迷宫地图本身就是一张二维矩阵，豆子位置、墙体碰撞、路径搜索都要依赖数据结构来组织。
• 基础AI逻辑：幽灵的追踪、逃跑、巡逻不能靠随机，需要用距离判断或搜索算法来驱动。
• 事件驱动开发：键盘输入、游戏状态切换、精灵动画刷新，全部是事件驱动的典型场景。
• 工程化能力：代码组织、注释规范、资源文件管理、打包运行，这些在实际开发中比写核心算法更影响体验。

如果你只想通过查重，网上随便抄一份代码改改当然可以，但答辩老师一旦追问“幽灵AI是怎么设计的”“碰撞检测为什么用矩形”“地图数据怎么读进来的”，答不上来就非常尴尬。所以选这个题目的正确姿势，不是把它当成一个“抄来的成品”，而是当作一次完整的软件工程小实践来做。

1.2 功能需求的细化清单

很多同学写需求分析只会写一句“实现吃豆人游戏”，这太模糊了，写进文档里老师会直接打回。把需求拆细之后，你会发现工作量是可控的，而且每一块都能单独说明。我建议按功能模块拆成下面这些点：

• 基础功能：角色在地图内自由移动，不能穿墙，吃到豆子后分数增加，豆子消失。
• 幽灵系统：至少设计4个幽灵，拥有追捕、散射、害怕、回收4种状态，玩家被碰到后扣生命。
• 道具机制：地图中放置大力丸，吃下后幽灵进入可被反吃状态，有持续时间。
• 游戏流程：通关判定（豆子全部吃完）、失败判定（生命归零）、关卡难度递增。
• 界面反馈：实时显示分数、剩余生命、当前关卡，支持开始界面和结束界面。
• 扩展项：音效、动效、键盘流畅操作、打包成exe，这些是加分项，也是答辩时的“差异化亮点”。

需求清单列出来之后，你就可以分配时间了。一般来说，地图和玩家移动是最要先做的，幽灵AI是最花时间的，界面和音效是最后补的。千万不要一上来就写幽灵AI，否则地图还没跑通，调试难度会翻倍。

2. 技术选型与工程结构：别一上来就写代码

2.1 语言与库的选择：Pygame为什么够用

Python写游戏，最常用的库就是Pygame，它是SDL的Python封装，专门用来处理窗口创建、图像加载、键盘鼠标事件、音效播放这些底层操作。很多同学会纠结要不要用Pygame Zero、Tkinter、或者干脆上Unity，我的建议是：如果毕设题目明确写了Python，那就老老实实用Pygame，原因有三个：

一是生态成熟，网上资料多，遇到问题能搜到解决方案；二是文档清晰，API很稳定，适合短时间上手；三是它足够“底层”到能体现出你的能力，窗口循环、精灵绘制、碰撞检测这些核心机制都是自己写的，答辩时能讲的东西非常多。相比之下，Pygame Zero虽然写起来更快，但很多逻辑被封装掉了，反而不好解释；Tkinter做2D游戏性能差，卡顿感明显；Unity虽然效果好，但那已经不是Python小游戏的范畴了，方向跑偏。

安装过程不复杂，直接用pip装即可。需要注意Python版本和Pygame版本的匹配，Python 3.8以上的环境装Pygame 2.x基本没有问题。如果装完打开窗口报错或者闪退，优先检查是不是显卡驱动和SDL初始化的问题。

2.2 整体架构与代码目录规划

代码结构是毕设老师比较看重的一项，拆分得好说明你有工程意识。下面是一种简单但合理的组织方式：

pacman/ ├── main.py # 程序入口，初始化游戏 ├── settings.py # 全局配置：尺寸、颜色、速度、常量 ├── map.py # 地图数据加载与绘制 ├── player.py # 玩家类：移动、吃豆、状态 ├── ghost.py # 幽灵类：AI状态、移动、绘制 ├── game.py # 游戏主控制器：循环、碰撞、分数、关卡 ├── resources/ │ ├── images/ # 图片素材 │ ├── sounds/ # 音效文件 │ └── maps/ # 地图文本文件 └── docs/ # 需求分析、设计说明、答辩PPT素材

有的同学喜欢把几百行代码全部塞进一个 main.py 里，这样做不是不能运行，但后期调试极其痛苦，哪怕只改一个豆子数量都要翻很久的代码。模块化之后，每块逻辑是独立的，写测试也方便。settings.py 单独拉出来是我特别想强调的，因为吃豆人的所有参数——格子大小、移动速度、幽灵速度、力量丸持续时间、颜色配置——都会在调平衡性的时候反复修改，集中放到一个文件里，调一次改一处，效率高很多。

3. 地图、角色与游戏循环：核心细节怎么落地

3.1 迷宫地图的二维数组表示

吃豆人的地图数据最适合用二维数组来表示。简单说，就是用一排字符串，每个字符对应一个格子，例如：

MAZE_1 = [ "####################", "#........##........#", "#.##.###.##.###.##.#", "#..................#", "#.##.#.######.#.##.#", "#....#....##....#..#", "####.#.###..###.#.##", " #.# 0 #.# ", "####.#.######.#.####", "#........##........#", "#.##.###.##.###.##.#", "#..##....##....##..#", "###.##.######.##.###", "#.....#.... .....#", "#.#####.##.##.#####.#", "#.................#", "####################", ]

在这个数组里，“#”代表墙体，“.”代表普通豆子，“ ”代表空地，数字或字母可以代表幽灵初始位置，P代表玩家出生点。读取的时候只要遍历数组，把每种字符映射成对应的对象或标志就行。这样做的好处是：改地图就是改文本，完全不碰代码，测试不同的迷宫布局非常方便。

我见过不少同学用坐标列表手动摆墙和豆子，代码里一大串坐标数字，一旦地图要调整就崩溃。用二维数组的方式，地图可视化程度高，也方便计算格子坐标。比如每个格子是30像素，那么二维数组的 [row][col] 对应屏幕上的位置就是 col30, row30，算起来非常直观。

这里还有一个容易踩的坑：豆子不要用二维数组的同一个字符串反复遍历去“删除”。因为字符串是不可变的，改成“空格”还要重新拼接，效率低也容易错。比较稳妥的做法是在加载地图时，把所有豆子的坐标收集到一个集合（set）里，例如 {(行, 列), (行, 列), ...}，玩家每次移动后判断当前格子是否在这个集合中，如果在就删除它并加分。查找复杂度是O(1)，比遍历整个地图快得多。

3.2 主角移动与碰撞检测的细节

玩家的移动控制看起来简单，但细节决定了手感。最基本的方式是监听键盘事件，把上下左右键映射到方向向量上，然后在游戏循环里按这个方向移动。比如方向为向右时，x坐标加上移动速度乘以时间增量；向上时，y坐标减去移动速度乘以时间增量。

但直接把自己画到墙上再拉回来，会有个很严重的体验问题：如果玩家按了向上键，角色会先卡在墙前一帧再移动，看上去是“抖”的。更好的做法是“预判移动”：每次移动前，先计算下一步会到达的新位置，判断这个新位置对应的格子是不是墙，如果是墙就不移动，否则才移动。这样角色会紧贴墙停下来，不会穿模，操作也更跟手。

def can_move(self, new_x, new_y, maze): grid_x = int(new_x // TILE_SIZE) grid_y = int(new_y // TILE_SIZE) if maze[grid_y][grid_x] == WALL: return False return True

碰撞检测的判断也需要统一标准。如果每个角色用不同的坐标口径，比如一个用左上角，一个用中心点，就会出现“觉得碰到了但其实没碰到”的判定问题。我建议统一用Rect对象来管理位置和碰撞，Pygame里Rect天然提供了colliderect方法，碰撞判断写起来非常简洁。需要注意的是，Rect的坐标是左上角，而很多计算用中心坐标更方便，所以最好在类内部封装一个center属性，返回中心点坐标，用于格子归属判断；碰撞检测则直接用Rect。

另外一个很实用的小技巧是“方向缓冲队列”。吃豆人原版里，玩家先按右再迅速按上，角色会在到达可行路口时自动转向。实现方式很简单：维护一个最近一次有效按键的方向，当当前方向下一个位置被堵住时，检查缓冲方向是否可行，可行就切换方向。这样就能模拟出经典街机的操作手感，很多同学做完之后觉得“操作有点生硬”，差就差在这个缓冲逻辑上。

3.3 游戏循环与帧率控制

Pygame的核心是一个无限循环，每一帧做三件事：处理输入、更新游戏状态、绘制画面。循环写得不好，最典型的问题是“速度跟电脑性能挂钩”——好的电脑跑得快，坏的电脑跑得慢，这在毕设演示现场特别容易出丑。解决方案是用Clock对象锁帧率：

clock = pygame.time.Clock() while running: dt = clock.tick(60) / 1000.0 handle_events() update(dt) draw()

tick(60)的意思是让循环每秒最多执行60次。dt是上一帧到这一帧的秒数，所有角色移动都乘以dt，这样无论机器性能如何，角色的实际移动速度都保持一致。这里再提醒一句：如果你用clock.tick(60)但移动步长不乘dt，那么帧率波动时游戏速度会明显变化，这是一个非常容易忽略的bug。

游戏状态的管理也要放在循环里统一处理。吃豆人至少需要这么几个状态：开始界面、游戏中、暂停、关卡结束、游戏结束。我建议用一个简单的状态变量加分支来管理，状态多了再用状态模式。比如GAME_STATE = "PLAYING"，根据状态决定要不要更新角色、要不要响应键盘、绘制哪个界面。很多同学不区分状态，结果就是角色死了还在移动，游戏结束了还能吃豆子，逻辑一片混乱。

4. 幽灵AI与状态管理：让游戏“活”起来

4.1 幽灵的追捕、散射与巡逻逻辑

幽灵AI是整个项目里最值得写进论文和PPT的部分，也是最容易出彩的地方。经典吃豆人里，每个幽灵看起来在“追你”，但其实背后是一套非常清晰的规则。实现上不用做太复杂，掌握追捕和散射两种模式就够了。

追捕模式的目标是玩家当前位置，幽灵每到一个路口，就选择能让它离玩家最近的格子方向走。距离一般用曼哈顿距离，也就是横向格子差加上纵向格子差，因为迷宫不允许斜着走，欧几里得距离反而不符合实际。“离玩家最近”不能只看下一步，而是估算到目标需要的总步数。简单实现时，可以用BFS搜索最短路，也可以用“贪心+防回头”的近似方案。对毕设来说，BFS更稳妥，因为迷宫规模不大，每个路口算一次完全来得及，而且能在文档里写上“基于广度优先搜索的路径规划”，这个表述在答辩时是有含金量的。

散射模式是幽灵每隔一段时间会切换到的另一种状态，目标是迷宫的某个固定角落，比如左上角、右上角、左下角、右下角，四个幽灵各分配一个角落。这样做的好处是，幽灵不会永远追着玩家跑，偶尔会散开再重新集结，游戏节奏更有呼吸感。如果只有追捕没有散射，你会发现幽灵经常叠在一起，玩家很难操作，体验很差。

还需要处理“死胡同掉头”的问题。如果幽灵在一条通道里和玩家相向而行，或者追捕目标正好在身后，角色需要允许掉头。经典做法是：幽灵在每个路口维护一个“可行方向”的集合，排除掉当前来的方向，除非所有方向都被堵住或者只剩回头路，否则绝不原路返回。这个逻辑很简单，但能明显提升AI的智商感。

4.2 吃豆人状态的4种切换

在游戏运行过程中，幽灵不是一直处于追捕状态的。核心的状态有四种：普通状态、被吓到状态（蓝脸）、即将恢复状态（闪烁）、被吃掉后的返回状态（只有眼睛）。这四种状态之间切换的触发条件要写清楚：

• 玩家吃到大力丸时，所有正常状态下的幽灵进入害怕状态，同时移动速度减慢，颜色变化。
• 害怕状态持续一段时间，快结束时闪烁提示，然后恢复成普通状态。
• 害怕状态下如果幽灵被玩家碰到，则进入回收状态，快速返回巢穴位置，返回后恢复普通状态。
• 如果玩家在害怕状态结束前没有碰到幽灵，幽灵直接恢复普通状态。

这四态看似不复杂，但在实现上建议不要写成一堆if嵌套，而是给幽灵类加一个state属性，再配合一个状态切换方法。状态不同，幽灵的目标、速度、颜色、碰撞结果都不同。比如普通状态下碰到玩家是玩家死亡，害怕状态下碰到玩家是幽灵被吃，这两个逻辑写反了，游戏就没法玩了。

害怕状态的计时也要处理好。每次吃大力丸都重新计时，而不是计时结束时间叠加到下一次。所以比较稳妥的做法是记录一个fear_time_remaining，每帧减去dt，小于等于0就恢复。同时，玩家可以由一个标志判断自己当前是否“正在吃幽灵”的动画期间，避免连续碰到两个幽灵时出现分数叠加错误。

4.3 评分、生命与关卡递进

游戏数值设计是很多同学忽略的地方，但其实很影响游戏性。正常豆子每颗10分，大力丸50分。吃掉害怕状态的幽灵，分数按照200、400、800、1600递增，也就是同一波大力丸有效期内，连续吃掉第1只、第2只、第3只、第4只幽灵的分数分别是200、400、800、1600。这个规则能很好地激励玩家尝试反打，而不是一直逃跑。

生命数初始给3条，碰到幽灵减一条，减到0则游戏结束。每吃掉一定数量的豆子可以奖励生命，这个可以用累计分数来判断，比如每10000分奖励一条生命。关卡的递进也不只是换图，更常见的方式是在原有地图上，提高幽灵的移动速度、缩短害怕状态的持续时间、减少幽灵在巢穴里的等待时间。我把这些参数全部用settings.py里的变量控制，每次换关时按关卡序号更新。

完成一关的判定有两种：豆子吃完，或者地图上所有可收集物品清空。注意，幽灵巢穴周边的一些空格不算豆子，所以统计总豆子数时，要在加载地图时就记录总数，然后实时用“剩余豆子数 == 0”来判断，不能凭地图字符再数一遍。

5. 打磨体验：界面、音效、打包发布

5.1 界面反馈与音效

一个好游戏不能只靠逻辑正确，反馈感是第一位的。玩家吃了豆子要有声音或视觉变化，碰到幽灵要有明显的“惊吓”效果，关卡结束要有胜利氛围。Pygame实现这些不复杂，但初始化mixer时特别容易出问题。

音效加载前必须先初始化pygame.mixer，如果直接在文件顶部pygame.mixer.init()之后再加载音频，排错会比较方便。音效文件建议用短促的wav格式，加载为Sound对象，播放的时候调用play()就行。背景音乐可以用Music对象，加载后play(-1)循环播放。如果播放声音出现延迟或杂音，多半是音频采样率不兼容，用格式工厂转换一下即可。

界面部分，除了得分和生命，还有一个容易被忽略的是“动画反馈”。比如玩家吃到豆子时，把当前格子的豆子位置播放一个小闪烁效果；玩家被幽灵碰到时，做一个短暂的死亡动画，再进入重生动画。动画不一定要用序列帧，简单的方案是控制角色精灵的可见性——比如死亡时每0.05秒切换一次是否绘制，看起来就像闪烁。这种小细节会明显提升演示效果，而且还是写论文时“游戏交互体验设计”这一节的好素材。

再提一个容易被毕设老师盯上的点：开始界面和结束界面不能省。很多同学上来就进游戏，没有标题界面，也没有“按任意键开始”的引导，显得不完整。结束界面至少要显示最终得分，最好还能显示本局吃掉的幽灵数量、使用的大力丸数量。这些统计数据写起来很简单，但在答辩时能作为“游戏数据统计”功能来讲，很加分。

5.2 打包成exe与部署展示

答辩现场不可能让评委先装Python再跑你的代码，所以交付物里一定要提供一个可以直接双击运行的exe。最常用的打包工具是PyInstaller，命令通常是：

pip install pyinstaller pyinstaller --onefile --windowed --name pacman main.py

--onefile表示打包成单个exe，--windowed表示运行时不弹出控制台窗口。但这里有一个经典坑：如果你的程序里用到了图片、音效、地图文件，默认打包方式不会把它们一起打进去，换一台电脑运行就会报“找不到文件”的错误。解决方案有两种：

一种是用--add-data参数显式把resources目录带进去，例如在Windows下执行：

pyinstaller --onefile --windowed --add-data "resources;resources" --name pacman main.py

另一种是在代码里写一个资源路径解析函数，判断当前是源码模式还是打包模式，然后分别指向不同的路径。这个函数可以这样写：

import sys, os def resource_path(relative): base = getattr(sys, "_MEIPASS", os.path.abspath(".")) return os.path.join(base, relative)

两种方式可以结合使用，核心思路是：exe运行时实际解压到一个临时目录，资源文件从那个目录读取。如果你直接打包后发现音效和图片都丢了，先检查这一步准没错。

6. 常见问题排查与答辩经验

6.1 运行异常与修复

做吃豆人项目时，有几类问题几乎人人都会遇到，我直接列成一张速查表，方便你对照排查：

调试的时候，我习惯随手写几个print输出关键变量的值，比如玩家坐标、当前状态、剩余豆子数。这些日志在状态切换的bug排查中比任何工具都直观。不过发布前记得把这些调试输出清理掉，否则在答辩现场看到控制台刷屏很尴尬。

6.2 答辩演示技巧与亮点提炼

很多同学代码写得挺好，答辩却讲得像流水账：先说需求，再贴类图，最后演示一遍，就没了。这样老师很难抓住重点。一定要主动把几个技术难点讲出来，每个难点都配上“你当时怎么解决”的故事。

比如，你可以说：“地图我用二维数组表示，因为这样方便修改和扩展；但删豆子如果依赖修改字符串，效率很低，所以我用集合记录豆子坐标，吃豆子是集合的删除操作，复杂度O(1)。”这一段话不仅讲到了数据结构，还讲到了性能优化意识。再比如幽灵AI，你可以说：“追捕模式使用的是基于曼哈顿距离的BFS寻路，散射模式则让幽灵搜索四个角，两种模式交替切换，让难度曲线平稳上升。”这就是答辩现场的“亮点输出”。

演示时我还有个建议：提前准备好一两个快捷键，比如按P直接暂停、按R直接重开，方便在老师要求看某个功能时快速操作。演示顺序上，先讲清楚操作，再展示正常通关，再专门展示结束界面和得分统计，最后讲解代码结构和设计思路。

如果时间允许，强烈建议加一个“双人模式”或“自定义地图上传”这种小扩展功能。不需要做得多复杂，哪怕只是让地图文件可以被玩家自己替换，也比单纯做一个原版复刻要多一个技术讨论点，查重时也更有辨识度。我是觉得，吃豆人这个题最有趣的地方就在于，它给了你一个足够经典的框架，但可以塞进去自己的想法。只要不是原封不动抄一个教程版本，答辩基本不会为难你。

最后再分享一个我做这类项目时的小习惯：不要等项目写完再写文档，而是在开发过程中同步记录“为什么这么设计”。这些记录以后会原封不动变成你需求文档和设计说明书里的素材。等答辩前三天再补文档，你会发现自己早就忘了当初为什么选这个方案。文档不是写给老师看的，是写给你自己的——它是你整个开发过程的思考痕迹。希望这个拆解能帮你少走点弯路，按着这个思路做完，你收获的绝不仅是一个能跑的游戏，而是一整套可以迁移到其他项目里的设计思维。