よくある質問¶

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

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

要約すれば:

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)
Web
Android (実験的)

ゲームの書き出し:

Windows (およびUWP)
macOS
X11 (Linux, *BSD)
Android
iOS
Web

デフォルトは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機能を通じてサードパーティによる対応が可能です。例えば現在、PythonやNimの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専用のスクリプト言語を作った主な理由は以下の通りです:

ほとんどのスクリプト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は上記の問題を減らすように設計されています。

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¶

Godot の実行可能ファイルを安定した場所（ダウンロードフォルダ以外など）に移動し、将来誤って移動してショートカットが壊れないようにします。
Godotの実行ファイルを右クリックして**ショートカットの作成**を選択。
作成したショートカットを``%LOCALAPPDATA%MicrosoftWindowsStart MenuPrograms``へ移動します。これは、スタートメニューに表示されるショートカットのユーザー共通の場所です。また、実行ファイルを右クリックして「タスクバーにピン留め」を選択すれば、Godotをタスクバーにピン留めすることができます。

macOS¶

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

Linux¶

Godot の実行可能ファイルを安定した場所（ダウンロードフォルダ以外など）に移動し、将来誤って移動してショートカットが壊れないようにします。
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/3.x/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の幅が非常に広くなりました。

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

ゲームの基本解像度を1つ選択します。2Kあるデバイスであれ、400pだけのデバイスであれ、デバイスの通常のハードウェアスケーリングは、パフォーマンスコストをほとんど又はまったくかけずに対応できます。最も一般的な選択肢は、1080p(1920x1080)または720p(1280x720)です。この解像度が高いほどアセットが大きくなり、メモリの使用量が多くなり、ロードに時間がかかることに注意してください。
Godotのストレッチオプションを使用します。アスペクト比を維持したまま2Dストレッチを行うと、最適な結果が得られます。この方法については、チュートリアル複数の解像度を参照してください。
最小解像度を決定し、ゲームを縦横比ごとに垂直または水平に伸ばすかどうか、または縦横比を固定して余白に黒いバーを表示するかどうかを決定します。これについては、複数の解像度でも説明されています。
ユーザインタフェースでは、anchoringを使用して、コントロールの位置と移動先を指定します。UIがより複雑な場合は、コンテナについて学ぶことを検討してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ライブラリとして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サイトの対応するページをご覧ください。