Anwendung ScriptableObjects

[Bradley]

Ich bin mir nicht sicher ob ich Plane die ScriptableObjects richtig anwenden will:

Mein Spiel hat verschiedene "Module" mit dem man Raumschiffe ausrüsten kann.
Diese Module, z.B. Waffen oder Panzerung, will ich über ScriptableObjects definieren. 

Wie hier zum Beispiel:

public class Module : ScriptableObject
{
	private int iD;
	private float mass;
	private string description;
	private blueprint bluePrint;
	private int StructurActual;
	private int StructurMax;
}

Damit hätten ich die Werte dieser Module recht einfach irgendwo gespeichert.
Aber wie bekomme ich diese Werte Sinnvoll in meinen Schiffsklasse?

Soll ich einfach das Scriptable Object referenzieren in der Schiffsklasse und dann zuweisen?
Oder soll ich lieber Parallel in der Schiffsklasse die gleichen Variabel definieren und wenn ein solches Modul zugewiesen wird, z.b. durch bauen oder designen im Spiel, die Werte des ScriptableObjects zuweisen?

[Sascha]

Moin!

ScriptableObjects sind genau dazu da, eine Identität und oder Daten zu haben, die im Editor eingestellt und dann in den Build mitgenommen werden. Wenn man das Konzept ein bisschen streckt, dann kann man auch dynamische Daten drin haben. Aber auch das ist nur sinnvoll, wenn man auch die Identität nutzt.

Falls das mit der "Identität" nicht so klar ist, so als Beispiel: Du kannst ein komplett leeres ScriptableObject nutzen, um Spielfiguren in Teams einzuteilen. Zwei Figuren, die dasselbe "Team-SO" referenzieren, sind im selben Team und machen sich gegenseitig keinen Schaden. Das meine ich mit Identität.

Wenn ich jetzt aber so Felder wie "iD" und "StructurActual" sehe, dann nehme ich an, dass du hier ein Laufzeit-Objekt repräsentieren willst. Also ein Objekt, dass der Spieler während des Spiels erstellt. Zum Beispiel, indem er es im Shop kauft oder so. Das geht zwar, macht aber so seine Problemchen. Da du aber wiederum Felder wie "Description" hast, die recht eindeutig Daten beinhalten, die du im Editor eingibst, sind ScriptableObjects schon gut.

Ich würde empfehlen, das aufzuteilen. Eine ScriptableObject-Klasse beinhaltet die statischen Daten, die du im Editor eingibst:

public class ModuleInfo : ScriptableObject
{
  public string name;
  public string description;
  public int maxIntegrity;
}

Und eine nicht-SO-Klasse kannst du zur Laufzeit instanziieren, um Laufzeit-Objekte zu repräsentieren:

class Module
{
  public readonly ModuleInfo moduleInfo;
  public int integrity;
}

Wie du siehst, referenziert es ein ModuleInfo-Objekt, das die statischen Daten beinhaltet. So kannst du auch wunderbar beliebig viele Triebwerke (also gleichartige Module) erlauben. Das ist wäre immer ein bisschen schwer, wenn du alle potentiellen Module im Voraus im Editor anlegen müsstest.

[Bradley]

Ah grundsätzlich war ich dann wohl auf dem richtigen Weg, nur die Feinheit hat da noch gefehlt.
Danke Sascha