「Why Does the Games Industry Reject Godot?」 (なぜゲーム業界はGodotを拒否するのか？) という動画が面白かったので内容をまとめておきます。
動画の主題
この動画内で投稿者は Godot Engineを「個人的に最も気に入っているゲームエンジン」だと述べつつも、ゲーム業界での採用は少ない（個人のインディー開発を除く）理由を紹介しています。
まず動画の冒頭では GameJob.co での開発者応募数を検索し、Unreal Engineは 5396件、Unityは 701件、Godotは 14件と表示され、Godotの開発者の募集が少ないことを伝えています。
そして、この動画で述べられている「企業がGodotを採用しない」理由は以下の3つです。
- 採用実績の少なさ（Lack of Adoption）
- 成熟度の不足（Lack of Maturity）
- セキュリティの弱さ（Lack of Security）
1. 採用実績の少なさ（Lack of Adoption）
Unreal や Unity に比べ、Godot はまだ新しく「実績不足」と見られていて、エンジンを選ぶことは会社にとって大きなリスクであり、一度採用すると変更は困難です。 ここでのリスクとして、例えば採用したゲームエンジンでプロジェクトを進めた結果、必要な機能がないとします。そうなると、ゲームエンジンを使って楽に作れると思ったのに、別途新規実装が必要となり余計なコストが生まれます。
こういった「他のゲームエンジンでは簡単にできることが、このゲームエンジンではできなかった」というのは大きなリスクの1つです。またトラブル発生時に解決のためのリソースが少ないこともリスクです。
そして「使っている企業が少ない → リスクとみなされる → さらに企業が使わない」という悪循環が発生し、結果としてプロとしての Godot 経験者が少ないことも採用をためらう一因となっています。
2. 成熟度の不足（Lack of Maturity）
Godot は進化中のエンジンであり、AAA開発者が期待する一部の高度な機能は未実装です。例として、フォトリアルなグラフィックスや高予算ゲーム向けの先進機能など。
| 項目 | 説明 | 問題点 | 補足 |
|---|---|---|---|
| 1. 公式のコンソール 移植サポート |
Godot 自体はオープンソースであり、 任天堂・ソニー・マイクロソフトとの公式契約を結んでいないため、 公式に Switch / PlayStation / Xbox 向けビルドを提供できません |
企業がコンソール展開を前提にする場合、 Unity や Unreal のように 「公式で動作保証されたエクスポート機能」 がないのは大きな不安材料 |
商用サポート企業（例：W4 Games）が 別途移植サービスを提供していますが、 これは標準機能ではありません |
| 2. 地形生成機能 | Godot には Unity/Unreal のような ビルトインの地形ツールがまだありません |
広大なオープンワールドや自然環境を作る場合、 外部プラグインや自作のシステムに頼る必要がある |
コミュニティ製のアドオン （例：Zylann’s Terrain3D）があり、 少しずつ進歩しています |
| 3. 高度なレンダリング技術 (レイトレーシングなど） |
Godot 4 で Vulkan レンダラーが導入されましたが、 レイトレーシングやハイエンド向けのGI技術はまだ初歩的 |
Unreal Engine が標準で持つ Nanite / Lumen のような先進技術と比べると不足感がある |
研究・試験的な実装は進んでおり、 今後追加される可能性は高い |
| 4. 高度なアニメーション ワークフロー (モーションキャプチャ連携など） |
Godot の AnimationPlayer は強力だが、 モーションキャプチャや高度な リギング／レイヤードアニメーション統合には弱い |
AAA開発のように実写Mocapを 取り込んで複雑なキャラクター制御を行う場合は不十分 |
Blender との連携や、 コミュニティ製の拡張で補える部分もある |
| 5. 高度なプロファイ リングツール |
Godot にはデバッガーやプロファイラはあるが、 メモリ使用量、スレッド挙動、 GPU/CPUパフォーマンスを詳細に 分析する高度なツールはまだ未熟 |
大規模開発ではボトルネック解消のために 強力なプロファイラが必須。 Unreal の Insights などに比べると見劣りする |
|
| 6. 一般的な動画フォーマット のサポート |
Godot の標準機能は Ogg Theora や WebM を中心にサポート |
問題点：MP4（H.264/H.265）など 業界標準の動画再生に対応していないため、 外部ライブラリの導入が必要 |
法的な特許問題やライセンス料の 関係で標準サポートが難しいという事情がある |
| 7. ビジュアル スクリプティング |
Godot 3 系ではビジュアルスクリプトがあったが、 Godot 4 では非推奨・削除済み |
Blueprint（Unreal）や Bolt/Playmaker（Unity） のようなノードベースでのプログラミング 環境を求めるユーザーには不便 |
別のコミュニティ製ツールで代替 可能だが、公式標準ではない |
| 8. デバッグ描画機能 | Godot にも一応デバッグ描画 API （draw_line、draw_circle など2D系や 3D Gizmo）があるが、 Unreal の DrawDebug 系に比べるとシンプル |
衝突判定や物理挙動を 視覚的に確認するツールが限定的で、 複雑なデバッグ用途には不十分。 一部はプラグインや自作で補えるが、標準機能としての厚みが弱い |
個人的な印象として、仕事では Unreal Engineを使っているのですが、UEではノードエディタが使いやすく、マテリアルノードやアニメーションブループリントは非エンジニアでも容易に作れる、シーケンサーの柔軟性の高さ、ポストエフェクトの充実度、開発リソース（情報源）の多さ、公式フォーラムでのサポートの手厚さといったところに圧倒的な差を感じています。
3. セキュリティの弱さ（Lack of Security）
最後に、Godot で作ったゲームはリバースエンジニアリングが非常に容易です。配信したゲームからソースコード・アセット・プロジェクトファイルを抽出して再利用できてしまいます。 これは他のゲームエンジンでもつきまとう問題ですが、Godotの場合はソースコードも簡単に抜き出せてしまうということがあります。
例えば、以下のことが簡単にできるということです。
- ゲーム内のお金を簡単に最大にできしまう、無敵モードを作ってゲームバランスが崩壊する
- ソースコードの課金処理の部分を無効にして、無料で遊べるようにしてしまう
- これら改造したゲームを再ビルドして配信できてしまう
他のゲームエンジン、例えば Unreal Engineであってもデータの抜き出しはある程度できてしまうようですが、実行ファイルはバイナリ化されるため改造が容易ではないとのことです。
そしてGodot Engineでは実際に盗まれて販売された事例（「Diapers Please」）もあるとのことです。 ただ、DRMとの関係もあり、オープンソースの性質上「最低限の保護」すら難しい点が懸念されます。
それでもGodotを使うメリット
上記の問題はありますが、個人開発であればGodotを使うメリットはいくつかあります。
- 学習コストが低く直感的で、ドキュメントも充実。有能な開発者なら短期間で習得可能
- 趣味開発者には非常に人気があり、ポートフォリオを持つ優秀な人材も多い
- 「未成熟」とされる機能も、オープンソースであるため企業自身が実装できるし、プラグインも豊富
- セキュリティ問題は Godot 特有ではなく、他エンジンでも似た問題はある。対策ツールも存在
- 実際に Godot 製の優れたインディーゲーム例も増えてきている
個人的に考える、Godotを使うメリット (デメリット) は以下のページにまとめています。
まとめ
この動画のまとめとしては以下のとおりです。
- Godot は シンプルで軽量、使う喜びの大きいエンジン
- 大規模 AAA ではなくても、小規模・情熱的なチームのゲーム開発には最適
- 今後さらに人気が高まり、やがて採用の「臨界点」を超えると予想
- 完全に無料・オープンソースである点も大きな強み
補足：Godotの暗号化について
以下の動画では、Godotの実行ファイルを暗号化する方法について紹介しています。 www.youtube.com 簡単なまとめとしては以下のとおりです。
- エンジンビルドが必要になるが暗号化は可能
- ただし実行ファイルに復号化のキーが含まれるので、時間をかければ暗号を解除できる
- とはいえ、素人に解除できるほど簡単なものではないので、9割くらいは不正を防げる
動画の概要
動画では「Godotでゲームを暗号化すれば盗難を防げるのか？」というテーマを検証しています。 実際に未暗号化のゲームを逆コンパイルしてプロジェクトを復元し、その後に暗号化したゲームで同じことを試し、どこまで保護できるのかを確認しています。
未暗号化ゲームの危険性
- 例として「Diapers Please」というインディーゲームが盗まれ、アプリストアに無断公開されて利益を出された事件を紹介
- Godotで作られた未暗号化のゲームは「exeファイル」だけからでもツール（Godot Toolsなど）を使えばすべてのスクリプト・アセット・音声ファイルを復元可能
- 簡単にコード改変や再配布、他プラットフォームへの勝手な移植ができてしまう
暗号化の方法
Godotの「カスタムエクスポートテンプレート」を利用して暗号化可能です。
- Godotのソースコードを取得。
- C++コンパイラ（例：mingw）、Python、esconパッケージを準備。
- OpenSSLやPowerShellで暗号化キーを生成。
- 環境変数に暗号化キーを設定。
- Godotソースをコンパイルしてカスタムエクスポートテンプレートを作成。
- エクスポート時にそのテンプレートを指定し、暗号化キーを入力してビルド。
ただエンジンビルドが必要となるため、やや敷居が高くなっています。
暗号化の効果
暗号化したゲームを復元しようとすると「キーが間違っている」というエラーになり、ツールでは復元できなくなります。ただし実行ファイルには「復号のために暗号化キー自体が埋め込まれている」ため、熟練したリバースエンジニアが解析すればキーを取り出すことが可能です。
結論としては、「Godot暗号化はゲームを100%守るわけではないが、しないより圧倒的に安全」です。
- Godotの暗号化は完全な防御策ではない
- しかし「素人の盗用」や「簡単な抜き取り」を防ぐには十分であり、9割以上の窃盗リスクを下げられる
- 家の鍵のように、プロの泥棒には破られる可能性があるが、大半の盗難は抑止できる
