Godot 中场景与脚本的使用

在 Godot 开发中，我们经常面临一个核心架构问题：在创建游戏对象时，应该只写一个脚本（Script），还是应该制作一个场景（Scene）？

虽然两者最终都能在游戏中生成对象，但它们的工作原理、性能表现以及适用场景有着本质区别。

1. 核心原理差异

你可以将“脚本”和“场景”理解为两种不同的构建蓝图：

1.1 脚本（Script）：命令式代码

• 本质：纯代码指令书。
• 工作方式：通过代码一步步构建对象（如 Node.new()）。这就像你口头告诉工人：“先拿一块木板，锯成圆形，刷上红漆。”

• 特点：

  • 只能定义逻辑和属性。
  • 难以直观地定义复杂的节点层级结构（如子节点位置、附件）。
  • 匿名性：默认情况下，脚本只是一个文件，编辑器不知道它的存在，除非通过路径加载。

1.2 场景（Scene）：声明式数据

• 本质：预制组件包（序列化数据）。
• 工作方式：从现有的模具中实例化对象（如 MyScene.instantiate()）。这就像你直接给工人一个做好的箱子，里面已经装好了摆放整齐的零件。

• 特点：

  • 可以同时包含节点结构（层级关系）、属性设置和脚本逻辑。
  • 可视化：所见即所得，便于编辑复杂的视觉元素（如角色、UI）。
  • 安全性：比纯代码更容易管理和修改结构。

2. 性能考量

结论：场景（PackedScene）的实例化通常比纯脚本构建要快。

• 脚本构建的开销：如果使用纯代码（如在 _init() 中连续调用 Node.new(), set_name(), add_child()），引擎必须逐行解释执行指令。每一步操作都需要在脚本层（GDScript/C#）和引擎底层（C++）之间进行通信，这会产生累积的性能开销。
• 场景实例化的优势：场景文件（.tscn）本质上是序列化的数据。Godot 引擎在后台可以批量处理这些数据，直接在底层 C++ 层面一次性构建整个对象树，效率显著更高。

建议：对象结构越复杂（子节点越多），越应该使用场景。

3. 注册脚本（Script Classes / Named Types）

虽然场景很强大，但有时我们只需要一个纯粹的逻辑组件。为了让脚本像内置节点一样易用，Godot 允许我们将脚本“注册”到编辑器中。

3.1 什么是“注册”？

默认情况下，脚本是“匿名”的，必须通过文件路径加载。
“注册”就是给脚本一个全局名称（Global Name），使其成为 Godot 类型系统的一部分。

• 未注册：const MyNode = preload("res://my_node.gd")
• 已注册：可以直接使用 MyNode.new()，并能在编辑器的“创建节点”面板中搜索到。

3.2 如何注册？

推荐使用 脚本类（Script Classes） 功能。在脚本开头添加 class_name 关键字：

# my_cool_node.gd
class_name MyCoolNode  # <--- 注册名为 MyCoolNode
extends Node

@export var health: int = 100

3.3 注册脚本 vs. 自定义类 vs. 内部类

• 普通脚本：本质上就是匿名自定义类。
• 注册脚本：本质上是拥有全局名称和编辑器集成权限的自定义类。
• 内部类（Inner Class）：写在脚本内部的类（class Inner:）。它们在代码中是完全公开可见的（非私有），但无法注册到编辑器中，也不能作为独立的节点资源在编辑器面板使用。

4. 决策指南：何时使用什么？

在实际开发中，请遵循以下判断标准：

情况 A：应该使用“场景 (Scene)”

• 适用对象：游戏中的具体实体（如：玩家角色、敌人、UI界面、关卡元素）。

• 特征：

  • 有复杂的视觉表现（Sprite、Model）。
  • 有复杂的层级结构（带有碰撞体、音频播放器、粒子效果等子节点）。
  • 需要经常在编辑器中调整子节点的位置或属性。
• 理由：场景提供了可视化的编辑能力，且性能更好。

情况 B：应该使用“注册脚本 (Registered Script)”

• 适用对象：逻辑组件、数据管理器、自定义控件（如：HealthComponent、InventoryManager、StateMachine）。

• 特征：

  • 逻辑重，外表无：不需要子节点，或者子节点完全由代码控制。
  • 多实例需求：游戏中有多个对象需要挂载此逻辑，且每个对象有独立状态（区别于单例）。
  • 生命周期依赖：需要使用 _process 或 Timer 等引擎回调（区别于静态类）。
  • 需要配置：策划需要在编辑器属性面板中调整参数（使用 @export）。
• 理由：注册后可以直接在编辑器中像添加原生节点一样添加它们，极大提高了工具和逻辑复用的便捷性。

情况 C：应该使用“单例 (Singleton/Autoload) 或 静态类”

• 适用对象：全局唯一的工具或管理器（如：MusicPlayer、GlobalConfig、MathHelper）。
• 特征：无状态（静态类）或 全局共享一份状态（单例）。

5. 进阶技巧：脚本作为命名空间

如果你既想要场景的结构优势，又想要脚本的全局访问便利性，可以结合使用：

1. 定义一个注册脚本类（如 Game）。
2. 在其中将场景预加载为常量。

# game_resources.gd
class_name GameResources # 注册为全局类
extends RefCounted

# 将场景作为常量暴露
const HeroScene = preload("res://hero.tscn")
const EnemyScene = preload("res://enemy.tscn")

使用方式：
在任何代码中，你都可以优雅地调用 GameResources.HeroScene.instantiate()，而无需手动加载路径。

---

总结

• 场景是游戏内容的容器，擅长处理结构和视觉，性能更优。
• 脚本是逻辑的载体。
• 注册脚本（class_name） 是将逻辑组件化的最佳手段，它让脚本变成了可配置、可复用的自定义节点。

黄金法则：如果你需要可视化的结构，用场景；如果你只需要复用的逻辑组件，用注册脚本。