Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Wann und wie man es vermeidet, Nodes für alles zu verwenden¶

Nodes sind sparsam mit Ressourcen, aber selbst sie haben ihre Grenzen. Ein Projekt kann zehntausende von Nodes haben, die alle irgendetwas tun.Je komplexer ihr Verhalten jedoch ist, desto größer ist die Belastung, die jeder einzelne Node für die Performace eines Projekts darstellt.

Godot bietet leichtgewichtigere Objekte zum Erstellen von APIs, die von Nodes verwendet werden. Behalten Sie dies als Möglichkeit im Hinterkopf, wenn Sie festlegen, wie Sie die Features Ihres Projekts erstellen möchten.

Object: Das ultimative Lightweight-Objekt, das ursprüngliche Object muss seinen Speicher manuell verwalten. Trotzdem ist es nicht allzu schwierig, eigene benutzerdefinierte Datenstrukturen zu erstellen, selbst Nodestrukturen, die auch leichtgewichtiger sind als die Node-Klasse.
- Beispiel: Siehe den Node Tree. Er unterstützt ein hohes Maß an Personalisierung für ein Inhaltsverzeichnis mit einer beliebigen Anzahl von Zeilen und Spalten. Die Daten, die es zum Generieren der Visualisierung verwendet, sind tatsächlich ein Baum von TreeItem-Objects.
- Vorteile: Durch die Vereinfachung der API auf Objekte mit kleinerem Gültigkeitsbereich wird die Zugänglichkeit und die Iterationszeit verbessert. Anstatt mit der gesamten Node-Bibliothek zu arbeiten, wird eine kleinere Menge von Objects erstellt, aus denen ein Node die entsprechenden Unter-Notes generieren und verwalten kann.
Bemerkung

Man sollte vorsichtig damit umgehen. Man kann ein Object in einer Variablen speichern, aber diese Referenzen können ohne Warnung ungültig werden. Wenn der Ersteller des Objekts beispielsweise beschließt, es aus dem Nichts zu löschen, wird beim nächsten Zugriff ein Fehlerstatus ausgelöst.
RefCounted: Nur ein wenig komplexer als Object. Sie tracken Referenzen auf sich selbst und geben den geladenen Speicher erst frei, wenn keine weiteren Referenzen auf sich selbst existieren. Sie sind in den meisten Fällen nützlich, wenn man Daten in einer eigenen Klasse benötigt.
- Beispiel: Siehe das FileAccess-Objekt. Es funktioniert genau wie ein normales Object, außer dass man es nicht selbst löschen muss.
- Vorteile: die gleichen wie bei Object.
Resource: Nur wenig komplexer als RefCounted. Sie bringen die Fähigkeit mit, ihre Objekteigenschaften in/aus Godot-Ressourcendateien zu serialisieren/deserialisieren (d. h. zu speichern und zu laden).
- Beispiel: Skripte, PackedScene (für Szenendateien) und andere Typen wie die verschiedenen AudioEffect-Klassen. Jedes dieser Elemente kann gespeichert und geladen werden, daher stellen Sie eine Erweiterung von Resource dar.
- Vorteile: Es wurde bereits viel über die Vorteile von Resource gegenüber traditionellen Datenspeichermethoden gesagt. Im Zusammenhang mit der Verwendung von Resources gegenüber Nodes liegt ihr Hauptvorteil jedoch in der Inspektor-Kompatibilität. Obwohl sie fast so leichtgewichtig sind wie Object/RefCounted, können sie dennoch Propertys im Inspektor anzeigen und exportieren. Dadurch erfüllen sie bezüglich Benutzerfreundlichkeit einen ähnlichen Zweck wie Unter-Nodes, verbessern aber auch die Performance, wenn man plant, viele solcher Resources/Nodes in seinen Szenen zu haben.