🚀Nova的软件工程冒险：从“一支箭”到“一片星海”
📌 作业信息
| 项目内容 | 内容 |
|---|---|
| 这个作业属于哪个课程 | H202601软件工程与软件工程实践 |
| 这个作业要求在哪里 | 2026 秋软件工程个人作业（第二次） |
| 这个作业的目标 | 使用 Python 和 AIGC 完成“一箭又一箭”小游戏 |
| 学号 | 102402102 |
| GitHub 仓库 | NovaArrowAdventure |
任务加载中……
🎯 主线任务：利用 AIGC 完成“一箭又一箭”小游戏
🧑💻 玩家：Nova
🗺️ 当前地图：Python / Pygame / GitHub / AIGC / 软件测试
🏹 初始装备：几支箭、一个棋盘，以及“应该不难吧”的错觉
⭐ 最终目标：完成一个真正能够运行、能够通关、也能够讲明白的小游戏第二章冒险，正式开始！
🌟 序章：上次刚走出新手村，这次直接发射火箭
大家好，我是 Nova。🌟
上一次的软件工程冒险，我还在新手村里研究地图；这一次，老师直接塞给我一张宇宙船票：用 Python 做一个“一箭又一箭”小游戏，而且还要让 AIGC 成为我的开发搭档。
于是，一支普普通通的箭头经历了四次 GitHub 提交，逐渐变成火箭；一张朴素的棋盘也一路冲出大气层，最终变成了一场拥有 7 个关卡、飞行动画、碰撞反馈、音效、提示、计时、暂停、最佳纪录和终章动画 的像素风太空冒险。🚀
上一篇博客的结尾，我写下了：
下一张地图，加载中……
没想到下一张地图真的加载出来了，而且这一次，地图已经不在地面上。
🎮 Nova 软件工程冒险·第二章
【起点】
│
↓
第一关：理解规则
│
↓
第二关：基础原型
│
↓
第三关：太空换装
│
↓
第四关：代码重构
│
↓
第五关：AIGC协作
│
↓
👑 Boss战：测试与Debug
│
↓
🏆 第二章通关！
这篇博客记录的不是“AI 按一下按钮，项目自动出现”的童话，而是我和 GPT / Codex、豆包、DeepSeek 一边讨论、一边运行、一边发现问题，再一点点修正的真实开发过程。
🎮 第一关：任务说明——欢迎登上 Nova 号
🎯 本关任务
老师交给我的核心任务可以翻译成一句话：
观察方向，判断前方有没有其他箭头；没阻挡就飞，有阻挡就接受碰撞教育。
听起来很简单。
而根据软件工程作业的传统，“听起来很简单”通常意味着：后面还藏着界面、动画、状态、关卡、测试、README、GitHub 和博客。🙂
在解释代码之前，先看看 Nova 号最终长什么样。
1. 开始界面
开始界面采用像素风太空主题。第一次进入游戏时显示“开始探索”；开始过游戏后，可以选择“重新探索”或“继续探索”。背景中的星星、流星、行星和宇航员让整个界面不再像一份“刚学 Pygame 三天”的实验作业。😎
2. 游戏界面
左侧是 7×7 棋盘，火箭代替传统箭头，火箭朝向就是移动方向；右侧信息面板显示当前关卡、关卡故事、剩余火箭、剩余失误次数、用时和最佳纪录。底部提供重新开始、暂停、提示和声音开关。
3. 碰撞与失败界面
如果火箭前方还有其他火箭，它会先冲过去“试图硬闯”，随后发生碰撞并返回，同时扣除一次失误机会。三次机会全部用完后进入失败界面，可以重新挑战当前关卡或返回主页。
4. 通关与终章
清空当前关卡后会弹出关卡总结，显示本次用时、最佳纪录和剩余星星。通关第七关后还会播放终章动画——毕竟辛苦飞到新星港湾，总不能只弹出一句冷冰冰的 You Win。✨
🕹️ 第二关：理解游戏规则——手不一定听脑子的话
游戏核心规则如下：
- 棋盘上的每枚火箭只有上、下、左、右四种朝向；
- 点击火箭后，程序沿它的朝向检查同一行或同一列；
- 如果前方没有其他火箭，它就会飞出棋盘并消失；
- 如果前方存在阻挡，它不能被消除，并触发碰撞动画和音效；
- 每次错误点击会损失一颗星，三颗星全部失去则挑战失败；
- 清空棋盘上的全部火箭即可完成当前关卡；
- 游戏共 7 关，火箭数量从 4 枚逐步增加到 16 枚，难度循序渐进。
基础规则只有一句话：“前面没人就飞，有人就别莽。”但真正写进程序后，它涉及坐标换算、方向扫描、动画状态、鼠标事件、关卡切换和数据保存。看起来是一支箭，背后却站着一整支开发小队。😂
🌟 项目特色
- 太空叙事关卡： 从“地面点火台”一路飞到“新星港湾”；
- 像素风视觉： 所有火箭、星星、行星和装饰主要由 Pygame 图形接口绘制；
- 7 个可通关关卡： 每关均设置合理的消除顺序；
- 基础动画反馈： 包括飞出、拖尾、碰撞、爆炸和星星破碎；
- 实用辅助功能： 提示、暂停、重开、继续探索和音效开关；
- 计时与纪录： 保存每关最后用时和最佳成绩；
- 纯 Python 合成音效： 不依赖外部商业音频素材；
- 模块化结构： 最终版本拆分为配置、音频、主页、游戏和主循环 5 个模块。
🧭 第三关：四次 GitHub 提交——一支箭的进化史
这次我没有在截止日期前上演“一次 Commit 包打天下”，而是把项目按功能成长拆成了四个阶段。每一次提交都能看出项目比上一版多学会了什么。
3.1 第一次提交：先让箭头真的飞起来
第一版使用单文件 main1.py，窗口大小为 900×700，棋盘为 5×5，并设计了 3 个基础关卡。这个阶段优先完成评分标准中的核心要求：
- 开始、游戏、成功和失败状态；
- 鼠标点击与网格坐标换算；
- 上、下、左、右四个方向；
- 路径阻挡判断；
- 飞出动画与碰撞返回；
- 3 次失误机会；
- 3 个可通关关卡与重新开始。
这一版界面还比较朴素，但它非常重要：只有核心规则可靠，后面的宇宙皮肤才不是“会闪光的 Bug”。
3.2 第二次提交：箭头换装火箭，地图扩大到宇宙
第二版 main2.py 将棋盘扩大到 7×7，把普通箭头绘制成不同颜色的火箭，并将关卡扩展到 7 关。同时加入：
- 不同关卡的太空背景和剧情名称；
- 火箭喷焰、拖尾和爆炸粒子；
- 暂停与提示功能；
- 单关计时和最佳时间显示；
- 更可靠的跨平台中文字体回退；
- 更完整的通关流程。
从这一版开始，项目不再只是“满足要求”，而是有了自己的主题。火箭每升一关，背景也从地面逐渐过渡到深空，玩家的操作被串成了一段完整旅程。
3.3 第三次提交：让宇宙不再静音
第三版 main3.py 加入了音效系统和更精细的交互反馈。程序使用 array 和正弦波、噪声实时合成声音，包括：
- 火箭发射音；
- 碰撞爆炸音；
- 星星损失音；
- 按钮点击音；
- 通关与失败提示音；
- 游戏内声音开关；
- 按钮按下、回弹和悬停反馈；
- 更完整的开始界面与通关弹窗。
我还对发射音进行了降音高、削弱高频和包络平滑，避免玩家点击一次火箭，耳机先替火箭“爆炸”。🎧
3.4 第四次提交：从“能运行”走向“像项目”
最终版本没有继续把所有内容堆进一个越来越长的文件，而是拆分成 5 个模块：
| 文件 | 主要职责 |
|---|---|
main.py |
主循环、事件分发、游戏状态切换 |
config.py |
窗口、颜色、字体、公共绘制与按钮配置 |
audio_system.py |
音效合成、播放与声音开关 |
home_screen.py |
开始界面、继续探索与最终章动画 |
game_screen.py |
关卡数据、路径判断、动画、计时与纪录 |
最终版还加入了本地 JSON 纪录保存、继续探索、当前关卡重开、从第一关重开、最终关终章动画等功能。主循环只负责“什么时候做什么”，各模块负责“具体怎么做”，代码结构终于从“一间堆满纸箱的宿舍”变成了“贴好标签的实验室”。🧪
3.5 四次版本对比
| 能力 | 第一次 | 第二次 | 第三次 | 最终版 |
|---|---|---|---|---|
| 基础路径检测 | ✅ | ✅ | ✅ | ✅ |
| 关卡数量 | 3 | 7 | 7 | 7 |
| 太空像素主题 | － | ✅ | ✅ | ✅ |
| 暂停 / 提示 / 计时 | － | ✅ | ✅ | ✅ |
| 程序合成音效 | － | － | ✅ | ✅ |
| 模块化结构 | － | － | － | ✅ |
| 最佳纪录持久化 | － | － | － | ✅ |
| 继续探索 / 终章动画 | － | － | 部分 | ✅ |
🧠 第四关：核心代码迷宫——火箭怎么知道前面有人？
4.1 关卡与火箭的数据表示
每枚火箭用一个三元组表示：
(row, col, direction)
例如：
(1, 2, "right")
表示火箭位于第 1 行、第 2 列，方向朝右。关卡则是多个火箭三元组组成的列表。加载关卡时，我再加入颜色编号，变成：
[row, col, direction, color_index]
这种设计把关卡数据与绘制逻辑分开：以后修改布局时只需要改坐标，不必去碰动画代码。
4.2 鼠标坐标如何变成网格坐标
鼠标点击得到的是屏幕像素坐标，而路径判断需要行列坐标，因此要减去棋盘左上角偏移量，再除以单元格大小：
col = (mouse_x - BOARD_X) // CELL_SIZE
row = (mouse_y - BOARD_Y) // CELL_SIZE
clicked = find_arrow(row, col)
只有点击位置处确实存在火箭时，程序才继续处理。这样点击空白格不会误伤任何无辜火箭。🫡
4.3 核心路径检测
路径检测的关键不是计算复杂几何碰撞，而是根据方向沿同一行或同一列逐格扫描。例如向上时，从当前行的上一格开始，一直检查到第 0 行：
def get_blocking_arrow(arrow):
row, col, direction = arrow[:3]
if direction == "up":
for r in range(row - 1, -1, -1):
target = find_arrow(r, col)
if target:
return target
elif direction == "down":
for r in range(row + 1, GRID_SIZE):
target = find_arrow(r, col)
if target:
return target
elif direction == "left":
for c in range(col - 1, -1, -1):
target = find_arrow(row, c)
if target:
return target
elif direction == "right":
for c in range(col + 1, GRID_SIZE):
target = find_arrow(row, c)
if target:
return target
return None
返回值有两种：
None：前方没有阻挡，可以启动飞出动画；- 某个火箭对象：找到了最近阻挡物，启动碰撞动画。
四个方向看起来很像，但上下改变的是行，左右改变的是列；向上和向左还需要使用负步长。这里也是最容易出现边界写反或漏掉第 0 行 / 第 0 列的地方。
4.4 为什么阻挡的火箭要暂时移出列表
点击后，火箭会先从静态火箭列表移除，再交给动画系统绘制：
if blocker is None:
arrows.remove(clicked)
start_fly_animation(clicked)
else:
arrows.remove(clicked)
start_collision_animation(clicked, blocker)
如果成功飞出，动画结束后它就真正消失；如果发生碰撞，动画系统会在返回原位后把火箭重新加入列表，同时扣除一次机会。这样不会出现同一枚火箭被“静态图层”和“动画图层”同时画两次的分身术。
4.5 游戏状态管理
主程序使用状态变量控制不同界面：
start → game → level_complete → game
↕
pause
↓
fail
最终关完成后还会经过 ending 状态播放终章，再进入最终总结界面。事件处理、逻辑更新和界面绘制都根据当前状态执行，避免开始界面的按钮突然跑到游戏中抢戏。
4.6 最佳纪录如何保存
最终版把每关的 best、last 和 runs 保存为 JSON，并采用“先写临时文件，再替换正式文件”的方式：
temporary.write_text(json.dumps(data, ensure_ascii=False, indent=2),
encoding="utf-8")
temporary.replace(RECORDS_SAVE_PATH)
这种做法比直接覆盖更稳妥。即使写入过程中意外中断，也能降低原纪录文件被写坏的风险。
🤖 第五关：召集 AIGC 队友——AI 是副驾驶，不是自动驾驶
本次开发使用了 GPT / Codex、豆包和 DeepSeek。我把它们当成三个不同风格的队友：GPT / Codex 更适合代码实现与调试，豆包帮助发散主题与界面想法，DeepSeek帮助梳理功能结构和实现步骤。最终代码仍由我运行、比较、修改和负责。
5.1 第一次协作：实现四方向路径检测
| 项目 | 记录 |
|---|---|
| 使用工具 | GPT / Codex |
| 我提出的要求 | 根据单格箭头规则，设计上、下、左、右四个方向的阻挡检测，并处理棋盘边缘 |
| AI 提供的内容 | 使用行列扫描实现 get_blocking_arrow()，并建议将查找单元格火箭封装为 find_arrow() |
| 实际效果 | 基本规则可以工作，但我重点检查了向上、向左时的负步长和第 0 行 / 列边界 |
| 我的修改 | 统一四个分支的返回方式，并通过边缘火箭与多火箭同行 / 同列场景验证 |
这次我学到：AI 写出四个 for 循环不难，难的是我必须知道为什么向上的范围是 range(row - 1, -1, -1)。助教要是问到这里，我至少不会回答：“因为 AI 当时心情不错。”😅
5.2 第二次协作：把小游戏设计成太空冒险
| 项目 | 记录 |
|---|---|
| 使用工具 | 豆包 |
| 我提出的要求 | 帮我把普通箭头消除游戏包装成统一的主题，并给出界面、关卡命名和视觉反馈建议 |
| AI 提供的内容 | 提出“箭头变火箭、关卡代表航天旅程”的思路，以及星空、行星、喷焰、拖尾等视觉元素 |
| 实际效果 | 主题与玩法非常契合，火箭方向天然对应箭头方向，七关也有了连续故事 |
| 我的修改 | 结合 Pygame 能力筛选方案，没有使用外部商业素材，而是用基础图形绘制像素风元素 |
这一步对我的帮助不只是“变好看”，而是让我理解了设计统一性：主题、关卡名、按钮文案、背景变化和音效都应该服务于同一段体验。
5.3 第三次协作：梳理功能结构与开发顺序
| 项目 | 记录 |
|---|---|
| 使用工具 | DeepSeek |
| 我提出的要求 | 根据作业评分点拆解功能，规划从基础版到完整版本的开发顺序 |
| AI 提供的内容 | 将任务归纳为核心逻辑、界面状态、关卡流程、反馈动画、测试与文档几个部分 |
| 实际效果 | 避免一开始就沉迷粒子特效，先确保路径检测、失败与通关流程完整 |
| 我的修改 | 将计划进一步拆为四次 GitHub 提交，并让每次提交都形成可以运行的阶段版本 |
这次最大的收获是：需求分析不是把作业说明复制进待办列表，而是识别“必须先做什么”。如果路径检测还没写对，就先做一个会旋转的银河，银河也救不了分数。🌌
5.4 第四次协作：从单文件重构为五个模块
| 项目 | 记录 |
|---|---|
| 使用工具 | GPT / Codex |
| 我提出的要求 | 单文件已经超过两千行，希望按职责拆分，同时保持现有功能不变 |
| AI 提供的内容 | 建议划分 config、audio_system、home_screen、game_screen 和 main，通过状态信号连接主循环与游戏模块 |
| 实际效果 | 主程序的事件循环更清楚，各模块职责更集中，后续修改界面或音效不必翻遍整个文件 |
| 我的修改 | 手动检查模块之间的共享状态、按钮坐标、关卡切换和音效调用，修正拆分后的引用关系 |
5.5 第五次协作：验证七个关卡是否真的可解
| 项目 | 记录 |
|---|---|
| 使用工具 | Codex 辅助编写验证脚本 |
| 我提出的要求 | 不只看关卡“像是能过”，而是按同样的阻挡规则检查每关能否清空 |
| AI 提供的内容 | 编写小型求解脚本，每一步寻找当前无阻挡火箭并模拟移除 |
| 实际效果 | 最终 7 个关卡全部找到完整通关序列，火箭数依次为 4、6、8、10、12、14、16 |
| 我的修改 | 对照游戏规则检查脚本判断条件，并保留实际试玩作为最终确认手段 |
小结：AIGC 能快速给出方案，但“能生成”不等于“能提交”。我仍然需要读懂边界条件、运行程序、验证关卡、比较版本，并决定哪些建议适合这个项目。
👑 Boss战：测试与 Debug——别让火箭带着 Bug 上天
我采用了“静态检查 + 规则验证 + 手工界面测试”的方式。提交前，最终 5 个 Python 文件通过了 py_compile 语法检查；同时使用与游戏一致的同行 / 同列阻挡规则验证 7 个关卡，均能找到完整消除顺序。
6.1 基础功能测试
| 编号 | 测试内容 | 预期结果 | 实际结果 | 是否通过 |
|---|---|---|---|---|
| T01 | 点击前方无阻挡的火箭 | 火箭飞出棋盘并消失 | 播放飞出与拖尾动画，火箭从列表移除 | ✅ |
| T02 | 点击前方有阻挡的火箭 | 火箭不消失，失误次数减 1 | 火箭移动至阻挡物附近后返回，并损失一颗星 | ✅ |
| T03 | 点击边缘且朝向棋盘外的火箭 | 正常消失，不出现越界错误 | 四个方向均能正确离场 | ✅ |
| T04 | 消除本关全部火箭 | 显示通关结果并可进入下一关 | 弹出关卡总结，显示用时与下一关按钮 | ✅ |
| T05 | 连续错误点击直至机会耗尽 | 显示失败并允许重新开始 | 第三次失误后进入失败界面，可重试或回主页 | ✅ |
| T06 | 游戏进行中重新开始 | 布局和失误次数恢复 | 当前关卡重新加载，火箭和 3 次机会恢复 | ✅ |
6.2 扩展功能测试
| 编号 | 测试内容 | 预期结果 | 实际结果 | 是否通过 |
|---|---|---|---|---|
| T07 | 点击提示按钮 | 标记一个当前可安全飞出的火箭 | 对应格子出现高亮提示 | ✅ |
| T08 | 暂停后继续 | 暂停期间不计入关卡用时 | 恢复后计时扣除暂停时长 | ✅ |
| T09 | 切换声音开关 | 音效停止 / 恢复，游戏逻辑不受影响 | 播放函数受全局开关控制 | ✅ |
| T10 | 完成一关后再次运行 | 最佳纪录可从本地读取 | JSON 中保存并重新载入纪录 | ✅ |
| T11 | 完成最终关 | 播放终章并显示最终总结 | 进入 ending 状态，动画结束后展示总结 | ✅ |
| T12 | 对 7 个关卡执行可解性检查 | 每关都存在完整消除序列 | 7 / 7 关验证通过 | ✅ |
6.3 关卡验证结果
| 关卡 | 名称 | 火箭数量 | 求解结果 |
|---|---|---|---|
| 1 | 地面点火台 | 4 | ✅ 可通关 |
| 2 | 冲破大气层 | 6 | ✅ 可通关 |
| 3 | 近地轨道巡航 | 8 | ✅ 可通关 |
| 4 | 地月转移航线 | 10 | ✅ 可通关 |
| 5 | 月球环绕轨道 | 12 | ✅ 可通关 |
| 6 | 行星际深空 | 14 | ✅ 可通关 |
| 7 | 新星港湾 | 16 | ✅ 可通关 |
6.4 测试中发现和处理的问题
- 中文字体兼容问题： 只写死 Windows 字体路径时，换一台电脑可能显示方框；后来增加系统字体匹配和多个平台的回退字体。
- 暂停时间被计入成绩： 如果直接用当前时间减开始时间，暂停越久成绩越差；后来累计
paused_total并从总时间中扣除。 - 碰撞火箭重复绘制： 动画开始前若不从静态列表移除，同一枚火箭会出现重影；后来改为动画独立绘制，返回后再加入列表。
- 单文件维护困难： 第三版功能越来越多，定位代码开始像在星海里捞针；最终按职责拆成 5 个模块。
- 音效可能刺耳： 最初高频成分较强，后来降低音高、减少高次谐波并增加淡入淡出。
🎒 隐藏任务一：整理项目背包
7.1 最终目录
NovaArrowAdventure/
├── main.py
├── config.py
├── audio_system.py
├── home_screen.py
├── game_screen.py
└── README.md
7.2 开发环境
- Python 3.10 及以上版本；
- Pygame 2.x；
- Windows 10 / 11（代码也提供了 macOS、Linux 常见中文字体回退）；
- 开发辅助工具：GPT / Codex、豆包、DeepSeek。
7.3 安装与运行
pip install pygame
python main.py
7.4 操作说明
- 鼠标左键：点击火箭或按钮；
Esc：暂停 / 继续；- 重新开始：恢复关卡初始布局和 3 次机会；
- 提示：高亮一个当前可以安全飞出的火箭；
- 声音：开启或关闭游戏音效。
本项目的图形主要由程序实时绘制，音效也由 Python 实时合成，不使用原商业游戏的代码、美术或音频素材。
⏳ 隐藏任务二：打开冒险计时器——PSP 表格
| 任务 | 预估耗时（小时） | 实际耗时（小时） | 差异（小时） |
|---|---|---|---|
| 需求分析与游戏设计 | 1.0 | 1.5 | +0.5 |
| Python 与 Pygame 学习 | 2.0 | 2.5 | +0.5 |
| 游戏界面实现 | 4.0 | 5.5 | +1.5 |
| 路径与碰撞逻辑实现 | 3.0 | 3.5 | +0.5 |
| 关卡设计 | 2.0 | 2.5 | +0.5 |
| AIGC 辅助开发 | 2.0 | 3.0 | +1.0 |
| 测试与修改 | 2.5 | 4.0 | +1.5 |
| README 与博客撰写 | 2.0 | 3.0 | +1.0 |
| 合计 | 18.5 | 25.5 | +7.0 |
最大的“时间黑洞”是界面和测试。路径检测写出来只需要几个循环，但为了让火箭飞得自然、按钮按得舒服、暂停计时准确、七关都真的能通关，我花了比预想更多的时间。软件工程再次证明：写出第一版代码，只是故事的序章。📖
💡 通关心得：我学会的不只是 Pygame
1. 先完成闭环，再增加烟花
这次最正确的决定，是第一版先完成“开始—游玩—通关 / 失败—重开”的完整闭环。等核心逻辑稳定后，我才加入太空背景、粒子、音效和终章。否则很容易出现界面已经飞出银河系，路径检测还困在第 0 行的尴尬场面。
2. 数据结构决定代码能不能继续长大
用 (row, col, direction) 表示火箭，看起来只是一个小选择，却让关卡编辑、路径判断和绘制都变得直接。后来加入颜色时，只需要扩展一项，而不用推翻整个结构。
3. AIGC 最有价值的地方是加速试错
GPT / Codex 能快速生成函数和帮助对比版本，豆包能提供主题灵感，DeepSeek能整理开发路径。但 AI 也可能给出不兼容的字体、没有验证的关卡或看似合理却有边界问题的代码。真正重要的能力不是“会不会问 AI”，而是能否判断回答、运行结果并完成修改。
4. 重构不是为了显得高级
当 main3.py 超过两千行后，继续往里面添加功能的成本明显上升。最终拆成五个模块后，音效、主页、关卡和公共配置各自有了归属。重构并没有直接让玩家多一颗星，却让开发者少掉很多头发。🧑💻
5. 测试让“我觉得能过”变成“我证明能过”
关卡看起来可解并不代表真的可解。除了手工试玩，我还使用与游戏一致的规则做可解性检查，确认 7 个关卡都存在完整消除序列。这个过程让我体会到：测试不是项目完成后的仪式，而是帮助我建立信心的证据。
🎯 隐藏任务三：看看升级后的“角色面板”
上一篇博客结束时，我还是一名刚刚接触完整项目的软件工程新手。
这一次，我的技能树又点亮了几个新图标：
🟢 本章新解锁技能
- Pygame 图形界面与事件循环；
- 二维网格与坐标换算；
- 四方向路径扫描；
- 游戏状态管理；
- 动画、粒子和程序合成音效；
- 模块化重构；
- 关卡可解性验证；
- Git 多阶段提交；
- 使用多种 AIGC 工具协作开发。
🟡 仍在升级的技能
- 更系统的自动化测试；
- 更复杂的关卡生成算法；
- 游戏存档与配置管理；
- Python 项目打包；
- 代码规范和持续集成。
🎮 Nova
等级：软件工程冒险者 Lv.2
│
┌──────────────┼──────────────┐
↓ ↓ ↓
游戏逻辑 工程结构 AI协作
★★★☆ ★★★☆ ★★★☆
│
↓
本章新增称号
│
↓
🚀 “会让火箭自己找路的人”
和第一章相比，我最大的变化不是又会用了一个新库，而是开始主动考虑：
这个功能应该放在哪里？怎么验证它真的正确？下一次修改会不会把旧功能弄坏？
这三个问题，正在把“写代码”慢慢变成“做工程”。
🏁 最终关：回到起点，再看这次冒险
从 5×5 棋盘上的几支普通箭头，到 7 个关卡中的彩色火箭；从一个 1600 行左右的基础版本，到第三版超过 2400 行的单文件，再到最终职责清晰的五模块结构——这次作业让我完整经历了需求分析、原型实现、功能迭代、视觉设计、重构、测试和文档编写。
我的火箭也许还没有达到商业游戏的精致程度，但它已经可以正确判断路径、对错误操作给出反馈、保存最佳纪录，并带玩家从地面一路飞向新星。更重要的是，我不只是“得到了一份代码”，而是在一次次修改里逐渐明白了代码为什么这样工作。
下一次 Nova 的软件工程冒险会飞向哪里？不知道。
但至少现在，我已经学会在起飞前先跑一遍测试。🚀✨
🎉 第二章通关！
╔══════════════════════════════════════════╗
║ ║
║ 🎮 NOVA SOFTWARE ADVENTURE ║
║ ║
║ 🏆 第二章通关 ║
║ ║
║ Python / Pygame ✅ ║
║ 四方向路径检测 ✅ ║
║ 七个可通关关卡 ✅ ║
║ 动画与碰撞反馈 ✅ ║
║ AIGC 协作开发 ✅ ║
║ 测试与 Debug ✅ ║
║ GitHub 多阶段提交 ✅ ║
║ ║
║ EXP +1 SOFTWARE ENGINEER ║
║ NEW TITLE: ROCKET NAVIGATOR ║
║ ║
╚══════════════════════════════════════════╝
第一章里，我把一个想法变成了能够调用 AI 的网页。
第二章里，我把一条游戏规则变成了拥有界面、状态、动画、关卡、音效、纪录和测试的完整小游戏。
两次冒险看起来完全不同，但它们都让我走过了同一条路线：
需求
↓
分析
↓
原型
↓
迭代
↓
测试
↓
Debug
↓
重构
↓
文档
如果说第一章让我明白：
代码不是终点。
那么第二章让我进一步明白：
第一版能运行，也不是终点。
真正的软件工程，是让程序从“能跑”逐渐变成“正确、清楚、稳定，而且能够继续修改”。
🌌 写在冒险最后
火箭已经飞出了棋盘，Nova 的第二张地图也暂时探索完毕。
但是我的技能树显然还没有点满，项目背包里也还有很多空格。
下一次，也许会遇到团队协作，也许会遇到更大的项目，也许还会遇到一个比数组越界更难缠的 Boss。
不过没关系。
至少现在，我已经知道应该怎么开始：
先读需求，再写代码；先看报错，再改程序；先完成测试，再宣布起飞。
下一张地图，加载中……
Nova's Software Engineering Adventure · Chapter 2To be continued. 🚀
浙公网安备 33010602011771号