Library)を使わないのですかなぜGodotは例外処理を使わないのですか?GodotがRTTI(実行時型情報)を強制しないのはなぜですか?GodotがユーザーにDoD(データ指向設計)の実装を強制しないのはなぜですか?Godotの開発をサポートしたり、貢献したりするにはどうすればいいですか?誰がGodotで働いていますか。問題Xにアプローチするときに、戦略をYにするかZするかについて悩んだことはありませんか?この記事では、これらのジレンマに関連するさまざまなトピックについて説明します。メソッドが存在します。処理を前もって行い、パフォーマンスに敏感なコードの途中で、リソースの読み込が発生することを回避するために、できるだけ早くリソースを読み込みます。メソッドは、loadステートメントに到達したときにのみリソースをロードします。リソースをインプレースでロードするため、速度低下を引き起こす可能性があり、敏感なプロセスの途中でも発生します。エイリアスでもあり、すべてのスクリプト言語からアクセスできます。より、スクリプトは、スクリプトを読み込んだ瞬間にすべての読み込みを処理できます。便利ですが、それを望まない場合もあります。これらの状況を区別するために、考慮できることがいくつかあります。スクリプトがいつロードされるかを判断できない場合、リソース、特にシーンまたはスクリプトをプリロードすると、予期しない追加のロードが発生する可能性があります。これにより、元のスクリプトのロード操作に加えて、意図しない可変長のロード時間が発生する可能性があります。シーンのエクスポートされた初期化など、他の何かが値を置き換えることができる場合、値をプリロードしても意味がありません。スクリプトを常に独自に作成する場合、この点は重要な要素ではありません。別のクラスリソース(スクリプトまたはシーン)のみを「インポート」したい場合は、多くの場合、プリロードされた定数を使用することが最善のアクションです。使用して初期化する必要があります(そして、後で初期化されることはありません)。スクリプトが非常に多くの依存関係を必要とし、あまり多くのメモリを消費したくない場合、状況の変化に応じて実行時にさまざまな依存関係をロードおよびアンロードすることができます。リソースを定数にプリロードする場合、これらのリソースをアンロードする唯一の方法は、スクリプト全体をアンロードすることです。拡張型として、リソースがメモリから自分自身を削除します)。大きなレベルを作成している場合、どの状況が最も適切ですか?レベルを1つの静的な空間として作成する必要がありますか?または、レベルを断片的にロードし、必要に応じてワールドのコンテンツをシフトする必要がありますか?そうですね、簡単な答えは、「パフォーマンスにそれが必要な場合」です。速度よりメモリの最適化を優先するか、それとも逆か?素朴な答えは、すべてを一度にロードする静的レベルを使用することです。プロジェクトによっては、大量のメモリを消費する可能性があります。ユーザーのRAMを浪費すると、コンピュータが同時に実行しようとする他のすべてのプログラムが、低速化または完全にクラッシュしてしまいます。何があっても、大きなシーンを小さなシーンに分割する必要があります(資産の再利用性を高めるため)。開発者は、リソースとノードの作成/ロード、削除/アンロードをリアルタイムで管理するノードを設計できます。大規模で多様な環境や手続き的に生成された要素を持つゲームは、多くの場合、メモリの無駄を避けるためにこれらの戦略を実装します。裏を返せば、動的システムのコーディングはより複雑です。多くのプログラムされたロジックを使用するため、エラーやバグが発生する可能性があります。注意しないと、アプリケーションの技術的負債を膨らませるシステムを開発してしまいます。そのため、最良のオプションは...小さなゲームには静的レベルを使用する。中規模または大規模のゲームでは、時間/リソースが確保できる場合は、ノードとリソースの管理をコーディングできるライブラリまたはプラグインを作成します。使いやすさと安定性を改善するために時間の経過とともに改良されれば、プロジェクト全体で信頼性の高いツールに進化する可能性があります。コーディングスキルはあるが、コードを絞り込むための時間やリソースは持っていないため、中規模/大規模ゲームの動的ロジックをコーディングします(ゲームを完成させる必要があるので)。後でリファクタリングして、コードをプラグインにアウトソースできます。ドキュメントを参照してください。