「Godot」0からゲーム作ろう! (導入: Godot基礎)
こんにちは. Coding課のAugustです.

本シリーズは, 完全に0から, あらゆる2Dゲームにも使われるエンジン機能や, ゲーム制作に欠かせない
- 信号(Signal, ~=UntiyのEvent System)
- キャラ操作
- Tweenの作り方
- User Interface
などを
Godotエンジンを使って解説したいと思います.
Unity達人でも, Godotエンジンでの制作流れをみて, 感じられるものがいるかもしれません.
初めて記事を書くので, はじめに, 「お前の記事信頼できるの?」という疑問をある程度打ち消すために, この前3週間わたって作った練習用ゲームのgifを見せたいと思います.

まぁ, まだまだ未解決なバグが残っているが, 初めてのGodotゲームなので無視して願いたい.
(ちなみに, このゲーム(練習用)のソースコードは, 2025年5月中半に公開する予定です)
今回公開する記事は, (本記事) Godotに関する一般的な解説から,
(紙数・テンポにより)次の記事からは
- キーボード・ゲームパッドでのキャラ操作の実装
- Signalを使って簡単な当たり判定
- Tweenを使ってUIを動かし, アイテム拾いのVisual Effectを作る
という順で進みます.
なお, もし 「このゲーム・この機能, どうやって作れる?」に対して興味を持つ方は, (複雑過ぎない機能かつ現段階2D限定)なら, Discordでメッセージくれたら次回の記事で作りたいと思います.
では早速始めましょう.
Godotエンジンはなに?
〜Unity・Unrealとの違いも含めて〜
ゲーム開発の世界には, さまざまなゲームエンジンが存在している. その中でも注目を集めているのがUnreal Engine (UE, C++言語), Unity (C#)と Godot(ゴドー)エンジン(GDscript, C#, C++)
Godotは無料・オープンソースのゲームエンジンであり, 2Dおよび3Dのゲーム開発に対応している. 特に, 初心者にも扱いやすい直感的なUIと, 軽量かつ高速な動作が特徴である.
軽量ってどのぐらいかというと,
具体的に, Godot v4.4.1のインストーラは約70MB, インストール後も100MB未満に収まる. 一方, Unity 6.1は標準構成で10GB前後を要し, 上記で貼り付ける2D練習ゲームのファイルサイズでもGodotが約30MBに対し, 去年作った2Dゲームでは, Unityは約1.5GBとなることもある.
ただし, 容量の大小は必ずしも機能の豊富さや性能を示すものではない. UnityやUnreal Engineは, 旧バージョンとの互換性, 多数のプラットフォーム対応, ビルトインパッケージやテンプレートなどを内包しており, その多くは実際のプロジェクトで使用されないまま常駐することがある. これがファイルサイズ増加(bloat)の主因である.
対照的に, Godotはモジュールベースかつミニマルな設計により, 必要最小限の構成で動作する. GDScriptのホットリロード機能により, ゲーム実行中のコード変更も即座に反映され(オプション), 軽快な開発体験を実現している.
「軽い=機能が乏しい」との見方も表面的であり, 実際にはGodotも2Dや小〜中規模の3D開発に必要な機能を一通り備えている. ファイルサイズは, 対象範囲や内部構造の違いを反映する指標であって, 直接的な機能性の優劣とは結びつかない.
むしろ, Godotの軽量性は, 開発サイクルの短縮やマシン負荷の低減といった実利面での優位性を生み出している.
主題に戻って,
現時点, 主要ゲームエンジンの現状は, 概ね以下になる:
項目 | Godot | Unity | Unreal Engine |
---|---|---|---|
ライセンス形態 | MITライセンス(完全無料、ソースコード改変・再配布自由) | Proprietary(個人/収益<$100Kは無料、超過で有料) | Proprietary + ロイヤリティ(収益$1M超で5%徴収) |
ソースコード公開 | 完全公開(GitHub) | 非公開(限定的にC++部分提供) | 公開(Epic Gamesアカウント経由で全体入手可能) |
主要スクリプト言語 | GDScript(独自)、C#, C++(GDNative) | C# | C++(BlueprintはC++のラッパー) |
ビジュアルスクリプト | VisualScript(非推奨・開発停滞) | Bolt(Unity製品統合済み) | Blueprint(公式サポート、事実上の標準) |
2D開発適性 | 最適化済(内部的にも2D専用設計あり) | 2D対応は十分だが3Dベース構造上やや負荷高 | 非最適(2D対応はBlueprint経由の限定的実装) |
3D描画機能 | 中程度(Vulkanベース、GI・PBR対応は限定的) | 高(HDRP/URP選択可、GPU最適化あり) | 非常に高(映画品質、Nanite/Lumen標準) |
プラットフォーム対応 | デスクトップ・モバイル・Web・一部コンソール(要申請) | 主要プラットフォーム網羅(Switch含む) | 主要プラットフォーム網羅(AAA向けに最適化) |
エディタの軽量性 | 非常に軽量(起動〜操作まで高速) | 中程度(PC性能に依存) | 重い(高性能マシン前提) |
開発規模との相性 | 個人・インディー・教育向け | 中〜大規模プロジェクト(中規模企業中心) | 大規模開発(AAA企業・シネマティック系) |
学習コスト | 低(ただし資料が断片的) | 中(豊富な公式・非公式教材) | 高(C++とBlueprintの二重構造) |
開発実績 | インディー、ゲームジャム中心(大手事例は少数) | 多数(モバイル、PC、Switch含む商用) | 多数(Fortnite、FFVII Rebirth、AAA多数) |
商用サポート | なし(コミュニティ・GitHubベース) | 有(有償サポートプランあり) | 有(大規模スタジオ向け技術支援あり) |
要するに, Godotは, 実績は少ないものの, 軽量かつPython文法に似たGDscriptで, ゲーム制作の学習・小規模開発に適しているものの, 現状就職を目指すに, 最適ではないともいえるかもしれない (ゲーム制作・コーディングの経験は繋がるが, 即戦力になるには, Unity・UEの経験もある程度持ったほうがいいかもしれない)
要するに, Godotは, Open Sourceプロジェクトとして, 開発者は皆, 実際にエンジンの利用者で, 「この機能ならほしいな, 作ろっか」と思い, 作り, エンジンに導入したものばかりである. この方面から, ユーザーエクスペリエンス(UX), つまり, 使い勝手は, 期待できる.
部員ほぼ全員Unityを使うのに, なぜ敢えてGodot?
私は, Principle of Least Effort (最小努力原理) を信じている, 要は, 目的に辿る道の中, 抵抗の一番少ない道を選ぶほうが進みやすい.
知能情報コースは, C#には一切触ることはない. Unityでゲーム作ろうと思っても, ゲーム制作理論+エンジン細かさ+C#プログラミング を同時に直面しなければならない. 個人的には少々荷が重かった.
Godot 基礎: Scene と Node
Sceneとは, Nodeの集合体である. ステージ, プレイヤー, 敵, 武器, 音楽, 当たり判定, 文字, ボタン など, ゲームのあらゆる要素は, Sceneで構成できる.

この図は, 私が作った”Player”というScene. Playerは, “CharacterBody2D”というNodeを親に, 部品(Component) であるSceneから築き上げたものである.
Nodeとは, Sceneを構成する基礎単位ともいえる. その中, NodeはUnityでは MonoBehaviourを継承すると似て, _ready() と _process(_delta:float)などのメソードを持つ.
すべてのノードには次の特性がある:
- 名前
- 編集できるプロパティ
- 毎フレーム、更新するためのコールバックを受け取る
- 新しいプロパティと関数を使用して拡張できる
- 別のノードを子として追加できる
最後の特性が重要で, Nodeは集まってツリーを形成する

図: Nodeの基本タイプ.
簡易化するために, 軽く説明すると:
Nodeは位置情報・回転・高度機能など一切持たない, ただスクリプト乗せるためのものと考えていい
Node2DとControlは, CanvasItemというアブストラクト クラス(Abstract Class, オブジェクト指向論の授業で学べる)から継承し,
位置情報(Transform)をもつ.

これから2Dゲームを作る際, 基本的にNode, Node2Dとその子クラスで機能を実現し, Control NodeでUIを築く.
更に詳細な説明は, 公式ドキュメントで読める: https://docs.godotengine.org/en/stable/getting_started/introduction/key_concepts_overview.html
今すぐ理解できなくても構わない。次の記事で、実際にものを動かして理解しよう!