
※Godot公式が配布しているのデモプロジェクト (最初の2Dゲーム)
Godot Engineについてご存知でしょうか?
2014年にオープンソース化されたMITライセンスのゲーム開発エンジンですが、近年注目された要因は2023年9月22日にUnityがインストールごとに料金を徴収する新料金プラン「Runtime Fee」を発表したことでした。この発表はコミュニティから大批判を受け、Unityは最終的に方針を撤回しましたが、この騒動をきっかけに多くの開発者がGodotへの移行を検討し、一気に知名度が上がりました。
私自身も以前から興味は持っていたものの、UnityやUnreal Engineでの開発に慣れていたためなかなか手が出せずにいました。しかし、近年Godotが順調に機能拡張を続けており、また気分転換という意味合いも込めて、本格的にGodot学習を開始してみることにしました。

※学習中のUdemyコース「Godot4: Build a 2D Action-Adventure Game (link)」
今回はUdemyの「Godot Engineで気軽に2Dゲームを作ろう」というコースを修了した感想と、主にUnity開発者視点でみたときのGodotに対する疑問点を自分の学習ノートを見ながらまとめたいと思います。
なお、私はあくまでGodot初学者です。Godotについて技術的アドバイスができるほどの知見はまだないですが、初学者だからこそ感じられる疑問点や感動などを記録しておくことで、これからGodotを学習し始める人の参考になればと考えています。
Godot Engineに対するQ&A

下記は自分がGodot学習前に書き記していた疑問に対する自問自答文です。
Q. Godot Engineって?
A. 2014年にオープンソース化されたゲーム開発エンジン。MITライセンスのため完全無料で利用可能。エンジン本体はC++製。
Q. UnityやUnreal Engineと比べた第一印象
A. エンジンが圧倒的に軽量(v4.4.1時点の実行ファイルは約149MB)。ただし日本語情報が少ない。
Q. Godotで作られた有名ゲームって?
A. 「Backpack Battles」、「Backshot Roulette」、「Unrailed 2: Back on Track」など。
Q. ノードベースってなに?
A. 例えば、物理判定のあるキャラクターを作成する場合、CharacterBody2Dというノードの中に、AnimatedSprite2Dというアニメーション用のノードと、CollisionShape2Dという衝突判定用ノードを設置する。Godotはこのようにノードをネストする形で個々の機能を作成していく。
Q. ノードベースって難しい?
A. 簡単。最初は戸惑うかもしれないが、Unityでコンポーネントをアタッチしていく感覚と同じ。
Q. ノードベースって自由度低そうじゃない?
A. 「ノード」と聞くとプリセット範囲でしか値が変更できないような窮屈なイメージがあったが、実際はノードを継承して様々な独自実装ができるので、コーディング体験はUnityやUnreal Engineと何も変わらない。自由。
Q. GDScriptって何?
A. PythonベースのGodot独自言語。開発には基本的にこれを使う。C#も使えるらしいけど、少なくとも基礎学習の範囲では素直にGDScriptで進めたほうが良い。構文もシンプルで理解しやすい。
※Godotで開発されたゲームについては、公式サイトのShowcaseページで一部を閲覧できます。各年度のまとめ動画がオススメです。
Godot基礎学習の開始
新しいゲームエンジンを学習するうえで、公式ドキュメントを確認したり、デモプロジェクトを動かしてみるのは非常に重要です。
私はそれに加えて、YouTubeやUdemyなどの動画チュートリアルを複数個完了させることで基礎を固めています。今回はUdemyにて「Godot Engineで気軽に2Dゲームを作ろう」という基礎に最適なコースを見つけました。これを6.5時間ほどかけて修了しました。

Godotの独自仕様については、ChatGPTやClaudeなどに「これはUnity/Unreal Engineで例えるとどのようなものか?」と質問しながら進めると基礎学習がはかどります。
・@exportは、UnityのSerializeFieldのようなもの
・get_tree().change_scene_to_file()は、UnityのSceneManager.LoadSceneのようなもの
もちろん細かい仕様は異なるとは思いますが、他のゲームエンジンの概念と紐づけることで理解が促進されます。
Udemy講座「Godot Engineで気軽に2Dゲームを作ろう」を学んだ感想

※コースの手順で作成できるゲームの完成形
カリキュラム概要
- Section 1-3: 基礎(プロジェクト設定、ノード・シーン理解)
- Section 4-5: 出力(Windows、Web向けビルド)
- Section 6-9: 2Dゲーム基礎(Player、Mob、HUD実装)
- Section 10: GDScript詳細
- Section 11-13: 高度な2D機能(迷路生成、シーン遷移)
- Section 14-18: システム機能(BGM、UI、データ保存、敵AI、射撃システム)
基礎にフォーカスされたコースで、Godotのインストール手順、セットアップ、エディタの見方、公式デモの実演、より実践的なオリジナルゲームの開発という流れで説明が進みます。1動画あたり1~5分で要点を簡潔に説明してくれるため、サクサクと内容を理解することができました。
オリジナルゲーム開発では、穴掘り法アルゴリズムを用いた迷路のプロシージャル生成、UI作成、データ保存、射撃システムなど、非常に実践的でツボを抑えた解説がされます。これによりタイトル、エリア選択、迷路、タイトルというゲームサイクルを構築することができます。

※穴掘り法アルゴリズムの実行ログ
Godotに興味はあるけどまだ触れたことがない、という人はこのコースから基礎学習を開始することをおすすめします。Godotの日本語情報は非常に少なく、ここまでキレイに整備されたカリキュラムは稀有なので、こうしたコースを 第一歩にしてから、より複雑な英語圏のGodotコースを受講するのが良いでしょう。
Udemyはかなり頻繁にセールをしているので、とりあえずお気に入りに登録して、セールのときに購入して空き時間に消化するというスタイルがオススメです。
▶︎ Godot Engineで気軽に2Dゲームを作ろう (Udemy)
ここからはコースの内容ではなく、Godotエンジンに初めて触れて驚いたことや、実際に学習を進めながらメモしたGodotとUnityの対応表などについてまとめてみます。
Godotに触れて感動したこと

このコースを通じて、Godotの設計思想の美しさを実感できました。特に印象的だったのは以下の点です:
- ノードシステムの直感性: 「ノード」と「シグナル」を使いこなせるようになるとGodotは超快適です。エンジン自体が軽量なので、UnityやUEのようにエディタのロードやコンパイルに時間を取られることなく、ガシガシとコードを書いて開発を進めることができます。シグナルは最初は混乱しますが、Unityなどでイベント駆動開発をしたことがある人ならすぐ理解できると思います。
- シーンの再利用性: GodotのシーンはUnity開発者ほど最初は混乱するかもしれませんが、実際の開発体験はUnityと大差ありません。例えば、Unityでは全体管理用のGameManagerというスクリプトをアタッチした空のGameObjectをPrefab化してシーンに配置すると思います。Godotは空のシーンは作れないので、最も軽量なMaker2DというノードにGameManagerスクリプトをアタッチし、そのシーンを別シーンに配置することで再利用することができます。また、グローバル設定にシーンを登録することでシングルトン化することも可能です。つまり、最初の混乱を乗り越えたら、既存のUnity知識がGodot理解の助けになってくれます。
- 軽量な動作: Unreal Engineは言わずもがなですが、Unityでもプロジェクトを開くときに関連パッケージの読み込みに時間がかかることがあります(※Unity6でかなり改善された気はする)。ですがGodotはそもそものエンジンサイズが軽量で、公式サイトからダウンロードしたエディタの.exeをクリックするだけですぐにゲーム開発を再開できるのでストレスがありません。そのうえでしっかりとした開発機能はあるので、かなり面白いエンジンだなと思いました。
- 2D機能の充実: TileMapやAnimatedSprite2Dなど専用ノードの豊富さ
- AnimatedSprite2Dのスプライトシート制作が快適: UnityではスプライトシートをSliceして、個別画像をAnimatorコンポーネントなどに設定して~とかなり手間がかかります。しかしGodotはAnimatedSprite2DのSpriteでスプライトシートを選択してグリッドアイコンを押して、スプライトシートから必要な画像(例: 右歩行の差分4枚)をクリックしたら、即座にタイムラインにその画像が並びます。2Dゲーム開発者ならこの快適さが伝わるのではないでしょうか。
- タイルセット作成時の衝突判定設定が簡単: Unityではオートタイルの登録や衝突判定を設定してタイルシートを作成するのにかなり手間が必要です。一方、Godotではより直感的に進行可否部分を設定することができ、Physics Layerの設定でタイルごとの当たり判定を効率的に管理できます。複雑な設定なしに、視覚的にタイルの衝突範囲を決められるため、ストレスがほとんどありませんでした。
Unity開発者向け: Godotとのおおよその対応表

Unity開発者がGodotを学習する際に、概念的にあらかじめ知っておくと理解の助けになる対応表を作成しました。これから基礎学習を始める前にざっと目を通しておくことをおすすめします。
シーン・オブジェクト関連
- Godotのシーン ≒ UnityのPrefab + Scene
- get_tree().change_scene_to_file() ≒ SceneManager.LoadScene()
- $記法 / get_node() ≒ GameObject.Find() / FindObjectOfType()
- get_parent() ≒ transform.parent
ライフサイクル関連
- _ready() ≒ Start()
- _process() ≒ Update()
- _physics_process() ≒ FixedUpdate()
UI・表示関連
- CanvasLayer ≒ Canvas (Sorting Order)
- Control ≒ UI GameObject
- Label ≒ Text (TextMeshPro)
イベント・通信関連
- シグナル ≒ UnityEvent / C# Event
- emit_signal() ≒ event.Invoke()
その他の基礎機能
- @export ≒ [SerializeField]
- @onready ≒ Awake() / Start()
- AutoLoad ≒ DontDestroyOnLoad
- load() ≒ Resources.Load()
Unity開発者向け: コードで見るGodotとUnityの違い
Unity開発者が最も気になるであろう、実際のコードの記述スタイルの違いをいくつかの例で見てみましょう。
例1:変数の公開と初期化 (`@export` vs `[SerializeField]`)
インスペクターで値を調整できるように変数を公開し、ゲーム開始時にその値をコンソールに出力する基本的な処理です。
Godot (GDScript)
# Player.gd
extends Node2D
@export var player_name: String = "Hero"
@export var speed: int = 100
# UnityのStart()に相当
func _ready():
print("Player Name: ", player_name)
print("Initial Speed: ", speed)
Unity (C#)
// Player.cs
using UnityEngine;
public class Player : MonoBehaviour
{
[SerializeField] private string playerName = "Hero";
[SerializeField] private int speed = 100;
// Godotの_ready()に相当
void Start()
{
Debug.Log("Player Name: " + playerName);
Debug.Log("Initial Speed: " + speed);
}
}
例2:毎フレームの処理 (`_process` vs `Update`)
オブジェクトを右に移動させ続ける処理です。`delta` (Unityの `Time.deltaTime`) の使い方が分かります。
Godot (GDScript)
# Mover.gd
extends Sprite2D
@export var move_speed: float = 200.0
# UnityのUpdate()に相当
func _process(delta):
position.x += move_speed * delta
Unity (C#)
// Mover.cs
using UnityEngine;
public class Mover : MonoBehaviour
{
[SerializeField] private float moveSpeed = 200.0f;
// Godotの_process()に相当
void Update()
{
transform.position += new Vector3(moveSpeed * Time.deltaTime, 0, 0);
}
}
例3:物理演算の処理 (`_physics_process` vs `FixedUpdate`)
入力に応じて物理的にキャラクターを動かす処理です。
Godot (GDScript)
# Character.gd
extends CharacterBody2D
const SPEED = 300.0
# UnityのFixedUpdate()に相当
func _physics_process(delta):
var direction = Input.get_axis("ui_left", "ui_right")
velocity.x = direction * SPEED
move_and_slide() # Godotの便利な組み込み関数
Unity (C#)
// Character.cs
using UnityEngine;
[RequireComponent(typeof(Rigidbody2D))]
public class Character : MonoBehaviour
{
[SerializeField] private float speed = 300.0f;
private Rigidbody2D rb;
void Start()
{
rb = GetComponent<Rigidbody2D>();
}
// Godotの_physics_process()に相当
void FixedUpdate()
{
float moveInput = Input.GetAxis("Horizontal");
rb.velocity = new Vector2(moveInput * speed, rb.velocity.y);
}
}
例4:ノード(オブジェクト)の取得 (`$` vs `GetComponent/transform.Find`)
子ノード(子オブジェクト)を取得して、そのプロパティを変更する処理です。
Godot (GDScript)
# Player.gd
extends Node2D
func _ready():
# $記法で子ノードに直接アクセス
$AnimatedSprite2D.play("run")
# get_node() を使う方法もある
var collision_shape = get_node("CollisionShape2D")
collision_shape.disabled = true
Unity (C#)
// Player.cs
using UnityEngine;
public class Player : MonoBehaviour
{
void Start()
{
// 子オブジェクトからコンポーネントを取得
Animator animator = GetComponentInChildren<Animator>();
if (animator != null)
{
animator.Play("run");
}
// 名前で子オブジェクトを探す場合
Transform collisionShape = transform.Find("CollisionShape");
if (collisionShape != null)
{
collisionShape.gameObject.SetActive(false);
}
}
}
例5:シグナル(イベント)の使用 (`signal` vs `UnityEvent`)
体力が変化した時に他のオブジェクトに通知する処理です。
Godot (GDScript)
# Player.gd
extends Node2D
signal health_changed(new_health)
var health: int = 100
func take_damage(damage: int):
health -= damage
health_changed.emit(health) # シグナル発信
# UI.gd
extends Control
func _ready():
var player = get_node("../Player")
player.health_changed.connect(_on_health_changed)
func _on_health_changed(new_health: int):
print("体力が ", new_health, " になりました")
Unity (C#)
// Player.cs
using UnityEngine;
using UnityEngine.Events;
public class Player : MonoBehaviour
{
[SerializeField] private UnityEvent<int> onHealthChanged;
private int health = 100;
public void TakeDamage(int damage)
{
health -= damage;
onHealthChanged?.Invoke(health); // イベント発信
}
}
// UI.cs
using UnityEngine;
public class UI : MonoBehaviour
{
[SerializeField] private Player player;
void Start()
{
player.onHealthChanged.AddListener(OnHealthChanged);
}
private void OnHealthChanged(int newHealth)
{
Debug.Log("体力が " + newHealth + " になりました");
}
}
例6:シーン切り替え (`change_scene_to_file` vs `SceneManager.LoadScene`)
ゲームクリア時に次のレベルに移動する処理です。
Godot (GDScript)
# GameManager.gd
extends Node
func level_complete():
print("レベル クリア!")
get_tree().change_scene_to_file("res://scenes/Level2.tscn")
Unity (C#)
// GameManager.cs
using UnityEngine;
using UnityEngine.SceneManagement;
public class GameManager : MonoBehaviour
{
public void LevelComplete()
{
Debug.Log("レベルクリア!");
SceneManager.LoadScene("Level2");
}
}
まとめ
今回は「Godot Engineで気軽に2Dゲームを作ろう」コースを通じて、Godotの真価を実感することができました。
結論から言うと、ノードベースシステムのGodotは、特に2D開発者にかなりおすすめできるゲームエンジンだと感じました。私はUnityやUnreal Engineにおける2Dゲーム開発の方法を一通り学んでいますが、Godotは主に2Dスプライトやタイルセット管理でかなりの優位性があるように感じています。純粋な2DゲームはGodot、HD-2Dなどライティング演出にこだわりたいならUnityという使い分けが良いのかなと思案中です。
今回は初学者なりにGodotの魅力をまとめてみましたが、エンジンとしてのクオリティでいえば、UnityやUnreal Engineのほうが現状は圧倒的に上です。関連情報やノウハウの量、Unity StoreやFabなどのストア環境、商業ゲームにおける採用実績などでは、Godotはまだまだ駆け出しエンジンといえるでしょう。
ただし、現状普通に楽しく開発できるだけのクオリティになっているGodotには可能性を感じます。
「Backpack Battles」や「Backshot Roulette」など「えっ、あれってGodot製だったの?」というゲームも少しずつ増えていっている印象です。UnityのRuntime Fee騒動のときに間違いなく一定数の開発者はGodotに移行したはずなので、彼らの作品が完成して注目されれば、Godotシェアも今後伸びていく可能性はあるでしょう。
オープンソースというのが非常にユニークな点です。かつてMayaや3dsMaxが覇権を握っていた3DCG業界が、いつのまにかBlenderに支配されているのを見ると、Godotも化けるかも…?と想像してしまいます。(※Blenderの急速進化が30万円以上する3DCGソフトしかマトモな制作環境がなかったことへの改善圧だと考えると、UnityやUnreal Engineは億単位の収益を稼ぐまでは基本無料なので、Blenderと同じ文脈で進化することはなさそう?やはりRuntime Free騒動のようにUnityかUnreal Engineが批判を受けるたびに利用者を吸収する受け皿として成長していく予感がする。)
とはいえ私はUnityもUnreal Engineにも引き続き触れていきます。Godotは第三の選択肢になり得るポテンシャルがあると確認できただけも収穫です。
ノードベースシステムは、UnityともUnreal Engineとも異なる開発体験が味わえるので、興味があればぜひ触れてみてください。
今後もGodotに関する学習メモを定期的に記事にしつつ、日本におけるGodot情報不足の解消に微力ながら協力していければなと考えています。