场景组织

本文讨论与场景内容的有效组织, 相关的主题. 应该使用哪些节点？应该把它们放在哪里？它们应该如何互动？

如何有效地建立关系

当Godot用户开始制作自己的场景时, 他们经常遇到以下问题: 他们创建了自己的第一个场景, 并将其内容填满, 但最终却将自己场景的分支保存为独立的场景, 因为他们应该拆分东西的纠结感开始累积. 然而, 他们会发现, 之前能够依赖的强引用已经不能用了. 在多个地方重新使用场景会产生问题, 因为节点路径找不到目标, 在编辑器中建立的信号连接也会中断. 要解决这些问题, 必须实例化子场景, 而子场景不需要有关其环境的详细信息. 人们必须能够相信子场景会自己创建自己, 而无需挑剔人们如何使用它. 松散的耦合 . 这样可以使对象的大小保持在较小的范围内(便于维护), 并提高它们的可重用性. 多个 的意义. 如果可能的话, 应该设计没有依赖性的场景. 也就是说, 人们应该创建场景, 而场景将所需的一切保留在其内部. 依赖注入. 该技术涉及使高级API提供低级API的依赖关系. 为什么是这样？因为依赖于其外部环境的类, 可能会无意中触发, 错误和意外行为. 要做到这一点, 必须公开数据, 然后依赖父级上下文来初始化它:

  1. 连接到一个信号, 极其安全, 但只能用于 “响应” 行为, 而不是启动它. 请注意, 信号名称通常是过去式动词, 如 “entered” , “skill_activated” 或 “item_collected”. GDScript C#
  1. # Parent$Child.connect("signal_name", object_with_method, "method_on_the_object")# Childemit_signal("signal_name") # Triggers parent-defined behavior.
  1. // ParentGetNode("Child").Connect("SignalName", ObjectWithMethod, "MethodOnTheObject");// ChildEmitSignal("SignalName"); // Triggers parent-defined behavior.
  1. 调用一个方法. 用于启动行为. GDScript C#
  1. # Parent$Child.method_name = "do"# Child, assuming it has String property 'method_name' and method 'do'.call(method_name) # Call parent-defined method (which child must own).
  1. // ParentGetNode("Child").Set("MethodName", "Do");// ChildCall(MethodName); // Call parent-defined method (which child must own).
  1. FuncRef 属性. 比方法更安全, 因为方法的所有权是没必要的. 用于启动行为. GDScript C#
  1. # Parent$Child.func_property = funcref(object_with_method, "method_on_the_object")# Childfunc_property.call_func() # Call parent-defined method (can come from anywhere).
  1. // ParentGetNode("Child").Set("FuncProperty", GD.FuncRef(ObjectWithMethod, "MethodOnTheObject"));// ChildFuncProperty.CallFunc(); // Call parent-defined method (can come from anywhere).
  1. 节点(Node) 或其他 对象(Object) 引用. GDScript C#
  1. # Parent$Child.target = self# Childprint(target) # Use parent-defined node.
  1. // ParentGetNode("Child").Set("Target", this);// ChildGD.Print(Target); // Use parent-defined node.
  1. 节点路径(NodePath). GDScript C#
  1. # Parent$Child.target_path = ".."# Childget_node(target_path) # Use parent-defined NodePath.
  1. // ParentGetNode("Child").Set("TargetPath", NodePath(".."));// ChildGetNode(TargetPath); // Use parent-defined NodePath.

松耦合 . 人们可以在另外一个上下文中重新使用它, 而不需要对API做任何额外的改变. 注解 虽然上面的例子说明了父子关系, 但是同样的原则也适用于所有对象之间的关系. 兄弟节点应该只知道它们的层次结构, 而先祖节点则负责协调它们的通信和引用. GDScript C#

  1. # Parent$Left.target = $Right.get_node("Receiver")# Leftvar target: Nodefunc execute():    # Do something with 'target'.# Rightfunc _init():    var receiver = Receiver.new()    add_child(receiver)
  1. // ParentGetNode<Left>("Left").Target = GetNode("Right/Receiver");public class Left : Node{    public Node Target = null;    public void Execute()    {        // Do something with 'Target'.    }}public class Right : Node{    public Node Receiver = null;    public Right()    {        Receiver = ResourceLoader.Load<Script>("Receiver.cs").New();        AddChild(Receiver);    }}

同样的原则也适用于, 维护对其他对象依赖关系的非节点对象. 无论哪个对象实际拥有这些对象, 都应该管理它们之间的关系. 警告 人们应该倾向于将数据保存在内部(场景内部), 尽管它对外部上下文有一个依赖, 即使是一个松散耦合的依赖, 仍然意味着节点, 将期望其环境中的某些内容为真. 项目的设计理念应防止这种情况的发生. 如果不是这样, 代码的继承的责任将迫使开发人员使用文档, 以在微观尺度上跟踪对象关系；这就是所谓的开发地狱. 默认情况下, 编写依赖于外部文档的代码, 让人们安全地使用它, 是很容易出错的. _get_configuration_warning(). 从中返回一个非空字符串, 将使场景停靠面板生成警告图标, 该字符串作为节点的工具提示. 当它没有定义 CollisionShape2D 子节点时, 是相同图标, 即显示为节点如 Area2D 节点的图标. 然后, 编辑器通过脚本代码自行记录场景. 通过文档, 没有内容复制是必要的. 这样的GUI可以更好地通知项目用户有关节点的关键信息. 它具有外部依赖性吗？这些依赖性是否得到满足？其他程序员, 尤其是设计师和作家, 将需要消息中的明确指示, 告诉他们如何进行配置. 那么, 为什么这些复杂的开关都起作用呢？嗯, 因为场景在单独工作时运行得最好. 如果不能单独工作, 那么与别人匿名运行(最小化强依赖, 即松散耦合)是下下之策. 不可避免地, 可能需要对一个类进行更改, 如果这些更改导致它以不可预见的方式与其他场景交互, 那么事情就会开始崩溃. 所有这些间接性的目的就是为了避免最终出现改变一个类导致对其他类产生不利影响的情况. 所有 的OOP原则. 例如…

  • SOLID
  • DRY
  • KISS

  • YAGNI

    选择一个节点树结构

    哪里 呢？好吧，自己做的游戏当然自己说了算。虽然节点树的构造方法有无数种，但对于没把握的人而言，这份指南可以展示一个比较像样的结构作为基础。 一个游戏总是应该有一种 “入口点” ；在某个地方, 开发者可以明确地追踪到运行的开始位置, 以便他们可以在其他地方继续运行逻辑. 这个地方也可以作为程序中所有其他数据和逻辑的总览图. 对于传统的应用程序, 这将是 “主” 功能. 在这种情况下, 它将是一个Main节点.

    • Main (main.gd) main.gd 脚本将作为游戏的主要控制器. 世界 (二维或三维). 这可以是 Main 的子节点. 另外, 他们的游戏将需要一个主要的GUI, 来管理项目所需的各种菜单和小部件.
    • Main (main.gd)

  • 世界 (game_world.gd)

  • gui.gd) 世界 节点的子级. 手动更换场景 让用户完全控制他们的游戏世界如何过渡. 下一步是考虑项目需要什么样的游戏系统. 如果有这么一个系统…
  1. 跟踪所有的内部数据
  2. 应该是全局可访问的
  3. 应该是独立存在的 自动加载单例节点 节点. 注解 SceneTree.change_scene() 方法以交换出主场景的内容. 这种结构或多或少保留“World”作为主要游戏节点. 任何GUI也需要是一个单例；是 “世界” 的一个过渡部分；或者是作为根节点的直接子节点手动添加. 否则,GUI节点也会在场景转换时自行删除. 自动加载与普通节点。 SceneTree 中应有其自己的部分. 仅在节点是其父级的有效元素的情况下, 才应使用父子关系. 合理地移除父级是否意味着也应删除子级？如果没有, 那么它应在层次结构中有自己的位置, 作为同级关系或其他关系. 注解 RemoteTransform / RemoteTransform2D 节点. 它们将允许目标节点有条件地, 从 Remote* 节点继承选定的转换元素. 要分配 目标 NodePath, 请使用以下方法之一:
  4. 一个可靠的第三方, 可能是一个父节点, 来协调分配任务.
  5. 一个编组, 轻松提取对所需节点的引用(假设只有一个目标). 什么时候应该这样做呢？嗯, 这是主观的. 当一个节点必须在SceneTree[场景树]上移动以保护自己时, 就会出现两难的局面. 例如…
  • 玩家 节点到一个 房间.
  • 房间, 因此必须删除当前 房间.

  • 房间 之前, 必须保存和/或移动 玩家. 需要关心内存吗？

  • 房间, 移动 玩家 并删除旧的那个. 没有问题.

如果是这样, 那么需要…

  • 玩家 移动到树的其他位置.
  • 房间.
  • 房间.
  • 玩家. 知道 需要以这种方式处理项目中的角色. 因此, 作为一个团队可靠地分享这些信息的唯一方法就是 文档化 . 而将实现细节保留在文档中是很危险的, 它是一种维护负担, 使代码可读性下降, 不必要地膨胀项目的知识内容. 在拥有更多的素材的, 更复杂的游戏, 简单地将玩家完全保留在 SceneTree 中的其他地方会更好. 这样的好处是:
  1. 更多的一致性.
  2. 特殊情况.
  3. 因为没有考虑这些细节, 所以没有机会发生错误. 不 继承父节点的转换, 那么具有以下选项:
  4. 声明性 解决方案: 在它们之间放置一个 Node . 作为没有转换的节点, 节点不会将这些信息传递给其子节点.
  5. 命令性 解决方案: 对 CanvasItem 或者 Spatial 节点, 使用 set_as_toplevel 设值函数. 这将使节点忽略其继承的转换. 注解 玩家 相关, 而哪些只与权威服务器相关. 例如, 用户并不需要所有人都拥有每个 玩家 的 PlayerController 逻辑的副本. 相反, 他们只需要自己的. 这样, 将它们保持在从 世界 分离的独立的分支中, 可以帮助简化游戏连接等的管理. The key to scene organization is to consider the SceneTree in relational terms rather than spatial terms. Are the nodes dependent on their parent’s existence? If not, then they can thrive all by themselves somewhere else. If they are dependent, then it stands to reason that they should be children of that parent (and likely part of that parent’s scene if they aren’t already). 这是否意味着节点本身就是组件？并不是这样.Godot的节点树形成的是聚合关系, 而不是组合关系. 虽然我们依旧可以灵活地移动节点, 但在默认情况下, 无需移动, 仍然是最好的选择.