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

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

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

Object: 究極の軽量オブジェクトであり、オリジナルのオブジェクトは手動メモリ管理を使用する必要があります。そうは言っても、Node クラスよりも軽い独自のカスタムデータ構造、さらにはノード構造を作成することはそれほど難しくありません。
- 例: Tree ノードを参照してください。任意の数の行と列を持つコンテンツテーブルの高度なカスタマイズをサポートします。ただし、視覚化の生成に使用するデータは、実際には TreeItem オブジェクトのツリーです。
- 利点: APIをより小さなスコープのオブジェクトに単純化すると、アクセシビリティが向上し、改善のための反復時間が改善されます。ノードライブラリ全体を扱う代わりに、ノードが適切なサブノードを生成・管理するための簡潔なオブジェクトセットを作成することができます。
注釈

それらを扱うときは注意が必要です。オブジェクトを変数に保存できますが、これらの参照は警告なしに無効になる可能性があります。たとえば、オブジェクトの作成者がどこからでもオブジェクトを削除することを決定した場合、その次にオブジェクトにアクセスしたときにエラー状態が発生します。
RefCounted: オブジェクトよりも少しだけ複雑です。自身への参照を追跡し、それ自体への参照がそれ以上存在しない場合にのみ、ロードされたメモリを削除します。これらは、カスタムクラスでデータが必要になるほとんどの場合に役立ちます。
- 例: FileAccess オブジェクトを参照してください。通常のオブジェクトと同じように機能しますが、自分で削除する必要がありません。
- 利点: オブジェクトと同じです。
Resource: Referenceよりも少しだけ複雑です。それらは、Godotリソースファイルとの間でオブジェクトプロパティをシリアル化/逆シリアル化(つまりセーブおよびロード)する固有の機能を備えています。
- 例: Scripts、PackedScene(シーンファイル用)、および AudioEffect クラスの各種型などが挙げられます。これらはいずれも保存および読み込みが可能であるため、Resource を拡張しています。
- 利点: リソースが従来のデータストレージ方法より優れている点については、すでに多くが述べられています。特にノードと比べてリソースを選ぶ文脈では、その主な利点は インスペクタとの互換性 にあります。Object/RefCounted とほぼ同じ軽量性を持ちながらも、インスペクタでプロパティの表示やエクスポートが可能です。これにより、使用性の面ではサブノードのような役割を果たしつつ、多数のリソースやノードをシーンに配置する場合にはパフォーマンスを向上させることができます。