Unity转Godot实战：用C#重制2D躲避游戏《Dodge the Creeps!》

1. 项目概述：为什么从Unity转向Godot？

最近我完成了一个小项目，把Unity官方那个经典的2D教程项目《Dodge the Creeps!》用Godot引擎和C#重新实现了一遍。这个决定听起来可能有点“折腾”，毕竟Unity的生态和成熟度有目共睹，但这次迁移的体验，却让我对Godot这个后起之秀有了全新的认识。如果你也在考虑引擎选型，或者对Godot的C#支持感到好奇，那么我这次从踩坑到上手的完整经历，或许能给你一些直接的参考。

简单来说，《Dodge the Creeps!》是一个顶视角的2D躲避游戏：玩家控制一个小人在屏幕中央移动，四面八方会不断生成“Creeps”（怪物）并向玩家靠近，玩家需要灵活走位避免被碰到，坚持的时间越久越好。这个项目麻雀虽小，五脏俱全，涵盖了2D游戏开发的核心流程：场景搭建、角色控制、碰撞检测、敌人生成与AI、UI（分数/生命值显示）以及游戏状态管理。在Unity里，你可能已经习惯了GameObject-Component（游戏对象-组件）模式，用C#脚本挂在物体上驱动一切。而在Godot里，你需要适应的是它独特的“场景即节点树”的架构。这次迁移，本质上就是一次思维模式的转换练习。

我选择用C#而不是GDScript（Godot的原生脚本语言）来开发，主要有几个考量。首先，我个人和团队对C#的熟悉度更高，从Unity转过来几乎没有语言障碍，能更快上手核心逻辑。其次，C#在性能敏感的场景下（虽然这个小游戏不敏感）和大型项目结构管理上，有其传统优势。最后，我也想亲自验证一下Godot对C#的支持到底到了什么程度，是否真的能用于严肃的、以C#为主的开发工作流。事实证明，Godot 4.x版本对C#的支持已经相当可靠，虽然仍有小坑，但整个开发体验是流畅且高效的。

2. 环境准备与项目初始化

2.1 Godot引擎与.NET环境的搭建

第一步当然是安装Godot。我直接从Godot官网下载了最新的稳定版（4.2.1）。这里有个关键选择：你需要下载Mono版本的Godot。标准版本只支持GDScript，而Mono版本内置了.NET运行时，才能支持C#开发。下载后是一个独立的可执行文件，无需安装，非常绿色。

接下来是配置.NET开发环境。Godot的C#支持依赖于.NET SDK。我使用的是.NET 8.0 SDK，这也是目前Godot官方推荐兼容的版本。你可以在微软官网下载并安装它。安装完成后，在命令行输入dotnet --version确认安装成功。这一步至关重要，没有正确的.NET SDK，Godot编辑器将无法创建或编译C#项目。

打开Godot Mono版本，新建项目时，需要注意一个重要的设置：渲染器。Godot 4提供了两种主要的2D渲染后端：Forward+和Compatibility。对于纯粹的2D像素风或风格化游戏，Compatibility渲染器是更好的选择。它更稳定，对2D功能的支持更完整，并且有更成熟的渲染管线。而Forward+更侧重于高端的3D渲染。我们的2D躲避游戏，毫无疑问应该选择“Compatibility”渲染器。项目创建好后，Godot会自动生成一个基本的项目结构，其中就包含一个.csproj（C#项目文件），这意味着你的C#脚本将能在这里被正确编译和引用。

注意：如果你在新建项目时忘了选择Mono版本，或者选错了渲染器，后续将无法添加C#脚本。一个稳妥的方法是，在创建项目后，立即在项目设置的“应用程序”->“运行”中，确认“主场景”已设置，并在“DotNet”设置中确认“程序集名称”等项目信息正确。这能避免后续出现诡异的编译错误。

2.2 理解Godot的核心概念：场景与节点树

从Unity转过来，第一个需要跨越的认知鸿沟就是Godot的“场景（Scene）”系统。在Unity中，场景（Scene）是一个容器，里面摆放着许多GameObject。在Godot中，场景是一切的核心，它本身就是一个可实例化、可复用的节点树。

你可以把Godot的场景理解为一个预制体（Prefab）和场景的融合体。场景中的根节点（Root Node）及其所有子节点，共同定义了一个完整的、可重用的游戏对象或功能模块。比如，一个“玩家”场景，其根节点可能是一个CharacterBody2D（用于物理移动和碰撞），下面挂着一个Sprite2D（显示图片）和一个CollisionShape2D（碰撞形状）。这个“玩家”场景可以被保存为一个.tscn文件，然后在主游戏场景中被多次实例化。

节点（Node）是Godot的基石，相当于Unity的Component，但更基础、更原子化。每个节点提供一项具体功能：Sprite2D负责显示纹理，CollisionShape2D负责定义物理形状，Timer负责计时功能。构建一个游戏对象，就是将这些功能节点像搭积木一样组合成一棵树。这种模式非常直观，尤其是在编辑器里，你可以清晰地看到对象的完整结构。

对于C#开发，每个节点都可以附加一个脚本。在Godot中为节点添加C#脚本时，编辑器会自动生成一个继承自该节点类型（如CharacterBody2D）的类。这是与Unity一个显著的不同：在Godot中，脚本是紧密绑定在特定节点类型上的，你无法将一个CharacterBody2D的脚本挂到Sprite2D节点上。这种强类型关联带来了更好的代码提示和安全性。

3. 核心场景构建与玩家角色实现

3.1 创建玩家场景与物理体设置

我们的玩家需要移动和碰撞，因此根节点选择CharacterBody2D。这是Godot 4中用于2D角色控制的核心节点，它内部集成了物理状态（速度、是否在地面等）和移动方法，比单纯的RigidBody2D（刚体）更适合由代码精确控制的角色。

1. 创建场景：新建一个场景，添加一个CharacterBody2D节点作为根，将其保存为Player.tscn。
2. 添加视觉表现：为CharacterBody2D添加一个子节点Sprite2D。将玩家角色的图片（例如一个圆形或小方块）拖入检查器（Inspector）中Sprite2D的“纹理”属性。在2D游戏中，处理好纹理的导入设置很重要。我通常将纹理的“导入”模式设置为“2D像素”，并关闭“过滤”，这样在像素风游戏中可以避免纹理模糊。
3. 添加碰撞形状：这是实现躲避逻辑的关键。为CharacterBody2D添加一个子节点CollisionShape2D。在其“形状”属性中，新建一个CircleShape2D（圆形碰撞体）或RectangleShape2D（矩形碰撞体），并调整大小使其与Sprite2D的视觉轮廓大致匹配。精确匹配碰撞体和视觉轮廓是2D游戏手感良好的基础，一个过大的碰撞体会让玩家感觉“被空气墙撞到”，体验很差。

3.2 使用C#编写玩家移动逻辑

为CharacterBody2D节点附加一个新的C#脚本，命名为Player.cs。Godot会自动生成类骨架。

using Godot; public partial class Player : CharacterBody2D { // 导出变量，可以在编辑器中实时调整 [Export] public int Speed { get; set; } = 400; public override void _PhysicsProcess(double delta) { // 1. 获取输入向量 Vector2 inputDirection = Input.GetVector("move_left", "move_right", "move_up", "move_down"); // 2. 计算速度 Velocity = inputDirection * Speed; // 3. 执行移动并处理碰撞 MoveAndSlide(); } }

这段代码是玩家控制的核心：

• [Export]属性：这是Godot C#的一个强大特性。它将Speed变量暴露在编辑器的检查器中，你可以不修改代码，直接拖动滑块或输入数值来调整玩家速度，实现快速迭代。
• _PhysicsProcess方法：在固定的物理时间步长（默认每秒60次）中被调用，是处理物理相关逻辑（如移动、碰撞）的最佳位置。delta是上一帧到这一帧的时间间隔。
• Input.GetVector：这是一个非常方便的方法，它根据你在“项目设置”->“输入映射”中定义的四个动作（如“move_left”对应A键/左箭头），返回一个归一化的二维方向向量。这意味着即使同时按下斜方向键，速度也不会叠加（向量长度不会超过1）。
• MoveAndSlide()：这是CharacterBody2D的“灵魂”方法。它根据当前Velocity移动角色，并自动处理与环境中其他PhysicsBody2D（如我们后面要加的敌人）的碰撞。如果发生碰撞，它会阻止角色穿透，并且你可以通过返回值获取碰撞信息。

实操心得：在Godot中设置输入映射比在代码里硬编码键位要灵活得多。你可以在“项目设置”里定义“move_left”动作，并为其分配多个输入源（如键盘A键、手柄左方向键）。这样，Input.GetVector会自动处理所有输入设备的适配，大大简化了多平台支持的工作。

3.3 限制玩家移动范围

在顶视角游戏中，我们通常不希望玩家跑出屏幕。这可以通过在_PhysicsProcess中移动后，对玩家的位置进行钳制（Clamp）来实现。

public override void _PhysicsProcess(double delta) { // ... 原有的移动代码 ... // 4. 限制玩家位置在屏幕范围内 var viewportRect = GetViewportRect(); GlobalPosition = GlobalPosition.Clamp(viewportRect.Position, viewportRect.End); }

GetViewportRect()获取当前游戏窗口的矩形区域。Clamp方法确保GlobalPosition（节点的全局位置）不会超出这个矩形的起始点和结束点。这里使用GlobalPosition而非Position是因为我们要限制的是在世界空间中的绝对位置，不受可能的父节点变换影响。

4. 敌人（Creeps）的生成与AI逻辑

4.1 设计可复用的敌人场景

敌人和玩家有很多相似之处：都需要视觉表现、碰撞体，以及移动逻辑。因此，我们也创建一个CharacterBody2D为根的场景Mob.tscn。同样添加Sprite2D（使用不同的颜色或图片区分）和CollisionShape2D。

敌人的移动AI很简单：生成后，朝着玩家的当前位置直线移动。为敌人的根节点创建C#脚本Mob.cs。

using Godot; public partial class Mob : CharacterBody2D { [Export] public int MinSpeed { get; set; } = 150; [Export] public int MaxSpeed { get; set; } = 250; private AnimationPlayer _animationPlayer; public override void _Ready() { // 获取动画节点，用于播放死亡动画 _animationPlayer = GetNode<AnimationPlayer>("AnimationPlayer"); } public void Initialize(Vector2 startPosition, Vector2 playerPosition) { GlobalPosition = startPosition; // 计算朝向玩家的方向并归一化 LookAt(playerPosition); // 设置一个随机速度 Velocity = (playerPosition - startPosition).Normalized() * GD.RandRange(MinSpeed, MaxSpeed); } public override void _PhysicsProcess(double delta) { MoveAndSlide(); // 简单处理：如果敌人移出屏幕，则删除它以释放资源 if (Position.X < -100 || Position.X > GetViewportRect().Size.X + 100 || Position.Y < -100 || Position.Y > GetViewportRect().Size.Y + 100) { QueueFree(); } } }

关键点解析：

• Initialize方法：这是一个自定义的初始化方法。因为敌人需要在生成时就知道玩家的位置，所以我们不在_Ready中设置速度，而是由生成它的“生成器”来调用Initialize，并传入生成位置和目标（玩家）位置。
• LookAt方法：让敌人节点旋转，使其正方向（通常是X轴正方向）指向玩家位置。如果你的敌人贴图有方向性，这会让它的朝向看起来更自然。
• QueueFree()：Godot中安全删除节点的方法。它会在当前帧的安全时间点将节点从场景树中移除并释放内存。直接调用RemoveChild或置空引用是不规范的做法。

4.2 实现敌人生成器（Spawner）

敌人不是预先放在场景里的，而是需要定时、在随机位置生成。我们创建一个名为MobSpawner的Node2D场景（它本身不需要视觉表现，只是一个逻辑节点）。

在这个场景中，我们需要：

1. 一个Timer节点，用于控制生成间隔。
2. 一个Path2D节点，定义敌人可能出现的生成路径（例如，围绕屏幕边缘的一个矩形路径）。
3. 在C#脚本中，加载敌人场景，并在计时器超时时，在路径上随机选取一个点生成敌人实例。

using Godot; public partial class MobSpawner : Node2D { [Export] public PackedScene MobScene { get; set; } [Export] public Path2D SpawnPath { get; set; } private Timer _spawnTimer; private PathFollow2D _pathFollow; private Node _player; public override void _Ready() { _spawnTimer = GetNode<Timer>("Timer"); _pathFollow = GetNode<PathFollow2D>("Path2D/PathFollow2D"); // 假设主场景中有一个名为“Player”的节点 _player = GetTree().Root.GetNode("Main/Player"); // 连接计时器的timeout信号到生成方法 _spawnTimer.Timeout += OnSpawnTimerTimeout; _spawnTimer.Start(); } private void OnSpawnTimerTimeout() { if (MobScene == null || _player == null) return; // 1. 实例化敌人 Mob mobInstance = MobScene.Instantiate<Mob>(); // 2. 设置生成位置：在路径上随机一个进度点 _pathFollow.ProgressRatio = GD.Randf(); Vector2 spawnPosition = _pathFollow.GlobalPosition; // 3. 初始化敌人（传入生成位置和玩家位置） mobInstance.Initialize(spawnPosition, _player.GlobalPosition); // 4. 将敌人添加到当前场景树中 GetParent().AddChild(mobInstance); } }

• PackedScene类型：这是Godot中保存的场景资源。在编辑器中，你可以将保存好的Mob.tscn文件拖拽到MobSpawner节点的MobScene属性上，完成关联。
• 信号（Signal）连接：Godot使用信号系统进行节点间通信，这是一种松耦合的观察者模式。这里我们将Timer节点的timeout信号连接到自定义的OnSpawnTimerTimeout方法。在C#中，使用+=操作符来连接信号非常直观。记得在节点被销毁时（如果需要）断开连接，不过对于这种生命周期同步的简单情况，Godot的垃圾回收会处理。
• Instantiate<T>()：这是从PackedScene创建场景实例的方法。使用泛型可以避免类型转换，更安全。

5. 游戏规则与UI界面实现

5.1 碰撞检测与游戏状态管理

玩家和敌人之间需要碰撞检测。我们已经为它们都添加了CollisionShape2D，并且它们都是CharacterBody2D。当MoveAndSlide()发生碰撞时，我们可以通过其返回值或通过Godot的信号系统来感知。

更常用的方法是使用区域（Area2D）节点。我们可以给玩家添加一个Area2D子节点，并为其赋予与碰撞体相同或略大的形状。然后，监听这个Area2D的body_entered信号。当任何PhysicsBody2D（如敌人）进入该区域时，就会触发信号。

1. 在Player.tscn中，为根节点添加一个Area2D子节点，并为它添加一个CollisionShape2D。
2. 在Player.cs脚本中连接信号并处理碰撞：

public override void _Ready() { GetNode<Area2D>("Area2D").BodyEntered += OnBodyEntered; } private void OnBodyEntered(Node2D body) { // 检查进入区域的是否是敌人（Mob） if (body is Mob) { // 玩家被击中，处理游戏逻辑：减少生命值、播放受击动画/音效等 EmitSignal(SignalName.Hit); // 发射一个自定义的“Hit”信号 // 可以添加一个短暂的无敌时间或击退效果 // ... } }

这里我们选择发射一个自定义的Hit信号，而不是直接在玩家脚本里修改游戏分数或生命值。这是为了遵循Godot倡导的松耦合设计。玩家的职责是移动和报告“我被打了”，而“被打之后游戏该做什么”（比如减命、判断游戏结束）应该由更上层的游戏管理器（Game Manager）来处理。

5.2 创建游戏管理器与UI

我们需要一个全局性的节点来管理游戏状态：分数、生命值、游戏开始/结束的逻辑。通常，我们会创建一个名为GameManager的Node（或Node2D）作为主场景的根节点，或者作为一个自动加载（AutoLoad）的单例。

同时，我们需要UI来显示分数和生命值。Godot的UI系统基于控件（Control）节点树，类似于其他GUI框架。

1. 创建UI场景：新建一个场景，根节点为CanvasLayer。CanvasLayer可以确保其下的所有UI控件渲染在游戏世界之上，并且不受摄像机影响。在这个层下，添加Label节点来显示分数和生命值。
2. 创建游戏管理器：创建一个GameManager.cs脚本，将其附加到主场景的一个节点上，或者设置为自动加载。
   • 在管理器中定义分数、生命值等变量。
   • 连接玩家发射的Hit信号。当收到信号时，减少生命值，更新UI。如果生命值归零，则触发游戏结束逻辑（显示“Game Over”画面，停止生成敌人等）。
   • 连接敌人被销毁的信号（例如，在敌人飞出屏幕QueueFree时，可以发射一个OnMobDestroyed信号），用于增加分数。
3. 更新UI：在游戏管理器中，每当分数或生命值变化，就更新对应的Label节点的Text属性。

// GameManager.cs 部分代码示例 public partial class GameManager : Node { private int _score = 0; private int _health = 3; [Export] private Label _scoreLabel; [Export] private Label _healthLabel; [Export] private PackedScene _gameOverScreen; public override void _Ready() { // 假设玩家节点路径已知，连接其Hit信号 var player = GetNode<Player>("../Player"); player.Hit += OnPlayerHit; } private void OnPlayerHit() { _health--; _healthLabel.Text = $"Health: {_health}"; if (_health <= 0) { GameOver(); } } private void GameOver() { // 停止敌人生成器的计时器 GetNode<MobSpawner>("../MobSpawner").GetNode<Timer>("Timer").Stop(); // 显示游戏结束界面 var gameOverInstance = _gameOverScreen.Instantiate(); AddChild(gameOverInstance); } }

6. 从开发到导出：全流程避坑指南

6.1 场景组织与信号通信的最佳实践

随着项目扩大，场景树会变得复杂。良好的组织习惯至关重要：

• 使用场景进行模块化：将玩家、敌人、UI元素、特效等都做成独立的场景（.tscn文件）。主场景（Main.tscn）只负责将这些模块实例化并组装起来。这极大提升了复用性和可维护性。
• 善用信号（Signal）：Godot的信号系统是其架构的精髓。尽量避免节点间直接的强引用调用（GetNode<...>(“../../SomeNode”)）。取而代之的是，让子节点发射信号，由父节点或管理者来监听和处理。这降低了耦合度，调试和修改都更方便。在C#中，使用[Signal]属性声明自定义信号，用EmitSignal发射，用+=连接。
• 合理使用组（Groups）：你可以给节点分配组名（如“enemies”、“collectibles”），然后通过GetTree().CallGroup(“group_name”, “method_name”)来批量调用方法。这在处理大量同类对象时非常高效，比如游戏结束时暂停所有敌人。

6.2 Godot C#开发的独特注意事项

1. 热重载（Hot Reload）：Godot对GDScript的热重载支持非常好，但对C#的支持还在完善中。很多时候，修改C#脚本后，需要手动停止并重新运行项目才能生效。一个变通方法是使用dotnet watch命令来监控和编译项目，但最稳定的方式还是养成“修改-编译-重启”的习惯。
2. 编辑器与代码的同步：在编辑器中重命名节点、变量或信号后，有时C#代码中的引用不会自动更新，可能导致编译错误或运行时错误。重命名后，务必检查相关C#代码，并手动更新字符串路径或标识符。
3. 资源路径：在C#代码中加载资源（如纹理、场景）时，使用GD.Load<PackedScene>(“res://path/to/scene.tscn”)。路径是相对于项目根目录的。确保资源文件已导入到项目中，否则在导出时这些资源会被遗漏。
4. 性能分析：Godot内置了性能分析器（调试器 -> 分析器）。对于C#项目，要特别关注垃圾回收（GC）的触发频率。避免在_Process或_PhysicsProcess中频繁分配新的对象（如new Vector2()），可以考虑对象池技术来重用敌人、子弹等对象。

6.3 导出项目为可执行文件

Godot的导出流程非常直观，但针对C#项目有一些额外步骤：

1. 配置导出预设：在“项目” -> “导出”中，添加一个导出预设（如“Windows Desktop”）。你需要下载对应的导出模板（对于C#项目是“Mono”版本的模板）。Godot编辑器会引导你完成下载。
2. 准备依赖项：C#项目导出后，其运行需要.NET运行时。在导出窗口的“架构”选项下，有一个“嵌入 .NET 运行时”的复选框。务必勾选它。这会将必要的.NET库打包进你的游戏可执行文件，确保在没有安装.NET的电脑上也能运行。这会使导出包体积增大（约30-40MB），但对于分发来说是必需的。
3. 执行导出：选择好输出路径和预设，点击“导出项目”。Godot会编译你的C#代码，并将所有资源、脚本和.NET运行时打包成一个独立的可执行文件（或平台特定的包，如APK）。
4. 测试导出包：永远不要假设导出包一定能运行。务必在目标平台（或虚拟机）上彻底测试导出的游戏。检查输入、音频、存档等功能是否全部正常。一个常见问题是资源路径大小写敏感（在Linux/macOS上），在代码中尽量使用一致的大小写。

6.4 迁移过程中的核心思维转换总结

回顾整个从Unity到Godot的迁移过程，最大的挑战和收获不在于语法，而在于思维模式的转换：

• 从“组件挂载”到“节点组合”：Unity鼓励你为一个GameObject挂载多个Component。Godot鼓励你将功能分解成更细粒度的节点，然后组合成树。思考方式从“这个对象需要什么功能组件”变成了“这个功能模块由哪些节点构成”。
• 从“序列化字段”到“导出变量”：Unity的[SerializeField]在Godot中对应[Export]，但Godot的集成更紧密，在编辑器中修改[Export]变量能立刻看到游戏运行时的变化（对于某些类型）。
• 从“SendMessage/Broadcast”到“信号系统”：Godot的信号系统是其架构的核心优势。它比Unity的SendMessage更高效、更类型安全（在C#中），也比基于接口或委托的解决方案更直观、与编辑器集成更好。花时间理解和习惯信号通信，是写好Godot代码的关键。
• 场景即预制体：在Godot中，每个场景天然就是可复用的预制体。这种一致性简化了工作流，你不再需要区分“场景文件”和“预制体文件”。

最终，这个用Godot和C#重制的《Dodge the Creeps!》运行流畅，代码结构清晰。虽然Godot的C#生态和工具链成熟度目前还不及Unity，但其简洁的设计、高效的编辑器、以及对独立开发者极其友好的MIT开源协议，都让它成为了一个非常有吸引力的选择。对于从Unity转来的开发者，尤其是那些对C#有偏好的团队，Godot 4的C#支持已经足够强大，可以承担起中小型2D/3D项目的开发工作。这次迁移更像是一次“降本增效”的探索——用更轻量的工具，同样能实现，甚至更优雅地实现游戏创意。