Johnson et al.: Wie verändert sich ein Spiel, wenn man große Sprachmodelle einbaut? — gelesen von Fukai

Zusammenfassung in einem Absatz

Johnson und Kollegen von der University of Calgary in Kanada haben zwei Spiele entwickelt, in denen ein großes Sprachmodell (LLM – eine KI, die mit riesigen Textmengen trainiert wurde und Text generieren oder Fragen beantworten kann) nicht als nachträglich hinzugefügtes Beiwerk, sondern direkt in die Struktur des Spiels eingebaut wurde. Sie haben ihre Entwicklungserfahrung dokumentiert und analysiert. Die Frage dahinter ist denkbar einfach: Wie verändern sich Gameplay, Spielbarkeit und Spielererfahrung, wenn man ein LLM einbaut?

Kurz gesagt: LLMs erzeugen einerseits „jedes Mal andere Inhalte" und „auf die einzelne Person zugeschnittene Erlebnisse", bringen aber andererseits neue Belastungen mit sich – Korrektheit, die Abstimmung des Schwierigkeitsgrads und die Konsistenz des Gesamtbilds. Weil die generierten Inhalte direkt mit dem Regelablauf des Spiels verknüpft sind, verwandeln sich fehlerhafte Ausgaben unmittelbar in Unfairness oder Ernüchterung. Die Entwickler hielten das Spiel nur dadurch gerade noch spielbar, dass sie die Ausgaben des LLM in ein festes Format zwangen und Prüfmechanismen dazwischenschalteten.

Vorab sei angemerkt: Es handelt sich um ein Preprint vor der Begutachtung (ein gerade erst eingereichtes Manuskript, das noch kein Fachgutachten durchlaufen hat), und eine Überprüfung mit tatsächlichen Spielern hat noch nicht stattgefunden. Bitte lesen Sie diesen Artikel mit der Prämisse, dass es sich um eine systematische Auswertung der Selbstreflexionen der Entwickler selbst handelt.

Einleitung

Das Paper ist als arXiv-Preprint 2603.27896 am 29. März 2026 eingereicht worden, Fachgebiet cs.SE (Software Engineering). Die sechs Autoren – Keeryn Johnson, Muhammad Ahmed, Charlie Lang, Sahib Thethi, Wilson Zheng und Ronnie de Souza Santos – sind allesamt an der University of Calgary tätig. Das Manuskript ist im Format einer ACM-Konferenz verfasst, ist aber kein bei einer bestimmten Konferenz angenommenes, peer-reviewtes Paper, sondern derzeit ein Preprint vor der Begutachtung – das sei hier klar festgehalten.

Warum ich mich heute für dieses Paper entschieden habe: Demos, die zeigen, „was mit LLMs in Spielen alles möglich ist", gibt es zuhauf. Aufzeichnungen jedoch, die in Ruhe reflektieren, wie sich das Gefühl von Entwicklung und Spiel verändert, wenn man ein LLM tatsächlich in das Grundgerüst eines Spiels einbaut, sind erstaunlich selten. Dieses Paper schlägt keine spektakuläre neue Technologie vor, sondern liest sorgfältig die Selbstreflexionen von Studierenden, die tatsächlich zwei Spiele fertiggestellt haben – und das liegt sehr nah an der Realität, mit der Entwickler morgen konfrontiert sein werden. Deshalb halte ich es für lohnenswert, dieses Paper zu übersetzen und vorzustellen.

Hintergrund

In der Spieleforschung gelten drei Konzepte seit langem als zentral: Gameplay, Spielbarkeit (playability) und Spielererfahrung (player experience). Übernimmt man die Einordnung des Papers, so bezeichnet Gameplay „die Gesamtheit der Aktivitäten, die Spieler oder andere Entitäten innerhalb der virtuellen Welt ausführen können", Spielbarkeit „die konkrete Ausprägung von Usability im Spiel – also mit welcher Qualität diese Aktivitäten ausgeführt werden können", und Spielererfahrung „das Eintauchen, die Freude und die Reaktionen, die während des Spielens entstehen".

Herkömmliche Software wird an „funktionaler Korrektheit" und „Usability" gemessen, doch bei Spielen stehen Freude und Unterhaltung im Vordergrund, weshalb die üblichen Maßstäbe für Software allein nicht ausreichen, so die einleitende Feststellung des Papers. Genau hier sind in den letzten Jahren LLMs hinzugekommen. Bislang wurden LLMs für automatische Inhaltsgenerierung (PCG, Procedural Content Generation – das programmatische Erzeugen von Levels, Gegenständen und Ähnlichem), Dialogsysteme sowie sogenannte „Mixed-Initiative"-Ansätze eingesetzt, bei denen Mensch und KI die Entwicklung gemeinsam vorantreiben. Dabei wurden als Vorteile Abwechslung und Personalisierung berichtet, als Herausforderungen jedoch Unvorhersehbarkeit, Konsistenz und die Schwierigkeit der Bewertung.

Als Forschungslücke benennen die Autoren jedoch Folgendes: Wie „das Einbauen eines LLM während der Entwicklung" mit den etablierten Konzepten Gameplay, Spielbarkeit und Spielererfahrung zusammenhängt, wurde bislang kaum direkt untersucht. Zwar wächst der Katalog an Anwendungsbeispielen, doch wie das Einbauen die Struktur selbst umgestaltet, ist nahezu unbearbeitet geblieben. Diese Lücke aus den unmittelbaren Erfahrungen der Entwickler heraus zu füllen, ist das Ziel dieser Arbeit.

Ansatz / Methode

Die Methode ist die „kollaborative Autoethnographie". Dabei handelt es sich um eine qualitative Methode, bei der nicht ein von außen beobachtender Forscher, sondern die Beteiligten selbst ihre eigene Praxis dokumentieren und systematisch analysieren (Autoethnographie = das Schreiben über die eigenen Erfahrungen als Material und das Herauslesen wiederkehrender Muster daraus). Hier schreiben die studentischen Entwickler über ihre eigenen Erfahrungen beim Einbau von LLMs in ihre Spiele und lesen diese Erfahrungen durch die Linse etablierter Konstrukte.

Untersuchungsgegenstand sind zwei Spiele. Sie entstanden im Rahmen einer dreimonatigen Bachelor-Lehrveranstaltung und eines sechsmonatigen Forschungsprojekts; insgesamt sieben Studierende haben sie entwickelt, davon fünf als Mitautoren dieses Papers. Der Einbau eines LLM war verpflichtende Vorgabe und wurde für Dialoggenerierung, Verzweigungen der Handlung, das Verhalten von NPCs (Nicht-Spieler-Charakteren) sowie für PCG eingesetzt; als Modelle kamen Google Gemini und Modelle von OpenAI zum Einsatz. Die Daten bestehen aus fünf introspektiven Erzählungen (jeweils rund zwei Seiten) zusammen mit Entwurfsunterlagen und Code. Die Analyse kombiniert eine thematische Lektüre (durchgängiges Lesen der Erzählungen, um wiederkehrende Themen herauszuarbeiten) mit einer Inhaltsanalyse.

Das erste Spiel, Wizdom Run, ist ein mit Unity gebautes RPG nach dem Prinzip „Lernen während des Spielens". Wenn der Spieler seine eigenen Lernnotizen als PDF hochlädt, liest ein LLM (von OpenAI) diese ein und generiert Multiple-Choice-Fragen auf drei Schwierigkeitsstufen. Die Fragen werden in das feste Format JSON gebracht und in PostgreSQL (einer Datenbank) gespeichert. In gewöhnlichen Kämpfen stellt eine richtige Antwort die für Zaubersprüche benötigte Mana wieder her, eine falsche schränkt die Handlungsmöglichkeiten ein. Bosskämpfe laufen über ein rundenbasiertes Kartensystem, bei dem richtige Antworten Boni oder Fähigkeiten bringen. Das zweite Spiel, Sena, dient dem Lernen über Nachhaltigkeit im Software Engineering; hier übernimmt das LLM ergänzende Erklärungen im Dialog, die Interpretation von Szenarien und die Erzeugung von Feedback, und es besitzt Modi, deren Zustand sich je nach getroffenen Entscheidungen ändert. In beiden Fällen ist das LLM nicht als „Hilfswerkzeug", sondern als „struktureller Baustein" (architectural component) eingebaut.

Zur Sicherheit sei angemerkt: In diesem Paper tauchen weder Formeln noch statistische Modelle auf. Es handelt sich nicht um numerische Experimente, sondern um eine qualitative Studie, deren Hauptmaterial die Worte der Entwickler selbst sind. Deshalb stelle ich das Ganze im Folgenden nicht anhand von Zahlen, sondern anhand von Konzepten und konkreten Beispielen vor.

Befunde

Auswirkungen auf das Gameplay. Die generierten Inhalte wurden nicht zu „verzichtbarem erzählerischem Beiwerk", sondern zu Bausteinen, die direkt mit der Ausführung der Regeln und dem Spielfortschritt verknüpft sind. Ein Teilnehmer (P1) berichtet, dass die Fragengenerierung „die Wiederherstellung von Skillpunkten, Bosskämpfe und den Levelfortschritt direkt steuert und damit den Kern des Gameplays bildet". Gleichzeitig ändert sich der Inhalt je nach Eingabe bei jedem Mal. P1 schreibt: „Der Code bleibt im Grunde derselbe, und trotzdem wird jede Kampagne zu einem völlig anderen Erlebnis", P2 schreibt: „Jedes Mal ändern sich Fragen und Antworten." Diese Abwechslung ist allerdings nicht unbegrenzt. P5 stellt fest: „Wenn man dieselben Unterlagen wiederverwendet, kommen meist ähnliche Arten von Fragen heraus", was zeigt, dass die Vielfalt der Generierung durch das Design begrenzt bleibt.

Auswirkungen auf die Spielbarkeit. Im Austausch für Flexibilität wurde eine Art „Eindämmung" nötig, um das System nicht zusammenbrechen zu lassen. P1 sagt: „Indem wir die Antworten des LLM in das erwartete Format brachten, konnten wir das Backend-Design konsistent halten", und P4 berichtet, dass durch die explizite Festlegung des Rückgabeformats „auf der C#-Seite des Spiels Objekte erzeugt werden konnten". Auch die Kalibrierung des Schwierigkeitsgrads wurde zu einem Spannungspunkt. P3 berichtet: „Für medium oder hard generierte Fragen fühlten sich manchmal wie das easy-Set an (Originaltext: \"felt like the easy set\")", wodurch die Balance des Fortschritts aus dem Gleichgewicht geriet. Korrektheit war unmittelbar mit Fairness verknüpft. P2 erinnert sich: „Es kam eine einfache Rechenaufgabe heraus, bei der aber keine der Antwortoptionen korrekt war (Originaltext: \"none of the answer options were correct\")", und P5 sagt über fehlerhafte Ausgaben: „Die Spieler lernen dann nicht mehr wirklich, sondern versuchen nur noch zu erraten, wie die KI denkt – das beeinträchtigt das Erlebnis." Zudem wies P3 darauf hin, dass „die richtige Antwort wiederholt an derselben Position unter den Optionen erschien", und warnte, dass dies unbeabsichtigte Lösungswege (Schlupflöcher) hervorbringen könne.

Auswirkungen auf die Spielererfahrung. Die Personalisierung nahm tatsächlich zu. P2 sagt: „Die Themen, die Spieler ausprobieren können, sind unendlich", und P4 beurteilt die Dialogfunktion so: „Spieler können Kontext hinzufügen und nachfragen." Die Qualität der Erfahrung hing jedoch von der Balance zwischen Abwechslung und Vorhersehbarkeit ab. P5 sagt: „Ein gewisses Maß an Abwechslung erweitert die Bandbreite der Veränderung, aber damit ein Spiel fair und spielbar bleibt, braucht es auch ein gewisses Maß an Vorhersehbarkeit." Wenn die Kontextualisierung fehlte, antwortete das System „einfach wie ein gewöhnliches, öffentlich verfügbares LLM und prüfte nicht einmal, ob die Frage überhaupt zum eigentlichen Thema passte (Originaltext: \"answer like any publicly available LLM\")" – diese Bemerkung von P4 bringt den Moment, in dem Konsistenz und Vertrauen zusammenbrechen, sehr gut auf den Punkt.

Nochmals sei betont: All dies sind Selbstreflexionen der Entwickler, und Zahlenwerte wie Trefferquoten oder Verweildauer tauchen in diesem Paper nicht auf. Deshalb lässt sich nicht in Zahlen ausdrücken, „wie stark" etwas gewirkt hat. Was die Autoren zeigen, ist nicht das Ausmaß der Wirkung, sondern wo und in welcher Form sich diese Wirkung zeigt.

Anwendungsfälle

1. Wer selbst ein Sokoban-artiges Kistenschiebe-Rätsel oder ein Puzzle entwickelt, bei dem die Eindeutigkeit der Lösung entscheidend ist, und dabei Levels mit einem LLM automatisch generieren lässt: Hier sollten „Korrektheit" und „Lösbarkeit" (solvability) als für das Gameplay kritische Eigenschaften behandelt werden. Als Schlüssel zur Spielbarkeit nennt das Paper immer wieder die Schema-Erzwingung – das Hineinzwingen der LLM-Ausgabe in ein festes Format und deren Überprüfung. Nach demselben Gedanken sollte man unbedingt einen Solver (ein Programm, das automatisch löst und prüft) zwischen die LLM-Ausgabe und den Spieler schalten, damit niemals ein Fall wie der von P2 beschriebene – „eine Aufgabe ohne existierende richtige Antwort" – in die Welt gelangt.

2. Wer ein Hyper-Casual-Spiel im Quiz- oder Trivia-Stil entwickelt (leicht spielbare, massenhaft produzierte Smartphone-Spiele): Man sollte die vom LLM selbst vergebenen Schwierigkeitsgrad-Labels nicht blind übernehmen. In diesem Paper trat die Diskrepanz auf, dass sich „für hard vorgesehene Fragen wie easy anfühlten". Es ist sicherer, den Schwierigkeitsgrad nicht anhand des bei der Generierung vergebenen Labels, sondern anhand externer Kennzahlen wie der tatsächlichen Trefferquote zu kalibrieren. Also nicht: generieren → dem Label vertrauen, sondern: generieren → messen → das Label neu vergeben.

3. Wer ein Spiel entwickelt, das auf Erzählung oder Dialog zentriert ist: Das LLM sollte gegroundet werden (Grounding = Verankerung, also durch Retrieval oder Beschränkungen fest „innerhalb der Werkwelt" gehalten werden), um den von P4 berichteten Fehler zu vermeiden, bei dem das System „vom eigentlichen Thema abweicht und wie ein gewöhnliches LLM antwortet". Zusätzlich sollte die Ausgabe auf ein Schema wie JSON festgelegt werden, damit nachgelagerter Code (etwa die Objekterzeugung in C#) sie stabil interpretieren kann. Genau das ist der Kniff, von dem das Paper berichtet, dass er tatsächlich wirkt.

4. Genreübergreifend gilt: Muster in den generierten Inhalten (etwa die Verzerrung, dass die richtige Antwort immer an derselben Position steht) sollten geprüft und Schlupflöcher geschlossen werden. Man sollte es dabei aber nicht übertreiben. Wie P5 sagt, ist es für Fairness und Spielbarkeit gesund, „ein gewisses Maß an Vorhersehbarkeit" zu bewahren. Abwechslung und Vorhersehbarkeit sollten meines Erachtens nicht einseitig maximiert, sondern bewusst gegeneinander abgewogen werden.

Grenzen

Beginnen wir mit den Schwächen, die die Autoren selbst einräumen. Es handelt sich um eine qualitative Studie, die keine statistische Verallgemeinerung anstrebt, und das Material ist mit fünf Selbstreflexionen aus zwei Lehrveranstaltungssettings klein. Da die Beteiligten selbst über sich berichten – also eine Innenperspektive mit Selbstauskunft vorliegt –, lassen sich Interpretationsverzerrungen und eine selektive, günstige Erinnerung nur schwer vermeiden. Die Autoren geben an, dies durch den Abgleich mehrerer Selbstreflexionen (Triangulation), das Heranziehen von Entwurfs- und Codeunterlagen sowie gegenseitige Reviews unter den Mitautoren abgemildert zu haben. Als größter Vorbehalt bleibt: Dies ist die Perspektive der Entwickler, keine unabhängige Überprüfung durch Spieler. Auch die Autoren nennen Nutzerstudien als künftige Aufgabe.

Im Folgenden nenne ich Punkte, die mir, Fukai, beim Lesen aufgefallen sind. Erstens: Beide behandelten Spiele sind Lern- bzw. Bildungsspiele, also eine Art, bei der „Korrektheit" besonders entscheidend ist. Ich möchte deshalb vorsichtig damit sein, diese Lehre unbesehen auf rein unterhaltungsorientierte Puzzles zu übertragen, bei denen Gefühl und Überraschung wichtiger sind als Korrektheit. Zweitens: Die verwendeten Modelle – Gemini und Modelle von OpenAI – zeigen das Verhalten zu einem bestimmten Zeitpunkt. Da sich das Verhalten von Modellen durch Updates verändert, ist es riskant, dies als „allgemeine Eigenschaft von LLMs" umzudeuten. Drittens: Es gibt bislang kaum Zitierungen (was bei einem gerade erst eingereichten Preprint selbstverständlich ist), es handelt sich also nicht um breit diskutierte Erkenntnisse. Und, wie bereits gesagt, lässt sich mangels Zahlenwerten das Ausmaß der Wirkung aus dieser Arbeit nicht in Zahlen ausdrücken.

Fukais Lesart

Ich schreibe hier ausdrücklich unter dem Vorbehalt, dass es sich um meine eigene Interpretation handelt. Ich möchte diese Studie in eine Strömung einordnen, die generative Inhalte nicht als Dekoration, sondern als Struktur behandelt. Im Vokabular der Designkritik gesprochen, lässt sich das Einbauen eines LLM in ein Spiel weniger als „Hinzufügen von Inhalt" lesen, sondern eher als eine Arbeit, die die Grenzlinie zwischen den von Hand geschriebenen, festen Regeln des Autors und dem probabilistisch generierten Anteil neu zieht. Was dieses Paper immer wieder zeigt, ist, dass das Wesen des Spielspaßes in der auf den ersten Blick unspektakulären Verrohrung aus Prompt-Design, Schema und Verifikation steckt. Hinter der spektakulären Generierung, so verstehe ich es, entwerfen die Macher in Wahrheit genau jene Grenze: wie weit man der Maschine überlässt und ab wo man von Hand garantiert.

Schluss

Für alle, die eine breitere Landkarte sehen möchten: Einen Überblick bietet Gallotta et al. 2024, „Large language models and games: A survey and roadmap" (IEEE Transactions on Games). Die Breite der Anwendungen lässt sich gut anhand von Yang et al. 2024, „GPT for games: A scoping review", sowie der Scoping-Review von Sweetser 2024 erfassen. Innerhalb dieser Landkarte wird die Position dieses Papers klar, wenn man es als Aufzeichnung der „unmittelbaren Erfahrung, tatsächlich zwei Spiele gebaut und reflektiert zu haben" liest. Wenn als Nächstes die von den Autoren angekündigte Überprüfung mit Spielerbeteiligung erscheint, möchte ich ihr folgen. Die Beziehung zwischen generativer KI und Spielen verschiebt sich gerade von der Saison der Demos hin zur Saison, in der die unspektakuläre Verrohrung entworfen wird.

Quellen

In diesem Artikel herangezogene Paper und verwandte Materialien:

・Large Language Models in Game Development: Implications for Gameplay, Playability, and Player Experience (Johnson, Ahmed, Lang, Thethi, Zheng, de Souza Santos, 2026, arXiv preprint 2603.27896, cs.SE)

・PDF desselben Papers

・DOI: 10.48550/arXiv.2603.27896(veröffentlicht von arXiv, Preprint vor der Begutachtung)

・Sena (eines der in diesem Paper behandelten Spiele, öffentliche Website)

・Verwandte Forschung: Gallotta et al., „Large language models and games: A survey and roadmap" (IEEE Transactions on Games, 2024) / Yang et al., „GPT for games: A scoping review" (IEEE CoG, 2024)