Game UI Frontend
Überblick
Verwenden Sie diese Fertigkeit immer dann, wenn das Spiel eine sichtbare Benutzeroberfläche benötigt. Die Aufgabe besteht nicht darin, generische Dashboard-UI zu erstellen. Die Aufgabe besteht darin, eine lesbare, thematische Browser-Spieloberfläche zu erstellen, die das Spielerlebnis unterstützt.
Standardannahme: Erstellen Sie die Spielwelt in Canvas oder WebGL und textlastige UI im DOM.
Frontend-Standards
- Legen Sie die visuelle Richtung fest, bevor Sie codieren.
- Genre und Fantasy
- Materialsprache
- Typografie
- Farbpalette
- Bewegungston
- Verwenden Sie CSS-Variablen für das UI-Theme.
- Bauen Sie eine klare Hierarchie auf.
- Kritische Kampf- oder Überlebensinformationen zuerst
- Sekundäre Werkzeuge als zweites
- Selten genutzte Einstellungen hinter Menüs oder Schubladen
- Schützen Sie zuerst das Spielfeld, besonders in 3D.
- Der erste Bildschirm sollte sich innerhalb weniger Sekunden spielbar anfühlen.
- Standardmäßig einen primären persistenten HUD-Cluster und höchstens einen kleinen sekundären Cluster verwenden.
- Die Mitte des Spielfelds während des normalen Spiels freihalten.
- Das untere mittlere Spielfeld während des normalen Spiels größtenteils freihalten.
- Überlieferungen, Feldnotizen, Questdetails und lange Steuerungslisten hinter Schubladen, Umschaltern oder Pause-Oberflächen platzieren.
- Kontextbezogene Aufforderungen und temporäre Hinweise permanenten Box-Panels vorziehen.
- Stellen Sie sicher, dass Overlays auch bei Bewegung lesbar bleiben.
- Verwenden Sie Hintergrundpanels, Kantenbehandlung, Kontrast und zurückhaltende Unschärfe, wo nötig.
- Entwerfen Sie von Anfang an für Desktop und Mobilgeräte.
- Entwerfen Sie 3D-UI um Kamera- und Eingabesteuerungsgrenzen herum.
- Kamera-Steuereingaben pausieren oder blockieren, wenn Menüs, Dialoge oder pointergesteuerte UI aktiv sind.
- Halten Sie Pointer-Lock, Drag-to-Look und Menüinteraktionszustände explizit.
3D-Standardvorgaben
Für Erkundungs-, Fortbewegungs- oder Third-Person-Starter-Gerüste bevorzugen Sie dieses UI-Budget:
- einen kompakten Ziel-Chip oder Statusstreifen am Rand
- einen temporären Steuerungshinweis oder Interaktionsprompt
- eine optionale einklappbare sekundäre Oberfläche wie ein Tagebuch, eine Karte oder ein Questlog
Öffnen Sie nicht beim ersten Laden jede Informationsoberfläche. Die Szene sollte lesbar sein, bevor der Benutzer eine tiefere UI öffnet.
Als standardmäßige Implementierungsbeschränkung für 3D-Browserspiele:
- kein immer aktives Vollbreiten-Header plus Multi-Card-Body plus Full-Width-Footer-Layout
- keine großen Bildschirmmitte- oder unteren mittleren Overlays während der normalen Bewegung
- nicht mehr als etwa 20-25% des Viewports, die von persistentem HUD auf Desktop bedeckt werden, es sei denn, der Benutzer fordert explizit ein dichteres Layout
- auf Mobilgeräten auf einen schmalen Stapel oder kontextbezogene Chips reduzieren, bevor das Spielfeld mit größeren Panels bedeckt wird
Prompting-Regeln
Wenn das Modell gebeten wird, Spiel-UI zu entwerfen oder zu implementieren, fügen Sie hinzu:
- die Spiel-Fantasy
- die Kamera oder den Blickwinkel
- die Spieleraktionen
- die HUD-Ebenen
- den Kamera- oder Steuerungsmodus, wenn das Spiel 3D ist
- den Bewegungston
- Desktop- und Mobilerwartungen
- Spielfeldschutz- und Offenlegungsstrategie
- explizite Anti-Patterns, die vermieden werden sollen
Verwenden Sie ../../references/frontend-prompts.md für konkrete Prompt-Formen.
Bewegungsregeln
- Bevorzugen Sie wenige aussagekräftige Übergänge gegenüber ständigen Mikroanimationen.
- Reservieren Sie starke Bewegungen für Zustandsänderungen, Belohnungen, Gefahren und Onboarding.
- Respektieren Sie reduced-motion-Einstellungen für nicht-essentielle Animationen.
- Vermeiden Sie, dass 3D-HUD-Bewegungen mit Kamerabewegungen konkurrieren.
Wie es gut aussieht
- HUD-Elemente sind lesbar, ohne die Szene zu verflachen.
- Menüs fühlen sich der Spielwelt zugehörig an, nicht wie ein SaaS-Admin-Panel.
- Das Layout passt sich sauber an verschiedene Bildschirmgrößen an.
- Pointer-, Tastatur- und Spielzustands-Feedback sind offensichtlich.
- In 3D-Spielen geraten Menü- und HUD-Zustände nicht mit der Kamerasteuerung oder dem Pointer-Lock in Konflikt.
- In 3D-Spielen behält die erste spielbare Ansicht den größten Teil des Viewports für Bewegung, Zielen und räumliches Lesen.
- Die persistente Informationsdichte ist niedrig genug, dass Screenshots immer noch wie Spielszenen aussehen, nicht wie UI-Kompositionen.
Anti-Patterns
- Generische App-Dashboard-Layouts
- Flaches Platzhalter-Styling ohne Theme
- Standard-Schriftarten ohne Absicht
- Dichte Overlays, die das Spielfeld verdecken
- Große Titel-Karten oder mehrteilige Notizen, die über einer live spielbaren Szene liegen
- Gleich gewichtete Box-Panels, die um jeden Rand des Viewports verteilt sind
- Steuerungen, Ziele, Notizen und Überlieferungen, die alle beim ersten Laden aufgeklappt sind
- Vollbreite obere und untere Leiste mit großen immer aktiven mittleren oder Body-Panels im 3D-Spiel
- Übermäßige Bewegung auf jedem Element
- Canvas-only-UI, wenn DOM klarer und günstiger wäre
- HUD-Steuerungen in die 3D-Szene zu erzwingen, wenn Standard-DOM klarer wäre
- Kamera-Eingaben unter Modals oder Inventar-Panels aktiv zu lassen
Referenzen
- Gemeinsame Architektur:
../web-game-foundations/SKILL.md - Prompt-Rezepte:
../../references/frontend-prompts.md - Low-Chrome-3D-Layout-Muster:
../../references/three-hud-layout-patterns.md - React-gehosteter 3D-UI-Kontext:
../react-three-fiber-game/SKILL.md - Playtest-Review:
../../references/playtest-checklist.md