spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo,

Ich habe mir vorgenommen, beim nächsten Unity Meetup in Berlin einen Vortrag darüber zu halten, wie man in Unity zu besserem Software Design kommen, welche Mittel man dafür verwenden kann und welche Philosophie man verfolgen sollte. Während des Vortrags würde ich u. a. auf folgende Punkte eingehen:

• [SerializeField]
  
• [HideInInspector]
  
• [RequireComponent]
  
• konkrete Komponententypen statt GameObject für Inspector-Variablen
  
• Properties
  
• enums
  
• structs
  
• Nullable
  
• List<T>, bzw. System.Collections.Generic allgemein
  
• Generik allgemein
  
• Erweiterungsmethoden, auch in Verbindung mit enums und Generik
  
• delegates, mit speziellem Verweis auf System.Action und System.Func
  
• Lambdas
  
• events
  
• Operatorenüberladung

Ich will dabei nicht nur die Punkte nennen und die Syntax aufzeigen, sondern auch darauf eingehen, warum bestimmte Dinge das Software Design verbessern, warum man andere eher vermieden werden sollten und anhand von Beispielen Verwendungsmöglichkeiten aufzeigen. Genauso will ich Hinweise geben und diverse Fallstricke aufzeigen, in die man gerade dann tappen kann, wenn man die Unity-Mittel gewohnt ist. Für SerializeField und Properties würde ich kurz erwähnen, warum man seine Variablen möglichst private halten sollte und für delegatess und somit auch events würde ich erwähnen, dass dieses unabhängig der active- und enabled-Eigenschaften ausgeführt werden, um mal 2 Beispiele genannt zu haben.
Viele der Punkte sind im Grunde Grundlagen, die ein Programmierer ohnehin schon wissen sollte, allerdings gehe ich bei dem Vortrag davon aus, dass auch Neulinge und nicht-Programmierer zuhören werden. Diese nicht-Programmierer könnten Grafiker und Game Designer sein, die für die Umsetzung ihrer Spiele zwar auch Code schreiben, für die das aber dennoch eher ein Mittel zum Zweck ist.

Nun die Frage an euch: Habe ich etwas vergessen? Gibt es noch andere Dinge, auf die ein "typischer Unity-Programmierer" wahrscheinlich nicht stoßen würde? Mir ist dabei ziemlich egal, wie fortgeschritten oder grundlegend von euch eingebrachte Vorschläge sind. Es müssen auch keine Sprachfeatures oder Attribute sein. Allgemeine Hinweise zur Vorgehensweise oder Best Practices würde ich auch begrüßen.


Sollte der nächste Unity Meetup weder verschoben werden noch ausfallen, wird er am 1. Mai stattfinden.

Richard Wepner

Ja, das klingt nach guten Stichpunkten, und zugegebenermaßen bin ich bisher auch noch nicht darüber gestolpert...

Ich habe mir die aufgeführten Frameworks nicht weiter angesehen, allerdings verallgemeinert ein DI-Framework die Aufgabe, Abhängigkeiten zu injezieren. Das könnte bspw. erreicht werden, indem man über Annotationen an einer Member-Variable angibt, dass diese über das Framework mit einem Wert versehen werden soll. Dieses Attribut könnte außerdem parametrisiert sein, sodass das DI-Framework sich dann auch darum kümmern würde, die richtige Instanz zuzuweisen oder notfalls die gewünschte zu erzeugen.

@Tobiking:
Danke dafür. Ich hatte mich bisher nicht mit derartigen Frameworks für Unity beschäftigt. Gerade im Zusammenhang mit Unity müsste ich aber noch ein paar Dinge nachschauen, wie bspw. den Zeitpunkt und die Bedingung des injezierens und ob diese Frameworks automatisch neu erstellte GameObjects berücksichtigen. Letzteres kann durch dynamische Generierung und durch additives Laden auftreten.
Und es wäre natürlich gut zu wissen, wie gut es sich mit den Unity Test Tools kombinieren lässt, sodass während des Tests beispielsweise Testimplementierung verwendet werden.

@LetsGo:
Object.DontDestroyOnLoad werde ich noch mit unterbringen, allerdings scheint Resources.UnloadUnusedAssets nur für die Optimierung des Codes relevant zu sein, nicht aber für das (Software-)Design. Die anderen beiden Attribute sind erst im Zusammenhang mit Editor-Scripting relevant. Man kann sich oder den anderen Teammitgliedern damit die Arbeit durchaus vereinfachen, allerdings würde ich diese eher in einem Vortrag speziell über Editor Scripting besser angesiedelt sehen.
Der Hinweis, dass Materialien kopiert werden, ist nicht unsinnig. Ich weiß aber nicht, ob ich diesen in den Vortrag einbauen kann, da ich gerade nicht den Bezug zum Thema sehe.

Zitat von »Tobiking«

Zitat von »Richard Wepner«

Gerade im Zusammenhang mit Unity müsste ich aber noch ein paar Dinge nachschauen, wie bspw. den Zeitpunkt und die Bedingung des injezierens und ob diese Frameworks automatisch neu erstellte GameObjects berücksichtigen. Letzteres kann durch dynamische Generierung und durch additives Laden auftreten.

Ich habe bisher nur mit Zenject Erfahrung gesammelt. Da ist es so, dass es vom Framework eigene Funktionen zum Erzeugen von GameObjects und dem Laden von Szenen (auch additiv) gibt, die dafür sorgen das auch direkt die Abhängigkeiten aufgelöst werden. Das Laden von Szenen ist allerdings ein Sonderfall, da Unity selber die Objekte erzeugt und deswegen keine Constructor injection möglich ist. Es werden nachträglich Properties injected und anschließend mit PostInject annotierte Funktionen aufgerufen.

Ich konnte mir schon denken, dass man eben solche Umwege gehen muss, damit die Abhängigkeiten ordentlich injeziert werden können. Insgesamt werde ich es mir aber dennoch selbst ansehen müssen, um zu sehen, wie genau ich das in den Vortrag integrieren könnte.
Ich muss aber auch zugeben, dass ich den Konstruktor vom MonoBehaviours bisher nie implementiert habe, gerade weil Unity einem bei jedem Aufruf darauf hinweist, dass man die Komponenten nicht über einen Konstruktorausruf instanziieren solle.

Zitat von »Tobiking«

Zitat von »Richard Wepner«

Und es wäre natürlich gut zu wissen, wie gut es sich mit den Unity Test Tools kombinieren lässt, sodass während des Tests beispielsweise Testimplementierung verwendet werden.

In Zenject sollte das möglich sein. Man hat ein CompositionRoot Objekt in der (Haupt-)Szene, in dem die Bindings konfiguriert werden etc. und man könnte für die Testszenen dort eine andere Konfiguration wählen. Ich habe mich aber mit den Unity Testtools nicht allzu lang beschäftigt, da für den Prototyp den ich gebaut hatte eher wenig Abhängigkeiten zwischen verschiedenen Objekten bestand und mir da der Aufwand des Testaufbaus zu hoch vor kam. Ich habe die Logik einfach in normale Klassen (keine MonoBehaviours) ausgelagert und sie per Unittests abgedeckt.

Und die Unity Test Tools machen nichts anderes, als eine Oberfläche für die automatisierten Tests zu liefern. Man kann darüber alle oder nur bestimmte Unit-Tests ausführen lassen und sich in einer Liste ansehen, welche erfolgreich waren und welche fehlschlugen. Soweit ich weiß kann man diese Ausführung auch automatisch zu bestimmten Ereignissen anstoßen lassen, wie bspw. vor dem Bauen des Projekts. In der Hinsicht bin ich mir aber nicht sicher, dafür habe ich diese Tools dann doch zu wenig verwendet...


@KeksX:
Mir ist leider nicht bekannt, dass das gemacht werden würde. Das heißt, ich müsste mich darum kümmern, dass das gemacht wird, ich kann also nichts versprechen.
Hast du nur Interesse an der Information oder würdest du dir den Vortrag dann auch mal ansehen wollen?