Unity 101 · 停电救援 A1.0

作业要求怎样落到游戏里#

老师的 Unity 101 Final Project 要求制作经过测试的 3D 游戏、提供始终可访问的退出按钮，并提交完整 Windows 构建、公开 Git 仓库链接和不超过两页的开发问题复盘。A1.0 已实现其中的技术要求：

• **Prefab 实例化：**从预制体生成电芯对象。
• **物理与碰撞：**机器人、空间站、设备和停靠边界组成可碰撞的物理场景。
• **瞬时施力：**按 Shift 通过 Rigidbody.AddForce 施加冲刺冲量，并显示冷却与尾焰。
• **实时 UI：**目标、携带物、冲刺状态和计时随游玩更新。
• **场景切换：**从开始菜单进入游戏场景。
• **声音：**操作和事件有音效反馈；开始菜单与游戏内均可退出。

完整 Windows 生成目录被打包为 ZIP。源码仓库包含 Unity 的 Assets、Packages、ProjectSettings、对应的 .gitignore、中英文 README 和素材声明。

从小球原型到看得懂的任务#

最初的原型先解决移动、碰撞与冲刺，随后加入完整任务：识别正确电芯、搬到发电机、完成撤离。形象改版再把这些动作放进统一的空间站故事，让设备有明确外观和用途。

我的试玩反馈推动了几个关键选择：头部应该朝移动方向转；加速要能看出来；放电要像真正的危险；靠近设备应先显示操作，再由玩家执行。供电也成为发电机启动、能量沿实体线路传播、选中气闸打开的连续过程。

现在的游戏有开始菜单、简短帮助、暂停菜单、即时中英文切换和精简目标提示。两种电芯、三个可能的救援港口为这个小关卡提供变化。

开门之后，机器人掉下去了#

实际问题。 我在恢复供电后直接开过气闸，没有按 E 登船。机器人穿过看得见的平台，掉到了空间站下面。

最初的判断。 排查考虑过门碰撞体是否过早移除，也考虑过走进去就自动登船。但当时门已经完全打开，手动登船也是既定规则，这些判断没有解决平台缺少支撑的问题。

真正原因。 场景构建器把 LandingPad 创建为可见形状，而辅助方法默认不保留实体碰撞。平台有渲染器却没有支撑角色的碰撞体，外沿也缺少边界。

修复方式。 可重复执行的构建器现在保留实体平台，并增加侧面和末端护栏。玩家可以走进打开的气闸，安全站立，再回到标记处主动登船。

验证结果，以及它能说明什么#

新增移动检查先在 A 港口重现了旧问题：开门后向前移动，机器人落到约 y = -26.59。这个失败结果给修复提供了明确的验收条件。

修复后对三个打开的港口分别检查向前和侧向移动、平台支撑、护栏边界、返回标记和主动登船。已有记录包含 317 项 Editor 检查、176 项 Windows 检查，以及从干净源码副本首次导入、编译后通过的 317 项检查。完整 Windows 包也经过解压验证。

这些结果对应记录中的路线与状态。此前的检查全部通过，却漏掉了“继续开过已经打开的门”；这正是新增检查的价值。查看验证报告 ↗

下次设计时可以复用什么#

1. 同时写外观和行为。 看得见的路需要物理支撑；发光的设备需要明确的供电状态和后续影响。
2. 写清交互约定。 靠近、选择和执行是不同步骤，还要说明没有输入、错误输入、重复输入、暂停和重开时怎样处理。
3. 测试状态变化后新开放的空间。 门打开会改变可走区域，验收也需要进入那个区域。
4. 把经验整理成工具。 仓库中的 DesignKit 保存设计简报、Prompt 工作台和项目经验，供下一次构思时使用。

分工与后续计划#

我负责构思、设计选择和真实试玩反馈，代码实现、回归执行与文档整理使用 AI 辅助。链接中的两页复盘仍是需要我审阅的课程提交草稿。

后续计划是 Python 控制接口（B）、视觉游戏代理（C），以及记忆与重新规划对比（D）。3D Gaussian Splatting 实验则需要单独完成并提供实际实验记录。

返回课程目录 → · 游戏项目 → · Unity 安装记录（英文）→