Jump to content
Unity Insider Forum

Wie teile ich die Scripte logisch auf?


ulli

Recommended Posts

Hallo zusammen,

ich habe in den letzten Wochen mir Tutorials angesehen, etwas programmiert und getestet. Ich habe viel technisches gelernt. Doch eine Sache vermisse ich.

Wie teile ich meine Scripte logisch auf? Dazu habe ich nichts gefunden. Mein Fokus liegt auf der Steuerung von 3D Objekten durch die UI.

Ich würde dem Cancas oder einem Nullobject ein Script zuweisen.

In diesem Script würde ich alle Buttons und 3D Objekten als GameObject zuweisen.

Mein Hauptprogramm würde in diesem Script laufen und alles Steuern.

Aber ist das so richtig?  Wie macht ihr das?

Ich schreibe das mal ins Allgemeine Forum. Es ist ja keine wirkliche Code Frage.

 

Grüße Ulli

 

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo

Die Frage ist schwer allgemein zu beantworten. Ich versuche immer möglichst wenig Spaghetticode zu basteln und lieber logisch aufzuteilen. Meist ergibt sich das dann von allein. Am wichtigsten ist meiner Meinung nach eine sinnvolle benamung der Funktionen, Klassen und member. Wenn du das gut machst, kannst die Klasse auch größer sein und der Editor deiner Wahl hilft dir dann nur den zu bearbeitenden Code auszuklappen usw. 

 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Es gibt da tatsächlich einiges drüber, weil dieses Thema relevant ist, seit es Software-Entwicklung gibt. Da gibt es zum Beispiel das Single Responsibility-Prinzip. Deine Klasse/Komponente sollte nach Möglichkeit nur eine Aufgabe erledigen und nicht mehrere. Wenn man sich den Source Code vom (wirklich guten!) Player Controller von Celeste anschaut, sieht man, dass in diesen grausamen 5471 Zeilen Code einfach alles drinsteckt: Bewegung, Gravitation, Kollisionsabfrage, Animationen, Haarphysik, Sound-Effekte... einfach alles. Finde da mal einen Fehler drin. (Die Entwickler haben selbst gesagt, dass sie wissen, dass das keine so ganz gute Idee war :).) Stattdessen solltest du versuchen, deine Code-Einheiten (also meist: Komponenten) so zu bauen, dass du beim Testen z.B. merkst: Die Kollisionsabfrage funktioniert nicht richtig; und dann schaust du dir nur die Klasse an, die dafür verantwortlich ist.

Entsprechend sollten deine Klassen nach Möglichkeit modular sein, heißt: Wenn du eine Komponente oder mehrere wegnimmst, funktionieren die anderen noch. Das "nach Möglichkeit" ist hierbei nicht unwichtig, denn ohne Abhängigkeiten geht es oft nicht.

Gerade in Unity mit dem Komponentensystem ist es wunderbar möglich sein ganzes Programm in einzelne Akteure aufzuteilen, die eigenständig agieren, anstatt ein Master-Script zu haben, das alles regelt. Und das sollte man auch tun.

vor 9 Stunden schrieb ulli:

Mein Hauptprogramm würde in diesem Script laufen und alles Steuern.

Das ist also genau der falsche Ansatz. Zum Ziel kommt man damit natürlich auch irgendwie, aber Fehler finden und reparieren ist bei so einer Herangehensweise immer unendlich viel schwieriger.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Im normalen Arbeiten ist es wirklich einfacher, wenn du kleinere einzelne Sripte hast.
Beispiel: Sollen sich verschiedene Gameobjekte neben verschiedener ander Sachsen auch um die Z-Achse drehen mach dafür ein eigenen Script und weise dieses im Inspector den GameObjekten zu. Somit siehst du schon anhand des Vorhandensen des Script (ich habe es bei mir "TranformRotZ" genannt), dass sich dieses GameObjekt dreht, ohne dafür in das "MasterScript" des GameObjekt nachschauen zu müßen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich würde sagen, was man am besten bequem findet.
Ich ändere pro Projekt jedes mal meine Idee, weil mir was besseres oder manchmal auch schlechteres einfallen.
Was ich immer tue ist, die Nachteile zu eliminieren und Vorteile zu generieren.

Ich habe zum Beispiel öfters gesehen, dass einige unter jedem Button ein Script knallen um eine Aktion auszuführen. Beispiel ein Script UIActions.cs und hat oder mehrere Funktion z.B.

OpenMenu( menu ).

Was ist hier zum Beispiel der Nachteil?

  • Jedes Button hat diesen Script und erschwert das Bearbeiten.
  • Mehrere Instanzen, mehr verbrauch von Ram Speicher (und normalen Speicher weil Components größer werden).

Dabei braucht man diesen Script nur einmal auf ein GameObject und man kann es dann auf jeden Button bei Click Event reinziehen. Daher mach ich meist leeren GameObject mit nur UI Scripte.

Vorteil hier:

  • Eine Instanz (also weniger Ram Speicher und Speicher usw.) Allerdings weiß ich nicht, wie Unity im Hintergrund das macht. Kann das da trotzdem mehr Speicher benutzt wird.
  • Ein Script (wenn man zum Beispiel löschen oder ersetzen will muss man nicht bei allem Buttons löschen).

Aber auch das mit Buttons tue ich nicht so. Das wird immer komplexer die Lösungen, aber bequemer. 

Nachteil ist immer noch: Sollte ich den UI Script ändern muss ich die Buttons wieder zuweisen. Also brauch ich noch geilere Idee.

Tja und da komm ich wieder zu dem ersten teil kombiniert mit einer anderen Idee. Beispiel was ich noch ausprobiere ist mit FindObjectOfType und automatische Button Registration bzw. scriptableObject. Das heißt ich habe mehrere Button die zu einem Script senden, ich habe diese Aufgabe "Menu öffnen". Dort weiß das Script wohin er alles weiter leiten muss. In anderen Worten, ich muss nie den Button oder ihr Verhalten selber anfassen. Das wird automatisch in Runtime gemacht. Nachteil, dieser Button muss ein Script enthalten. Also.. du siehst schon. Hier ist die Frage, was ist bequemer :D

Was Aufteilungen angehtBei Kleinigkeiten kann man ruhig in eine Datei machen. Bei größeren ist Aufteilung zu empfehlen.

Auch hier ein Beispiel von mir. Multiplayer Spiel mit Player Spaceships + AI Spaceships.
Folgende Componenten hatte ich beim Player Ship drauf:

  • Ship
  • ShipMovement
  • ShipWeaponController
  • DamageSystem

Und Ai Ship hatte:

  • ShipAi
  • ShipMovement
  • ShipWeaponController
  • DamageSystem

Du siehst also was man sich dadurch erspart. Aber der Nachteil bei mir ist, dass Ship und ShipBase den Movement und Weapon brauchen. Ohne funktioniert es nicht. Also da struggle ich noch, aber irgendwann ist das auch gut gelöst, denn ich versuch so gut wie möglich unabhängig von einander arbeiten zu lassen.

Bei mir allgemein ist so, dass ich mittlerweile ohne meine Standard Scripte nicht mehr klar komme:

WMhnNPQ.png

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

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

×
×
  • Neu erstellen...