DSVGO
Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu.
Server Wartungsarbeiten
Glossar
Parent = Elternelement
Child = Kindelement
Aspect Ratio = Seitenverhältnis
Für einfaches Layering gilt folgende Hierarchie:
[Beispiel sprite renderer]
Bedeutet also:
Anmerkungen:
Um bessere Performance aus der UI herauszuholen müssen wir uns vor allem zweier Dinge bewusst sein:
Bevor es jetzt weiter geht noch ein Hinweis: Wie bei allem was mit Performance zu tun hat, gibt es kaum einen universell besten Weg Dinge anzugehen, sondern spezifische Lösungen für Probleme mit der eigenen UI. Diese Lösungen können dann wieder an anderen Stellen Dinge kaputt machen, beispielsweise sind mehrere Canvasses eine gute Idee, jedoch erhöhen sie auch die Anzahl an Batches; Spritemesh wird Overdraw verringern, allerdings gibt es jetzt mehr Polygone und man muss die Importeinstellung "Tight" verwenden. Es ist also ein Ausprobieren und Abschätzen, was für einen den meisten Mehrwert bringt. Am Ende kann wahrscheinlich nur der Profiler wirklich bei der Entscheidung helfen.
Gerade auf Mobile ist Overdraw ein Performance-Killer. Er entsteht, wenn sehr viele transparente Objekte über einander liegen. Es werden also oft Pixel gerendered, die später im Rendervorgang überschrieben werden, weil sie tatsächlich verdeckt sind.
Nochmal: Die gesamte UI ist transparent.
Es ist also allgemein ratsam beim Bau von Elementen darauf zu achten, dass alle statischen Elemente zu einer Textur zusammengeführt werden. Hierzu ein Beispiel:
[Beispiel vorher nachher]
Man kann bereits beim Export von Grafiken darauf achten, dass sie möglichst wenig leere Pixel enthalten und beispielsweise nicht unvorteilhaft rotiert sind.
[Beispiel]
Bei sehr detailierten Sprites kann es sich lohnen, die Funktion "Use Sprite Mesh" der Image-Komponente zu verwenden.
[Beispiel vorher nachher]
Man kann sehen, dass nun ein mehr oder minder genaues Mesh des Sprites verwendet wird, anstelle eines einzelnen Rechtecks. Dafür wird allerdings die Einstellung "Mesh Type - Tight" beim Import benötigt.
Unity bietet Möglichkeiten an Overdraw zu visualisieren - welche es gibt ist abhängig von der verwendeten Renderpipeline. Der Modus für die Built-in-Renderpipeline sieht beispielsweise so aus:
[Beispiel]
Allgemein wird der Inhalt von Canvasses über ein generiertes dynamisches Mesh gerendered. Dieses Mesh wird jedes mal neu generiert wenn sich etwas innerhalb des Canvas verändert. Wenn sich also ein einzelnes Element verändert, muss das ganze Canvas neu generiert werden. Zusätzlich dazu muss auch noch das Layout neu generiert werden - warum das ebenfalls schlecht ist kommt später im Abschnitt Layouts.
Eine erste Faustregel ist es also mehrere Canvasses zu benutzen und nicht die gesamte UI in ein riesiges Canvas zu Packen.
Im nächsten Schritt kann man dann ein jedes Canvas noch unterteilen, indem man Sub - bzw. Nested Canvasses hinzufügt.
Einen Beispiel Artikel von Unity findet man hier.
Die grundsätzliche Idee ist es UI in statische bzw. dynamische Elemente und damit auch Canvasse zu unterteilen. Dadurch sollen Elemente die sich manchmal bis sehr häufig verändern von denen, die das gar nicht tun, abgeschottet werden, damit sie nicht in Neu-Berechnungen eingeschlossen werden.
Im Artikel von Unity geht es um einen Timer. Dieser besteht aus einem Text und einer Zeitanzeige. Es ist klar, dass sich der Text "Current time" nie ändern wird, während die Anzeige der Zeit sich kontinuierlich updated. Entsprechend bringen wird die Zeitanzeige in ein eigenes Subcanvas, unter dem Canvas auf dem der Text liegt. Wenn sich jetzt die Zeit verändert, wird nur das Subcanvas neu berechnet - der Text bleibt unberührt.
[Beispiel]
Auto Layout funktioniert über ein sog. "dirty flag"-System. Wenn sich ein Layoutelement verändert und es damit einen umgebenden Layoutcontroller ungültig macht (z.B. Size oder Scale verändert), wird es als "dirty" markiert, worauf das Layoutsystem dann reagieren kann.
Problem: Layoutelemente sind Komponenten, also kann auf jedem Element oder auch Parent eins oder mehrere sein.
Um die Neu-Berechnung des Layouts korrekt auszuführen, wird nach dem Layoutcontroller gesucht, der am weitesten oben in der Hierarchie steht. Das ganze passiert natürlich über GetComponent() auf jedem Objekt. So wird jedes Element, dass sein Layout auf dirty setzen will, minimal einen Aufruf von GetComponent() nach sich ziehen. Jeder geschaltete Layoutcontroller vervielfältigt dieses Problem.
Wodurch wird ein Layout als dirty markiert?
Kurzform: Durch fast alles ...
Nur ein paar Beispiele:
Lösungen: Was kann man dagegen tun?
Kurz gesagt: Benutzt keinen Animator für die UI. Stattdessen solltet ihr Code und/oder Tweens verwenden um eure UI zu animieren. Für Tweens gibt es das sehr gute Package DotweenPro.
[Beispiel]
Warum ist ein Animator Setup, wie auf dem Standard-Button von Unity, schlecht?
Ein Animator wendet jeden Frame seine Werte auf die animierten Objekte an, egal ob sich Werte in der Animation verändert haben oder nicht. Das bedeutet, dass jeden Frame alle animierten Objekte als dirty markiert werden, was wie bereits beschrieben diverse Aktionen im Layout bzw. Canvas Code nach sich zieht.
Entsprechend ist der Animator nicht dafür geeignet States abzubilden - wie z.B. hover, selected im Standard-Button Beispiel - sondern sollte nur zum Abspielen von Animationen verwendet werden, da sich in diesem meist sowieso jeden Frame etwas verändert, was dann dirtying nach sich zieht.
Den Graphics Raycaster benötigt man auf jedem Canvas (und Sub-Canvas!) das (Touch-)Input erhalten soll. Tatsächlich ist er nicht wirklich ein Raycaster, sondern prüft ob sich ein Punkt innerhalb eines Rechtecks befindet und das für jedes RectTransform unter dem Canvas, dass als interaktiv markiert ist. Als interaktiv markiert sind alle Komponenten mit dem Toggle "Raycast Target" auf an (beispielsweise Image).
[Beispiel]
Faustregel: Achte darauf den Toggle auszuschalten, wo es Sinn macht!
Mit der Sorting Group gruppiert man ein GameObject und seine Childs als Einheit für das Rendern - ähnlich wie es das Canvas tut. Das bedeutet, dass außerhalb der Gruppe die Sortieroptionen und die Z-Position des Gruppen-Parents für alle Childs gelten.
[Beispiel]
Innerhalb der Gruppe werden Renderer nach den für sie geltenden Regeln sortiert: Beispielsweise gelten für Sprites Sorting-Layer und Wert, während Z zugunsten der Hierarchie ignoriert wird (erneut, wie beim Canvas). Bei 3D-Renderern wird nach Z sortiert und bei gleichem Z-Wert der Hierarchie nach.
[Beispiele]
Insbesondere bei 3D-Renderern ist wichtig, dass Sorting nur auf transparente Geometry angewendet wird. Wird der Render-Mode "Opaque" verwendet sortieren 3D-Renderer mit Sorting-Groups trotzdem über die Z-Position gegen andere Sorting-Groups.
[Beispiel]
Sorting groups sind für zwei Anwendungen wichtig:
Wie man seine UI am besten layered ist sehr stark vom Spiel abhängig. Um eine Idee davon zu haben kann man sich beispielsweise folgende Fragen stellen:
Die UI könnte ein klassisches HUD sein - in diesem Fall nutzt man ganz einfach den Modus "Screen Space - Overlay" und sortiert verschiedene Canvasse über den Sorting Wert.
In diesem Fall würde ich keinen "Screen Space - Camera" Modus verwenden. Diese Art von Canvas sortiert sich immer nach Abstand zur Kamera auf Z - ihr X- und Y-Wert ist immer 0. Entsprechend könnten Weltobjekte nun ungewollt vor der UI erscheinen und es wird unmöglich die Sortierung im Scene View nachzuvollziehen.
Canvas mit "World Space" ist dein Freund. Sortiert werden kann das Canvas dann über Abstand zur Kamera oder mittels Sortieroptionen.
Angenommen wir haben ein 2D-Spiel mit Seitenansicht. Es wäre denkbar, dass z.B. Texte zwischen Spielebene und Hintergrund auftauchen sollen.
[Beispiel]
Für diesen Effekt sollten wir "Screen Space - Camera" oder "World Space" verwenden. Mit beiden Optionen können wir entsprechend unserer Szene die UI entweder über Tiefe oder Sortieroptionen einsortieren. Wenn sich diese UI dem Bildschirm oder der Kamera anpassen soll ist "Screen Space - Camera" zu verwenden.
Ein solches Setup erlaubt es auch Partikelsysteme in der Welt vor bzw. hinter der UI zu rendern. Warum das sehr praktisch ist steht im Kapitel über Partikel.
Wenn UI gegen Welt sortiert wird stellt sich dann die Frage nach der Sortierung:
Meiner Meinung nach schließen sich diese beiden Optionen ein wenig aus und bieten unterschiedliche Vor- bzw. Nachteile. Das liegt vor allem an der zuvor beschriebenen einfachen Hierarchie - Sortieroptionen werden immer vor Z angewendet. Letztendlich muss die Wahl hier vor allem anderen mit der Sortierung der Spielszenen funktionieren.
Ich halte folgende Kombinationen für sinnvoll:
Eine Sortierung nach Tiefe bietet vor allem den "What you see is what you get" - Vorteil. Wenn wir im Scene View auf 3D schalten, können wir unser Layering ganz bequem überblicken.
[Beispiel]
Die verschiedenen Ebenen der Spielszene könnten mit einer Sorting Group versehen werden, damit man diese intern über Sortieroptionen sortieren kann.
[Beispiel]
Nachteil ist natürlich, dass sie nicht funktioniert, wenn Z nicht die Transparenzachse ist - also für Top-Down eher nicht zu gebrauchen.
Wenn die Transparenzachse oder die Szenenhierarchie eine Sortierung per Tiefe nicht zulässt, eignen sich die Sortieroptionen am besten, auch wenn sie die Sortierung unübersichtlicher machen.
Ein Mittelweg kann es sein allein die Sortierung der UI über Z zu regeln und für die Welt Sortieroptionen zu nutzen. Dafür würde man alle Canvasses auf ein Vordergrundlayer verschieben, das über dem Weltlayer liegt. So behält man sich den Überblick der Tiefensortierung bei.
[Beispiel]
[Beispiel - wie schaltet man ihn an?]
Mit dem Device Simulator kann man sehen, wie sich unter anderem die UI auf verschiedenen Geräten verhält. Es ist auch möglich das Gerät zu drehen und die Safe Zone anzeigen zu lassen.
[Beispiel]
Man sollte stets verschiedenste gängige Geräte testen - mindestens Android bzw. iOS jeweils als Phone und Tablet. Insbesondere bei der Safe Zone unterscheiden sich die Geräte sehr:
[Beispiel]
Apple macht die Safe Zone gerne symmetrisch und hat außerdem eine vertikale Safe Zone für den Home-Button.
[Beispiel]
Android ist hingegen oft asymmetrisch.
[Beispiel]
Tablets haben oft genug gar keine Safe Zone.
Um all diese Dinge sehen zu können und entsprechend mit Code oder Design zu reagieren, ist der Device Simulator unabdingbar.
Partikeleffekte für die UI sind von Unity nicht von Haus aus unterstützt. Man kann zwar ein herkömmliches Partikelsystem an Childs eines Canvas hängen - das führt dann zu dieser komisch wirkenden Mischung von Transform und RectTransform - aber das Sortieren funktioniert nur mäßig:
[Beispiele]
Ein weiterer Grund warum Partikel besser nicht in der UI sein sollten ist Performance. Partikelsysteme sind konstant in Bewegung und würden das Canvas immer wieder neu zeichnen lassen (mehr dazu im Kapitel Performance).
Besser ist es Partikelsysteme in der Welt zu belassen. Dann kann man sie auch einfacher gegen die UI sortieren, in dem man den richtigen Canvas Render Mode wählt (siehe Layering, Canvas).
[Beispiel]
Wenn man seine Partikel dennoch im Canvas haben möchte, um sich beispielsweise das Layouting zu erleichtern, kann man auf ein Rendertextur Setup zurückgreifen.
[Beispiel]
Hier werden die Partikel von einer separaten Kamera gerendert, deren Bild dann auf der Rendertextur angezeigt wird.
Zuletzt noch ein sehr gutes Package, was neben dem Rendertextur Ansatz auch noch andere Lösungen bietet: hier.
Tools für UI- oder UX-Design, je nach dem wie genau man mit dem Namen ist, helfen massiv bei der Arbeit an UI. Von Wireframes bis hin zu Click-Prototypen kann man damit alles erstellen und das meistens sogar kollaborativ. Entwickler können später als Betrachter hinzugefügt werden, damit sie alle Layouts, Abstände und Größen genauestens ins Spiel bringen können.
Figma ist ein cloudbasiertes UI-Tool, was ich in den meisten meiner Projekte verwendet habe.
[Beispiele]
-zeigen: Basic layout in figma, inspector
Komponenten sind wiederverwendbare Elemente im eigenen Design. Sie können alles Mögliche sein, von einem simplen Button bis hin zu einer kompletten Navigationsleiste. Ein paar der geläufigsten Kandidaten für Komponenten sind:
[Beispiel]
Sobald man eine Komponente erstellt hat, kann man Kopien von dieser im Projekt verwenden. Die Kopien der sog. Master-Komponente sind mit ihr verbunden, das heißt wenn sich die Master-Komponente ändert, werden sich auch alle Kopien entsprechend verändern. Die Kopien selbst können aber immer noch lokal geändert werden - so kann ein und derselbe Button an verschiedenen Stellen in unterschiedlicher Farbe erscheinen, vielleicht auch nur um rumzuprobieren. Man kann dann später die lokalen Änderungen auf die Master-Komponente anwenden, wenn man sie für alle Kopien übernehmen will.
Ein weiterer Vorteil ist, dass man Komponenten auch schachteln kann.
[Beispiel]
Im Grunde genommen kann man sich so eine eigene Bibliothek an UI-Elementen aufbauen, die dann in vielen Designs verwendet werden.
Mit Komponenten kann man sich viel Arbeit sparen, indem man Designs und strukturieren wiederverwendbar macht, während Änderungen am gesamten Design mit wenig Aufwand möglich sind.
Styles sind ähnlich wie Komponenten, nur das mit ihnen das Aussehen bzw. Eigenschaften von Elementen festgelegt werden. Dazu gehören Dinge wie Farben, Textgröße, Schlagschatten oder gar Einstellungen von Layout-Grids.
[Beispiel]
Der Vorteil ist dann, dass man durch Änderungen am Style alle Elemente verändert, die diesen Style verwenden. So könnte man beispielsweise den im Projekt verwendeten Font für Seitentitel austauschen.
[Beispiel]
Neben der erhöhten Iterationsgeschwindigkeit kann man so auch bestimmte Teile des eigenen Designs benennen, um z.B. die Verwendung einer Farbe deutlich zu machen, kann man einen Style mit dem Namen "Highlight Color" erstellen. Jedes neue Teammitglied, dass am UI-Design arbeitet kann dann über die Bibliothek auf diesen Style zugreifen und seine Verwendung verstehen.
Bei der Arbeit mit Prefabs orientiere ich mich an dem Workflow in Figma. So kann man stumpf für jede Master-Komponente aus Figma ein eigenes Prefab erstellen. Solche Prefabs nenne ich "Templates". Templates sind idR. nicht dafür gedacht wirklich selbst verwendet zu werden, sondern um als Ausganspunkt für Prefab-Varianten zu dienen. Beispielsweise würde ich einen fertigen Button als Template erstellen - jedoch Dinge wie z.B. Grafiken auf einer Variante ausdefinieren. Auf diese Weise erhält man die selbe Funktionalität, wie die Master-Komponenten in Figma: Größere Änderungen am Design des Buttons sind schnell einzupflegen, weil sie sich auf alle Varianten auswirken, die keine im Konflikt stehenden Änderungen aufweisen.
[Beispiel]
Styles lassen sich leider nicht so einfach umsetzen, ohne eigenen Code zu schreiben. Einzig bei TextMeshPro liegt schon eine Implementierung seitens Unity vor. Grob gesehen reichen Prefab-Varianten für einige Anwendungsfälle von Styles aus - aber mit einem Klick die Highlight-Farbe im gesamten Projekt zu ändern bleibt leider aus.
Oft lohnt es sich lieber noch ein Prefab oder eine Variante mehr zu erstellen, anstatt zu viel in einem einzelnen vereinigen zu wollen. Versionen für links und rechts sind ein gutes Beispiel dafür:
Es scheint zunächst verlockend, die Grafiken und das Layout innerhalb des gleichen Prefabs einzubauen, man spart sich so eine weitere Datei, die es zu verwalten gilt, aber beim Animieren sind rechts und links oft genug zu unterschiedlich - deshalb lieber eine Variante links und eine Variante rechts.
[Beispiel - speechbubble?]
Ich versuche innerhalb meines Projektes möglichst wenige lokale Änderungen zu haben, da diese eingehende globale Änderungen von Templates blockieren. Nach Möglichkeit sollten Änderungen lieber eine eigene Variante oder ein neues Prefab werden - wie immer gilt, dass von Fall zu Fall zu entscheiden ist. Änderungen innerhalb von Szenen sind besonders nervig für Versionskontrolle, weshalb ich die gesamte UI innerhalb von eigenen Prefabs produziere. Es gibt also z.B. keinen Button, der nur in einer Szene eine andere Farbe annimmt. Einzig die fertige Hierarchie bzw. das Layering findet am Ende in der Szene statt.
Im Grunde genommen habe ich gelernt, UI-Elemente in drei verschiedene Klassen aufzuteilen:
Beginnen wir mit der View:
Eine Gruppe von Views ist ein Element:
Ganz oben in der Hierarchie steht das Panel:
Diese Aufteilung soll Ordnung in die ganzen Elemente und Prefabs bringen, indem sie:
TODO: Idk beispiele oder genauer sagen, warum das gut ist?
Spätestens mit der Ankündigung des iPhone X wurden sogenannte "edge-to-edge" oder randlose Displays zu einem weitverbreiteten Design auf der Mobile-Plattform. Damit die UI nicht von Notches oder Flächen für Gesten (z.B. iPhone Home-Geste) überlagert wird, gibt es die Safe Zone. Innerhalb der Safe Zone ist garantiert, dass Elemente bedienbar und vollständig sichtbar sind.
Hier mal ein paar Beispiele aus dem Device Simulator:
[Beispiele]
Veraltete Apps, die Notches bzw. Safe Zone nicht korrekt unterstützen sehen inzwischen so aus:
[Beipiel]
Beim Aufbau und Design der eigenen UI sollte die Safe Zone unbedingt miteinbezogen werden. Damit verhindert man das,
Für das Design bedeutet die Safe Zone vor allem erst einmal weniger Platz für so gut wie alles. Beim Bau der UI stellt sich die Frage, wie man sich an die Safe Zone anpasst.
Ich habe hier ein Asset aus dem Store, mit samt Artikel zur Erklärung parat. Zusammengefasst erhält man über die Screen-Klasse ein Rect, welches die Maße der Safe Zone darstellt. Dieses Rect kann man dann mit den Maßen der vollen Auflösung verrechnen und so Werte für anchorMin bzw. anchorMax des anzupassenden RectTransforms erhalten, um dieses auf die Dimensionen der Safe Zone zu setzen. Zur Erinnerung: Die Anker Werte sind zwischen 0 und 1 - sie beschreiben wie viel des Rects auf einer Achse genutzt wird. Man errechnet also, wie viel die Safe Zone anteilig vom gesamten Bildschirm ausmacht.
Final stellt sich damit noch die Frage, auf welcher Ebene dieses Safe Zone einhaltende Script liegen sollte:
Die Antwort darauf hängt ganz vom Design ab - vor allem, ob das/die Panel/s einen Full Screen Hintergrund haben.
Stumpf ist Trumpf - wir passen einfach den gesamten Canvas auf die Safe Zone an. Daraus ergeben sich schnell zwei Probleme:
In beiden Szenarien muss man die Safe Zone Änderung quasi wieder zurückrechnen. Bei Hintergründen von Panels könnte man einfach ein großzügiges Maß an Padding hinzufügen, das ist jedoch ein wenig hacky und kann in Zukunft nicht mehr ausreichen, wenn wieder andere Display Dimensionen auf den Markt kommen. Am besten platziert man also eine Safe Zone auf Canvas Ebene, wenn man weiß, das Panels darunter sowieso keine Fullscreen-Grafiken oder Elemente am Displayrand haben werden.
[Beispiel]
Eine flexiblere Lösung kann es sein pro Panel zu entscheiden, ob dieses eine Safe Zone benötigt oder nicht. Auf diese Art und Weise können Safe Zone-konforme und nicht-konforme Panel auf dem gleichen Canvas existieren, was Hierarchie und Layering vereinfacht. Eine weitere Idee wäre es Panels unter dem Canvas in eine Safe Zone - konforme und eine nicht-konforme Gruppe aufzuteilen - allerdings kann das wieder zu Problemen beim Layering führen, wenn Panels aus zwei verschiedenen Gruppen gleichzeitig auftreten.
[Beispiele]
In manchen Fällen kann es sogar notwendig sein einzelne Elemente innerhalb eines Panels an die Safe Zone anzupassen oder diese ignorieren zu lassen. Das dritte Beispiel aus dem Artikel zeigt das ganz gut:
[Beispiel]
Die horizontalen blauen Streifen sollen fullscreen sein, entsprechend erhalten sie die Option nur auf der vertikalen mit der Safe Zone konform zu sein.
Man kann auch innerhalb eines Panels in Safe Zone-konform und nicht-konform unterteilen - eine beispielhafte Hierarchie wäre Panel → Background → Content mit Safe Zone. Ansonsten würde ich diesen Anwendungsfall als Randfall betrachten und ihn möglichst vermeiden, da die Hierarchie immer kleinteiliger bzw. komplexer wird.
Ich verwende drei verschiedene Wege um in meinen Layouts Abstände einzubauen:
Auf die Anwedungsgebiete, sowie Vor- und Nachteile möchte ich im Folgenden eingehen.
Der einfachste Weg ist es einen Wert für Spacing auf der Gruppe zu setzen.
Vorteil:
Nachteil:
Spacing als fixer Wert funktioniert am besten, wenn zuvor bereits absehbar ist, dass es problemlos eingehalten werden kann. Um dem Problem der fehlenden Flexibilität entgegenzuwirken, könnten die Childs der Gruppe flexible Größen haben, um eventuell zu schrumpfen oder zu wachsen - allerdings stellt sich hier die Frage, ob man festen Abständen so viel Priorität einräumen will.
Wichtig: Diese Spacing Variante unterstützt als einzige negative Werte, wodurch man Elemente überlappen lassen kann.
Zur Wiederholung: Wenn auf einer Layoutgruppe die Option Child Force Expand angewählt ist, werden die Childs so verteilt, dass sie die Gruppe maximal ausfüllen. Wird die Größe der Childs nicht zusätzlich von der Gruppe kontrolliert, kann Leerraum entstehen, wenn die Gruppe größer als die Summe ihrer Childs ist.
Vorteil:
Nachteil:
Auf diese Art und Weise lässt sich unkompliziert dynamisches Spacing erzeugen - allerdings nur bis zu einer gewissen Mindestgröße der Gruppe. Ausschlaggebend für die Richtung des Spacings ist die Option Child Alignment:
[Beispiele]
Anzuwenden ist diese Technik, wenn auf der Achse des Spacings keine dynamische Größe existiert - zum Beispiel eine Gruppe von Bildern mit fixer Höhe, welche dynamischen Abstand auf der horizontalen hat. Die Nachteile könnte man beispielsweise ausbessern, indem die Gruppe selbst eine ausreichende Minimum Size hat, durch die dann ein Mindestmaß an Spacing gewährleistet ist.
Man kann ebenfalls ganze, quasi leere (sprich ohne Grafik) Objekte für Spacing benutzen. Diese enthalten dann nur ein Layoutelement, was der Gruppe ihre Size mitteilt.
Vorteil:
Nachteil:
[Beispiele]
Diese Variante gibt einem die meiste Flexibilität und Kontrolle, bringt aber auch mehr Komplexität mit sich. Diese Komplexität kann sich auf das gesamte Projekt ausweiten, wenn man Spacer als Prefabs verwendet. In der Theorie könnte man ähnlich wie in UX-Tools das Spacing in mehreren Elementen der UI mit nur einer Änderung auf dem Prefab anpassen. Das klingt erstmal sehr praktisch, kann aber auch gleichermaßen tückisch sein - es wird viel Achtsamkeit im Umgang mit solchen Strukturen gebraucht. Genau deswegen ist es in den meisten Fällen leichter auf die zuvor genannten einfacheren Optionen zurückzugreifen.
Eine wirklich gute Anwendung ist das synchronisieren der Abstände über mehrere Panels. Nehmen wir an, dass unser Spiel ein HUD besitzt, was stehts am oberen Bildschirmrand ist. Andere Elemente auf der gleichen Ebene sollten einen Abstand zum HUD wahren, um dieses nicht zu überlappen. Natürlich kann jedes weitere Element nun schlicht einen festen Abstand nach oben aufweisen, welcher dann die Höhe des HUDs und eventuelles Padding ist - was passiert aber, wenn das HUD nun durch ein neues Design seine Höhe ändert? Man muss loslaufen und diesen Wert auf jedem anderen Element aktualisieren. Um diese Arbeit zu sparen, kann schlicht ein Spacer Prefab erstellt werden, welches die selben Maße wie das HUD aufweist. Jetzt muss bei einer Änderung des Designs nur noch das Spacer Prefab angepasst werden und nicht jedes einzelne Objekt. Diese Technik hilft ebenfalls, wenn das HUD eine flexible Höhe hat, z.B. für den Porträt-Modus.
[Beispiele]
Ähnlich wie beim Spacing kann manchmal auch beim Padding ein fixer Wert nicht ausreichend sein. Hierfür gibt es folgende Lösungen:
Vorteil:
Nachteil:
Indem man die Ankerpositionen korrekt wählt, kann man ebenfalls ein Padding relativ zur Größe des Parents erreichen.
Eine beispielhafte Konfiguration wäre Min (0.25,0) und Max (0.75, 1). Auf diese Art und Weise erhält man ein Padding von 25% auf der X-Achse, jeweils links und rechts.
[Beispiel]
Da das Padding immer relativ zum Parent ist, kann man leider keinen maximalen Wert für die Menge an Padding festlegen. Es bedeutet ebenfalls, dass das Padding nach Innen ist.
Zur Erinnerung: Bei Layoutcontrollern gibt es Priorisierung. Das Layoutelement hat die höchste Priorität und kann somit die Size der Layoutgruppe überschreiben. Wenn man dann die Layoutgruppe größer werden lässt, als deren Children das benötigen, entsteht Leerraum um die Gruppe herum - vorausgesetzt das die Option Child Force Expand auf der entsprechenden Achse nicht genutzt wird. Wo der Leerraum entsteht ist vom Alignment der Childs abhängig
[Beispiele]
Vorteil:
Nachteil:
Der eine Vorteil dieser Methode mag unscheinbar klingen, es ist jedoch nicht zu verachten, dass in dieser Variante die Padding-Einstellung noch gut nachvollziehbar ist und nicht so versteckt (wie bei der folgenden Variante).
Diese Methode funktioniert nur mit Images oder wenn Spacer Objekte innerhalb der Gruppe genutzt werden. Die Idee ist, dass wir Objekte größer werden lassen, ohne das optisch mehr Raum mit Grafik gefüllt wird. Wenn wir z.B. Spacern in einer Horizontalen Gruppe eine andere Höhe als die restlichen Elemente geben entsteht Padding auf der vertikalen Achse. Umgekehrtes funktioniert für die Vertikale Layoutgruppe - andere Breite für Spacer führt zu Padding auf der Horizontalen. Wenn wir Padding auf der kontrollierten Achse erzeugen wollen, fügen wir einfach am Anfang und Ende der Gruppe ein Spacer Objekt mit der Size des Paddings ein.
[Beispiele]
Ohne Spacer Objekte kann man das Ganze auch mit Images und der Option "Preserve Aspect Ratio" erreichen, da diese nicht mit Auto Layout kommuniziert. Allerdings ist man so auf eine Achse beschränkt, da die Images ansonsten wieder im Sinne der Aspect Ratio wachsen würden. Das ist aber eher ein Hack, als das ich es wirklich für gut empfinden würde.
[Beispiel]
Vorteil:
Nachteil:
Ich glaube eigentlich nicht, dass diese Methode empfehlenswert ist. Was man sich hier potenziell an Iterationszeit sparen kann wird durch die gestiegene Komplexität zunichte gemacht.
Bedenke: Wir können Layoutgruppen schachteln. Eine Layoutgruppe mit flexiblem Padding wäre dann also drei Objekte unterhalb einer weiteren Layoutgruppe - enstprechend ein Spacer, Layoutgruppe und ein weiterer Spacer.
[Beispiel]
Vorteil:
Nachteil:
Diese Variante bietet sich vor allem an, wenn die Layoutgruppe sowieso schon unterhalb einer anderen Gruppe liegt (Beispiel: Mehrere Zeilen Inhalt innerhalb Panels, also horizontale Gruppen unter einer vertikalen). Vielleicht will man auch andere Alignment Optionen nehmen oder Force Expand nutzen. Leider kann man wie gesagt nur auf der kontrollierten Achse Padding erzeugen - auf der anderen geht das nur mit einer der beiden zuvor beschriebenen Methoden.
Für die Benennung von meinen UI-Prefabs benutze ich lose das von Masahiro Sakurai vorgeschlagene Schema. Im Grunde genommen geht es darum selbst sortierende Namen zu erzeugen, indem man eine Hierarchie innerhalb der Namen einhält. Ein Beispiel: Nehmen wir an, dass wir den Button zum Schließen des Optionsmenü benennen wollen - ein möglicher Name wäre "Menu Options Button Close" mit Leerzeichen oder einfach Camel-Case "MenuOptionsButtonClose". Der Name entsteht durch eine Verkettung von Kategorien, die den Kontext der Verwendung immer weiter eingrenzen:
Der direkte Vorteil an dieser Benennung ist, dass sie innerhalb eines Ordners die Sortierung vorgibt. Beispielsweise werden alle Elemente des Optionsmenüs nebeneinander sein.
[Beispiel]
Bei Anzahl bzw. Umfang von Kategorien kann man nicht pauschal sagen, wie viele Kategorien benötigt werden bzw. wie groß der Umfang sein sollte. Beispielswiese könnte man die erste Kategorie "Menü" auch durch einen Ordner ersetzten. Die Entscheidung ist also ein wenig persönliche Präferenz, aber auch vom Projektumfang abhängig.
Ein weiterer Faktor ist die globale Suche: Wenn man nun z.B. "Options" in die Suche eingibt, erhält man alle zu dem Optionsmenü gehörigen Elemente - wenn man die Kategorie "Options" in einen Ordner verwandelt hat, findet man jetzt nur diesen. Es kann ebenfalls vorkommen, dass es Kollisionen gibt, wenn es beispielsweise mehrere Close Buttons in den zugehörigen Ordnern (z.B. Options, Shop) gibt - wird hier nach "Close Button" gesucht, erscheinen zwei Assets und man kann nur noch durch Blick auf Pfad oder Inspektor feststellen, welcher der richtige ist.
[Beispiel]
Sakurai verwendet in dem Video Abkürzungen, diese sparen Platz bei den immer länger werdenden Namen. Allerdings haben Abkürzungen immer den Nachteil, dass man sie erklären muss. Sobald also mehrere Leute an dem Projekt arbeiten müsste man eine Art Glossar für die Abkürzungen aufsetzen. Deswegen ist es meist unkomplizierter die Sachen einfach auszuschreiben.
Für Varianten oder fortlaufende Teile einer Animation kann man Buchstaben bzw. Nummerierung anfügen: Close Button a-c oder Attack Forward 01 - 05.