Interface-Karten
Ihre gesamte 2D-Oberfläche ist eine Karte — HUDs, Menüs, Buttons, Beschriftungen, Dialoge. Nicht 3D-Text auf einer Fläche, keine Textur mit Wörtern darauf.
Karten werden wie eine gewöhnliche Oberfläche gesetzt, vor der 3D-Ansicht, deshalb bleiben sie auf jeder Entfernung und bei jeder Bildschirmgröße scharf. Text in einer Karte ist lesbar; Text auf einer Fläche in der Welt ist der Kamera ausgeliefert.
Eine Karte ist eine Ressource, und Sie hängen sie an ein Objekt.
Zwei Arten, sie zu platzieren
Overlay füllt den Bildschirm. Das ist Ihr HUD, Ihr Menü, Ihr Dialogfenster.
Anchored heftet die Karte an die Bildschirmposition eines Objekts — ein Name über einer Figur, ein Preis über einem Produkt.
Sie behält die Größe, in der Sie sie entworfen haben, und verschwindet, wenn ihr Objekt hinter die Kamera gerät. Sie ist ein Etikett an etwas, kein Objekt in der Welt. Wollen Sie etwas, das beim Weggehen kleiner wird, nehmen Sie 3D-Text.
Was Sie bauen können
Die üblichen Bausteine sind alle da:
container · text · image · gif · video · separator · grid · gallery
pager · tabs · state · indicator · slider · input · select · switch
Ein Button ist ein text oder ein container mit Hintergrund, etwas Innenabstand, einem Rahmen
und einer Aktion. Das klingt nach Mehrarbeit und ist tatsächlich das Gegenteil: Sie bekommen genau
den Button, den Ihr Entwurf verlangt, statt gegen einen vorgegebenen anzukämpfen.
Für alles Wiederkehrende (eine Zeile in einer Liste, ein Chip, eine Karte in einer Galerie) bauen Sie einmal ein Template und verwenden es wieder.
Eine Karte kann mehrere eigene Screens enthalten und zwischen ihnen wechseln, ganz ohne die Szene einzubeziehen. Genau so baut man ein Panel mit Reitern oder einen mehrstufigen Dialog: Die Szene muss es nie erfahren.
Eigene Komponenten und Fremd-Erweiterungen wie Lottie werden nicht gerendert.
Eine Karte etwas tun lassen
Eine Karte hat eigene Variablen und kann sich damit selbst verändern — ein- und ausblenden, Text tauschen, Screens wechseln, Timer laufen lassen. Alles, was rein die Oberfläche betrifft, sollte in der Karte bleiben.
Muss sie an die Szene heran, gibt es drei Wege, mit steigender Mächtigkeit:
| Weg | Wofür |
|---|---|
| Eine eingebaute Kartenaktion | nur Oberflächenzustand — ein Reiter, ein Schalter, ein Timer |
| Ein Szenenschritt an der Aktion | einen Szenenschritt ohne Code ausführen: Szene wechseln, Animation abspielen |
| Eine benannte Aktion plus ein Skript | Spiellogik |
Eine Aktion auf einer Karte löst außerdem ein gewöhnliches Ereignis aus, das die Hierarchie hinaufwandert — ein Ereignis auf der Szene kann also einen Druck aus jeder Karte darin abfangen, nach Namen oder jeden beliebigen.
Mit einem Skript sprechen
Ein Skript kann die Variablen einer Karte lesen, schreiben und auf Drücke lauschen:
const ui = ctx.getDivKit(entity);
ui.set('score', (v) => v + 1);
ui.subscribe('lives', (v) => {
/* die Anzeige hat sich geändert */
});
ui.onAction('restart', () => {
/* der Neustart-Button wurde gedrückt */
});
Das ist das Muster, das man verinnerlichen sollte: Der Spielzustand lebt im Skript, und die Karte zeigt ihn an. Nicht andersherum.
Auf Bilder und Video zeigen
Zeigen Sie in einer Karte auf eine Projektressource statt auf eine URL. Verweise funktionieren auch in Ausdrücken, ein Bild anhand einer Bedingung auszuwählen verhält sich also erwartungsgemäß.
Bevor Sie zu entwerfen beginnen
- Eine Karte wird nur gezeigt, solange ihre Szene aktiv ist — Oberfläche schwappt also nie zwischen Szenen über.
- Ein Screenshot der 3D-Ansicht enthält Ihre Karten nicht. Prüfen Sie Oberflächen in der Vorschau.
- Kartenvariablen sind nicht zwischen Teilnehmern geteilt und werden beim Neuladen zurückgesetzt. Alles, was geteilt werden oder überleben muss, gehört in ein Skript.
- Der visuelle Editor zeigt einen kuratierten Satz Eigenschaften, lässt handgeschriebene Layouts aber unangetastet — sie überstehen das Bearbeiten, sie haben nur kein Eigenschaften-Panel.
Weiter: Material-Graphen — wenn die Standardmaterialien nicht reichen.