Jump to content
Unity Insider Forum

GO, die mit Instantiate erstellt werden


chrische5

Recommended Posts

Hallo

Ich habe ein Prefab, welche ich zur Laufzeit mit Instantiate() erzeuge. Das klappt alles ohne Probleme. Wenn ich allerdings zwei oder mehr Objekte erstelle und bei einem davon Werte ändere, ändern sich diese auch bei den ebenfalls erstellten Objekten. Ist das so gewollt oder habe ich ein Wahrnehmungsproblem und der Fehler liegt ganz woanders?

 

Stimmt nicht, habe es praktisch in dem Moment entdeckt, als ich auf Absenden geklickt habe. Fehler muss bei mir liegen. Sorry.

 

Christoph  

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo 

Jetzt habe ich doch mal noch eine Frage zum Thema. Stellen wir uns vor, ich habe ein Prefab mit einem SO. Dieses Prefab instanziere ich mittels Instantiate() mehrfach. Was passiert dann mit den Daten des SO? Werden dabei neue SOs intern hinterlegt oder greifen alle neuen GOs auf das eine, im Editor ins Prefab gezogene, SO zu und teilen sich die Daten entsprechend? 

 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Letzteres. Instantiate dupliziert das übergebene GO, alle dessen Komponenten, alle Kind-GOs und deren Komponenten. Eine Referenz auf eines dieser Objekte wird durch eine Referenz auf die jeweilige Kopie umgestellt. Referenzen auf Objekte, die nicht Teil davon sind, bleiben, wie sie sind. Und da das SO nicht Teil dieser Struktur ist, bleibt die Referenz dieselbe.

[SerializeReference] macht die Angelegenheit etwas komplizierter, aber das benutzt man ja auch nicht alle Tage.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo 

 

Ich muss mal wieder nach einem allgemeinen workaround fragen. Ich habe bisher oft so für Daten genutzt 

Also dort Dinge, wie Name, Beschreibung, Geschwindigkeit und ähnliches ausgelagert. Das funktioniert aber nicht mehr, wenn ich das go zur Laufzeit erstelle, weil dann ja alle auf das eine so zugreifen. Kann ich die Daten anderweitig auslagern oder ist das grundsätzlich Unfug? 

 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Warum benutzt du denn da ScriptableObjects? Die Dinger sind ja im Prinzip fast ganz normale Objekte. Der einzige Unterschied ist, dass ScriptableObjects im Editor 1. angelegt, 2. mit Daten versehen und 3. referenziert werden können. Wenn du die Dinger benutzt, um da Daten reinzutun, die spezifisch für einzelne, zur Laufzeit erzeugte Objekte sind... welchen dieser drei besonderen Eigenschaften nutzt du dann überhaupt?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo

Dann stelle ich mich mal ins Schaufenster...Ich habe bisher nach der Maxime gehandelt, die reinen Daten (Name, Beschreibung, Alter, Schaden,...) möglichst nicht direkt im MB zu haben, sondern als SO und im MB hatte ich dann ein Feld Data und in das habe ich das entsprechende SO gezogen. Das schien mir sauberer. Das funktioniert aber eben nicht dynamisch. War die Grundidee schon falsch? Ich könnte die Daten ja auch aus einer Datei oder ähnlichem auslagern. Ich habe früher immer mal mit MVC und MVVM gearbeitet und es dabei so gehalten.

 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 12 Minuten schrieb chrische5:

War die Grundidee schon falsch?

Naja, falsche Grundideen gibt's eher selten. Eher so "nicht richtig umgesetzt" und/oder "Overkill" und... "Underkill"? Du weißt schon ;)

MVC ist meiner Meinung nach für "normale" Projekte ganz schnell Overkill. Ich hab das auf der Arbeit, weil wir alle zwei Wochen ein Update raushauen und der Kram von oben bis unten gnadenlos testbar sein soll. Da greifen so viele Zahnräder ineinander und in jedem Sprint wird die Hälfte der Zahnräder in irgendeiner Weise angefasst. Wenn wir uns da auf Augenmaß verlassen würden, wäre das Spiel das reinste Bugfest. Wenn du aber ein, zwei Jahre an einem Spiel arbeitest, es danach veröffentlichen und dann noch eine Weile maintainen (Bugfix-Patches, vielleicht hin und wieder eine Erweiterung) willst, dann sieht die Kosten-Nutzen-Rechnung gleich ganz anders aus. MVC ist dazu da, Logik, Daten und Anzeige/Input voneinander zu trennen. Hauptsächlich, damit du beim (automatisierten) Testen schnell sehen kannst, wo in diesen drei Bereichen der Fehler liegt. Es kann aber durchaus sein, dass dein Code nicht sonderlich komplex oder volatil ist. In diesem Fall bedeutet MVC Mehraufwand, der beim Bugfixen aber kaum Mehrwert liefert.

Wenn du aber MVC durchziehen willst, musst du dir Gedanken machen, welche Objekttypen wozu gehören. Hauptsache, es ist getrennt. Du kannst Model-MonoBehaviours neben Controller-MonoBehaviours und View-MonoBehaviours haben. Du kannst aber auch MonoBehaviours ausschließlich als Views benutzen und Models und Controller anders bauen. ScriptableObjects für Models zu benutzen kann durchaus sinnvoll sein, wenn deine Datenschicht eine recht statische Struktur hat. Wenn du z.B. eine Soda-GlobalVariable für die HP des Spielers nutzt, dann ist ja sozusagen Teil eines Models. Auch wenn es etwas unüblich ist, ein Model in mehrere Objekte aufzuteilen. Aber bei einem simplen 2D-Plattformer reicht so etwas vielleicht. Sobald es etwas komplexer wird, stehst du halt vor dem Problem, das du jüngst bemerkt hast. ScriptableObjects geben dir nix, wenn du sie zur Laufzeit erzeugst. Wenn deine Daten dynamisch zur Laufzeit entstehen, musst du deine Models entweder direkt auf die Objekte packen, die sie betreffen - also gibt's Model-MonoBehaviours - oder du baust deine Models komplett getrennt von der Unity-Welt. Dafür baust du stinknormale C#-Klassen.

Wenn du dich fragst, wo überhaupt der Einstiegspunkt für Programme ist, die gar nicht so Unity-zentrisch sind... Du kannst da entweder selber etwas initialisieren, z.B. mit [RuntimeInitializeOnLoadMethod], oder du nutzt etwas bereits existierendes wie Zenject.

Keine Ahnung, ob dir diese Antwort überhaupt hilft, aber dieses noch:

vor 35 Minuten schrieb chrische5:

Das schien mir sauberer.

Mache dir immer Gedanken, warum du bestimmte Dinge machst. So etwas wie "ich habe im Hinterkopf, dass MVC sauberer ist" schadet dir sehr schnell viel mehr, als es hilft. "Das schien" klingt danach, dass du die Vorteile deines Ansatzes in deinem Projekt nicht wirklich bemerkst. Und wenn du den Unterschied nicht wirklich sehen kannst, dann liegt das vermutlich daran, dass nicht wirklich einer da ist. Außer dem ständigen Mehraufwand, wenn du dich fragst, wie du ein bestimmtes Konzept in deine dir selbst auferlegte Struktur reinpressen kannst.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo

 

Vielen Dank für deine ausführliche Antwort. Gerade den letzten Absatz finde ich sehr interessant und versuche noch eine Meinung dazu zu entwickeln. Du hast natürlich Recht und trotzdem macht man manchmal Dinge, die man noch nicht durchschaut, weil es eben guter Stil ist. Du rätst ja auch, dass man strings und so weiter vermeiden sollte (und zwar von Anfang an) obwohl einem das zunächst nicht so richtig einleuchtet.

Ich wälze das mal noch etwas hin und her für mich.

 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Es ist auf jeden Fall gut, Strings zu vermeiden, weil man die Nachteile einsieht... "weil Sascha das sagt" ist aber kein sehr guter Grund :D

vor 59 Minuten schrieb chrische5:

Ich wälze das mal noch etwas hin und her für mich.

Viel Erfolg, und nie zu wenige Fragen stellen ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...