Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

よくある質問

Godotでできることは何ですか?それに費用は掛かりますか?ライセンスは?

Godotはフリーかつオープンソースのソフトウェアであり、OSI承認済みのMITライセンスの元で利用できます。これは「フリービール (無料のビール)」のフリーと「フリースピーチ (言論の自由)」のフリーの二つの意味でとてもフリーであることを意味します。

要約すると:

  • Godotは、個人的な利用、非営利な利用、商業、そのほかの目的に無料で自由に使用できます。

  • 商用、非商用を問わず、無料で自由にGodotを改変、配布、再配布できます。

このコンテンツは、「Juan Linietsky」、「Ariel Manzur」そして 「Godot Engineコミュニティ」によって、クリエイティブ・コモンズ-表示 3.0(CC-BY 3.0)ライセンスの下、管理されております。

ロゴ、アイコンはクリエイティブ・コモンズ・ライセンス下で管理しています。補足としてサードパーティライブラリには、Godotのソースコードとは違うライセンスを含んでいる可能性があります。

For full details, look at the COPYRIGHT.txt as well as the LICENSE.txt and LOGO_LICENSE.txt files in the Godot repository.

また、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をコンパイルするをご参照ください。

注釈

Godot 3 also had support for Universal Windows Platform (UWP). This platform port was removed in Godot 4 due to lack of maintenance, and it being deprecated by Microsoft. It is still available in the current stable release of Godot 3 for interested users.

Godotが対応するプログラミング言語は?

Godotが公式対応している言語は、GDScript、C#、およびC++です。それぞれの言語についてのサブカテゴリーはスクリプトセクションにあります。

初めてGodotを使う人や、これからゲーム開発を始める人には、Godot内蔵のGDScriptがおすすめです。スクリプト言語はより低水準な言語に比べて、必ずしも長期的には最適ではありません。しかし試作や、実用最小限の製品(MVP)の開発、製品化への時間(TTM)を重視する場合、GDScriptはゲーム開発のためのスピーディで親しみやすい、有用な手段になります。

Note that C# support is still relatively new, and as such, you may encounter some issues along the way. C# support is also currently missing on the web platform. Our friendly and hard-working development community is always ready to tackle new problems as they arise, but since this is an open source project, we recommend that you first do some due diligence yourself. Searching through discussions on open issues is a great way to start your troubleshooting.

新しい言語については、GDNative/NativeScript/PluginScript機能を通じてサードパーティによる対応が可能です。例えば現在、PythonNimの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専用のスクリプト言語を作った主な理由は以下の通りです:

  1. ほとんどのスクリプトVM(Lua、Python、Squirrel、JavaScript、ActionScriptなど)ではスレッドサポートが不十分ですが、Godotはスレッドを使用します。

  2. ほとんどのスクリプトVM(Lua、Python、JavaScript)ではクラス拡張のサポートが不十分で、Godotの動作方法に適応させる作業は非常に非効率的です。

  3. 既存の多くの言語(Lua、Python、Squirrel、JavaScript など)では、C++とバインドするには、煩雑なインターフェイスを使わなければなりません。その結果、大量のコード、バグ、ボトルネック、および全般的な非効率性が生じてしまいます。私たちは、結合用コードではなく、すばらしいエンジンのために集中したかったのです。

  4. No native vector types (Vector3, Transform3D, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

  5. (Lua、Python、JavaScript、ActionScriptなどでは)ガベージコレクタが原因で速度低下が発生したり、不必要にメモリ使用量が増えたりします。

  6. (前記の各種言語では)コード補完、ライブ編集などを提供するコードエディタとの統合が困難です。GDScriptではそれらがサポートされています。

GDScriptは上記の問題を減らすように設計されています。

Godotで読み込める3Dモデルのフォーマットは?

サポートされているフォーマットや、3Dモデリングソフトからのエクスポート方法、Godotへのインポート方法については、 3Dシーンのインポート ドキュメントに詳しい情報があります。

Godotでは(FMODやGameWorksなどの)クローズドSDKの組み込みがサポートされますか?

Godotの目的は、モジュール式で拡張可能な自由でオープンソースのMITライセンスエンジンを作成することです。コアエンジン開発コミュニティは、サードパーティのクローズドソース/プロプライエタリSDKについては、これらとの統合がGodotの精神に反するとして、サポートする計画はありません。

とはいえ、Godot はオープンソースかつモジュラーであるため、ライブラリがオープンソースかクローズドソースであるかに関わりなく、それらをモジュールとして追加して、ゲームを出荷することを妨げるものは何もありません。

選択したSDKのサポートがどのように提供されるのかを確認するには、以下のプラグインの質問を参照してください。

Godotではサポートされていないものの、自由かつオープン ソースでの統合が可能なサードパーティ製のSDKがあるのをご存知であれば、その統合作業を自身で始めることをご検討ください。Godotは一人の人間が所有しているわけではなく、コミュニティに属しているので、あなたのような野心的なコミュニティへの貢献者と一緒に成長します。

Godotを拡張するにはどうすればよいですか?

Godotエディタプラグインの作成や追加言語のサポートの追加など、Godotを拡張するには、エディタプラグインおよびツールスクリプトを参照してください。

また、Godot用のネイティブ拡張機能を開発する方法であるGDExtensionに関する公式ブログの投稿も参照してください:

You can also take a look at the GDScript implementation, the Godot modules, as well as the Jolt physics engine integration for Godot. This would be a good starting point to see how another third-party library integrates with Godot.

Godotを自分のシステムにインストール(デスクトップへ統合)するには?

実際にはGodotをあなたのシステムで実行する必要はないので、デスクトップ統合は自動的には実行されません。これを解決するには2つの方法があります。Godotを`Steam <https://store.steampowered.com/app/404790/Godot_Engine/>`__ (all platforms), Scoop (Windows), Homebrew (macOS) もしくは Flathub (Linux) からインストールできます。これらの方法では、デスクトップ統合に必要なステップが自動的に実行されます。

あるいは、インストーラーが実行するステップをあなたが手動で行うこともできます。

Windows

  • Godot の実行可能ファイルを安定した場所(ex.WindowsではProgram filesの中など)に移動し、将来誤って移動してショートカットが壊れないようにします。

  • Godotの実行ファイルを右クリックして**ショートカットの作成**を選択。

  • 作成したショートカットを``%LOCALAPPDATA%MicrosoftWindowsStart MenuPrograms``へ移動します。 これは、スタートメニューに表示されるショートカットのユーザー共通の場所です。また、実行ファイルを右クリックして「タスクバーにピン留め」を選択すれば、Godotをタスクバーにピン留めすることができます。

macOS

取り出されたGodotアプリケーションを`/Applications/Godot.app`にドラッグし、必要な場合にはDockにもドラッグします。Spotlightは`/Applications`または`~/Applications`にある限り、Godotを見つけられるようになります。

Linux

  • Godot の実行可能ファイルを安定した場所(Program Filesフォルダなど)に移動し、将来誤って移動してショートカットが壊れないようにします。

  • Godotのバイナリを環境変数`PATH`に含まれる場所にリネームして移動してください。これは標準では`/usr/local/bin/godot`または`/usr/bin/godot`です。この作業を行うには管理者権限が必要ですが、 :ref:`ターミナルからGodotエディタを起動する<doc_command_line_tutorial>`のように`godot`と入力して起動することも可能になります。

    • Godot エディタのバイナリを保護された場所に移動できない場合、バイナリをホームディレクトリのどこかに置いて、下記にリンクされている .desktopファイルの中の Path= 行を修正し、Godotバイナリへの絶対パスのすべてを含めることができます。

  • `この .desktop ファイル<https://raw.githubusercontent.com/godotengine/godot/master/misc/dist/linux/org.godotengine.Godot.desktop>`__$HOME/.local/share/applications/に保存してください。また、管理者権限があれば、.desktopのファイルを /usr/local/share/applicationsに保存することによって、すべてのユーザーへのショートカットを作成できます。

Godotエディタはポータブルなアプリケーションですか?

デフォルトでは、Godot は "セミポータブル" です。その実行ファイルはどんな場所(書き込み不可能な場所を含む)から実行でき、特別な権限は必要ありません。

しかし、設定ファイルはユーザー全体の設定またはデータディレクトリに書き込まれます。これは通常良いアプローチですが、Godotの実行ファイルがあるフォルダをコピーした場合、設定ファイルが異なる環境で共有されないことを意味します。詳しくは File paths in Godot projects を参照してください。

もし、本当にポータブルな操作が必要な場合 (例: USB メモリでの使用)、 自己完結型モード のステップに従ってください。

GodotがDirect3Dの代わりにVulkanやOpenGLを使うのはなぜですか?

Godotは第一にクロスプラットフォームでの互換性とオープンスタンダードを目指しています。OpenGLとVulkanは(ほぼ)すべてのプラットフォームで利用できる技術です。このおかげで、Windows上のGodotで開発されたプロジェクトでもLinuxやmacOSなどで実行することができます。

Godotのレンダラーについて作業する人は数人しかいないため、私たちがメンテナンスするレンダリングバックエンドはより少ない方が望ましいです。またすべてのプラットフォームにおいて単一のAPIを使用することでプラットフォーム固有の問題が少なくなり、一貫性の向上が見込めます。

長期的には、私たちはDirect3D 12 レンダラーを(主にXbox用に)開発する可能性はありますが、VulkanとOpenGLはWindowsを含むすべてのプラットフォームにおいてデフォルトのレンダリングバックエンドであるでしょう。

なぜGodotは基本的な機能をより少ないリソースで提供しようとしているのですか?

よほど使用機会が多くない限り、Godotではアドオンで実装できるような機能は意図的に搭載していません。例えば、高度な人工知能の機能などがその例です。

これにはいくつかの理由があります:

  • コードのメンテナンス性とバグの表面化。 Godotのリポジトリに新しいコードを受け入れるたびに、既存の貢献者がそのコードを維持する責任を負うことがよくあります。一部の貢献者はコードがマージされた後も常にいるわけではありませんので、私たちが当該コードを保守することが困難になることがあります。そのため、バグが修正されないまま、メンテナンスが不十分な機能になってしまうことがあります。それに加えて、テストやリグレッションのチェックが必要になる「APIサーフェス」も、時間とともに増え続けます。

  • 開発参加の容易化。 コードベースを小さく整頓することで、ソースからのコンパイルを高速かつ簡単に行うことができます。これにより、新しい貢献者は、ハイエンドのハードウェアを購入することなく、Godot開発を始めることができます。

  • エディタのバイナリサイズ削減。 誰もが高速なインターネット接続を持っているわけではありません。誰もがGodotエディタをダウンロードし、解凍し、5分以内に実行できるようにすることで、あらゆる国の開発者がGodotにアクセスできるようになります。

  • エクスポートテンプレートのバイナリサイズ削減。 これはGodotでエクスポートするプロジェクトのサイズに直接影響します。モバイルやウェブのプラットフォームでは、ファイルサイズを小さくすることは、パワー不足のデバイスでのインストールや読み込みを高速に行うためには基本的なことです。また、高速インターネットが容易に利用できない国も多くあります。さらに、これらの国では厳しいデータ使用量の上限が設定されていることもあります。

上記のような理由から、Godotのコア機能として認められるものを選択しなければなりません。そのため、Godotの将来のバージョンでは、コア機能の一部を公式にサポートされるアドオンに移行することを目指しています。バイナリサイズの点では、プロジェクトで実際に使用する分だけを消費することになるという利点もあります。(今の段階では、プロジェクトの配布サイズを最適化するためには、未使用の機能を無効にしたカスタムエクスポートテンプレートを コンパイル します)

複数の解像度やアスペクト比に対応するアセットを作成するにはどうすればよいですか?

この質問は頻繁に出てきますが、これはおそらくAppleが当初デバイスの解像度を2倍にしたときに起こした誤解のせいでしょう。同じアセットを異なる解像度で持つことは良い考えだと人々に思わせ、多くの人がその道に向かって進み続けました。当初はAppleのデバイスのみであり、ある程度はうまくいっていましたが、その後、解像度とアスペクト比の異なる複数のAndroidとAppleのデバイスが作られたことで、サイズとDPIの幅が非常に広くなりました。

The most common and proper way to achieve this is to, instead, use a single base resolution for the game and only handle different screen aspect ratios. This is mostly needed for 2D, as in 3D, it's just a matter of camera vertical or horizontal FOV.

  1. Choose a single base resolution for your game. Even if there are devices that go up to 1440p and devices that go down to 400p, regular hardware scaling in your device will take care of this at little or no performance cost. The most common choices are either near 1080p (1920x1080) or 720p (1280x720). Keep in mind the higher the resolution, the larger your assets, the more memory they will take and the longer the time it will take for loading.

  2. Use the stretch options in Godot; canvas items stretching while keeping aspect ratios works best. Check the 複数の解像度 tutorial on how to achieve this.

  3. 最小解像度を決定し、ゲームを縦横比ごとに垂直または水平に伸ばすかどうか、または縦横比を固定して余白に黒いバーを表示するかどうかを決定します。これについては、複数の解像度でも説明されています。

  4. ユーザインタフェースでは、anchoringを使用して、コントロールの位置と移動先を指定します。UIがより複雑な場合は、コンテナについて学ぶことを検討してください。

これで終わりです!あなたのゲームは複数の解像度で動くことでしょう。

次のGodotのリリースはいつですか?

用意できたときです! 詳細については、次のリリースはいつ?を参照してください。

新しいプロジェクトを作るにはどのGodotのバージョンを使用すればいいですか?

新しく作るプロジェクトにはGodot 4.xを使うことをお勧めしますが、必要な機能セットによっては3.xを使う方が良いかもしれません。詳しくは Which version should I use for a new project? を参照してください。

新しいバージョンのGodotを使用するために自分のプロジェクトをアップグレードするべきですか?

新しいバージョンの中にはアップグレードしたほうが安全なものもあります。一般的に、アップグレードすべきかどうかはあなたのプロジェクトの状況によります。詳しくは Should I upgrade my project to use new engine versions? を参照してください。

Godotに貢献したいのですが、どうすればよいですか?

Awesome!オープンソースプロジェクトとして、Godotは、あなたのような野心的で貢献的なメンバーを求めています。

もっとも良いGodotに貢献する方法は、Godotを使用して発生したバグを報告することです。ここ から再現可能なバグを報告することで、ほかの開発者が迅速かつ高速にその問題について取り組むことができます。また、オンラインドキュメントで見つかった問題も`こちら <https://github.com/godotengine/godot-docs/issues>`_ から報告することができます。

もし問題を報告する準備が整っていれば、上記のリンクから問題を報告、選択、修正することができます。ソースからエンジンをコンパイルする方法、ドキュメントを構築する方法を学ぶ必要があります。また、Godot 開発者が使用するバージョン管理システムである Git についても理解しておく必要があります。

エンジンソースの扱い方、ドキュメントの編集方法、その他の貢献方法については :ref:`documentation for contributors <doc_ways_to_contribute>`で説明しています。

Godotについていいアイデアがあるのですが、どこで共有すればいいですか?

私たちはエンジンを改善するための提案を常に求めています。ユーザーからのフィードバックは、私たちの意思決定プロセスの主な原動力であり、あなたがプロジェクトに取り組んでいる間に考えた疑問や不満点は、私たちがエンジンの改良を検討する際の素晴らしい判断材料になります。

Godotの現在のバージョンで、使いづらいと感じた部分や、欠けている機能がある場合は、私たちの`コミュニティ<https://godotengine.org/community/>`_で議論することから始めてください。コミュニティのメンバーの提案によって他にもっと良い方法が見つかるかもしれません。また他のユーザーが同じ問題を経験しているかどうかを知り、良い解決策を一緒に考えることができます。

エンジンのための明確なアイデアを思いついたら、遠慮なく`proposal issue <https://github.com/godotengine/godot-proposals/issues>`_を開いてください。あなたの問題や提案する解決策を明確かつ具体的に説明するようにしてください。実行可能な提案のみが考慮されます。必須ではありませんが、自分で実装したい場合は、いつでも歓迎します!

具体的な詳細がない一般的なアイデアについては、`proposal discussion <https://github.com/godotengine/godot-proposals/discussions>`_を開くことができます。提案の内容は何でもよく、解決策を探すための自由な議論ができます。解決策が見つかれば、proposal issueを開くことができます。

`readme <https://github.com/godotengine/godot-proposals/blob/master/README.md>`_を読み、手順について理解した上での提案をお願いします。

ゲーム以外のアプリケーション作成のためにGodotを使用できますか?

Godotには豊富なUIシステムが組み込まれており、ディストリビューションサイズが小さいため、ElectronやQtのようなフレームワークの代替としても適しています。

ゲーム以外のアプリケーションを作成する場合、プロジェクト設定で :ref:`low-processor mode <class_ProjectSettings_property_application/run/low_processor_mode>`を有効にして、CPUとGPUの使用量を減らしてください。

Godotで作成されたオープンソースアプリケーションの例については、 Material MakerPixelorama をご覧ください。

ライブラリとしてGodotを使用できますか?

Godotはエディタを通じて使用されるように作られています。長い目で見れば時間の節約になるはずなので、まずはエディタを試してみてください。Godotをライブラリとして使用可能にする計画は今のところありません。そうするとエンジンの他の部分がより複雑になり、カジュアルユーザーにとって使うのが難しくなってしまうためです。

もしレンダリング ライブラリとして使用されたければ、代わりに既存のレンダリングエンジンを検討してください。ただし、レンダリングエンジンは通常、Godotと比較するとコミュニティーが小さいことに注意してください。疑問の答えを見つけるのは、より難しくなるでしょう。

Godot はどのユーザーインターフェースツールキットを使いますか?

Godotは、GTK、Qt、wxWidgetsなどの標準の GUI ツールキットを使用しません。代わりに、Godotは、OpenGLESまたはVulkanを使用してレンダリングされた独自のユーザーインターフェイスツールキットを使用します。このツールキットは、エディター (C ++で記述されている) のレンダリングに使用されるコントロールノードの形式で公開されます。これらのコントロールノードは、Godotでサポートされている任意のスクリプト言語のプロジェクトでも使用できます。

このカスタムツールキットを使用すると、ハードウェア アクセラレーションのメリットを受けられ、すべてのプラットフォームで一貫した外観を実現できます。その上、GTKやQtに付随するLGPLライセンス制限に対処する必要がありません。最後に、エディタ自体がGodotのUIシステムを特に複雑に応用しているユーザの一つなので、Godotは「ドッグフーディング」しています。

このカスタムUIツールキットをライブラリとして使用することはできませんが、しかしエディタを使えばGodotでゲーム以外のアプリケーションを作成することはできます。

なぜGodotはSConsビルドシステムを使うのですか?

Godotはビルドするために SCons を使用しています。私たちはSconsが大好きなので、他のものに変えるつもりはありません。他のビルドシステムがGodotのビルドに適しているかどうかさえ、確信がありません。ビルドシステムをCMakeやVisual Studioに変更してほしいというリクエストをよく受けますが、起こり得ないことです。他のシステムではなくSConsを選ぶのには、多くの理由があります。例えば:

  • Godotは十種類以上のプラットフォームを対象にコンパイルできます: すべてのPCプラットフォーム、すべてのモバイルプラットフォーム、多くのコンソール機、およびWebAssembly。

  • 開発者は、多くの場合、複数のプラットフォームを同時にコンパイルする必要があります、または同じプラットフォームの異なるターゲットをコンパイルする必要があります。毎回プロジェクトを再構成して再構築する余裕はありません。SConsは、ビルドを壊すことなく、労なくこれを行うことができます。

  • どれほど変更・設定・追加・削除などがあったにせよ、SConsはビルドを中断することはありません

  • Godotビルドプロセスは簡単ではありません。いくつかのファイルはコードによって生成され(バインダー)、他のファイルはパースされ(シェーダー)、他のファイルはカスタマイズを提供する必要があります( modules )。これには、ビルドのみを意図したマクロベースの言語を使用するのではなく、実際のプログラミング言語(Pythonなど)で記述する方が簡単な複雑なロジックが必要です。

  • Godotのビルド処理はクロスコンパイル ツールを多用しています。それぞれのプラットフォームには専用の検査処理があり、またそれらすべてを個別の問題として、専用のコードでもって対処しなければなりません。

ですので、もしGodotを自分でビルドすることを計画している場合は、オープンマインドを持って、SConsに多少は触れてみてください。

なぜGodotはSTL (Standard Template Library)を使わないのですか?

Like many other libraries (Qt as an example), Godot does not make use of STL (with a few exceptions such as threading primitives). We believe STL is a great general-purpose library, but we had special requirements for Godot.

  • STLテンプレートは非常に大きなシンボルを作ります、そして巨大のデバッグバイナリーを結果として生じます。私たちは、代わりにいくつかのテンプレートをとても短い名前と共に使います。

  • 私たちのコンテナのほとんどは、コピーオンライトを使用していてデータの受け渡しに使うベクターや、必要とするアクセス時間が O(1) のみであるパフォーマンス重視なRIDシステムなど、特別なニーズに対応しています。同様に、ハッシュマップの実装は、内部エンジンタイプとシームレスに統合するように設計されています。

  • コンテナにはメモリトラッキングが組み込まれているため、メモリ使用量を追跡できます。

  • 大規模な配列の場合、プールメモリを使用します。これは、事前に割り当てられたバッファまたは仮想メモリのいずれかにマップできます。

  • 私たちはカスタムString型を使用しています。STLが提供するものは基本的すぎて、適切な国際化サポートが不足しているためです。

なぜGodotは例外処理を使わないのですか?

私たちは、ゲームが何であれ、クラッシュすべきではないと考えています。予期しない状況が発生した場合、Godotはエラーを出力します(スクリプトまでトレース可能)が、その後、可能な限り正常に回復し、動き続けます。

Additionally, exceptions significantly increase the binary size for the executable and result in increased compile times.

GodotはECS(エンティティ・コンポーネント・システム)を使用していますか?

GodotはECSを使用して**おらず**、代わりに継承に依存しています。普遍的に他より良いアプローチというものはありませんが、私たちは継承ベースのアプローチをすることが、結果として多くの使われ方において十分にすばやく、より良いユーザビリティをもたらすと気づきました。

それはつまり、個々のスクリプトによって子ノードを作成する際に、プロジェクト内でコンポジションを利用するのを妨げるものがないということです。これらのノードはランタイムに動的に、追加したり取り除いたりすることができます。

Godotの設計に関する詳細については、`この記事 <https://godotengine.org/article/why-isnt-godot-ecs-based-game-engine>`__を参照してください。

GodotがユーザーにDOD(データ指向設計)の実装を強制しないのはなぜですか?

Godotは内部的に可能な限りキャッシュコヒーレンシーを使用しようとしますが、ほとんどのユーザーにとってDODプラクティスを強制される必要はないと考えています。

DODは主にキャッシュコヒーレンシー最適化であり、何十万ものオブジェクト(ほとんど変更なしでフレームごとに処理される)を処理する場合にのみ、大幅なパフォーマンスの向上が得られます。たとえば、フレームごとに数百のスプライトまたは敵を移動する場合、DODは役に立ちません。最適化の別のアプローチを検討する必要があります。

ゲームの大部分はこれを必要としません。そして、あなたがそのような仕事を必要とする時には、殆どの場合Godotは便利なヘルパーを提供します。

このような大量のオブジェクトを本当に処理する必要がある場合、推奨されるのは、高性能部分にはC++とGDNativeを、残りのゲームにはGDScript(またはC#)を使用することです。

Godotの開発をサポートしたり、貢献したりするにはどうすればいいですか?

貢献する方法をご覧ください。

Godotには誰が関わっているのですか?どうしたら連絡が取れますか?

Godot webサイトの対応するページをご覧ください。