Was kann der KI-Assistent einer verschwundenen Figur in einem Detektivspiel wirklich wissen?
In einem fiktiven Detektivspiel sollte ein KI-Assistent nur die Story-Aufzeichnungen kennen, die die Autorenschaft ihm zugänglich gemacht hat – und dies erst ab dem Zeitpunkt in der Geschichte, an dem diese Aufzeichnungen erreichbar werden. Weisen Sie jedem Fakt eine Quelle, einen Zeitpunkt des Bekanntwerdens und eine Zugriffsregel zu. So kann der Assistent den Spielenden helfen, Hinweise zu verknüpfen, ohne unbemerkt zu einem allwissenden Erzähler zu werden.
Trennen Sie die Aufzeichnungen der Geschichte vom Zugriff des Assistenten
Beginnen Sie mit einer vollständigen, autorenseitigen Dokumentation der Geschichte: Ereignisse, Aussagen von Figuren, Gegenstände, Nachrichten und die Reihenfolge, in der sie ins Spiel eintreten. Definieren Sie dann eine eingeschränktere Ansicht für den Assistenten. Ein Fakt kann in der Story-Bibel existieren, ohne für den Assistenten bereits verfügbar zu sein. Diese Unterscheidung bildet das Fundament eines fairen Rätselspiels: Der Autor weiß vielleicht, was passiert ist, während der Assistent nur Aufzeichnungen nutzen kann, die seine fiktive Rolle ihm zu sehen erlaubt.
Interactive-Fiction-Tools wie Twine organisieren Geschichten in Passagen und können Variablen und bedingte Logik nutzen, um zu verändern, was ein Spieler sieht. Das bietet eine nützliche Design-Analogie: Behandeln Sie jeden verfassten Datensatz als diskrete Einheit und machen Sie den Zugriff darauf abhängig von der entsprechenden Passage, dem Ereignis oder der Entscheidung. Twines grundlegende Konzepte
Nehmen wir zum Beispiel an, eine fiktive Figur namens Mara bereitet eine Ausstellung für einen Gemeinschaftsgarten vor. Der Assistent könnte Zugriff auf eine geteilte Planungsnotiz haben, einen am schwarzen Brett der Gruppe ausgehängten Zeitplan und eine spätere Nachricht von ihr über das Unterstellen bemalter Schilder im Innenbereich. Er sollte nicht darauf schließen, wo Mara sich aufhält, nur weil er weiß, dass sie gerne gärtnert, und er sollte keinen privaten Entwurf sehen, der nie mit ihm geteilt wurde. Diese Grenzen ergeben sich aus den verfassten Zugriffsregeln der Geschichte, nicht aus einer Annahme darüber, worauf echte KI-Systeme zugreifen können.
Geben Sie jedem Fakt eine Quelle und einen Zeitpunkt des Bekanntwerdens
Ein nützlicher Fakten-Datensatz beantwortet mindestens vier Fragen: Was wird behauptet, wer oder was hat die Information geliefert, wann wurde sie für den Assistenten verfügbar und handelt es sich um eine direkte Angabe oder eine Schlussfolgerung? Das W3C-Provenienzmodell beschreibt die Herkunft von Informationen anhand von Entitäten, Aktivitäten und Agenten; es erlaubt auch, in Datensätzen abzubilden, wie ein Element aus einem anderen abgeleitet wurde. Das ist ein praktisches Gerüst für fiktive Aufzeichnungen, selbst wenn ein Spiel einfache Kennzeichnungen statt des formalen Modells verwendet. W3C PROV Model Primer
Ein kompakter Datensatz könnte so aussehen:
Behauptung: Mara plante, die Gartenschilder zu bemalen; Quelle: Geteilte Planungsnotiz; Dem Assistenten bekannt seit: Montag, 10:00 Uhr; Art: Direkte Aussage
Behauptung: Die Schilder wurden nach drinnen gebracht; Quelle: Update am Gruppen-Brett; Dem Assistenten bekannt seit: Dienstag, 16:30 Uhr; Art: Direktes Update
Behauptung: Mara könnte sie hereingeholt haben, weil Regen vorhergesagt war; Quelle: Wetternotiz plus Update; Dem Assistenten bekannt seit: Dienstag, 16:30 Uhr; Art: Schlussfolgerung; unbestätigt
Die Beispielzeitpunkte dienen der Veranschaulichung. Der entscheidende Unterschied liegt zwischen dem Zeitpunkt, an dem ein Ereignis stattfand, und dem Zeitpunkt, an dem der Assistent davon erfuhr. Wenn eine am Montag erstellte Notiz am Dienstag geteilt wird, beginnt das Wissen des Assistenten am Dienstag – es sei denn, die Geschichte gewährt ihm explizit früheren Zugriff. Behalten Sie beide Zeitstempel bei, wenn sie voneinander abweichen.
Halten Sie Beobachtung, Bericht und Schlussfolgerung getrennt
Eine Quelle verleiht ihren Inhalten nicht automatisch Gewissheit. Eine Figur kann beschreiben, was sie gesehen hat; eine Notiz kann unvollständig sein; ein Zeitplan dokumentiert womöglich eher einen Plan als eine tatsächlich durchgeführte Handlung. Die Kennzeichnung des Aufzeichnungstyps hilft dem Assistenten, seine Antwort präzise zu formulieren: „Auf dem Brett steht, dass die Schilder hineingebracht wurden“ unterscheidet sich von „Mara hat die Schilder hineingebracht“, und beides unterscheidet sich von „Sie hat sie wahrscheinlich wegen des Wetters hineingebracht.“
Verwenden Sie durchgängig ein kleines Vokabular: direkte Beobachtung, Bericht einer Figur, verfasste Aufzeichnung und Schlussfolgerung. Eine Schlussfolgerung sollte auf ihre stützenden Datensätze zurückverweisen und als Schlussfolgerung gekennzeichnet bleiben. W3C PROV modelliert explizit die Verantwortung von Agenten für Aktivitäten und die Ableitung einer Entität aus einer anderen; wendet man diese Unterscheidung auf Dialoge an, hilft dies einem Spiel zu zeigen, woher eine Schlussfolgerung stammt, anstatt sie als neue Tatsache darzustellen. W3C PROV-O
Daraus ergibt sich auch ein nützlicher Test für das Schreiben: Kann ein Spieler eine selbstsichere Aussage des Assistenten zu einer Aufzeichnung zurückverfolgen, auf die dieser zugreifen durfte? Wenn nicht, überarbeiten Sie die Antwort, fügen Sie die fehlende geschriebene Aufzeichnung hinzu oder lassen Sie den Assistenten sagen, dass ihm nicht genügend Informationen vorliegen.
Definieren Sie den Zugriff in der Story-Zeit, nicht nur nach Figuren
Legen Sie für jede Aufzeichnung das Ereignis fest, das den Zugriff für den Assistenten freischaltet. Eine geteilte Nachricht könnte verfügbar sein, sobald sie gesendet wird; ein an ein Brett gehefteter Aushang könnte verfügbar sein, wenn der Assistent das Brett überprüft; ein Gespräch könnte erst verfügbar werden, nachdem die spielende Person sich entschieden hat, danach zu fragen. Vermeiden Sie es, sich auf vage Bezeichnungen wie „Der Assistent weiß alles aus dem Archiv“ zu verlassen, es sei denn, die Geschichte legt fest, was dieses Archiv enthält und wann es aktualisiert wird.
Eine praktische Zugriffsregel besteht aus drei Teilen: dem Zielpublikum der Aufzeichnung, ihrem Verfügbarkeitsauslöser und einer etwaigen Verzögerung. Zum Beispiel: „Der Assistent kann Beiträge am Gruppen-Brett lesen, nachdem der Spieler das Brett öffnet; er kann keine persönlichen Entwürfe lesen.“ Die Verzögerung spielt in verzweigten Geschichten eine wichtige Rolle. Wenn ein Spieler das Brett nicht besucht hat, sollte der Assistent sich nicht so verhalten, als hätte er den neuesten Beitrag gesehen, nur weil dieser Beitrag an anderer Stelle in den Dateien des Autors existiert.
In Twine können Story-Variablen über Passagen hinweg verfügbar sein, während temporäre Variablen in Harlowe und SugarCube auf die aktuelle Passage beschränkt sind. Dieser Unterschied verdeutlicht, warum Autoren ganz bewusst entscheiden sollten, ob ein Fakt über die gesamte Geschichte hinweg bestehen bleibt oder nur zu einer bestimmten Szene gehört. Die genaue Umsetzung hängt vom Story-Format ab; betrachten Sie die Regel daher eher als Designmodell denn als Code-Anweisung. Twine Cookbook: Variablen
Machen Sie Ungewissheit für die Spielenden nutzbar
Wenn eine Aufzeichnung fehlt, alt oder mehrdeutig ist, lassen Sie den Assistenten die Lücke in konkreten Worten beschreiben. Er kann sagen, dass er den Plan von Montag hat, aber keine spätere Bestätigung, oder dass eine Figur berichtet hat, die Schilder weggeräumt zu haben, während das Brett kein Update enthält. Das gibt dem Spieler einen sinnvollen nächsten Schritt: eine andere verfasste Quelle prüfen, ein Gespräch mit einer Figur erneut aufgreifen oder entscheiden, dass der Hinweis ungelöst bleibt.
Dieser Ansatz stützt das Mysterium ohne willkürliche Allwissenheit. Die Forschung zu interaktiven Narrativen hat untersucht, wie begrenztes Wissen das Verhalten der Spielenden prägen kann, einschließlich einer Studie, die das Interactive-Fiction-Werk *Anchorhead* nutzte, um Spielermodelle zu erforschen. Für einen geschriebenen Assistenten ist die Designkonsequenz bescheiden: Was Spieler und Assistent gelernt haben, kann ihre nächsten Entscheidungen beeinflussen, also erfassen Sie diese Wissenszustände explizit. Rivera-Villicana et al., „Informing a BDI Player Model for an Interactive Narrative“
Eine kurze Prüfung vor dem Schreiben von Assistenten-Dialogen
Überprüfen Sie vor dem Verfassen einer Antwort diese Punkte für jede folgenreiche Behauptung:
Ist die Behauptung in einer verfassten Aufzeichnung vorhanden oder ist sie als Schlussfolgerung gekennzeichnet?
Nennt die Aufzeichnung ihre Quelle und unterscheidet sie zwischen einem Plan, einem Bericht, einer Beobachtung oder einer späteren Bestätigung?
Zu welchem Zeitpunkt in der Geschichte erhielt der Assistent Zugriff darauf?
Erlaubt die fiktive Rolle des Assistenten den Zugriff auf diese Quelle?
Wenn die Aufzeichnung unvollständig oder widersprüchlich ist, bewahrt der Dialog diese Ungewissheit?
Wenn die Antwort auf einen dieser Punkte unklar ist, schränken Sie die Aussage des Assistenten ein, bis sie mit der verfügbaren Aufzeichnung übereinstimmt. Die resultierende Figur kann dennoch hilfreich sein: Sie kann zusammenfassen, was sie gesehen hat, benennen, was unbestätigt bleibt, und den Spieler zum nächsten verfassten Hinweis leiten. Ihre Glaubwürdigkeit rührt von einer sichtbaren Grenze zwischen den vollständigen Aufzeichnungen der Geschichte und den Informationen her, die sie tatsächlich erhalten hat.