Godot 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 這類低成本模型反而會很香。