游戏开发 on KnightLi的博客

Godot 游戏开发入门：从节点、场景到第一个 2D 小游戏

Sun, 17 May 2026 12:37:30 +0800

Godot 是一款开源游戏引擎，适合从 2D 小游戏、独立游戏原型，到中等规模的 3D 项目开发。

它最大的特点是轻量、开源、启动快，节点和场景系统非常清晰。对新手来说，Godot 的门槛通常比 Unity 低；对独立开发者来说，它不绑定商业授权模式，也更容易做出可控的小项目。

这篇文章用最少概念把 Godot 的入门路线讲清楚：你先理解节点和场景，再学 GDScript，最后用一个 2D 小游戏把输入、物理、碰撞、UI、音效和导出串起来。

先说结论

Godot 入门不要一上来就学大而全的引擎功能。

更合理的路线是：

先做 2D，不急着做 3D。
先理解节点和场景，不急着写复杂架构。
先学 GDScript，不急着上 C#。
先做一个能跑、能失败、能重开的小游戏。
再逐步补动画、音效、UI、关卡和导出。

只要做完一个完整小项目，你对 Godot 的理解会比刷十几个零散教程更稳。

Godot 适合什么人

Godot 很适合这几类人：

想从零开始学游戏开发。
想做 2D 独立游戏。
想快速做玩法原型。
不想被复杂商业引擎工具链压住。
想理解游戏引擎底层组织方式。
有一点 Python / JavaScript 经验，想快速上手脚本。

如果你的目标是大型 3A 画面、复杂商业团队管线、现成资产商店生态，Unity 或 Unreal 可能仍然更成熟。但如果目标是学习和做自己的游戏，Godot 非常适合起步。

安装和项目创建

Godot 的安装很简单。

到官网下载安装包，解压后直接运行即可。它不像很多大型引擎那样必须先装完整启动器，也不需要复杂账号流程。

新建项目时，建议先选：

Renderer：默认即可。
Project Name：用英文短横线或下划线。
路径：不要放在中文或空格特别多的目录里。
版本管理：建议从一开始就用 Git。

第一个项目可以叫：

`1`	`first-godot-game`

项目创建后，Godot 会进入编辑器。你需要先熟悉几个区域：

Scene：当前场景的节点树。
FileSystem：项目资源目录。
Inspector：选中节点的属性面板。
Script：脚本编辑区。
2D / 3D 视图：编辑画面和对象位置。

Godot 的核心：节点和场景

Godot 最重要的概念只有两个：节点和场景。

节点是功能单元。比如：

Node2D：2D 对象基础节点。
Sprite2D：显示图片。
CollisionShape2D：碰撞形状。
CharacterBody2D：可移动角色。
Camera2D：2D 摄像机。
AudioStreamPlayer：播放音频。
Label：显示文字。

场景是一组节点的组合。一个角色可以是一个场景，一个敌人可以是一个场景，一个关卡也可以是一个场景。

比如一个玩家角色场景可能长这样：

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

这棵树的意思是：玩家本体负责移动，Sprite2D 负责显示角色图片，CollisionShape2D 负责碰撞，Camera2D 跟随玩家。

Godot 的思路就是：把游戏拆成很多可复用场景，再把场景组合成完整游戏。

第一个 2D 项目做什么

新手第一个项目不要做 RPG、开放世界、联机游戏或复杂平台跳跃。

建议做一个最小 2D 闪避游戏：

玩家可以上下左右移动。
敌人从屏幕边缘出现。
玩家碰到敌人就失败。
存活时间越长分数越高。
有开始按钮、失败界面和重新开始。

这个项目很小，但能覆盖 Godot 入门最重要的东西：

角色移动。
输入系统。
碰撞检测。
敌人生成。
UI 显示。
定时器。
音效。
场景切换。

做完它，你就已经跨过了“只会看教程，不知道怎么组织项目”的第一道坎。

玩家移动怎么写

在 Godot 里，玩家角色通常用 CharacterBody2D。

给 Player 节点挂一个脚本：

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

这段代码做了几件事：

读取水平和垂直方向输入。
把方向向量归一化，避免斜向移动更快。
把方向乘以速度，得到 velocity。
用 move_and_slide() 让角色移动并处理碰撞。

还需要在 Project Settings 里设置输入：

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

Godot 的输入系统建议一开始就用 action，不要在代码里直接写死键盘按键。这样以后支持手柄、触屏或改键会方便很多。

碰撞和物理怎么理解

Godot 的碰撞不是只靠图片大小判断，而是靠碰撞形状。

常用节点有：

CollisionShape2D：给角色或敌人定义碰撞范围。
Area2D：检测进入、离开、重叠，适合触发器。
CharacterBody2D：适合玩家和会移动的角色。
RigidBody2D：适合受物理力影响的物体。
StaticBody2D：适合墙、地面、固定障碍。

入门阶段记住一个原则：

如果你要自己控制角色移动，用 CharacterBody2D。

如果你只想检测“玩家碰到敌人”，敌人可以用 Area2D，再监听信号：

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

后面项目变复杂时，可以改成发送 game_over 信号，而不是直接重载场景。新手阶段先跑通逻辑更重要。

场景实例化：让敌人不断出现

Godot 的场景可以当成“预制体”使用。

假设你有一个 Enemy.tscn，可以在主场景里用脚本生成它：

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

再配合 Timer 节点，每隔一段时间调用一次 spawn_enemy()，敌人就会不断生成。

这就是 Godot 项目常见组织方式：

一个场景负责一种对象。
主场景负责调度和组合。
需要时动态实例化子场景。

UI 和分数

Godot 的 UI 使用 Control 系列节点。

常用节点包括：

CanvasLayer：让 UI 固定在屏幕上，不跟随相机移动。
Label：显示文字。
Button：按钮。
Panel：面板背景。
VBoxContainer / HBoxContainer：自动排版。

分数可以先用存活时间来做：

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

这样每秒增加 1 分。后面可以改成击败敌人、收集金币或完成关卡加分。

音效和反馈

小游戏好不好玩，很大一部分来自反馈。

即使画面很简单，也要加：

移动或点击音效。
碰撞音效。
得分音效。
失败音效。
屏幕震动或闪烁。
按钮 hover / pressed 状态。

Godot 里可以用 AudioStreamPlayer 播放音效：

`1`	`$HitSound.play()`

新手常犯的错误是只做功能，不做反馈。功能能跑只是第一步，玩家能不能感到“我做了一个动作，游戏回应了我”，才是游戏体验的开始。

文件怎么组织

项目一开始就建议整理目录：

res://
├── scenes/
│   ├── Main.tscn
│   ├── Player.tscn
│   └── Enemy.tscn
├── scripts/
│   ├── player.gd
│   └── enemy.gd
├── assets/
│   ├── sprites/
│   └── audio/
└── ui/
    └── GameOver.tscn

不要把所有资源都丢在根目录。小游戏阶段无所谓，项目稍微大一点就会混乱。

一个简单原则是：

场景放 scenes/。
脚本放 scripts/。
图片和音频放 assets/。
UI 单独放 ui/。

Godot 新手常见坑

第一个坑：节点选错。

能自己控制移动的角色用 CharacterBody2D，不是随便用 Node2D。触发检测用 Area2D，固定障碍用 StaticBody2D。

第二个坑：忘记碰撞形状。

只有图片没有碰撞体，游戏不会知道它们撞上了。

第三个坑：把按键写死。

不要直接判断 KEY_A，用输入 action。

第四个坑：场景职责混乱。

不要让一个脚本同时管玩家、敌人、UI、音效和关卡。新手可以简单，但不要所有东西都堆在 Main.gd。

第五个坑：一开始就做大项目。

第一个项目越小越好。只要完整，有开始、有失败、有重新开始，就比半途而废的大项目更有价值。

Godot 和 Unity 怎么选

如果你主要做 2D 独立游戏、教学项目、个人原型，Godot 非常舒服。

如果你需要庞大的资产商店、成熟商业插件、移动广告和商业化 SDK、成熟团队经验，Unity 生态仍然更强。

如果你要做高规格 3D、复杂渲染、影视级画面，Unreal 更适合。

对新手来说，不要把选引擎变成拖延。Godot 足够你做出大量完整小游戏。你真正需要先学会的是：

游戏循环。
输入响应。
碰撞和反馈。
场景组织。
状态管理。
资源和版本管理。

这些能力换到其他引擎也能用。

第一个项目的完成标准

你可以用这个清单判断自己是否真的入门：

玩家能移动。
有敌人或障碍。
有碰撞失败。
有分数或目标。
有开始界面。
有失败界面。
能重新开始。
有至少两个音效。
有简单动画或视觉反馈。
能导出一个可运行版本。

做到这里，你就不是“打开过 Godot”，而是真的完成了一个游戏闭环。

总结

Godot 入门的关键，不是把所有功能看一遍，而是先理解它的组织方式：节点组成场景，场景组成游戏，脚本驱动行为，信号连接事件，资源通过目录管理。

第一个项目建议从 2D 小游戏开始。玩家移动、敌人生成、碰撞失败、UI 分数、音效反馈、重新开始，这几个环节跑通之后，再去学动画树、TileMap、存档、状态机、3D、Shader 和导出优化。

游戏开发不是先学完引擎再开始做，而是在做小项目的过程中反复补概念。Godot 的优势正好在这里：它足够轻，能让你很快从“想做游戏”走到“真的跑起来”。

DeepSeek V4 Flash 做 Godot 游戏 Demo：几毛钱能跑通到什么程度？

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash 用来开发 Godot 游戏 Demo，到底能不能打？

重点很直接：它能不能做出一个可运行、可观察、带物理效果的 Godot 小 Demo。

结论先说：可以跑通，效果不算商业级，但已经足够作为玩法原型和物理交互 Demo 使用。更重要的是，成本非常低，适合快速验证想法。

Demo 表现

这个 Demo 的重点是物理交互。

几个比较直观的效果包括：

绳子可以被切断。
箱子会掉到地上。
调大质量后，箱子碰撞会更猛烈。
绳子表现出比较明显的弹性。
调整摩擦力和弹性后，箱子会出现明显的滑动和反弹。

从呈现效果看，它已经不是“只生成几段 Godot 脚本”那么简单，而是一个能运行、能观察物理表现的小型原型。

可用程度

这个 Demo 的价值在于“能跑、能看、能改”。它不是完整游戏，也不是可以直接商业化的工程，但已经能说明几个问题：

DeepSeek V4 Flash 能理解 Godot Demo 的基本目标。
AI Agent 可以把需求转成可运行工程。
Godot 物理交互这种非网页类任务，已经可以进入低成本原型阶段。
对个人开发者来说，它能把“想法”快速变成“能看的东西”。

如果目标是做一个正式游戏，它当然还不够；但如果目标是验证“这个玩法有没有意思”“物理效果大概能不能做出来”，这个 Demo 已经可用。

成本意义

最值得关注的不是画面有多精致，而是成本。

如果一个 Godot 物理 Demo 只需要几毛钱级别的模型成本，就能得到一个可运行版本，那么它的意义就不是替代专业游戏开发，而是大幅降低原型试错成本。

以前想验证一个小游戏想法，至少需要自己熟悉 Godot、写脚本、调场景、调物理参数。现在可以先让 AI Agent 生成一个可运行版本，再由人判断方向对不对。

对独立开发者来说，这类低成本试错很有用：

快速验证玩法概念。
生成临时 Demo 给别人看。
探索 Godot API 和物理系统。
把想法转成能跑的初版工程。
在不确定方向前减少手写代码成本。

DeepSeek V4 Flash 的表现

比较值得注意的是，使用的是 DeepSeek V4 Flash，而不是更贵、更重的旗舰模型。

它在“低成本原型”这个定位上表现不错。它不是最强、最稳、最适合交付生产工程的模型，但在预算敏感、想快速试一下方向的场景里，很有吸引力。

适合什么场景

DeepSeek V4 Flash + Agent + Godot 更适合下面这些任务：

小型玩法原型。
物理效果 Demo。
UI 或交互概念验证。
教学示例。
辅助理解 Godot 项目结构。
生成第一版可运行工程。

不太适合直接承担这些任务：

大型游戏架构。
复杂角色控制器。
网络同步。
商业项目核心代码。
高精度物理模拟。
不经过人工测试的自动提交。

换句话说，它适合做“第一稿”和“试验场”，不适合当生产工程负责人。

这说明了什么

这说明，AI 编程正在从网页、脚本、后端接口，继续向游戏开发和交互原型扩展。

过去游戏开发的门槛很高，尤其是引擎、脚本、资源管理和物理系统混在一起时，新手很容易卡住。现在模型加 Agent 工具，可以先把工程搭起来，让开发者把注意力放在玩法判断和效果调优上。

它带来的变化可能有三点：

第一，游戏原型会更便宜。很多想法不用等到完整开发阶段才验证，可以先得到可运行 Demo。

第二，独立开发者会更敢尝试。不会 Godot 的人，也可以借助 AI 先摸到项目结构和基本流程。

第三，模型稳定性会变得更重要。游戏开发不是只要代码能跑，还要效果合理、手感正常、参数可控。未来谁能更好地结合实际画面和运行状态，谁就更适合做这类任务。

小结

DeepSeek V4 Flash 做 Godot Demo，可以概括成一句话：效果不完美，但足够便宜、足够快，也足够适合做原型。

它离商业游戏还很远，但如果目标是用极低成本验证一个小游戏想法，它已经很有价值。

对个人开发者来说，最现实的用法不是把游戏全交给 AI，而是让 AI 先给出能跑的工程，再由人负责判断、取舍和打磨。这样用，DeepSeek V4 Flash 这类低成本模型反而会很香。