Communitygithub.com

downbelowdotxyz/game-ui-screens

Entwerfe, gestalte oder überprüfe die Menüs, HUDs, Ladebildschirme, Modale und Einführungsflüsse eines Spiels, sodass sie wie echte In-Game-Bildschirme wirken und nicht wie Webseiten – basierend auf einem einheitlichen Stilvertrag, der vom stärksten bestehenden Bildschirm abgeleitet wird, In-Game-Navigation und einer Viewport-Prüfmatrix. Verwende dies, wenn Bildschirme „seltsam aussehen“, „zu schlicht“, „gequetscht“, inkonsistent oder wie eine Website wirken, wenn du neue Bildschirme erstellst oder wenn du spielerorientierte Namen umbenennst.

Was ist game-ui-screens?

Diese Anleitung beschreibt eine Methode, um alle Bildschirme eines Spiels (Menüs, HUD, Ladebildschirme, Modale, Onboarding) so zu gestalten, dass sie sich wie ein Teil desselben Spiels anfühlen und nicht wie typische Webseiten. Der Ansatz beginnt mit einer vollständigen Bestandsaufnahme aller Bildschirme und der Extraktion eines gemeinsamen „Stilvertrags“ vom stärksten bestehenden Bildschirm (z. B. Titel oder Hauptmenü). Dieser Vertrag definiert Schriftarten, Farben, Hintergründe, Panel-Formen, Button-Zustände, Abstände und Bewegungen. Die Methode unterstützt verschiedene UI-Technologien wie Canvas-Overlay-DOM, Engine-UI oder In-Scene-UI und ist für Entwickler von Spiel-UIs konzipiert, die mit KI-Agenten wie Claude Code, Cursor oder Codex arbeiten. Sie wird auf Plattformen wie GitHub und in Code-Editoren genutzt, bietet eine klare Struktur für die Anwendung und Verifikation der Bildschirme und hilft dabei, Inkonsistenzen zu vermeiden und die Benutzererfahrung zu verbessern.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/downbelowdotxyz/downbelow-skills/tree/HEAD/skills/game-ui-screens
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

Game UI Bildschirme

Sorge dafür, dass sich jeder Bildschirm wie ein Teil desselben Spiels anfühlt. Arbeite vom besten eigenen Bildschirm des Spiels ausgehend, nicht von generischen Web-Stilen. Halte die Navigation spieltypisch und überprüfe jeden Bildschirm in den Größen, die die Spieler verwenden. Passe dich an die UI-Technologie an (DOM über einer Canvas, Engine-UI oder In-Scene-UI). Verwende game-foundation für den Bildschirmfluss selbst, falls verfügbar; diese Fähigkeit deckt ab, wie Bildschirme aussehen und sich verhalten.

1. Bestandsaufnahme

Liste jeden Bildschirm und jedes Overlay auf, einschließlich derer, die man leicht vergisst: Titel, Hauptmenü, jedes Modus-Menü, Garage oder Ausrüstung, Einstellungen, Lobby- oder Raumbildschirme, Teilnahme- und Einladungsflüsse, Laden, Pause, Ergebnisse, Fehler, leere Zustände, das HUD und reine Entwickler-Bildschirme. Notiere für jeden die Datei, wie er erreicht wird, wie er verlassen wird und ob er einen Server oder gespeicherte Daten benötigt, um angezeigt zu werden. Bildschirme, die den Spielserver benötigen, müssen mit diesem ausgeführt oder als nicht verifiziert gemeldet werden.

2. Extrahiere den Stilvertrag

Wähle den Anker: den Bildschirm, der bereits am meisten wie das Spiel aussieht (normalerweise der Titel oder das Hauptmenü). Schreibe seine Regeln auf, bevor du andere Bildschirme anfasst: Schriftarten und Titelbehandlung, Farbtokens, Hintergrund (Live-3D-Szene, unscharfer Hintergrund, Kunst), Panelformen, Button-Zustände (inaktiv, hover, fokussiert, gedrückt, deaktiviert), Abstandsskala, Bewegung und Soundsignale. Fasse die gemeinsamen Teile in Tokens oder gemeinsam genutzten Klassen zusammen, damit die Bildschirme nicht auseinanderdriften. Lese style-contract.md für die Vorlage und die In-Game-Konventionen.

3. Anwenden

  • Vollbild-Spiellayouts, keine Web-Karten. Kein Dokument-Scroll auf dem Desktop; Modale passen in den Viewport; lange Listen scrollen innerhalb ihres eigenen Panels.
  • Spielnavigation. ESC oder die Zurück-Taste verlässt jeden Bildschirm; Tastatur- und Gamepad-Fokus bewegt sich vorhersehbar mit einem sichtbaren Fokus-Zustand; die primäre Aktion ist offensichtlich.
  • Onboarding-Gates als Fluss. Wenn ein Name oder Profil vor bestimmten Modi erforderlich ist, frage in einem kurzen Startschritt danach (Namensfeld + Spielen), anstatt ein Menü voller gesperrter Schaltflächen zu zeigen. Behalte die gleiche Validierung in den Einstellungen bei, damit eine spätere Bearbeitung sie nicht zerstört.
  • Ein Eintrag, wo einer ausreicht. Bitte die Spieler nicht, zwischen Optionen zu wählen, die zum gleichen Ort führen (z. B. drei Spawnpunkte auf einer Karte); gib eine primäre Aktion und biete die Varianten im Spiel an.
  • HUD-Hierarchie. Lese hud-and-loading.md. Jede Zahl beschriftet, nichts, das wie Debug-Ausgabe aussieht, kontextbezogene Elemente nur wenn relevant.
  • Ladebildschirme haben Bewegung, die zum Spiel passt, echten Fortschritt, wo verfügbar, und kein Blinken bei kurzen Ladezeiten.
  • Abstände skalieren mit der Viewport-Höhe (clamp() oder Viewport-Einheiten), damit hohe Menüs weder zusammengequetscht noch auf großen Bildschirmen auseinandergezogen wirken.

4. Umbenennung von spielerorientierten Namen

Beim Umbenennen des Spiels, von Modi, Orten oder Gegenständen: suche nach jeder Schreibvariante (Groß-/Kleinschreibung, Leerzeichen, Bindestriche, Tippfehler) in UI-Strings, HTML-Titeln, Manifesten, Dokumentationen, Paketnamen und Speicherschlüsseln. Migriere gespeicherte Daten, wenn sich ein Speicherschlüssel ändert, damit bestehende Spieler ihr Profil behalten. Behalte interne IDs stabil, es sei denn, die Aufgabe erfordert ihre Änderung.

5. Überprüfen

Überprüfe jeden bearbeiteten Bildschirm bei 1440×900, 1280×720, 1024×600 und Telefongröße (375×812), plus den eigenen Zielen des Projekts. Verwende Screenshots und verwende __pt.layout() von playtest (oder eine gleichwertige Bounding-Box-Prüfung) für Seiten-Scroll, nicht erreichbare Steuerelemente und Überlappungen. Gehe jeden Eintritt und Austritt der Bildschirme durch. Melde Bildschirme, die du nicht öffnen konntest, inklusive Grund.

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community