よくある質問

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を作った動機はどのようなものですか?

Godot専用のスクリプト言語を作った主な理由は以下の通りです:

  1. ほとんどのスクリプトVM(Lua、Python、Squirrel、JS、ASなど)ではスレッドサポートが不十分ですが、Godotはスレッドを使用します。
  2. ほとんどのスクリプトVM(Lua、Python、JS)ではクラス拡張のサポートが不十分で、Godotの動作方法に適応させる作業は非常に非効率的です。
  3. 既存の多くの言語(Lua、Python、Squirrel、JS など)では、C++とバインドするには、恐ろしく悪いインターフェイスを使わなければなりません。その結果、大量のコード、バグ、ボトルネック、および全般的な非効率性が生じてしまいます。私たちは、すごい量の結合用コードではなく、すごいエンジンのために集中したかったのです。
  4. (Lua、Python、Squirrel、JS、ASなどには)ネイティブなベクトルタイプ(vector3、matrix4など)がないため、その代わりにカスタムタイプを使用する必要がありますが、それによってパフォーマンスが大幅に低下します。
  5. (Lua、Python、JS、ASなどでは)ガベージコレクタが原因で速度低下が発生したり、不必要にメモリ使用量が増えたりします。
  6. (前記の各種言語では)コード補完、ライブ編集などを提供するコードエディタとの統合が困難です。(それらすべて)これはGDScriptによってサポートされています。

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

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

Godotは、OpenCollada エクスポーターを介してColladaをサポートしています(Maya、3DSMax)。 Blenderを使用している場合は、我々の `Better Collada Exporter <https://godotengine.org/download>`_をご確認ください。

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

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

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

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

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

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

Godotではサポートされていないが、自由でオープン ソースの統合を提供するサードパーティ製のSDKがわかっている場合は、統合作業を自分で開始することを検討してください。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サポート<https://github.com/touilleMan/godot-python>`_もご覧ください。これは、別のサードパーティライブラリがどのようにGodotに統合されるかを知る良い出発点です。

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

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

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

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

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

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

  • あなたがソフトウェアを使って得た体験と問題(我々は改善のアイデアよりも、これに重きをおいています)。
  • あなたのプロジェクトで必要なので、新たに実装してほしい機能。
  • 使い方を学ぶにあたって理解しにくかった概念。
  • あなたの作業フローにおいて、最適化したい部分。
  • 明確なチュートリアルを見逃した部分、またはドキュメントが明確ではなかった部分。

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