软件工程第二次作业

软件工程第二次个人作业：利用 AIGC 完成“一箭又一箭”小游戏

项目	内容
这个作业属于哪个课程	202601 SoftwareEngineering 课程
这个作业要求在哪里	第二次个人作业
这个作业的目标	使用 Python 和 AIGC 完成“一箭又一箭”小游戏
学号	102402118
GitHub 仓库	https://github.com/Feion-Chen/2601-fzu-SoftwareEngineering-YuezhongWu

1. 项目展示

开始界面：

游戏过程：

通关界面：

第二关通关：

全部关卡完成：

失败界面：

2. 项目介绍

“一箭又一箭”是一个点击式箭头解谜游戏。棋盘上放置若干方向不同的箭头，玩家需要按照合理顺序点击它们。只有箭头前进方向到棋盘边界之间没有其他箭头时，它才能飞出并消失。若路径中存在阻挡，箭头保持不动并消耗一次失误机会。清空棋盘即可通关。

主要功能

• 开始界面、游戏界面、通关界面和失败界面；
• 上、下、左、右四种方向的箭头；
• 基于逐格扫描的路径阻挡判断；
• 箭头飞出缓动动画和受阻抖动、变色反馈；
• 失误次数、剩余箭头、用时和点击次数显示；
• 三个经过自动求解器验证的关卡；
• 重新开始、进入下一关、返回首页；
• 提示、撤销、快捷键和关卡自选附加功能。

界面设计

界面使用圆角卡片、深浅对比和方向颜色区分四种箭头。棋盘使用深浅交替的格子，边缘带有飞出方向提示。右侧状态栏集中显示进度和操作按钮，减少游戏区与信息区的互相干扰。

3. 实现思路

3.1 数据表示

每个箭头使用一个不可变对象表示，包含：

• row：所在行；
• col：所在列；
• direction：U、D、L、R 中一个方向。

棋盘状态保存当前箭头集合、失误次数、最大失误次数和游戏状态。历史记录用于实现撤销。

3.2 路径检测

玩家点击箭头后，程序根据方向取得行、列的增量，从箭头前方相邻格开始逐格检查：

当前格 = 箭头位置 + 单步方向
while 当前格仍在棋盘内：
    如果当前格有箭头：
        返回阻挡
    当前格 = 当前格 + 单步方向
返回可以飞出

这种写法把四个方向统一为 (行增量, 列增量)，不需要为四个方向分别写四段容易出错的边界判断。当前格一旦离开棋盘就结束循环，因此边缘箭头不会发生索引越界。

3.3 关卡和可解性

第一关为 5×5，共 8 个箭头，重点帮助玩家理解基础规则。第二关为 6×7，共 11 个箭头，横竖路线开始互相牵制。第三关为 7×7，共 18 个箭头，包含多条横向和纵向链条。

为了避免设计出无解关卡，项目额外实现了回溯求解器。求解器把当前箭头集合作为状态，尝试所有当前可飞出的箭头；一旦后续状态无法继续，就回退并尝试其他分支。测试会检查三个关卡均能返回完整通关顺序，并按照顺序实际执行消除操作。

3.4 界面与动画

界面使用 Python 标准库 Tkinter 的 Canvas 绘制。游戏以约 30 毫秒为间隔刷新，箭头飞出时使用 1 - (1 - t)^3 的缓出函数计算位置；发生碰撞时根据剩余时间生成正弦抖动，并把箭头颜色临时切换为红色。这样不需要外部素材，也能满足基本动画和视觉反馈要求。

游戏逻辑和图形界面分离：core.py 不导入 Tkinter，因此可以独立运行自动化测试；app.py 只负责读取状态、处理事件和绘制结果。

4. AIGC 使用过程

子任务	借助何种 AIGC 技术	向 AI 提出了什么	AI 实现或提供了什么	实际效果	人工修改
需求分析与结构设计	Codex	拆解作业要求，优先使用标准库，并让规则与界面分离	设计 core.py、levels.py、app.py、tests/ 的结构	核心逻辑可独立测试	已检查代码结构，无需修改
路径检测与边界处理	Codex	统一处理上下左右方向，避免边缘越界	使用方向增量逐格扫描，返回第一个阻挡箭头	T01-T03 测试通过	已试玩并核对边界表现，无需修改
关卡设计与验证	Codex	设计至少 3 个真正可通关的关卡	提供三个关卡数据，并实现回溯求解器验证通关顺序	三个关卡都能完整清空	已按关卡顺序实际通关，未调整关卡
界面与反馈动画	Codex	使用 Tkinter 完成四个界面、飞出与碰撞反馈	使用 Canvas 绘制并实现缓动、抖动、变色、提示	界面可正常操作并生成截图	已实际运行并截图，无需修改
自动化测试	Codex	按作业 T01-T06 编写测试，并覆盖关卡可解性	编写 8 项 unittest 测试	全部通过	已运行测试，8 项全部通过

5. 测试结果

测试命令：

python -m unittest discover -s tests -v

编号	测试内容	预期结果	实际结果	是否通过
T01	点击前方无阻挡的箭头	箭头飞出棋盘并消失	返回 FLY，箭头数减少	是
T02	点击前方有阻挡的箭头	箭头不消失，失误次数减 1	返回 BLOCKED，失误次数增加	是
T03	点击边缘朝外箭头	正常消失，无越界错误	正常返回 FLY	是
T04	消除本关全部箭头	显示通关并进入下一关	状态变为 WON	是
T05	失误次数耗尽	显示失败并允许重新开始	状态变为 LOST	是
T06	游戏过程中重新开始	布局和失误次数恢复	快照与初始状态一致	是

补充测试中，第一关、第二关和第三关分别有 8、11、18 个箭头，均通过求解器找到完整通关顺序。

6. PSP 表格

任务	预估耗时（小时）	参考实际耗时（小时）	差异（小时）
需求分析与游戏设计	1.0	0.5	-0.5
Python 与图形库学习	1.0	0.5	-0.5
游戏界面实现	2.0	1.0	-1.0
路径与碰撞逻辑实现	1.5	0.5	-1.0
关卡设计	1.0	0.5	-0.5
AIGC 辅助开发	1.5	1.0	-0.5
测试与修改	1.0	0.5	-0.5
README 与博客撰写	1.5	0.5	-1.0
合计	10.5	5.0	-5.5

上述实际耗时根据本次开发与测试过程记录整理。

7. 心得与总结

这次作业让我体会到，AIGC 可以很快生成程序初稿，但“代码能生成”并不等于“项目已经完成”。路径检测虽然规则简单，真正实现时仍要仔细考虑四个方向、边界条件和被阻挡后的状态变化；关卡设计也不能只凭肉眼判断，需要求解器或实际试玩验证。

把规则逻辑与界面分离是本次实现中比较重要的决定。它让自动化测试可以直接操作游戏状态，不需要启动窗口，也让界面出现问题时更容易定位是绘制问题还是规则问题。提示、撤销和求解器虽然是附加功能，但它们也帮助验证了核心状态模型是否清晰。

AIGC 适合辅助拆解需求、生成重复代码和补充测试，但最终仍应由提交者理解关键逻辑、实际运行、检查结果并对代码负责。本次作业中，我实际完成了三个关卡的试玩，并对通关截图、测试结果和博客内容进行了核对。AIGC 提高了开发效率，但对规则、边界、关卡可解性和最终效果的判断仍需要人工完成。