软件工程第二次个人作业
2026秋软件工程个人作业(二)——《一箭又一箭》游戏开发实践
| 项目内容 | 信息 |
|---|---|
| 这个作业属于哪个课程 | H202601软件工程与软件工程实践 |
| 这个作业要求在哪里 | 2026 秋软件工程个人作业(第二次) |
| 这个作业的目标 | 使用 Python 和 AIGC 完成“一箭又一箭”小游戏 |
| 学号 | 102401118 |
| GitHub 仓库 | Arrow_Puzzle_Game |
前言
这次软件工程个人作业的任务是使用 Python 和 AIGC 完成一个“一箭又一箭”小游戏。
本项目使用 Python + Pygame 开发,实现了箭头点击、路径阻挡判断、箭头飞出动画、错误次数、关卡切换、成功与失败状态、背景音乐以及碰撞视觉反馈等功能。
在开发过程中,我使用 ChatGPT 作为 AIGC 辅助开发工具,根据实际运行过程中遇到的问题不断提出新的需求,再结合程序运行结果进行修改和测试。
最终项目设置了 3 个关卡,并在程序启动时对关卡进行可解性检查,保证每个关卡至少存在一种能够完成游戏的操作顺序。
下面对本次项目的开发过程进行记录。
一、项目展示
1. 开始界面
游戏启动后首先进入开始界面。
开始界面主要用于展示游戏标题,并提供进入游戏的按钮。

2. 游戏主界面
进入游戏后,可以看到当前关卡、剩余箭头数量以及剩余错误次数等信息。
玩家需要观察每个箭头的方向,并判断箭头前方是否存在其他箭头。

3. 箭头飞出效果
如果箭头前方没有其他箭头阻挡,点击箭头后,箭头会沿着自己的方向飞出棋盘,并从游戏区域中消失。

箭头飞出后,棋盘中的箭头数量会相应减少。

4. 被阻挡时的反馈
如果点击的箭头前方存在其他箭头,那么该箭头无法飞出。
此时程序会给出明显的视觉反馈:被阻挡的箭头会变成红色,同时消耗一次错误机会。

这种反馈可以让玩家比较直观地知道本次操作没有成功。
5. 失败界面
当错误次数全部消耗后,游戏进入失败状态。

玩家可以重新开始游戏,重新挑战当前关卡。
6. 最终通关
当第三关中的所有箭头都被成功清除后,游戏完成全部关卡。

二、项目介绍
1. 游戏规则
《一箭又一箭》是一款基于 Python + Pygame 开发的箭头益智解谜游戏。
棋盘中的箭头共有 上、下、左、右 四个方向。
玩家需要观察箭头当前的方向,并判断箭头前方是否存在其他箭头。
- 如果前方没有箭头阻挡,点击后箭头会沿当前方向飞出棋盘;
- 如果前方存在其他箭头,则箭头无法飞出;
- 点击被阻挡的箭头会消耗一次错误机会,并产生红色视觉反馈;
- 当棋盘上的所有箭头都被成功清除后,即可完成当前关卡;
- 游戏共有 3 个关卡;
- 如果错误次数耗尽,则本次挑战失败。
游戏的核心就是寻找一个正确的箭头点击顺序。
2. 游戏界面
游戏主要由以下几个部分组成:
- 开始界面:进入游戏;
- 游戏界面:显示当前关卡、剩余箭头和错误次数;
- 棋盘区域:显示当前关卡中的所有箭头;
- 游戏操作区域:提供重新开始等操作;
- 成功界面:当前关卡完成后显示;
- 失败界面:错误次数耗尽后显示。
游戏过程中加入了背景音乐,使整体游戏体验更加完整。
3. 主要功能
目前项目实现了以下功能:
- 四方向箭头;
- 箭头路径阻挡检测;
- 箭头飞出动画;
- 被阻挡箭头红色反馈;
- 错误次数系统;
- 剩余箭头数量显示;
- 3 个游戏关卡;
- 关卡成功与失败状态;
- 游戏重新开始;
- 返回开始界面;
- 背景音乐;
- 游戏启动时进行关卡可解性检查。
4. 项目运行环境
本项目开发环境:
- 操作系统:macOS
- Python:3.12.14
- Pygame:2.6.1
- 开发工具:Visual Studio Code / Terminal
- 版本管理:Git + GitHub
项目依赖保存在 requirements.txt 中。
安装依赖:
pip install -r requirements.txt
运行游戏:
python main.py
5. 项目文件结构
项目目前主要文件结构如下:
Arrow_Puzzle_Game/
├── .gitignore
├── main.py
├── requirements.txt
├── README.md
├── assets/
│ └── background_music.wav
├── screenshots/
│ ├── 01_start.png
│ ├── 02_level1.png
│ ├── 03_fail.png
│ ├── 04_blocked_red.png
│ ├── 05_level3_success.png
│ ├── 06_arrow_fly.png
│ └── 07_arrow_fly2.png
└── venv/
其中 venv/ 是本地 Python 虚拟环境,通过 .gitignore 排除,没有上传到 GitHub。
三、实现思路
1. 箭头数据表示
游戏中的每一个箭头都记录了自己的位置和方向。
一个箭头可以抽象表示为:
{
"row": 2,
"col": 3,
"direction": "RIGHT"
}
其中:
row:箭头所在的行;col:箭头所在的列;direction:箭头方向。
方向主要包括:
UP
DOWN
LEFT
RIGHT
所有箭头数据统一进行管理,程序根据这些数据完成棋盘绘制、鼠标点击检测和路径判断。
2. 路径阻挡检测
路径检测是整个游戏最核心的逻辑。
当玩家点击一个箭头时,程序首先判断该箭头前方是否存在其他箭头。
例如:
向右
如果箭头方向为 RIGHT,则检查:
other_row == row and other_col > col
如果满足条件,则说明当前箭头右侧存在其他箭头,因此当前箭头被阻挡。
向左
other_row == row and other_col < col
向上
other_col == col and other_row < row
向下
other_col == col and other_row > row
如果对应方向没有其他箭头,则当前箭头可以飞出。
因此整个判断过程可以概括为:
根据箭头方向,在同一行或同一列中检查箭头前方是否存在其他箭头。
3. 箭头飞出
当程序判断当前箭头没有被阻挡后,就会启动箭头的飞出动画。
箭头沿自己的方向不断移动,直到离开棋盘区域。
飞出完成后,从当前箭头列表中删除该箭头,同时更新剩余箭头数量。
这样就形成了:
点击箭头
↓
检查前方是否有阻挡
↓
/ \
有阻挡 无阻挡
↓ ↓
红色反馈 飞出动画
↓ ↓
错误次数-1 箭头消失
↓
数量减少
4. 错误反馈
如果玩家点击了一个被阻挡的箭头:
- 箭头不会飞出;
- 箭头产生红色视觉反馈;
- 错误次数减少;
- 如果错误次数耗尽,则进入失败状态。
这种处理能够让玩家快速理解自己的操作为什么没有成功。
5. 关卡设计与可解性检查
本项目设置了 3 个关卡。
在开发过程中,我特别考虑了一个问题:
如果关卡设计出现无解情况,玩家即使操作正确也无法通关。
因此在游戏启动时,程序会对每个关卡进行可解性检查。
程序会模拟不同的箭头消除顺序,并搜索是否存在可以将全部箭头清除的方案。
实际运行时可以看到:
========== 关卡可解性检查 ==========
第 1 关:√ 存在通关方式 (搜索到 6 步完整方案)
第 2 关:√ 存在通关方式 (搜索到 6 步完整方案)
第 3 关:√ 存在通关方式 (搜索到 6 步完整方案)
==================================
三个关卡均通过检查。
这样可以避免因为关卡本身无解而导致玩家无法完成游戏的问题。
四、AIGC 使用过程
1. AIGC 使用说明
本项目开发过程中主要使用 ChatGPT 作为 AIGC 辅助开发工具。
AIGC 并不是在游戏全部完成之后一次性生成代码,而是参与了实际开发过程中的多个具体子任务。每次遇到新的功能需求或程序问题时,我都会先向 ChatGPT 描述具体需求,再将生成的代码放入项目中运行,根据实际运行结果继续修改。
本次开发中比较有代表性的三次 AIGC 使用过程如下:
| 子任务 | 借助何种 AIGC 技术 | AI 实现或提供了什么 | 效果如何 | 人工修改 |
|---|---|---|---|---|
| 路径检测 | ChatGPT | 根据四个箭头方向生成路径阻挡判断逻辑,并帮助分析箭头前方是否存在其他箭头 | 基本实现了四个方向的阻挡检测,但需要结合实际棋盘数据进行调整 | 根据实际关卡布局修改边界判断和箭头位置处理 |
| 碰撞反馈 | ChatGPT | 根据测试结果修改被阻挡箭头的处理逻辑,增加红色视觉反馈和错误次数扣除 | 被阻挡的箭头能够变红,错误次数能够正常减少 | 根据实际运行效果调整反馈显示和交互表现 |
| 关卡设计与可解性 | ChatGPT | 提供关卡可解性检查思路,并生成搜索不同箭头消除顺序的检测逻辑 | 程序可以在启动时检查三个关卡是否存在通关方案 | 将可解性检查整合进最终程序,并实际测试三个关卡 |
2. AIGC 交互截图



3. AIGC 使用总结
通过以上三次实际开发过程,我发现 AIGC 对代码开发比较有帮助,尤其适合用于:
- 分析具体功能需求;
- 提供代码实现思路;
- 排查程序运行问题;
- 修改已有功能;
- 设计测试方法。
但是 AI 生成的代码并不能直接代替人工开发。
在实际过程中,我仍然需要:
- 根据作业要求提出具体需求;
- 判断 AI 提供的方案是否符合游戏规则;
- 将代码放入项目中运行;
- 根据运行结果发现问题;
- 对代码进行人工修改;
- 最后通过实际测试确认功能。
因此,本项目的开发方式可以概括为:
AIGC 辅助实现 → 实际运行测试 → 发现问题 → 人工修改 → 再次测试。
AIGC 在本项目中主要承担的是辅助开发和问题分析的角色,最终代码仍然经过了实际运行和人工调整。
五、功能测试
在完成主要功能后,对游戏进行了实际测试。
| 测试编号 | 测试项目 | 预期结果 | 实际结果 | 是否通过 |
|---|---|---|---|---|
| T01 | 点击未被阻挡的箭头 | 箭头沿当前方向飞出并从棋盘中消失 | 箭头正常播放飞行动画并消失 | 通过 |
| T02 | 点击被阻挡的箭头 | 箭头无法飞出,出现错误反馈并扣除一次错误次数 | 箭头变红,错误次数减少 1 | 通过 |
| T03 | 点击边缘且方向朝向棋盘外的箭头 | 箭头正常消失,不出现越界错误 | 箭头正常飞出并消失 | 通过 |
| T04 | 清空当前关卡所有箭头 | 当前关卡完成并进入成功状态 | 成功进入下一阶段 | 通过 |
| T05 | 错误次数全部耗尽 | 游戏进入失败状态,可以重新开始 | 错误次数耗尽后进入失败界面 | 通过 |
| T06 | 游戏过程中点击重新开始 | 当前关卡重新初始化,布局和错误次数恢复 | 关卡重新加载,错误次数恢复 | 通过 |
测试结果可返回文章开头<项目展示>查看。
测试总结
经过实际测试,游戏的箭头点击、路径阻挡检测、箭头飞出、错误次数、关卡切换、失败状态以及重新开始等核心功能均能够正常运行。
三个关卡也通过了程序启动时的可解性检查。
目前游戏已经能够完成完整的:
开始游戏
↓
选择正确箭头
↓
箭头飞出
↓
清空当前关卡
↓
进入下一关
↓
完成第三关
同时也能够处理错误操作和失败情况。
六、PSP 表格
| 任务 | 预计耗时(小时) | 实际耗时(小时) | 差异(小时) |
|---|---|---|---|
| 需求分析与游戏设计 | 1 | 1 | 0 |
| Python 与 Pygame 学习 | 2 | 2 | 0 |
| 游戏基础功能实现 | 3 | 4 | +1 |
| 箭头路径与碰撞逻辑 | 2 | 2 | 0 |
| 关卡设计与可解性检查 | 1 | 2 | +1 |
| AIGC 辅助开发 | 2 | 2 | 0 |
| 测试与问题修改 | 2 | 3 | +1 |
| README 与博客撰写 | 2 | 3 | +1 |
| 合计 | 15 | 19 | +4 |
从 PSP 表格可以看出,本次项目实际耗时比最初预计时间更长。
其中主要增加时间的是游戏功能修改、关卡测试以及博客整理。
在实际开发过程中,经常会出现“代码能够运行,但是实际效果还需要调整”的情况,因此后续进行项目时间估算时,需要给测试、调试和修改预留更多时间。
七、GitHub 版本管理
本项目使用 Git 进行版本管理,并将项目上传到了 GitHub。
GitHub 仓库:
项目目前具有多次有意义的提交记录,而不是只保留最终版本。
主要提交记录如下:
9ae3f7e docs: 添加游戏运行截图
5ad0689 docs: 完善项目说明文档
9eb260 docs: 完善项目 README
6a2668d feat: 完成游戏基础版本
通过 Git 进行版本管理,可以记录项目从基础版本到最终版本的开发过程,也方便后续继续修改和维护。
八、心得体会
这次作业让我第一次比较完整地经历了一个小型软件项目从需求分析、编码、测试到文档整理和版本管理的过程。
刚开始的时候,我主要关注的是如何让游戏能够运行起来。但在实际开发过程中发现,“能运行”和“做好一个游戏”还是有很大区别的。
例如,箭头能够移动只是最基础的功能,还需要考虑:
- 箭头是否真的按照自己的方向飞出;
- 被阻挡时应该如何反馈;
- 错误次数如何处理;
- 关卡是否存在无解情况;
- 游戏失败后如何重新开始;
- 背景音乐是否能够正常播放;
- 不同游戏状态之间如何切换。
这些问题都是在实际运行和测试过程中逐渐发现并修改的。
在这次项目中,AIGC 对我的帮助比较大。很多代码实现和问题排查都可以先让 AI 提供思路,再结合自己的项目进行修改。
但是经过这次开发,我也发现 AI 生成的代码并不是拿过来就可以直接使用。实际运行时经常需要继续修改,有些代码还需要根据自己的项目结构重新整合。
因此,我认为比较合适的开发方式并不是完全依赖 AI,而是:
自己提出需求和判断问题,使用 AIGC 辅助实现,再通过运行测试验证结果,最后由自己完成修改。
另外,这次作业也让我实际使用了 Git 和 GitHub。
以前对 Git 的理解比较停留在基本命令层面,这次真正将项目进行多次 commit 并上传到 GitHub 后,对版本管理的作用有了更加直观的认识。
总体来说,这次作业虽然只是一个小型 Pygame 游戏,但完整经历了需求、设计、开发、测试、版本管理和文档整理几个阶段,让我对软件工程开发流程有了更加具体的认识。
九、项目总结
本项目最终完成了一个基于 Python + Pygame 的“一箭又一箭”小游戏,实现了:
- 开始界面;
- 四方向箭头;
- 箭头路径阻挡判断;
- 箭头飞出动画;
- 阻挡红色反馈;
- 错误次数;
- 3 个可通关关卡;
- 关卡可解性检查;
- 成功与失败状态;
- 游戏重新开始;
- 背景音乐;
- Git + GitHub 版本管理;
- README 和项目运行截图。
项目源码及相关资源已经上传至 GitHub:
https://github.com/209691048/Arrow_Puzzle_Game
本次作业也让我认识到,一个完整的软件项目不仅仅是把代码写出来,还需要进行测试、修改、版本管理以及文档整理。
这也是我通过这次“一箭又一箭”小游戏开发得到的最大收获。

浙公网安备 33010602011771号