Unity ScriptableObjects: gemeinsame Definitionen und individueller Laufzeitzustand

Zuerst die Zuständigkeit klären

Eine Waffendefinition und eine Waffe, die ein Charakter gerade trägt, sind unterschiedliche Arten von Daten. Werden sie vermischt, kann die Änderung der Munition eines Charakters alle Charaktere betreffen, die dasselbe Asset verwenden. Vor der Wahl eines Unity-Containers entscheiden, ob ein Wert zu einer wiederverwendbaren Definition, zu einer einzelnen gespawnten Instanz oder zu einem gespeicherten Spielerprofil gehört. Jeder Kategorie einen eindeutig identifizierbaren Verantwortlichen zuweisen.

Was ein Asset teilt

Ein ScriptableObject kann Daten unabhängig von Szenenkomponenten halten. Mehrere Objekte können auf dasselbe Asset verweisen und teilen sich damit dessen Werte, statt jeweils eigene Kopien zu speichern. Das eignet sich für vorgegebene Konfiguration, macht das referenzierte Objekt aber nicht unveränderlich. Das Unity-6.0-Handbuch beschreibt diese Rolle als gemeinsamer Datenspeicher. [1]

Eine bewusste Grenze ziehen

Von Designern festgelegte Werte hinter einer lesenden Schnittstelle bereitstellen und den Zustand pro Instanz separat initialisieren. Für Munition, Cooldown-Timer und aufsummierten Schaden genügt oft eine gewöhnliche Laufzeitklasse. Braucht ein Laufzeitobjekt ausdrücklich die Identität eines ScriptableObject, erzeugt CreateInstance eine neue Instanz; Object.Instantiate klont ein bestehendes Objekt. [2][3] Anhand der eigenen Initialisierungsregeln entscheiden, welcher Weg passt, statt beide als austauschbare Arten des Asset-Ladens zu behandeln.

Beispiel: zwei Leuchtraketenwerfer

Angenommen, eine Leuchtraketen-Definition enthält eine Kapazität von 4, eine Nachladedauer von 2 Sekunden und eine Projektilreferenz. Zwei gespawnte Werfer lesen beide diese Definition. Jeder Werfer startet mit eigenem Munitionswert 4 und eigenem Nachlade-Timer. Feuert Werfer A, sinkt dessen Munition auf 3; Werfer B bleibt bei 4. Eine Balancing-Änderung an der gemeinsamen Nachladedauer kann gewollt beide Werfer betreffen, sobald sie die Konfiguration das nächste Mal lesen. Das Beispiel unterscheidet live gelesene Konfiguration von Werten, die beim Spawn kopiert werden: Pro Feld eine Regel wählen und dokumentieren. Die Kennung der Definition und den veränderlichen Zustand des Werfers speichern und den Werfer anschliessend über einen expliziten Ladepfad rekonstruieren.

Grenzen und Prüfungen

Ein Klon garantiert nicht, dass jedes referenzierte Asset ebenfalls in eigenem Besitz ist. Verschachtelte Referenzen prüfen, bevor Schreibzugriffe auf deren Inhalt erlaubt werden. Festlegen, wer temporäre Unity-Objekte zerstört und wer den Zustand zwischen Spielsitzungen zurücksetzt. Speichern als eigene Anwendungsfunktion behandeln; die Änderung eines Objekts im Arbeitsspeicher ist kein dauerhaftes Speicherformat. Ein sinnvoller Test erzeugt zwei Instanzen, verändert nur eine und prüft sowohl deren Zustand als auch die ursprüngliche Definition. Den Test nach einem Szenen-Reload und nach einem frischen Anwendungsstart wiederholen, um unbeabsichtigte Abhängigkeiten vom Editor-Zustand aufzudecken.

Quellen

1. ScriptableObject data assets — Unity Technologies.
2. ScriptableObject.CreateInstance — Unity Technologies.
3. Object.Instantiate — Unity Technologies.