Understanding Entities

现在让我们理解 cave 中的 Entity 概念。实体是 Cave 场景中的基本对象。

如果一个场景是一个关卡、菜单或测试空间，那么实体就是存在于该空间内的东西。例如，玩家、敌人、门、灯光、摄像机、触发器、UI 按钮、声音源和文件夹都可以是实体。

在本课中，你将学习：

• 名称。
• ID。
• 活跃状态。
• 父子关系。
• 文件夹。
• 层级顺序。
• 标签和属性。
• 模板实例。

这些细节看起来虽小，但当一个场景从几个对象发展成一个真正的关卡时，它们会带来很大的不同。

什么是 Entity？

Entity 是场景中的一个对象。

实体可以代表：

• 一个可见的 3D 对象。
• 一个不可见的辅助对象。
• 一个游戏触发器。
• 一个 UI 元素。
• 一个声音源。
• 或仅仅是用于组织的文件夹。

例如，一个货箱是可见实体。一个出生点在游戏中可能不可见，但它仍然是一个实体，因为它标记了事件发生的位置。

Cave 保持这个理念简单：场景由实体构建。

实体是组件容器

实体本身不做太多事情，它们的功能来自组件。例如：

这就是实体灵活的原因。门并不是完全分离的硬编码对象类型。它是一个由多部分组成的实体：用于显示的网格、阻挡玩家的碰撞体和控制开关的逻辑。

理解这一点后，构建对象变得更实用。你不再问“我需要哪种对象类型？”而是问“这个实体需要哪些组件？”

实体名称

每个实体都有一个名称。你可以在 Scene Graph 的快速编辑菜单或 Properties 标签中重命名实体。

值得一提的是，名称首先是给人看的：

• 让场景图更易于浏览。
• 方便调试。
• 便于与团队成员讨论对象。
• 有助于你以后理解自己的场景。

Cave 不要求每个实体名称唯一。多个实体可以共享相同名称，这对重复对象（如石头、金币、货箱或敌人）很有用。

但不要把名称当做实体的唯一可靠标识。

好的名称应简单且具描述性：

目标不是让名称花哨，而是让场景可读。

实体名称也可以在代码中用来获取场景中具体实体，但既然你已经知道多个实体可以有相同名称，那么如果通过名称获取实体，且该名称对应多个实体，可能导致未定义行为，因为引擎会返回搜索到的第一个实体。因此，如果你需要通过代码获取特定对象（比如玩家），确保给它一个独一无二的名称。

实体 ID

Cave 在内部用唯一的 ID 跟踪实体。

通常你无需编辑或关心这些 ID。它们存在以确保引擎能可靠识别实体，即使名称重复。实际上，唯一 ID 是不可变的，你不能更改它们。它们由引擎自动分配。

记住：

即使两个敌人都叫 Enemy，Cave 也能在幕后区分它们。

实体活跃状态

实体可以是活跃或非活跃。

在 Scene Graph 和 Properties 标签中，用眼睛图标表示活跃状态。

根据实体及其组件的不同，禁用可能会影响：

• 渲染。
• 物理。
• 逻辑。
• 运行时更新。
• 组件行为。

禁用的实体不会调用任何组件的更新函数。禁用时会调用组件的结束方法，重新启用时调用组件的开始方法。

你可以安全地假设禁用的实体不会参与场景中的物理计算、逻辑、触发器等，除非你手动从场景查询这些被禁用的实体并忽略它们的禁用状态。

实际意义是：非活跃意味着“保留在这里，但当前不参与”。

禁用与删除

禁用和删除不同。

当你可能稍后还需要该实体时，禁用它。 确定要移除时，删除实体。

测试时，禁用通常更安全。如果敌人太难，先禁用几个再测试关卡。如果感觉合适，之后可以清理场景。

实体父子关系

实体可以有父子关系。

有父实体时，实体成为父实体层级的一部分。移动父实体时，子实体也随之移动。

父子关系常用来：

• 把剑附加到角色。
• 把灯光附加到火炬。
• 把摄像机附加到车辆。
• 把一组道具放入文件夹。
• 把 UI 元素组织在父面板下。

父子关系也影响变换。子实体的变换是相对于父层级计算的。

这是保持相关对象组合在一起的最简单方式之一。

文件夹实体

文件夹实体用于组织场景。特别是当场景包含很多对象时，很有帮助。

定义上，一个实体成为文件夹，通常是因为它缺少组件，特别是缺少 Transform 和 UI Element 组件，因为一个没有世界变换且没有 UI 元素的实体，很可能用作文件夹。不过这主要是命名约定，需记住这一点。

常见的文件夹分组包括：

• 环境
• 游戏触发器
• 敌人
• 道具
• 灯光
• UI
• 音频
• 调试辅助

文件夹不仅仅是整洁。干净的场景图可帮助你更快工作，因为你无需在数百个散乱实体中寻找需要的对象。

实体层级顺序

Scene Graph 中实体的顺序关系到组织，有时也影响处理或显示方式。

如果你展开一个文件夹看到如下结构，扫描起来较难：

Crate
Player
Light
Enemy
Camera
Rock
Trigger

但这更容易：

Player
Camera
Lighting
Enemies
Environment
Gameplay Triggers

目标不是让层级花哨，而是让它有用。

如果你一周后打开场景能立即看懂重要对象位置，说明层级设计得当。

重要提示：由于引擎内部优化，顶层没有父实体的实体顺序是随机的，但子实体可以按特定顺序排列，你可以在编辑器中右键点击单个实体，选择上移、下移、置顶或置底来整理它们。

实体属性和标签

实体可以存储自定义属性和标签。

例如，一个敌人可以有：

• 一个 Damageable 标签。
• 一个 health 属性。
• 一个 team 属性。
• 一个 patrolRadius 属性。

脚本和逻辑可利用这些数据做出决策。

伤害系统可能会查找具有 Damageable 标签的实体。敌人脚本可能读取 patrolRadius 来决定敌人可巡逻的范围。

属性和标签让你在无需为每个小数据添加组件的情况下，赋予实体游戏意义。

标签查询速度快，适合标识敌人或可受伤实体之类的用途，但它们不携带值。属性查询较慢，但可以附带值。从编码角度看，实体属性实际上是 Python 字典。

实体模板预览

有些实体是 Entity Templates 的实例。例如，你在默认的新 Cave 项目中会找到的 Player，就是此模板的实例：

模板实例在 Scene Graph 中以 Cave 模板色显示，帮助你识别该实体来自可复用的模板资源。

当实体是一个模板实例时：

• 它的内部子对象属于模板。
• 放置的实例属于场景。
• 模板结构通过打开模板资源进行编辑。
• 暴露为属性的本地值仍然可以调整。

下一课将更详细地讲解 Entity Templates。

Entity 的心智模型

将 Entity 想象成一个小容器：

• 名称帮助你理解它。
• ID 帮助 Cave 跟踪它。
• 活跃状态控制它是否参与。
• 父对象控制它的归属。
• 组件定义它的功能。
• 属性和标签描述额外的游戏数据。

这就是 Cave 中场景构建的核心。

一旦理解了 Entity，场景图不再只是对象列表，而是你的游戏世界结构。