コンテンツを追加/削除/移動するには、隣接するレコードを移動する必要があります(スペースを空ける/スペースを塗りつぶす作業)。末尾からは追加/削除が速い。任意の位置からは追加/削除が遅い。先頭からは追加/削除が最も遅い。先頭から複数の挿入/削除を行う場合には...配列の並びを反転します。末尾から配列の変更をするループ処理を実行します。配列の並びを再反転します。この方法なら、操作の最中に配列の約1/2を平均してN回(線形時間)コピーをする代わりに、配列全体の2回のコピーだけで済みます(依然として一定の時間がかかり、遅いですが)。位置で指定するので最速。0番目、2番目、10番目のレコードなどを要求できますが、必要なレコードを指定することはできません。配列の開始位置から目的のインデックスまでの1回の追加操作。値のインデックス/位置を識別します。配列を反復処理し、一致するものが見つかるまで値を比較する必要があります。パフォーマンスは、徹底的な検索が必要かどうかによっても異なります。素人のユーザーはこれに不慣れです。編集のたびに配列を再ソートし、順序に対応した検索アルゴリズムを作成することで完了します。Variant>``として実装します。エンジンは、キーと値のペアの巨大な配列(1000レコードに初期化された)を保存します。値にアクセスしようとすると、まず値がキーになります。次に、キーをハッシュします。キーを数値に変換します。「ハッシュ」は配列へのインデックスになり、OHM(訳注:オブジェクト・ハンドル・マネージャー?)は値にマップされたキーの概念的な「テーブル」内の値をすばやく検索できます。ハッシュは、キーの衝突の可能性を減らすためのものです。発生した場合、テーブルは以前の位置を考慮した値の別のインデックスを再計算する必要があります。これにより、メモリと若干の運用効率が犠牲になりますが、全体として、すべてのレコードに定数時間でアクセスできます。すべてのキーを任意の回数ハッシュします。ハッシュ操作は定数時間であるため、ハッシュ計算の数がテーブルの密度に依存しすぎない限り、アルゴリズムで複数の処理を行う必要がある場合でも、処理は高速になります。話は続きます...巨大なサイズのテーブルを保持します。1000個のレコードから始まり、テーブルに散在する未使用メモリの大きなギャップを強制する理由は、ハッシュの衝突を最小限に抑え、アクセスの速度を維持するためです。おわかりになると思いますが、Dictionaryは配列ではないタスクに特化しています。運用の詳細の概要は次のとおりです。マップのハッシュの内部ベクトルを反復処理し、各キーを返します。指定されたキーをハッシュします。1回の追加操作を実行して、適切な値(配列の開始+オフセット)を検索します。移動はこれらの2つです(1つは挿入、1つは消去)。マップは、その機能を維持するためにいくつかのメンテナンスを行う必要があります:レコードの順序付きリストを更新します。テーブルの密度により、テーブルの容量を拡張する必要があるかどうかを判断します。Dictionaryは、ユーザーがキーを挿入した順序を記憶しています。これにより、信頼性の高い反復処理を実行できます。キーによる検索と同じです。挿入/消去/移動と同じです。値のキーを識別します。レコードを反復処理し、一致が見つかるまで値を比較する必要があります。Godotはすぐにはこの機能を提供しないことに注意してください(これらの機能はこのタスク用ではないため)。コンテンツの動的なコンテナーとして実装します。Objectは、質問が行われるとデータソースに対してクエリを実行します。<class_ClassDB>`を要求します。記事で、オブジェクトとは何か、そしてそれらがどのように機能するかについての詳細を見つけることができます。ここで重要な点は、オブジェクトのタスクの複雑さです。反復ループとHashMapのルックアップを実行します。クエリはオブジェクトの継承階層サイズに依存する線形時間操作です。Objectクエリを実行するクラス(現在のクラス)で何も見つからない場合、リクエストはObjectの継承元の基本クラスへと次々に受け渡されます。両方の代替手段よりも遅くなる理由です。開発者がスクリプトAPIの速度が遅いと言及するのは、この一連のクエリの参照についてです。アプリケーションが何かを見つける場所を正確に知っているコンパイル済みのC++コードと比較すると、スクリプトAPIでは操作にかかる時間が大幅に長くなることは避けられません。アクセスを行う前に、関連するデータのソースを見つける必要があるからです。GDScriptが遅いのは、実行するすべての操作がこのシステムを通過するためです。C#は、より最適化されたバイトコードにより、一部のコンテンツをより高速に処理できます。C#スクリプトがエンジンクラスのコンテンツを呼び出す場合、またはスクリプトが外部の何かにアクセスしようとする場合、このパイプラインを通過します。C++はさらに進んで、デフォルトですべてを内部に保持します。外部構造への呼び出しは、スクリプトAPIを経由します。C++では、スクリプトAPIに公開するメソッドを登録するのは手動のタスクです。++クラスがAPIを使用してそれらを見つけます。使用すると、より洗練された構造を作成する機能が提供されます。データを抽象化して、内部データ構造の変更に応じて外部APIが変更されないようにすることができます。シグナルを持ち、反応的な動作を可能にします。スクリプトとエンジンクラスが定義するデータに関しては信頼できるデータソースです。プロパティは期待する値を保持していない場合がありますが、プロパティがそもそも存在するかどうかを心配する必要はありません。同様のデータ構造をすでに念頭に置いている場合、既存のクラスから拡張すると、データ構造を構築するタスクがはるかに簡単になります。すべてのユースケースを満たしているわけではありません。使用すると、ユーザーはさらに特殊なデータ構造を作成することもできます。これを使用して、独自のリスト、バイナリ検索ツリー、ヒープ、スプレー木、グラフ、素集合、およびその他のオプションのホストを設計できます。「ツリー構造にNodeを使用しないのはなぜですか?」と尋ねるかもしれません。Nodeクラスには、カスタムデータ構造に関係のないものが含まれています。そのため、ツリー構造を構築するときに、独自のノードタイプを構築すると役立ちます。}}ここから、想像力によってのみ制限される特定の機能を備えた独自の構造を作成できます。string¶ほとんどの言語には、列挙型オプションがあります。GDScriptでも同様ですが、他のほとんどの言語とは異なり、整数値または文字列を列挙値に使用できます。簡単な答えは、「どちらが快適か」です。これは、(C++、C#等の)一般的なGodotスクリプトにはない、GDScript固有の機能です。この言語はパフォーマンスよりも使いやすさを優先しています。他の言語の規則を維持したい場合は、整数を使用する必要があります。整数値の使用に関する主な問題は、列挙値を印刷したいときに発生します。整数の列挙型を出力するには、各列挙型に対応する文字列値をマップする辞書(Dictionary)を作成する必要があります。列挙型を使用する主な目的が値を出力することであり、それらを関連する概念としてグループ化する場合、それらを文字列として使用することは理にかなっています。すれば、印刷で実行するための別個のデータ構造は不要です。答えは、新しいGodotユーザーにはすぐにはわからないかもしれません。ループとして描画するテクスチャです。ユーザーは次の操作ができます...テクスチャの各セクションを移行する速度(fps)。テクスチャに含まれる領域の数(フレーム数)。指定されたレートで領域を順番に描画します。良いニュースは、これはエンジンの部分に余分なロジックを含みないことです。悪いニュースは、ユーザーがほとんど制御できないことです。オブジェクトとは異なります。ノードを作成できます。統合することで、単一のバッチ描画呼び出しですべてをレンダリングできる、多くの自動アニメーション背景を作成できます。シーケンスを作成し、アニメーションの反復、速度、領域のオフセット、および方向を制御できます。これにより、2Dフレームベースのアニメーションの制御に適しています。ノードを使用する必要があります。次のようなより複雑な2Dアニメーションシステムを設計する場合に使用する必要があるツールでもあります。実行時にスプライトの幾何学変換を編集します。スプライトのテクスチャの領域を定義し、スケルトンをリギングします。次に、ボーンのアニメーション化を行い、ボーンの相互関係に応じてテクスチャを伸縮させます。必要ですが、アニメーションを組み合わせてブレンドすること、つまり、これらのアニメーション間のスムーズな移行を可能にすることにも役立ちます。アニメーション間には、オブジェクトに対して計画している階層構造もあります。脚光を浴びるケースです。見つけることができます。