HOUSE DUCK · AUTOMATIC TRANSLATION
Spielcharakter-Design mit Prompts | House Duck Vibe Coding
Wenn man die KI bittet, einen Spielcharakter zu erstellen,
erhält man recht schnell ein überzeugendes Bild.
Das Problem war das Danach.
Man bat darum, dieselbe Person erneut zu zeichnen, aber das Gesicht änderte sich,
beim Ändern des Gesichtsausdrucks veränderte sich sogar die Kleidung,
und als es für den Spielbildschirm verkleinert wurde, verschmolzen Augen und Mund zu einer Einheit.
Betrachtet man nur ein einzelnes Bild, gefällt es einem,
aber wenn man mehrere nebeneinander legt, sah es oft nicht mehr nach demselben Spiel aus.
Hübsche Bilder zu generieren und
Spielcharaktere zu erschaffen, waren zwei verschiedene Dinge.
Selbst wenn ein einziges Prompt ein Bild lieferte, das einem gefiel,
war es eine ganz andere Frage, ob dieses Bild im Spiel auch wirklich Bestand hatte.
Bei Project K, Quirky Ball
und während der Arbeit an einem Nachfolgeprojekt,
für das noch nicht einmal ein Spieltitel feststand, habe ich das gelernt.
Ein einziges gut gelungenes Bild war am gefährlichsten.
Die frühen Charakterzeichnungen von Project K
zeigen heute noch sehr deutlich die Spuren generativer Bilder.
Betrachtete man nur dieses eine Bild, schien der Charakter Persönlichkeit zu haben.
Da wir jedoch die Merkmale der Welt schnell vermitteln wollten,
und deshalb immer wieder ähnliche äußere Bedingungen einfügten,
glichen sich alle Kandidaten für die Führungspersonen plötzlich in Alter und Statur.
Zwar gab es nun viele Gesichtsausdrücke,
aber wenn man die Namen verdeckte, war es kaum möglich, sie sofort voneinander zu unterscheiden.
Anstatt also die Anzahl der Figuren zu erhöhen,
ging ich dazu über, Gesichtsform, Statur, Frisur und die Silhouette der Kleidung
zuerst stärker voneinander zu differenzieren.
Sie bestanden zwar die automatischen Prüfungen problemlos
und auch Bildgröße und Dateiformat stimmten.
Als wir sie jedoch auf dem tatsächlichen Mobilbildschirm einsetzten,
blieben feine Details wie Haare, Falten in der Kleidung und Glanzeffekte erhalten,
was den Eindruck erweckte, als würden sie nicht zur Pixel-Grafik des Spiels passen.
Dass eine Datei in Ordnung war, bedeutete noch lange nicht, dass auch das Bild gut war.
Schließlich verwarf Project K auch den Ansatz, einen stärkeren Pixelfilter zu verwenden,
und kehrte dazu zurück, zuerst ein originales 3D-Modell einer Person ordnungsgemäß zu erstellen
und daraus dann Porträts, Profil- und Kartenbilder abzuleiten.
Auch das obige Bild stellt kein finales Spiel-Asset dar.
Es kommt einer derzeit freigegebenen Richtlinientafel für Charaktere nahe,
und das originale 3D-Modell für das eigentliche Spiel wird noch erstellt.
Es war zudem äußerst wichtig,
nicht so zu tun, als sei die Arbeit bereits abgeschlossen, nur weil man eine passende Richtung gefunden hatte.
Ich wandelte die Prompts von gefühlsbetonten Beschreibungen in konkrete Produktionsanweisungen um.
Anfangs dachte ich,
dass das Hinzufügen vieler Adjektive wie „cool“, „edel“ oder „filmreif“ die Ergebnisse verbessern würde.
Mittlerweile mache ich es genau umgekehrt.
Ich schreibe zuerst auf, welche Rolle dieser Charakter hat,
wie groß er auf dem Bildschirm dargestellt wird
und was sich auf keinen Fall verändern darf.
Rolle: Eine Führungspersönlichkeit, die auf dem Mobilbildschirm sofort erkennbar ist
Unterscheidungsmerkmale: Gesichtsform, Statur, Frisur und die Silhouette des langen Mantels
Fixierung: Vorder-, Seiten- und Rückansicht derselben Person, identische Kleidung und charakteristische Farbe
Schattierung: Cel-Shading mit 2 bis 3 Stufen, fokussiert auf Grundfarben und Schatten
Verboten: Ähnlichkeit mit realen Personen, Hautrauschen, winzige Falten, Text und Wasserzeichen
Prüfung: Augen, Nase, Mund und Rolle müssen auch bei einer Verkleinerung auf die tatsächliche Spielgröße erkennbar sein
Dies ist nicht der ursprüngliche Prompt, der damals verwendet wurde.
Es handelt sich um eine erneute Zusammenfassung der nach mehreren Fehlschlägen übrig gebliebenen Produktionsbedingungen
im Format eines Prompts.
Außerdem erstelle ich nicht mehr Dutzende auf einmal.
Ich generiere zunächst nur einige wenige Hauptcharaktere,
teste sie in der echten Benutzeroberfläche sowie im Spiel und gehe erst dann zur nächsten Charge über.
Es ging schneller, zuerst Kriterien für Ablehnungen festzulegen, anstatt einfach die Anzahl der Generierungen zu erhöhen.
Quirky Ball wurde erst durch weniger Details zu einem stimmigen Charakter.
Quirky Ball hatte anfangs ebenfalls nicht das Gesicht von heute.
Zeitweise wurde sogar versucht, Gesichter auf gewöhnliche Kugeln zu setzen,
Der rote, sechseckige Quorky lächelte mit einem breiten, zahnigen Grinsen.
Wenn alles auf dem Bildschirm wie eine Figur aussah,
verwischte es tatsächlich, wer der Hauptcharakter sein sollte.
Daher entfernten wir die Gesichter der normalen Kugeln
und behielten nur Quorky als Charakter mit vier sichtbaren Augenpartien und dicken Augenbrauen,
dessen einer Mundwinkel nach oben gezogen war.
Es war nicht damit getan, nur den Gesichtsausdruck zu korrigieren.
Seinen Namen zu nennen, zu erklären, warum er im Labor eingesperrt war,
und je nach Spielsituation zu blinzeln, zu lächeln, sich zu sorgen und zu provozieren –
erst dann begann die rote Form als Charakter gelesen zu werden.
Cutscenes durchliefen einen ähnlichen Prozess.
Anfangs wurden Wissenschaftler und Maschinen als einfache Formen gezeichnet.
Später erhielten wir zwar Entwürfe für Wissenschaftler und Ausrüstung durch generative Bilder,
aber diese Ergebnisse wurden nicht einfach so ins Spiel übernommen.
Wir reduzierten die Farben auf fünf, löschten den weißen Hintergrund
und fixierten Größe sowie Pixel-Skalierung, um sie in einem einzigen Atlas neu zusammenzufassen.
Erst nachdem sie auf dieselbe Norm zugeschnitten waren,
wackelten das Gesicht des Wissenschaftlers und die Größe der Maschine bei Szenenwechseln nicht mehr.
Gute Nachbearbeitungsregeln überlebten länger als gute Prompts.
Beim noch namenlosen Nachfolgeprojekt wurde absichtlich kein finaler Charakter erstellt.
Der frühe Prototyp des Nachfolgers
war eher ein Timing-Spiel ganz ohne Charaktere.
Beim Reboot wurden zwar Enten, Gänse und Tauben hinzugefügt,
aber die Vögel, die man jetzt sieht, sind per Code erstellte Low-Poly-Grayboxen.
Dies ist noch kein finales Charakterdesign.
Stattdessen wurden zuerst die Rollen festgelegt.
Die Ente wurde als Charakter für Führung und Gleichgewicht,
die Gans für Verteidigung und Gewicht
und die Taube als Charakter zum Erstellen von Pfaden eingeteilt.
Auch wenn das Modell nicht hübsch ist,
wird zuerst darauf geachtet, ob Ziehen, Kollision, Deckung und Belohnung richtig ablesbar sind.
Die Überprüfung des Spaßfaktors durch externe Spieler hat es ebenfalls noch nicht bestanden.
Deshalb wurden nicht im Voraus massenhaft finale Charaktere der Zelle 3D erschaffen,
sondern es wurde bei dem Plan gestoppt, zunächst nur das Original einer Entenart zu prüfen und dann zu erweitern.
Denn selbst wenn man einem Spiel ohne Spaß noch viele hübsche Charaktere hinzufügt,
wird daraus kein unterhaltsames Spiel.
Ein Spiel ist nicht allein dadurch fertig, dass einem die Assets gefallen.
Wenn ein Charakterbild gut gelingt,
hat man plötzlich das Gefühl, das Projekt sei schon weit fortgeschritten.
Auch ich habe jedes Mal, wenn ich eine neue Zeichnung eines Vogels in den Bildschirm einfügte,
mir eingeredet, das Spiel würde ziemlich vielversprechend aussehen.
Ob das Spiel jedoch so viel Spaß macht, dass Spieler es noch einmal starten,
ob die Software so weit fertig ist, dass Speichern, Anmeldung und Zahlung nicht versagen,
ob die UI so eindeutig ist, dass selbst Neulinge sie verstehen,
ob die Interaktion so reaktionsschnell ist, dass sie bei einem Tastendruck sofort reagiert,
und ob dies alles bis zum Marketing führt, das auf die Existenz des Spiels aufmerksam macht –all das
lässt sich nicht durch eine einzige Charaktergrafik lösen.
Im Gegenteil: Je besser die Assets werden,
desto höher schrauben die Spieler auch ihre Erwartungen an das Spiel.
Assets lassen die Startlinie gut aussehen.
Aber was ein Spiel letztendlich antreibt,
sind Spielspaß und Reife.
Wenn ein Prompt gut funktioniert und ein geliebter Charakter dabei herauskommt,
darf man sich freuen.
Das bedeutet lediglich, dass das Projekt an diesem Tag gut vorangekommen ist,
aber noch lange nicht, dass das Spiel ein Erfolg ist.
Am nächsten Tag heißt es wieder spielen, verbessern
und die Reaktion einer einzelnen Taste sowie den Spaß der ersten 10 Minuten überprüfen.
Es gibt noch zu viel zu tun, bis das Spiel fertig ist, als dass man sich von jedem Hoch und Tief mitreißen lassen könnte.