ノードの使用をさけるべき場合といろいろな方法

ノードは安価に作成できますが、制限があります。プロジェクトには、すべてで処理を行う数万のノードが含まれている場合があります。ただし、動作が複雑になるほど、それぞれの負荷がプロジェクトのパフォーマンスに大きく影響します。

Godot には、ノードが使用するAPIを作成するための、より軽量なオブジェクトが用意されています。プロジェクトの機能を構築する方法を設計する際には、これらのオプションを念頭に置いてください。

  1. Object: 究極の軽量オブジェクトであり、オリジナルのオブジェクトは手動メモリ管理を使用する必要があります。そうは言っても、Node クラスよりも軽い独自のカスタムデータ構造、さらにはノード構造を作成することはそれほど難しくありません。

    • 例: Tree ノードを参照してください。任意の数の行と列を持つコンテンツテーブルの高度なカスタマイズをサポートします。ただし、視覚化の生成に使用するデータは、実際には TreeItem オブジェクトのツリーです。
    • 利点: APIをより小さなスコープのオブジェクトに単純化すると、アクセシビリティが向上し、反復時間が改善されます。 ノードライブラリ全体を使用するのではなく、ノードが適切なサブノードを生成および管理できるオブジェクトのの省略されたセットを作成します。

    注釈

    それらを扱うときは注意が必要です。オブジェクトを変数に保存できますが、これらの参照は警告なしに無効になる可能性があります。たとえば、オブジェクトの作成者がどこからでもオブジェクトを削除することを決定した場合、その次にオブジェクトにアクセスしたときにエラー状態が発生します。

  2. Reference: オブジェクトよりも少しだけ複雑です。自身への参照を追跡し、それ自体への参照がそれ以上存在しない場合にのみ、ロードされたメモリを削除します。これらは、カスタムクラスのデータが必要になるほとんどの場合に役立ちます。

    • 例: File オブジェクトを参照してください。それ自体を削除する必要がないことを除いて、通常のオブジェクトと同じように機能します。
    • 利点: オブジェクトと同じです。
  3. Resource: Referenceよりも少しだけ複雑です。それらは、Godotリソースファイルとの間でオブジェクトプロパティをシリアル化/逆シリアル化(セーブおよびロード)する固有の機能を備えています。

    • 例: スクリプト、PackedScene(シーンファイル用)、および各 AudioEffect クラスのような他のタイプ。これらはそれぞれセーブおよびロードができるため、Resourceから拡張されます。
    • 利点: Resource の従来のデータ保存方法に対する利点については、既に語られています。ただし、ノードよりもリソースを使用する場合の主な利点は、インスペクタの互換性です。Object/Referenceとほぼ同じくらい軽量ですが、インスペクタでプロパティを表示およびエクスポートできます。これにより、ユーザビリティの面でサブノードによく似た目的を果たすことができますが、シーンにそのようなリソース/ノードが多数ある場合はパフォーマンスも向上します。