Godot 技术实践（一）：用场景树把游戏当成可组合的程序

很多人第一次打开 Godot，会把它理解成“带节点树的 Unity 替代品”。这个理解能帮你点开编辑器，但解释不了后面最常见的三个问题：为什么改了一个场景，实例全变了；为什么信号连上了却收不到；为什么把逻辑写进根节点之后，项目会迅速变成一棵无法移动的大树。

Godot 4 真正值得先建立的，不是菜单在哪，而是把游戏看成一棵运行时的场景树：节点是对象，场景是可复用的子树，信号是节点之间约定好的事件接口。

本文是 Godot 技术实践系列第 1 篇。下一篇：用状态机把 2D 角色做成可维护的循环

一、先记住三个词

1. Node：只负责一件事

场景树里的每个节点都应该有清楚的职责。CharacterBody2D 处理移动与碰撞，Sprite2D 负责显示，CollisionShape2D 提供形状，AnimationPlayer 播放动画，Camera2D 决定镜头。把这些能力塞进同一个脚本里，短期更快，长期一定难拆。

一个实用的判断标准：如果这个节点被单独拖到别的场景，它是否仍然说得通？说得通，说明职责清楚；必须连同十几个兄弟节点一起搬，说明你在用场景树模拟“大类继承”。

2. Scene：可实例化的子树

场景不是文件夹，也不是关卡的同义词。它是一份 PackedScene：一棵被保存下来的节点树，可以在编辑器里打开，也可以在运行时 instantiate()。

玩家、子弹、宝箱、UI 弹窗，都应该是独立场景。关卡场景负责把它们摆进去，而不是在关卡脚本里 new 出一整套节点。

上图对应一个很常见的 2D 开场结构：

World (Node2D)
├── Player (CharacterBody2D)          # 独立场景
│   ├── Sprite2D
│   ├── CollisionShape2D
│   └── Camera2D
├── TileMapLayer
└── HUD (CanvasLayer)                 # 独立场景

Player.tscn 被改动后，所有实例同步更新。这是 Godot 组合模型的核心收益，也是它和“在关卡里现场搭角色”最大的差别。

3. Signal：约定事件，而不是互相查找

节点之间不要靠 get_parent().get_node("...") 层层翻找。能用信号说清楚的事情，就不要用节点路径耦合。

玩家受伤、敌人死亡、宝箱打开、关卡完成，都适合做成信号。发出信号的节点不需要知道谁在听；监听方也不需要知道发射方内部有哪些子节点。

二、用最小场景跑通一次循环

新建 Godot 4 项目后，先不要急着做完整角色控制器。用下面这个结构确认“场景能实例化、信号能连通、输入能响应”：

1. 创建 player.tscn，根节点为 CharacterBody2D，脚本如下：

extends CharacterBody2D

signal hit(amount: int)

@export var speed := 220.0
@export var max_health := 3

var health := 0

func _ready() -> void:
    health = max_health

func _physics_process(delta: float) -> void:
    var direction := Input.get_vector("move_left", "move_right", "move_up", "move_down")
    velocity = direction * speed
    move_and_slide()

func take_damage(amount: int) -> void:
    health = max(health - amount, 0)
    hit.emit(amount)
    if health == 0:
        queue_free()

2. 在项目设置里添加 move_* 四个动作，绑定 WASD 或方向键。
3. 创建 world.tscn 作为主场景，实例化 player.tscn，再放一个 Label 监听 hit：

extends Node2D

@onready var player: CharacterBody2D = $Player
@onready var hp_label: Label = $HUD/HPLabel

func _ready() -> void:
    player.hit.connect(_on_player_hit)
    _on_player_hit(0)

func _on_player_hit(_amount: int) -> void:
    hp_label.text = "HP %d" % player.health

这一步的目标不是手感，而是确认三件事同时成立：场景可复用、物理帧在跑、信号能更新 UI。官方的场景与节点说明把同一套关系写得更细，值得对照着看。

三、编辑器里最容易踩的四个坑

1. 把关卡当成唯一场景。 角色、子弹、UI 全写在 world.tscn 里，项目过了两周就无法拆关卡。
2. 用节点路径当 API。 $"../Enemy/Hitbox" 能工作，但敌人场景一改结构，调用方全部报错。
3. 在 _ready() 里假设子节点已经全部就绪。 父节点的 _ready() 会等子节点 _ready() 完成；跨场景查找时，对方可能还没进树。需要对方数据时，优先等信号，或使用 call_deferred()。
4. 把 @onready 当成“一定存在”。 节点改名或场景没挂上时，它只是默默变成 null。关键引用更适合 @export 拖进去，让缺失在编辑器里就暴露。

四、从第一天就可以养成的习惯

• 一个场景一个根职责。 Player 不要同时管地图生成。
• 对外只暴露信号和少量方法。 take_damage() 可以公开，内部动画切换不要公开。
• 能实例化的东西就做成场景。 复制节点树是临时方案，保存为场景才是结构。
• 命名跟职责走。 Hitbox、Sprite2D、Camera2D 比 Node2D2 有用得多。
• 先跑通主场景再堆系统。 没有可运行的入口，架构讨论没有锚点。

小结

Godot 的生产力和场景树是否被当成组合工具直接相关。节点负责一件事，场景负责复用一棵子树，信号负责跨节点通信。把这三件事摆正，后面的物理、动画、状态机和资源系统才有地方安放。

下一篇会在这个 Player 上继续：用 CharacterBody2D、碰撞层和有限状态机，把“能移动”推进到“可维护的角色循环”。

下一篇：Godot 技术实践（二）：用状态机把 2D 角色做成可维护的循环