Über Unitys Versionsverwaltung und Clouddienste lassen sich Projekte mit anderen Personen teilen. Dabei erhält die eingeladene Person eine Info-E-Mail ohne Links oder weiterführende Informationen. Auch die Unity-Support-Strukturen sind hier wenig hilfreich. Wie kommt man an die Projektsourcen ran?
Die E-Mail
Die Person, die zu einem Projekt eingeladen wird, erhält eine automatische E-Mail mit folgendem Text, der aber keine Links oder Downloadinfos liefert:
Die Einladungs-E-Mail sagt nichts dazu, wie man an das Projekt rankommt.
Hello,
You have been invited by (Name des Einladenden), to join project: (Titel des Projekts) as a user. This is a project associated with organization: (Name von Organisation/Team).
Sincerely, The Unity Team
Zugriff aufs Projekt erhalten
Der Weg, um an die Projektdaten ranzukommen, führt direkt über Unity Hub, das Zugriff und Download übernimmt.
1. Wechsle die Organisation in Unity Hub
1.1 Gehe in Unity-Hub und klicke oben rechts auf den Benutzernamen.
1.2 Geh dann im Popup nochmal auf den Benutzernamen, dort wo Switch organisation steht.
1.3 Darunter wiederum sollte die Organisation des Einladenden erscheinen. Klicke darauf.
Im Hub ist die neue Organisation verfügbar.
2. Füge das neue Projekt hinzu
2.1 Wechsle zum Bereich Projekts im Unity Hub.
2.2 Klicke auf den Add-Schalter und dann auf Add from repository.
Im Projekttab kann ein Projekt aus dem Repository hinzugefügt werden.
3. Lade das neue Projekt herunter
3.1 Im sich öffnenden Fenster sollte das Projekt erscheinen. Wähle es aus und klicke auf Next.
3.2 Folge den weiteren Anweisungen, um das Projekt runterzuladen.
Das neue Projekt erscheint in der Liste.
4. Projekt öffnen
Das neue Projekt wird nun auf den lokalen Computer runtergeladen und kann wie jedes andere Projekt geöffnet werden. Wahrscheinlich wird Unity-Hub nach dem Hinzufügen direkt den Editor öffnen. Darin ist auch ein Bereich für die Versionsverwaltung zu finden, mit dem sich bearbeitete Daten synchronisieren lassen.
Zusammenfassung
Wenn Du zu einem Unity-Projekt eingeladen wirst, bekommst Du zwar eine Info-E-Mail, doch leider ohne Infos zur Annahme der Einladung. Gehe in Unity-Hub, wo Du das Projekt über „Add from repository“ direkt runterladen und öffnen kannst.
Um eine Figur in Blender mit einer Armature zu versehen, muss ein Mesh mit dieser verbunden und anschließend der Einfluss jedes Knochens auf jeden Vertexpunkt festgelegt werden. Um die Auswirkungen zu sehen, ist das Umschalten der Modi auf beiden Objekten nötig, was unglaublich mühsam ist. Folgendes Skript erlaubt es, mit einem Klick umzuschalten.
Ausgangssituation ist eine Blender-Szene mit einem Mesh und einer Armature, die miteinander durch Parenting verbunden wurden.
Erzeuge einen Fensterbereich mit Texteditor und lege dort einen neuen Textblock namens ModusUmschalten an.
Text in der Blenderdatei anlegen
Kopiere folgenden Code und füge ihn in den neuen Textblock ein:
# gamedev-profi.de - 28.11.2025
# Wechselt per Klick zwischen Weight Paint und Pose Mode.
import bpy
# --- KONSTANTEN: Namen Ihrer Objekte anpassen ---
MESH_NAME = "Kind"
ARMATURE_NAME = "KindArmature"
# --------------------------------------------------
def toggle_weight_pose_mode():
"""Schaltet zwischen Weight Paint und Pose Mode um."""
mesh_obj = bpy.data.objects.get(MESH_NAME)
armature_obj = bpy.data.objects.get(ARMATURE_NAME)
if not mesh_obj or not armature_obj:
print(f"FEHLER: Mesh '{MESH_NAME}' oder Armatur '{ARMATURE_NAME}' nicht gefunden.")
return
# Überprüfen, ob die Armatur aktiv ist UND im Pose Mode
is_in_pose_mode = (bpy.context.view_layer.objects.active == armature_obj) and (armature_obj.mode == 'POSE')
# 1. Fall: Aktueller Zustand ist POSE-MODE -> Wechsel zu WEIGHT-PAINT
if is_in_pose_mode:
print("Wechsle von Pose Mode zu Weight Paint...")
# 1.1 Zurück zum Object Mode
if bpy.context.object and bpy.context.object.mode != 'OBJECT':
bpy.ops.object.mode_set(mode='OBJECT')
# 1.2 Alle Objekte abwählen
bpy.ops.object.select_all(action='DESELECT')
# 1.3 Mesh und Armatur auswählen
mesh_obj.select_set(True)
armature_obj.select_set(True)
# 1.4 Das MESH muss aktiv sein, um darauf Weight Paint auszuführen
bpy.context.view_layer.objects.active = mesh_obj
# 1.5 In den Weight Paint Modus wechseln
bpy.ops.object.mode_set(mode='WEIGHT_PAINT')
# 2. Fall: Aktueller Zustand ist NICHT POSE-MODE (vermutlich Weight Paint oder Object Mode) -> Wechsel zu POSE-MODE
else:
print("Wechsle zu Pose Mode...")
# 2.1 Zurück zum Object Mode
# Dieser Schritt ist ESSENZIELL, um den Weight-Paint-Modus sauber zu verlassen
if bpy.context.object and bpy.context.object.mode != 'OBJECT':
bpy.ops.object.mode_set(mode='OBJECT')
# 2.2 Alle Objekte abwählen
bpy.ops.object.select_all(action='DESELECT')
# 2.3 Nur die Armatur auswählen
armature_obj.select_set(True)
# 2.4 Die ARMATUR MUSS aktiv gesetzt werden
# Nur auf dem aktiven Objekt kann der Modus gewechselt werden
bpy.context.view_layer.objects.active = armature_obj
# 2.5 In den Pose Modus wechseln
bpy.ops.object.mode_set(mode='POSE')
# Skript ausführen
toggle_weight_pose_mode()
Ändere im Code in Zeile 7 und 8 den Namen zum Namen des Meshs und der zugehörigen Armature.
Du kannst jetzt per Klick auf den Play-Button dieses Python-Skript ausführen und so sofort zwischen Pose-Mode und Weight-Paint-Modus umschalten. So ist eine viel schnellere visuelle Kontrolle der Gewichtung durch Ändern der Pose und Durchführen von Korrekturen im Weight-Paint-Modus möglich.
Ergebnis: mit einem Klick den Modus auf Armature und Mesh für die Bearbeitung von Weightpaint oder Pose umschalten.
Mein Spiel-Projekt Fart Fiasco ist nach vielen Jahren in ungewissem Zustand zu einem Ende gekommen und auf Steam letztlich final veröffentlicht. Lief dieses Projekt besonders gut? Nicht so richtig. Lief es besonders schlecht? Eigentlich auch nicht. Irgendwie war es von all meinen Projekten eines der chaotischsten. Zeit für eine Post-Mortem-Rückschau.
Wie alles begann
Irgendwann im Sommer 2016 fiel mir ein Stofftier in die Hände. Die ungewöhnlich kugelrunde Körperform dieser Kuh fand ich super witzig und begeisterte mich sofort.
Es dauerte auch nicht lange, bevor die Ballonform den Gedanken weckte, dass diese Kreatur flugfähig sein muss. Dabei erscheint es nur logisch, dass der Wiederkäuer abhebt, weil ihn ein übermäßiges Volumen an Verdauungsgasen enorm aufbläht. Die Idee für eine interaktive Interpretation in Form eines Computerspiels war geboren.
Brachte das Projekt ins Rollen: die Blähkuh.
Farting Apps und andere Trends
Ich hatte relativ schnell einen Prototyp gebastelt, den ich nicht öffentlich, aber für individuelle Gespräche in der Tasche hatte, als ich im August 2017 mein bis dahin laufendes Projekt A Room Beyond auf der gamescom ausstellte. Dabei kam unter anderem auch zu Tage, dass sich zu dieser Zeit Farting Apps besonders in Frankreich einer zunehmenden Beliebtheit erfreuten. Diese Spaßprogramme spielen häufig lediglich Geräusche ab und haben kaum tiefergehende Funktionalität, was aber nicht verhindert, dass die Downloadzahlen teils sogar im zweistelligen Millionenbereich liegen. So primitiv diese Art von Humor auch erscheinen mag, so amüsiert er Menschen nicht erst heute, wie man am Beispiel einer legendären Show-Einlage am Moulin Rouge um 1900 sieht, von der es sogar ein Video gibt. Von Shakespeare, Mark Twain und Jonathan Swift („Gullivers Reisen“) sei Flatulenz-Humor bekannt und selbst der älteste aufgezeichnete Witz der Welt fällt angeblich unter diese Kategorie. An sich sollten das also scheinbar relativ gute Markt-Voraussetzungen für mein Spielthema sein.
Eine Gelegenheit für Spiele
Ein weiterer Trend, der zumindest in meiner Wahrnehmung zu dieser Zeit verstärkt aufkam, waren die Gelegenheitsspiele. Mit dem um 2018 veröffentlichten (und inzwischen schon wieder eingestellten) Facebook Gameroom flutete eine Welle von Casual Games die Spielewelt. Allen voran wuchsen die Spiele des Casual-Königs King, sowie diverse Varianten von Aufbausimulationen, die sich oft in landwirtschaftlichen Motiven bewegten, wie zum Beispiel Zynga’s FarmVille. Vor allem der niedlich-bunte Bauerhof-Look von Farm Heros Saga stellte eine große Inspiration für mein Spielprojekt dar, das mittlerweile den selbstironischen Namen Fart Fiasco trug.
Links eine sehr frühe Skizze der Kuh, rechts die fertige Zeichnung in Adobe Illustrator CS3.
Mir war früh klar, dass es sich bei Fart Fiasco um ein Gelegenheitsspiel handeln soll, das auf extrem einfacher, minimalistischer Spielmechanik beruht. Herausforderungen, die auf Impuls, Reaktion und Geschick basieren, sollten mit Physiksimulation und klar abgegrenzten Leveln zu einem kurzweiligen, aber auch kurzfristigen und jederzeit unterberechbaren Spielerlebnis führen. Es bot sich hierfür an, ein Spiel für Mobilgeräte zu entwickeln. Ein entscheidender Fehler, wie sich herausstellen sollte.
Zwei Aspekte waren für mich ausschlaggebend, um Fart Fiasco für Mobilgeräte zu entwickeln:
Das einfache Gelegenheitsspielprinzip ist eher für Smartphones mit Touchscreen geeignet als für Desktop.
Der Mobile-Markt ist enorm groß und hat somit viel Potenzial zur Vermarktung.
Allerdings zeigte sich, dass diesen vermeintlich attraktiven Zielen eine ganze Menge unerwartete Hindernisse gegenüberstehen, von denen nur einige technischer Natur sind.
Eingabeformen: Klick oder Touch?
Die Kernsteuerung der Kuh geschieht über Tippen und Drehen, was sich gut auf Fingereingaben abbilden lässt. Weil der Bildschirm jedoch auch Eingabe-Elemente wie den Menü-Knopf enthält, muss die Eingabe dabei lokal begrenzt werden.
Im zweidimensionalen Spielbrett darf Klicken/Tippen die Kuh nur innerhalb des Spielfelds steuern, dort aber unabhängig davon, wo genau hin getippt wird. Menükomponenten sollen beim Antippen dagegen nicht die Kuh steuern, sondern die Eingabeelemente. Dabei sind Überlappungen auch dreidimensional zu berücksichtigen, d.h. wenn des Menü aufgeklappt ist, soll dieses die Eingaben abfangen und nicht das darunterliegende Spielbrett.
Der einfachste Lösungsansatz bestand darin, ein unsichtbares Rechteck im 2D-Grafikstapel einzufügen, das mittels Pointer-Events Klicks abfängt, grafisch ganz einfach ins Spielfeldlayout ausgerichtet werden kann und dessen Interaktionsereignisse Verdeckungen automatisch berücksichtigen.
Der Tap-Catcher ist ein normalerweise unsichtbares (hier pink gefärbtes) Rechteck im Canvas-System, das Ereignisse von Mausklick oder Fingertippen über Pointer-Events erkennt.
Bei der Gestaltung der Programmoberfläche musste ich zudem darauf achten, dass Eingabeelemente groß genug sind, um sie mit der im Vergleich zu Mausklicks sehr groben Fingereingabe bequem treffen zu können. Spezialeingaben wie zum Beispiel das Drehen der Kuh per Tippen und Ziehen des Fingers waren nicht direkt mit Unity-Boardmitteln möglich, so dass ich diese Lücke mit dem Touch Kit-Modul schließen musste.
Bildformat
Bei PC-Desktop-Spielen liegen Bildschirmproportionen häufig in Querformaten vor, die nur relativ gering variieren, so dass man sich z.B. um 16:9 oder 16:10 kümmern muss. Zwar verlangt das auch schon ein gewissermaßen responsives Layout der HUD-Elemente, doch ist die Situation bei Mobilgeräten deutlich komplizierter. Die Bildschirmformate der vielen verschiedenen Handys auf dem Markt unterscheiden sich oft drastisch. Soll das Spiel auf dem Handy auch noch sowohl im Hoch- als auch Querformat funktionieren, erhöht das den Entwicklungsaufwand für das Bildschirm-Layout.
Die Hauptfrage, die sich dabei aber stellt ist eigentlich: Wie testet man schnell und einfach, wie sich das Spiel in den vielen unterschiedlichen Bildschirmformaten verhält und ob sich das Layout überall gut zugänglich und fehler- bzw. überschneidungsfrei anpasst? Hierfür kam bei Fart Fiasco das Editor-Plugin Universal Device Preview zum Einsatz, das den Spielbildschirm in einem Zug in unterschiedliche Formate zeichnet und so unglaublich viel Zeit spart.
Das automatisierte Erzeugen von Screenshots für verschiedene Geräte-Bildschirme zeigt umgebungsabhängige Layoutfehler auf einen Blick.
Monetarisierung
Leider hat sich im App-Markt das Konzept kostenloser Spiele durchgesetzt und das reine Premium-Modell ist eher unüblich. Weil der Produktverkauf zum damaligen Zeitpunkt eine wichtige Einnahmequelle für mich war, musste ich eine Monetarisierungsstrategie finden. Der Verkauf digitaler In-Game-Items kam aber eher nicht in Frage, weil hierfür das gesamte Produktkonzept zu dieser Verkaufsform passen muss. Das Spiel und seine Inhalte erfordern psychologisch präzise gesetzte Gestaltungsentscheidungen. Mikro-Transaktionen bringen auch langfristig einen gewissen Technik- und Verwaltungsaufwand mit sich.
Unity Ads und die DSVGO
Die offensichtliche, weit verbreitete Lösung besteht aus dem Schalten von Werbung innerhalb des Spiels. Hierfür hatte Unity bereits seit längerem seine Unity Ads-Lösung im Angebot, die eine nahtlose Integration in die Game-Engine versprach. Abgesehen davon, dass sich die Unity Services in den letzten Jahren ständig verändert haben, was einiges an Pflegeaufwand mit sich zog, kam die Umsetzung der Datenschutzgrundverordnung ins Rollen. Die jetzt umzusetzenden sehr strengen Regularien zogen eine enorme Last an technischer und rechtlicher Umsetzung nach sich. Zwar hatte Unity relativ schnell reagiert und das nötige Einholen von Nutzerzustimmungen in ihre Ads-Bibliothek integriert, doch blieb sowohl ein gewisser Verwaltungsaufwand als auch ein bedrohlicher Beigeschmack hinsichtlich der rechtlichen Risiken für Produktanbieter. Und das noch zusätzlich zur damals ohnehin schon datenschutzrechtlich eher ungewissen Praxis der Datensammlung durch Unity.
Die Unity-Ads-Integration im Spiel erforderte wegen der DSGVO nun ausdrückliche Zustimmung zu personalisierter Werbung.
Der klassische Weg
Da die Ads-Lösung technisch wie auch hinsichtlich DSGVO in den Kinderschuhen zu stecken schien, warf ich diesen Ansatz wieder aus meiner Software raus und kam zur Freemium-Lösung zurück, die aus einer simplen kostenlosen Basisversion sowie einer kostenpflichtigen Vollversion bestand.
Zwischenzeitliche Experimente mit Marketplace-Mechanismen für erwerbbare Booster.
Zunächst ging ich davon aus, dass sich das Umschalten zwischen Basis- und Vollversion mit einem In-Game-Kaufmechanismus realisieren ließe. Das hätte den Vorteil, dass alles innerhalb der selben Softwareversion liefe und der Status über Abfragen des Kaufstatus im Benutzerkonto synchronisiert werden könnte. Kurz zusammengefasst funktionierte das so leider nicht. Hauptproblem war noch nicht einmal die Abwicklung des Kaufs, sondern die Behandlung von Rückerstattungen, wie sie in den USA z.B. bei Softwarekäufen möglich sind. Wurde der Kauf storniert, so hat mein Spielcode dies nicht in Erfahrung bringen können, d.h. ein einmal freigeschaltetes Spiel blieb auch nach Kaufstornierung für immer freigeschaltet. Dies war ein Problem der Google-API selbst, das auch in den Entwicklerforen diskutiert wurde und für das es damals auch seitens der Google-Entwickler keine echte Lösung gab – wenngleich ich mich frage, wie das all die anderen Produkte in der Vergangenheit lösten.
In-Game-Werbescreen zum kostenpflichtigen Update auf die Vollversion.
Letztlich bestand der Ausweg darin, von der sich sehr unzuverlässig anfühlenden In-Game-Update-Variante zu einem klassischen Zwei-Versionen-Modell zu wechseln. Durch eigene Compiler-Switches hatte ich mein Spiel so programmiert, dass Unity sowohl eine Demo-Version als auch in eine Vollversion aus der gleichen Projektbasis erzeugen konnte.
Build Automation
Würde ich nun für Android und iOS jeweils eine Demo- und eine Vollversion bauen, so käme ich schon auf vier nötige Erstellungsvorgänge, deren manuelle Konfiguration und Auslösung schnell umständlich wurde. Daher suchte ich nach einer Möglichkeit des schnelleren Umschaltens und Erstellens plattformspezifischer Spielversionen und landete letztlich bei Super Unity Build. Damit konnte ich nicht nur mehrere Plattformziele definieren und auf Knopfdruck gesammelt erstellen lassen, sondern auch gleich noch Pre- und Postprocessing-Schritte automatisieren, wie z.B. Dateien zu kopieren oder das Programmsymbol für Demo- und Vollversion zu ändern.
Automatisierte Buildvorgänge erleichtern die Erstellung mehrerer Versionen erheblich.
Mit der Erstellung von plattformspezifischen Datenpaketen ist das Produkt allerdings noch längst nicht für Mobilgeräte verfügbar. Neben der technischen Anbindung ist auch die Publikation im Store nötig, was einige neue unerwartete Probleme mit sich brachte.
Auf dem Mobile-Markt sind vor allem Google (Android) und Apple (iOS) verbreitet und damit relevant. Für beide lässt sich zwar grundsätzlich kostengünstig entwickeln, jedoch muss dabei das jeweilige SDK genutzt und auf die Systemeigenheiten eingegangen werden. Immerhin bieten heutige Game-Engines wie Unity bereits die Möglichkeit allgemeine Spielinhalte unabhängig vom Gerät zu erstellen und dann per Knopfdruck eine jeweilige plattformspezifische Version zu generieren. Jedoch geschieht auch dies letztendlich über das jeweilige Plattform-SDK, wenn auch teil-automatisiert.
Entwicklung für mobile Geräte
Ganz konkrete Systemfunktionen und Gerätebesonderheiten lassen sich naturgemäß nicht verallgemeinern. Ein Beispiel ist das jeweilige Benutzerkonto. Sowohl Google als auch Apple bieten mit Google Play bzw. Game Center inhaltlich ähnliche, aber eben nicht völlig identische Funktionen im Zusammenhang mit den Benutzerprofilen. Somit erfordert die Programmierung unterschiedlichen Code, abhängig davon, in welcher Umgebung das Spiel läuft. Ein Möglichkeit, um dies zu erreichen ist die bedingte Compilierung, die Code beim Erstellungsvorgang abhängig von der aktiven Konfiguration ein- oder ausschließt.
Beispiel-Code für Vibrationseffekte des Geräts, der nur für Android eingebunden wird.
Da die bedingte Compilierung aber dennoch das Schreiben (und Testen) von mehrfachem Code erfordert, um letztlich aber ähnliche Dinge zu erreichen, versuchen einige Entwickler den Code zu abstrahieren und in Bibliotheken zusammenzufassen. Für Fart Fiasco habe ich das Cross Platform Native Plugins – Ultra Pack von Voxel Busters Interactive eingesetzt, das inzwischen in eine Nachfolgerversion überging. Dieses Plugin versuchte die konkrete Store-Anbindung zu kapseln, so dass man sich als Entwickler nicht mehr um die plattformspezifischen Details kümmern muss. Das hat jedoch nur teilweise gut funktioniert, es gab immer wieder Probleme in dieser im Detail doch recht komplexen Angelegenheit.
Das Helfer-Plugin versucht plattformspezifische Funktionen zu verwalten, so dass sich die Anbindung an z.B. Zahlungs- oder Cloudsysteme für Spielerentwickler vereinfacht.
Google Android-Entwicklung
Die Stärken von Google-SDKs liegen wie so oft auch in diesem Fall klar in der zunächst relativ unkomplizierten Zugänglichkeit und niedrigen Kosten.
Das Android-SDK lässt sich auf einem Windows-Entwicklungs-PC einfach herunterladen und lokal ausführen. Der Test des Spiels geschieht über einen Emulator oder ein per USB angeschlossenes Android-Gerät. Zudem ist es möglich, das Spiel in Form der fertig erzeugten apk-Datei einfach auf ein Android-Handy zu kopieren und dort zu installieren.
Spätestens bei Veröffentlichung im Play Store ist ein Entwicklerkonto nötig, wofür eine einmalige Gebühr von ca. $25-$35 zu entrichten ist.
Google’s typische Schwächen finden sich in der Produktkomplexität. Es gibt unglaublich viele Stellen an denen irgend etwas konfiguriert werden muss. Ich empfinde die Webseite zum Einrichten eigener Produkte (genannt Entwickler-Konsole) bis heute nicht intuitiv und unglaublich unübersichtlich. Noch schlimmer ist jedoch die ständige Überarbeitung seitens Google, dessen Konsequenz ist, dass man permanent die SDKs-Versionen aktualisieren muss, weil z.B. ältere Android-Versionen nicht mehr unterstützt werden. Dabei entsteht jedoch ein neues Problem: Alle abhängigen Module müssen ebenfalls diese Änderung unterstützen. Wenn Google z.B. ein neues SDK erzwingt und das Native Plugins-Modul nicht ebenfalls vom Entwickler aktualisiert wird, passt der Code nicht mehr zusammen und das Projekt ist kaputt. Was sich auf den ersten Blick vielleicht „mit großer Sorgfalt irgendwie handhabbar“ anhört, war ein riesiges Problem. Die Unterstützung für Android bedeutet einen langfristig immer wiederkehrenden Wartungsaufwand, der am eigentlichen Spiel nichts ändert, aber Entwicklungsressourcen kostet.
Google kündigte hier an, dass Software eine neue API-Version unterstützen muss, um weiterhin im Store sichtbar zu bleiben bzw. um neue Versionen veröffentlichen zu können. Derartiger Update-Zwang ist in der Sache sicherlich richtig gemeint, zieht aber eine Menge technischer und wirtschaftlicher Risiken und Aufwand für Entwickler nach sich.
Apple iOS-Entwicklung
Eine Stärke der iOS-Welt liegt ganz klar in der besseren Nachhaltigkeit und dem glatten Zusammenspiel von Apple-Produkten. Entwickler werden meines Erachtens sehr viel besser und verständlicher durch die nötigen Vorgänge geführt und das bei Google vorzufindende Chaos bleibt hier aus.
Eine der größten Schwierigkeiten stellen dabei aber die mit dem zuvor genannten Qualitätsanspruch zwangsläufig einhergehenden Einschränkungen dar. Das geht schon damit los, dass Apple-Hardware nötig ist, um ein Spiel für die iOS-Welt zu erstellen. Ich brauchte also z.B. ein MacBook auf dem Xcode installiert wird. Auf dieses konnte ich mein Fart Fiasco-Unity-Projekt kopieren und dort eine iOS-Version des Spiels erzeugen.
Abgesehen davon, dass der Synchronisationsprozess relativ mühsam ist, gibt es weitere Probleme. So verlangt Xcode dem ausführenden System viel ab, was den Erstellungsprozess auf meinem alten MacBook von 2012 extrem langsam machte. Zudem müssen auch hier aktuelle Versionen des Tools verwendet werden. Das wurde dann zum Problem als eine neue Xcode-Version auch eine neue MacOS-Version voraussetzte, diese aber auf meinem alten MacBook nicht mehr installierbar war. Ich hätte also ein komplett neues MacBook kaufen müssen, nur um das Projekt für iOS-Geräte zu generieren.
Auch das Testen gestaltet sich in der Apple-Welt erheblich komplizierter. So können Programme nicht einfach auf Geräte kopiert werden (zumindest bisher). Ein Upload über die Store-Infrastruktur und die zeitlich eingeschränkte Installation per Testflight-App sind unumgänglich. Hierfür war wiederum das Eröffnen eines Entwicklerkontos nötig, das jährlich wiederkehrend $99 kostet. Hier entstehen also laufende Kosten, die auch laufend wieder eingespielt werden müssten.
Der Brückentroll: Apple’s Review-Team
Nun hatte ich tatsächlich sämtliche bisher genannten Hürden überwunden und hatte es geschafft, dass Fart Fiasco auch auf meinem iPhone lief. Allerdings ist bei diesem Vorgang noch eine Sache entscheidend: jede hochgeladene Version wird von Apple-Mitarbeitern kontrolliert, auch wenn es sich um nicht öffentlich sichtbare Softwareversionen handelt. Während mehrere Versionen problemlos eine Freigabe erhielten, erwischte ich eines Tages einen Gutachter, der das Projekt blockierte.
Fart Fiasco wurde als Spam eingestuft. Die Begründung war, dass es zu viele Farting-Apps im Store gebe und man daher nicht noch mehr wolle. Dass sich der Mitarbeiter oder die Mitarbeiterin offensichtlich überhaupt nicht mit dem Produkt auseinandergesetzt hat, sollte jedem klar werden, der das Spiel spielt. Bis heute ist Fart Fiasco meines Wissens einzigartig und im App-Store nichts ähnliches zu finden. Es mit plumpen Furzgeräusche-Generatoren gleich zu setzen, ist meiner Meinung nach schlichtweg sachlich falsch.
Apple lehnte das Spiel eines Tages willkürlich ab.
Leider konnte auch ein nachfolgender Dialogversuch keine Überzeugung leisten. Statt sich nochmal ernsthaft mit der Sache zu beschäftigen, riet man mir, ich soll das Produkt doch über Webtechnologie realisieren, so dass man es im Browser spielen kann, wodurch der App-Store umgangen wird. Natürlich geht das nicht so einfach, zumal das gesamte Interaktionssystem auf eine Vollbild-App ausgelegt ist und dies im Browser eine völlig andere technische Umsetzung erfordert.
Mit dem Wegfall von iOS war quasi über Nacht der gefühlt halbe Mobile-Markt unerreichbar geworden, was für eine Handy-App katastrophal ist.
Apple will mein Spiel nicht, Google rennt man ständig hinterher, die DSGVO kriminalisiert gefühlt das gesamte Werbenetzwerk und auch sonst schien die Smartphone-Entwicklung problematisch und mühsam. Sollte ich das Projekt, in das schon so viel Arbeit geflossen war einfach aufgeben? Allem Chaos zum Trotz liefen einige Dinge auch ganz gut, z.B. die Entwicklung der Spielinhalte.
Überraschend gut: Canvas UI + Physik
Der allererste Konzept-Test, damals noch in Unity 5, basierte auf Sprite-Objekten im 3D-Raum. Während das grundsätzlich funktionierte, stieß ich aber relativ schnell auf das Problem, dass bei diesem rudimentären Ansatz wirklich so gut wie alles von Null auf selbst programmiert werden muss. Insbesondere die Arbeit mit dem Verhältnis von Sprites zueinander sowie Relationen zu den physischen Bildschirmrändern wurde schnell sehr mühsam.
Die gesamte Spielgrafik wurde über das Canvas-System realisiert, wobei mehrere unterschiedlich konfigurierte Canvasse übereinander liegen.
Eine der interessantesten technischen Erkenntnisse dieses Projekts war für mich die Nutzbarkeit des Canvas UI-Systems für Szenengrafik. In vielen Game-Engines beschränkt sich das 2D-GUI-System auf die Entwicklung von HUDs. Doch in Unity ist der Canvas so vielseitig, dass er letztlich als komplexe Hilfsmittelsammlung für HUDs und Spielgrafik brauchbar ist. Die Arbeit mit 2D-Koordinaten im Pixelsystem, Drehpunkten, Grafikanimationen und der 2D-Physiksimulation vereinfacht sich hierbei erheblich. Ich hätte nicht gedacht, dass das so gut funktioniert, doch Fart Fiasco ist komplett in Canvas-Komponenten realisiert. Das Schweben und Gleiten der Kuh übernimmt dabei die Physik-Engine, die Kraftimpulse und andere physikalische Größen bei Interaktionen und Objektreaktionen erhält.
Mehr Spieltiefe durch Labyrinth-Generator
Das Spiel besteht aus zwei Arten von Leveln. Einerseits gibt es ca. 50 handgestaltete Herausforderungen mit individuellen Leveldesigns, das teils auch ungewöhnliche Formen einnimmt.
In diesem manuell gestalteten Level rotieren Steine auf ungewöhnlicher Kreisbahn.
Mit dem ursprünglichen Ziel für Mobile zu entwickeln, existiert zudem ein automatisch generiertes Level, das ein endloses Spiel oder das freie Sammeln von Punkten ermöglicht. In der letztlichen Desktop-Version wurden beide Teile kombiniert. Man spielt zunächst im freien Modus zufällig generierte Level und kann mit den so erspielten Punkten die individuellen Level in Form so genannter Quests freischalten.
Das Generieren unvorhersehbarer Levelverläufe war eine weitere neue Herausforderung für mich, da ich mich nie zuvor mit prozeduralen Inhalten beschäftigt hatte. Das ganze Spielbrett wird dabei in sechseckige Felder aufgeteilt. Zwar werden die Daten im Code über ein zweidimensionales Array realisiert, doch ergibt die Auswertung als Zellen mit jeweils sechs möglichen Ausgängen eine viel organischere und interessantere Wegform als ein rechteckiges Raster. Gleichzeitig lässt sich eine angrenzende Zelle durch errechnen des zweidimensionalen Array-Index schnell und einfach bewerkstelligen.
Das Wabenlayout entsteht aus vertikalem Versetzen der grafischen Zellen um die halbe Pixelgröße.
Im nächsten Schritt errechnet ein Labyrinth-Generator-Algorithmus Wege durch das hexagonale Raster. Dabei entstehen auch unterschiedlich lange Wege und Sackgassen. Dieses Video visualisiert die Schritte, die das Verfahren durchläuft.
Ein Maze-Generation-Algorithmus ermittelt zufällige Pfade innerhalb der Kacheln. Die Linienfarben waren ein Hilfsmittel, um die Verbindungsrichtung zwischen den jeweils einer Farbe zugeordneten Zellen zu kontrollieren.
Sobald die erlaubten Bewegungspfade für die Kuh feststehen, ergeben sich daraus indirekt automatisch die Positionen für mögliche Objekte wie Hindernisse oder Sammelobjekte.
Die Platzierung der einzelnen Szenenobjekte basiert auf einer zufälligen Verteilung entlang der gefundenen Wände. Für visuelle Varianz bei gleichzeitiger garantierter Lösbarkeit müssen einige Bedingungen berücksichtigt werden. Die zufällig festgelegte Größe eines Hindernisses muss stets ein Minimum erfüllen, damit das Objekt gut sichtbar ist. Gleichzeitig darf es nie zu groß werden, da der entstehende Korridor sonst zu eng für die Kuh wird und damit eine unbeabsichtigte Wegsperre entsteht.
Alle Seiten eines Sechseck, durch die kein Pfad verläuft (hier gelb), sind Kandidaten für die Platzierung von anderen Objekten wie Hindernisse.
Um die Level abwechslungsreich zu gestalten und eine Steigerung im Spielverlauf zu ermöglichen, kommen zudem weitere Bedingungen zum Einsatz, die in Form von Scriptable Objects gespeichert wurden. Dadurch konnte ich die grafische Programmoberfläche von Unity nutzen, um Bedingungen und Konfigurationen für den Levelgenerator zu hinterlegen. Zum Beispiel ist es möglich festzulegen, wann welche Arten von Hindernissen entstehen, welche Sammelressourcen auftauchen können und mit welcher Wahrscheinlichkeit Elemente vom Generator gestreut werden.
Das Verhalten meines Levelgenerators lässt sich durch Scriptable Objects visuell justieren und in parallelen Sets anlegen. Die Farbbalken am Ende der Liste zeigen zur Entwicklerkontrolle die Verteilung der Spawnrate an.
Noch mehr eigene Tools
Gerade in diesem Projekt erwies sich Möglichkeit eigene Editorerweiterungen für Unity zu schreiben, als extrem praktisch. Das Projekt besteht aus vielen einzelnen Bausteinen, die auf bestimmte Art miteinander zusammenspielen müssen. Zum Beispiel hatte ich allgemeine, levelübergreifende Spielobjekte in einer global Szene zusammengefasst. Die einzelnen Level-Szenen enthalten dagegen nur die individuellen Szenenobjekte, die aber ohne die globale Gameboard-Szene nicht darstellbar sind. Meine Editor-Erweiterung erkennt z.B. wenn ein solches Level im Editor geöffnet wird und bietet direkt an, die nötigen Abhängigkeiten ebenfalls zu laden.
Eigene Editor-Erweiterungen helfen, um Vorgänge zu Vereinfachen, schneller auf typische Konfigurationen zuzugreifen und Probleme zu finden, die sich aus der konkreten Spiellogik ergeben.
Auch der Zugriff auf bestimmte Elemente wie die Kuh, die sich irgendwo in der Objektehierarchie befindet, aber eindeutig identifizierbar ist, konnte ich beschleunigen. Mit nur einem Klick auf die Select Cow-Schaltfläche wählt Unity nun genau dieses zentrale Objekt aus. Ähnliches gilt für Konfigurationen, die sich über verschiedene Komponenten und GameObjects hinweg erstrecken und mit dem eigenen Editor-UI an einer Stelle zugänglich werden. Eine meiner persönlichen Lieblingsfunktionen in diesem Zusammenhang ist jedoch der Problem-Finder, den ich schon für A Room Beyond geschrieben und nun erweitert bzw. angepasst habe. Er untersucht die Szene auf Unplausiblitäten hin, wie z.B. eine Abweichung zwischen den maximal erreichbaren Punkten pro Level und den tatsächlich verteilten Sammelobjekten, die diese Summe bilden müssen. Wird ein Fehler gefunden, erscheint er in einer Liste. Ist der Fehler programmatisch behebbar, wird eine entsprechende Reparaturfunktion per Klick angeboten, andernfalls wird zum Objekt gesprungen, das den Fehler enthält. Eine super praktische Hilfestellung, um sich vor Flüchtigkeitsfehlern zu schützen, weil man mit zunehmender Komplexität schnell den Überblick über das eigene Softwarekonstrukt verlieren kann.
Fokus auf den Desktop
Letztlich entschied ich mich dazu, die Smartphone-Unterstützung komplett abzubrechen, zumindest aber eine Desktop-Version anzubieten. Mit der Veröffentlichung auf Steam hatte ich zuletzt gute Erfahrungen gemacht und das Spiel war ja auch schon fast fertig. Mit ein wenig Mehraufwand wäre Fart Fiasco auch mit Maus+Tastatur bzw. Controller grundsätzlich spielbar. Was sollte da noch schiefgehen?
Schließlich ging ich mit dem Spiel auf Steam in Early Access öffentlich, da es ja fast fertig war und eigentlich nur noch kleine Verbesserungen erfordern würde. Die aus der Mobile-Phase verbliebende Struktur aus generischem Hochleveln und den Quest-Modi hätte ich mir für ein Desktop-Spiel zum Beispiel anders vorgestellt. Was einfach zu ändern klingt, ist in diesem mittlerweile recht komplexen Projekt aber schwer umzusetzen geworden, da viele verschiedene Abhängigkeiten existieren und ein hohes Risiko des Einbaus schwer zu entdeckender Fehler besteht. Dennoch wollte ich das Projekt zu Ende führen und startete einige Werbekampagnen in Social Media, was auf gemischte, aber erwartungsgemäße Reaktionen stieß. Ich bewarb mich bei der Indie Arena als Aussteller (was aber nicht klappte) und beklebte Autos mit Werbemotiven.
Fart Fiasco-Auto-Werbung.
Zudem hatte sich mein Alltagsgeschäft eher unerwartet komplett verändert. Um 2017 erfuhr die Online-Learning- und Videokurs-Branche gerade ihren Aufstieg und ich hatte, zunächst als ein weiteres Experiment, meinen ersten Udemy-Kurs erstellt. Kurz gesagt lief dieser sofort überraschend gut an und brachte mir einen Teil des Lebensunterhalts ein. Da dies also in jederlei Hinsicht spürbar besser lief als das Spielprojekt selbst, investierte ich mehr Zeit in den Aus- und Aufbau dieser Geschäftsidee. Ich denke heute, dass das vollkommen richtig und wichtig war, doch leider bedeutete es, dass ich praktisch keine Zeit mehr für Fart Fiasco hatte.
Meine Lehrtätigkeit im Bereich Spieleentwicklung rückte immer weiter in den Mittelpunkt und nahm mich spätestens mit der Berufung in die Professur an der Hochschule Kempten komplett ein. Der Aufbau meiner Aufgaben dort, lies keine Zeit für andere Dinge, so dass ich weder neue Kurse erstellen, noch Fart Fiasco richtig fertigstellen konnte. Ich glaube auch hier, dass es richtig lief, aber alles einen gewissen Preis fordert. Das Loslassen dieser früheren Projekt fällt mir bis heute noch sehr schwer, scheint mir aber unvermeidbar.
Steam wies auf den brach liegenden Early-Access-Zustand hin.
Inzwischen, 2024, sind schlicht schon viele Jahre vergangen und die Entwicklung von Fart Fiaso ist für mich einfach zu weit in die Ferne gerückt. Schließlich hatte auch Steam nachgehakt, was denn nun der Stand der immer noch des Early Access befindlichen Projekts sei. Es hat hier nun mehrere Handlungsmöglichkeiten gegeben. Das Projekt komplett abzubrechen wollte ich nicht, denn dafür ist zu viel Arbeit reingeflossen und auch schon zu viel Ergebnis rausgekommen. Mit Hilfe von Steam wäre es zudem möglich gewesen, den Early Access-Status außerplanmäßig zu stoppen, ohne dabei den normalen Release-Vorgang zu durchlaufen. Die Entwicklung nochmal aufzugreifen und das Projekt so zu perfektionieren, wie ich es mir vorstelle, hatte ich zwar tatsächlich nochmal in Angriff genommen, doch muss ich zugeben, dass ich mich dazu nach fast acht Jahren inzwischen schlichtweg nicht mehr in der Lage sehe. Letztlich habe ich mich entschieden, das Spiel einfach in den Release-Zustand zu setzen. Bereits vor einigen Jahren hatte ich den Produktpreis auf kostenlos geschaltet und auch wenn es nicht perfekt ist, so ist es immerhin ja spielbar.
Erkenntnisse und Learnings
Fart Fiasco war ein wilder Ritt, der überhaupt nicht absehbar war. Obwohl das Endergebnis nicht wirklich meinem eigenen, oft zu perfektionistischen Anspruch genügt, ist zumindest irgendwas dabei herausgekommen. Gewinnbringender als das Endergebnis sind für mich aber wahrscheinlich die Erfahrungen aus dem gegangenen Weg.
Es passieren unerwartete Dinge. Manchmal läuft es einfach nicht wie geplant und es kommt etwas anderes, vielleicht auch besseres. Insbesondere die Finanzierung von Spieleentwicklungen ist und bleibt ein schwieriges Thema, das schnell zu anderen, lukrativeren und damit leichteren Projekten führen kann.
Einfach halten. Jede neue Idee verkompliziert das Projekt, wodurch es irgendwann nicht mehr handhabbar ist. Insbesondere die unterschiedlichen Plattformziele und die damit einhergehenden immer neuen Ideen haben Fart Fiasco besonders stark zerschlagen und verkompliziert.
Beim eigenen Thema bleiben. Meine früheren Erfahrungen mit älteren Smartphone-Vorgängern waren auch schon schlecht, ich hätte mich damit garnicht erst befassen, sondern beim für mich Bewährten bleiben sollen.
Man lernt immer was. Zweifellos habe ich in allen Bereichen viel gelernt, auch technisch. Den Canvas für Szenengrafik einzusetzen und Labyrinth-Generatoren zu implementieren, war etwas völlig neues, das durchaus gut funktioniert hat. Wenngleich übrigens unklar ist, wie performant das Ganze eigentlich ist.
Nie wieder mobile
Zwar haben mir die Experimente mit den Mobil-Versionen viel Erfahrungswerte geliefert, doch hat es auch unglaublich viel Entwicklungsarbeit erschwert. Daher denke ich, dass man, insbesondere als Mini-Team oder Solo-Entwickler eher zurückhaltend sein sollte, wenn es um die Erweiterung des Produkts auf zusätzliche Plattformen geht. Die Möglichkeit von Tools wie Unity quasi auf Knopfdruck ausführbare Versionen der selben Projektquelle für verschiedene Geräte zu erstellen, verführt schnell zur falschen Annahme, dass es ebenso einfach sei, dieses Produkt dann auch cross-plattform zu konzipieren und zu publizieren.
René Bühling, Professor für Game Design an der Hochschule Kempten spricht im Podcast von Josef Griesbauer über Game Design, Spieleentwicklung, Möglichkeiten des Studiums in diesem Bereich und Spiele die er spielt und mag oder nicht mag und den Weg und die Leidenschaft als Spieleentwickler.
Künstliche Intelligenzen werden immer wichtiger für die Spieleentwicklung. In diesem Artikel zeige ich dir ein paar KIs die du nutzen kannst um deine Spiele zu verbessern oder dich inspirieren zu lassen.
Story mit ChatGPT schreiben (lassen)
In anderen Artikeln haben wir bereits gezeigt, dass sich ChatGPT z.B. zum Erstellen von Code oder dem Entwerfen einer Spielmechanik samt passendem visuellen Thema einsetzen lässt. Zu den Anwendungsmöglichkeiten dieses mächtigen Tools gehört auch das Skizzieren einer Geschichte. Formuliere im Chat einfach Deine Wünsche und der Bot erzeugt einen passenden Vorschlag:
Eine von ChatGPT erstellte Vorgeschichte
Grafischen Entwurf mit DALL·E 2 zeichnen (lassen)
DALL·E 2 ist eine KI, welche von den selben Entwicklern wie ChatGPT ist. Es ist ein Tool das verwendet werden kann um Bilder zu erzeugen, die zu einer textuellen Beschreibung passen. Dabei kann man sich als Gestalter viel Inspiration holen oder auch ganze Charaktere entwerfen lassen.
Generierte Bilder der KI
Gebe dir auch Variationen der Bilder aus.
Variationen der Bilder
Zum aktuellen Zeitpunkt funktioniert DALL·E 2 nur auf englisch. Zudem gibt es zahlreiche Diskussionen über beispielsweise die Urheberrechte der generierten Kunstwerke, zumal der Computer Stile anderer Bilder imitiert. Weitere, ähnliche Bildgeneratoren sind z.B. midjourney oder stable diffusion.
Texte mit Voicebooking sprechen (lassen)
Gesprochene Texte steigern die Ästhetik von Videos oder Computerspielen enorm und hauchen virtuellen Charakteren Leben ein. Auch hierfür gibt es Lösungen auf Basis künstlicher Intelligenz, die besonders natürlich klingende Sprache aus einem Text erzeugen sollen. Zu den bekannten Anbietern solcher Text-to-Speech genannten Verfahren gehören z.B. Google Cloud-Dienste, Amazon Polly oder murf.ai. Der Dienst Voicebooking erzeugt eine kleine Menge von Textübersetzungen kostenlos, die z.B. auch für Dialoge in Spielen zum Einsatz kommen könnten. Audiodateien kannst Du z.B. mit der kostenlosen Software Audacity schneiden.
Zusammfassung
Wir haben hier mit kostenlosen Mitteln einen Spielcharakter erstellt, welcher eine Geschichte, ein Aussehen und eine Stimme bekommen hat. Wie sich die Bedeutung von KIs in der Zukunft der Spieleentwicklung entwickeln wird, bleibt ebenso wie die rechtliche Einordnung noch abzuwarten.
Das Forschungsunternehmen Open AI hat kürzlich eine Chat-Anwendung veröffentlicht, die einen Dialog mit einem Computer ermöglicht. Dieser nutzt dann Verfahren der künstlichen Intelligenz, um eine Antwort zu formulieren, die nicht nur inhaltlich, sondern auch sprachlich der Antwort eines Menschen nahekommen soll. Dieser ohne Fachwissen durchführbare Dialog lässt sich für verschiedenste Anwendungsgebiete einsetzen, was zu einer großen Popularität des Dienstes führte. In diesem Artikel gehen wir der Frage nach, wieweit sich der Mechanismus für die Konzeption von digitalen und analogen Spielen eignet.
ChatGPT bei Kreativtechniken
Kreativtechniken sind ein essentielles erstes Werkzeug der Ideenfindung. Fragen wir ChatGPT, welche Techniken es kennt:
ChatGPT benennt einige Kreativtechniken
Die Antwort zeigt, dass der Computer versucht, seine Antworten kurz und prägnant zu formulieren. Generell gibt die KI einen guten Überblick über das abgefragte Thema.
Fragen wir nun nach einer Erklärung einer Technik, z.B. dem Brainstorming.
ChatGPT erklärt die wichtigsten Punkte beim Brainstorming.
Die Antwort des Chatbots benennt in der Tat die essentiellen Schritte und Prioritäten des Brainstormings. Dieses Beispiel zeigt, wie ChatGPT eingesetzt werden kann, um z.B. ein bestimmtes Thema nochmal zu wiederholen oder aus anderem Blickwinkel zu erklären.
Personen, die noch nie etwas von Brainstorming gehört haben, könnte diese Antwort jedoch nicht genügen. Sie beschreibt das Werkzeug auf einer Meta-Ebene und gibt z.B. keine konkreten Handlungen oder Ablaufstrukturen an, wie sie ein menschlicher Moderator geben würde.
ChatGPT zur Game Design Document-Gestaltung
Anregungen aus den Antworten der künstlichen Intelligenz können im Prinzip überall dort einbezogen werden, wo es um das Sammeln und Kombinieren von Ideen geht. Bei der Erstellung eines Game Design Documents können wir uns auf verschiedenste Weise inspirieren lassen:
Spielmechanik
Um grundsätzliche Ideen zum Ablauf zu erhalten, kann der Chatbot nach Impulsen zur Spielmechanik gefragt werden. Je allgemeiner die Frage ist, desto allgemeiner ist auch die Antwort. Mit weiteren Rückfragen oder Aufforderungen zur Verbesserung oder Verfeinerung lässt sich die Idee konkretisieren.
ChatGPTs Vorschlag für eine Spielmechanik.
Titel- und Marken-Entwicklung
Eine große Herausforderung der Produktentwicklung ist die Namensfindung, zumal enorm viele Begriffe und Titel bereits existieren. Fragen wir ChatGPT nach Vorschlägen für das von ihm erfundene Spielprinzip:
Namensvorschläge, die sich auf die zuvor gegebene Antwort beziehen.
Wichtig ist hierbei zu bedenken, dass die KI lediglich über den Spielinhalt nachdenkt. Sie berücksichtigt zum Beispiel nicht, ob ein Name bereits existiert oder ob dieser womöglich sogar rechtlich geschützt ist.
Grafisches Thema
Zwar ist ChatGPT ein textbasiertes Werkzeug, doch können wir nach Vorschlägen zu einer interessanten visuellen Gestaltung fragen:
Die Frage nach der Gestaltung liefert zumindest einen Überblick über relevante Themenfelder.
Die Antwort ist noch sehr allgemein und liefert keine konkreten Aspekte, was aber der Allgemeinheit der Frage entspricht. Immerhin erhalten wir eine Liste von Bereichen, die in die Konkretisierung der Gestaltung einbezogen werden müssen.
Um genauere Vorschläge zu bekommen, können wir Detailfragen stellen:
Die Nachfrage nach Details liefert eine ausgewählte Farbpalette sowie eine Begründung zur Motivation.
Wir haben nun eine Palette aus Farbtönen, die aber immernoch sehr allgemein gehalten sind. „Knalliges Orange“ ist beispielsweise ein Farbeindruck, der aber noch viel Interpretationsspielraum zulässt. Fragen wir nach, was genau gemeint ist:
Vorschlag für ganz konkrete Farbtöne.
Die ermittelten Farbcodes können nun in einer Grafiksoftware visualisiert werden:
Grafische Darstellung der Farbwerte, die ChatGPT vorschlug.
Bei der Betrachtung dieser Farbe fällt auf:
Die Farben passen prinzipiell zueinander und wirken wie für Gelegenheitsspiele typische Farbwelten.
Die Farben sind eventuell nicht das, was man sich bei der textuellen Beschreibung zunächst vorstellte. So hätte ich mir unter „Leuchtendes Gelb“ einen deutlich knalligeren Farbton als dieses Blassgelb vorgestellt.
Die Palette ist in sich nicht perfekt: Insbesondere die Kontraste zwischen Rosa und Orange, sowie zwischen Blau und Grün sind sehr schwach.
Die Farbpalette ist noch keinem Genre oder Stil zugeordnet. Ist der Schauplatz ein Kinderspielplatz könnte die Palette zum Thema passen, während sie für ein Zombie-Szenario wahrscheinlich unbrauchbar ist.
…
Die Schwächen begründen sich auch darin, dass wir keine Anforderung zu Kontrast oder Thema formuliert hatten und sich ChatGPT somit für irgend etwas entschied. Durch weitere Eingrenzungen ließe sich hier das Ergebnis verbessern.
Weitere Bereiche
Das oben gezeigte Prinzip von Frage und Nachfrage lässt sich nun beliebig wiederholen und vertiefen. Es könnte in weiteren Abschnitten des Game Design Documents helfen:
Charaktere und Story Entwerfen von Nichtspielercharakteren, einfachen Handlungssträngen und Dialogen
Stimmungen und Akustik Impulse zu Stil, Rhythmus, Geschwindigkeit oder anderen Klangparametern lassen sich wie die Farben im Beispiel abfragen.
Steuerung und Geräteanbindung Tastenbelegungen erfordern genaue Details der Spielmechanik. Der Chatbot kann aber auch mit wenigen Infos bereits allgemeine Vorschläge generieren.
…
Grenzen des KI-Unterstützung
Es ist erstaunlich, welche Impulse die künstliche Intelligenz bereits liefert. Dennoch lassen sich einige Schwächen feststellen, etwa in folgenden Bereichen:
Nicht wirklich intelligent. Das Beispiel oben hat gezeigt, dass es vor allem so aussieht als seien die Antworten intelligent. Im Detail müssen sie aber auf Fehler und Konsistenzen überprüft und ggf. korrigiert werden. Häufig sind Antworten auf den ersten Blick zwar gut geschrieben, bei genauerer Betrachtung aber inhaltlich sehr oberflächlich und aussageschwach.
Nicht einzigartig. Die Antworten der KI hängen vom Datenbestand ab, den der Chatbot kennt. Somit ist der Wissensschatz auf diese Quelle begrenzt. Zudem können gleiche Eingaben zu gleichen Ergebnissen führen.
Monoton und gefühlskalt. ChatGPT kann einem viel Arbeit abnehmen. Vor allem an Stellen in denen man einfache Antworten oder Inspiration benötigt, blüht die KI auf. Die Antworten neigen aber auch dazu schnell monoton zu klingen und den gewissen Feinschliff zu vermissen.
Im Umfang begrenzt. Die KI eignet sich (zumindest heute noch) erst für kleine, überschaubare Fragen. Komplexe Anforderungen scheinen noch fehleranfällig.
Zusammenfassung
Künstliche Intelligenz wie z.B. ChatGPT eignet sich, um Impulse zu bestimmten Fragen des Game Designs zu liefern. Die Antworten liefern Vorschläge deren Detailgrad in der Regel dem der Fragestellung entspricht. Sie müssen reflektiert und verfeinert werden, um das Game Design Document zu konkretisieren.
