よくある質問

Godotで何ができますか?費用はいくらかかりますか?ライセンス条項は何ですか?

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

要約すれば:

  • Godotをダウンロードして、個人的、非営利、商業、またはその他の目的に無料で自由に使用できます。

  • 商用と非商用を問わず、どのような用途であれ、心おきなく無料で自由にGodotを改変、配布、再配布およびリミックスできます。

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

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

詳細はGodotリポジトリの、COPYRIGHT.txtまたは LICENSE.txtLOGO_LICENSE.txtファイルをご覧ください。

また、Godotウェブサイトのライセンス情報ページも見てみて下さい。

Godotが対応するプラットフォームは?

エディタ:

  • Windows

  • macOS

  • X11 (Linux, *BSD)

  • Web

  • Android (experimental)

ゲームの書き出し:

  • Windows (およびUWP)

  • macOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • ウェブ

デフォルトは64ビットですが、場合に応じて32ビットと64ビット両方に対応しています。

Raspberry Piのような、ARMベースのLinuxマシンでGodotが動作したという報告もいくつかあります。

それに加えて、コンソール機向けに第三者による非公式のビルドがいくつかあります。しかし、現時点では標準のビルドスクリプトや書き出しテンプレートには含まれていません。

詳しくは、書き出しについての節やGodotをコンパイルするをご参照ください。

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

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

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

C#への対応はまだ比較的新しいため、何らかの問題が生じる可能性があります。当方のフレンドリーで仕事熱心な開発コミュニティーは、新たに浮かんできた問題に挑む準備は万端です。しかし、これはオープンソース・プロジェクトなので、まずはご自身で解決法を探ることを推奨します。トラブルシューティングには最初に、open issues(英語)内にて交わされているやりとりを調べてみて下さい。

新しい言語については、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: 動的言語の紹介にあります。

GDScriptを作った動機はどのようなものですか?

初期には、このエンジンは 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. (Lua、Python、Squirrel、JavaScript、ActionScriptなどには)ネイティブなベクトルタイプ(vector3、matrix4など)がないため、その代わりにカスタムタイプを使用する必要がありますが、それによってパフォーマンスが大幅に低下します。

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

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

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

Godotはどんな3Dモデルフォーマットをサポートしていますか?

Godotは、OpenCollada エクスポーターを介してColladaをサポートしています(Maya、3DSMax)。 Blenderを使用している場合は、我々の Better Collada Exporter をご確認ください。

Godot 3.0の時点で、glTFをサポートしています。

FBXは、Open Asset Importライブラリを介してサポートされています。ただし、FBXはプロプライエタリですので、ワークフローに適している場合は、上記の他の形式を使用することをお勧めします。

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

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

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

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

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

システムに Godot エディターをインストールするにはどうすればよいですか (デスクトップ統合用)?

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

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

Windows

  • Move the Godot executable to a stable location (i.e. outside of your Downloads folder), so you don't accidentally move it and break the shortcut in the future.

  • Right-click the Godot executable and choose Create Shortcut.

  • Move the created shortcut to %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs. This is the user-wide location for shortcuts that will appear in the Start menu. You can also pin Godot in the task bar by right-clicking the executable and choosing Pin to Task Bar.

macOS

Drag the extracted Godot application to /Applications/Godot.app, then drag it to the Dock if desired. Spotlight will be able to find Godot as long as it's in /Applications or ~/Applications.

Linux

  • Move the Godot binary to a stable location (i.e. outside of your Downloads folder), so you don't accidentally move it and break the shortcut in the future.

  • Rename and move the Godot binary to a location present in your PATH environment variable. This is typically /usr/local/bin/godot or /usr/bin/godot. Doing this requires administrator privileges, but this also allows you to run the Godot editor from a terminal by entering godot.

    • If you cannot move the Godot editor binary to a protected location, you can keep the binary somewhere in your home directory, and modify the Path= line in the .desktop file linked below to contain the full absolute path to the Godot binary.

  • Save this .desktop file to $HOME/.local/share/applications/. If you have administrator privileges, you can also save the .desktop file to /usr/local/share/applications to make the shortcut available for all users.

Is the Godot editor a portable application?

In its default configuration, Godot is semi-portable. Its executable can run from any location (including non-writable locations) and never requires administrator privileges.

However, configuration files will be written to the user-wide configuration or data directory. This is usually a good approach, but this means configuration files will not carry across machines if you copy the folder containing the Godot executable. See File paths in Godot projects for more information.

If true portable operation is desired (e.g. for use on an USB stick), follow the steps in 自己完結型モード.

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

For all the reasons above, we have to be selective of what we can accept as core functionality in Godot. This is why we are aiming to move some core functionality to officially supported add-ons in future versions of Godot. In terms of binary size, this also has the advantage of making you pay only for what you actually use in your project. (In the meantime, you can compile custom export templates with unused features disabled to optimize the distribution size of your project.)

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

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

これを実現する最も一般的で適切な方法は、代わりに、ゲームでは単一の基本解像度を使用して、異なる画面アスペクト比のみに対処することです。これが必要になるのは主に2Dにおいてであり、3DではカメラXFov (X視野角) またはYFovの問題になります。

  1. ゲームの基本解像度を1つ選択します。2Kあるデバイスであれ、400pだけのデバイスであれ、デバイスの通常のハードウェアスケーリングは、パフォーマンスコストをほとんど又はまったくかけずに対応できます。最も一般的な選択肢は、1080p(1920x1080)または720p(1280x720)です。この解像度が高いほどアセットが大きくなり、メモリの使用量が多くなり、ロードに時間がかかることに注意してください。

  2. Godotのストレッチオプションを使用します。アスペクト比を維持したまま2Dストレッチを行うと、最適な結果が得られます。この方法については、チュートリアル複数の解像度を参照してください。

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

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

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

小さな画面(幅が300ピクセル未満)の古いデバイスでもゲームを動作させたい場合は、エクスポートオプションを使用して画像を縮小し、そのビルドをAppStoreまたはGooglePlayの特定の画面サイズで使用するように設定できます。

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

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

また、これらのトピックに関する公式ブログの投稿を参照してください:

GDScriptの実装、Godotモジュール、およびGodotの非公式Pythonサポートもご覧ください。これは、別のサードパーティライブラリがどのようにGodotに統合されるかを知る良い出発点です。

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

詳細については、エディタでコードを実行するを参照してください。

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

素晴らしい!オープンソースプロジェクトとして、Godotは、あなたのような開発者の技術革新と野心によって支えられています。

まずはじめに見るべきはissuesです。あなたの共感を呼ぶIssueを見つけ、How to Contributeでforkや編集の方法を学び、そしてプルリクエストを提出してください。

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

Godotにアイデアをもたらしたいと思うかもしれません。たとえば、大規模なコアの変更が必要なことであったり、他のゲームエンジンがしていることを取り入れたり、あるいは代替ワークフローをエディタに組み込むべきといったことです。これらは素晴らしく、そのような貢献をのぞむ意欲的な方々に感謝しておりますが、Godotがあくまで重視しているのは、コア機能をロードマップに定められたとおりにすること、バグをつぶしたり問題に対処すること、そしてGodotコミュニティメンバー同士の対話です。

それよりも、Godotコミュニティのほとんどの開発者は、以下のようなことを知りたいと思っているでしょう:

  • あなたがソフトウェアを使って得た体験と問題(我々は改善のアイデアよりも、これに重きをおいています)。

  • あなたのプロジェクトで必要なので、新たに実装してほしい機能。

  • 使い方を学ぶにあたって理解しにくかった概念。

  • あなたの作業フローにおいて、最適化したい部分。

  • 明確なチュートリアルを見逃した部分、またはドキュメントが明確ではなかった部分。

Godotに対するあなたのアイデアが歓迎されないとは思わないでください。それよりも、それらを最初に問題としてまとめ上げてみてください。そうすれば、それは開発者とコミュニティがあなたのアイデアを土台にした機能を実現する為の基礎になります。

コミュニティでアイデアや問題を共有するための良い方法は、ユーザーのストーリーとして共有することです。あなたが 何をしようとしているのか、どのような行動が起こると予想されるのか、そして実際にどのような行動が起こったのかを説明してください。 この方法で問題やアイデアを立案すると、コミュニティ全体が開発者エクスペリエンス全体の改善に集中できるようになります。

スクリーンショット、具体的な数字、テストケース、またはサンプルプロジェクト(該当する場合)はボーナスポイントをもたらします。

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

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

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

ただし、モバイルプラットフォームでは low-processor モードがまだサポートされていないため、Godotを使用して モバイル アプリケーションを作成することはお勧めしません。

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はSTL (Standard Template Library)を使わないのですか?

他のライブラリのように(例えばQt)、GodotはSTLを使いません。私たちはSTLが素晴らしい標準的な目的のためのライブラリだと信じています、しかし、私たちはGodotのために特に必要とはしていません。

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

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

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

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

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

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

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

さらに、例外を処理する機能の分、実行ファイルのバイナリサイズが大幅に増加します。

GodotがRTTI(実行時型情報)を強制しないのはなぜですか?

Godotには独自の型キャストシステムがあり、オプションで内部でRTTIを使用できます。 GodotでRTTIを無効にすると、わずかなパフォーマンスコストで、かなり小さいバイナリサイズを実現できます。

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

多くの重いパフォーマンスタスクのためにGodotは内部的に可能な限り最高のキャッシュコヒーレンシーを使用しようとしていますが、ほとんどのユーザーはDoDプラクティスを強制する必要はほとんどないと考えています。

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

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

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

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

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

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

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