Jump to content
Unity Insider Forum

Gescheiten UI Architectur, MVC Pattern sinnvoll?


MaZy

Recommended Posts

Hallo ich war mal nach UI Architecture Techniken mal am Googlen um Tipps einzuholen.

Dabei hab ich öfters gelesen, das einige von MVC schreiben. Ich verstehe ja grundsätzlich worum es da geht, aber von der Umsetzung her kommt mir das nicht so sinnvoll vor bzw. dass es vllt nicht so mein Ziel entspricht.

Ein Beispiel was ich gelesen habe war: https://www.toptal.com/unity-unity3d/unity-with-mvc-how-to-level-up-your-game-development 
Allerdings bezieht man sich hier nicht um die UIs, sondern um das Konzept selbst.

Trotzdem wollte ich mal allgemein Fragen, ob es überhaupt sind macht sowas bei sowas zu verwenden oder gibt es da andere Techniken. Einige andere System wie Doozy UI benutzt da komplexeres, allerdings ist das eher für Menüs gestaltet. Also Animationen, Sounds usw. Mir geht es eher um den Managen von verschiedenen Teilen.

Was ich bei MVP gut finde ist, dass man quasi im Core von überall zugreifen kann. app.menuManager.Open("option");. MenuManager würde selber die app kennen und kann von da aus sogar andere Menüs öffnen (ob es machen dürfen sollte, ist ne andere Frage ^^).

So ähnlich ist ja bei Components auch, wenn ich entweder Referenz zu dem Hauptteil aufbaue. Also quasi:
class UIMenuManager;
class UIMenuItem -> Awake -> finde UIMenuManager

Jetzt könnte ich bei UIMenuItem beispielsweise Back() benutzen und da wäre sowas wie: Close this -> menuManager.LastMenu -> Open()

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Der Witz an MVC ist Modularität. Man kann halt M, V oder C austauschen und das System funktioniert immer noch. Wenn man sein Projekt komplett mit MVC aufbaut, dann ist Unity als Grafikengine die View, man kann dann aber stattdessen Uneal drunterschrauben, wenn sich das irgendwann als sinnvoll erweisen sollte, und muss nicht Model oder Controller neu schreiben.

Testbarkeit ist auch ganz nett, dass du z.B. deinen Controller-Teil testen kannst, ohne dafür technische Details deines View-Anteils einbeziehen zu müssen (also: ohne Unitys Besonderheiten in den Tests berücksichtigen zu müssen).

MVC hat halt Vorteile, schraubt aber die Basiskomplexität nach oben. So etwas wie Soda würdest du da nicht benutzen, weil hier Daten in ScriptableObjects (und die gehören zu Unity und damit zum Definitionsbereich der View) liegen. Das ist ein bisschen wie mit RTX - ist schon ganz geil, aber du brauchst halt erstmal ne Grafikkarte die das kann, um da überhaupt mit arbeiten zu können. Wenn dein Projekt über Jahre hinweg maintained wird, ist so etwas auf jeden Fall sinnvoll. Bei einem Gamejam ist das völliger Blödsinn (es sei denn, man geht zum Gamejam, um Dinge auszuprobieren, und dieses Mal ist MVC dran...). Und irgendwo dazwischen liegt halt die Grenze. Bei einem Zweierteam in einem Projekt über ein halbes Jahr würde ich z.B. noch darauf verzichten.

Ich bleibe jedenfalls so oder so nach wie vor dabei: Wenn deine Klasse "Manager" im Namen hat, machste grundsätzlich was falsch :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Mit Soda oder die ähnlichen Weg gehen konnte ich mich nicht anfreunden. Ich hab schon da einiges ausprobiert und teilweise auch einiges gemacht und benutze paar Techniken davon, aber insgesamt mit dem scriptable floats, ints usw. ist für mich nicht so schön. Allerdings finde ich die events schön mit scriptable objects und damit hab ich auch teilweise die UI geupdatet. Ich hab das so ähnlich, aber mit generic types. Mir geht es allgemein darum, dass ich wenig wie möglich übers Inspector machen möchte, sondern so aufbauen möchte, dass es automatisiert funktioniert. Also sprich Automation soll eher hier sein. Bezüglich der UI Beispiel: Je mehr Einheiten im Spiel vorhanden sind umso mehr sind HP Bars zu sehen. Diese Prozesse dahinter möchte ich sag mal so "perfektionieren". 

vor 5 Stunden schrieb Sascha:

Ich bleibe jedenfalls so oder so nach wie vor dabei: Wenn deine Klasse "Manager" im Namen hat, machste grundsätzlich was falsch

Ja in dem Fall hab ich tatsächlich Manager genannt, aber ich weiß nicht warum das "grundsätzlich" Falsch sein soll. Es ist einer der normalen Methoden die man benutzen kann. Hier geht es mir darum, dass ich direkt etwas aufrufen kann ohne, dass es etwas hier oder da gezogen werden muss (also die Components). Zum Beispiel ziehe ich ein neuen UI Panel rein und es ist automatisch zu finden. Später kann / möchte ich MenuManager.Get("TeamMenuItem") machen und MenuItem zurück geben und kann dann damit direkt arbeiten. Ist nicht mal von MonoBehaviour geerbt. Das ist derzeit so und möchte das aber etwas noch besser handlen.

Ich schätze mal du reagierst darauf allergisch, weil in dem Unite Video die Manager bezüglich singletons etwas kritisiert haben und das man auch jedes mal in die Scene die Sachen brauchst damit es funktioniert. Das ist hier nicht der Fall da es singleton frei ist.

Hierbei geht es wirklich um großes Spiel, welches in Steam, wenn es Fortschritte macht erscheinen soll. Deswegen möchte die UI Planung gut durchführen. Andere Teile sind schon fortgeschritten.

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo 

Ich verstehe auch nucht so recht, warum Manager komisch ist. Ich habe zum Beispiel ein Objekt und dieses hat einen Manager, der alle Verhaltensweisen (einzelnen Klasse, die vom gleichen interface erben) in einem array hält. Das hat den großen Vorteil, dass ich den Manager nur angreifen muss, wenn ich ein neues Verhalten hinzufüge oder so. 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

"Manager" hat keine Aussagekraft. Der Name "EnemyManager" sagt nichts aus, außer, dass die Klasse irgendwas mit Gegnern zu tun hat. Was macht sie aber? Bewegt sie die? Hat sie Jobs? Verteilt sie die Jobs oder ist das Ding nur ein Datenspeicher? Namen sind extrem wichtig, wenn der Code nicht nach und nach zum Urwald werden soll, und ein Name wie dieser bietet keine Einschränkungen dafür, was alles in die Klasse gehört und was nicht.

Bei diesem Punkt geht es natürlich nicht um "funktioniert" und "funktioniert nicht". Der Ansatz, irgendwelche Dinge über lauter Manager-Klassen zu regeln, ist einfach nur Ursache für schlechtere Code-Qualität, also Robustheit, Modularität, Testbarkeit, Lesbarkeit... diese Dinge.

Nicht zuletzt auch deshalb, weil er zu zentralisierter Architektur verleitet. Mit Unitys Komponentendesign kann man 99% aller Dinge dezentral oder statisch implementieren. Eine zusätzliche Klasse, die im schlimmsten Fall auch noch als Komponente in der Szene platziert werden muss, damit andere Objekte funktionieren können, da sie es alleine nicht schaffen, ist einfach ein Garant für schwer zu behebende Probleme, sobald das Projekt auch nur minimal an Komplexität gewinnt.

@chrische5 Warum ist dein Array zum Beispiel in einem Manager? Ist der Manager eine Komponente auf einem anderen GameObject? Was genau managed der überhaupt? Ist das Ding nicht doch vielleicht einfach nur ein Objekt mit einem Array drin? Wenn das nicht einfach statisch implementiert ist: Warum nicht?

@MaZy Find ich ein bisschen bitter, dass du annimmst, dass ich ein Video geschaut habe und darauf irgendwie komplett meine Meinung aufbaue. Da du aber von deiner Lösung überzeugt bist, werde ich da nicht weiter gegen andiskutieren. Wenn du meine Meinung erklärt haben willst, sag Bescheid.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo 

 

Zuerst möchte ich sagen, dass mir natürlich deine Expertise komplett abgeht und ich gerade einfach nur ganz viel sehe und lese und versuche zu verstehen. Das, was du hier schreibst, scheint mir immer gut begründet und sehr fundiert zu sein. Deswegen auch mein großes Interesse an Soda und der Art, wie du dort Probleme angehst. 

Bei meinem Manager handelt sich um ein Script auf einen prefab. Dieses hat verschiedene Verhaltensweise, die zuerst alle direkt im Manager implementiert waren. Dann habe ich was Solid gesehen und dort vor allem zum open close Prinzip, welches ich sehr spannend finde. Also verwaltet der Manager nun nur die verschiedenen Verhaltensweisen. Das scheint mir sehr elegant zu sein und der Name auch passend. Wenn ihr bzw willst, kann ich die Klasse mal hier posten und du zeigst, was dir daran nicht passt. Da lerne ich bestimmt eine Menge und du kannst deinen Punkt noch deutlicher machen. Also nur als Angebot. 

 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 6 Stunden schrieb Sascha:

 

@MaZy Find ich ein bisschen bitter, dass du annimmst, dass ich ein Video geschaut habe und darauf irgendwie komplett meine Meinung aufbaue. Da du aber von deiner Lösung überzeugt bist, werde ich da nicht weiter gegen andiskutieren. Wenn du meine Meinung erklärt haben willst, sag Bescheid.

Ich wollte jetzt nicht damit dich angreifen bzw. sagen, dass du unter einer Gehirnwäsche leidest oder so. Mit deinem Soda Solution hast du auch ein Video verlinkt, wo ich von anderen Threads teilweise die Argumente von dir gelesen habe wie im Video. Ich meinte damit nicht, dass die Aussagen darauf aufbauen, wenn es so rüber kam. Die Argumente sind auch ja nichts schlimmes, weil sie dort Probleme aufweisen und Lösungswege zeigen. Ich bin daher davon ausgegangen, dass du auch die gleiche Meinung teils ins Sinne von, dass zum Beispiel Singletons usw. die Produktivität in Unity erheblich kompliziert machen können. Aber du sagtest trotzdem auch, dass ICH etwas grundsätzlich Falsch mache, weil ich etwas Manager nenne, ohne eigentlich zu wissen, wie es im Hintergrund tatsächlich abläuft. Und ich finde hier gibt es aber kein richtig oder falsch. Ich habe auch nirgends erwähnt, dass ich überzeugt von meiner Methode bin, sondern nach verschiedenen Ideen Ausschau halt und etwas erklärt wie ich sonst mache bzw. mir vorstelle.

Genauso denke ich das bei der Lösung mit Soda oder ähnliches auch. Ist ja nicht so, dass ich das "Falsch" sehe:

m4X87aW.png

Ich bin jetzt auch nicht großer Fan von Singletons, wie es gerade in Unity verwendet wird, aber genau deswegen hab ich eine eigene Technik in einem anderen Projekt was das angeht entwickelt. Genau die Probleme, dass ich nicht immer in der ersten Szene starten will, damit alles geladen wird, fehlende Referenzen vermeiden usw., die wollte ich damit eliminieren. 
Dabei wurden, wenn überhaupt gebraucht wird, die Singletons in ScriptableObjects eingebaut. Das heißt, sie werden nur dann eingesetzt, wenn etwas sie braucht. Egal ob ich ein Prefab in de Scene zum Testen rein schiebe oder nicht. Die waren automatisch da. Und solche Automatisierungen mag ich sehr gerne.

Nichtsdestotrotz, ging mir ja hier eher um die Menüs und HUDs zu verwalten. Eine relevante Aussage hast du zu MVC gemacht. Es wird so aufgebaut, dass man von Unity weggehen kann und wo anders weiter machen kann und glaube hat auch mit sowas wenig zu tun und brauche das nicht.

Ich hab letztens etwas anderes auch zu UI Sache gelesen und werde mal schauen, ob es eventuell Sinn macht.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb MaZy:

Nichtsdestotrotz, ging mir ja hier eher um die Menüs und HUDs zu verwalten. Eine relevante Aussage hast du zu MVC gemacht. Es wird so aufgebaut, dass man von Unity weggehen kann und wo anders weiter machen kann und glaube hat auch mit sowas wenig zu tun und brauche das nicht.

Oh, nicht unbedingt. Das war ein Beispiel für MVC, aber das muss nicht so sein. Gerade bei UI kannst du das auch in kleinerem Rahmen verbauen. Es gibt z.B. Frameworks, wo man sein UI mit XML oder HTML+CSS spezifizieren kann und dann wird das in Unity angezeigt. Damit ist dann die Spezifikation des UIs nicht mehr in Unitys eigene Semantik eingebettet, und du kannst die Elemente auch von etwas anderem anzeigen lassen (oder einfach etwas an der Anzeige ändern), ohne deine Layouts oder dein Welcher-Button-macht-was zu opfern.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 17.5.2020 um 04:24 schrieb Sascha:

Oh, nicht unbedingt. Das war ein Beispiel für MVC, aber das muss nicht so sein. Gerade bei UI kannst du das auch in kleinerem Rahmen verbauen. Es gibt z.B. Frameworks, wo man sein UI mit XML oder HTML+CSS spezifizieren kann und dann wird das in Unity angezeigt. Damit ist dann die Spezifikation des UIs nicht mehr in Unitys eigene Semantik eingebettet, und du kannst die Elemente auch von etwas anderem anzeigen lassen (oder einfach etwas an der Anzeige ändern), ohne deine Layouts oder dein Welcher-Button-macht-was zu opfern.

Ich habe sowas bei Source 2 Engine (beim Spiel modden von Dota 2) verwenden müssen. Bald soll ja mit 2020 auch sowas kommen. Allerdings frage ich mich, wie es mit externen Frameworks aussieht z.B. animejs ist ein tolles Ding. In einem Kommentar oder Video, weiß nicht genau wo das war, meinte ein Unity Staff nämlich, dass Javascripts schwieriges Thema ist.
 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

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

×
×
  • Neu erstellen...