HOUSE DUCK · AUTOMATIC TRANSLATION
Spiele-Design mit Vibe-Coding, der Grund, warum ich als Absolvent des Industriedesigns kein einziges Asset selbst erstellt habe | Quirky Ball
Um es vorwegzunehmen,
obwohl ich Industriedesign studiert habe,
habe ich die Spiel-Assets von Quirky Ball nicht selbst erstellt.
Das bedeutet, dass ich weder Illustrationen einzeln gezeichnet,
noch Buttons in Photoshop exportiert,
noch Symbole manuell verfeinert habe.
So sind sie also nicht entstanden.
Dennoch fügt sich die Atmosphäre des Spiels immer mehr zu einem stimmigen Ganzen zusammen.
Anfangs kam mir das selbst etwas seltsam vor.
Ich habe Design studiert, zeichne aber ausgerechnet die Grafiken für mein eigenes Spiel nicht selbst.
Wenn man ein Spiel jedoch bis zum Ende fertigstellen will,
war dieser Ansatz letztlich genau der richtige.
Nur weil man Design studiert hat, muss man nicht jede Grafik eigenhändig zeichnen.
Wenn man sich mit Industriedesign beschäftigt,
wirkt es oft so, als könne man hervorragend zeichnen.
Aber das Design, das ich gelernt habe,
glich eher dem Ordnen von Problemen
als dem Erstellen hübscher Bilder.
Es geht darum zu bestimmen, wer diesen Bildschirm betrachtet,
was zuerst verstanden werden muss
und welche Handlungen ganz natürlich angeregt werden sollen.
Das ist die Aufgabe der Entscheidungsfindung.
Bei Quirky Ball war meine Rolle im Grunde genau dieselbe.
Anstatt Murmeln selbst zu zeichnen,
habe ich festgelegt, welche Form sie haben müssen, um auf den ersten Blick unterscheidbar zu sein.
Anstatt Wissenschaftler eigenhändig in Pixel zu fassen,
habe ich beurteilt, wie gut dieser Charakter die schräge Laboratmosphäre
des Spiels vermittelt.
Keine Grafiken zu zeichnen bedeutete nicht, kein Design gemacht zu haben.
Wenn man zuerst mit den Assets beginnt, wird das Spiel niemals fertig.
Das Beängstigendste bei der Entwicklung von 1 ist nicht, dass man etwas nicht herstellen kann.
Es ist die Tatsache, dass immer mehr Dinge hinzukommen,
während das Spiel nach wie vor nicht lauffähig ist.
Selbst wenn man nur einen einzigen Startbildschirm gestaltet,
benötigt man Hintergründe, Logos, Buttons, Symbole,
Abzeichen, Pop-ups und Charaktere.
Hätte ich versucht, all das von Hand fertigzustellen,
bevor ich mit der Programmierung beginne,
würde ich wahrscheinlich immer noch am ersten Bildschirm sitzen
und Farben auswählen.
Daher habe ich die Reihenfolge geändert.
Zuerst habe ich einen spielbaren Bildschirm erstellt
und unpassende Stellen direkt im laufenden Spiel korrigiert.
Die benötigten visuellen Elemente wurden schnell mithilfe von KI und Code generiert,
und nur die überlebenden Elemente wurden in Designregeln zusammengefasst.
Da ich nicht auf fertige Assets warten musste,
konnte ich Bildschirme wesentlich schneller miteinander vergleichen.
Ein Großteil von Quirky Ball wird durch Regeln statt durch Bilder dargestellt.
Wenn man das Projekt genauer betrachtet, stellt man überraschenderweise fest,
dass weitaus mehr Bildschirme durch Code als durch Bilddateien gerendert werden.
Das Gesicht und die Glanzlichter der Murmeln,
die Ränder und Schatten der Karten,
der Druckzustand der Buttons sowie kleine Abzeichen und Symbole
setzen sich direkt im Spiel zusammen.
Der Vorteil dieses Vorgehens liegt darin,
dass eine einzige Korrektur gleich mehrere Bildschirme verbessert.
Wenn man die Größe der abgerundeten Ecken,
die Richtung der Schatten
und die Akzentfarben als feste Regeln definiert,
muss man für jede Shop-Karte kein neues Bild mehr erstellen.
Ob Pakete, Währungen, Tickets oder Kosmetika –
selbst wenn der Inhalt unterschiedlich ist,
sie wirken stets, als würden sie zum selben Spiel gehören.
Das war natürlich nicht von Anfang an so aufgeräumt.
Jeder Button hatte eine andere Farbe,
der Stil der Symbole war uneinheitlich
und die Reihenfolge der Informationen variierte von Karte zu Karte.
Anstatt jedes Element mühsam einzeln zu verschönern,
habe ich zuerst die gemeinsamen Regeln korrigiert,
wodurch sich der gesamte Bildschirm rasant zu ordnen begann.
Das Design, das ich umgesetzt habe, bestand vor allem darin, auszuwählen und wegzulassen.
Durch Vibe-Coding erhält man Ergebnisse in extrem kurzer Zeit.
Das Problem dabei ist jedoch, dass nicht nur gute Resultate schnell entstehen.
Es entstehen auch schick wirkende Bildschirme, die nicht zum Spiel passen,
Symbole, die völlig aus dem Rahmen fallen,
und schwer lesbare Farbkombinationen, die sich unkontrolliert häufen.
Deshalb habe ich am häufigsten folgendes getan:
nicht etwa Neues zu erschaffen,
sondern zu vergleichen und zu verwerfen.
Ich habe den Ausführungsbildschirm aufgenommen,
geprüft, was zuerst ins Auge fällt,
und das Problem in einem Satz beschrieben.
Ich habe den modifizierten Bildschirm erneut betrachtet
und ihn wieder verworfen, wenn er sich noch unnatürlich anfühlte.
Für den Ranglistenbildschirm galt derselbe Prozess.
Anstatt nur bloße Ranglistenzahlen aneinanderzureihen,
habe ich das Siegerpodest, meinen Rang, Saisoninformationen
sowie die Zugänge zu den verschiedenen Ranglisten
so übersichtlich angeordnet, dass sie auf einen Blick erfassbar sind.
Design bedeutete hier keine Dekoration, sondern die Festlegung der Informationsreihenfolge.
Ein Button, den man nicht versehentlich drücken kann, war wichtiger als ein hübscher Button.
Allein dadurch, dass man den Spielbildschirm hübsch gestaltet,
steigt die Vollständigkeit noch nicht.
Man muss auch designen,
wie sich die Finger der Spielenden tatsächlich bewegen.
In Quirky Ball gibt es einen Bildschirm, auf dem man
bei einem Stufenaufstieg eine von zwei
Entwicklungsrichtungen auswählen kann.
Wenn jedoch die Finger,
die unmittelbar zuvor schnell auf den Bildschirm getippt hatten, in dieser Haltung verharren,
kann es passieren, dass man direkt nach dem Aufpoppen des Fensters
eine ungewollte Auswahl betätigt.
Deshalb bleibt der Auswahl-Button für die ersten 1.5 Sekunden
abgedunkelt und nimmt keine Eingaben entgegen.
Nach Ablauf dieser Zeit kehren Farbe und Kontrast zurück
und der Button wird aktiviert.
Nur wenn der verblasste Zustand und der klare Zustand sich deutlich voneinander unterscheiden,
verstehen die Spielenden sofort,
ob eine Aktion jetzt möglich ist.
Solche Details vergisst man leicht,
wenn man lediglich einen einzigen Screenshot ästhetisch gestaltet.
Wenn man das Spiel jedoch kontinuierlich ausführt und währenddessen entwickelt,
stößt man schließlich darauf.
Die Vollständigkeit des Spieldesigns, wie ich sie verstehe,
entspringt solchen kleinen Sicherheitsvorkehrungen.
Das Design vollendet sich nicht automatisch nur dadurch, dass eine KI es erstellt hat.
Eine KI kann Bildschirme zwar schnell erstellen.
Aber sie weiß nicht, welcher Bildschirm wirklich den Charakter von Quirky Ball widerspiegelt.
Welcher Button grösser dargestellt werden muss,
welcher Scherz beibehalten und welche Dekoration verworfen werden sollte,
und ob Text auf einem Mobilbildschirm tatsächlich lesbar ist –
das muss am Ende ein Mensch entscheiden.
Meine Aufgabe bestand nicht darin,
die KI zu bitten, einmal etwas Tolles zu erschaffen,
und die Arbeit damit abzuschließen.
Ich habe das Spiel ausgeführt,
aufgenommen,
das Problem konkret benannt
und den Prozess des erneuten Vergleichens wiederholt.
Letztlich ist der Moment beim Vibecoding,
in dem ein Gespür für Design gefragt ist,
nicht der Moment des Erschaffens, sondern der des Auswählens.
Würde ich es genauso machen, wenn ich es noch einmal erschaffen würde?
Wahrscheinlich würde ich es genauso machen.
Ich würde nicht von Anfang an ein perfektes Asset-Paket schnüren,
sondern mit spielbaren Bildschirmen beginnen.
Und sobald Formen und Farben erkennbar werden,
die wiederholt verwendet werden,
würde ich sie zu Designregeln zusammenfassen.
Anstatt selbst zu zeichnen,
werde ich mehr beobachten,
präziser formulieren
und gnadenloser verwerfen.
Der Grund, warum ich, obwohl ich Design studiert habe,
kein einziges Asset selbst erstellt habe,
liegt nicht daran, dass ich die Kunst aufgegeben hätte.
Es liegt daran, dass ich eine Designmethode gewählt habe,
mit der man auch alleine ein Spiel bis zum Ende fertigstellen kann.