よくある質問

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)

ゲームの書き出し:

  • 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がDirect3Dの代わりにVulkanやOpenGLを使うのはなぜですか?

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

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

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

なぜGodotはそのコア機能セットを小さいままにすることを目指しているのですか?

Godot intentionally does not include features that can be implemented by add-ons unless they are used very often. One example of this would be advanced artificial intelligence functionality.

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

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

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

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

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

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

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

この質問は頻繁に出てきますが、これはおそらく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に対するあなたのアイデアが歓迎されないとは思わないでください。それよりも、それらを最初に問題としてまとめ上げてみてください。そうすれば、それは開発者とコミュニティがあなたのアイデアを土台にした機能を実現する為の基礎になります。

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

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

Is it possible to use Godot to create non-game applications?

Yes! Godot features an extensive built-in UI system, and its small distribution size can make it a suitable alternative to frameworks like Electron or Qt.

When creating a non-game application, make sure to enable low-processor mode in the Project Settings to decrease CPU and GPU usage.

That said, we wouldn't recommend using Godot to create a mobile application since low-processor mode isn't supported on mobile platforms yet.

Check out Material Maker and Pixelorama for examples of open source applications made with Godot.

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

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

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

What user interface toolkit does Godot use?

Godot does not use a standard GUI toolkit like GTK, Qt or wxWidgets. Instead, Godot uses its own user interface toolkit, rendered using OpenGL ES or Vulkan. This toolkit is exposed in the form of Control nodes, which are used to render the editor (which is written in C++). These Control nodes can also be used in projects from any scripting language supported by Godot.

This custom toolkit makes it possible to benefit from hardware acceleration and have a consistent appearance across all platforms. On top of that, it doesn't have to deal with the LGPL licensing caveats that come with GTK or Qt. Lastly, this means Godot is "eating its own dog food" since the editor itself is one of the most complex users of Godot's UI system.

This custom UI toolkit can't be used as a library, but you can still use Godot to create non-game applications by using the editor.

なぜ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サイトの対応するページをご覧ください。