Godotで宇宙船シューティングを作った話
ゲームエンジンも物理も苦手な自分がAIと組んで完成させるまで
結論：ゲームエンジンが苦手でも、物理が分からなくても、GodotとAIがあれば2Dゲーム制作はかなり現実的だった
最初に結論を書くと、ゲームエンジンに苦手意識があって、物理も得意ではない自分でも、GodotとAIを使えば簡単な2Dゲームを作ることは十分可能でした。
実際に完成したのは、宇宙船を操作して敵機と戦う2Dシューティングゲームです。
自機の移動、弾の発射、敵のスポーン、当たり判定、スコア表示——一通りの要素が動いています。ゲームエンジンへの苦手意識があった自分が、Godotを選んで正解だったと思えた理由を、この記事では順番に書いていきます。
私は一応プログラミング歴10年の大学生ですが、得意なのはVue.jsやTauri、そして特にFlutterです。どちらかというとアプリやUI寄りの人間で、ゲーム開発一直線でやってきたタイプではありません。そんな自分にとって、ゲームエンジンはずっと少し遠い存在でした。
大学の部活に入ったことをきっかけに、Unityなども触ってみようと思った時期はありました。けれど当時はFlutterやBSDにかなりのめり込んでいて、ゲームエンジン特有のシーン、ノード、物理演算、インスペクタ中心の考え方がどうしても自分に合いませんでした。難しいというより、概念が違いすぎて拒否感があった、という方が近いです。
さらに、自分は物理もあまり得意ではありません。ゲーム制作では重力、速度、加速度、当たり判定、ベクトルのような概念が出てくるので、その時点で苦手意識が強くなりやすいです。正直、ゲームを作りたい気持ちはあっても、「どうせ物理で詰まるだろう」と思っていました。
それでもGodotは、自分のような人間でも入りやすかったです。軽くて、扱いやすくて、GDScriptも分かりやすい。しかも今はAIを使いながら進められるので、分からない部分をその場で聞きながら作業できます。全部を理解してから始めるのではなく、作りながら理解していくやり方が取りやすかったのが大きかったです。
自分はゲームエンジン向きの人間ではなかった
自分はVue.jsやTauri、Flutterのような技術に親しんできました。特にFlutterはかなりしっくり来ていて、UIを組み立てたり、状態を整理したり、アプリとして形にしていく作業には馴染みがありました。
一方でゲームエンジンは、同じ「ソフトを作る」という括りに見えても、中身の考え方がかなり違います。アプリ開発では、画面遷移、レイアウト、入力処理、データの流れを組み立てることが中心になりますが、ゲームエンジンではシーンの管理、オブジェクト同士の関係、当たり判定、アニメーション、フレーム単位の挙動など、別の発想が求められます。
この違いが自分には大きかったです。周りから見ると「プログラミング経験があるならすぐできそう」と思われるかもしれませんが、実際にはそうでもありませんでした。むしろ、既に別のやり方に慣れているぶん、ゲームエンジンの文化に入り込むのが難しかったです。
だから、自分にとってゲーム制作の壁は、コードの難しさだけではありませんでした。ツールそのものの思想に慣れないことが、かなり大きな壁でした。
さらに、自分は物理が苦手だった
ゲーム制作に対して身構えてしまう理由の一つが、物理です。簡単な2Dゲームでも、ジャンプ、落下、移動、衝突、滑り、反射のような要素が出てきます。そこには当然、速度や重力のような考え方が関わってきます。
自分はこうした分野が得意ではありません。物理を綺麗に理解して、それを数式として実装に落とし込むような進め方はかなり苦手です。だから、ゲーム制作というだけで少し構えてしまうところがありました。
ただ、実際にGodotを触ってみると、簡単な2Dゲームを作る段階では、最初から高度な物理理解が必須というわけではありませんでした。今回作った宇宙船シューティングで言えば、重力をあえてゼロにすることで「落下しない宇宙空間」を表現でき、むしろ物理エンジンの存在を意識せずに済む場面も多かったです。もちろん最低限の理解は必要ですが、まずは「この値を変えるとジャンプが高くなる」「この設定で落下する」「このノードで当たり判定が取れる」といった形で、挙動を見ながら理解していけます。
この「試しながら分かる」感じはかなり助かりました。最初から全部を理論で理解しなくても、動くものを作りながら少しずつ身につけられる。物理が苦手な自分でも続けやすかったのは、ここが大きいです。
Godotにやる気が出た一番の理由は、MITライセンスのオープンソースだったこと
自分がGodotに強く惹かれた最大の理由は、GodotがMITライセンスのオープンソースだったことです。ここはかなり重要でした。
Godotは公式サイトでも「permissive MIT licenseのもとで公開されているfree and open source software」と明記しています（godotengine.org/license）。ロイヤリティなし、収益分配なし、ゲームの著作権はすべて開発者自身に帰属する、という設計です。
単に無料で使えるから、というだけではありません。自分はもともとBSDベースのOSを開発してみたいという願望があり、ライセンスの違いには以前から関心がありました。
ここで少し整理しておくと、オープンソースライセンスには大きく分けてコピーレフト型とパーミッシブ型の2種類があります。GPLに代表されるコピーレフト型は、そのコードを使って作ったソフトウェアを配布するときに、派生物も同じライセンスで公開することを求めます。つまり、GPL製のゲームエンジンをベースに何かを作って配布すれば、自分のコードも公開義務が生じる可能性があります。一方、MITはパーミッシブ型で、著作権表示とライセンス文さえ残せば、クローズドなプロダクトに組み込んでも問題ありません。
注：これは一般的な説明であり、法的助言ではありません。実際の利用にあたっては各自で確認してください。
この性質は、将来的に独自の環境やGUI開発に応用していきたいと考える自分にとって、かなり魅力的でした。Macが好きなことや、Interface BuilderのようなGUI設計文化から受けた影響もあります。単にプログラムを書くのではなく、見た目や操作感まで含めて、自分で作り込みたい。その延長線上で考えると、Godotはただのゲームエンジンではなく、GUIそのものを作るための基盤としても見られる存在でした。
しかもGodotはオープンソースなので、必要ならエンジン自体の中身を追うこともできます。自分でビルドしたり、環境に合わせて改造したりする余地がある。この「最後は自分の側で触れる」という感覚が、ゲームエンジンへの拒否感をかなり和らげてくれました。
閉じたツールを借りて使う感覚ではなく、技術として持てる感覚があった。そこが、自分がGodotにやる気を持てた一番大きな理由です。
AIに頼りながら進められたのも大きかった
そして、今回かなり大きかったのがAIの存在です。昔なら、ゲームエンジンに不慣れな人が詰まるたびに、ドキュメントを読んで、フォーラムを探して、動画を見て、試して失敗して、という流れを何度も繰り返す必要がありました。
今は、分からないことをかなり細かくAIに聞けます。
- 「Godotで自機を上下左右に動かすにはどうすればいいのか」
- 「弾をまっすぐ飛ばすにはどう書けばいいのか」
- 「敵をランダムにスポーンさせるには何を使えばいいのか」
- 「当たり判定でゲームオーバーにするにはどう書くのか」
- 「velocityは結局何を表しているのか」
こういったことを、その都度確認しながら進められるのは大きかったです。特に自分のように物理が苦手な人間にとって、抽象的な説明ではなく、実装に結びつけて理解できるのはかなり助かります。
AIに頼ることに対して、少し後ろめたさを感じる人もいるかもしれません。けれど実際には、AIに聞けばすべて自動で完成するわけではありません。最終的には自分で試して、直して、動かして、完成させる必要があります。だから、自分としてはAIを使うことは「ズル」ではなく、かなり合理的な学び方だと感じました。
特にゲームエンジンや物理に苦手意識がある人ほど、AIと一緒に進める価値は大きいと思います。全部を理解してから始めるのではなく、動くものを作りながら理解していけるからです。
実際にGodotを使って感じたメリット
1. *BSDにもビルドできる
かなり人を選ぶメリットではありますが、自分にとっては大きなポイントでした。
公式ドキュメントを見ると、コンパイル対象のページは「Compiling for Linux, *BSD」というタイトルになっており、*BSDが明示的にスコープに含まれています。FreeBSD向けのビルド手順が公式docsにあり、OpenBSDについても「フォントのビルドにClangが必要」といった具体的な注意書きが記載されています。
ただし「公式バイナリが常に全環境に用意されている」とは少し違います。*BSDのサポートはベストエフォートで、環境ごとの追加検証は必要です。それでも、「オープンソースだから公式docsに沿ってビルドする選択肢がある」という事実は、BSD環境に関心を持つ自分にとって大きなモチベーションになりました。
詳しくはGodotDocs Linux,BSDコンパイルについて
2. スペック要求が低い
Godotは比較的軽量です。少なくとも簡単な2Dゲームを作る段階では、かなり始めやすいと感じました。高性能なGPUや大きなメモリが前提という空気がそこまで強くないので、まず触ってみるまでのハードルが低いです。
ゲームエンジンに苦手意識がある人ほど、環境構築や動作の重さだけでやる気を失いがちです。その点でGodotは、最初の一歩を踏み出しやすいエンジンだと思います。
3. Gitを使ったバージョン管理がしやすい
公式ドキュメントには、「Godotはできる限りVCSフレンドリーで、読みやすくマージしやすいファイルを生成するように設計されている」と明記されています。シーンファイルやリソースのメタデータは人間が読めるテキスト形式で保存されるため、Gitの差分も比較的扱いやすいです。
さらにGodot公式はGitプラグインを提供しており、エディタ内からコミット・ステージング・差分確認が可能です。プロジェクト作成時に .gitignore と .gitattributes を自動生成するオプションもあります。
Webやアプリ開発ではGitが前提なので、そこからゲーム制作に入る人にとっては重要なポイントです。普段の開発フローを大きく崩さずに済むのは、かなり安心感があります。
なお、3Dアセットや大きなバイナリファイルが増えてくると、Git LFSの設定など別途工夫が必要になってきます。2D中心の開発なら大きな問題にはなりにくいですが、チーム規模が大きくなる場合は注意が必要です。
4. GDScriptがかなり楽
Godotを触っていて特に助かったのが、GDScriptの書きやすさです。構文がPythonに近く、型ヒントも書けるグラデュアルタイピング方式です。試したい挙動をすぐ書きやすく、初心者や中級者にも入りやすいと思います。
特に、「まず動かしてみる」「AIに聞いて直す」「少しずつ理解する」という流れと相性が良いです。最初から重厚な設計を求められる感じが薄いので、気軽に試しやすいのが良かったです。
5. MCPによる操作がしやすい
今後さらに重要になると思うのが、AIや自動化との相性です。MCP（Model Context Protocol）はAnthropicが公開した、AIモデルと外部ツールを接続するためのオープンプロトコルです。Godot向けのMCPサーバーを使えば、AIがエディタを直接操作したり、ノードを配置したり、スクリプトを書き出すといったことが可能になります。
ゲーム制作はコードだけではなく、エディタ操作も多いので、こうした外部連携がしやすいのはかなり面白いです。単なるコード補完以上の補助を受けられる可能性があります。AI前提の開発体験が広がっていく中で、Godotのこうした拡張しやすさは強みになると思います。
6. Godot自体を改造できる
Godotの大きな魅力を一言で言うなら、やはりここです。必要があれば、エンジンそのものに踏み込めます。これはかなり大きいです。
もちろん、全員が改造するわけではありません。けれど「どうしても困ったら中身まで追える」という事実は、ツールに対する安心感につながります。閉じた製品ではなく、技術として向き合える感覚があります。
一方で感じたデメリット
1. 周りとの孤立を感じやすい
ゲーム制作といえば、やはりUnityやUnreal Engineが強いです。そのため、Godotを選ぶと周囲と話が合わないことがあります。部活やコミュニティでも、Godot前提で情報交換できる相手はまだ少ないと感じることがあります。
これはエンジン自体の欠点というより、エコシステムの規模の問題です。ただ、初心者や中級者にとっては相談先の多さも重要なので、無視できない点だと思います。
2. Mac版リリース時にUniversal 2バイナリになる
Mac向けに配布を考えたとき、バイナリのサイズ感が少し気になることがあります。
公式ドキュメントによると、Godotの公式エクスポートテンプレートを使うと、macOS向けの出力は「Universal 2」バイナリになります。これはIntel x86_64とARM64（Apple Silicon）の両アーキテクチャを1つのファイルに含む形式です。互換性は高い一方で、ARM64単体のバイナリと比べるとファイルサイズが増えます。
ただ、これは解決の余地があります。公式docsのコンパイル手順では、arch=arm64オプションを指定してARM64専用バイナリをビルドし、lipoコマンドでの統合ステップを省けば、単一アーキテクチャのテンプレートを作ることも可能です。少し上級者向けですが、オープンソースだからこそ取れる選択肢です。
詳しくはGodotDocs Mac OSコンパイル方法について
3. リファレンスが少ないと感じる場面がある
基本情報はありますが、Unityほど何でも大量に出てくるわけではありません。少し踏み込んだ内容やニッチな使い方になると、情報の量に差を感じます。特に日本語情報はまだ少ないです。
AIが補助してくれる時代とはいえ、公式情報や事例の多さはやはり重要です。ここはGodotの今後に期待したい部分でもあります。
4. 共同開発時の不便さ
個人開発には向いていても、共同開発では少し工夫が必要だと感じます。アセットやシーンの扱いも含めて、運用ルールを作る必要があります。
Gitでカバーできる部分はありますが、前述のとおり大きなバイナリアセットが増えてくるとGit LFSの設定が必要になります。チーム開発の快適さという意味では、まだ少し不便さがあります。
5. 特定のLinuxサーバーでエディタの3D挙動が不安定なことがある
これは全員に当てはまるわけではありませんが、特定のLinuxサーバー環境でエディタの3D挙動が不安定に感じることがあります。2Dゲーム中心なら大きな問題にならない場合もありますが、環境依存の挙動は多少あると感じました。
自由度が高いぶん、環境ごとの検証コストは少しあります。
それでも、自分のような人にはGodotが合っていた
自分はいわゆる王道のゲーム開発者ではありません。Flutterが得意で、Vue.jsやTauriも触っていて、どちらかというとアプリケーション開発の人間です。ゲームエンジンに自然に馴染めるタイプでもなければ、物理に強いタイプでもありません。
そんな自分でも、Godotなら2Dゲームを形にするところまで進められました。これはかなり大きかったです。
その理由は単純で、Godotは「全部分かっている人」のためだけの道具ではなかったからです。軽くて、扱いやすくて、GDScriptも書きやすい。しかもMITライセンスのオープンソースで、自分の思想にも合っていた。さらにAIを使いながら進められることで、苦手な部分を抱えたままでも前に進めました。
完璧に理解してから始める必要がない。これが、自分にとってはかなり大きかったです。
Godotが向いている人・向いていない人
記事の最後に、自分が実際に触れてみて感じた「向き不向き」を整理しておきます。エンジン選びで迷っている人の参考になれば。
Godotが向いている人
Webやアプリ開発をやってきた人。Gitに慣れていて、テキストファイルベースの開発フローに馴染みがある人は、Godotの設計思想と自然に合います。UnityのようなBlobファイルに苦労した経験がある人なら、Godotのシンプルな差分管理は特に快適に感じるはずです。
まず動くものを作りながら学びたい人。GDScriptはPythonに近い構文で、型を書いても書かなくても動きます。「全部理解してから始める」より「とりあえず動かしてみる」タイプの人と相性が良いです。
ライセンスや知財に意識が高い人。MITライセンスなので、作ったゲームやエンジンを改造したプロダクトのライセンス設計を自分で決められます。将来的にクローズドなプロダクトに発展させたい人にとっても障壁がありません。
個人開発・少人数開発の人。エンジンが軽く、環境構築が速く、ひとりで完結しやすいです。今回の宇宙船シューティングのように、アイデアをさっと形にするフェーズと非常に相性が良いです。
オープンソースに思想的な共感がある人。「ツールは借りるものではなく持つもの」という感覚がある人なら、Godotのエンジンを中まで追える設計は安心感として機能します。
Godotが向いていない人
周囲がUnityを使っていて、情報共有が重要な環境にいる人。部活、チーム開発、スクールなど、周りの人と一緒に学ぶ状況ではUnityのエコシステムの厚さが効いてきます。質問先、チュートリアルの量、日本語情報の豊富さはUnityが圧倒的です。
3D表現をメインにしたい人。Godotの3Dサポートはv4以降で大きく改善されましたが、大規模な3Dゲームや高品質なグラフィックを目指す場合、UnityやUnreal Engineの方がアセットストアや実績面で優位です。2Dに関しては十分に強いですが、3Dをメインにしたいなら他の選択肢も視野に入れるべきです。
就職・インターンのポートフォリオとしてゲーム制作を考えている人。ゲーム業界では依然としてUnity、またはUnreal Engineの経験を求められる場面が多いです。キャリアを意識するなら、Godotの体験とは別に主流エンジンも触っておく価値があります。
大規模なチーム開発を想定している人。前述の通り、バイナリアセットが大量に発生するプロジェクトではGitの運用に工夫が必要です。既存のチームワークフローがUnityやUnreal前提で整備されている場合、途中からGodotを持ち込むコストは高くなります。
結論：ゲームエンジンも物理も苦手でも、GodotとAIがあれば作れた
改めて結論を書くと、ゲームエンジンが苦手で、物理にも自信がない自分でも、GodotとAIを使うことで宇宙船シューティングゲームを完成させることができました。
自分はFlutterやVue.js、Tauriのようなアプリ寄りの技術が得意で、ゲームエンジン向きの人間ではありません。それでもGodotは、MITライセンスのオープンソースで、軽くて、GDScriptが扱いやすく、Gitとも相性が良く、必要なら中身まで触れることができます。
しかも今は、分からないところをAIに聞きながら進められます。ゲームエンジンの概念が苦手でも、物理に苦手意識があっても、一つずつ動かしながら理解していけます。
だからこそ、「ゲームを作ってみたいけれど、ゲームエンジンが苦手」「物理が分からなくて不安」「でも何か形にしてみたい」と思っている人には、Godotはかなり有力な選択肢だと思います。
少なくとも自分にとっては、Godotは初めて拒否感より先に手が動いたゲームエンジンでした。