创作者视角：编程让世界从静止变成活的

第二部结束时，场景里通常只有这些：几块 Cube 当地板墙、一颗或几颗带 Point Light 的球、按第 9 章调过的材质和方向光。能 Build & Test 走进去，但按钮按了没反应，门只是模型，灯只能在编辑器里手动开关。

第三部没有往场景里加 BGM、雨声、桌椅或咖啡角。那些在第 7 部及以后才系统出现。如果读到这里觉得「我的房间还是空的」，和书的进度一致，不是漏做了某章。

编程改的是哪一层

GameObject、Component、Material、Light、Prefab 搭的是外观和布局：看得见什么、光从哪来、哪些物体可以复用。

UdonSharp 脚本加的是对玩家的响应：按一下、走进去、拿起来、计时、改状态。同一间毛坯房，挂上 Interact 和 Trigger 之后，才会对操作有反馈。

两类工作都重要，也不是二选一。展览类世界可以几乎不写自定义脚本；游戏类世界会在规则脚本上花很多行。差别在目标，不在「静态高级 / 动态高级」。

看世界的方式会多一层

进别人的世界时，除了看灯光和模型，还可以对照已经学过的结构：这个像是 Trigger 进区域播音；那个像是 Interact 切 Light.enabled；Pickup 三件套齐了就能抓。

这一层是读代码和执行链路的副产品，不是第三部的考试内容。

编程在这里是「把步骤写清楚」

「玩家按按钮 → 灯亮 → 三秒后灭」要先拆成：哪个事件（Interact）、改哪个字段（targetLight.enabled）、怎么等三秒（SendCustomEventDelayedSeconds）。

语法是把这些步骤写成 UdonSharp 认得的形状。第三部铺的是最小语法和 Udon 编译链，够读懂第四部每章的短脚本。

自带组件也是同一套链路

出生点、镜子、Pickup、Portal 等 SDK 组件，背后同样是 Udon 字节码和虚拟机。不写自定义脚本，是在用官方写好的脚本。第四部会从「按按钮开灯」这类最小自定义交互开始加。

---

第三部到这里收束。场景可能仍然像毛坯房；第四部的动手章会在现有房间上逐个加交互。