何时使用场景VS脚本

我们已经介绍了场景和脚本的不同之处。脚本使用命令性代码定义引擎类扩展，而场景使用声明性代码。

结果，每个系统的功能都不同。场景可以定义扩展类的初始化方式，但不能定义其实际行为。场景通常与脚本结合使用，以便场景充当脚本声明性代码的扩展。

匿名类型

单独使用脚本 可以 完全定义场景的内容。从本质上讲，Godot编辑器所做的，仅在其对象的C++构造函数中。

但是，选择哪个来使用，可能是一个两难问题。创建脚本实例与创建引擎类相同，而处理场景需要更改API：

GDScript

C#

  1. const MyNode = preload("my_node.gd")
  2. const MyScene = preload("my_scene.tscn")
  3. var node = Node.new()
  4. var my_node = MyNode.new() # Same method call
  5. var my_scene = MyScene.instance() # Different method call
  6. var my_inherited_scene = MyScene.instance(PackedScene.GEN_EDIT_STATE_MAIN) # Create scene inheriting from MyScene
  1. using System;
  2. using Godot;
  4. public class Game : Node
  5. {
  6.     public readonly Script MyNodeScr = (Script)ResourceLoader.Load("MyNode.cs");
  7.     public readonly PackedScene MySceneScn = (PackedScene)ResourceLoader.Load("MyScene.tscn");
  8.     public Node ANode;
  9.     public Node MyNode;
  10.     public Node MyScene;
  11.     public Node MyInheritedScene;
  13.     public Game()
  14.     {
  15.         ANode = new Node();
  16.         MyNode = new MyNode(); // Same syntax
  17.         MyScene = MySceneScn.Instance(); // Different. Instantiated from a PackedScene
  18.         MyInheritedScene = MySceneScn.Instance(PackedScene.GenEditState.Main); // Create scene inheriting from MyScene
  19.     }
  20. }

此外，由于引擎和脚本代码之间的速度差异，脚本的运行速度将比场景慢一些。节点越大和越复杂，将它构建为场景的理由就越多。

命名的类型

在某些情况下，用户可以在编辑器内，将脚本注册为新类型。在节点或资源创建对话框中，将其显示为新类型，并带有可选图标。在这些情况下，用户使用脚本的能力更加流畅。而不必…

  1. 了解他们想要使用的脚本的基本类型。
  2. 创建一个该基本类型的实例。
  3. 将脚本添加到节点。
    1. （拖放方法）
      1. 在文件系统停靠面板中找到脚本。
      2. 将脚本拖放到场景停靠面板中的节点上。
    2. （属性方法）
      1. 向下滚动到属性检查器的底部，找到 脚本 属性并选择它。
      2. 从下拉列表中选择 加载。
      3. 从文件对话框中选择脚本。

使用一个注册的脚本，脚本类型将像系统中的其他节点和资源一样成为创建选项。不需要做任何上述工作。创建对话框甚至还有一个搜索栏，用于按名称查找类型。

有两种用于注册类型的系统…

  • 自定义类型

    • 仅限编辑器。类型名称在运行时中不可访问。
    • 不支持继承的自定义类型。
    • 一个初始化工具。使用脚本创建节点。仅此而已。
    • 编辑器没有对该脚本的类型感知，或其与其他引擎类型或脚本的关系。
    • 允许用户定义一个图标。
    • 适用于所有脚本语言，因为它抽象处理脚本资源。
    • 设置使用 EditorPlugin.add_custom_type。

  • 脚本类

    • 编辑器和运行时均可访问。
    • 显示全部继承关系。
    • 使用脚本创建节点，但也可以从编辑器更改或扩展类型。
    • 编辑器知道脚本、脚本类和引擎c++类之间的继承关系。
    • 允许用户定义一个图标。
    • 引擎开发人员必须手动添加对语言的支持（名称公开和运行时可访问性两者）。
    • 仅适用于Godot 3.1+版本。
    • 编辑器扫描项目文件夹，并为所有脚本语言注册任何公开的名称。为公开此信息，每种脚本语言都必须实现自己的支持。

这两种方法都向创建对话框添加名称，特别是脚本类，还允许用户在不加载脚本资源的情况下访问类别名称。在任何地方都可以创建实例，和访问常量或静态方法。

有了这些功能，由于它赋予用户易用性，人们可能希望它们的类型是没有场景的脚本。那些正在开发的插件或创建供设计人员使用的内部工具，将以这种方式使事情变得更轻松。

不足之处在于，这也意味着很大程度上必须使用命令式编程。

Performance of Script vs PackedScene

One last aspect to consider when choosing scenes and scripts is execution speed.

As the size of objects increases, the scripts’ necessary size to create and initialize them grows much larger. Creating node hierarchies demonstrates this. Each Node’s logic could be several hundred lines of code in length.

The code example below creates a new Node, changes its name, assigns a script to it, sets its future parent as its owner so it gets saved to disk along with it, and finally adds it as a child of the Main node:

GDScript

C#

  1. # Main.gd
  2. extends Node
  4. func _init():
  5.     var child = Node.new()
  6.     child.name = "Child"
  7.     child.script = preload("Child.gd")
  8.     child.owner = self
  9.     add_child(child)
  1. using System;
  2. using Godot;
  4. public class Main : Resource
  5. {
  6.     public Node Child { get; set; }
  8.     public Main()
  9.     {
  10.         Child = new Node();
  11.         Child.Name = "Child";
  12.         Child.Script = ResourceLoader.Load<Script>("child.gd");
  13.         Child.Owner = this;
  14.         AddChild(Child);
  15.     }
  16. }

Script code like this is much slower than engine-side C++ code. Each instruction makes a call to the scripting API which leads to many “lookups” on the back-end to find the logic to execute.

Scenes help to avoid this performance issue. PackedScene, the base type that scenes inherit from, defines resources that use serialized data to create objects. The engine can process scenes in batches on the back-end and provide much better performance than scripts.

总结

最后，最好的方法是考虑以下几点：

  • 如果希望创建一个基本工具，它将在几个不同的项目中重用，以及可能提供给不同技能水平的人使用。(包括那些不认为自己是个程序员的用户)，它很可能是一个脚本，有一个自定义名称/图标。

  • 如果有人想创造一个特定于他们的游戏的概念，那么它应该是一个场景。场景比脚本更容易跟踪/编辑，并提供更多的安全性。

  • 如果有人想命名一个场景，他们仍然可以在3.1版本中，通过声明一个脚本类并给它一个场景作为常量来实现这一点。实际上，该脚本变成了一个命名空间：

    GDScript

    1. # game.gd
    2. extends Reference
    3. class_name Game # extends Reference, so it won't show up in the node creation dialog
    4. const MyScene = preload("my_scene.tscn")
    6. # main.gd
    7. extends Node
    8. func _ready():
    9.     add_child(Game.MyScene.instance())