ゲームエンジンGodot Engineは今後どうなる？コンソールサポートは？AIは？弱点はどこ？Godot利用開発者が関係者に訊いた。ロング公式Q&A決定版になった

ゲームエンジンGodot Engineの躍進が続いている。Godotは、PC/モバイル/Web向けゲームおよびアプリを制作できる2D/3Dゲームエンジンだ。オープンソースとして提供され、完全無料で利用可能。開発にかかるコストは寄付によって賄われている。そんなGodot Engineはシェアを伸ばしており、UnityともUnreal Engineとも違う選択肢として脚光を浴び、シェアを伸ばしている。

一方で、Godot Engineを使う上では課題や疑問もあるだろう。ということで、実際にGodotを使いゲームを開発している開発者に、メールでGodot側のスタッフにインタビューしてもらった。聞き手はSteamで好評を得たスロットローグライク『Slot & Dungeons』開発者のすぱうい氏。質問に答えてもらったのは、W4 Gamesのスタッフ。W4 Gamesは、Godot Foundationを支える企業のひとつ。

W4 GamesはGodotエコシステムに参加しているものの、述べられている見解はあくまでW4 Games独自のものであり、Godot Foundationを代表するものではない点だけご注意あれ。いずれにせよ、熱心な回答にして対して丁寧な返信がされており、ロング公式Q&Aともいえる内容になっている。

■ W4Games / コンソール移植

――W4 Consolesの日本での採用事例はありますか？また、日本市場での今後の展開について教えてください。

W4Games：
W4 Consolesは比較的新しい製品ですが、日本を含む世界各国で導入が進んでおり、日本国内でも複数の企業にご利用いただいています。当社は日本を非常に重要で高い成長可能性を持つ市場と考えており、市場需要の拡大に合わせて日本での事業展開を拡大していく計画です。

――PCからコンソールへの移植で、「想定より大変になりやすいポイント」はどこに出やすいでしょうか？

W4Games：
ゲームの内容やコンソール移植の性質によって異なりますが、PCゲームをコンソール向けに移植する際には、いくつかの難しい課題が発生する可能性があります。

一つ目の課題は、パフォーマンスとハードウェアに関連するものです。コンソールは固定されたハードウェア構成と厳しいメモリ制約があるため、PC上では柔軟にスケールするシステムであっても、大幅な最適化や再設計が必要になる場合があります。

二つ目の課題は、プラットフォーム準拠です。各コンソールには詳細な認証要件が存在しており、これを満たせない場合、技術的な問題以上にリリースの遅延につながることがあります。

三つ目の課題は、入力操作とUXに関連するものです。マウスやキーボード向けに設計された操作は、コントローラーへ単純に割り当てるだけでは十分に機能しない場合があり、一部の領域では再設計が必要になることがあります。

四つ目の課題として、ビルドおよびデプロイのパイプラインがより複雑になる点があります。ツールチェーン、SDK、プラットフォーム固有のデバッグ環境はPC向けのワークフローとは異なるため、開発サイクルに影響を与える可能性があります。

五つ目の課題は、ネットワーク機能や各種サービスに関して、プラットフォーム固有のAPI統合が必要になる点です。

――私もW4 Consoles に申し込んで、Steam で販売しているゲームの Switch 移植を検討しています。インディー開発者がW4 Consolesを利用してコンソール移植を行う場合、どの程度の工数・期間を見込むべきでしょうか？（例：2Dローグライクなど）「ワンクリックでコンソールビルド可能」とありますが、実際の開発ではどのような課題や追加対応が発生しますか？

W4Games：
W4 Consolesを使用してゲームをNintendo Switch向けに移植する際の作業量や期間は、ゲームの技術的特性、最適化の状態、プラットフォーム固有機能への対応状況、そして元のPC版がどの程度「コンソール対応」を意識して構築されているかによって大きく異なります。

しかし、たとえばGodotで開発された2Dローグライクのような一般的なインディーゲームであれば、いくつかの一般的な目安を示すことができます。経験則として、Steam Deckのような携帯型プラットフォーム向けに十分最適化されているゲームであれば、Nintendo Switch移植に向けた良い出発点にあると言えます。多くの場合、比較的クリーンで最適化された2Dゲームであれば、小規模チーム、あるいは個人開発者であっても、数週間から数か月程度で移植可能なケースがあります。

W4 Consolesは、開発者自身がコンソール向けのエンジンフォークを構築する必要をなくし、ミドルウェア承認済みのコンソール向けエクスポート機能とネイティブなプラットフォーム統合を提供することで、従来のGodotコンソール移植の負担を大幅に軽減するよう設計されています。

プロセス自体は、コンソール以外のプラットフォーム向けエクスポートと非常によく似ています。対象プラットフォーム用のエクスポートテンプレートを設定し、開発機（devkit）を接続して、「Export」ボタンを押せば、対象コンソール上でゲームを実行できる状態になります。

その後、パフォーマンス最適化、メモリ管理、解像度スケーリング、ドックモードおよび携帯モードでの検証、さらにさまざまなコンソール環境におけるテストやQAといった作業が必要になる場合があります。

すでにSteamでリリースされており、ゲームコントローラーに対応している2Dローグライクであれば、大規模な3Dタイトルやオンラインマルチプレイヤー作品と比較して、通常ははるかに容易に移植できます。描画負荷が比較的軽く、プラットフォーム固有の依存関係が少ないジャンルは、W4 Consolesのようなミドルウェアを利用したセルフポーティングに適したケースと言えます。

小規模プロジェクトであれば社内対応できることも多い一方で、大規模または高いパフォーマンス要件を持つゲームについては、依然として外部の移植専門会社の支援が有効な場合があります。

従来の移植手法と比較した場合のW4 Consolesの主な利点の一つは、開発者が外部の移植会社に全面的に依存することなく、移植プロセスを自ら直接コントロールできる点にあります。

W4 Consolesは、Godotのコンソール向けエクスポートにおけるデプロイおよび移植ワークフローを大幅に簡素化しつつ、必要に応じてより深いコンソール固有のカスタマイズにも対応できるようになっています。

――コンソール移植において、Godot特有のハードルや注意点があれば教えてください。

W4Games：
Godot Engineのプロジェクトをコンソール向けに移植する際には、一般的なコンソール移植の課題に加えて、Godot特有のいくつかのハードルも存在します。

最も大きな課題の一つは、オープンソース版のGodotにネイティブな公式コンソールエクスポート機能が含まれていない点です。UnityやUnreal Engineとは異なり、Godotにおけるコンソール対応は通常、サードパーティーパートナーや独自のプラットフォーム移植に依存しているため、コストや調整作業が増え、場合によってはビルドパイプラインに対する直接的な制御が制限されることがあります。W4 GamesはGodot向け承認済みミドルウェアの主要プロバイダーですが、Godotはオープンソースであるため、誰でも独自のコンソール移植ツールを開発することが可能です。

また、GodotのGDScriptはGodotのコア機能の一部であるため、あらゆるプラットフォームで完全にサポートされていますが、C#やGDExtensionライブラリのようなサードパーティー言語や拡張機能を利用している場合には、移植プロセスがより複雑になります。その場合、ビルドシステムやSDKに関する知識が必要になります。

さらに、認証対応の準備も重要な検討事項です。UnityやUnrealと比較すると、コンソール向けツールやワークフローの一部は、まだ成熟度や統合度が十分でない場合があります。

最後に、テストおよびデバッグ環境についても、まだ発展途上の部分があります。コンソール上でのツール、プロファイリング、クラッシュ診断などは、より成熟したエンジンと比べると、必ずしも効率的かつ洗練されたものではない場合があります。

――W4Gamesのサポート体制について、実際にどの程度の関与・支援（技術サポート・トラブル対応など）を受けられるのでしょうか？

W4Games：
W4 Gamesは、契約プランに応じて異なるレベルのサポートを提供しています。標準サポートでは、バグ報告および問題追跡が中心となります。一方、プレミアムサポートでは、技術的なガイダンス、アドバイザリーサービス、そしてW4 Games製品に関する直接的な支援を提供するオンラインサポートポータルをご利用いただけます。

また、個々のゲーム開発者のニーズに合わせたカスタムサポートパッケージも提供しており、専任エンジニアとの協業や共同開発サービスを含めることも可能です。

――実際にGodotで商用タイトルを開発する開発者に向けて、「事前に知っておくべき重要なポイント」があれば教えてください。

W4Games：
Godot Engineを用いた商用プロジェクトを検討している開発者は、開発初期の段階でいくつかの重要なポイントを理解しておく必要があります。これらは一般的には利点と言えるものですが、開発やスケーリングへのアプローチに影響を与える要素でもあります。

まず第一に、GodotのオープンソースMITライセンスは大きなメリットです。ロイヤルティは不要で、売上分配もなく、コードやゲームに対する完全な所有権を維持できます。

ただし、その一方で、UnityやUnreal Engineのように、有償サポート契約を通じて受けられるような組み込み型の商用サポートは基本的に存在しません。そのため、エンタープライズレベルのサポートが必要な場合、開発者はドキュメント、コミュニティリソース、またはサードパーティープロバイダーにより大きく依存する必要があります。

第二に、エコシステムの成熟度を考慮することが重要です。Godotは特に3D分野を中心に急速な進化を遂げていますが、コンソール向けエクスポートパイプライン、高度なグラフィックスツール、大規模ミドルウェア統合といった分野では、追加の作業や独自ソリューションが必要になる場合があります。

第三に、チームの技術的特性を考慮する必要があります。Godotのネイティブ言語であるGDScriptは、非常に扱いやすく、迅速な反復開発に適していますが、大規模システムや高いパフォーマンスが求められる領域では、C#やC++を利用するケースも多くあります。これを早い段階で計画しておくことで、後々の大規模な書き直しを回避しやすくなります。

第四に、ツールや開発パイプラインについても検討が必要です。より成熟したエンジンと比較すると、アセットパイプライン、プロファイリングツール、大規模開発向けデバッグ環境など、一部のワークフローはまだ成熟途上にあります。これは開発を妨げるものではありませんが、社内ツールの構築やワークフロー調整のための時間をあらかじめ確保しておく必要があることを意味します。

第五に、コミュニティの強さとマーケットプレイス規模についてです。Godotは非常に活発かつ急速に成長している大規模コミュニティを持っており、一部のエンゲージメント指標ではUnityやUnrealを上回ることもあります。アセットマーケットプレイス自体は比較的小規模ですが、それだけに依存する必要はありません。他のマーケットプレイスのアセットをGodot向けに変換・適応することも可能であり、さらにオープンソースコミュニティによって維持されている多数のプラグインやツールも利用できます。ただし、他のサードパーティー依存と同様に、長期的な信頼性や保守性については慎重に評価する必要があります。

最後に、そして非常に重要な点として、Godotは独立性、柔軟性、そして長期的なコントロールを重視する開発者にとって非常に優れた選択肢です。多くの商用開発チームがGodotを選択する理由は、ベンダーロックインを回避でき、エンジンおよびソースコードに対する完全な透明性を確保できる点にあります。

Godotは商用開発に十分対応可能なエンジンですが、どの部分でより高い自立性が求められるのかを理解し、開発初期から計画しておくことが重要です。

■ Godotの方向性・強み

――私はGodot を使っていて特に気に入っている点は軽量でイテレーションが素早く回せる点です。Godotの強みの一つである「軽さ・開発の速さ」は、今後も維持されると考えてよいでしょうか？

W4Games：
Godotの大きな特徴の一つは、これまでも常に軽量であることと、高速な反復開発ワークフローにありました。そして私たちは、それこそが多くの開発者がGodotを好んで利用する大きな理由の一つであると考えています。

エンジンは成長とともにまったく変化しないわけではありませんが、迅速な開発サイクル、応答性、そして扱いやすさは、Godotのアイデンティティに深く結びついていると私たちは考えています。エコシステムが今後さらに拡大していく中でも、これらの特性は、コミュニティ貢献者やエンジンを支援する企業にとって引き続き重要な優先事項であり続けると考えています。

Godotアーキテクチャの利点の一つは、そのモジュール性とオープン性にあります。これにより、すべてのプロジェクトに不要な複雑さを強制することなく、多様な開発スタイルを支援することが可能になっています。この柔軟性は、特に迅速な反復開発と効率的なワークフローを重視するインディー開発者や小規模チームにとって非常に大きな価値があります。

――機能追加によってエンジンが重くなることへの懸念について、どのようにバランスを取っていますか？

W4Games：
これは非常にもっともな懸念であり、成功したエンジンが進化していく過程では自然に生じるものです。より多くの開発者がエンジンを採用し、追加機能を求めるようになると、機能拡張とシンプルさ・パフォーマンス維持との間で常にバランスを取る必要があります。

私たちは、成長とは単に機能数を増やすことではないと考えています。本当の課題は、開発者の生産性、使いやすさ、そして効率的なワークフローを維持しながらエンジンを進化させることにあります。

また、Godotコミュニティ自身も、このバランスについて非常に強く意識していると考えています。エディタの応答性、ワークフロー品質、パフォーマンス、モジュール性、不必要な複雑化の回避といったテーマは、コミュニティ内で日常的に議論されています。

最終的に、軽量で親しみやすい開発体験を維持することは、Godotを特徴づける重要な要素の一つです。そのため、こうした点への配慮は、今後のエンジン進化においても引き続き重要なテーマであり続けると考えています。

――他のゲームエンジン（UnityやUnrealなど）と比較した際の、今後の差別化戦略や強みは何でしょうか？

W4Games：
Godotの主な強みは、「集中性」「オープン性」「コントロール性」にあります。

第一に、オープンソースであることが中核にあります。エンジンのすべてのレイヤーに完全にアクセスできるため、開発者は自由に調査・改修・拡張を行うことができます。これは、柔軟性、長期的な安定性、あるいは独自ワークフローを必要とするチームにとって非常に重要です。

第二に、Godotは軽量かつ効率的に設計されています。高速な反復開発、小さなビルドサイズ、低いハードウェア要件により、インディー開発者や新興市場にとって魅力的であるだけでなく、効率性を重視する大規模スタジオにとっても、ますます魅力的な選択肢となっています。

第三に、開発者による所有権と透明性です。ロイヤルティ不要、寛容なライセンス体系、そしてクローズドなエコシステムと比較してプラットフォームリスクを軽減するガバナンスモデルが特徴です。

第四に、モジュール性と拡張性があります。成長を続けるツールエコシステムに加え、エンジンに制約されることなく独自パイプラインを統合できる柔軟性があります。

第五に、コミュニティ主導のイノベーションです。世界中の貢献者コミュニティが機能開発を加速させ、開発の優先事項が実際の開発者ニーズを反映するよう支えています。

今後については、Godotプロジェクトは、PC、モバイル、Web、そしてコンソール向けにゲームを公開するための「最良の汎用ゲーム開発ツール」であり続けることを目指しています。使いやすさと安定性は開発を導く重要な原則の一部であり、開発者が現在および将来のゲーム開発において安心してGodotを利用できるよう重視されています。現在の優先事項については、Godot公式ウェブサイトで確認できます。

――一方で、現時点でのGodotの弱みや課題についてはどのように認識していますか？

W4Games：
Godotには多くの強みがありますが、UnityやUnreal Engineと比較した場合、いくつかの弱点も存在します。

第一に、高度な3D機能やレンダリング面の成熟度は、まだ発展途上にあります。急速に改善は進んでいるものの、レンダリングパイプラインのカスタマイズ、高度なライティング効果の安定性、グラフィックスドライバーとの互換性、パフォーマンスの不安定さなどに関する課題が、プロジェクトによっては発生する場合があります。

第二に、ツール群やエコシステムの成熟度にも改善の余地があります。UnityやUnrealと比較すると、Godotはアセットマーケットプレイスの規模が小さく、成熟したサードパーティーツールも少なく、アセットパイプラインや大規模開発向けワークフローにおける自動化も限定的です。特に複雑なプロジェクトでは、こうした点が課題となる可能性があります。

第三に、コンソール対応やエンタープライズ向けサポートの体制が、単一の商用ベンダーによって支えられているエンジンとは異なります。Godotエコシステムでは、これらのサービスはコアのオープンソースプロジェクト自体ではなく、専門企業やパートナー企業によって提供されるのが一般的です。W4 Gamesのような企業は、商用サポート、コンソール向けプラットフォーム統合、エンタープライズサービス、カスタム開発支援などを提供することで、このギャップを埋めています。

これらのサービスには、エンジンの主要コントリビューターやメンテナーが直接関与することもあります。このモデルは、スタジオにとって高い柔軟性と価値を提供できる一方で、特にGodotプロジェクト全体のガバナンスプロセスに依存する変更や承認については、顧客がオープンソース本体に加えてサードパーティーの商用パートナーとも連携する必要があることを意味します。

最後に、オープンソースガバナンス特有の課題があります。これはGodotの強みでもありますが、一方で、メンテナーの人的リソース不足や、最近増加している低品質なAI生成コードの投稿によって、レビュー負荷やメンテナーの作業負担が増大しているといった問題も生じています。

Godotは非常に強力で急速に進化しているエンジンですが、高度な商用開発、エコシステムの深さ、そして運用面でのスケーラビリティについては、現在も成熟を続けている段階にあります。

■ 継続性・運営

――GodotおよびW4Gamesの運営体制や資金面について、今後の継続性は順調ですか？エンジンの長期的なサポートや安定性について、開発者はどの程度安心して利用できる状況でしょうか？

W4Games：
どのような技術エコシステムであっても将来について絶対的な保証を提供することはできませんが、私たちは、Godotエコシステムの構造と、これまで積み重ねられてきた成長の勢いから、開発者は十分に信頼を持つことができると考えています。

Godotの大きな強みの一つは、大規模なグローバル貢献者コミュニティによって支えられたオープンソースエンジンである点です。単一企業の方針に完全に依存するプロプライエタリエンジンとは異なり、Godotは独立系開発者、ゲームスタジオ、教育関係者、インフラ提供企業、支援組織など、幅広い主体からの貢献によって成り立っています。これは、長期的な継続性と進化を支える、より広範な基盤を形成しています。

また、このエコシステムは、10年以上にわたる継続的な開発、エンジン改善の積み重ね、対応プラットフォームの拡大、そしてインディーから商用プロジェクトまで幅広い採用実績を通じて、すでに強い長期的コミットメントを示していると私たちは考えています。

さらに、W4 Gamesのような企業も、ツール開発、コンソール対応、インフラ提供、商用サービスなどを通じて、エンジンを取り巻くプロフェッショナル向けエコシステムの強化に貢献しています。これにより、開発者は製品のリリースや長期運用をより効率的に行うことが可能になります。

最終的に、信頼は長期間にわたる着実な実行によって築かれるものです。Godotを用いた商用ゲームの成功事例が増え続け、エンジンを取り巻くエコシステムがさらに成熟していく中で、開発者はGodotを長期的に有力な開発プラットフォームとして、より一層信頼するようになると私たちは考えています。

■ AI × 開発

――AIコーディング（ChatGPTなど）とGodotの相性について、どのように考えていますか？

W4Games：
ChatGPTのようなAIコーディングツールとGodot Engineとの互換性は、全体として非常に高く、ある意味では非常に相性の良い組み合わせと言えます。

Godotのクリーンなアーキテクチャとスクリプト設計（GDScript）は、AIツールによるコード生成、説明、デバッグを比較的容易にしています。また、エンジンのドキュメントやソースコードはオープンかつ一貫性が高いため、より閉鎖的あるいは断片化されたエコシステムと比較して、AIによる出力品質も向上しやすくなっています。さらに、Godotは開発時に設定やリソースをプレーンテキスト形式で保存するため、AIコーディングツールがこれらの情報へアクセスしやすい点も利点です。

大きなメリットの一つはアクセシビリティです。開発者はAIを利用することで、深いエンジン知識がなくても、ゲームメカニクスの迅速なプロトタイピング、ボイラープレートコードの生成、問題解決などを効率的に行うことができます。これは、「開発の参入障壁を下げる」というGodotの理念とも非常によく一致しています。

一方で、いくつかの制約も存在します。AIツールは一般的に、より主流な言語やエンジンへの対応に強みを持っているため、GDScript特有のケース、新しい機能、あるいはドキュメントが少ないサブシステムについては、不完全または古い提案を生成する場合があります。また、Godotは進化のスピードが速いため、バージョンの違いによって誤ったコードが生成されるケースもあります。

さらに、統合の深さという課題もあります。より成熟したエコシステムと比較すると、AIをエディタ内に直接統合するネイティブプラグインやワークフローはまだ少ない状況です。

――私も Godot で開発をしていて、機能開発で詰まった点やエラーメッセージをAIに読ませて解決してもらうことが増えました。開発者がAIを活用する際のおすすめの使い方やベストプラクティスがあれば教えてください。

W4Games：
W4 GamesおよびGodot Foundationのいずれも、Godotを用いたゲーム開発に関連するAIツールの利用について、正式なガイドラインを策定しているわけではありません。

AIツールは、他の多くのソフトウェア開発ツールと同様に、利用ケースによって利点と欠点の両方を持ち得るものであり、開発者やスタジオが個別の状況ごとに慎重に評価する必要があります。

実際には、AIシステムによって生成された成果物については、特にエンジン固有の機能、API互換性、パフォーマンスへの影響、コード品質などに関して、批判的かつ慎重なレビューを行うべきです。

また、Godotはバージョンごとに急速に進化しているため、AIによる技術的提案については、公式ドキュメントや自社のテストプロセスを通じて、開発者自身が独立して検証することが重要です。

AIツールは、あくまで補助的な支援技術として捉えるべきであり、絶対的な情報源として扱うべきではありません。その有用性は、開発者の経験、与えるプロンプトの品質、そして具体的な開発状況に大きく依存します。

――OSSであるGodotにおいて、AI生成コードによるPull Requestの増加によるメンテナンス上の問題はいかがでしょうか？

W4Games：
多くのオープンソースプロジェクトと同様に、Godotも現在、低品質なAI生成プルリクエストの急増という問題に直面しており、それがメンテナーに大きな負担を与えています。こうした投稿には、GitHubプロフィール上の実績を増やすためにボットが大量生成する純粋なスパム的投稿から、善意ではあるものの技術的に誤っていることが多いAI支援型の投稿まで含まれており、結果としてメンテナーの時間を浪費するケースが増えています。

コントリビューションガイドラインでは、AI支援を受けた投稿については開示することが求められています。しかし、多くの新規コントリビューターはそれを行わず、メンテナーは相手が人間なのかAIエージェントなのかを常に推測しながら対応しなければならず、大きな精神的負担となっています。

Godotは何よりもまずコミュニティプロジェクトであり、人と人との交流や、経験を積み重ねながら新しいコントリビューターが長期的なメンテナーへ成長していくことを重視しています。メンテナーは、新規コントリビューターが適切なプルリクエストを作成し、上流へマージできるよう支援するために時間を投資することを歓迎しています。しかし、その相手が学習能力を持たないAIエージェントを遠隔操作しているだけである場合、その前提自体が成り立たなくなってしまいます。

そのため、現時点では、多くのGodotメンテナーにとってAI支援型のコントリビューターは望ましい存在とは見なされておらず、全体としてはマイナス要因であると受け止められています。

■ コミュニティ・エコシステム

――Godotはコミュニティ主導のエンジンですが、リソース不足（情報・人材）について課題を感じていますか？

W4Games：
Godotはオープンソースエンジンであるため、その発展は主にボランティアベースの貢献に大きく依存しています。これまでのところ、貢献活動は非常に活発であり、それがエンジンの急速な成長を支えてきました。しかし、コミュニティ全体の成長速度と比較すると、貢献の増加率はやや鈍化しています。これは、エンジンの成熟に伴ってコードベースの複雑性が増していることが一因ですが、それに加えて、主にボランティアで構成されるチームを、Godotのような大規模プロジェクトに必要な規模まで拡大することの難しさも反映しています。

実際のところ、Godotはコードやドキュメントの貢献不足に悩んでいるわけではありません。一方で、メンテナーによる質の高いレビュー作業が大きなボトルネックとなっています。メンテナーの仕事は非常に負担が大きく、エンジンの品質、長期的な保守性、そして目的に適した設計を維持する責任を負っています。その多くもボランティアで活動しており、さらに、すべてのエンジン領域において十分な専門知識を持つレビュー担当者が揃っているわけではありません。

このボトルネックを解消するために、Godot Foundationは、レンダリング、スクリプト、オーディオ、物理演算、プラットフォーム対応、エディタなど、各エンジン分野ごとに少なくとも1名の専任メンテナーを雇用できる体制を目指しています。その実現には、より多くの寄付や企業スポンサーシップを獲得し、フルタイムのコントリビューターを増やしていく必要があります。

――『Slay the Spire 2』 が大ヒットをし、Godot Engine 製ゲームで最大のSteam同接プレイヤー数を更新しました。マルチプレイも実装されていて、ゲームエンジンとしてのポテンシャルもアピールできたかと思います。ニュース記事で以下のような記載がありました。

 「ちなみに、開発元Mega Critは、ユーザーとのやり取りの中でエンジンを乗り換えた件について明かしており、中でもリード・プログラマーのJake Card氏は「今回のようなプロジェクトでは、Godotはほぼ全ての面でUnityに勝っていた。後悔について言えるとすれば、Unityに比べてユーザーが少ないこと。コミュニティ間のリソースが少なく、何か上手くいかなくて、原因がわからなくても頼れる人が少ないこと。」と回答しています。

コミュニティ側のリソース不足という指摘について、Slay the Spire2 のヒットやフィードバックを踏まえて今後対策等ございますか？

W4Games：
私たちは、Slay the Spire 2の成功を、Godotの能力が着実に向上していることを示す非常に強力な実証例だと考えています。特に、商業的成功を目指すプロジェクトや、技術的に高度なプロジェクトにおいて、その意味は大きいと言えます。

また、大手プロプライエタリエンジンと比較した際のユーザーベースの小ささや、コミュニティリソースの限定性に関する指摘は理解できるものであり、比較的新しいエコシステムが自然に抱える課題の一つでもあります。

一方で、特にソーシャルメディアやコミュニティエンゲージメント指標においては、GodotコミュニティはすでにUnityやUnrealを取り巻くコミュニティと同等、あるいはそれ以上の規模に達している側面もあります。

現在、より顕著な差となっているのは、コミュニティ規模そのものというよりも、エコシステムの成熟度、マネタイズ環境、そして長年にわたって蓄積されてきた商用リソースの厚みにあります。たとえば、チュートリアル、マーケットプレイス向けアセット、ミドルウェア統合、エンタープライズ向けツールなどの分野では、既存の大手エンジンは数十年にわたる商業投資とエコシステム構築の恩恵を受けています。

それでも、Godotエコシステムはここ数年で急速に成長しており、開発者採用数だけでなく、利用可能なリソース、ツール、そして商用サポートの幅も大きく広がっています。

Godotはオープンソースエンジンであるため、コミュニティリソースの継続的な拡充は、開発者、企業、教育関係者、ミドルウェア提供企業、そしてエコシステム全体からの貢献によって支えられています。実際に、チュートリアル、プラグイン、サードパーティーツール、プロフェッショナル向けサポートサービス、エンタープライズ向けソリューションなどの分野では、すでに大きな成長が見られています。

私たちの視点では、最も重要な進展の一つは、商業スタジオやインフラ提供企業による参加が増え、エンジン周辺のエコシステム強化が進んでいることです。Godotを用いた成功事例が増えるにつれて、知識共有、ドキュメント、ミドルウェア、コンソール対応、マルチプレイヤーツール、そして開発者体験を取り巻くネットワーク効果は、さらに加速していくと考えています。

最終的に、Slay the Spire 2のような成功事例は、より多くの開発者、コントリビューター、そして業界関係者の関心をGodotエコシステムへ引き寄せる役割を果たします。そしてそれが、まさに指摘されているようなリソース不足の課題を解消していくことにつながると私たちは考えています。

――いろいろとお答えいただき、ありがとうございました。

インタビューは以上となる。ナイスな質問をしてくれたすぱうい氏の『Slot & Dungeons』は、Steamで発売中だ。