spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hey Leute,
Mal wieder eine Frage von mir die mir beim basteln mit Unity gekommen ist:

Sind ScriptableObjects in relativ großer Anzahl schlecht für die Performance (oder egal) ?

Derzeit verwende ich etliche Lists welche Klassen beinhalten (z.B. Items), diese können via EditorScripts editiert werden. Das habe ich hauptsächlich gemacht um Editor Scripts zu üben. Jetzt muss ich feststellen das mir der Aufbau eigentlich nicht taugt bzw. das es überhaupt nicht nötig ist. Stattdessen könnte man für jedes Item auch ein Scriptable Object verwenden und dieses beim Programmstart in die Listen laden.

Das wäre jetzt natürlich ein riesen Umbau aufwand. und genau an der stelle würde mich mal eure meinung interessieren (unabhängig vom Aufwand meines Projekt).

Sind ScriptableObjects in größerer Anzahl noch performant oder ist von der Idee abzuraten?

Danke (hoffe ich kann bald mal was retoure hier beitragen)

-Weaver

hi Schorsch,
ja du hast voll und ganz recht. im endeffekt müsste ich den inhalt ScriptableObjects beim spielstart in die Liste laden was dann während der runtime exakt das gleiche wäre wie meine bisherige Lösung (eine liste mit instanzen).

Es wäre also wenn dann beim spielstart unperformant aber nicht während des spiels.

aber könnte ja sein das sich da jemand besser auskennt, ich höre alles mögliche (resources load sei auch schlecht für die performance und so weiter).

Ist ein RPG, also wären es dementsprechend viele Items (theoretisch).

Werds wohl mal testen.

Im asset store gibts viele die das so machen, aber auch sehr viele die es eben nicht so machen.

Danke euch beiden,
ich sollte wohl eh nicht soviel auf derart Überlegungen geben und einfach weitermachen (man demotiviert sich sonst nur selbst). Denke mal performance ist wenn dann erst im fortgeschrittenen stadium ein problem (wenn überhaupt).

Mal sehen ob ichs umbaue, lässt sich dann leichter bedienen/erweitern - ginge aber auch so.

Ich poste demnächst mal einen Thread über mein projekt

hier also nochmal ein kleines update über mein fortkommen:

ich habe jetzt begonnen mal eine klasse testweise in meinem spiel umzubauen und das ergebnis ist wesentlich besser als vorher. im anhang seht ihr zwei screens meiner "Status (Zustände)" klasse und der dazugehörigen library klasse.

hier so einige erkenntnisse/vorteile:

1. die editor scripts können nun ganz raus, da jeder zustand über das scriptable objekt editiert werden kann.
2. die library enthält ein static Dictionary das beim ersten zugriff mit den SO's beladen wird
3. die lib ist dann von überall im objekt zugreifbar und muss nirgends angehängt werden (kein monobehaviour)

jetzt gehts erstmal daran alle anderen klassen auch zu umzuschreiben (sind doch einige)

auf lange sicht aber die beste lösung (finde ich zumindest)

Danke für eure Antworten!

Ich hab mich jetzt definitiv für die SO's entschieden, da ich gut damit klarkomme und diese überall angeprießen werden wie sauer bier ;-)

@Schorsch:

1. Klar, wenn du mehrere spieler hast musst du die SO's im editor verlinken und das ist lästig. Aber du hast immer nur 1 objekt davon in deinem projekt und verlinkst im endeffekt nur eine "referenz". Wenn also 20 Spieler das ScriptableObjekt "Lederrüstung" verlinkt haben, so existiert die Lederrüstung trotzdem nur einmal im speicher/im projekt - es werden keine 20 kopien davon erstellt.

2. Problematisch wirds nur dann wenn du im code ein SO benötigst was nirgendwo verlinkt ist, z.B. ein zufälliges SO. weil dann hast du keine referenz darauf und müsstest im extremfall den Resources ordner deines projekts durchsuchen. deswegen habe ich das in meinem post weiter oben mit einem Dictionary gelöst wo alle SO's eingetragen werden.

Dann kann ich später einfach sagen:

StatusLibrary.GetStatus("Gift");

und ich erhalte das passende SO zurück ohne das es arg auf die performance geht. beim ersten zugriff werden die SO's in das dictionary geladen und sitzen dann im speicher. das ist schneller als jedesmal den Resources ordner zu durchsuchen.

mit dem system könnte man übrigens auch einer beliebigen anzahl von spielern den status "Gift" zuweisen ohne alles im editor verlinken zu müssen. die spieler bräuchten nur einen wert:

public StatusTemplate meinDerzeitigerZustand;

und dann könnte man sagen:

spieler.meinDerzeitigerZustand = StatusLibrary.GetStatus("Gift");

diese technik habe ich bisher mit gewöhnlichen klassen/werten angewendet und funktioniert bei SO's ganz genauso. bisher fahre ich ganz gut damit.

hoffe das war verständlich und hilft etwas weiter!