本当にあなたの投稿が好きです。

編集：
くそーそれはこの段落を見落としました

ソースレベルでの変更が必要な場合に備えて、実際にファイルをプロジェクトにコピーする方法があります。 その場合にのみ、ファイルをプロジェクトフォルダ自体に取り込む必要があります。 「複製された」アセットは、.customのような隠しフォルダーに存在する可能性があります。

だからあなたは基本的に私が持っていた懸念をカバーしました。 （ごめん）
ワークフローと動作をどのように想像するかについて、さらに詳しく説明します。

役職：
ただし、1つのワークフローはIMOを見落とされています。
資産を単なるリソースまたは最初の構築石として使用します。
現在の非常に透過的でシンプルなアプローチでは、いくつかのアセットをダウンロードすることもできます。 いくつかのファイルを削除します。 いくつかのpngと、必要な機能のいくつかを備えたスクリプトを保持するよりも。 現在、それらに取り組んで変更することが可能です。

アセットが.local/godot/assetsフォルダーに隠されている場合、この機能は失われます。

提案

アセットは引き続き表示され、エディタファイルブラウザに一覧表示されます。 それらが.local/godot/assetsフォルダー内にあるかプロジェクトフォルダー自体にあるかは独立しています。 したがって、ファイルを参照して、適切なドキュメントがない場合、またはファイルから学習したい場合に、ファイルがどのように機能するかを理解できます。
「アセット」であるすべてのフォルダも、ある種のアイコンが付いたものとしてマークする必要があります。これにより、アセットとは何か、実際のファイルが保存されている場所の概要を把握できます。
すべてのアセットを一覧表示するエディターウィンドウも必要です。 （テーブル内）

• Downloadedには、ダウンロードされたすべてのアセットが一覧表示されます。 ボタンをクリックするだけでプロジェクトに追加できます。 ただし、それ以外は、アセットライブラリのアセットと同じです。 このリストはどのプロジェクトでも同じであり、プロジェクト自体には影響しません。 （概要を簡単に把握できます。プロジェクトを開くときに、このリストをクリアしてすべてのアセットを再ダウンロードするのも簡単です。）
• 常にアクティブ（基本的に、すべてのプロジェクトで「このプロジェクトで使用（アクティブ/非アクティブ）」を切り替えるだけです）これらのアセットは、マシン上のすべてのプロジェクト（新しく作成されたプロジェクトも含む）に追加されます。 （たぶん、アセット自体がそれを可能にする必要があります。）それらは本当にエディター指向です。 隅にある時計のように、gitサポート、todoリスト、またはいくつかのデフォルトリソースを用意します:(カスタム環境、各プロジェクトの開始時に使用するいくつかのテーマとスプライトの束）...
  プロジェクトごとに手動で非アクティブ化できます。
  それらはまだプロジェクトファイルシステムにリストされており、他のassed/pluginと同じように動作します。 そのため、ファイルを参照して、それらがどのように機能するか/何をするかを確認できます。
• このプロジェクトで使用される（アクティブ/非アクティブ）これは、実際にはプロジェクトファイルシステム内のリンクされたフォルダーを示します。 および「追加」（これらはまだ.local/godot/assetsフォルダー内にありますが、プロジェクトのローカルファイルのように動作します）。ファイルをプロジェクトに追加します。
  ここで、アクティブ化するアセットのバージョンを選択することもできます。 そして、バージョンを切り替えます。

アセットからファイルを編集/保存/更新するとすぐに、2つのオプションが表示されます

.local/godot/assetsで保存

.local/godot/assetsのアセットを更新して、カスタムユーザーバージョンにします。
パッケージマネージャーがgitベースの場合、カスタムユーザーバージョンは1つの追加コミットである可能性があります。 保存するたびにcommit --amendが取得されます。
（たとえば3.2.5/user ）そして他のすべてのプロジェクトでも利用できます。 （これらの他のプロジェクトのバージョンをユーザーバージョンに更新する場合）
なぜこれが便利なのですか？
アセットストアのテーマはほぼ完璧ですが、フォントタイプが嫌いです...
フォントタイプを変更して、新しいアセットバージョンとして保存します。 他のすべてのプロジェクトに再度アクセスし、アセットのバージョンを/userに変更します。 今、あなたは幸せです。
アセットのユーザーバージョンを公開するためのボタンが1つあるかもしれません。
そのため、アセットストアでは、他のpplにも、微調整を加えたユーザーバージョンを選択するオプションがあります。
アセットgitリポジトリへのprを作成するための中間体と同じように。 （または、アセットの作成者が/userバージョンからマスターの新しいバージョンへの変更をチェリーピックします。）

プロジェクトにローカルにする

.local/godot/assetsフォルダーから現在のプロジェクトにファイルをコピーします...特別なアセットの動作（バージョンなど）を削除します。これで、好きなようにそれをいじることができます。 （また、フォルダーはアセットとしてのカスタムの外観を失います。）

これにより、アセットストアはテンプレートのユースケースもカバーできます。 そして、ほとんどすべてのアート関連のアセットに最適です。 必要に応じてアセットを作成することができるので。
すでにダウンロードされているアセット（いくつかの基本的なプロトタイプスプライトなど）をいつでもアクティブ化してローカルにし、インポートすることができます。

ランダムな考え

これは、独自のローカルアセット/リソースライブラリ/コレクションにとっても優れたソリューションになる可能性があります。 .local/godot/assets内のフォルダーを使用すると、OSファイルマネージャーで検索しなくても、優れたエディターUIを使用してそのコンテンツをGodotプロジェクトに追加できます。

AssetLibとAssetLib統合（エディターとGDScriptの両方）の両方が、コアエンジンに含める代わりにそれをプッシュし続ける場合は、愛が必要であることに同意します。

しかし、私は個人的に、これがプラグインをどれだけ強くプッシュすべきかについては同意しません。

新しいPRについて私たちが自問する最初の質問は、これがプラグインである可能性があるのではないでしょうか。 むしろ、これはコアになるのに十分に使用されるのでしょうか？ 。

プラグインに問題があります。

• 人々はそもそも自分が何を探しているのかを知る必要があります。 Godotは初心者を対象としています。 初心者向けのソフトウェアは通常、誰かが（合理的に）必要とするすべてのものを手に入れようとします。そうしないと、最初に不足しているものとそれを取得する方法を学ぶ必要があるからです。
  初心者がGentooではなくUbuntuを使用するのには理由があります。 あなたがその依存関係システムをどれほど素晴らしいものにするかに関係なく。
• 意思決定の麻痺が存在します。 Godotに機能がある場合は、それを使用するのに1秒かかります。 そのためのプラグインが5つある場合、どれを使用しますか？ たとえば、5つ以上のコンソールプラグインがあります。 初心者はどちらを選ぶべきですか、そしてその理由と、この決定に合理的に費やすべき時間はどれくらいですか？
• プラグインは放棄され、品質が低下し、更新時に遅れます。 ランダムなプラグインが爆発しないと信じる理由は、背後に十分な数の人がいるGodotを信頼するよりもさらに少ないです。
• Unityを参照してください。 彼らの資産はほとんどが有料であり、多くの場合、最初にプラグインが必要であり、プラグインは有料であり、通常は少なくともある程度のサポートが可能ですが、最終的には統合が不十分であるか、更新時に壊れます。
• ドキュメント：とにかくこれは十分ではありません。 コアにないすべての機能は、公式のチュートリアル/ドキュメントでは使用できません。 プラグインのランダムな独身者は、ドキュメントや短い例だけを提供しない可能性があり、プロジェクトでその機能を他の機能とシームレスに統合する方法に関するデモや本格的なチュートリアルを提供するより価値のあるビットではありません。

例：

• スプリングアームノード。 （https://github.com/godotengine/godot/pull/18822）適度に小さな追加で、独自のクラスに分けられているため、物事を壊してはなりません。すべてのサードパーソンゲームではなくても、多くの3Dゲームで使用されます。 応答：プラグインである必要があります。
• RNGのものについても、プラグインとして使用することが議論されました。 ゲームの90％がどこかにRNGを必要としていないかのように。

編集：明確にするために、私はすべて膨張を避けるためです。 しかし、これはバランスであり、プラグインにすべてが含まれていないことに対するサポートを表明したいと思います。 非常にゲーム固有または広く使用されていないもの、プロプライエタリプラグイン、大きな依存関係、はい、お願いします、それらをAsset Libに入れてください！

@karroffelこれは素晴らしい投稿であり、私はあなたが言ったことすべてにほぼ同意します。 ただし、この点についてコメントしたいと思います。

アセットはバージョンが関連付けられた状態で保存され、すべて.local / godot/assetsなどに保存されます。 それらはプロジェクト自体の一部ではなくなりましたが、システム全体で利用できます。

これは、Pythonpipシステムの動作と似ています。 その後、人々は、パッケージの最新バージョンが、システムにある他のプロジェクトを台無しにしていることに気づきました。 virtualenvはその問題を解決します。 Javascriptのnpmエコシステムでは、モジュールはデフォルトでプロジェクトにローカルにインストールされ、システム全体がオプトイン機能です（ npm install --global ）。 次に、 package-lock.jsonをソース管理にチェックインして、チームの全員がすべてのnpmモジュールの同じバージョンを使用していることを確認し、競合を回避します。

システム全体のパッケージは、人々のシステムの肥大化を減らすので優れています。 バージョンの固定は、チームが一貫したバージョンのセットを維持するのに役立ち、一緒に機能するバージョンの完全なコレクションを識別するのに役立つため、優れています。

システム全体のルートに行く場合は、バージョンの固定を維持することをお勧めします。 例えば：

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

プロジェクトAはfsm-1.0を使用できますが、プロジェクトBはfsm-1.1を使用します。 プロジェクトCが登場し、どちらかを再利用できます。 ユーザーは、 dependencies.jsonファイルまたは最小パッチ、マイナーバージョンまたはメジャーバージョンでプラグインの特定のバージョンを指定できる必要があります。

依存関係がダウンロードされると、 dependencies-lock.jsonファイルが生成され、ソース管理にチェックインされます。

@mhilbrunner私は間違いなく同意します。「これはプラグインである必要があります」という考え方が少し強すぎると思います。まさに、そのような状況がそれらの考えを引き起こしました。 SpringArmのようなもっと一般的なものはエンジンに入れる価値があると思います。また、Juanが削除したいInterpolatedCameraは、めちゃくちゃ便利でかっこいいです！ これらはほんの数行のコードですが、正しく処理するには時間がかかるため、「これは小さすぎます」もAssetLibraryにプッシュするための悪い理由です。

私の考えは主に「プロジェクトリーダーはそうだと言っていたので、新しい状況をより良くするために何ができるだろうか」ということに集中していました。

プラグインとしての機能の大幅なプッシュを少し下げてほしいのですが、どちらにしても、提示された変更は大いに役立つと思います！

@saltaresええそれは私の考えでした。 私はRustの貨物の大ファンです。 それはほとんど同じように動作します。 ライブラリは、ローカルで必要とされていたすべてのバージョンのシステム全体のフォルダにインストールされます。 説明は1つのファイルにあり、特定の構成は.lockファイルにあり、非常にうまく機能します。

私はこれがすでにいくつかの議論を引き起こしたことをうれしく思います：blush：

上記の点に対する私の見解は次のとおりです。

エンジンから物を押し出す

エンジンの外に物を押し出すことは、IMOが進むべき道です。 サイズの問題（モバイル、html5）を展開するプラットフォームが多すぎて、Godotのサイズのプロジェクトでは膨張が大きな懸念事項であるため、すべてを含めて満足することはできません。

私の哲学は、以下のすべての基準が満たされている場合にのみ、何かがエンジンの一部になるべきであるということです。

1. 比較的頻繁に使用されます
2. 自分でやるのは難しい
3. この機能を実行する方法は1つだけです

これにより、スプリングアーム、地形が除外されます。将来、InterpolatedCamera、Vehicleなど、エンジンの外側にあるはずの機能を削除するのに役立つことを願っています。

これに関する主な懸念は、何かが公式でない場合、それは維持されないということです。 これはあなたたちが間違っているところです。

これらのものは公式であってはならないと誰も言いませんでした、私たちはそれらのための公式リポジトリを持つことができ、それらはファーストパーティの拡張である可能性があります。 デモはこのように維持されており、最新であるため、公式の拡張リポジトリで機能しない理由がわかりません。

拡張機能はエンジンの一部のように感じる必要があります

これらの点について：

• カスタムノードの拡張を容易にし、言語間のスクリプト継承を可能にします

私はこれに非常に強く反対しています。 これを行うことには実際的なメリットはまったくなく、実装コストは非常に高くつきます。 申し訳ありませんが、それは素晴らしい機能のように感じますが、コスト/利益/リスクを重み付けすることは非常にマイナスの側面です。

また、カスタムノードまたはリソースがコアではないかのように表示されることもポジティブだと思います。エンドユーザーにとっては良いことです。 ユーザーは愚かではなく、この情報を隠してはなりません。

拡張機能から新しいノードが追加され、スクリプトを使用して実行された場合、これは作成ダイアログにも表示されます。

• スクリプトを添付する場合、スクリプトの継承は推奨されません。これらの場合のデフォルトはオーバーライドです。

これは間違いなく行う必要があり、非常に歓迎すべき追加です。

• アセットのシステム全体のインストールで適切な依存関係管理を追加します。 アドオンをプロジェクト自体から移動して、変更のために元に戻す方法を使用します

これについての私の感じは、それが素晴らしい働きをするか、明白な理由なしに壊れてしまう完全な混乱とアドオンをもたらす可能性があるということです。 他のエンジンがこれでどのように機能するかを見ると、依存関係の管理がそれほど重要ではないようです。

• アセットの場合に超長いパスを回避するために、スクリプトをクラス名と名前空間で参照できるようにします。

これは前に説明したことですが、私たちが到達した結論は、ほとんどの場合、スクリプト言語に依存する必要があり（エンジン自体によってコアScriptDBとして提供されるのではなく）、必要に応じて新しいスクリプトダイアログで使いやすさが少し向上するというものでした。グローバルクラスを使用します。

これについての私の感じは、それが素晴らしい働きをするか、明白な理由なしに壊れてしまう完全な混乱とアドオンをもたらす可能性があるということです。

私たちの場合、アドオンが自動的に更新されることはないと思いますが、代わりに、バージョンがリストされ、手動で更新されたインストール済みのアドオンのリストがあるはずです。これにより、ユーザーは更新を要求して、何かが壊れていないかすぐに確認できます。

このコメントは長さが長いため、折りたたまれたセクションに分かれています。

カメラが欲しいですか？ Godotには、コードをほとんどまたはまったく使用せずに、プレーヤーを追跡できるカメラがあります。 Godotでアニメーションを作りたいですか？ キャラクターアニメーションを作成できるだけでなく、同じシステムで、これまで懸命に取り組んだカットシーンシステムを（ほぼ）置き換えることができます。必要なコードは5行程度です。 このエディターは、R​​PG inaBoxのような他のエディターを作成するためにも使用されています。 Godotでどれだけ作成できるかは素晴らしいです。

これで、これを読んでいる人なら誰でも、エンジンから物事を押し出すことに関するreduzのいくつかのポイントに対応しようとしているときに、私がこれに入ると考えていることを理解できることを願っています。 （これは、「拡張機能はエンジンの一部のように感じられるはずです」セクションには返信されません。現在、それについては考えていません。）

エンジンの外に物を押し出すことは、IMOが進むべき道です。 サイズの問題（モバイル、html5）を展開するプラットフォームが多すぎて、Godotのサイズのプロジェクトでは膨張が大きな懸念事項であるため、すべてを含めて満足することはできません。

膨満感が懸念されることには同意できますが、これまでに削除したいものを見つけたら、そのようなものを削除する価値があるかどうかを自問します。 Vehicle、InterpolatedCameraなどのノードを削除したとしても...ファイルサイズの違いは実際にどのくらいですか？ 多分0.5メガバイト？ 多分数メガバイト？ 数メガバイトの節約になったとしても、35MBのダウンロードと45MBのダウンロードの違いは何ですか？ ゲームアセットは、関係なく、その10MBの空白をすばやく埋めます！ エンジンの半分を取り除く予定がない限り、私には意味がわかりません。

できるだけ多くのスペースを節約することに本当に関心がある場合は、エンドユーザーが不要なノードをエンジンから簡単に削除できるようにすることをお勧めしますか？ エンジンを使用する予定の人に、膨満感に問題がないかどうかを判断させます。決定しないでください。

もちろん、私たちに与えられたすべての提案を含めることはできません...

1. 比較的頻繁に使用されます
2. 自分でやるのは難しい
3. この機能を実行する方法は1つだけです

...そしてこれらのガイドラインは、エンジンで何が許可されるべきかを精査するための素晴らしい出発点です。 課題追跡システムを介して送信されるすべての機能リクエストについて、3つのポイントすべてがすでに考慮されていることは間違いありません。

以下のすべての基準が満たされている場合にのみ、何かがエンジンの一部である必要があります

でもね。 機能またはノードの運命は、コア機能であることに大きく依存するべきではありません。 提案されたガイドラインは素晴らしいです。誤解しないでください。ただし、それらをチェックリストとして使用するべきではありません。 それは、YoYo Gamesがフォーラムで機能を提案するときに行うことであり、私が彼らのエンジンから追い出された理由のもう1つの部分です。拡張機能を使用して作成できますか？ はい？ それから私たちの応答は拡張を行うことです。 エンジン内にあることがどれほど合理的であるか、実装するのがどれほど簡単であるか、またはコミュニティがどのように感じているかに関係なく、代わりに拡張機能にできるために拒否された機能要求の数を推測しますその機能。

私が言っているのは、これらのガイドラインを確実に念頭に置くことができるということです。 機能が提案されるたびにそれらを考慮することができます。 しかし、それらすべてが当てはまるかどうかは、機能が組み込まれるかどうかを決定する要因ではありません。アイデアをそれらのガイドラインと比較検討し、それらのガイドラインのそれぞれがどれほど重要であるかを検討し、それらの要因に重みを適用します...アイデアが当てはまらないという理由だけであまりにも頻繁に使用されているからといって、自動的に悪い考えになるわけではないようです（数年の経験があっても、実際の使用方法がわからない場合があることに注意してください）。 アイデアを自分で実装するのが簡単だからといって、それが悪いアイデアであると自動的に意味するわけではありません。 そして、アイデアを複数の方法で実装できるからといって、それが悪いアイデアであるとは限りません。 言うまでもなく、誰かがアイデアXを提案しているのは、他の人がそれから恩恵を受けると考えているからです。

これは初心者向けであると自称するエンジンであり、初心者がエンジンの一部ではないゲームに固有ではないものをコーディングする必要があるたびに、またはアセットライブラリを調べて必要なコードを取得する必要があることを忘れないでください、またはエンジンから必要なものを取得するために長い道のりを進むと、別のエンジンに向かって少し離れたり、ゲーム開発全体から離れたりする可能性があります。

tl; dr ：ガイドラインは、チェックリストではなくガイドラインとして使用される場合に最適です。

これに関する主な懸念は、何かが公式でない場合、それは維持されないということです。 これはあなたたちが間違っているところです。

これらのものは公式であってはならないと誰も言いませんでした、私たちはそれらのための公式リポジトリを持つことができ、それらはファーストパーティの拡張である可能性があります。 デモはこのように維持されており、最新であるため、公式の拡張リポジトリで機能しない理由がわかりません。

私は個人的にこの考えに同意しません。 私が上で言ったこと（バニラエンジンからそれを削除してもスペースをあまり節約できないということ）に加えて、それらすべてをGDscriptに変換するのか、それとも必要になるのかを尋ねる必要がありますそれらのノードを取得するためだけにエンジンを再コンパイルします。

• それらをC++として保持し、再コンパイルが必要な場合...なぜですか？ エンジンのコア部分を変更したり、独自の機能を追加したりしない限り、エンジンの再コンパイルが必要になる理由はありません。 コンパイルプロセスが完了するのを待っているだけでなく、平均的なユーザーがファーストパーティのノードを取得するためだけに二度と使用しない可能性のある他のツールをインストールする必要があるため、開発にかかる時間はわずかです。 今、それは肥大化のように聞こえます！

• それらをGDscriptに変換すると、GDscriptのすべての制限が発生します。 追加の子ノードの潜在的なオーバーヘッド（特に、このファーストパーティノードをシーンとしてインポートするようにユーザーに要求している場合）、クラスを参照するためにクラス名ではなくパスを使用する必要があるなどの制限（これに対処しましたが、どうやら、私はそれを上げる必要があると感じています）、パフォーマンスの低下（違いがいくら少なくても、それでも低い）など。再コンパイルからに移行したため、C++よりも少し理想的です。ドラッグアンドドロップですが...

どちらのオプションも、これらのノードのファイルを、すべての新しいユーザー（C ++の場合）でエンジンにインポートするか、それらを使用するすべての新しいプロジェクト（GDscriptの場合）でプロジェクトフォルダーにインポートする必要があることを意味します。 他の人のことはわかりませんが、それは私には面倒なことのように聞こえ、最初のガイドライン（「比較的頻繁に使用される」）を非常に議論の余地のあるものにするように思えます。 なぜそう思うのか説明しようと思います。

これらのノードを使用するために追加の作業が必要になることで、このファーストパーティソリューションの使用数が減少し、このファーストパーティソリューションが以前のように「比較的頻繁に」使用されなくなると確信しています。 その結果、人々がファーストパーティのソリューションがあることを学ぶのをやめたときに同じ機能を再現する選択肢の数が徐々に増えます-既存のバージョン（この場合は私たち自身のもの）を好むと確信しているとき機能Xを追加して新しいものを作成したり、機能Yを追加したり、両方の機能を備えているが最適化されていない新しいものを作成したりするのではなく、改善する必要があります。ファーストパーティのソリューションがあるかどうかわからない。 それは混乱を引き起こしています。

さらに、あなたは彼らが維持されると言います。 それは素晴らしいことです！ しかし、誰がそれらを維持するつもりですか？ このリポジトリに新しいものを追加するためのガイドラインは何ですか？ そして、安定版リリースでもマスターでも、このファーストパーティ拡張機能のリポジトリが常に機能するようにする努力をしますか？ 基本的に、効果的に別のプロジェクトであるものの努力の価値はありますか？

ちなみに、私はノードごとに複数のスクリプトを実装することを好みますサポート
言語間の継承ではなく。 前者はほんの数行です
コードの。

2018年6月10日13:51に、 PLyczkowskinotifications @github.comは次のように書いています。

これについての私の気持ちは、それが素晴らしい働きをするか、結果として
明白な理由なしに壊れた完全な混乱とアドオン。

私たちの場合、アドオンは自動的に更新されるべきではないと思いますが、
代わりに、バージョンがリストされたインストール済みのもののリストがあるはずです
手動更新なので、ユーザーは更新をリクエストして、次の場合にすぐに確認できます。
何かが壊れた。

—
コメントしたのでこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
。

ノードごとに複数のスクリプトが数回試行され、常に失敗します。

試みられたのはマルチスクリプトノードですが、それは面倒でした

2018年6月10日15: [email protected]は次のように書いています。

ノードごとに複数のスクリプトが数回試行され、常に
失敗します。

—
コメントしたのでこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
。

アセットは組み込みのものと同じに見えるべきではないことを理解しています。 しかし、ユーザーが作成したスクリプトよりも上位のスクリプトにする必要があるとも思います。 プロジェクトからアセットをマイニングすることなくアセットを簡単に交換/アップグレードできるように、アセットは明確に分離されている必要があります。

また、アセットのレイヤーを追加し、それらをエンジンとより適切に統合して拡張できるようにすることは、アセットライブラリを介して新しい機能を簡単に提供しながら、コアを小さくクリーンに保つための優れた方法です。 アセットがノード/リソースだけでなく、拡張されるクラスに対しても、グローバルにアクセス可能な方法で（つまり、パスに依存しない方法で）新しいタイプを登録できる場合、フレームワークがエンジン上に構築されることは大きなメリットになります。

Escoriaのようなフレームワークは、それから多くの利益を得ることができ、RPG、プラットフォーマー、ビジュアルノベルなどの他のフレームワークが存在する可能性があります。

ここで言っていることはすべて非常に抽象的なものですが、組み込みのもの、サードパーティの資産、およびユーザーコード（この分離が提示されている場合でも）を明確に分離することで、「コアを小さく保ち、拡張機能を提供する」ことができます。 「とても簡単に前進できます。

言語間の継承は、私には恐ろしい考えのように聞こえます。

EditorDataのTypeDBで行ってきた作業では、名前空間化されたタイプ名をファイルパスHashMapに保持しており、変更するとProjectSettingsのディクショナリに変換されます。 私のブランチでは、GDScriptパーサーとコンパイラーがこのデータを使用して、型のグローバル名を作成しています。 現時点では、カスタムタイプのスクリプトが表示されています。 スクリプトは、名前でそれらにアクセスして継承できます。 さらに、このデータには、ProjectSettingsを表示できるすべてのユーザーがアクセスできます。 そのため、エディターに表示されるCSharpScriptは、ProjectSettingsディクショナリに入力されるマッピングを生成して、C＃で宣言された型にGDScriptからアクセスできるようにすることができます。 ProjectSettingsディクショナリデータをC＃オブジェクトにラップして、アクセス時にスクリプトオブジェクトを返す方法もおそらくあります。そうすれば、C＃は名前でGDScriptタイプにもアクセスできます。

この手法は、共有名前空間をコアから外し、純粋にエディターコンテキスト内に保持します。これにより、オプトインする言語は、データにアクセスするための独自の手段を準備できます。

私は@karroffelの提案が好きですが、言語間のスクリプト継承を可能にすることができます（それが可能かどうかさえわかりません）。 どういうわけか、ベーススクリプトへの呼び出しを委任し、すべて同じプロパティ/シグナル/定数などを定義するメソッドを自動的に複製します。

私も、AssetLibraryのコンテンツへのより合理化されたアクセスを望みます。これには、エディター全体のプラグインと、単一のプロジェクトのプラグインを保持する機能があります。

私が作成しているTypeDBシステムは、エディターのサポートも提供します...

1. すべてのカスタムスクリプトをCreateDialogに表示させる
2. カスタムタイプのスクリプトを拡張すると、ノードにスクリプトを追加するときにそのスクリプトが自動的に拡張されます
3. カスタムタイプスクリプトを拡張するスクリプトを削除して、削除後にカスタムタイプスクリプトを復元します（したがって、カスタムスクリプトを削除することはできません。代わりに、エディターで[タイプの変更]コマンドを使用する必要があります）。

また、私が行っているすべてのインターフェイスの変更により、カスタムタイプのスクリプトがスクリプトであると明確に理解され、問題のスクリプトにアクセスできるようになります。 ユーザーは常にスクリプトとは何かを知っており、スクリプトにアクセスできるようになりますが、それでもある程度はエンジン内のオブジェクトのように感じることができます。 GDScript内でも、名前はコアタイプであるかのようにグローバルにアクセスされるのではなく、 Scriptsというグローバルディクショナリから抽出されます。 これまでのところ、カスタムタイプのスクリプトで動作していますが、最終的には、辞書にカスタムタイプのシーンと、プロジェクトで使用可能な一般的なスクリプトまたはシーンを登録させるように拡張したいと思います。スクリプト言語がない場合は、インポートシステムを使用する可能性があります。名前空間付きのタイプ名を取得する簡単な方法があります。

私はこの提案の思考プロセスの一部であったので、いくつかのことを指摘したいと思います。

Godotの私のビジョン

TLDR：Godotは、非常に簡単で、モジュール式で、初心者に優しい方法で、アセットとプラグインを使用して高度に拡張できるツールだと思います。

私のSpringArmprの拒否の背後にある動機は合理的であり、それが@karroffelと私が、エンジンが軽量でありながらユーザーフレンドリーであり続けるための方向性について話し合った理由です。

私が見たいのは、クリーンで小型かつ高速なコアエンジンと、アドオンとプラグインの十分に統合されたエコシステムです。
ArchLinuxには複数のパッケージリポジトリがあるので、Godotにコア機能（および現在コアとなっているノード）用の「公式」（Godotによって管理されている）リポジトリとコミュニティ用の別のリポジトリがあれば素晴らしいと思います。 Godotコアの「拡張リポジトリ」には、コーディングが面倒であるが、バニラバージョンのエンジンに付属するのに十分ではなかったすべてのノードを配置します。
ちなみに、考慮されないことが多いのは、一部の機能はコーディングが簡単な場合もありますが、これらの数行を配置する前に多くの調査が必要になる場合もあるということです。

ユーザーがエンジン自体を「拡張」しているように感じるプラグインやアセットをダウンロードできると想像します。ダウンロードする内容に応じて、Godot-fps、Godot-platformer、またはGodot-racingがあります。

Godotは、本当にUnixライクでモジュール式であると感じた最初のエンジンであり、エディター拡張機能を備えたUnityをも凌駕する可能性があります。 多くの人は、Linuxシステムが「そのディストリビューション」ではなく、非常に個人的な機能を備えた独自のカスタマイズされたシステムである場合に、どれほど快適に感じるかを知っています。

利点

TLDR：このアプローチにより、Godotの管理者は、エンジンの肥大化についてあまり心配することなく、ハードコアな技術コア機能とよりユーザーフレンドリーなプラグインを個別に管理できるようになります。

この提案の良いところは、関心の分離と寄稿者の扱いです。 今のところ、コアに何が入っていても大丈夫なのか、そうでないのかははっきりしていないと思います。 明確なルールや統計データはありません。 特定の機能が広く使用されていると言う人もいれば、そうではないと考える人もいます。

Godotをさまざまな「リング」に分割すると、PRと機能をよりきめ細かく管理できるようになり、 @ reduzやその他の非常に技術的な開発者がハードコアな技術に集中できるようになり、別のチームが拡張リングを管理できるようになります。 「エクステンションリング」はオンデマンドで肥大化するため、エンジンの肥大化に直面するのではなく、ユーザーのフィードバックと使いやすさをより考慮します。

多言語継承について

Godotが成長するにつれて、アセットストアは簡単に燃えるような混乱になる可能性があります。 スクリプト言語間の厳密な分割は、人々が資産を販売し、資産ストアでエコシステムを成長させる試みを文字通り破壊し、フリーランスのツールメーカーがGodot用のツールを作成および販売する多くの機会を殺します。
チャンチに活気のあるエコシステムを開発させたい場合は、言語ブリッジをより完全にする必要があります。
今のところ、言語間の継承は私には素晴らしいと思いますが、私はこの問題について何も言うほど技術的ではありません。 特に、C＃の周りには非常に大きなコミュニティがあるため、すぐに現れる可能性のある問題を指摘したいと思います。

使いやすさについての注意

私はもう1年近くGodotを使用していますが、最近、機能を決定する人々が小さなデモよりも大きなものにエンジンを使用していないように感じています。 @ LikeLakers2は、開発中のコアチームに深く関わっていない一部のユーザーが共有していると感じる問題を指摘しました。

膨張と見なされることは、より大きな計画の中で些細なトピックだと思います。私たちが今下す決定が、Godotの生涯にわたって従う必要があることではありません。 オープンソースであるということは、私たちが好きなときにいつでも変更を加えることができるということです。唯一の問題は、待つ時間が長くなるほど、変更の決定が重くなるということです。

さて、それはまた別の日の議論です。 現在のところ、事実は次のとおりです。

1. Godotは、コンパクトで高速なポータブルゲームエンジンです。 そして、私はそれがとても好きですが、....
2. Godotの実行可能ファイルは、さまざまな要因に応じて約45〜60MBです。 ただし、エクスポートテンプレートは300MBにもなる可能性があります。 さて、それは最初のポイントへの大きな打撃です。
3. Godotには、Camera follow、Parallax BG、Vehiclesなどの初心者向けのすばらしい機能がたくさんあります。これは、他の同様のゲームエンジンに比べて大きなプラスです。 Godotでのゲームの作成がはるかに簡単になるためです。 そして、Godotは、そのようなツールの独自の実装を作成するスキルを持たない多くの初心者開発者の本拠地になります。

膨満感があると考える機能を削除するとどうなるでしょうか。 さて、エンジンは確かによりコンパクトになりますが、それは必要ですか？ 100MBのエンジンをダウンロードしても、自分のニーズをよりよく満たすことができれば、問題はありません。 しかし、エクスポートについてはどうでしょうか。100MBのエンジンはより大きなゲームをエクスポートしませんか？

おそらくそうですが、デスクトップが256BG SSD + 1TB HDD未満のものを使用していないようで、電話でさえ最小16GBから始まるスペースがあり、そのすべてが増加する可能性が高い世界では、それはそれでしょうか悪い？
つまり、まだ何も削除する必要はありません。いくつかのことをより適切に管理し始める必要があります。それで十分です。
機能には、コアに含まれるかどうかを決定するためのある種の重要度リストが必要ですが、それはそれが法律になることを意味するのではなく、経験則になることを意味します。

ニットピッカーの場合、非常に未使用のツールをいくつか削除できますが、それだけです。 不注意でない限り、機能がエンジンを肥大化させることはありません。 そして、Unityのすべての肥大化でさえ、人々がそれを使用するのを止めていません。
そして、私は絶対に私たちが膨満感を気にするべきではないという意味ではありませんが、注意することと妄想的であることはまったく別の問題です。

多言語継承に関しては、ここでは実際には使用されていません。 確かに、複数の言語のスクリプトと対話できるはずですが、継承です！ それは私が想像するよりも多くの仕事であり、それだけの価値がないように思われる利点があります。
一方、マルチスクリプトは、アドオンの作成からモジュール性の向上まで、多くの問題の解決策にすぎない可能性があります。 それが私の見解ですが。

ボックスに含まれるノードとリソースの種類の数を制限することについては、言いたいことがあります。 あまり使用されていないアセットを外部のダウンロードに振り向けることで、1。機能の幅広さに圧倒されることなく（意思決定の麻痺）、新しい人々が「いじり回す」だけでシステムを把握しやすくなります。 2.より狭いユースケースシナリオのアセットの一部が、後で別のAPIを使用して提供されるものほど良くないワークフローを持っていることが判明した場合でも、多くのレガシーバゲッジを作成することにならないでください。

後者がビルトインで発生する場合、あなたはそれらで立ち往生しています。 ダウンロード可能なアセットで発生した場合、最も人気のあるアセットは時間の経過とともにデファクトスタンダードになる傾向がありますが、Godotの運命と永続的に絡み合うことはありません。 つまり、予想されるコアの互換性を損なうほど心配することなく、あいまいにフェードインする可能性があります。

言語間の継承ポイントには、いくつかの説明が必要です。 それは悪い考えだと思うだけでなく、それがどのようにリモートで可能であるかさえわかりません。

1. Godotの実行可能ファイルは、さまざまな要因に応じて約45〜60MBです。 ただし、エクスポートテンプレートは300MBにもなる可能性があります。 さて、それは最初のポイントへの大きな打撃です。

300MBのエクスポートテンプレート？ 資産のことですか？

@neikeqは、プロジェクト全体がC＃であるが、AssetLibraryからダウンロードしたカスタムノードを使用している場合、そのノードは通常のノードであり、GDScriptが接続されている可能性があります。

ノードを「拡張」したい場合は、できません。 子ノードを追加して新しい機能を追加できると思いますが、そうするとオーバーライドできなくなります。

実装

現在、スクリプト言語は、一般化できる継承された呼び出しに非常によく似たパターンを使用しています。

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

ここのパターンは

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

そのため、スクリプト継承ツリーの最下部から開始し、そのようなメソッドが見つからない場合は上位レベルを呼び出そうとします。

各スクリプトに言語固有の継承構造ではなくRef<Script> parent_scriptがある場合、これは次のように一般化できます。

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

結局のところ、これは良い考えではないかもしれませんが、AssetLibをさらにプッシュすると、言語間のものをオーバーライドするオプションがないことが時間の経過とともに問題になる可能性があります。

@neikeqこれを見て、

@swarnimarunこれは、すべてのプラットフォーム、サポートされているすべてのアーチ、デバッグ、およびリリース用のエクスポートテンプレートであり、それらのサイズはエンジンの「肥大化」とはまったく関係ありません。 Linux X11 64ビットリリースのみをサポートすることを決定でき、このファイルは20MBになります...

@ akien-mga私はそれを呼ぶつもりはなかった、膨満感。
ただし、新しいユーザーはフルサイズでダウンロードしますが、個別にビルドしたり、特定のプラットフォーム用にダウンロードしたりできることを知るのに十分な経験はありません。

これが私たちが初心者ユーザーに提供するものである場合、それはどのように無関係ですか？

@ akien-mga：ノードを削除するための引数が

サイズの問題を展開する（モバイル、html5）

@swarnimarun @ Zireael07はい、エクスポートテンプレートのサイズは個別に重要ですが、私のポイントは、テンプレートのバンドルのサイズを測定しても何の指標にもならないということです。 1つのテンプレートのサイズ（たとえば、wasmリリーステンプレートの圧縮3.4 MB、またはAndroidリリースAPK、armv7とx86ライブラリで圧縮された23 MB）は、「開発に必要なすべてのものをダウンロードするには350 MBかかります」（+多分10何かを構築する必要がある場合は、VisualStudio用のGB...）。 サイズが重要なプラットフォーム（ウェブ、モバイル）で最小のゲームがどのサイズになるかは重要です。

デプロイのサイズは非常に重要だと思いますが、考慮に入れる必要があるのは開発者の時間でもあると思います。 たとえば、Unrealには文字通り探している機能がありますが、非常に多くの機能があるため、何かを行う必要があるたびに、最初にどの組み込み機能を見つける必要があるため、開発プロセスは非常に非効率になります。使用してから、適切に使用する方法を学ぶ必要があります。

これは私がGodotについて本当に好きなことです。 すぐに機能をコーディングすると、誰かが来て、「よし、この組み込みのものが使えることを知っていましたか？」と言うでしょう。

エンジンの機能が多すぎる場合の問題は、そのエンジンを使用して開発することは非常に疲れる経験になることです。 はい、必要なすべての機能を備えているのは素晴らしいことですが、実際に必要なものを理解するためにそれらすべてを調べるのは非常に苦痛です。 それは肥大です。 そのため、オンデマンドで十分に統合された機能を提案しています。

アセットのシステム全体のインストールで適切な依存関係管理を追加します。 アドオンをプロジェクト自体から移動して、変更のために元に戻す方法を使用します。

これは、移植性を失うことと同じです。 私のプラグインは私のプロジェクトの一部です。どのコンピューターでも、すべてのプロジェクトのすべてのプラグインを具体的に変更する必要があります。プラグインを.local/whateverに保存してもメリットはありません。 。 これは私のプロジェクトの一種の難読化です。

res：// addonsの実際のシステムは良いです...ユーザーは無料で、コンピューターの周りに持ち運びできます。 このシステムについての不満がない場合、それを変更する必要がありますか？ ユーザーが本当に不満を言うことは他にもたくさんあります...

@Ranollerは、いつでもプラグインをゲームフォルダにコピーできます。
とにかく、その場合、project.godotはプラグインを依存関係としてリストし、正しいバージョンで新しいコンピューターにダウンロードされます。

ダウンロードしましたか？ 私のプラグインはペンドライブ内のプロジェクト内にあり、gitリポジトリの一部です...提案がわかりません...プラグインは他のコードと同じように変更されます...ゲームコードのプラグインからより多くのコードを変更します、プラグインにバージョンごとに番号を付けてプロジェクト外で作業したくない...1行のコードを変更するたびに、すべてのコンピューターのすべてのプラグインを手動で変更する必要がありますか？...本当にプラグインはプロジェクトの一部のように感じます。 .gitリポジトリからプラグインを提供することは私には意味がありませんが、私はそれについて何かを理解していないと本当に思います...

@Ranollerのアイデアは、変更する必要のないプラグインをプロジェクトの外に移動することです。 たとえば、 InterpolatedCameraは、コードを変更するのではなく、そのまま使用するノードになります。

TODOリストやgit統合などのエディターのみのプラグインの場合も同じです。これらは使用したいものですが、変更はしません。

これはパッケージマネージャーによく似ており、ライブラリはCやC++以外のすべての言語で機能します。 すべての依存関係を指定するファイルがあり、パッケージマネージャーはそれらの依存関係をフェッチします。 これは、PCを変更した場合でも発生します。パッケージマネージャーは、まだ存在しないパッケージをダウンロードします。

何かを変更したい場合は、コードをプロジェクトに取り込みます。 次に、それはあなたのgitとそのすべてのソースコードなどを含むプロジェクトにあります。しかし、常にそうであるとは限りません。

私の提案は、実際に何かを変更する必要があるまで、デフォルトでプロジェクト外のものを使用することです。

現在、多くのアセットはほとんどの場合、変更する必要のあるテンプレートです。このようなシステムを導入すると、ソースの変更ではなくAPIを介したより汎用的なものになる可能性があります。

@karroffelしかし、言語間の継承は各言語でどのように機能するのでしょうか。 エンジンと緊密に結合されているGDScriptの場合は簡単かもしれませんが、C＃などの汎用言語やGDNativeに追加された他の言語の場合はまったく別の話です。
私はこれがどのように達成されるのかを真剣に理解することはできません。

IMOプロジェクトが依存するアドオンのコンテンツを変更することはお勧めできません。 変更が必要な場合は、アドオンフォルダーの外にコンテンツをコピーして、そこで変更を加えます。

編集：またはアドオンを「フォーク」します😜

@neikeq変更するのはプロジェクト内です。 アドオンを変更する場合は、プロジェクト内にコピーされ、ローカルでのみ変更されます。

@karroffel混乱を避けるために、プロジェクトプラグインとエディタープラグインのアイデアが必要になる場合があります。2つを明確に分離します。

@QbieShay変更したファイルを変更する更新がある場合はどうなりますか？

@neikeqスクリプトの継承は、この問題の解決策ではなく、1つにすぎません。 現在、別のプログラミング言語を使用する場合に、スクリプトを添付してノードの機能をオーバーライドする良い方法はありません。

Script APIのメソッドをオーバーライドするオプションがあれば、それも良いでしょう！ （基本的に、新しいメソッドを外部で定義し、既存のメソッドをオーバーライドします）。

@PLyczkowskiも役立つ提案ですが、私が提案するのはそれに限定されません-そして理由があります。

InterpolatedCameraの例をもう一度見てみましょう。 私はそれのソースコードに触れることは決してありません、私はそれを使うだけです。 私のプロジェクトにソースがあると無駄になります。 また、私が作成するほとんどのプロジェクトはすべて3Dであるため、おそらくそのコードをすべてのプロジェクトにコピーすることになります。

一方、git統合は、gitフックで表現するのが難しいカスタム動作を追加するのに非常に便利な場合があるため、そこでカスタマイズすることが望まれます。

プロジェクトの内部に何かがあるべきとき、そして外部にあるとき、編集者であるかどうかにかかわらず、白黒の線はありません。

@neikeq

変更したファイルを変更する更新がある場合はどうなりますか？

その場合、バージョン情報が失われるため、簡単に更新できなくなります。 その場合は、gitなどのツールを使用する必要があります。

アイデアは

• プロジェクト外：更新が簡単で、プロジェクト間のクロスプロジェクトが簡単
• プロジェクト内：カスタマイズ可能、アセットステータスの喪失、自動更新なし

基本的に、プロジェクトにコピーすると、通常のファイルになります。

これを読むと、肥大化を回避し、ゲームのファイルサイズを最小化することは有効なことであると言えます。 ただし、ここにいくつかのアイデアを入れさせてください。

• Godotは、使用しないノード（つまり、多くの3Dゲームを備えたほとんどの2Dノードと多くの2Dゲームを備えたほとんどの3Dノード）によって使用されるコードのゲームを取り除くシステムを使用できます。 これにより、ゲームファイルのサイズを抑えるために新しいノードタイプを受け入れないというプレッシャーが軽減されます。 たとえば、Unityユーザーはすでに素晴らしい結果に似たものを使用しています。
• Godotには、Godotサイトのプラグインページに接続するアセットブラウザが組み込まれている可能性があります。 必要なカスタムノードを選択すると、正しい場所に自動的にインストールされます。 使用されていないプラグインは、ゲームのパッケージ化時に削除されます。
• おそらく、人気のあるカスタムノードをGodotビルドにバンドルすることもできます（Blenderがアドオンで行うように）。 カスタムノードは、通常はより高いレベルであり、ある程度、より一般的なノードよりもブラックボックスである可能性があるため、マークを付ける必要があります。

とにかく私の2セント。

@エース-ドラゴン

1. あなたの最初のポイントは、エンジン全体の機能として持っていると本当にクールだと思います。 エクスポートされたゲームでノードが使用されていない場合、またはプロジェクトで使用しているノードのいずれかでノードが使用されていない場合、最終的なバイナリからノードを自動的に除外できれば便利です。 それ以外では、現在、スイッチに依存してエンジンを再コンパイルする必要があります。 ：-/

2. これは基本的にアセットライブラリがすでに持っているものです。 問題は、依存関係の概念がなく、プロジェクトディレクトリに直接ドロップし、作成するすべてのプロジェクトに対してシステム全体で特定のプラグインのセットを維持する手段がないことです。

3. カスタムノードは常に明示的にマークされているため、心配する必要はありません（スクリプトを使用してカスタムノードを作成し、拡張するため、ノードの横にスクリプトアイコンがあります）。 これらはスクリプトであるため、エンジンに同梱されることはありません。 それらはある種のプラグインの一部になるので、どちらかといえば、ものを収集するための「ノード拡張」リポジトリである私のgodot-nextリポジトリのようなものがあるかもしれません。 それは何よりも「公式な」能力になるでしょう（そのレポは多くの仕事を使うこともできます、笑）。

OK、ゆっくりですがキャッチされました...プロジェクト内でアドオンを維持すれば、現在のプロジェクトとのgit統合を失うことなく、また移植性を失うことなく、別のスクリプトのようにプラグインコードで作業できます...他の開発者向けのツールまたはすべてのプロジェクト向けの一般的なツールのプラグインは、ツールの外部gitリポジトリで実現し、アセットライブラリを使用して他の人に変更できる外部パッケージの形式で共有します...他の開発者がツールを使用していて、個人バージョンが必要な場合は、プロジェクト内に保存する必要があります。この場合、プラグインは実際には機能しません（自分の作業を失うことはありません）。 ）...そうですか？

@Ranollerええ、あなたは彼の提案の要点を理解していると思います。

あなたたちが話していることについてのいくつかのフィードバック

1）これが解決する必要のある実際の問題である場合、言語間の継承（狂気）よりも、ノードごとに複数のスクリプト（数行のコード）をサポートする方がはるかに好きです。 これはまだ解決が必要な問題ではないと思います。

2）パッケージマネージャーとシステム全体にアドオンをインストールするというアイデアは好きではありません。 それはひどい考えであり、これからは何の意味も得られないと思います。 Unity開発者が大規模なプロジェクトでアセットのバージョンを更新し、すべてが壊れて何日もかけて修正するのを見ると、トラウマがどれほどあるかを見てきました。

3）パッケージ管理自体のアイデアが好きではありません。 Unityユーザーがアセットストアから得たものをハッキングして、ほとんどの場合終わりがないのを見てきました。 あまりにも多くの場合、彼らはそれをベースとして使用し、それを処理して自分の用途に合わせてカスタマイズします。なぜなら、取得するアセットは、希望する場所の60/70％しかないためです。または、単に見たかっただけです。それがどのように行われるか、そして後で彼ら自身のことをする。

議論されている提案から実際には何も得られないと思うので、この議論に自分で多くを追加する予定はありません。

人々が3Dのものなしで簡単な方法でエクスポートできるようにすると、エンジンのサイズをどれだけ減らすことができますか？ 多くのゲーム（半分？半分以上？）は3D機能を必要としませんが、それでも同じバイナリでそこにあります。 理論的には、少しの投資で、すべてのプラットフォームでマクロを使用して自分で再コンパイルできることを知っています...
また、このアイデアに従って、モジュールが公式エンジンのディストリビューションの一部である単なる「内部」ダイナミックライブラリである場合、エンジンに機能を追加しても、オプトアウトが非常に簡単であるという意味で問題は少なくなります（ ）ただし、このようなダイナミックライブラリを使用すると、一部のプラットフォーム（主にモバイルとHTML5）で少し制約が生じる可能性があります。 したがって、モジュールの場合、GDNativeが優先されることを理解します（まあ...同じ問題があります^^）。

@reduz複数のスクリプトはどのように機能しますか？ そして、それはエンジンの拡張にどのように貢献しますか？ 既存の問題であなたの考えを説明しましたか？ （このスレッドで説明するには多すぎるので質問します）

アセットのシステム全体のインストールで適切な依存関係管理を追加します。 アドオンをプロジェクト自体から移動して、変更のために元に戻す方法を使用します

いいえ。堅牢性のために、プロジェクトディレクトリにそれらを配置してください。 しかし、おそらくパッケージマネージャーを使用して手動で選択したものを更新する方法や、システム全体のキャッシュを使用して更新する方法があります。

肥大化の懸念については、代わりに_modules_をより細かく制御していただければ幸いです。これは、2018年1月のPatreon世論調査ですでに投票されています。

ロードマップの優先順位：エンジンの一部のコンパイルをオプトアウトして、より小さなバイナリサイズを作成するためのより多くのオプション[3.1で期待]

この提案はさまざまなことに触れており、人々はさまざまな側面についてコメントし、さまざまな問題を提起しているため、コメントするのは難しいです。

全体として、「依存関係マネージャー」の提案は紙面では良いように思えますが、この実装では、プロジェクトフォルダー内のアドオンをベンダー化するだけでは得られないメリットは得られないと思います。 「インストールが簡単」という1つのケースを解決するには、依存関係管理のための複雑なメカニズムを組み込む必要があります。 このプロジェクトには、貢献者の小さなチームですでに3000以上の問題があります。 私の意見では、依存関係の管理と同じくらい複雑なものを導入することは足がかりです。

コアはミニマリストでなければならないという@reduzに同意します。 私の意見では、「コア」として分類できないものはすべて、独立して組み込む必要があります。 ユーザーとして、私はGodotがマルチプラットフォームゲーム_engine_になることを期待しています。 godot _gameフレームワーク_（車両、補間カメラ、地形、プレーヤーコントローラーなど）が必要な場合は、コアに依存しないファーストクラスのアドオン（またはモジュール？）として利用できるはずです。 アドオンストーリーを改善することはこれに役立つと思いますが、完全な依存関係マネージャーと自動化されたアドオンマネージャーは、純利益を低くするためにそれを推進しているようです。

私の最後のコメントは、「初心者」へのケータリングと「パワー」ユーザーの見捨てに注意することです。 Godotは、その強力な機能（モジュール、gdnative、gdscript、エディターなど）と柔軟性により、より高度なユーザーの注目を集めています。 godotをテストし、その限界を押し広げ、そのAPIを探索し、プロジェクトに貢献することが多いのは、この種のユーザーです。 これらは、ファイルシステム内のディレクトリへのシンボリックリンクを作成して、複数のプロジェクトでアドオンを再利用できる同じユーザーです。

コアから上位レベルのノードを削除するというアイデアの場合、それらのノードはすぐに利用でき、ダウンロードのために簡単に見つけることができるはずです。 理想的には、それらを「公式」として維持できるため、（エンジン内ノードと同じように）可視性が向上します。 そうすれば、公式アセットをデモやチュートリアルで問題なく使用できます。

それらをアウトソーシングすることの利点は、新しいエンジンバージョンを待たずに改善およびリリースできることです。 したがって、拡張機能の場合、新しいリリースをパックする方が非常に簡単なので、バグはすぐに修正できます。

最終的には、パッケージ管理はほとんどの場合非常に面倒だと思います。 プロジェクトに追加したカスタムノードの新しいバージョンの場合でも、それを更新すると、他の多くの問題が発生する可能性があります（semverでも、現在修正されているバグを回避した可能性があるため）。

一部のエディタープラグインのOTOHは、プロジェクトから除外して頻繁に更新することが理にかなっている場合があります。 私のTiledインポータープラグインはその一例です。 ほとんどの場合、ゲームに同梱されることを望まず、より多くの機能をサポートし、バグ修正が行われた最新バージョンが必要です。

これは、gitマネージャーやタイムトラッカーなどの他のエディター拡張機能にも当てはまります。 チームメイトがタイムトラッカープラグインを持っているかどうかさえ気にしないかもしれません。それはプロジェクトとは関係ありません。 ただし、 addonsフォルダーに入れてプロジェクト設定で有効にする必要があります。その後、ゲームの残りの部分でコミットしないように注意してください。 これらはおそらくプラグインの少数派ですが、プロジェクトに関連付けられていないシステム全体のプラグインを使用している場合は、実際のユースケースがあります。

中間点は、Godotに統合するのではなく、外部ツールとしてパッケージマネージャーを作成することだと思います。 公式である必要はありません（「承認」される可能性はありますが）。 これをサポートするためにベースエンジンにいくつかの変更が必要な場合（グローバルプラグインの使用など）、特にエディターのみの場合は、追加してもそれほど問題にはなりません。

そうすれば、それが有益だと思う人はそれを使うことができます。 それが普及し、誰もがそれを使用している場合、それをベースエンジンに完全に統合するかどうか、そしてどのように統合するかを決定するために、使用統計とユーザビリティに関するフィードバックの両方があります。

さて、私にとってのクロススクリプト継承はノーノーです（それが可能であれば）。 マルチスクリプトはちょっと奇妙ですが、クロススクリプトの継承をよりクリーンな方法で効果的に置き換えることができます。 それはいくつかの懸念を引き起こしますが、例えば：同じオブジェクト内の別のスクリプトの関数を呼び出す方法は？ それは別の議論だと思います。

OTOHという名前でスクリプトを参照するのは本当にいいですね。 理想的には、すべてのリソースを名前で参照できるため、物事を移動することにした場合でも、パスを解決するのに問題はありません。

@vnen私がまだ目にしている唯一の問題は、アドオンとプロジェクトの間の非互換性です。 その問題にどのように対処しますか？
Godotによって維持されている公式の拡張ライブラリがある場合、すべてのノードがすべての可能な言語で出荷されるか、言語間の継承が使いやすさを維持できる唯一の方法であると考えているためです。

@vnenすべてのアセットを名前で参照すると、競合する混乱になります。 プログラマーだけがクラス（またはまれにリソース）を入力して使用するためにクラスの一意の名前を考え出す必要があるため、これはスクリプトに適しています。 他のものについては、パスを削除する場合、アーティスト、デザイナーなどもすべてのアセットに一意の名前を付ける必要がない限り、このhttps://github.com/godotengine/godot/issues/15673が必要になります（まだ名前の変更の問題があります）。

@Zylann @vnen私が書いているTypeDBを使用すると、理論的には、任意のアセットの名前をオプションで登録できるようになります。 現在、スクリプトにのみ使用しており、カスタムタイプのシーンにも使用する予定ですが、リソースを操作するように変更することもできます。 現在、ロジックにはスクリプトとシーン用にそれぞれHashMapがありますが、ロジックを一般化して、すべて分類されたHashMapであらゆる種類のアセットを処理できるかもしれません。

私はreduzのシステム全体の懸念を尊重することができ、それらは確かにエンジンの提供を変更するプラグインの懸念ですが、特にvnenが説明しているように、エディターの機能に関しては、比較的安全な方法。 人々が編集者にもっと多くの機能を与えるためにプラグインを追加しているなら、それらは彼らが通常ひび割れて自分自身を修正するものではありません。 彼らはそれをそのまま使用するか、変更を加える場合は、おそらくツールを改善するためにそれらの変更をPRするためになります。 結局のところ、あなたはそれらをゲームに適応させていません。 そのため、このようなプラグインの場合は、新しいプロジェクトを開始するときに、これらの機能をエンジンに簡単に付与する手段が必要だと思います（どういうわけか）。

依存関係マネージャーを必要とせずに物事を簡単にすることができる1つの可能な方法は、プラグイン間で依存関係を共有せず、代わりにプロジェクト内でそれらを複製することです。そうすれば、バージョン管理は問題になりません。 個々のプロジェクトが大きくなる可能性がありますが、ゲームに関連するコンテンツの場合、reduzが言うように、とにかく人々がそれをいじくり回すのであれば、依存関係を移動するだけです。 その場合に必要なのは、プラグインが外部プラグインの依存関係を宣言し、ユーザーがその依存プラグインを探す場所をカスタマイズするオプションを提供する方法です。 そうすれば、プラグインを移動することを選択し、他のプラグインに同じ場所でプラグインを検索させる場合、それをカスタマイズできます。 しかし、デフォルトでは、すべてが独自の依存関係を管理することにより、箱から出してすぐに機能します。 このケースは、plugins-as-sub-projects提案（＃19178）全体で処理するのもおそらく簡単でしょう。

これにより、依存関係マネージャーをまったく必要としないグローバルな依存関係を持つことができなくなります（reduzの問題番号3）。 また、ユーザーがアセットライブラリからお気に入りのアセットのリストを作成して、新しいプロジェクトが作成されたときにプロジェクトに自動的にインストールできるようにする機能と組み合わせることができます（したがって、すべてがローカルに保存されますが、自動的に行われます）また、手動で外出して、好みのプラグインをすべて見つけ、手動でダウンロードしてインストールする必要はありません）。 これにより、新しいプロジェクトを作成するときに同じアセットでエンジンを簡単に拡張することに関して@karroffelが対処したいユーザビリティの問題が修正されます。

複製する必要のない、よりエディター固有のプラグインの場合、おそらく人々はそれらの「お気に入り」プラグインにフラグを立てるだけで、シンボリックリンクが自動的に作成され、プラグインをある種のユーザーフォルダーに保存できます。 したがって、「すべてのプロジェクトでこれが必要です。共有場所に保存してシンボリックリンクを作成します」と「すべてのプロジェクトでこれが必要です。複製します」の「編集者のお気に入り」と「プロジェクトのお気に入り」をそれぞれ用意します。

これをTypeDBのものと組み合わせて、スクリプトの命名/カスタムタイプのカスタマイズを行います。これにより、言語間のスクリプト継承/マルチスクリプトの問題を除いて、前述のすべての問題に適切に対処できると思います。

したがって、「すべてのプロジェクトでこれが必要です。共有場所に保存してシンボリックリンクを作成します」と「すべてのプロジェクトでこれが必要です。複製します」の「編集者のお気に入り」と「プロジェクトのお気に入り」をそれぞれ用意します。

たぶん、プラグインの「バンドル」を持っている方が便利かもしれません-ユーザーが作成した公式に承認された+ユーザーが作成したローカル。 つまり、「編集者のお気に入り」と「プロジェクトのお気に入り」の代わりに、「ファーストパーソンシューティング」、「ボクセルブロックゲーム」、または単に「私のもの」があります。 たとえばUnityスターターアセットとほとんど同じですが、テクスチャなどで膨らませる必要はありません。さまざまな種類のGodotマスコットフェイスで十分です：D

これはパッケージマネージャーとしても機能します。パッケージマネージャーは現在、人間が管理するプラグインバンドルです。

@ starry-abyss現在人々が作成しているプラ​​グインは、他のプラグインの「バンドル」である可能性があります（ユーザーまたはプラグイン開発者は、プラグインを自分で移動してマージすることができます）。 ここでの目標は、エディターがユーザーに代わって実際にユーザビリティを向上させる操作を実行するカテゴリー間で機能を区別し、ユーザーが手動で操作する必要がないようにすることです。

この点で、私たちはすでに「人間がプラグインバンドルをキュレートする」機能を持っています。 問題は、すべてのユースケースで効率的な生産性でカスタマイズ可能に保ちながら、面倒なタスクを自動化することです。

@Zylann

すべてのアセットを名前で参照すると、競合する混乱になります。 プログラマーだけがクラス（またはまれにリソース）を入力して使用するためにクラスの一意の名前を考え出す必要があるため、これはスクリプトに適しています。

名前空間を適切に設定することは非常に重要ですか？ しかし、それはUIDである可能性があり、パスに依存しない限り、私にとってはそれほど重要ではありません。 リソースはインポートされた対応するものに再マップされるため、パスでさえ名前のようです...

@QbieShay

私がまだ目にしている唯一の問題は、アドオンとプロジェクトの間の非互換性です。 その問題にどのように対処しますか？

これが本当に問題である場合は、マルチスクリプトが最も簡単な解決策である可能性があります。 主に＃8546での議論で削除されましたが、苦労せずに解決できると思います。

同じことをする複数のプラグインの問題は仮想的だと思います。 すでにassetlibにスターシステムがあります。このシステムはまさにこれであり、一般的に使用され、好まれているものの指標です。

それが見落とされていることですが、私の意見では、人々がコアエンジンへの追加を求めている理由の1つはこれです：誰がすべてのプラットフォーム用にこれをコンパイルするのですか？

もちろん、gdscriptプラグインの場合、これは問題ではありませんが、Cppプラグインの場合、これは大きな問題です。

この問題を解決しないと、コアエンジン内に何が含まれるかについての議論が変わり、どのプラグインが公式としてマークされ、プラグインを公式としてマークすることでスターシステムが台無しになり、人々がプラグインにスターを付けるだけで、それは公式のものになります。

ですから、私の意見では、最初にこの問題を解決する必要があり、その方法がわかりません。 たとえば、Linuxを介してすべてのプラットフォーム用にコンパイルすることは可能ですか？ その場合は、Ubuntu Imager： https ://www.maketecheasier.com/create-linux-distro/のようなものを使用して、プラグインメーカーとGDNativeユーザー向けにセットアップ済みのLinux環境を作成できます。

たとえば、Linuxを介してすべてのプラットフォーム用にコンパイルすることは可能ですか？ その場合は、Ubuntu Imager： https ://www.maketecheasier.com/create-linux-distro/のようなものを使用して、プラグインメーカーとGDNativeユーザー向けにセットアップ済みのLinux環境を作成できます。

いいえ（macOSおよびiOSビルドは実際にはmacOSからのみコンパイルできます）。GDNativeライブラリをアセットライブラリにアップロードできるようにするために、ライブLinuxOSを起動するように強制することは良い考えではないと思います。

ただし、Travis CIとAppVeyorを使用してすべてのプラットフォーム用にコンパイルすることは可能です。これらは、パブリックGitHubリポジトリで無料でセットアップできます。

この問題を解決しないと、コアエンジン内に何が含まれるかについての議論が変わり、どのプラグインが公式としてマークされ、プラグインを公式としてマークすることでスターシステムが台無しになり、人々がプラグインにスターを付けるだけで、それは公式のものになります。

まあ、星系は実装されていないので、何も評価できません。 公式プラグインの場合、プラグインを選択して公式としてマークするのではなく、プラグインを作成および保守するのは私たちです。

基本的なもののための組み込みノードは、エディターの最も優れたものの1つです。重要なノードまたはリソースが削除される場合、プロジェクトマネージャーは共通ノードを自動的にダウンロードするためのテンプレートを必要とします。

この提案には、エンジンを別の「常にオンライン」および「ジャンクストア」エンジンでオンにするリスクもあります。実行された場合、他の多くのことが公式サポート（バグ修正）および可用性（バージョン更新）を取得する必要があります。

また、ストアはオフラインで使用するための公式バンドルを提供する必要があります（エディターでのオフラインストアのサポート付き）。

完了した場合、他の多くのことが公式サポート（バグ修正）と可用性（バージョン更新）を取得する必要があります。

TBH、エンジンや店内で物事を維持することはほとんど同じです。 たとえば、車両ノードはほとんど誰も使用していないため、バグレポートはほとんどなく、報告されたバグでさえ修正されませんでした。 これらの種類のノードをアウトソーシングする方がはるかに優れていると思います。エンジンソースをいじることなく、人々が問題を修正しようとするのが簡単であり、より多くの潜在的な貢献者がいるからです。

エンジンノードに問題がある場合、人々はバグレポートを開きます。 ただし、GDScriptコードを使用するプラグインの場合、コードを変更してテストするのは非常に簡単であり、修正がコミュニティに戻ってくる可能性があります。 私はこれを本当に利益と見ています。 ただし、これらの外部ノードを簡単に統合できる場合に限ります。これは現在のところそうではありません。 これには、優れた可視性と統合されたドキュメントが含まれます。

また、ストアはオフラインで使用するための公式バンドルを提供する必要があります（エディターでのオフラインストアのサポート付き）。

はい。オフラインパッケージも簡単にインストールできるはずです。

@reduz

パッケージマネージャーとシステム全体にアドオンをインストールするというアイデアは好きではありません。 それはひどい考えであり、これからは何の意味も得られないと思います。 Unity開発者が大規模なプロジェクトでアセットのバージョンを更新し、すべてが壊れて何日もかけて修正するのを見ると、トラウマがどれほどあるかを見てきました。

わかりましたが、なぜですか？ あなたがそれから見る実際の制限と問題は何ですか？ なぜそれが良い考えではないことを人々に納得させないのかを言わずに「私はそれが好きではない」と言う。 言及された漠然とした理由以外に、少なくともいくつかの説明をする必要があります。

わかりましたが、なぜですか？ あなたがそれから見る実際の制限と問題は何ですか？ なぜそれが良い考えではないことを人々に納得させないのかを言わずに「私はそれが好きではない」と言う。 言及された漠然とした理由以外に、少なくともいくつかの説明をする必要があります。

システムにグローバルな「アドオン」レジストリがあると仮定します。

• オンラインアドオンシステムからアドオンv1.3をダウンロードします。 アドオンは~/.godotまたはそれ以外にインストールされます
• バージョンは、ある種のローカルストア（ファイル、sqliteなど）の~/my-projectで私のプロジェクトに関連付けられます
• v1.4にアップグレードします。 これで、アドオンマネージャーは、1.3がどのプロジェクトでも使用されていないことを認識し、クリーンアップする必要があります。 そのため、マネージャーには、依存関係と、どのプロジェクトにどの依存関係があるかを追跡するための追加機能があります。 あるいは、誰もこの機能を追加しないので、私のローカルマシンは同じアドオンの複数のバージョンで汚染されます
• プロジェクトを~/big-project/gameに移動することにしました。 次に、アドオンレジストリ内のプロジェクトへの参照を更新する方法が必要です。 それ、どうやったら出来るの？ アドオンマネージャーを個別に実行する必要がありますか？ Manager register new_proj_location ？
• requirements.txt pythonスタイルで依存関係をローカルに保存することが決定されました。 素晴らしい、問題は解決しました。 どのプロジェクトがどのグローバルパッケージに依存しているかわからないことに戻った場合を除いて、バージョンが積み重ならないように、システムでgodotプロジェクトをスキャンするか、各プロジェクトを登録する必要があります。
• いいでしょう、私は問題を回避するだけです。 デッドパッケージを時々手動でクリーンアップします。 そのため、v1.5を使用してプロジェクトのVehicleBodyAddonに取り組んでいます。 うーん、加速計算ではF * Mを実行しますが、F * M *5を実行したいと思います。コードをすばやく変更しましょう...おっと、そのアドオンを実行している他のすべてのプロジェクトがあります。
• 他のアドオンに依存する新しいアドオンを作成しましょう。 うーん、新しいカスタムアドオンが既存のアドオンに依存していることを登録する必要があります。 次に、マネージャーを拡張して、リモートの場所からアドオンをダウンロードするだけでなく、ローカルパスやgitリポジトリなどを操作する必要があります。

「ベンダー」アドオンを想定：

• アドオンをアドオンディレクトリにダウンロードする
• ディレクトリ内のオーバーライドアドオンを更新しています

そのため、マネージャーには、依存関係と、どのプロジェクトにどの依存関係があるかを追跡するための追加機能があります。 あるいは、誰もこの機能を追加しないので、私のローカルマシンは同じアドオンの複数のバージョンで汚染されます

これは他のrubyのgemコマンドが行うこととまったく同じであり、他のgemに依存しない古いバージョンのgem（rubyのアドオンの用語）をクリーンアップするコマンドがあるため、誰も文句を言いません。 さらに、更新する場合、新しいバージョンはおそらくほとんど互換性があるのに、なぜ古いバージョンを保持する必要があるのですか？ プログラムが完全に古いバージョンに依存している場合、ユーザーは古いバージョンを再び取得できますが、ほとんどの場合、そうではありません。

プロジェクトを~/big-project/gameに移動することにしました。 次に、アドオンレジストリ内のプロジェクトへの参照を更新する方法が必要です。

あなたは本当にしません。 アドオンマネージャがプロジェクトマネージャのプロジェクトリストを使用して、存在しないパスを無視できる場合は、これについて深く考えすぎています。 もちろん、それはプロジェクトとその要件を絶対に追跡する必要がある場合にのみです。これは、文字通り他のすべてのアドオンのように、ダウンロードしたアドオンの最新バージョンを保持できる場合には必要ないと思います。

requirements.txt pythonスタイルで依存関係をローカルに保存することが決定されました。 素晴らしい、問題は解決しました。 どのプロジェクトがどのグローバルパッケージに依存しているかわからないことに戻った場合を除いて、バージョンが積み重ならないように、システムでgodotプロジェクトをスキャンするか、各プロジェクトを登録する必要があります。

Pythonスタイルのrequirements.txtは、この種のアドオンシステムに最適なオプションです。 そうすれば、プロジェクトで本当に古いバージョンが本当に必要な場合（ただし、とにかく最新バージョンが必要になることがよくあります）、それを指定できます。アドオンマネージャーがその古いバージョンを削除してしまった場合は、それを知ることができます。後で再ダウンロードします。

そのため、v1.5を使用してプロジェクトのVehicleBodyAddonに取り組んでいます。 うーん、加速計算ではF * Mを実行しますが、F * M *5を実行したいと思います。コードをすばやく変更しましょう...おっと、そのアドオンを実行している他のすべてのプロジェクトがあります。

または、そのプロジェクトにローカルなアドオンのコピーを使用しますか？ 1つのプロジェクトにのみ適用される変更が本当に必要であり、プロジェクトに対してローカルにコピーを作成したくない場合は、それを拡張して変更を加える.gdファイルを作成してから、アドオンからのファイルの代わりにその新しいGDファイル。

他のアドオンに依存する新しいアドオンを作成しましょう。 うーん、新しいカスタムアドオンが既存のアドオンに依存していることを登録する必要があります。 次に、マネージャーを拡張して、リモートの場所からアドオンをダウンロードするだけでなく、ローカルパスやgitリポジトリなどを操作する必要があります。

Gitサブモジュール。 別のrequirements.txt（pythonのように）。 または、アドオンXが必要であることをユーザーに伝えます。それは、あなたが考えているほど難しくはありません。 Godotのユーザーのほとんどは愚かではありません。 彼らは、「このアドオンに必要なもの：アドオンXコア、アドオンY、アドオンZ」の意味を知っています。

@rminderhoud必要に応じて、プロジェクトのアドオンのコピーを各プロジェクトに保存することをお勧めする場合（したがって、必要なバージョンのみがあり、問題を発生させることなく自由に変更できます）、おそらく私の以前の提案でコアを処理できますこの問題を取り巻く問題？ つまり、EditorSettings内にユーティリティを作成して、ユーザーが新しいプロジェクトを作成するときに自動的にインストールするアドオンを指定できるようにします。

特定の場所を保存するために、ユーザーがuser：//の場所へのハードリンクを形成できるようにする同様のユーティリティを作成することもできます（特にエディター機能を追加するアドオンの場合）。 ユーザーが無責任にそれを行うことを選択し、プロジェクトを台無しにする場合、それは彼ら自身の決定になります。 プロジェクトの作成中にすべてのアセットをコピーするデフォルトの方法は非常に便利です。

新しいプラグインシステムを追加することは、現在のようにres：// addonsに関して互換性がないはずです...そしてこれは次の理由によるものです：

実際のシステムは素晴らしいです...

繰り返します：

実際のシステムは素晴らしいです...

以前はその点について不平を言っていません。

私はこの議論に遅れています、ここに提案についてのいくつかの考えがあります：

• 個人的にはまだ多くの「アセット」を使用しておらず、アドオンフォルダをそのまま使用するのは簡単だと感じています。
• クロスランゲージスクリプトの継承によって何が行われ、どのような問題が解決されるかは理解しています（C＃開発者がGDScriptスクリプトから拡張してC＃を使用してカスタム機能を追加できるようにする）（使用したいというわけではありません）が、よくわかりませんノードごとに複数のスクリプトが実行すること。 ああ、GDScriptスクリプトから拡張されたC＃スクリプトの代わりに、それを呼び出すことができますか？ どのスクリプトがメインのスクリプトになりますか？ C＃コードはGDScriptスクリプトの機能をどのように変更しますか？
• スクリプトをクラス名/名前空間（TypeDB）で参照できるようにすると便利な場合があります。 私はres：// pathsで問題ありませんが、アドオン内の何かから継承すると、非常に長いパス名になるのは事実です。 大きな問題ではありませんが、言語間の継承にはおそらく必要です（または推奨されます）。

私が提案する資産管理のより単純な設計は次のとおりです。

• 依存関係.json（またはデータをプロジェクト設定に保存する）があると便利です。ダウンロードしたアセットのバージョンと、更新されたバージョンがあるかどうかがわかります。 それは必要な情報だと思います。
• いいえ、アセットに依存関係を定義させないでください。 Godotアセットは、npmモジュールのように相互に大きく依存することはないと思います。 アセットが本当に別のアセットに依存している場合は、アセット開発者にドキュメントに記載させ、ユーザーが手動でインストールできるようにします。 これにより物事が単純化され、コードの膨張/維持するコードの追加という別の依存関係検証を作成する必要がなくなります。
• いいえ、アセットを「グローバル」な場所に保存しないでください。 それらをプロジェクトアドオンフォルダに保持することはすでに良いことです。 これにより、プロジェクトでソース管理を行うことができ、管理が容易になります。 npm node_modulesでさえ、プロジェクトのモジュールをプロジェクト内に保存します。
• 次に、アセットブラウザを改善して、インストールされているアセットのどれが更新されたかを一覧表示し、必要に応じてそれらを更新できるようにします。
• さて、単なるエディターの改善であるこれらのアドオンに対して「グローバル」アドオンを使用できることは理にかなっています。 そのため、通常のアドオンは引き続きプロジェクトアドオンフォルダーに移動しますが、エディター関連のアドオンの場合は、グローバルにインストールするオプションがあります。 これにより、そのコードがプロジェクトのアドオンフォルダーの外に移動するため、リリースパッケージには含まれません。 （これは、開発ツールのnpm install -gに似ています）

したがって、更新されたアセットを追跡し、エディターアドオンをグローバルにインストールできるようにするためのいくつかの改善があります。

依存関係を処理しないとすると、ユーザーの発見可能性や使いやすさの問題があるのではないかと思います。 新しいユーザーが、依存関係のあるプラグインまたは「アセットパッケージ」を試したいとします。 パッケージはアセットライブラリに表示され、ダウンロードされますが、「内部スクリプトの読み込みに失敗しました」などの理由で機能しません。 それは不可解です。

• 少なくとも1つの依存関係を持つことをあえてするすべての開発者は、依存関係をインストールする必要があることをユーザーに示すためにボイラープレートコードを設定する必要があります（パッケージがそのプラグインの単なるデモであっても）。
• または、assetlibは少なくともそれを示していますか？

また、アセットを簡単に更新するために+1します。ライブラリで、アセットを再度参照する必要はありません。

確かに、ユーザーはそれが機能しないことを確認すると、すぐにドキュメントを調べて、他のアセットをインストールする必要があることを確認します。

この時点では、それは想像上の問題にすぎません。 そして、私が見たプロジェクトメンテナの考え方では、それが本当に問題であることがわかるまで、それを実装しないことは理にかなっています。 つまり。 他のアセットに依存しているアセットがたくさんあり、ユーザーはそれに多くの問題を抱えています。

ただし、適切に設計されたソリューションとして、他の資産に基づいて構築された資産のエコシステムの開発を促進する可能性があることに同意します。

更新によるアセット間の最上位の依存関係（サードパーティのアセット依存エンジンでは一般的）に加えて、同じプラグインの多くのバージョンをライブラリに保持する必要があります。

@ eon-sでは、@ bojidar-bgの提案のようなものですか？

ここで説明するより重要な問題は、コアエンジンに含めることと、拡張機能または公式の拡張機能として使用することのトピックに関するものだと思います。

私は個人的に、エンジンをカスタマイズして、実際に使用していないものをすべて削除できるというアイデアが本当に好きです。 [たとえば、3Dのものをすべて削除する方法を誰かに教えてもらえますか？ また、使用しないモジュールのコンパイルを無効にすることはできますか？ どのように？]

問題は、誰かが新しいノードタイプを提案したときです。 言及されたスプリングアームまたは新しいクラス。 より優れたRNGクラス、または既存のコアノードを削除する場合。 Vehicleコントローラー...これらはC++コードです。 それらがコアに含まれていない場合、それらはどのように拡張機能として追加されますか？ GDNativeアセット？ それは、管理/構築するための多くのdllと共有ライブラリになります。

私自身のgodotビルドをビルドする人として、私は実際にそれらを自分のgodotビルドフォルダーにインストールする方法を持ちたいと思っています。 たとえば、それらがモジュールの場合、モジュールフォルダーにgitクローンを作成するか、それを何らかの方法で自動化するツールがあるかもしれません。 公式モジュール、公式拡張モジュールのリスト、およびユーザーが送信したモジュールから、使用するすべてのモジュールを選択できます。 次に、それらをダウンロード（git clone）すると、カスタムのGodotを作成できます。 また、更新されたものを確認して更新し、後で新しいものをインストールすることもできます。 （これはC ++コードを参照しています。）

したがって、エンジンから機能を削除する前に、まず、より優れた柔軟なアセットライブラリ（アセットのインストール、依存関係、バージョン管理など）と、より簡単なプラグインの統合/拡張（エディターツール、スクリプト可能なカスタムノードなど）が必要だと思います。 。

ここで@chanonに返信します。

いいえ、アセットに依存関係を定義させないでください。 Godotアセットは、npmモジュールのように相互に大きく依存することはないと思います。

しかし、なぜですか？ その時点で、何も害を及ぼさないので、とにかくアセットにこの依存関係ファイルを持たせてみませんか？ 多くのnpmモジュールに依存関係がある理由は、すべての人の手間を省き、ユーザーがすでにインストールしている可能性のある他のモジュールのコードを再利用するためです。 同じことがRubygems、 pip経由のPythonにも当てはまり、Linuxディストリビューションのパッケージマネージャーでも許可されます。 アセットがあまり使用されない可能性があるという理由だけで、アセットへの依存を許可すべきではない理由がわかりません。

確かに、ユーザーはそれが機能しないことを確認すると、すぐにドキュメントを調べて、他のアセットをインストールする必要があることを確認します。

私はこれの感情に同意しません。 確かに、最初にドキュメントを検索する人はたくさんいるでしょうが、アセットライブラリで必要なすべてのアセットを毎回検索しなければならないことに悩まされることは間違いありません。 しかし、事前に問題をグーグルで検索したことがなく、アセットが機能していないとアセットの作成者に不平を言う人が常にいることにも言及する価値があると思います。

機能をGDScriptで実行できるという理由だけで、機能を削除するという考えにも同意しません。 簡単に言えば、大量のユーザーに必要なツールや機能などをダウンロードまたは実装するように強制する場合、Godotの「すべてのニーズに対応するノード」という目標とは正反対です。

実際、「自分で行うのは難しい」というのは完全に恣意的であるという理由だけで、大量のノードが@reduzのエンジンに含まれるという2番目の要件に該当します。 ある人にとっては単純かもしれないことは、他の人にとっては難しいことです。

拡張機能の公式リポジトリを持つことは、「すべてのニーズに対応するノード」に反するとは思いません。 それらが実行可能ダウンロードに統合されていないからといって、それらが提供されていないという意味ではありません。 また、基本的なニーズがカバーされ、それらを拡張する力がゲーム固有のニーズに利用できるという考え方です。

FPSキャラクターコントローラーをすぐに使えるのはいいことですが、FPSゲームをやっていない人には役に立ちません。 そして、そのようなものを追加することで、基本的に必要のない多くの機能を含むすべてのゲームを作成し、最終的なバイナリを増やします（これはモバイルおよびWebターゲットで非常に重要です）。 最終的なエクスポートから未使用のものを削除する方法が必要であり、必要に応じて外部に提供することは1つの方法です（少なくとも部分的に）。

難しさは主観的なものであることに同意します。 スプリングアームノードの作成は、それを実装するための基本をすでに知っている場合にのみ簡単です。 そうしないと、研究にかなりの時間を費やすことになり、フル機能のエンジンを使用する目的が失われます。 より良いメトリック（まだ多少主観的ですが）は、 「どの程度の低レベル」が機能であるかです。 物理サーバーまたはビジュアルサーバーに機能を追加する必要がある場合は、エンジンで提供する必要があります。 既存のノードの拡張のみである場合は、外部委託することができます。

コアをダウンロードしてトリミングするための公式ノードを提供することは、それでもより有益であると私は信じています。 これにより、次のことが可能になります。

• エディターとエクスポート用の小さな実行可能ファイルを用意します。
• より多くのゲーム固有のヘルパーを使用して、より多くの機能を公式に提供します。
• 新しいエンジンバージョンをリリースせずに、拡張機能のバグを更新および修正します。 これは、アウトソーシングされたノードのリリースサイクルがはるかに速く、バグが修正されるとすぐにパッチをリリースできることを意味します。

しかし、そのためには、アドオンをユーザーランドスクリプトよりも上流階級の市民にする必要があります。 拡張ノードを使用することは、コアノードを使用しているように感じるはずですが、そうではないことは明らかです。

興味深い議論。 多くの良い提案も。

最初に言わなければならないのは、最終的なバイナリのコンパクトさに感謝し、その目標を念頭に置いて作られたエンジンがあることに感謝しています。 ここでの中心的なビジョンは、膨満感と積極的に戦うことです。 少なくとも私にとっては、仕事に必要なツールだけを手元に置いておきたいと思っています。

これらの興味深いアイデアのいくつかにうなずきを伝えたかっただけです。

特に、ますます多くの機能が公式モジュールやプラグインのような形をとる何かにエクスポートされることに関するもの。

そのことから、これはコアのようなものであり、モジュールのライブラリのようなものであり、重要なものはデフォルトでインストールされていると思います。 おそらく、多くはエディター設定を通じてオプトアウトされる可能性があります。 （Zylannは、2Dゲームで3Dを除外することに言及していたと思います。）デフォルトを超えて、他のモジュールを簡単に見つけて含めることができます。

実装の難しさは気になりますが、プロジェクトに積極的に参加しているモジュールを削除したい場合にどうなるかを考えなければならないからです。 非アクティブ化する前に、それらのシーン/スクリプトから削除するようにユーザーに警告する必要がある場合があります...または、モジュールが追加されたときに復活できる、プロジェクト内の墓石のアイテムとして残りますか？

実装するのはおそらく小さなことではありませんが、可能な場合はいつでも、提供されている機能を選択して選択できるのが好きです。これにより、必要なものだけをゲームにエクスポートできます。 それをもっとコントロールすることは私にとって価値があるように思えます。

ビルトインとスクリプトの間に特別な分類を持つモジュールを持つことについてのVnenからの他の考えも、素晴らしいものでした。 これにより、既存の設計の優れた点に干渉することなく、他の種類のパーティション分割とエディターの動作およびオプションが可能になります。

アドオンをGodot自体のように見せることについては、賛成と反対の意見もありますが、状況に応じたものであると想像できます。 コンセプトを少し分けてやっていることも想像できました。 両方を提供します。

また、エディターツールを最終ビルドから除外することに関して何ができるかを知りたいと思います。 ツールを対象としたバグや動作がゲーム自体に忍び寄る可能性があるため、これらを区別するために多くの労力を費やしてきました。 保存されるデータを変更して何かをしている場合、破壊的になることがあります。

同時に、ツールスクリプトを使用してエディター内の機能を簡単に変更できることは非常に素晴らしいことだと思います。そのため、さらに注意を払うことも素晴らしいでしょう。

とにかく、みんな良い仕事を続けてください。

ちょうど別のクレイジーなアイデア：

おそらく、GDNative C ++をモジュールに自動変換することは可能でしょうか（理想的には、GDNativeによって作成された間接層を削除します）。 次に、「1つの静的実行可能ファイルのすべて」アプローチと「コンパイラをインストールせずに機能を削除する」アプローチの両方を支持する可能性があります。

ノードの削除に反対する人にとって、削除されたノードが公式プラグインとしてGDScriptに実装されている場合、現在のプラグインよりも優れているのではないでしょうか。 なぜなら、初心者は実際にスクリプト内でピークに達し、スクリプトがどのように機能するかを確認できるからです。

GDScriptはそれほど高速ではないため、パフォーマンスが低下するのではないかと心配しています。

2018年6月22日金曜日午後11時10分、Alan [email protected]
書きました：

ノードの削除に反対する人のために、削除されるノードが
GDScriptに公式プラグインとして実装されています。
私たちが現在持っているものは何ですか？ なぜなら初心者は実際に内部でピークに達する可能性があるからです
それがどのように機能するかを確認するためのスクリプト。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/19486#issuecomment-399628884 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEJES-DWkzuyItQDPbOZgsuN_lA345z7ks5t_b_NgaJpZM4UhqDC
。

@AlansCodeLogどうしても削除して外部拡張機能にする必要がある場合は、少なくともGDScriptバージョンがあれば便利です。これにより、ユーザーはエンジンを再コンパイルしたり（元のC ++ファイルの場合）、Monoをインストールしたりする必要がなくなります（元のC ++ファイルの場合）。 GDNativeに変換された場合）。 しかし、私の元の応答の一部（公式の拡張リポジトリのセクションを参照）には、ユーザーが拡張リポジトリがあることを思い出せなくなった場合に、拡張にそれらを持ち込むと、この奇妙な種類の市場が（より良い言葉がないために）作成されるという懸念が含まれていました公式バージョンがどれほど公式であるか、またはどれほど最新であるかに関係なく、必要なものが含まれています。 「機能Xを備えたノードX」、「機能Yを備えたノードX」など（拡張機能にされたノードを表す「ノードX」）を持つ新しいアドオンがアセットライブラリに追加され、混乱が生じます。すべてが車両を支援すると主張しているが、より多くの公式ノードが取得する可能性のあるレベルまたは精査を持っていないアドオンの数。

@ LikeLakers2

しかし、なぜですか？ その時点で、何も害を及ぼさないので、とにかくアセットにこの依存関係ファイルを持たせてみませんか？

私はそれに反対していません。 しかし、reduzはそれを好まないように思われるので、最初に提案したような単純な改善を行うことをお勧めします。 それがどうなるかを見て、後で依存関係を持つアセットの機能を追加することができます。 一度に一歩だけ提案。

ただし、プロジェクトフォルダーの外部にプロジェクトアドオンをインストールすると、管理が難しくなるため、反対です。 「グローバル」エディタアドオンのみがプロジェクトフォルダの外にある必要があります。

もう少し考えてみると、実際にコア機能が削除され、すべてのプロジェクトでそれらのコア機能（つまり拡張機能）にアクセスしたい場合は、これらの拡張機能をにインストールできるようにするのが理にかなっています。それらのバージョン管理を備えたグローバルな場所。 ただし、この場合、拡張機能をダウンロードしてプロジェクトフォルダに直接インストールするオプションもそのままにしておく必要があります。 （繰り返しますが、-gを使用してローカルまたはグローバルにインストールするnpmオプションのようなものです）

上記のように、コアエンジンから物事を削除して資産に変える場合は、より優れた資産管理システムを使用するのが理にかなっています。 そうしないと、ユーザーが削除された機能を簡単に見つけることができないため、エンジンから機能が失われることになります。

私はその理想的なシナリオを考えていました

• 新規ユーザーおよびエンジンをコンパイルしないユーザー：エンジンダウンロードページで、コアエンジンをダウンロードするオプションがあり、エンジンのダウンロードに含める公式または推奨の拡張機能を選択することもできます。 （拡張機能をグローバルフォルダに保存できない場合、これは不可能であることに注意してください。ユーザーは、プロジェクトを作成した後に拡張機能を見つける必要があり、発見可能性が損なわれます。...理想的な[不可能]世界では、Webサイトは選択した拡張機能/コンポーネントからその場でカスタムC++ビルドをビルドします。）
• エンジンをコンパイルする人：拡張C ++コードのダウンロードとバージョンを管理し、それらをビルドフォルダーの正しい場所に配置して、エンジンビルドに含めるツール。

エンジンをコンパイルする人として、GDNative（または低速のGDScript）ではなくモジュールとして拡張機能を使用したいと思います。 ビルドに含めるまたは含めない特定のノードタイプを選択したり、すべての3Dのものを削除したりできるモジュール性のレベルを想像しています。

C ++拡張機能がすべてGDNativeになる場合、拡張機能の作成者はすべてのプラットフォーム用に構築する必要があります。これは、やり過ぎだと感じるので便利な単純な小さな拡張機能を設定することを思いとどまらせる可能性があります。それを公開するために必要なすべてのことを行います-そしてまた、機能を多くの小さなモジュールに分割することを思いとどまらせます。 また、出力プロジェクトに非常に多くのdll/共有ライブラリファイルが追加されるという事実も気に入らない。

一方、エンジンをコンパイルしない人にとっては、GDNativeがC++拡張機能を追加するための唯一のソリューションです。

したがって、starry-abyssが提案したように、GDNativeを通常のモジュールに自動適応させることができれば、それは素晴らしいことです。

さて、私は立場を変えました。業界の大国と同じリーグの機能を備えた膨満感のないエンジンのアイデアが好きです。

すべての追加ノードを分離することで、多くの利点が得られます。特に、必要なものと不要なものを選択できるようになります。

これがそれにアプローチする方法の私の提案のいくつかです、

1. まず、アセットライブラリに機能を追加して、パーツにインストールできるアセットを作成できます。gitでは、アセットをタグまたはブランチで区切ることができます。
   したがって、2Dフィーチャノードのみが必要な場合は、それだけをダウンロードできますが、更新を確認する場所は1つだけです。
2. 次に、アセットの更新にラベルを追加する機能を追加できます。たとえば、コア更新や機能の更新、下位互換性の破れなどがあります。
   これは、アセットマネージャーがアドオンを更新し、問題について更新を依頼するために自動的に使用できます。 コアアップデートが待機している、または次のアップデートで下位互換性が失われることがわかるように。 更新しますか？
3. 3つ目は、アセットの複数のバージョンを使用できるようにするためです。バージョンが古すぎると、アドオン/アセットの開発者はそれを古くなったものとしてマークできます。これは、Godotを開いたときに反映され、古いバージョンを削除するかどうかを尋ねられます。 。
4. そして最後に、アドオンが他のアドオンを要求する機能は依存関係のようになりますが、このアドオンを実行するにはこのアドオンが必要であり、インストールしていない場合はそれが通知されます。
   また、アドオン自体がアドオンが見つからなくなったことに気付いた場合は、アドオンを再度追加するか、エラーメッセージを表示するように依頼してください。

この方法を使用すると、依存関係マネージャーは必要ありませんが、開発者が作業を担当します。 アドオンが古くなり、古いアセット/アドオンを使用している場合、両方の開発者が話し合い、開発者が何をすべきかを決定できます。
彼はアドオンをすぐに移植するかもしれません。 必要に応じて、または場合によっては、他のアドオンで古いタグを削除することもできます。

@chanonが言ったように、アセットをグローバルとしてダウンロードし、Unityが行ったようにプロジェクトにインポートできるようにする必要があります。
また、アドオンプロセスのインストールに多くの柔軟性を備えた、現在の実装よりも優れたアセットマネージャーを許可する必要があります。
GDNativeとModuleの両方としてアドオンを追加できるようにすることをお勧めします。これにより、アドオン開発者にいくらかの負荷がかかりますが、ここで何かが根本的に変更されない限り、これが唯一の許容可能な解決策だと思います。
ただし、アドオンの作成を容易にするために、GDNativeにいくつかの機能を追加することはできます。 一度にすべてのプラットフォーム用に構築できるように、はるかに優れています。

プラグインの更新による依存関係とアセットの破損の問題について、
なぜそうではないのですか（そして私がすでにこれを提案している誰かを逃した場合はお詫びします）

1. サーバーにすべてのバージョンのアップロードを維持させる

2. プラグインが特定のプラグインの特定のバージョンを指定できるようにする

3. プラグインには適切なバージョン管理システムを使用してみてください（Godotは
   Major.Feature.BugFixバージョン番号、私は好きです）

4. そして最も重要なのは、プラグインを自動更新しないのですか？ （または少なくとも許可する
   ユーザーは、バグ修正やバグ修正など、問題のない更新の種類を選択できます。
   機能は更新されますが、メジャーアップデートはありません）。

@ Two-Toneでは、なぜ全体を膨満感のないものにするのですか？

エンジンとシステム全体を可能な限り膨らませないようにするために、この議論があります。不必要なバージョンが飛び交うことはありません。

あなたはユーザーが更新することを決定できるようにすることについて正しいですが、バグ修正はデフォルトで自動であるはずです。 100個のアドオンがある場合、バグ修正の更新を1つずつ確認するつもりはありません。
残りはユーザー次第です。必要に応じて無効にする設定を行うことができます。

また、ストアはオフラインで使用するための公式バンドルを提供する必要があります（エディターでのオフラインストアのサポート付き）。

最も重要なデモと非常に簡単に見つけられるはずの最も重要なアドオンを含む数十MBのオフラインパックを1つ提案します。 古いgodotバージョンのような、公式ダウンロードページの小さなフォントリンクがあれば素晴らしいでしょう。

おそらくそうですが、デスクトップが256BG SSD + 1TB HDD未満のものを使用していないようで、電話でさえ最小16GBから始まるスペースがあり、そのすべてが増加する可能性が高い世界では、それはそれでしょうか悪い？

ポータブルで手頃な価格のラップトップセグメントでは、eMMCは健在で、32GBサイズ（10GB未満の空き容量）はそれほど珍しいことではありません。

ちなみに、そのクラスのラップトップでは、現在のandroidエクスポートシステムは使用できると思いますが、計画されているもの（https://github.com/godotengine/godot/issues/18865）は使用できません。 新しいシステムのメリットは理解しており、バランスをとると、おそらく自分で投票したはずです（この問題を確認したとき、まだコンテストはありませんでした）が、変更によって重要なユースケースが失われていることに注意する必要があります。

@swarnimarun誤解があるかもしれません。 そのコメントで「システム」と言うときは、エンジンではなく、プラグインを提供するサーバーを意味します。 それがあなたをつまずかせたものならごめんなさい。

そうでなければ、プラグインの依存関係システムで人々の問題を解決しようとすることは、エンジンの肥大化を抑えようとすることとは正反対であることがわかりません。 プラグインは、誰かが必要とする場合に備えてサーバーに保持され、肥大化やメンテナンスのオーバーヘッドには寄与しません。ほとんどのプラグインは非常に小さいため、それらを保存するためのコストはそれほど高くないはずです。

@Two-Toneええあなたはコンピューターを意味していると思いました。 ただし、サーバーでは問題なく、Githubでは変更が加えられた後でも保存できるハッシュが許可されているため、現在のシステムではリポジトリを更新した後でも、アセットページでハッシュを更新する必要があります。

githubだけでなく、gitlabや他の人もそれを許可しています。 他にある場合。 Gitは、コミットIDとして保存されるハッシュをサポートしているため、処理は実行された方法で実行されます。

ほんの数セントですが、これのほとんどは以前に言われたことがあるので、何か新しいものを持ち込むことはできないと思います。

私はプラグインとして物事を行うためにプラグインとして物事を行うことを信じていません。 サイズの問題は理解していますが、私たちはもう80年代に住んでいません。 エンジンが50Mbまたは55Mbであり、エンジンが50Mbまたは500Mbの間ではないことについて話しているので、プラグインに移動される機能の余分なサイズの増加は、シリアスゲームのアセットのサイズと比較して無視できます。 私たちが支払う価格がより厄介な統合である場合、それは価値がありません。

プラグインの方が理にかなっている場所はたくさんあります。GDNativeの成熟のようなアーキテクチャでは、「これはプラグインである方が良い」という質問をする必要があります。多くの場合、答えは「はい」です。 プラグインについて私が気に入っていることの1つは、開発者として多くの点でより自由になることです。 しかし、限界もあります。

私のVR体験は、これらのいくつかには当てはまりません。 これに時間がかかるのには理由があります。これをモバイルで起動して実行したいと思います。 特にモバイルでは、さまざまな方法でディスプレイを設定する必要があるため、コアの動作方法を変更する必要があり、プラグインでのキャプチャが困難であることが証明されています。
これまでのところ、OpenVRとOpenHMDは簡単なものでした。 Oculus見下されている回避策を実行しましたが、満足しています。
ARKitはコアにある必要があり、モジュールとしては解決できません。少なくとも現在の構造ではそうではありません（AppleはiOSでダイナミックライブラリを許可していないので、それもあります）。
GearVRとDaydreamは本当にコアである必要があります。これは、GearVRが独自のライブラリを使用しているため、不可能です。
Hololens / Microsoft MRこれをプラットフォームの選択にできるかどうかを確認するルートをたどっています。アプリは、2つの間で実行されることになっており、ホログラフィックのみのアプリとしてHololensにインストールされるため、Microsoftはそれらをそのように見ています。

現在、ARとVRはごく少数の人が使用するニッチな機能であるため、可能な限りコアから外しておくべきタイプのものであり、私はその観点に猛烈に同意しています。 しかし、他のことについても同じことを言うことはできません。

どこかで車体が真剣に言及されているのを見ましたか？ プラグインに入れることで節約できるコードのキロバイト？ 物理学は、私がコアIMHOで完全にサポートされるべきだと思うタイプのものです。 むしろ、コア内に完全に統合された物理オブジェクトの完全なスイートが表示され、プラグイン内のオブジェクトを探す必要があります。 GDNativeで作成したARVRInterfaceと同様のインターフェースアプローチは、おそらく強固な統合を生み出すでしょうが、それでも私たちは人生を不必要に困難にしているだけだと感じています。

地形エディタコンポーネントとは対照的に、プラグインベースに最適であると私が考えるものがあります。 作成したいゲームのタイプに応じて、地形に対処するさまざまな方法があります。そのため、さまざまなアドオンを選択することは理にかなっており、コアでの開発とは独立してこれらを開発できることは、さらに大きな理由です。

プラグインが理にかなっている長い話を短くするために、プラグインをサポートしますが、やりすぎないでください。

プラグインに変える価値のあるノードは、コントロールノード（複合ノード）によって作成されたコントロールノードであり、他のノードを構築するための単純なノードのみを残します。

Vehicleのような複雑なロジック、またはPositionのような単純だが便利なノードは、コアに適しています。

IMO、これらのどれもエンジンから削除されるべきではありません。 コントロールノード、物理ノード（Vehicleなど）、および現在存在しない地形サポート：

かなり自己完結型の統合アプリケーションであるため、Godotを使用します。
将来、Godotをダウンロードして、Vehicle、Controlノード、Terrainサポート、Shaderエディター、適切なNavmeshプラグインなどを探す必要がある場合は、現在のプラグインとAssetLibシステムを使用してください。

このようにすると、プラグインインフラストラクチャとAssetLibの両方でユーザビリティのオーバーホールが必要になります。

ちなみに、UE4のインストールサイズが大きいことは、Vehicles、Terrain、またはUIのサポートが組み込まれていない場合よりも、はるかに気になりません。

これがどれだけ述べられているかはわかりませんが、このような大きなスレッドは追跡が難しくなる可能性がありますが、とにかく：

すぐに使える最高のエクスペリエンスに焦点を当てるべきだと思います。 「公式に承認された」プラグインであっても、アセットライブラリにアクセスする必要があるのはかなり扱いにくいです。

エクスポートサイズによってエンジンの使いやすさが悪化することはありません、IMO。 エクスポートサイズを縮小する必要がある場合は、エクスポート時に3Dなどのエンジンのセクションを無効にする機能をいくつか作成します。 特に私は個人的にモバイルや特にウェブのようなプラットフォームを評価しておらず、このような議論でエンジンが抑制されているのを見るのは辛いです。 （私はそれらの需要を見ることができます、私を誤解しないでください、しかしねじウェブ）

地獄、エディターのダウンロードサイズが心配な場合は、「バッテリーが含まれている」と「最小限の」エディターのダウンロードが別々にあるはずです。 分離がどのように実装されるかは議論の余地がありますが、何があってもうまく統合されている必要があります。

ディスカッション全体を完全に読んだわけではありませんが、多少再調整したいと思います。サイズについては気にしません。 もちろん、一部のプラットフォームではエクスポートサイズを小さく保つことが重要ですが、エンジンに機能を実装する際の決定要因ではありません。 前述のように、エクスポートサイズを小さくするために一部の機能を条件付きにする必要がある場合、それは簡単です。 エンジン自体のダウンロードサイズは関係ありません。

これで解決したので、エンジンからいくつかのもの（「いくつか」を決定する必要があります）を除外することを検討するように促す主な要因は次のとおりです。

• 技術的負債。 すべてのコードを維持する必要があります。 2014年以来のような壊れたVehicleBodyは、実際のゲームには十分ではないため、特に有用ではありません。 最近、Bulletを使用して改善されたため、改善されていますが、過去4年間は、事実上デッドコードと不要なメンテナンスの負担でした。
• 普遍性：Godotは、あらゆる種類のゲームを実行できるエンジンであり、Godotが提供する機能により、あらゆる種類のゲームを実行できるようになります。 排他的である必要があるという意味ではありませんが（ほとんどのゲームで同時に2Dと3Dの両方を必要としない）、機能はほとんどのユーザーの一般的なニーズに対応する必要があります。 つまり、私たちが提供する機能は低レベルである必要があり、ゲーム固有の高レベルの機能はほとんどの場合、外部で提供するのが最適です。
• 柔軟性：コアの外部で高レベルの機能を維持することで、それらを改善したり、必要に応じてフォークしたりするための、はるかに高速な反復プロセスが可能になります。

このようにすると、プラグインインフラストラクチャとAssetLibの両方でユーザビリティのオーバーホールが必要になります。

それがこの問題の存在理由ですよね？ :)要点は、コアエンジンのすべてのコーナーケースをバンドルするのではなく、より良いワークフローを可能にするために、ユーザビリティのオーバーホールが必要であるということです。

そうですね...誰かがVehicleBodyという名前に加えて外部機能を開始するためのアイデアが必要な場合は、godot 2から3で失われたノードとクラスを覚えておきたいです：ParticlesAttractor2D（ノード）とEventStreamChibi（このクラスは外部アセットに最適です）、particlesattractorは実際のパーティクルシステムと互換性がないことを知っていますが、...外部アセットの形でgodotの失われた機能を回復するのはどうですか（たとえば、古いパーティクルシステムは新しいパーティクルシステムと共存しています...）。 たぶん誰かがそのコードを別々のリポジトリに保持したいと思うでしょう...

@Ranollerの新しいシステムは常に古いものを削除しますが、それは避けられません。
CPUパーティクルはGLES2で戻ってくるはずですが（CPUのものをサポートしていないため）、CPUにはアトラクタがあり、GPUにはないアトラクタがあるのは良くありません。
EventStreamChibiはモジュールでした。新しいオーディオシステムは、柔軟性が増すとトラッカーファイルのサポートが向上すると思います。

保守性を気にかけても、まだ分別するべきではないと思います。
特別なスレッドに投稿することで、年をとるのを手伝ってくれるように人々に頼むことができます。そうすれば、人々は機能を更新することができます。
Godotユーザーベースの驚異的な成長に伴い、多くの人が物事を更新し、エンジンの一部に欠けている古い機能や重要な機能、たとえばより多くのジョイントに取り組んでいることを確信しています。

人々に別々のコードファイルで作業させる方が簡単だと思うなら、ほとんどの場合、同じ露出が得られないため、それらのファイルについて知らないのは間違いです。アセットマネージャーは機能する必要がありますが、プラグインとしての機能はうまく機能しません。
UnityからGodotに切り替える人が何人かいます。これは、非常によく統合されており、プラグインとして不可欠な機能を提供していないためです。
そしてUnityは、物事をより統合する作業を開始し、アドオン開発者をUnity開発チームに追加したことに気づきました。

30MBのエンジンをダウンロードしてから、プロジェクトに追加するのを忘れる可能性のあるプラグインとして個別の機能をダウンロードする時間を無駄にする必要がある場合は、そもそもそれらを使用しない可能性があります。 これは初心者にとっては問題です。

技術的負債に関しては、これはすべてのプロジェクト（FOSSまたはコマーシャル）が最終的に対処しなければならない問題です。 真実は、一部の開発者が最終的に離れ、エリアがあまり注目されなくなることです（したがって、誰かが興味を持つまで、そのエリアを「メンテナンス」モードにする必要があります）。 私が言ったように、これは大きな商用アプリにも起こります。 そのため、エンジンをどれだけトリミングしても、Godotでは必然的に発生します。

その分野での最善の解決策は、人々がソースに貢献し始めることを奨励する開発シーンを育成することです（そして、Godotシーンは、すべてのボランティア開発を見ると素晴らしい仕事をしていますが、それを維持する必要がありますパッチの寄稿者がレビューを見るのに長く待たないようにするなど）。 ただし、開発者が残したために機能を削除することは、可能であれば避ける必要があります（常に変動する機能リストは、Godotを_使用しない_ように人々を説得するための優れた方法であるため）。 むしろ、機能の削除は主に、より優れたものに置き換えられているために発生するはずです。

ただし、開発者が残したために機能を削除することは、可能であれば避ける必要があります（常に変動する機能リストは、Godotをまったく使用しないように人々を説得するための優れた方法であるため）。 むしろ、機能の削除は主に、より優れたものに置き換えられているために発生するはずです。

繰り返しになりますが、議論は間違った方向に進んでいるので、正しい方向に戻そうとします。 トピックは、ものを削除することではなく、削除したいと思う可能性のある新しいものが追加されないようにすることです。 ものを追加するのはとても簡単ですが、互換性を壊さずに削除することはできません。

Godotが成長するにつれて、ますます多くの新しい貢献者が、エンジンに従わせたいアーキテクチャや設計に適合しない可能性のある追加機能を提供します。 これらすべての変更を確認するには多くの時間がかかり、さらに、それらが私たちが望むものに適合するかどうかを判断するのにさらに時間がかかります。 このような新機能を新しい寄稿者がマージすると、エンジンメンテナがよく知らないか、最終的に完全に承認されない可能性があり、元の寄稿者がリファクタリングして必要なものと一致することを確認するために固執しないことがよくあります（を参照してください）。たとえば、Tweenノードは優れた機能ですが、標準以下の設計であり、元の作成者はもう存在しないため、途中で互換性を壊して、再考して書き直すのは私たちの責任です）。

したがって、 @ reduzの提案の要点は、新しい貢献者がコアエンジンに入れたいと思う機能の数が増え続けることは、ほとんどの場合、アセットライブラリのアセットとしてより適しているということです。 ここでのこの問題のポイントは、このワークフローを可能な限りスムーズにする方法です。

Godotのコードベースを縮小しようとしているのではなく、爆発して制御不能になるのを防ぐ方法を考えています。 （PRが大きい1回限りの寄稿者は、完全なコードベースとエンジンの将来に対するビジョンを完全に理解しているエンジンメンテナーよりもはるかに頻繁であるため）。

したがって、 @ reduzの提案の要点は、新しい貢献者がコアエンジンに入れたいと思う機能の数が増え続けることは、ほとんどの場合、アセットライブラリのアセットとしてより適しているということです。 ここでのこの問題のポイントは、このワークフローを可能な限りスムーズにする方法です。

問題を一歩戻す以外に、これらをアセットライブラリのアセットにするにはどうすればよいでしょうか。 メンテナンスされなくなったGodotにバンドルされたコードから、メンテナンスされなくなったGodotアセットのコードに移行します。 いずれにせよ、元の寄稿者はおそらくある時点でそれを維持することをやめ、最終的には再び壊れることになります。

@ LikeLakers2ええと、それの目的は、エンジンに追加される新しい貢献のためのスムーズな道を作ることです（より資産に関連するもののほとんどは今のところ拒否されているため）。 エンジンのある側面が維持されていない場合、その時点での純粋な膨張として、そもそもエンジンにバンドルされるべきではありません。 その性質のものは、外部に含まれる/更新されたプラグインとして特に適しています。

将来、Godotをダウンロードして、Vehicle、Controlノード、Terrainサポート、Shaderエディター、適切なNavmeshプラグインなどを探す必要がある場合は、現在のプラグインとAssetLibシステムを使用してください。

丁度。 AssetLib /アドオンは一般的に今はうまく機能していません。そのため、会話がそれらに逸脱する傾向があります。 今すぐに物を取り出したいと思う人はいないと思いますが、前述のように、重要なのは新しいものをあまり追加しないことです。

問題を一歩戻す以外に、これらをアセットライブラリのアセットにするにはどうすればよいでしょうか。 メンテナンスされなくなったGodotにバンドルされたコードから、メンテナンスされなくなったGodotアセットのコードに移行します。 いずれにせよ、元の寄稿者はおそらくある時点でそれを維持することをやめ、最終的には再び壊れることになります。

そうですね、エンジンとは別に管理できればもっと簡単だと思います。 Blenderはこのようなことをします。 それらには「公式」（実際には公式ではなく、事前に含まれている）アドオンがありますが、それらのコードは別のgitサブモジュールに保持され、それらを送信した人によって保守されなくなった場合（再送信する必要があると思います）大きなリリースごとに）、それらは削除されます。 正直なところ、このアプローチはあまり好きではありませんが、90％のアセットブラウザが組み込まれ、残りの部分（エクスポーターなど）が完全に統合されていればいいのですが。

ただし、エンジンには基本的なビルディングブロックだけが含まれ、車両ノードなどは公式のアドオンになり、その他の大きくてさまざまな方法で実装できるものはすべて通常のアドオンになります。 、 正しい？

私が得られないのは、公式のアドオンがどのように実装されるかです。 現在、組み込みのように見えるカスタムノードを作成することはできないと思いましたが、スクリプトが必要でしたか？ または、c ++モジュールなどで可能ですか（ここではc ++ noobです）。

また、最終的には、分離された公式ノードに依存するアドオンをどのように作成するかという問題に直面します。 ある種の依存関係システムがなければ、それは地獄のように聞こえます。

パーティーに遅れましたが、現在のプロジェクトの規模を考えると、Godot 3用のプラグインを_たくさん_開発していて、プロジェクトが完了する前にさらに多くのプラグインを開発していることに気づきました。 各プラグインでは、ゲームにとらわれない方法でできるだけ多くのプラグインを開発し、他の人が使用できるようにMITライセンスの下でそれらをオープンソース化しようとしています。 私はうそをつくつもりはありません。 現在のアドオンシステムは、物事の壮大な計画では実際にはそれほど悪くはありません...しかし、多くの場合、境界線を役に立たないものにするいくつかの欠落部分があります。 ただし、それらに到達する前に、 @karroffelのアイデアについていくつかお話ししたいと思います。

まず、この問題をまとめていただきありがとうございます。 この議論をすることは重要だと思います-特に短期的には。 とは言うものの、OPで提示した各論点は、接線方向のオーバーラップのみでほぼ直交していると思います。 すべての懸念事項に一度に対処しなくても、ここで解決策を何度も繰り返すことができると思います。

これは、現在のアドオンシステムでの私の_個人的な_悩みにつながります。実際に定期的にプラグインを開発している人から、より良い世界への2つの非常に良い出発点になると思います。

現在のアドオンシステムの最大の問題は、依存関係の管理が不足していることです。

これについてはすでに十分に議論されていますが、提案のほとんどはかなり手間がかかり、現在のシステムとの互換性はあまり高くありません。 さて、私はまだassetlibモジュールのコードベースに精通していませんが、この部門では簡単に勝つことができるはずだと思います。 現在、Githubのサードパーティアドオンリポジトリは、次のフォルダ構造に従います。

addons/
    addon_name/
        plugin.cfg
        ...other files

私が提案するのは、plugin.cfgスキーマを拡張し、使用するオプションのコミットハッシュ（またはブランチ/タグ名）を使用して依存関係バージョンのリストを作成する機能を追加することです。 次のようなものが機能します。

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

次に、アセットライブラリがアセットをインストールするときに、最初にプロジェクトを現在と同じようにアドオンディレクトリにダウンロードし、次に各依存関係を（定義された正しいハッシュまたはブランチを使用して）ダウンロードし、アドオンディレクトリにも配置します。 。 最初のステップとして、依存関係の競合を無視するか、ユーザーにどちらを使用するかを選択させることができます。 これは「理想的な」解決策ではありませんが、ほとんどの場合は機能し、少なくとも、assetlibのより複雑なオーバーホールが実行されるまで私たちを引き留めると思います。 （誰かが依存関係の競合に頭から離れて対処する簡単な方法を思い付くことができない限り）。

実例として、
godotビヘイビアツリーのアセットがあります。 このシステムの一部は、ノード間で共有される任意のグローバルまたはノードローカルデータを格納するためのUE4のようなBlackboardノードです。 これは、動作ノード間で状態を共有するためにBTシステムで使用されます。 それはすべて問題なくダンディですが、私は現在、ダイアログシステムとそれに付随するツールを開発しています。このシステムの一部では、条件に使用するために、ある種の変数のデータベースが必要です。 BTシステムの黒板コンポーネントをダイアログシステムにも再利用したいと思います。 実際、Blackboardコンポーネントは可能な限り一般的であり、グローバルデータはgamedevでかなり一般的なイディオムであるため、基本的にすべてのプロジェクトで再実装されるため、それ自体でもかなり便利なアドオンになる可能性があります。 。

適切な依存関係システムを使用すると、Blackboardコンポーネントを独自のアドオンに分割し、このコンポーネントをすべてのBTアドオン、ダイアログシステムアドオン、およびその他のゲーム固有の用途で再利用できます。 私が何を意味しているようですか？

マルチスクリプトノードの必要性

これはすでにこの問題のもう1つのホットなトピックであり、正直なところ、Godotの使用目的の基本的なイデオロギーを変更せずにこれに取り組むための非常に良い方法はありません。 これは大丈夫かもしれないし、そうでないかもしれませんが、そうです...とにかく、これはプラグイン_authors_にとっては、プラグイン_users_の場合ほど問題ではありません（多くの場合、同じ人ですが;）。

結局、この2つを解決できれば、90％になると思います。 残りの10％は私の意見ではそれほど大きな問題ではなく、おそらく資産の基本的なアーキテクチャをオーバーホールするという観点からアプローチする必要があります。私の意見では、はるかに大きな魚を揚げた後に待つことができます。

異議がなければ、今後数日のうちに、依存関係の管理に関する提案をassetlibコードに実装しようと思います。

依存関係の管理は私にはクールに聞こえます。 ：スマイリー：

私が同意しない唯一のことは、依存関係のバージョンを持っていることです
オプションのリストになります。 それはreduzが言った問題を引き起こします
他のエンジンのプラグインシステムで発生します。

誰かが依存関係の競合に頭から離れて対処する簡単な方法を思い付くことができない限り

そのための解決策は、プラグインがコードを呼び出す方法に依存すると思います
別のプラグイン。 プラグインのスクリプトが実行するように設定した場合
extends "dep2/folder/script.gd" 、インストール時にdep2を変更するだけで済みます
dep2-v3.1.2 。 ハッシュの場合、最初の5桁を使用できます（ただし、
少なくとも42文字の長さの名前のフォルダーが必要です）。 5時に
数字衝突の可能性は信じられないほど小さいです。

今は少し疲れているので、何か足りないかもしれませんが、見えません
問題があります。

@jonbonazzaを使用する場合は、Gitの使用法をハードコーディングしないようにしてください。 このあたりは当たり前のように聞こえますが、他のVCSシステムを好む（またはVCSをまったく使用しない）人もいるので、おそらくそれはアセットライブラリ側で処理する詳細である必要があります。
また、プロジェクトでプラグインをVCSサブリポジトリとして使用しやすくするために何かを検討するのではないでしょうか。 ある時点で言及されましたが、合意があったかどうかは覚えていません。

はい、アセットのIDとバージョンだけで十分だと思います。

Gitリポジトリ/ブランチ/タグ/ハッシュを指定することは依存関係を指定するオプションの方法かもしれませんが、主な方法はアセットIDによるものでなければなりません。

アセットライブラリに人間が読み取れる一意のID（スラッグ）があるかどうかはわかりません。 そうでなければ、そうすべきです。 たとえば、npmモジュールには、インストール時に使用するテキストモジュール名/IDがあります。

その場合、依存関係の仕様は次のようになります。

[dependency]
asset_id="some_asset"
version="1.0.0"

@Two-Tone私はこれに夢中になりすぎないようにしようとしていました。 より良いアプローチが決定されるまで、私たちを引き留める簡単な何かが欲しかっただけです。

@Zylannおそらく、アセットライブラリで現在使用されているのと同じアプローチを使用します。つまり、githubからzipファイルをダウンロードして抽出します。

@chanonアセットlibはgithubで直接動作するため、バージョンの識別はコミットハッシュ、ブランチ、タグのみです。

クレイジーすぎる部分はどこですか？ 依存関係のバージョンを必須にするか、私のソリューション
依存関係の競合については？ 1つは持っているほとんどすべての場所で標準です
依存関係の管理とその他は、テキストとフォルダの簡単な編集です
名前付き。 どちらもおかしいとは思いません。

2018年7月3日火曜日、午前11時23分[email protected]は次のように書いています。

@Two- Tonehttps://github.com/Two-Tone夢中になりすぎないようにしようとしていました
これとともに。 より良いものになるまで私たちを引き留めるシンプルなものが欲しかった
アプローチが決定されます。

@Zylannhttps ://github.com/Zylannおそらく同じアプローチを使用します
これは現在アセットライブラリで使用されています-zipのダウンロードと抽出
githubからのファイル。

@chanonhttps ://github.com/chanonアセットlibはgithubで動作します
直接なので、バージョンの識別はコミットハッシュだけです。
ブランチ、およびタグ。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/19486#issuecomment-402214905 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEJES-_IJBjvj3ImvZnqdu-cIAunCp2gks5uC5qIgaJpZM4UhqDC
。

@ Two-Tone申し訳ありませんが、「あまりにもクレイジー」とは、「複雑すぎる」という意味でした。 長期的には適切な紛争解決が必要であることに同意しますが、暫定的にそれなしで逃げることができることを望んでいました。

もう1つのオプションは、assetlibをすべて一緒に放棄し、depsをプロジェクトに直接gitクローンすることです。ただし、現在の事実上のプラグインプロジェクト構造はaddonsディレクトリにルートされているため、これは実際には機能しません。 プロジェクトルートを1レベル深くする必要があります（つまり、アドオンディレクトリを除外し、プラグイン名をルートとします）。 正直なところ、これは歓迎すべき変更だと思います。依存関係にgitサブモジュールを使用できるからです。

@jonbonazzaなるほど。 ソリューションは、アセットライブラリを変更することなく、すぐに実装および機能できるものです。 それから私はそれが良い第一歩であることに同意します。 （私が権限を持っているコアメンテナーであるというわけではありません..それが良い第一歩だと思うだけです。）

アセットライブラリデータベースにテキスト識別子（スラッグ）とバージョン情報が追加されている場合は、上記の例のように追加できます。

依存関係にgitサブモジュールを使用できます。

@jonbonazzaは、後者の質問が再び発生する場所です。プラグインの再現でサブモジュールを使用することはできないようです。そのリポジトリには、ダウンロードに適した完全なファイル階層を含める必要があり、 .gitを強制するためです。

@chanon正確に。 いくつかのファイルに少量の追加コードが必要になるだけです。 正直なところ、assetlibに組み込む代わりに、これを実行できるアドオンが開発される可能性があります。

@Zylannええ、それは私がサブモジュールについての私のコメントで得ていたものです。 プロジェクト構造に対する現在の制限のため、現在は不可能ですが、この点でアセットライブラリをより柔軟に変更することは簡単です。

編集：下位互換性のある方法でも実行できます。

実は少し前にプロジェクトの構造を提案しました。 これが、プラグインが現在どのように機能するかについての私の主な不満です。 それらをパッケージ化する良い方法はありません。 ＃18131を参照してください。 それは本当に最初に変更する必要があります、imo、何よりも先に、そして早いほど良いので、プラグインを移行する必要のある人が少なくなります。

何が複雑ですか？ 1つは、で強制できる要件です。
単純なチェックともう1つは単純な一致と置換、または
追加/追加。 これは、依存関係のサポートを実際に追加するよりも簡単です。

2018年7月3日火曜日、午後12時11分[email protected]は次のように書いています。

@ Two-Tone https://github.com/Two-Tone申し訳ありませんが、「あまりにもクレイジー」という意味です
「複雑すぎる」というのは、これは私たちを引き留めるための迅速な解決策であると考えられているからです。
長期的には、適切な紛争解決が必要であることに同意しますが、
暫定的にそれなしで逃げられることを望んでいた。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/19486#issuecomment-402229111 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEJES7c8ziwhXZirsTsLY0zWfI-jrBzmks5uC6XUgaJpZM4UhqDC
。

@ Two-Toneは、プラグインのコード内のスクリプトがアドオンのパスを直接使用することが多いため、フォルダーの名前を変更することはできません。 例えば

extends "res://addons/foo/bar.gd"

@jonbonazza追加しますが、それを行うのはスクリプトだけではなく、別のリソースを参照するリソースです。

次に、アドオンフォルダの構造を私が言ったようにしますが、必須です。
インストール時間は、Stringクラスが検索および置換する関数を使用するだけです。
探すべきすべてのスクリプトにあります

'extends " res：// addonname / '

そしてそれを

'extends " res：// addonname-versionnumber / '

これらはコードの難しい問題ではありません。 それらはc++のおかげで本当にシンプルです。
これらの問題を確実に修正するために、これらはほとんどの場合ユーザーの問題です。
私たちはいくつかのものを義務付ける必要があります。 プラグインをアップロードし、ユーザーがそれを見つけた場合
開発者がこれらに信じられないほど従わなかったので、それは完全に壊れています
単純なルール、それはプラグイン開発者にあります。

そもそもルールを義務付ける必要があるので、
これらまたはこれらの何らかの形式を含めて、これが正しく行われていることを確認します
最初から。

2018年7月4日水曜日、午後12時48分[email protected]は次のように書いています。

@jonbonazza https://github.com/jonbonazza追加します、それはただではありません
それを行うスクリプトですが、別のアセットを参照するアセット。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/19486#issuecomment-402533781 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEJESwoMKvVVXcllrQ4YQQO852oZ1v7rks5uDP_SgaJpZM4UhqDC
。

プラグインが更新後に互換性を壊した場合、非推奨のフォールバックを提供するか、@ Two-Toneが言うように、プラグインまたはそのサブフォルダーの名前を変更してパスを意図的に壊す必要があります（ただし、これは最悪のシナリオです。良い状況ではありません）。 それがエンジン自体のやり方であり、他の人もそうしています。 プラグインを書くことは、あなたが知らない他の人々/プラグインがそれに依存するという全く異なる考え方を伴います。

これが解決するのは、依存関係の問題ではなく、依存関係の競合に対する解決策です。 1つのプラグインは別のアドオンのバージョン1に依存し、別のプラグインはバージョン2に依存する可能性があります。これがないと、競合が発生するか、ユーザーがプラグインを使用できないように制限する必要があります。競合する依存関係があります。

また、更新によって互換性が失われるのを防ぐための解決策は、各更新に一意のバージョン番号が必要であることを強制することです。 ただし、 plugin.cfgを解析してから、その名前とバージョン番号のプラグインが既に存在するかどうかをアセットサーバーに問い合わせる必要があるため、「複雑すぎる」カテゴリに分類される可能性があります。 ある場合は、エラーをスローします。 そうでなければ、すべてがうまくいくはずです。

プラグインのスクリプトについて話しているのか、ユーザーが作成したスクリプトについて話しているのかはわかりませんが、どちらにしても、少し扱いに​​くいことには同意しますが、それほど難しい問題ではないはずです。

私が考えることができる唯一の解決策は、ユーザーがスクリプトで使用しているプラ​​グインのバージョンを指定できるようにgdscriptを拡張することです。その後、ユーザーはextends "res://addonname/etcを実行し、エンジン自体に使用を処理させます。正しいパス。 しかし、それは間違いなく@jonbonazzaが言及した「複雑すぎる」問題に該当します。 ただし、短期的にはスキップできます。

最終的に解決する必要がある他の問題があります。 たとえば、ユーザーは、インストールされている依存関係、依存関係の競合の問題を解決するために内部ファイルシステムブラウザーで複数のフォルダーを処理する方法、依存関係であるが更新されているプラ​​グインをどのように処理するかを知っている必要があります（手動でインストールされたプラグインに使用されるのと同じ設定を適用しますか？たとえば、バグ修正を自動インストールするか、メインプラグインが依存関係のリストを更新するときにのみ更新をインストールします）。

@reduzが依存関係の管理が重要ではないと感じている理由は絶対にわかります。 非常に多くの変数があるため、これをGodotに含める価値があるためには、考慮して解決する必要があります。そうしないと、他のエンジンが使用するシステムよりも優れたシステムになってしまいます。

正直なところ、短期的な解決策の最善の行動は、アセットライブラリを変更して、 addonsディレクトリの下の1つのレイヤーであるプロジェクトにサービスを提供する機能をサポートすることです（下位互換性のために_require_ではありません）。 例えば

godot-tools.level-streamer/
    project.cfg

それ以外の

addons/
    godot-tools.level-streamer/
        project.cfg

このようにして、アドオンの説明で、他のアドオンが必要であることを指定できます。

また、必要に応じて、アドオンのプロジェクトでgitsubmodulesを簡単に使用できるようになります。

それをdeps（たとえば、 dep/ ）に対して行ってから、手動でインストールしたプラグインをルートディレクトリまたはユーザー定義フォルダーに配置するのはどうでしょうか。 そうすれば、依存関係がルートを乱雑にすることはなく、アドオンはどちらかになりますか？

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@ Two-Toneしかし、依存関係に依存関係がある場合はどうなりますか？ 代わりに、depsフォルダーをプラグイン自体のサブフォルダーにするべきではありません。そうすれば、必要に応じて任意の深さに移動できますか？

この依存関係の問題全体がかなり考え抜かれているように感じます。 たぶん、いくつかの簡単なシステムを考え出し、それぞれについて議論したり、投票したりする必要がありますか？ この会話が現在の方向で終わるとは思いません。

そうは言っても...

@willnationsdevそれは機能する可能性がありますが、多くのプラグインが同じ依存関係に依存している場合は、その依存関係の複数のコピーがあり、必要なのは2つだけです。

はい、依存関係の管理は簡単なことではありません。 それ以外の場合npmはそれほど複雑である必要はなく、 yarnを作成する必要もありません。

依存関係をアセットのサブフォルダーとして配置することは、非常に複雑なパスにつながるため、良い考えではないと思います。 2つ以上のアセットが同じ依存関係を持ち、何らかの重複排除が必要になる場合があります。 また、一般的な依存関係であるため、サブフォルダーのサブフォルダーを調べて、どの依存関係がn回使用または複製されているかを確認するよりも、ゲーム開発者がプロ​​ジェクトの依存関係を正確に確認する方がよいと思います。

たとえば、node.js Web開発では、サーバーにのみデプロイされるため、node_modulesが機能する限り、node_modules内にあるものを無視してもかまいません。 ゲームの場合、すべてのコード/アセットを最終的なアプリパッケージにパッケージ化することになり、同じ依存関係をn回複製するのはかなり悪いことです。

これらの問題が、私の最初の提案がアセットに依存関係をまだ定義させないように言った理由ですが、プロジェクトの依存関係をリストし、ユーザーがアセットの依存関係を手動でインストールできるようにする方法があります。
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

アセットに依存関係を定義させる場合、それらはすべて同じレベル（ res://addonsフォルダー）にインストールする必要があると思います。 依存関係のバージョンの競合（2つのアセットは同じアセットに依存しますが、バージョンが異なります）の場合は、常に新しいバージョンを使用するなど、単純な解決策が最適だと思います。

一方、同じアセットの複数のバージョンをインストールできるようにすることで、重複排除とバージョンの競合解決を伴う依存関係管理を本当に実装したい場合は、それでも構いません。 それが本当にしっかりと作られているかのように、それは資産エコシステムの拡大を長期的にサポートすることができるでしょう。 どういうわけか、ゲームプロジェクトに同じアセットの複数のバージョンを含めるというアイデアは好きではありません。 そして、それが正しくなるまでにnpm非常に多くのバージョンが必要だったので（私はまだyarnを好みます）、このタスクを過小評価するべきではないと思います。

依存関係をアセットのサブフォルダーとして配置することは、非常に複雑なパスにつながるため、良い考えではないと思います。
アセットに依存関係を定義させる場合、それらはすべて同じレベル（ res：// addonsフォルダー）にインストールする必要があると思います

私はそれに同意します。 また、アドオンは、他のさまざまなソースやさまざまなフォルダーで必要なバージョンほど多くはなく、標準の場所のプロジェクトに1回存在することをお勧めします。 依存関係は重要ですが、物事を比較的単純に保つために、最大限に細かくするのではなく、中立的な立場を見つけることもできます。

これらの問題が、私の最初の提案で、アセットに依存関係をまだ定義させず、プロジェクトの依存関係を一覧表示し、ユーザーがアセットの依存関係を手動でインストールできるようにする方法があると述べた理由です。

アセットが依存関係を定義している場合、インストールする前にドキュメントを確認したり、すべてのプラグインを確認したりするよりも、主にユーザーにすばやく通知することができます。 そして最終的には、依存関係を同時にダウンロードするオプションがありますが、便宜上です（特に最初からインストールする場合は、とにかくそれらをインストールする必要があります）。 おそらく、依存関係の競合も解決する必要はありません。少なくとも、インストールツールは、依存関係の競合を検出できるかどうかをユーザーに通知できます。

この依存関係の問題全体がかなり考え抜かれているように感じます

@ LikeLakers2適切な依存関係の管理と競合の回避は、重要で難しい問題です。 そのために多くの議論がなされています

この会話が現在の方向で終わるとは思いません。

依存関係がもたらすすべての問題を理解せずにこれを押し通そうとすると、非常に悪い考えになり、さらに多くの問題が発生します。 これは難しい問題であり、時間がかかります。

依存関係のバージョンの競合（2つのアセットは同じアセットに依存しているがバージョンが異なる）の場合、単純な解決策が最適だと思います

@chanon私の考えは単純です。 フォルダに名前を付けたり、テキストドキュメント内の関連するファイルパスを変更したりするのは何が複雑ですか？ これはユーザーにとって1回限りのコストであり、インストールしたもののバージョンが明確になり、記述がかなり簡単になります。

常に新しいバージョンに行くなど

これにより、プラグインの依存関係が更新され、動作が変更されるため、警告なしにプラグインが破損します。 EGプラグイン1と2はどちらもDep1に依存していますが、バージョンが異なります。 プラグイン2は現在の最新バージョンに依存しますが、プラグイン1は最新バージョンとは異なる動作をする古いバージョンに依存します。 プラグイン1が意図したとおりに機能しなくなったか、出荷されなかったバグがあります。

おそらく、依存関係の競合も解決する必要はありません。少なくとも、インストールツールは、依存関係の競合を検出できるかどうかをユーザーに通知できます。

@Zylann次に、yが同じ依存関係の異なるバージョンを使用しているため、ユーザーがxプラグインをインストールできないという問題があります。 それはユーザーにとって良いこととは見なされません

@willnationsdevと@LikeLakers2に同意します

この依存関係の問題全体がかなり考え抜かれているように感じます。 たぶん、いくつかの簡単なシステムを考え出し、それぞれについて議論したり、投票したりする必要がありますか？ この会話が現在の方向で終わるとは思いません。

自転車の脱落が多すぎます。 これはゲームエンジンであり、game-engine-addon-delivery-platformではありません。 各アドオンのディレクトリにベンダーの依存関係があり、それを1日と呼びます。 バージョンの競合や管理、または非効率性を犠牲にしてw/eについてのストレスはありません。 アドオンのユーザーがパフォーマンスに関心がある場合は、GDNativeやモジュールなどのREALパフォーマンスの最適化を検討する立場にある必要があります。 また、アドオンに深い依存関係のグラフがある理由も想像できません。 アドオンが別のアドオンに依存していることがわかる唯一の理由は、アドオンが何らかの方法で拡張されているかどうかです： SweetFpsController -> SweetFpsController w/ flying 。 その場合、エンジンに責任を与えるのではなく、2つのプロジェクトまたはそのユーザーがカップリングを調整する必要があります。

@ Two-ToneプラグインAがバージョン1のXを必要とし、プラグインBがバージョン2のXを必要とする場合、Godotはそれを魔法のように修正しようとすべきではないと思います。 これに対する簡単な解決策は次のとおりです。

• 通常、Xのバージョン2はバージョン1と下位互換性があるはずです。そのため、シンプルに保つ必要があります（プラグインを開発するときの考え方について言及したときに覚えておいてください）。
• 最新バージョンのXを使用できない場合は、プラグインAがそれをサポートするのを待って、前のバージョンをダウンロードします（最新バージョンだけでなく、さまざまなバージョンの取得を処理するために、assetlib APIが必要です。これは難しいことではありません）。 それは改造のようなもので、完璧である必要はありません。
• Xのプラグインメーカーは、Godot 3がリリースされたときと同じように、別のプラグインとしてアップロードします（APIが互換性を損なうため）。 したがって、同じプラグインが2回使用されますが、プラグインが異なるため、実際には同じプラグインにはなりません。それに応じたプラグインも機能します。 プラグイン開発者がフォルダ名を変更するだけでもかまいません。2つのアセットライブラリエントリが必要な場合もありません。

最悪のシナリオでは、これを手動で機能させる必要があります（そして、最終的にはプラグインメーカーとのPR互換性があります）。

そうでない場合は、毎回異なるパスがインストールされている2つのバージョン（更新のたびにすべての参照をねじ込む）、またはパスの動作を変更するためにエンジンにコア変更が追加されている（複雑）必要があります。
単純な依存関係管理を取得できれば、Godotがすでに持っている機能と構造を基本的に使用し（したがって、実装も非常に簡単になるため）、ユーザーが現在持っていることを自動的に実行するので、すでに非常に便利だと思います。とにかく手動で行う。

依存関係の管理は、常に機能し、エンジン（npmなど）の全責任を負うべきものとは考えていません。これは、多くの作業になるためです。 これは主に、既存の機能を使用して現在手作業で行う必要があることの利便性であると考えており、プラグインメーカーはその単純なシステムを念頭に置いて作業をリリースできます。
誰かがこれよりもはるかに進んだシステムをうまく実装できれば、後で行うことができます。これは、上記で説明したことは以前は実行可能であり、ほとんどの場合、assetlibとエディターのみの単純な改善であるためです。

@Zylannこれらのオプションのどれかが私が提案したものよりどのように優れていますか？ また、特定の文字列を検索してテキストを追加することについて、魔法のようなことは何もありません。

オプション1を使用すると、開発者はバージョンの更新によって、それに依存する他のプラグインが壊れないようにする必要があります。これにより、開発者に多くの余分な作業が追加されます。 そのようなもののためのプラグインを開発したいのは誰ですか？

オプション2は、プラグインがまだアクティブに開発されている場合はプラグインが更新されるのを待つか、まったく使用しないため、ユーザーに必要なプラグインを使用しないように強制します。

オプション3は、プラグイン開発者にとって物事をさらに困難にします。

パスが異なる2つのバージョンは難しい問題ではありません。 それらが更新された場合は、どのインストールパッケージに依存関係があるかを確認し、検索を再実行して、それらのパッケージのすべてのスクリプトを（古いバージョン番号を考慮して）置き換え、最後に新しいバージョンを解凍します。

人々はこれを必要以上に複雑にしようとしているように感じます。

適切な依存関係の管理と競合の回避は、重要で難しい問題です。 そのために多くの議論がなされています

@ Two-Tone私が言いたかったのは、それが難しい問題であるとしても、あなたはその問題についてあまりにも熱心に考えているということです。 会話の多く（確かに私の返信を含むので、これは偽善的に聞こえるので失礼します）は、提示されたアイデアの何が悪いのかについてであり、それを変更してより良くするために何ができるかについてではありません予定。 提案されているアイデアには欠点があるだけではありませんね。 誰もが自分の道と自分の道だけを望んでいるようですが、それは問題にはなりません。

依存関係がもたらすすべての問題を理解せずにこれを押し通そうとすると、非常に悪い考えになり、さらに多くの問題が発生します。 これは難しい問題であり、時間がかかります。

私は、いくつかの簡単なアイデアを考え出すことを提案しました。それは、それらを解決し、優れたシステムができたと感じたら決定するという意味です。 私はそれを明確に指摘する必要があるとは思いませんでしたが、あなたはそこに行きます。

この会話が何の進展もなく続いていることにちょっとイライラします。 真剣に。

パスが異なる2つのバージョンは難しい問題ではありません

それだけでは、おそらくそうではありません。 しかし、Godotで特定の時間に同じプラグインの2つのバージョンがあるということは、解決するのが混乱する他のことを意味します。

• あなたのパスはもはやあなたが思っているものではありません/コアに変更を加える必要があります。これはコア開発者にとって主に懸念事項です
• プラグインがカスタムタイプを公開している場合、エディターはどれを表示しますか？
• プラグインがC＃の場合、他のコピーと競合することなくどのようにコンパイルしますか？
• プラグインが自動ロードを登録する場合、どのようにそれらを区別しますか？
• ユーザーがプラグインを使用するデータを作成する場合、どれを使用しますか？
• エディターにUIを表示するのはどれですか？

エンジンに適合するものの簡単な解決策を見つける前に（そして私が考えていなかったものがもっとあるかもしれません）、互換性を壊したりコアの変更を導入したりすることなく、エディターとアセットライブラリの既存のものをすでに改善できると思います。

このスレッドのすべてに+1-プラグインモジュールを拡張し、アセットライブラリの使用を増やすことが方法です

Unityを試して学んだ後、私はこれがどのようなものであるかについてより明確な考えを持っています。

1つ目は、Unityに「パッケージマネージャー」が追加されたことです。これを使用して、ユーザーがインストール/アンインストールするエンジンのコンポーネントを選択できるようになりました。 将来的にはアセットストアにもこれを使用する可能性があるようです。

このようなものは、Godotが「公式アドオン」を使用しながら「膨満感を軽減」できるようにするのに本当に役立ちます。 Unityは、パッケージマネージャーを使用しても非常に肥大化していますが、Godotにパッケージマネージャーがあれば、さらに小さくなる可能性があります。 ただし、「1つのexe」配布方法を使用する必要がある場合があります。

また、通常の「モジュール」は、パッケージマネージャーでインストール/アンインストールするために選択できるように、共有ライブラリ（dll / .soファイル）として構築する必要があります。

プロジェクトとパッケージには、依存するパッケージをリストするマニフェストファイルが必要です。Godot/パッケージマネージャーは、必要なパッケージがインストールされていることを確認します。

パッケージのパブリックレジストリが必要になります。

これにより、コミュニティはGodotの機能を簡単に拡張し、お互いの作業を簡単に構築できるようになります。 コミュニティの発展を大いに促進すると思います。

パッケージマネージャーのアプローチに移行することの全体的なメリットに異議を唱えることはありませんが、まだ決心していませんが、弱点もあることを指摘したいと思います。1つの実行可能ファイルをより統合してうまく機能させることができます。少なくとももっと簡単にテストされました。

パッケージマネージャーを使用すると、プラグインとバージョンごとにテストサーフェスが指数関数的に増加します。 プラグインがほとんど（現在AssetLibにあるような）小さな追加であり、エンジンコアに深く接続されていない場合、これはそれほど悪くはありませんが、エンジンのコア部分を分割するとすぐにそうなります。

Unityは、パッケージのさまざまなバージョン、エディター、または特定のパッケージの組み合わせがインストールされている（またはインストールされていない）場合、あるいはインストールされた順序でさえ、すでに問題、クラッシュ、互換性の問題に直面しています。

これは、依存関係地獄に陥らないように、適切に管理する必要がある多くの追加の複雑さです:)

依存関係地獄に関しては、AppImageのようなものからページを取得し、プラグインディストリビューターにアセット/ファイルの依存関係の管理を任せることで、依存関係の問題を回避してみませんか？ これが私がこの問題をどのように見るかです...

プラグインは、（理想的には）独自の依存関係を持つロジック（カスタムエディター、カスタムノード、ダイナミックリンクライブラリ）またはアセット（モデル、マテリアル、フォント、テクスチャなど）の自己完結型要素である必要があります。 共有された依存関係を理解し​​ようとすることは、人々がそれを好むかもしれないが、それを維持するためにより多くの努力を意味するという難問です。 共有の依存関係を実際に許可する場合は、Steamランタイムと同様にこの問題に取り組み、さまざまなライブラリ、プラグイン、アセットを独自のパッケージとして維持する必要があります。 また、複数のバージョンのサーバーに同じパッケージを複数保存する必要があります。これはメンテナンスの悪夢であり、最新のLinuxディストリビューションが多かれ少なかれパッケージマネージャーから離れているのも当然です。

プラグインは、基本的に、そのプラグインが単独で機能するために必要なすべての要素の単一のtarアーカイブである可能性があります。 それらは、内部にアーカイブされたすべての依存関係を使用して、独自にネイティブに機能する必要があります。 godotはこのファイルを見ると、アーカイブフォルダーのルート内にあるマニフェストファイルをチェックします。 このマニフェストには基本情報（名前、説明、godotバージョン、アイコン、作成者）を含めることができますが、次のようなものも含める必要があります：update-info（プラグイン開発者が管理する最新バージョンをダウンロードするためのリンク）godotが自動的に更新するために使用できるプラグイン（ユーザー権限あり）、project_website（ユーザーがパッケージのソースをすばやく見つけられるようにするリポジトリまたはWebサイトへのリンク）、およびclass_names（拡張可能で、スクリプトに使用できるこのアドオン内のクラスのリスト）。内部プラグインファイルへの相対パスを使用して依存関係として使用するアドオン。

プラグイン内でプラグインを許可すると、依存関係の問題は（多かれ少なかれ）解決されます。 同じライブラリの異なるバージョンは異なるディレクトリパスにあり、特定のフォークでは異なる「パス」として扱われる可能性があります。 もちろん、このシステムの問題は、特定のディスクに多くの重複情報が存在することです。 ただし、ゲームをパッケージ化する場合、godotは理想的にはすべてのプラグインディレクトリを調べ、チェックサムを介して一致するファイル参照をマージできます（これにはtarで表されるファイル構造を含めることができますか？）。 このように、2つのファイルが同一である場合、godotは、参照を1つのファイルにマージすることにより、最終的な出力バイナリを最適化します。

これは、これほど複雑な問題の解決策としてはあまりにも素朴すぎると思いますが、カスタムフォントパッチのために、最近プラグインシステムについて考えていました。 最高のユーザーエクスペリエンスは、依存関係を気にする必要がないものだと思います。開発者は、自分の依存関係の管理に注意を払う必要があります。 これにより、ユーザーの管理が容易になります。プロジェクトでは、アドオンをファイルシステムドック内の単一ファイルとして表すことができ、右クリックして追加のオプション（ extract files （開発用）、 update plugin ）を取得できます。 for easy community organization ））にアクセスし、特定の'コンテナー'（ extends "[path-to-addon-tar]://ClassName" ）内のクラスを参照します。

私の2セントだけで、私が考えている方法にもいくつかの欠陥があると確信していますが、それは興味深い解決策であり、メンテナンスの必要性を減らすための適切な方法でもあります。 Godotチーム。

前の2セントに基づいてわずか2セント（これで4ミルになりますか？）：
.tarアーカイブは、ほとんどのユーザー（つまり、Windowsユーザー）には少し馴染みがないので、サポートがいくらか広いので、 .zipアーカイブを使用する方がよいと思います。

そうは言っても、Godot独自の.pck形式でプラグインを配布するのはどうでしょうか。 私にはいくつかの短所があります（ほとんどのアプリケーションで認識されないなど）が、それはそれをより標準的にして使用するチャンスかもしれません。

.tarアーカイブは、ほとんどのユーザー（ええと、Windowsユーザー）には少し馴染みがないので、サポートがいくらか広いので、.zipアーカイブを使用する方が良いかもしれません。

そうは言っても、プラグインをGodot独自の.pck形式で配布するのはどうでしょうか。 私にはいくつかの短所があります（ほとんどのアプリケーションで認識されないなど）が、それはそれをより標準的にして使用するチャンスかもしれません。

確かに、私は主に、一般的なパックアーカイブタイプの例として.tarを意味していました。 godotの.pck形式を使用できる可能性があります。

圧縮を提供し、標準形式であるため、ZIPを使用してみませんか？

@Calinou同意します。 .pckファイルを使用する必要がある場合は、プラグインをバンドルして使用するために好みのパッキングツールを使用するだけでなく、GodotEngineを使用してパックする必要があります。 GitHubは、リポジトリを.zipファイルとしてダウンロードし、Godotプラグインの最大のコレクションを格納します。

ここで同意します。 別のファイルタイプを作成する必要はないと思います。 Zipファイルは非常にうまく機能しているようで、アセットライブラリからGodotインターフェイスを使用してインストールするか、手動でダウンロードするかを選択できます。 .pckファイルではその選択はできません。

私の理想的な世界では、 https ：//godotengine.org/downloadに2つのダウンロードボタンが必要です。

• reduzの3つの要件を満たす1つの洗練された最低限のダウンロード、および
• いくつかの品質管理を超えた、承認され定期的に保守されているすべてのプラグインを含む1つの肥大化したダウンロード。したがって、それらのAPIは、少なくともコアと最小バージョンのAPIと同様に機能することを知っています。

さらに理想的：
選択して混ぜます。 最低限のものをダウンロードすると、最小バージョン+プラグイン「テーマ」を選択できます。 これは、一般的なユースケースに必要な一般的なプラグインのコレクションです。 （たとえば、2DPixelart、3D FirstPersonShooter、3D ThirdPerson、RTS、RPG、2.5Dゲーム、2DCutout、Rougelike、ManagementSim、Sidescroller、Eventpackage、Shaderpackage、Scriptpackage、Assetpackaceなど）。 したがって、エンジンを起動すると、重要なプラグインがすでにインストールされており、すぐに使用できるようになっています。承認されているため、プラグインが機能することがわかります。
より上級のユーザーは、必要がないことがわかっている場合は、それらのテーマコレクション内の個々のプラグインのチェックを外したり、2つ以上のプラグインテーマを組み合わせたり、承認されたプラグインのプールからテーマに単一のプラグインを追加してカスタムパッケージを作成したりできます。

理想的には、結果はhttps://godotengine.org/downloadがそれらの選択肢から_オンザフライで1つのダウンロードリンク_を作成することになるでしょう。

なんで？ これは、チームやグループで作業する人、複数のコンピューターにデプロイする必要がある学校の教育者や教師、チュートリアルに従い、家庭教師と同じ構成が必要な人、個人にとって、大幅な時間の節約と品質保証になるためです。誰もが使用しているわけではないが、一般的に使用されているもののために開発チームによって承認された公式プラグインが1つあるので、GithubとRedditを何日も掘り下げて、必要なものを見つける必要はありません。彼らが見つけた6つのうちのオプション。

ワンクリックのベア最小ダウンロードは、サイズを気にしないが最大機能でエンジンが何を実行できるかを確認したい最大機能のダウンロードと同様に、小さなサイズが必要な人のためにまだ存在しているはずです。

より簡単な解決策は、エディターを初めて実行するときに、追加の[公式のみ？]プラグインをインストールするように依頼することです。 現在、プロジェクトリストが空の場合にAssetLibを開くオプションがあります。 Godotを初めて実行する場合は、公式プラグインをインストールするためのダイアログポップアップを表示してみませんか？

https://github.com/godotengine/godot-proposals/issues/142、https://github.com/godotengine/godot-proposals/issues/577、https：//github.com/godotengine/に賛成して締めくくりますgodot-proposals / issues / 607 、機能の提案がGodotの提案リポジトリで追跡されるようになりました。

aaronfrankeから編集： https ：//github.com/godotengine/godot-proposals/issues/554も参照してください