1.2 场景与游戏对象：舞台与工位

1.2 场景与游戏对象：舞台与工位

本节摘要：场景（Scene）是 Unity 的舞台单元，游戏对象（GameObject）是舞台上的工位。本节讲清两者的关系、父子层级的组织套路，以及空物体当"组长"的工程习惯，并用一个双场景切换的案例演示场景在运行时如何交接。

舞台不是世界，工位不是角色

初学者常把 Scene 理解成"游戏世界"，这个类比在小型项目里凑合，做大就会歪。更准确的说法：Scene 是一张可以独立加载与卸载的舞台布置单。一个游戏可以只有一个场景，也可以由几十个场景拼装；大型项目还会在运行时把多个场景叠加（Additive）到一起，比如常驻的 UI 场景垫底，关卡场景一个个往上叠。

GameObject 则更"空"。它本身几乎什么都不会：没有位置概念、没有外观、不会渲染——这些能力全靠挂载组件提供。你可以把 GameObject 理解成值班室里的一个工位：工位本身只是一张桌子和一个门牌号，能给客人倒水的是坐在那里的员工（组件）。所以"场景里有一个敌人"这句话在引擎层面的真实含义是：场景里有一个叫 Enemy 的工位，上面坐着 Transform（管位置）、MeshRenderer 或 SpriteRenderer（管外观）、Collider（管碰撞）、以及你写的 EnemyLogic（管行为）等一排员工。

理解这种"空"带来一个直接推论：物体与行为是分离的。同一个模型，挂上玩家控制脚本就是主角，挂上 AI 巡逻脚本就是 NPC——第 3 章的物理、第 4 章的渲染都建立在这个可拆装的结构上。

层级：工位也要有编制

场景一多，花名册就是几十上百行。父子层级（Transform 层级）是 Unity 给你的编制工具：把子对象挂到父对象下，子对象会跟随父对象的移动、旋转、缩放。典型套路：

• 角色根节点挂移动与碰撞逻辑，模型挂在它下面负责外观，武器再挂在模型的右手骨头上——根一动，全身跟着动；
• 关卡道具按区域归组到空物体（Create Empty）下，比如把一片火把都挂在 Torches 组下，整体控制显隐；
• 特效与音源挂在触发点下，方便销毁时一锅端。

空物体的价值值得单独强调：它没有渲染与碰撞，纯粹是一个"组长工位"，专门用来当锚点、容器与逻辑挂载点。出生点、寻路目标点、区域触发器的中心，几乎都是空物体。

一棵典型的小关卡层级树

动手：双场景交接的值班演练

背景：做游戏躲不开"从主菜单进入关卡"这一步，它本质上是运行时的场景交接。本例建立 Menu 与 Level01 两个场景，用一行代码完成交接。

操作：把默认场景改名为 Menu，再新建场景 Level01（两个场景都要拖进 Build Settings 的场景列表，否则打包后找不到，编辑器内直接运行也一样会报错）。在 Menu 场景建一个空物体命名 Boot，挂上如下脚本：

using UnityEngine;
using UnityEngine.SceneManagement;

public class SceneRelay : MonoBehaviour
{
    void Start()
    {
        // 延迟三秒后切换，模拟玩家在主菜单停留的时间
        Invoke(nameof(GoLevel), 3f);
    }

    void GoLevel()
    {
        // Single 模式：卸载当前场景，加载目标场景
        SceneManager.LoadScene("Level01", LoadSceneMode.Single);
    }
}
​

结果：按 Play 运行 Menu 场景，三秒后 Hierarchy 的内容整体换成 Level01 的对象，Console 无报错。

解读：LoadScene 的 Single 模式是"换台"，旧舞台连人带布景全部撤下；Additive 模式则是"加台"，新场景叠在旧场景之上、旧场景继续运行。交接时所有旧场景对象会收到 OnDestroy，跨场景想存活的调度员要用 DontDestroyOnLoad，这在第 2 章讲对象生命周期时会再碰面。名字传参要求两个场景都已登记进打包列表，这是新人最常踩的坑：报错信息是"Scene couldn't be loaded because it has not been added to the build settings"，看到它先查打包列表而不是查代码。

变式：把 Single 改成 Additive 再运行一次，观察 Hierarchy——Menu 的对象还挂着，Level01 叠了上来，两边的摄像机同时工作，画面可能闪烁。这提示叠加场景要主动管理：旧场景的摄像机与灯光要么关掉，要么在加载后用 SetActiveScene 指定新场景为活动场景。

运行时的场景叠加：不止是"进入关卡"

LoadScene 的两种模式值得再深一层，因为它们决定了大型游戏的资源节奏。Single 换台简单可靠，但换台瞬间玩家在等——所以正经项目都走异步版本 LoadSceneAsync，配合进度条把等待变成反馈。Additive 加台则是开放世界与长关卡的基础设施：把一个大地图切成若干区块场景，玩家走近哪个区块就叠加加载哪个，走远就卸载，内存水位始终平稳。这套"流式加载"再配合第 5.2 节的 Addressables，就是开放世界资源管理的完整拼图。

叠加场景还有个编辑器红利：多人协作时每人拥有一个子场景，各自独立编辑、分开保存，从根上绕开了场景合并冲突——第 5.3 节的协作规范会引用这一点。代价是叠加场景之间的对象引用要经过管理器中转，不能直接拖拽跨场景引用，跨场景通信统一走事件总线（第 2.4 节）。

场景的组织建议

一个实用原则：按"加载节奏"切场景，而不是按美术文件夹切。同一时间出现在屏幕上的东西尽量在同一场景；主菜单、每个关卡、结算页各自独立；常驻的 UI 与全局管理器走叠加场景或跨场景存活对象。场景文件名避免中文与空格，重命名场景要在 Project 窗口里做，别在文件管理器里改，否则所有引用它的资源会断链。多场景协作的项目再加一条：约定"谁的场景谁保存"，编辑器提示多场景有未保存改动时，只保存自己负责的那几个，别一把梭全存了——那等于把别人的半成品也提交进了历史。

本节要点回顾

• Scene 是布置单：可独立加载、卸载与叠加，按加载节奏而非文件类型划分场景；
• GameObject 是空工位：能力全部来自组件，物体与行为天然分离；
• 层级即编制：父子跟随变换，空物体当组长，负责分组、锚点与逻辑挂载；
• 场景交接的两种模式：Single 换台，Additive 加台，跨场景存活靠 DontDestroyOnLoad；
• Scene couldn't be loaded 报错：先查打包列表，再查代码与场景名拼写。

工位与编制都清楚了，接下来看工位上那张最重要的岗位卡：组件系统。