Wie man einen Playtest für KI-Spieldialoge in 20 Minuten beobachtet
Beobachten Sie bei einem kleinen Studio, das eine einzelne generative Dialogszene testet, was Spieler mit den Antworten des NPCs tun: ob sie verschiedene Fragen ausprobieren, nützliche Informationen umsetzen, sich von erfundenen Fakten erholen und den Dialog verlassen, um die Szene abzuschließen. Ein kurzer Fragebogen kann erfassen, was die Spieler im Nachhinein gefühlt oder verstanden haben wollen; er kann jedoch für sich allein genommen nicht die Entscheidungen und Umwege aufzeigen, die sich von Moment zu Moment ereignet haben. Verwenden Sie während des Spielens einen einfachen Ereignisbogen und stellen Sie anschließend gezielte Nachfragen. Betrachten Sie die Beobachtungen als Belege für diese Szene und diesen Build – nicht als Zufriedenheitsmaßstab oder Beweis dafür, wie sich alle Spieler verhalten werden.
Was sollten Sie in einer generativen Dialogszene beobachten?
Wählen Sie eine Szene mit einem klaren Ziel und einem NPC, dessen Antworten die Herangehensweise des Spielers verändern könnten. In einer fiktiven Szene muss der Spieler beispielsweise ein versiegeltes Gewächshaustor öffnen, bevor ein Belüftungszyklus endet. Ein Wartungs-NPC kann durch frei formulierte Gespräche Hinweise liefern. Der vorgesehene Weg besteht darin, einen blauen Ventilgriff im Geräteschuppen zu finden, aber der NPC könnte gelegentlich ein Detail erfinden, wie etwa die Behauptung, der Griff befinde sich im überfluteten Pumpenraum.
Die vier folgenden Indikatoren konzentrieren sich auf das Spielerverhalten und die Konsequenzen innerhalb der Szene. Sie erfordern keine Beurteilung darüber, ob eine Frage clever ist oder ob ein Spieler scheinbar Spaß am Spiel hat.
Indikator: **Variierende Fragen** — Ein Ereignis festhalten, wenn…: Der Spieler nach einer Antwort den Wortlaut, das Thema oder die Herangehensweise ändert – beispielsweise fragt, wo sich ein Ventil befindet, und danach fragt, welche Farbe es hat oder welcher Raum sicher ist. — Zu notierende Belege: Was gefragt wurde, was der NPC geantwortet hat und ob die nächste Frage sich aus dieser Antwort ergab. Unterscheiden Sie eine wirklich neue Erkundigung von einer bloßen Wiederholung. — Danach fragen…: „Was wollten Sie mit diesen Fragen herausfinden?“
Indikator: **Antwort verändert die nächste Aktion** — Ein Ereignis festhalten, wenn…: Der Spieler sich bewegt, etwas inspiziert oder seinen Plan auf eine Weise ändert, die der Antwort des NPCs folgt. — Zu notierende Belege: Die Antwort, die nächste Aktion des Spielers und jede sichtbare Alternative, die er umgangen hat. Markieren Sie den Zusammenhang als eindeutig, plausibel oder ungewiss; eine Aktion nach einer Antwort beweist noch nicht, dass die Antwort sie verursacht hat. — Danach fragen…: „Welcher Teil des Gesprächs hat, falls überhaupt, beeinflusst, was Sie als Nächstes getan haben?“
Indikator: **Erfundener Fakt führt zu einer Fehlentscheidung** — Ein Ereignis festhalten, wenn…: Der Spieler einer bestimmten unbegründeten oder falschen Aussage des NPCs folgt und daraufhin eine unproduktive Aktion ausführt. — Zu notierende Belege: Die genaue Behauptung, die dadurch ausgelöste Aktion, der im Build sichtbare Verlust bzw. Umweg und wie der Spieler den Fehler entdeckt oder korrigiert hat. Überprüfen Sie nach der Sitzung die vorgesehenen Fakten der Szene, bevor Sie eine Aussage als erfunden einstufen. — Danach fragen…: „Warum erschien Ihnen dieser Weg als der richtige? Wann haben Sie beschlossen, den Kurs zu ändern?“
Indikator: **Spieler kann den Dialog beenden und die Szene abschließen** — Ein Ereignis festhalten, wenn…: Der Spieler das Gespräch verlässt, pausiert oder ablehnt und das Ziel weiterhin verfolgen und abschließen kann. — Zu notierende Belege: Ob eine Ausstiegsoption sichtbar ist, was nach dem Verlassen geschieht, ob weiterhin sinnvoller Fortschritt möglich ist und ob der Spieler den Abschlusszustand der Szene erreicht. Erfassen Sie Hindernisse getrennt von der Entscheidung eines Spielers, einfach weiterzureden. — Danach fragen…: „Hatten Sie das Gefühl, das Gespräch verlassen zu können? Was hat Sie dazu bewogen, weiterzusprechen oder aufzuhören?“
Dies sind Ereignisdefinitionen, keine Qualitätsbewertungen. Notieren Sie die tatsächlichen Worte und Aktionen des Spielers, anstatt Absichten aus Mimik, Schweigen oder Spielzeit abzuleiten. Wenn ein Ereignis nicht eintritt, notieren Sie „in dieser Sitzung nicht beobachtet“, keinen mutmaßlichen Fehlschlag.
Den Beobachtungsbogen an den Build binden
Halten Sie vor jeder Sitzung die Build-Version, das Ausgangsziel, die bekannten Szenenfakten und den zulässigen Abschlusszustand fest. Schreiben Sie während des Spielens die Frage des Spielers, die Antwort des NPCs, die nächste sichtbare Aktion und jede festgeschriebene Änderung des Spielzustands auf. Eine Zeile, die hilfreich klingt, kann dennoch falsch sein, wenn sie auf einen Ort verweist, der in diesem Build nicht existiert.
Gleichen Sie nach der Sitzung mutmaßlich erfundene Fakten mit dem eigentlichen Datenblatt der Szene ab. Markieren Sie eine unbegründete Behauptung erst dann als bestätigt erfunden, wenn die Szenenfakten ihr widersprechen; andernfalls stufen Sie sie als ungeklärt ein und untersuchen Sie den Fall. Führen Sie separate Notizen für Moderationshinweise oder technische Unterbrechungen, da diese die nächsten Schritte des Spielers verändern können. Diese kleine Dokumentationskette macht die spätere Diskussion präziser, ohne einen einzelnen Spieldurchlauf zu einem universellen Ergebnis aufzublasen.
Wie man eine begrenzte 20-minütige Sitzung durchführt
Sagen Sie dem Teilnehmer: „Bitte spielen Sie diese Szene so, wie Sie es normalerweise tun würden. Sie können mit der Figur sprechen oder das Gespräch jederzeit verlassen. Ich werde mich möglicherweise ruhig verhalten, um beobachten zu können, was Sie ausprobieren.“ Bringen Sie ihnen nicht bei, abwechslungsreiche Fragen zu stellen, und warnen Sie sie nicht vor erfundenen Fakten; dies würde genau das Verhalten verfälschen, das die Sitzung aufdecken soll. Wenn sie um Hilfe bitten, reagieren Sie einheitlich, protokollieren Sie das Eingreifen und werten Sie das spätere Verhalten unter Berücksichtigung dieser Hilfestellung aus.
Ein praktikabler Zeitplan ist:
**Minuten 0–2: Vorbereitung.** Erklären Sie die Aufgabe und die Steuerung, ohne die vorgesehene Lösung zu beschreiben. Starten Sie die Zeitmessung, sobald der Spieler die Steuerung übernimmt, und beginnen Sie die Szene für jeden Teilnehmer im selben Zustand.
**Minuten 2–15: Beobachten.** Lassen Sie den Spieler erkunden und sprechen. Protokollieren Sie jede relevante Antwort und die nächste Aktion, insbesondere wenn eine Behauptung den Spieler an einen bestimmten Ort schickt. Halten Sie neutrale Nachfragen wie „Was geht Ihnen gerade durch den Kopf?“ für Momente bereit, in denen der Spieler innegehalten hat und einen Anstoß braucht, um fortzufahren; notieren Sie, dass Sie eingegriffen haben.
**Minuten 15–20: Abschluss und Nachfragen.** Wenn der Spieler noch nicht fertig ist, beenden Sie das Spiel nach 15 Minuten und notieren Sie den aktuellen Zustand, anstatt den Eindruck zu erwecken, er habe einen Schnelligkeitstest nicht bestanden. Stellen Sie die auf die beobachteten Ereignisse bezogenen Folgefragen und schließen Sie mit einer offenen Frage ab: „Was, falls überhaupt etwas, war am Gespräch oder an Ihrem nächsten Schritt unklar?“ Erfassen Sie Selbstberichte getrennt vom beobachteten Verhalten.
Das 20-Minuten-Limit ist eine praktische Sitzungsgrenze für dieses Beispiel, kein empirischer Richtwert. Ein Spieler, der mehr Zeit im Gespräch verbringt, hat damit nicht automatisch eine höhere Zufriedenheit gezeigt, und ein Spieler, der schnell abschließt, hat die Szene nicht zwangsläufig besser verstanden oder mehr genossen. Wenn die Aufgabe in Ihrem Build mehr Zeit erfordert, passen Sie den Zeitplan vor den Sitzungen an und behalten Sie ihn einheitlich bei.
Trennen, was passiert ist, von dem, was der Spieler sagt
Im [Postmortem zu The Turing Test](https://www.gamedeveloper.com/business/postmortem-building-i-the-turing-test-i-around-a-secret-mechanic) beschreibt Design Director David Jones das Testen von Rätseln mit Studenten, bei dem Spaß- und Schwierigkeitsbewertungen sowie Spielzeiten erfasst wurden, wobei der Beobachtung des Spielerverhaltens ein höherer Stellenwert eingeräumt wurde. Er schildert, wie Bewertungen und Beobachtungen kombiniert wurden, um die Schwierigkeitskurve zu beurteilen. Für eine Dialogszene besteht die nützliche Lehre darin, beide Arten von Belegen zusammen, aber getrennt zu betrachten: Das Ereignisprotokoll zeigt, was der Spieler getan hat; die Nachbefragung erfasst seine Erklärung oder Bewertung. Keines von beiden erklärt das andere automatisch.
Kleis [Postmortem zu Mark of the Ninja](https://www.gamedeveloper.com/design/classic-postmortem-klei-entertainment-s-i-mark-of-the-ninja-i-) beschreibt regelmäßige Tests mit neuen Spielern, um Designannahmen zu überprüfen. Das Team suchte nach den Ursachen hinter Beschwerden, beobachtete, wo neue Spieler Schwierigkeiten hatten, und passte daraufhin Hinweise und Design an. Auf unseren Fall übertragen: Die Fehlentscheidung eines Spielers ist ein Anhaltspunkt für Nachforschungen – keine Aufforderung, den Dialog des NPCs einfach zu verlängern. Fragen Sie sich, was an der Antwort, der Benutzeroberfläche oder der Szene diesen Weg überzeugend erscheinen ließ, und überprüfen Sie die Aufzeichnung oder den Zustand des Builds, bevor Sie Änderungen beschließen.
Ubisofts [Teammates-Ankündigung](https://staticctf.ubisoft.com/8aefmxkxpxwl/2QCAorjku7w7gH1LGORV3t/6e8f347be3ecab7daa4769e5300086bc/Ubisoft_Unveils_%C3%A2__Teammates%C3%A2____Its_First_Playable_Generative_AI_Experience_Through_Closed_Player_Testing.pdf) beschreibt einen geschlossenen Spielertest für ein spielbares generatives KI-Erlebnis. Sie belegt, dass das Team geschlossene Tests angekündigt hat; sie enthält in der zitierten Ankündigung jedoch keine veröffentlichten Spielergebnisse und kann daher keine Aussagen darüber stützen, was Spieler getan haben oder ob das Erlebnis erfolgreich war.
Beobachtungen in Entscheidungen für den nächsten Build überführen
Gehen Sie nach der Sitzung den zeitlichen Ablauf durch und verknüpfen Sie jede NPC-Antwort mit der nächsten Aktion des Spielers. Überprüfen Sie bei jedem scheinbaren Holzweg die relevanten Fakten der Szene und ermitteln Sie die wahrscheinliche Ursache: Der NPC hat ein falsches Detail geliefert, der Spieler hat eine wahre Antwort missverstanden, oder ein Hinweis in der Umgebung bzw. Interaktion hat ihn woanders hingelenkt. Diese Erklärungen bleiben Hypothesen, bis sie mit der aufgezeichneten Sequenz und gegebenenfalls einer weiteren Sitzung abgeglichen wurden.
Nutzen Sie die vier Indikatoren, um eine konkrete Folgeänderung oder einen Test auszuwählen. Wenn der Spieler mehrere unterschiedliche Fragen stellt, aber Antworten erhält, die keine Handlungen anleiten, prüfen Sie, ob die Szene umsetzbare Informationen bietet. Wenn eine bestimmte erfundene Behauptung ihn in den falschen Raum führt, überlegen Sie, ob die Szene eine Möglichkeit braucht, die Behauptung zu überprüfen oder ohne Sackgasse wieder auf den richtigen Pfad zu gelangen. Wenn der Spieler den Dialog nicht verlassen und die Szene nicht abschließen kann, untersuchen Sie die Ausstiegsoption und den Ablauf des Ziels. Wenn er das Gespräch verlässt und die Szene abschließt, halten Sie fest, dass der Pfad in diesem Build verfügbar war; fragen Sie nach, was er verstanden hat, bevor Sie daraus schließen, dass alles eindeutig war.
Eine einzelne 20-minütige Sitzung kann eine konkrete Unklarheit oder einen fehlenden Pfad aufdecken, aber sie kann nicht feststellen, wie weit verbreitet dieses Problem ist. Halten Sie die Notizen des Beobachters, die verifizierten Szenenfakten und die nachträglichen Antworten des Spielers getrennt, wenn Sie entscheiden, was als Nächstes untersucht werden soll. Das liefert einem kleinen Team einen nützlichen Einblick darin, wie dieser Spieler diese generative Dialogszene bewältigt hat – weit über das hinaus, was ein Fragebogen allein leisten kann.