...
Faustregel: Achte darauf den Toggle auszuschalten, wo es Sinn macht!
Sorting Group
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:
- Gruppieren von Objekten, die optisch eine Einheit sein sollen - z.B. Charakter aus mehreren Sprites,
- Anwendung von Sortieroptionen auf 3D-Renderer.
Layering - Beispiel
...
Device Simulator
[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.
UI Design Tools
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
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:
- UI Elemente (Button, Toggle, Slider etc,)
- Icons
- Firmenlogos oder andere Markenzeichen
- Platform Komponenten (für Android, iOS)
[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
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.
Prefabs
Workflow
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.
Struktur
Im Grunde genommen habe ich gelernt, UI-Elemente in drei verschiedene Klassen aufzuteilen:
- Panels,
- Elemente,
- Views.
Beginnen wir mit der View:
- Alles was mindestens eine Grafik (auch Text) hat ist grundsätzlich erstmal eine View,
- View ist die kleinste Einheit in der Hierarchie,
- Beispiel: Ein einzelner Button oder ein Icon.
Eine Gruppe von Views ist ein Element:
- Elemente haben idR. eine View und ggf. weitere Grafiken unter sich,
- Beispiel: Ein Button mit zugehörigem Erklärungstext.
Ganz oben in der Hierarchie steht das Panel:
- Ein Panel ist die größte Einheit und wird entsprechend nicht geschachtelt,
- Es kann sowohl Elemente, als auch Views und einzelne Grafiken unter sich haben,
- Beispiel: Ein Optionsmenü oder Inventar etc.
Diese Aufteilung soll Ordnung in die ganzen Elemente und Prefabs bringen, indem sie:
- Bei der Benennung hilft,
- Hierarchien und damit auch,
- Zuständigkeiten vorgibt.
TODO: Idk beispiele oder genauer sagen, warum das gut ist?
...
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:
- Ist die UI immer vorne?
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.
- Benutze ich Z als Achse für Sortierung von Transparenz?
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.
- Soll UI dynamisch Spielobjekten folgen?
Canvas mit "World Space" ist dein Freund. Sortiert werden kann das Canvas dann über Abstand zur Kamera oder mittels Sortieroptionen.
- Was ist wenn UI hinter Spielobjekten auftauchen soll?
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:
- Benutze ich Sortieroptionen oder Distanz zur Kamera bzw. Transparenzachse Z?
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:
- Alles sortiert sich nach Tiefe,
- Alles sortiert sich mit den Sortieroptionen,
- Global werden Sortieroptionen verwendet, aber UI sortiert sich intern nach Z.
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]
Device Simulator
[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.
UI Design Tools
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
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:
- UI Elemente (Button, Toggle, Slider etc,)
- Icons
- Firmenlogos oder andere Markenzeichen
- Platform Komponenten (für Android, iOS)
[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
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.
Prefabs
Workflow
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.
Struktur
Im Grunde genommen habe ich gelernt, UI-Elemente in drei verschiedene Klassen aufzuteilen:
- Panels,
- Elemente,
- Views.
Beginnen wir mit der View:
- Alles was mindestens eine Grafik (auch Text) hat ist grundsätzlich erstmal eine View,
- View ist die kleinste Einheit in der Hierarchie,
- Beispiel: Ein einzelner Button oder ein Icon.
Eine Gruppe von Views ist ein Element:
- Elemente haben idR. eine View und ggf. weitere Grafiken unter sich,
- Beispiel: Ein Button mit zugehörigem Erklärungstext.
Ganz oben in der Hierarchie steht das Panel:
- Ein Panel ist die größte Einheit und wird entsprechend nicht geschachtelt,
- Es kann sowohl Elemente, als auch Views und einzelne Grafiken unter sich haben,
- Beispiel: Ein Optionsmenü oder Inventar etc.
Diese Aufteilung soll Ordnung in die ganzen Elemente und Prefabs bringen, indem sie:
- Bei der Benennung hilft,
- Hierarchien und damit auch,
- Zuständigkeiten vorgibt.
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,
- Elemente der UI durch Rundungen in den Ecken des Displays abgeschnitten werden,
- Bedienelemente von der Notch verschluckt werden oder sonst wie nicht bedienbar sind,
- beim Interagieren ungewollt Systemgesten angesteuert werden.
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:
- Canvas
- Panel
- Element
Die Antwort darauf hängt ganz vom Design ab - vor allem, ob das/die Panel/s einen Full Screen Hintergrund haben.
Safe Zone auf dem gesamten Canvas
Stumpf ist Trumpf - wir passen einfach den gesamten Canvas auf die Safe Zone an. Daraus ergeben sich schnell zwei Probleme:
- Was ist mit Fullscreen-Hintergründen bzw. Panels?
- Was ist, wenn ich Elemente bündig zum Displayrand platzieren muss?
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]
Safe Zone pro Panel
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]
Safe Zone pro Element
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.
Flexibles Spacing
Ich verwende drei verschiedene Wege um in meinen Layouts Abstände einzubauen:
...