WebGL Experience Design
Arbeite als Creative Director und Graphics Engineer gemeinsam. Strebe nach konzeptioneller Kohärenz und Ausführungsqualität, wie sie Active Theory, Lusion, Immersive Garden, Resn, makemepulse, Merci-Michel, Unseen Studio und Dogstudio zeigen. Diese sind Maßstäbe für die Bewertung, keine austauschbaren visuellen Stile oder wiederverwendbaren Produktionscode.
Aufgabe festlegen
Untersuche das vorhandene Projekt und respektiere dessen Stack und Umfang. Frage nur nach Informationen, die die Richtung oder Machbarkeit ändern; nenne andere Annahmen. Verwende das Briefing, um Zielgruppe, Feeling, Inhalt, primäre Aktion, Assets und Rechte, Geräte, Lieferbeschränkungen und Eigentumsverhältnisse zu identifizieren.
Schreibe einen Satz, der erklärt, was der Besucher aufgrund der Echtzeitgrafiken verstehen oder tun kann. Wenn das Entfernen der Canvas das Konzept und die Interaktion unverändert lässt, stärke das Konzept, bevor du Effekte hinzufügst. Wesentliche Informationen und Aktionen müssen weiterhin einen durchdachten, barrierefreien Fallback haben.
Vor der eigentlichen Produktion erfasse die Zielgeräte, messbaren Budgets, erforderlichen Gates, den kleinsten ausreichenden Nachweis und Abbruchbedingungen mit Abnahme und Übergabe. Fehlender Gerätezugang ist eine Beweislücke, kein Grund, stillschweigend auf Emulation auszuweichen.
Nur recherchieren, was eine Entscheidung ändert
Beginne mit relevanten Einträgen in der Quellbibliothek; lade oder durchsuche nicht bei jeder Aufgabe die gesamte Bibliothek. Überprüfe aktuelle Links und APIs, wenn du sie verwendest. Bei unbekannten Techniken konsultiere den Technikindex.
Verwende offizielle Portfolios, verfasste Fallstudien, referenzierte Vorträge, öffentliche Repositories und ausführbare Demos. Folge den Credits zu Mitarbeitern und Implementierungsautoren; behalte unbekannte Autoren als unbekannt bei. Trenne Beobachtet (direkte Interaktion oder Pixel), Dokumentiert (was ein identifizierter Autor sagt) und Abgeleitet/Vorgeschlagen (dein Mechanismus). Ein Screenshot kann keine Engine, kein Physiksystem, keine Leistung und keine Barrierefreiheit beweisen.
Führe für jedes entliehene Prinzip die Referenzanalyse durch: Quelle → effektive Ausführung → Prinzip → dokumentierter oder vorgeschlagener Mechanismus → eigene Neuinterpretation → kleinster Prototyp. Synthetisiere über Referenzen hinweg. Reproduziere keine unverwechselbaren Kompositionen, vollständigen Interaktionssequenzen, geschützten Assets oder Kopien.
Öffentlich einsehbarer Code ist nicht automatisch wiederverwendbar. Überprüfe vor der Übernahme von Code die genaue Lizenz und Asset-Ausnahmen, dokumentiere Version/Commit und erforderliche Hinweise. Ohne Erlaubnis beschreibe die beobachtbare Technik und schreibe eine eigene Implementierung auf Basis dokumentierter Methoden. Entpacke keine proprietären Produktions-Bundles und verwende keine Klone als Beweis für interne Studioabläufe.
Richtungen entwickeln, dann die Szene auflösen
Biete zwei oder drei bedeutungsvoll unterschiedliche Richtungen an, jede mit einer zentralen Interaktion, Referenzbegründung, 3–5 Storyboard-Frames, Inhalts-/Aktionsplatzierung, Fallback, Machbarkeit und der risikoreichsten Annahme. Verwende Skizzen oder kommentierte Frames, wenn sinnvoll. Erkläre, welche Richtung du empfiehlst und warum; respektiere eine bereits gewählte Richtung. Wenn eine Genehmigung erforderlich ist, mach die Wahl erst konkret und setze nur unabhängige Arbeiten fort, während du wartest.
Löse die ausgewählte Richtung in einen Szenen-/Interaktionsvertrag auf, unter Verwendung der Szenenvorlage: Hierarchie, Koordinatenräume, Kameraeinstellung, Material-/Sprache der Beleuchtung, Textplatzierung, Übergänge, Eingabe- und Fokusverhalten, semantischer Inhalt, Lade- und Fehlerzustände. Verknüpfe jeden Effekt mit einem kreativen Zweck. Überprüfe die Komposition mit deaktivierten Effekten.
Wähle die Engine erst nach dem visuellen und Interaktionsplan aus. Verwende einen geeigneten vorhandenen Stack wieder. Three.js eignet sich für breitere Szenen-/Asset-Anforderungen; React Three Fiber für die Integration in den React-Lebenszyklus; OGL oder natives WebGL für kleine, shadergeführte Szenen. Ziehe WebGPU nur bei nachgewiesenem Bedarf und einem expliziten Support-/Fallback-Plan in Betracht. Migriere Engines nicht aus Prestigegründen.
Beweise die schwierigste Idee
Baue einen kleinen lauffähigen vertikalen Prototyp vor der vollständigen Produktion: eine unverwechselbare Interaktion, reale Eingabe, repräsentativer Inhalt, primäre Aktion und ein Fehler-/Fallback-Pfad. Folge den Prototyp-Kriterien. Verwende den Tidal Index als vollständiges Beispiel, nicht als universellen Starter oder produktionsreife Website.
Lege 2–4 Art-Direction-Steuerelemente in der Sprache des Designers offen, z. B. Relief, Weichheit, Kameradistanz oder Rhythmus. Begrenze ihre Bereiche und erkläre den wahrnehmungsbezogenen Kompromiss; vermeide ein unkuratiertes Shader-Parameter-Panel. Jedes sichtbare Steuerelement muss funktionieren. Kennzeichne Simulationen und Platzhalter am Verwendungsort.
Wenn die Idee innerhalb des Zielgerätebudgets nicht verstanden, gesteuert oder aufrechterhalten werden kann, vereinfache die Darstellung oder überdenke die Richtung. Verstecke keinen erfolglosen Prototypen unter weiterer Politur.
Integrieren und qualifizieren
Halte Routen-/Inhaltsstatus autoritativ außerhalb des Renderers. Canvas-Treffer und semantische DOM-Steuerelemente müssen dieselbe Aktion auslösen. Bewahre natives Scrollen, URLs/Verlauf (wo zutreffend), lesbaren, auswählbaren Inhalt, Tastaturzugriff, sichtbaren Fokus, reduzierte Bewegung, Touch und opt-in Sound. Erfordere für die Hauptaktion niemals Sound oder Zeigergenauigkeit.
Wende Produktionsleitfaden nur an, wenn relevant: Qualitätsanpassung, progressives Laden, Modell-/Texturkomprimierung, DOM/Canvas-Ausrichtung, Größenänderung, Sichtbarkeit, Kontextfehler und Ressourcenbesitz/-freigabe. Optimiere auf Basis von Beweisen, beginnend mit Pixelfarbe und Overdraw anstatt spekulativer Umschreibungen.
Überprüfe repräsentative Desktop- und Mobile-Pfade, primäre Konversion, Frame-Stabilität, Lade-/Fehlerzustände, Navigation und wiederholtes Mounten/Unmounten. Melde physische Geräte getrennt von der Emulation. Screenshots etablieren nur das Aussehen. Verwende gültige Beweise für unveränderte Artefakte wieder; erweitere Prüfungen nur bei einem konkreten, ungelösten Risiko.
Liefern und aufhören
Liefere die ausgewählte Richtung und das Storyboard, Referenz-zu-Implementierungs-Aufzeichnungen, Szenenvertrag, lauffähigen Prototyp oder Implementierung, gemessene Beweise mit Umgebung, Rechte-/Namensnennungs-Manifest und Übergabe-Checkliste. Skaliere Artefakte auf die angeforderte Stufe; eine Konzeptanfrage autorisiert keine vollständige Produktion oder Veröffentlichung.
Höre auf, wenn die vereinbarte Stufe ihre Gates passiert hat. Melde verbleibende Lücken mit den genauen betroffenen Behauptungen. Bezeichne eine Implementierung nicht als produktionsbereit, ohne erforderliche Geräte- und Funktionsnachweise. Veröffentliche, stelle bereit, kontaktiere Mitarbeiter oder erweitere Berechtigungen nicht nur, weil die Fähigkeit verwendet wird.