よくある質問
Godot でできることは何ですか？それに費用は掛かりますか？ライセンスは？
Godotはフリーかつオープンソースのソフトウェアであり、OSI承認済みの MIT ライセンスの元で利用できます。これは「言論の自由（free speech）」や「無料のビール（free beer）」と同様にフリー（自由で無料）であることを意味します。
要約すると:
Godot は、個人的な利用、非営利な利用、商業、そのほかの目的に無料で自由に使用できます。
商用、非商用を問わず、無料で自由に Godot を改変、配布、再配布できます。
このコンテンツは、「Juan Linietsky」、「Ariel Manzur」そして 「Godot Engine コミュニティ」によって、クリエイティブ・コモンズ - 表示 3.0 (CC-BY 3.0) ライセンスの下、管理されています。
ロゴやアイコンはクリエイティブ・コモンズ・ライセンス下で管理されています。サードパーティ製のライブラリには、Godot のソースコードとは違うライセンスが含まれている可能性があることに注意してください。
詳細はGodotリポジトリの、COPYRIGHT.txtと LICENSE.txt、さらにLOGO_LICENSE.txtファイルをご覧ください。
また、Godotウェブサイトのライセンス情報ページも見てみて下さい。
Godot が対応するプラットフォームは？
エディタ:
Windows
macOS
X11 (Linux, *BSD)
Android (実験的)
Web (実験的)
ゲームの書き出し:
Windows
macOS
X11 (Linux, *BSD)
Android
iOS
Web
デフォルトは 64 ビットですが、32 ビットと 64 ビット両方に対応しています。
Raspberry Pi のような、ARM ベースの Linux マシンで Godot が動作したという報告もいくつかあります。
コンソールゲーム機製造元とのライセンス契約を結ばずに、コンソール向けにゲームをエクスポートする機能を提供することは Godot チームには出来ません。どのエンジンを使っていても、コンソール機でゲームをリリースするには常に多くの労力が必要です。そのことについては Godotでの(ゲーム)コンソールのサポート で詳しく解説しています。
詳しくは、書き出しについての節やGodotをコンパイルするをご参照ください。
注釈
Godot3 では Universal Windows Platform (UWP) もサポートしていました。しかしこのポートはメンテナンス不足や Microsoft からの対応が薄まった事で Godot4 からはサポートされなくなりました。興味があるユーザーは現在も Godot3 の最新バージョンを使用する事で UWP をサポートすることが出来ます。
Godot が対応するプログラミング言語は？
Godotが公式対応している言語は、GDScript、C#、および C++ です。それぞれの言語についてのサブカテゴリーはスクリプトセクションにあります。
初めて Godot を使う人や、これからゲーム開発を始める人には、Godot 内蔵の GDScript がおすすめです。スクリプト言語はより低水準な言語に比べて、必ずしも長期的には最適ではありません。しかし試作や、実用最小限の製品 (MVP) の開発、製品化への時間 (TTM) を重視する場合、GDScript はゲーム開発のためのスピーディで親しみやすい、有用な手段になります。
C# への対応はまだ比較的新しいため、何らかの問題が生じる可能性があることに注意してください。C# はウェブプラットフォームでもまだサポートされていません。当方のフレンドリーで仕事熱心な開発コミュニティーは、新たに浮かんできた問題に挑む準備は万端です。しかし、これはオープンソース・プロジェクトなので、まずはご自身で解決法を探ることを推奨します。トラブルシューティングには最初に open issues(英語) 内にて交わされているやりとりを参照してみてください。
新しい言語については、GDNative / NativeScript / PluginScript 機能を通じてサードパーティによる対応が可能です。例えば現在、PythonやNimのGodot向け非公式バインディングが開発進行中です。
GDScript とは何ですか？それを使うメリットは？
GDScript は Godot 内蔵のスクリプト言語です。より少ないコードで Godot の能力を最大限に発揮できるよう、一から設計されています。初心者からエキスパートまで、すばやく Godot の性能を引き出せるようになります。もし Python のような言語で書いた経験があれば、すぐに馴染めることでしょう。GDScript のサンプルや歴史、その力の概要を知りたい方は、GDScriptスクリプティング・ガイドをお読み下さい。
GDScript を使用する理由はいくつかありますが、一番のメリットは、全体的に 複雑さを軽減 できることです。
Godot 用に緊密に統合されたカスタムスクリプト言語を作る目的は、2つありました: 第一に、Godot を起動したり動作させたりするときに必要な時間を減らし、開発者がエンジンにすばやく触れる方法を提供して、生産性を重視するためです。第二に、維持にかかる負担を全体的に軽減し、問題の次元を下げるためで、これによりエンジンの開発者は、多くの言語で動作する小さな機能追加に多くの時間を費やすのではなく、エンジンコアのみに関連する機能改善やバグ修正に集中できるようになります。
Godot はオープンソース プロジェクトであるため、より馴染みのあるプログラミング言語をサポートしてユーザーを増やすよりも、より統合されたシームレスな開発体験を優先してきました。馴染みのある言語をサポートすると体験がよくない場合があります。Godot で別の言語を使用したいということは理解します (上記のサポート対象オプションのリストを参照) 。とはいえ、GDScript をまだ試していない場合は、3 日間 試してみてください。Godot と同様に、GDScript の強力さと開発の迅速性を一度体感すれば、気に入ってもらえるはずです。
GDScript や他の動的言語を使いこなすための情報は、こちらのチュートリアルGDScript: 動的言語の紹介にあります。
なぜ Godot Script を作ったのですか？
最初、このエンジンは Lua スクリプト言語を使用していました。Lua は高速ですが、オブジェクト指向システム (フォールバックを使用して) へのバインディングの作成は複雑で時間がかかり、膨大なコードを必要としました。 Python でもいくつかの実験を行いましたが、これも埋め込むのは難しいことがわかりました。
Godot 専用のスクリプト言語を作った主な理由は以下の通りです:
ほとんどのスクリプト VM (Lua、Python、Squirrel、JavaScript、ActionScript など) ではスレッドサポートが不十分ですが、Godot はスレッドを使用します。
ほとんどのスクリプト VM ( Lua、Python、JavaScript )ではクラス拡張のサポートが不十分で、Godot の動作方法に適応させる作業は非常に非効率的です。
既存の多くの言語 ( Lua、Python、Squirrel、JavaScript など) では、C++ とバインドするには、煩雑なインターフェイスを使わなければなりません。その結果、大量のコード、バグ、ボトルネック、および全般的な非効率性が生じてしまいます。私たちは、結合用コードではなく、すばらしいエンジンのために集中したかったのです。
( Lua、Python、Squirrel、JavaScript、ActionScript などには) ネイティブなベクトルタイプ ( vector3、matrix4 など)がないため、その代わりにカスタムタイプを使用する必要がありますが、それによってパフォーマンスが大幅に低下します。
( Lua、Python、JavaScript、ActionScript などでは) ガベージコレクタが原因で速度低下が発生したり、不必要にメモリ使用量が増えたりします。
(前記の各種言語では) コード補完、ライブ編集などを提供するコードエディタとの統合が困難です。GDScript ではそれらがサポートされています。
GDScript は上記の問題を減らすように設計されています。
最も速いプログラミング言語は？
ほとんどのゲームでは、 スクリプト言語 自体がパフォーマンスの問題の原因ではありません。むしろ、パフォーマンスは非効率的なアルゴリズム（すべての言語で遅い）、GPUのパフォーマンス、または物理やナビゲーションのような一般的なC++エンジンコードによって遅くなります。Godotがサポートするすべての言語は、一般的なスクリプティングに十分な速さです。使いやすさ、親しみやすさ、プラットフォームのサポート、または言語の機能など、他の要因に基づいて言語を選択するべきです。
一般的に、CとGDScriptのパフォーマンスは同じくらいで、C++は両者よりも速いです。
GDScriptのパフォーマンスをCと比較するのは難しいです。なぜなら、Cは特定のケースではより速くなることがあるからです。Cの 言語 自体はGDScriptよりも速くなる傾向があり、これはCがGodotエンジンコードへの呼び出しが少ない状況で速くなることを意味します。しかし、Cは多くのGodot API呼び出しを行う際にはGDScriptよりも遅くなることがあります。これは マシャリング のコストによるものです。また、Cのパフォーマンスは、ランダムで予測不可能な瞬間に発生するガーベジコレクションによっても低下する可能性があります。これにより、複雑なプロジェクトでのスタッタリング問題が発生することがあり、Godotに特有のものではありません。
C++は、 GDExtension を使用することで、ほぼ常にCやGDScriptよりも速くなります。しかし、C++はCやGDScriptよりも使いにくく、開発速度も遅くなります。
単一のプロジェクト内で複数の言語を使用することも可能で、 クロス言語スクリプティング を利用するか、GDExtensionとスクリプト言語を組み合わせて使用できます。ただし、その場合は独自の複雑さが伴うことに注意してください。
Godot で読み込める 3D モデルのフォーマットは?
サポートされているフォーマットや、3D モデリングソフトからのエクスポート方法、Godot へのインポート方法については、 3Dシーンのインポート ドキュメントに詳しい情報があります。
Godot では ( FMOD や GameWorks などの) クローズド SDK の組み込みがサポートされますか？
Godot の目的は、モジュール式で拡張可能な自由でオープンソースの MIT ライセンスエンジンを作成することです。コアエンジン開発コミュニティは、サードパーティのクローズドソース/プロプライエタリ SDK については、これらとの統合が Godot の精神に反するとして、サポートする計画はありません。
とはいえ、Godot はオープンソースかつモジュラーであるため、ライブラリがオープンソースかクローズドソースであるかに関わりなく、それらをモジュールとして追加して、ゲームを出荷することを妨げるものは何もありません。
選択した SDK のサポートがどのように提供されるのかを確認するには、以下のプラグインの質問を参照してください。
Godot ではサポートされていないものの、自由かつオープン ソースでの統合が可能なサードパーティ製の SDK があるのをご存知であれば、その統合作業を自身で始めることをご検討ください。Godot は一人の人間が所有しているわけではなく、コミュニティに属しているので、あなたのような野心的なコミュニティへの貢献者と一緒に成長します。
Godot を拡張するにはどうすればよいですか?
Godot エディタプラグインの作成や追加言語のサポートの追加など、Godot を拡張するには、エディタプラグインおよびツールスクリプトを参照してください。
また、Godot 用のネイティブ拡張機能を開発する方法である GDExtension に関する公式ブログの投稿も参照してください:
GDScript の実装、Godot モジュール、および Godot 向けの Jolt Physics Engine integration もご覧ください。これは、別のサードパーティライブラリがどのように Godot に統合されるかを知る良い出発点です。
Godot を自分のシステムにインストール (デスクトップへ統合) するには？
実際には Godot をあなたのシステムで実行する必要はないので、デスクトップ統合は自動的には実行されません。これを解決するには2つの方法があります。Godot を Steam (all platforms)、 Scoop (Windows)、 Homebrew (macOS) もしくは Flathub (Linux) からインストールできます。これらの方法では、デスクトップ統合に必要なステップが自動的に実行されます。
あるいは、インストーラーが実行するステップをあなたが手動で行うこともできます。
Windows
Godot の実行可能ファイルを安定した場所 ( Windows であれば Program files の中など ) に移動し、将来誤って移動してショートカットが壊れないようにします。
Godot の実行ファイルを右クリックして ショートカットの作成 を選択。
作成したショートカットを
%APPDATA%\Microsoft\Windows\Start Menu\Programsへ移動します。 これはスタートメニューに表示されるショートカットのユーザー共通の場所です。また、実行ファイルを右クリックして タスクバーにピン留め を選択すれば、Godotをタスクバーにピン留めすることができます。
macOS
取り出されたGodotアプリケーションを /Applications/Godot.app にドラッグし、必要な場合にはDockにもドラッグします。Spotlightは /Applications または ~/Applications にある限り、Godotを見つけられるようになります。
Linux
Godot の実行可能ファイルを安定した場所（Program Filesフォルダなど）に移動し、将来誤って移動してショートカットが壊れないようにします。
Godotのバイナリを環境変数
PATHに含まれる場所にリネームして移動してください。これは標準では/usr/local/bin/godotまたは/usr/bin/godotです。この作業を行うには管理者権限が必要ですが、 ターミナルからGodotエディタを起動する のようにgodotと入力して起動することも可能になります。Godot エディタのバイナリを保護された場所に移動できない場合、バイナリをホームディレクトリのどこかに置いて、下記にリンクされている
.desktopファイルの中のPath=行を修正し、Godotバイナリへの絶対パスのすべてを含めることができます。
この .desktop ファイル を
$HOME/.local/share/applications/に保存してください。また、管理者権限があれば、.desktopのファイルを/usr/local/share/applicationsに保存することによって、すべてのユーザーへのショートカットを作成できます。
Godotエディタはポータブルなアプリケーションですか？
デフォルトでは、Godot は "セミポータブル" です。その実行ファイルはどんな場所（書き込み不可能な場所を含む）から実行でき、特別な権限は必要ありません。
しかし、設定ファイルはユーザー全体の設定またはデータディレクトリに書き込まれます。これは通常良いアプローチですが、Godotの実行ファイルがあるフォルダをコピーした場合、設定ファイルが異なる環境で共有されないことを意味します。詳しくは Godotプロジェクトのファイルパス を参照してください。
もし、本当にポータブルな操作が必要な場合 (例: USB メモリでの使用)、 自己完結型モード のステップに従ってください。
Godot が Direct3D の代わりに Vulkan や OpenGL を使うのはなぜですか？
Godotは第一にクロスプラットフォームでの互換性とオープンスタンダードを目指しています。OpenGLとVulkanは(ほぼ)すべてのプラットフォームで利用できる技術です。このおかげで、Windows上のGodotで開発されたプロジェクトでもLinuxやmacOSなどで実行することができます。
Vulkan と OpenGL はオープン スタンダードとクロスプラットフォームの利点から引き続き私たちの主なフォーカス対象ですが、Godot 4.3 では Direct3D 12 の実験的なサポートが導入されました。この追加は、Windows や Xbox など、Direct3D 12 が普及しているプラットフォームでのパフォーマンスと互換性の向上を目的としています。ただし、Vulkan と OpenGL は、Windows を含むすべてのプラットフォームで引き続きデフォルトのレンダリングドライバーとして使用されます。
なぜGodotは基本的な機能をより少ないリソースで提供しようとしているのですか？
よほど使用機会が多くない限り、Godotではアドオンで実装できるような機能は意図的に搭載していません。例えば、高度な人工知能の機能などがその例です。
これにはいくつかの理由があります:
コードのメンテナンス性とバグの表面化。 Godotのリポジトリに新しいコードを受け入れるたびに、既存の貢献者がそのコードを維持する責任を負うことがよくあります。一部の貢献者はコードがマージされた後も常にいるわけではありませんので、私たちが当該コードを保守することが困難になることがあります。そのため、バグが修正されないまま、メンテナンスが不十分な機能になってしまうことがあります。それに加えて、テストやリグレッションのチェックが必要になる「APIサーフェス」も、時間とともに増え続けます。
開発参加の容易化。 コードベースを小さく整頓することで、ソースからのコンパイルを高速かつ簡単に行うことができます。これにより、新しい貢献者は、ハイエンドのハードウェアを購入することなく、Godot開発を始めることができます。
エディタのバイナリサイズ削減。 誰もが高速なインターネット接続を持っているわけではありません。誰もがGodotエディタをダウンロードし、解凍し、5分以内に実行できるようにすることで、あらゆる国の開発者がGodotにアクセスできるようになります。
エクスポートテンプレートのバイナリサイズ削減。 これはGodotでエクスポートするプロジェクトのサイズに直接影響します。モバイルやウェブのプラットフォームでは、ファイルサイズを小さくすることは、パワー不足のデバイスでのインストールや読み込みを高速に行うためには基本的なことです。また、高速インターネットが容易に利用できない国も多くあります。さらに、これらの国では厳しいデータ使用量の上限が設定されていることもあります。
上記のような理由から、Godotのコア機能として認められるものを選択しなければなりません。そのため、Godotの将来のバージョンでは、コア機能の一部を公式にサポートされるアドオンに移行することを目指しています。バイナリサイズの点では、プロジェクトで実際に使用する分だけを消費することになるという利点もあります。(今の段階では、プロジェクトの配布サイズを最適化するためには、未使用の機能を無効にしたカスタムエクスポートテンプレートを コンパイル します)
複数の解像度やアスペクト比に対応するアセットを作成するにはどうすればよいですか？
この質問は頻繁に出てきますが、これはおそらくAppleが当初デバイスの解像度を2倍にしたときに起こした誤解のせいでしょう。同じアセットを異なる解像度で持つことは良い考えだと人々に思わせ、多くの人がその道に向かって進み続けました。当初はAppleのデバイスのみであり、ある程度はうまくいっていましたが、その後、解像度とアスペクト比の異なる複数のAndroidとAppleのデバイスが作られたことで、サイズとDPIの幅が非常に広くなりました。
これを実現する最も一般的で適切な方法は、(複数の解像度を用意する) 代わりに、ゲームでは単一の基本解像度を使用して、異なる画面アスペクト比のみに対処することです。これが必要になるのは主に 2D においてであり、3D では単にカメラの視野角 ( XFov や YFov ) の問題になります。
ゲームの基本解像度を1つ選択します。解像度が 1440px あるデバイスであろうと 400px の低解像度デバイスであろうと、通常デバイスはパフォーマンスコストをほとんど、または全くかけずにハードウェアスケーリングで対応できます。最も一般的な選択肢は、1080px ( 1920 x 1080 ) または 720px ( 1280 x 720 ) です。解像度が高ければ高いほど、アセットは大きくなり、メモリの使用量が多くなり、ロードに時間がかかることに注意してください。
Godot のストレッチオプションを使用します。キャンバスアイテムをアスペクト比を維持したまま伸縮させる最適な機能です。この方法についてのチュートリアルは 複数の解像度 を参照してください。
最小解像度を決めて、さまざまなアスペクト比でゲームを垂直方向または水平方向に伸縮させるか、アスペクト比は固定で代わりに余白 (黒い画面) を表示するかを決定します。これについては、複数の解像度 でも説明されています。
ユーザインタフェースでは、anchoringを使用して、コントロールの位置と移動先を指定します。UIがより複雑な場合は、コンテナについて学ぶことを検討してください。
これで終わりです！あなたのゲームは複数の解像度で動くことでしょう。
次のGodotのリリースはいつですか？
用意できたときです！ 詳細については、次のリリースはいつ？を参照してください。
新しいプロジェクトを作るにはどのGodotのバージョンを使用すればいいですか？
新しく作るプロジェクトにはGodot 4.xを使うことをお勧めしますが、必要な機能セットによっては3.xを使う方が良いかもしれません。詳しくは 新しいプロジェクトにはどのバージョンを使用すればよいですか？ を参照してください。
新しいバージョンのGodotを使用するために自分のプロジェクトをアップグレードするべきですか？
新しいバージョンの中にはアップグレードしたほうが安全なものもあります。一般的に、アップグレードすべきかどうかはあなたのプロジェクトの状況によります。詳しくは 新しいエンジンバージョンを使用するために、プロジェクトをアップグレードする必要がありますか? を参照してください。
Forward+、モバイル、互換性のどのレンダラーを使用すればいいですか？
レンダラーの詳細な比較は Renderers にあります。
Godotに貢献したいのですが、どうすればよいですか？
素晴らしい事です！ オープンソースプロジェクトである Godot は、あなたのような革新性と向上心を持った開発者たちによって発展してきました。
もっとも良い Godot に貢献する方法は、Godot を使用して発生したバグを報告することです。ここ から再現可能なバグを報告することで、ほかの開発者が迅速かつ高速にその問題について取り組むことができます。また、オンラインドキュメントで見つかった問題も こちら から報告することができます。
もし問題を報告する準備が整っていれば、上記のリンクから問題を報告、選択、修正することができます。ソースからエンジンをコンパイルする方法、ドキュメントを構築する方法を学ぶ必要があります。また、Godot 開発者が使用するバージョン管理システムである Git についても理解しておく必要があります。
エンジンソースの扱い方、ドキュメントの編集方法、その他の貢献方法については documentation for contributors で説明しています。
ゲーム以外のアプリケーション作成のためにGodotを使用できますか？
Godotには豊富なUIシステムが組み込まれており、ディストリビューションサイズが小さいため、ElectronやQtのようなフレームワークの代替としても適しています。
ゲーム以外のアプリケーションを作成する場合、プロジェクト設定の高度な設定にある 低プロセッサモード を有効にして、CPU と GPU の使用量を減らしてください。
Godotで作成されたオープンソースアプリケーションの例については、 Material Maker と Pixelorama をご覧ください。
ライブラリとしてGodotを使用できますか？
Godotはエディタを通じて使用されるように作られています。長い目で見れば時間の節約になるはずなので、まずはエディタを試してみてください。Godotをライブラリとして使用可能にする計画は今のところありません。そうするとエンジンの他の部分がより複雑になり、カジュアルユーザーにとって使うのが難しくなってしまうためです。
もしレンダリング ライブラリとして使用するのであれば、代わりに既存のレンダリングエンジンを検討してみてください。ただし、レンダリングエンジンは通常、Godot と比較するとコミュニティが小さいことに注意してください。疑問の答えを見つけるのは、より難しくなるでしょう。
Godot はどのユーザーインターフェースツールキットを使いますか？
Godotは、GTK、Qt、wxWidgetsなどの標準の GUI ツールキットを使用しません。代わりに、Godotは、OpenGLESまたはVulkanを使用してレンダリングされた独自のユーザーインターフェイスツールキットを使用します。このツールキットは、エディター (C ++で記述されている) のレンダリングに使用されるコントロールノードの形式で公開されます。これらのコントロールノードは、Godotでサポートされている任意のスクリプト言語のプロジェクトでも使用できます。
このカスタムツールキットを使用すると、ハードウェアアクセラレーションのメリットを受けられ、すべてのプラットフォームで一貫した外観を実現できます。その上、GTK や Qt に付随する LGPL ライセンス制限に対処する必要がありません。最後に、これは「自身で試験運用する」という意味でもありますが、Godot のエディタ自体が Godot の UI システムを特に複雑に応用しているものの一つです。
このカスタムUIツールキットをライブラリとして使用することはできませんが、しかしエディタを使えばGodotでゲーム以外のアプリケーションを作成することはできます。
なぜGodotはSConsビルドシステムを使うのですか？
Godotはビルドするために SCons を使用しています。目下のところ、別のビルドシステムに変更するという計画はありません。他のシステムではなくSConsを選ぶのには、多くの理由があります。例えば:
Godotは十種類以上のプラットフォームを対象にコンパイルできます: すべてのPCプラットフォーム、すべてのモバイルプラットフォーム、多くのコンソール機、およびWebAssembly。
開発者は、多くの場合、複数のプラットフォームを同時にコンパイルする必要があります、または同じプラットフォームの異なるターゲットをコンパイルする必要があります。毎回プロジェクトを再構成して再構築する余裕はありません。SConsは、ビルドを壊すことなく、労なくこれを行うことができます。
どれほど変更・設定・追加・削除などがあったにせよ、SConsはビルドを中断することはありません。
Godotビルドプロセスは簡単ではありません。いくつかのファイルはコードによって生成され（バインダー）、他のファイルはパースされ（シェーダー）、他のファイルはカスタマイズを提供する必要があります( modules )。これには、ビルドのみを意図したマクロベースの言語を使用するのではなく、実際のプログラミング言語（Pythonなど）で記述する方が簡単な複雑なロジックが必要です。
Godotのビルド処理はクロスコンパイル ツールを多用しています。それぞれのプラットフォームには専用の検査処理があり、またそれらすべてを個別の問題として、専用のコードでもって対処しなければなりません。
ですので、もしGodotを自分でビルドすることを計画している場合は、オープンマインドを持って、SConsに多少は触れてみてください。
なぜGodotはSTL (Standard Template Library)を使わないのですか？
多くの他のライブラリのように (例えば Qt )、Godot は STL を使いません (スレッドプリミティブなどのいくつかの例外を除きます)。私たちは STL が素晴らしい汎用のライブラリだと信じています。しかし、godot には特別な要件がありました。
STLテンプレートは非常に大きなシンボルを作ります、そして巨大のデバッグバイナリーを結果として生じます。私たちは、代わりにいくつかのテンプレートをとても短い名前と共に使います。
私たちのコンテナのほとんどは、コピーオンライトを使用していてデータの受け渡しに使うベクターや、必要とするアクセス時間が O(1) のみであるパフォーマンス重視なRIDシステムなど、特別なニーズに対応しています。同様に、ハッシュマップの実装は、内部エンジンタイプとシームレスに統合するように設計されています。
コンテナにはメモリトラッキングが組み込まれているため、メモリ使用量を追跡できます。
大規模な配列の場合、プールメモリを使用します。これは、事前に割り当てられたバッファまたは仮想メモリのいずれかにマップできます。
私たちはカスタムString型を使用しています。STLが提供するものは基本的すぎて、適切な国際化サポートが不足しているためです。
なぜGodotは例外処理を使わないのですか？
私たちは、ゲームが何であれ、クラッシュすべきではないと考えています。予期しない状況が発生した場合、Godotはエラーを出力します(スクリプトまでトレース可能)が、その後、可能な限り正常に回復し、動き続けます。
さらに、例外を処理する機能の分、実行ファイルのサイズやコンパイルにかかる時間が大幅に増加します。
GodotはECS（エンティティ・コンポーネント・システム）を使用していますか？
GodotはECSを使用 していません 、代わりに継承に依存しています。普遍的に他より良いアプローチというものはありませんが、私たちは継承ベースのアプローチをすることが、結果として多くの使われ方において十分にすばやく、より良いユーザビリティをもたらすと気づきました。
それはつまり、プロジェクトの構成を生かして、個々のスクリプトによって子ノードを作成する際に、妨げるものが何もないということです。これらのノードはランタイムに動的に、追加したり取り除いたりすることができます。
Godotの設計に関する詳細については、この記事 を参照してください。
GodotがユーザーにDOD(データ指向設計)の実装を強制しないのはなぜですか？
Godotは内部的に可能な限りキャッシュコヒーレンシーを使用しようとしますが、ほとんどのユーザーにとってDODプラクティスを強制される必要はないと考えています。
DODは主にキャッシュコヒーレンシー最適化であり、何十万ものオブジェクト(ほとんど変更なしでフレームごとに処理される)を処理する場合にのみ、大幅なパフォーマンスの向上が得られます。たとえば、フレームごとに数百のスプライトまたは敵を移動する場合、DODは役に立ちません。最適化の別のアプローチを検討する必要があります。
ゲームの大部分はこれを必要としません。そして、あなたがそのような仕事を必要とする時には、殆どの場合Godotは便利なヘルパーを提供します。
このような大量のオブジェクトを本当に処理する必要がある場合、推奨されるのは、高性能部分にはC++とGDNativeを、残りのゲームにはGDScript(またはC#)を使用することです。
Godotの開発をサポートしたり、貢献したりするにはどうすればいいですか?
How to contribute をご覧ください。
Godotには誰が関わっているのですか？どうしたら連絡が取れますか？
Godot webサイトの対応するページをご覧ください。