这次来看一件事：在刚刚公布的 GMTK 游戏开发挑战赛引擎统计里，Godot 的使用数量第一次超过了 Unity。对于持续关注独立游戏开发社区的人来说，这确实是一个等了九年的反转信号。毕竟 Unity 从 2014 年开源引擎格局形成后，一直是中小团队和 Game Jam 场景里的默认选项。而这次，开源引擎在真实参赛作品数量上完成了反超。
这篇文章不打算只停留在“谁赢了”的讨论上。更值得做的是把 Godot 与 Unity 的差异重新梳理一遍：为什么 Godot 能在这个节点反超、它到底适合哪些人、从 Unity 转过来的开发者需要改什么、以及用两种引擎分别写一个小 Demo 时体感差距在哪。最后会给出选型建议和常见排错清单。
1. 核心能力速览
先把两个引擎的核心信息放在一起，方便快速判断。这里的数据和结论，来自公开资料与社区讨论，不一定代表所有场景，但方向上有明显差异。
| 对比项 | Godot 4.x | Unity 6.x |
|---|---|---|
| 项目类型 | 开源免费，无授权费 | 商业引擎，有免费版与付费订阅 |
| 源码开放 | 完全开放 | 不开放 |
| 主要脚本语言 | GDScript、C#（.NET 版） | C#，第三方方案可接 C++ |
| C# 支持 | 需要下载 .NET 版 Godot，编辑器内置 | 原生支持 |
| 引擎体积 | 约 50-100 MB，安装包很小 | 数 GB，含大量模块与模板 |
| 编辑器启动速度 | 明显更快 | 较慢 |
| 2D 开发 | 强项，内置像素、骨骼动画工具 | 2D 功能完整，但部分依赖插件 |
| 3D 开发 | SDFGI、体积雾、全局光等都有，但易用性仍在补齐 | 成熟，光照、地形、后处理体系完善 |
| 移动端导出 | 支持 Android、iOS | 支持 Android、iOS |
| 控制台平台 | 需获取许可与源码自行构建 | 官方渠道支持 |
| 适合场景 | 2D 游戏、独立游戏、Game Jam、教学 | 3D 游戏、商业项目、跨平台大项目 |
| 官方素材商店 | 有，但生态小很多 | Asset Store 生态成熟 |
| 社区学习资料 | 教程增长很快，但中文本地资料仍少于 Unity | 中文资料和培训机构较多 |
单看这张表，可能觉得两者差距不大。但真正拉开使用体感的是语言生态、资源占用和安装部署方式。下面分点展开。
2. GMTK 挑战赛与 Godot 反超为什么值得关注
GMTK 游戏开发挑战赛是 Game Maker's Toolkit 频道举办的限时 Game Jam，主题每年不同，开发者需要在规定时间内提交完整可玩作品。它对引擎选择没有任何限制，所以统计结果能比较真实地反映独立开发者的日常选择。
过去九年里，Unity 在该赛事中几乎一直占据首位。而这次公开统计显示 Godot 超过 Unity，从传播角度看，这是开源引擎第一次在“参赛作品数量”这个维度上压过商业引擎。为什么会发生这个变化？
首先是 License 信任问题。2023 年后 Unity 的运行时费用政策引发大量开发者的迁移讨论。虽然 Unity 后来调整了方案，但信任裂痕已经留下。很多小型团队和独立开发者开始认真评估开源替代方案，Godot 是接受度最高的一个。
其次是 Godot 4 里程碑版本的功能补齐。光照、体积雾、SDFGI、骨骼动画、导航网格等模块在 Godot 4 之后达到可用状态。对 2D 开发者来说，Godot 一直很顺手；对 3D 开发者来说，Godot 4 终于值得认真尝试。
第三是 Jam 场景的“轻量优势”。Game Jam 只有几天时间，引擎下载体积、启动速度、脚本迭代节奏都会影响体验。Godot 编辑器体积小、启动快，模板项目没有额外负担，创作流程更集中在代码和场景本身。
这些因素叠加，让 Godot 在独立开发者的 Game Jam 场景中出现了明显增长。当然，这并不等于 Godot 已经全面取代 Unity。商业项目、3A 团队、控制台平台、大型招聘市场仍然是 Unity 的地盘。这次反超更像是一个趋势节点，而不是终局。
3. 编程语言差异：GDScript、C# 与 C++ 的选择逻辑
标题里的 #C 标签，对应的是两个引擎都绕不开的 C# 话题。
3.1 GDScript：Godot 的轻量主力语言
GDScript 是 Godot 内置的脚本语言，语法接近 Python。它绑定编辑器深度非常好，节点路径、信号、场景引用都能直接用语言关键字表达，写起来比 C# 更简洁。
下面是一段 GDScript 示例，让角色按方向键移动：
extends CharacterBody2D @export var move_speed := 200.0 func _physics_process(delta: float) -> void: var input_dir := Vector2.ZERO if Input.is_action_pressed("ui_right"): input_dir.x += 1 if Input.is_action_pressed("ui_left"): input_dir.x -= 1 if Input.is_action_pressed("ui_down"): input_dir.y += 1 if Input.is_action_pressed("ui_up"): input_dir.y -= 1 velocity = input_dir.normalized() * move_speed move_and_slide()这段代码的关键点是：
extends CharacterBody2D声明节点类型。@export把变量暴露到编辑器面板，方便调参。_physics_process是物理帧回调，适合处理移动。move_and_slide()是 Godot 内置的运动方法，自动处理碰撞滑动。
GDScript 的缺点是生态相对封闭。如果你只写 Godot，问题不大；如果以后想转别的引擎团队，GDScript 经验很难迁移。
3.2 C#：Godot 与 Unity 的最大交汇点
Godot 提供了一个 .NET 版本，支持用 C# 编写游戏逻辑。这对 Unity 开发者来说，迁移成本大幅降低。
同一段移动逻辑，用 Godot C# 写法是这样：
using Godot; public partial class Player : CharacterBody2D { [Export] public float MoveSpeed { get; set; } = 200.0f; public override void _PhysicsProcess(double delta) { Vector2 inputDir = Vector2.Zero; if (Input.IsActionPressed("ui_right")) { inputDir.X += 1; } if (Input.IsActionPressed("ui_left")) { inputDir.X -= 1; } if (Input.IsActionPressed("ui_down")) { inputDir.Y += 1; } if (Input.IsActionPressed("ui_up")) { inputDir.Y -= 1; } Velocity = inputDir.Normalized() * MoveSpeed; MoveAndSlide(); } }对照起来可以发现，Godot C# API 和 Unity 的 MonoBehaviour 模型存在明显差异：
- Godot 使用
CharacterBody2D节点和_PhysicsProcess回调，Unity 使用MonoBehaviour和FixedUpdate。 - Godot 的属性导出用
[Export]，Unity 用[SerializeField]。 - Godot 没有
Update与FixedUpdate的区分习惯，统一用_Process和_PhysicsProcess。 - Godot 节点直接挂到场景树上，Unity 是组件挂在 GameObject 上。
C# 开发者转到 Godot，API 层面需要重新记忆，但语言层没有障碍。这一点对从 Unity 跳出来的团队非常友好。
3.3 C++ 的插件角色
很多初学者以为 Godot 主要用 C++，其实不是。Godot 引擎本体用 C++ 编写，但普通游戏逻辑不需要写 C++。只有需要编写性能关键模块、自定义引擎功能或编写 GDExtension 插件时，才会用到 C++。
Unity 的情况类似。虽然核心引擎是 C++，但大多数游戏开发者在 Unity 中只写 C#。所以日常开发中，两个引擎的对标语言其实是 C#。
4. Godot 与 Unity 的安装部署体验
安装体验对初学者影响很大。很多人在布置开发环境时，会在“下载引擎”这一步就被劝退。
4.1 Godot 安装方式
Godot 的安装非常简单，核心思路是：下载标准版或 .NET 版解压即用，不需要安装器。
# 示例：把 Godot 解压到应用目录 # 下载地址为官网 https://godotengine.org/download tar -xzf Godot_v4.3-stable_linux.x86_64.zip ./Godot_v4.3-stable_linux.x86_64Windows 用户直接下载.exe文件双击运行即可，免安装。如果你用 C#，需要先安装对应版本的 .NET SDK，并确保 Godot 下载的是 .NET 版。首次启动后，直接进入项目管理器，可新建项目。
Godot 编辑器自带代码编辑器，不需要额外装 VS Code。这是它与 Unity 一个很大的体验差异。
4.2 Unity 安装方式
Unity 需要安装 Unity Hub，通过 Hub 管理多个编辑器版本。安装步骤明显更重，中间需要登录 Unity 账号，选择安装模块，包括 Android Build Support、Documentation 等。完整安装可能占用数 GB 空间。
安装完成后，首次创建项目还会运行编译与包恢复，等待时间比 Godot 长。
对比下来，Godot 更适合“快速打开编辑器写一个测试原型”的场景，Unity 更适合需要完整工程模板和跨平台构建配置的项目。
4.3 环境准备通用检查清单
无论是用哪个引擎，建议按以下清单检查环境：
| 检查项 | Godot | Unity |
|---|---|---|
| 操作系统 | Windows / macOS / Linux | Windows / macOS / Linux |
| 显卡驱动 | 建议 OpenGL 4.3 或 Vulkan 1.0 以上 | 建议同一级别的驱动支持 |
| .NET 环境 | 仅 C# 版本需要 .NET SDK | 需要 .NET 与构建工具 |
| 磁盘空间 | 500 MB 以内足够 | 建议预留 10 GB 以上 |
| 内存 | 8 GB 起步 | 16 GB 更稳 |
| 端口 | 默认不依赖本地端口 | 部分构建工具可能占用本地端口 |
安装时如果遇到下载慢、依赖缺失、构建失败，先看官方文档，再检查系统版本是否满足要求。
5. 本地创建一个最小 Demo 并跑通
下面用 Godot 完成一个最小验证流程。这套流程可以快速检验：编辑器是否正常、脚本是否生效、导出流程是否通。具体以 Godot 4.3 版本为例，其他 4.x 版本操作基本一致。
5.1 新建项目
打开 Godot，点击 New Project，输入项目名称，选择路径，渲染器选择 Forward Plus，点击 Create。
5.2 添加场景与脚本
在 FileSystem 面板右键，新建一个 2D 场景，命名为Main.tscn。双击打开场景，点击左侧“+”按钮，添加一个CharacterBody2D节点，命名为Player。
选中 Player 节点，点击“新建脚本”图标，脚本语言选择 GDScript 或 C#，保存后进入脚本编辑器。
写入上一节给出的移动代码，保存。
5.3 运行验证
点击编辑器右上角的运行按钮，运行当前场景。运行后，用方向键控制角色移动，并在输出面板观察是否有报错。
如果一切正常，说明最小 Demo 已经跑通。
5.4 导出桌面平台
点击 Project -> Export，选择 Windows Desktop。第一次导出会提示添加 export preset，按提示添加，然后选择目标目录导出。导出的.exe文件可以脱离编辑器独立运行。
到这里，一个最小练习流程就结束了。整个过程从下载到跑通，通常远快于 Unity 的首次体验，这也是 Godot 在 Jam 场景中快速被接受的原因之一。
6. 从 Unity 转到 Godot 的关键差异
如果你已经在 Unity 中写过 Cocos、写过 C#，再转到 Godot，核心差异主要集中在调用方式和架构设计上。梳理如下：
| 关注点 | Unity | Godot |
|---|---|---|
| 场景架构 | 场景由 GameObject 与 Component 组合 | 场景由 Node 树组成，节点即逻辑单元 |
| 文件组织 | 场景、预制体、资源独立存储 | 场景是可复用的场景资源，也可内嵌子场景 |
| 生命周期 | Awake、Start、Update、FixedUpdate | _Ready、_Process、_PhysicsProcess |
| 资源加载 | Resources 与 Addressables | Resource 与打包时导入配置 |
| 物理系统 | PhysX（旧版）与 Unity Physics | Godot 内置 PhysicsServer |
| UI 系统 | UGUI / UI Toolkit | Control 节点体系 |
| 通信方式 | 组件查询、事件系统、消息系统 | 信号 Signal 为核心 |
Godot 节点即逻辑的设计，对 Unity 开发者来说需要一次思维转换。Unity 里习惯把逻辑拆成多个组件挂到同一个物体上；Godot 更倾向搭一棵节点树，每个节点负责明确的职责，节点之间通过信号通信。
这种差异在小型项目里更自然，但在大型多人协作项目里，需要提前约定节点组织规范，否则场景树很容易变成一棵没有边界的圣诞树。
7. 资源占用与性能观察
很多人关心本地开发时的资源占用。这里提供一个通用观察方法，不写具体数字，因为结果会因系统和项目规模差异很大。
7.1 如何观察资源占用
在导入项目、运行编辑器、加载场景这三个阶段，分别打开系统自带的任务管理器或性能监控工具，记录 CPU、GPU、内存的变化。
- 编辑器空闲时，资源占用低说明引擎本身轻量。
- 运行小 Demo 时，内存增长说明资源加载逻辑是否合理。
- 导出后的独立运行包，资源占用应与编辑器状态明显不同。
7.2 Godot 性能优化注意事项
Godot 4 支持 Forward+、Mobile 和 Compatibility 三种渲染方式。同一台机器上，三种渲染方式的显存占用差异很大。可依据目标平台选择合适模式：
- Forward+：适合桌面端，画质更好，但显存占用更高。
- Mobile：适合移动端，降低着色器复杂度。
- Compatibility：适合老旧显卡与 Web 导出，API 更保守。
如果遇到卡顿，优先降低窗口分辨率、关闭抗锯齿、减少实时光源数量。
7.3 Unity 性能优化注意事项
Unity 中的性能瓶颈更多来自脚本与资源加载。启用了过度复杂的实时阴影、光照贴图不烘焙、持续实例化对象等都会导致帧率波动。
在对比时，注意不要拿“Godot 对 2D 的优化”直接对比“Unity 对 3D 的优化”，两者侧重点不同。
8. 常见问题与排查方法
从 Godot 新手和 Unity 迁移者反馈看，下面几个问题出现频率较高。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Godot 打开后界面白屏 | 显卡驱动不支持 Vulkan 或 OpenGL | 查看官方日志，看版本兼容 | 改用 Compatibility 渲染器 |
| .NET 版 Godot 无法创建 C# 脚本 | 未安装对应 .NET SDK | 命令行运行dotnet --version验证 | 安装 .NET SDK 并重启编辑器 |
| 场景运行后节点不显示 | 场景没有设置为主场景 | 检查 Project Settings 中 Main Scene | 将当前场景设为主场景 |
| 导出 Windows 包失败 | 未配置导出模板 | 查看 Export Preset 设置 | 通过官方下载对应模板 |
| Unity 迁移的 C# 代码大量报错 | Godot API 与 Unity API 不兼容 | 查看编译器提示，定位调用方法 | 手动替换为 Godot 对应 API |
| 2D 物理碰撞不生效 | CollisionShape2D 与实际节点未对齐 | 查看调试绘制碰撞体显示 | 调整形状位置与大小 |
| 鼠标点击 UI 被场景物体拦截 | 缺少 GUI 输入处理 | 检查事件传播顺序 | 使用 Godot 信号或控制节点的输入处理 |
| 更新引擎版本后项目异常 | 旧版本项目与新版兼容性变化 | 查看项目日志 | 按官方迁移指南调整 |
如果启动后没有反应，可以先删掉项目临时缓存再重新打开。Godot 项目目录下的.godot文件夹有可能因版本升级导致异常，删掉后会自动重建。
9. 选型建议与最佳实践
面对 Godot 和 Unity 的选择，不需要盲目跟风。以下建议比较实用：
9.1 适合选择 Godot 的场景
- 2D 游戏或轻量 3D 原型。
- 需要快速迭代、频繁改代码的 Game Jam 或个人项目。
- 重视源码可控、希望完全免费开源的团队。
- 教学场景，学生可以用小体积安装包快速启动。
9.2 适合选择 Unity 的场景
- 中大型 3D 商业项目，需要大量美术资产与成熟插件。
- 控制台平台发行或需要完整的商业服务支持。
- 团队本身已经是 C# 技术栈，且希望过渡成本最低。
- 需要大型招聘市场，后续维护人力更容易找到。
9.3 最佳实践建议
- 不要同时铺开两个引擎学习。先选定一个方向，把一个小 Demo 做完整再切换。
- 保留一套最小可运行项目。每次升级引擎版本前，用最小项目验证兼容性。
- 如果从 Unity 转到 Godot，先把 C# 迁移能力验证通过，再做场景架构迁移。
- 项目文件按
maps、scripts、assets、exports分目录，避免资源管理混乱。 - 开源引擎不等于免责。使用第三方素材与插件时，仍然需要遵守许可证，注意合规要求。
- 在团队协作时，约定 Godot 场景树命名规则、脚本资源导入策略和版本控制方案，减少冲突。
10. 总结与下一步
这次 Godot 在 GMTK 游戏开发挑战赛中首次超过 Unity，本质上反映的是独立开发者对轻量、开源、可控工具的渴求。事件本身的含金量不在于“谁更优秀”，而在于游戏开发工具的使用门槛正在被重新定义。
如果你正在犹豫是否要上手 Godot，建议先下载官方最新版，新建一个 2D 项目，跑通角色移动、碰撞检测、场景切换和导出这四个步骤。整个过程用不了太久，但足以建立对 Godot 工作流的直接体感。
如果是为了 Unity 项目迁移，建议先在一个预留分支里验证 C# 脚本在 Godot 中的可运行性，再逐步迁移场景和资源。多数 Unity C# 代码无法直接复制通过，需要花时间熟悉 Godot 的节点与信号体系。
下一步可以继续关注两个引擎的新版本发布公告、GMTK 挑战赛历年的引擎使用统计，以及国内外独立开发社区的实战反馈。工具没有绝对的最好，只有更适合当前项目和团队的选择。
