Blog Metlivi

Cosa può davvero sapere l'assistente IA di un personaggio scomparso in un gioco investigativo?

In un gioco investigativo di finzione, un assistente IA dovrebbe conoscere solo le informazioni della storia che l'autore gli ha reso disponibili, e solo a partire dal momento narrativo in cui tali informazioni diventano accessibili. Assegna a ogni fatto una fonte, il momento in cui è diventato noto e una regola di accesso. Questo permette all'assistente di aiutare i giocatori a collegare gli indizi senza trasformarsi silenziosamente in un narratore onnisciente.

30 settembre 20266 min di letturaLettura, arte e culturaDi Metlivi Editorial Team
Sezione 1

Separare i registri narrativi dall'accesso dell'assistente

Inizia con una traccia completa della storia riservata all'autore: eventi, affermazioni dei personaggi, oggetti, messaggi e l'ordine in cui compaiono nel gioco. Poi definisci una visione più ristretta per l'assistente. Un fatto può esistere nella "bibbia" della storia senza essere ancora accessibile all'assistente. Questa distinzione è il fondamento di un giallo onesto: l'autore può sapere cosa è successo, mentre l'assistente può utilizzare solo le registrazioni che il suo ruolo narrativo gli consente di vedere.

Gli strumenti di narrativa interattiva come Twine organizzano le storie in passaggi (passage) e possono utilizzare variabili e logica condizionale per modificare ciò che un giocatore vede. Questo offre un utile parallelismo progettuale: tratta ogni dato scritto dall'autore come un'unità distinta e rendi l'accesso a esso condizionato al passaggio, evento o scelta pertinente. Twine’s basic concepts

Ad esempio, immagina che un personaggio di fantasia di nome Mara stia preparando un'esposizione per un orto comunitario. L'assistente potrebbe avere accesso a una nota di pianificazione da lei condivisa, a un programma affisso sulla bacheca di gruppo e a un messaggio successivo in cui Mara afferma di aver portato i cartelli dipinti al coperto. Non dovrebbe dedurre dove si trovi Mara solo perché sa che le piace il giardinaggio, né dovrebbe visualizzare una bozza privata che non è mai stata condivisa con esso. Questi limiti derivano dalle regole di accesso stabilite dall'autore per la narrazione, non da speculazioni su ciò a cui i veri sistemi di IA possono accedere.

Sezione 2

Assegnare a ogni fatto una fonte e un momento di acquisizione

Una scheda informativa utile risponde ad almeno quattro domande: cosa viene affermato, chi o cosa lo ha fornito, quando è diventato accessibile all'assistente e se si tratta di un dato diretto o inferito. Il modello di provenienza del W3C descrive le origini delle informazioni in termini di entità, attività e agenti; permette inoltre alle registrazioni di descrivere come un elemento sia stato ricavato da un altro. Si tratta di un modello pratico per i registri di finzione, anche se un gioco utilizza etichette semplici al posto del modello formale. W3C PROV Model Primer

Una scheda sintetica potrebbe avere questo aspetto:

Affermazione: Mara intendeva dipingere i cartelli dell'orto; Fonte: Nota di pianificazione condivisa; Nota all'assistente da: Lunedì, 10:00; Tipologia: Affermazione diretta

Affermazione: I cartelli sono stati portati al coperto; Fonte: Aggiornamento sulla bacheca di gruppo; Nota all'assistente da: Martedì, 16:30; Tipologia: Aggiornamento diretto

Affermazione: Mara potrebbe averli spostati perché erano previste piogge; Fonte: Nota meteorologica più aggiornamento; Nota all'assistente da: Martedì, 16:30; Tipologia: Inferenza; non confermata

Gli orari di esempio hanno uno scopo illustrativo. L'importante è distinguere tra quando è avvenuto un evento e quando l'assistente ne è venuto a conoscenza. Se una nota creata lunedì viene condivisa martedì, la conoscenza dell'assistente inizia martedì, a meno che la storia non gli dia esplicitamente accesso prima. Conserva entrambe le marcature temporali quando differiscono.

Sezione 3

Mantenere distinte osservazione, testimonianza e inferenza

Una fonte non rende automaticamente certi i propri contenuti. Un personaggio può descrivere ciò che ha visto; un appunto può essere incompleto; un programma può registrare un piano anziché un'azione effettivamente avvenuta. Etichettare il tipo di dato aiuta l'assistente a formulare la risposta in modo accurato: «La bacheca dice che i cartelli sono stati spostati» è diverso da «Mara ha spostato i cartelli», ed entrambi differiscono da «Probabilmente li ha spostati a causa del meteo».

Usa un vocabolario ristretto e coerente: osservazione diretta, testimonianza del personaggio, registro dell'autore e inferenza. Un'inferenza dovrebbe rimandare alle informazioni di supporto e rimanere contrassegnata come tale. W3C PROV modella esplicitamente la responsabilità degli agenti per le attività e la derivazione di un'entità da un'altra; applicare questa distinzione ai dialoghi aiuta il gioco a mostrare da dove proviene una conclusione invece di presentarla come un fatto nuovo. W3C PROV-O

Questo crea anche un utile test di verifica in fase di scrittura: il giocatore riesce a ricondurre un'affermazione sicura dell'assistente a una fonte a cui l'assistente aveva effettivamente accesso? Se la risposta è no, correggi la risposta, aggiungi l'informazione mancante nella storia o fai dire all'assistente che non dispone di elementi sufficienti.

Sezione 4

Definire l'accesso nel tempo narrativo, non solo in base al personaggio

Per ogni informazione, specifica l'evento che ne sblocca l'accesso per l'assistente. Un messaggio condiviso potrebbe essere disponibile non appena viene inviato; un avviso affisso su una bacheca potrebbe essere disponibile quando l'assistente consulta la bacheca; una conversazione potrebbe diventare disponibile solo dopo che il giocatore sceglie di fare domande al riguardo. Evita di affidarti a formule vaghe come «l'assistente sa tutto ciò che c'è nell'archivio», a meno che la storia non stabilisca cosa contiene quell'archivio e quando viene aggiornato.

Una regola di accesso funzionale si compone di tre parti: il destinatario dell'informazione, il fattore che ne sblocca la disponibilità ed eventuali ritardi. Ad esempio: «L'assistente può leggere i post sulla bacheca di gruppo dopo che il giocatore apre la bacheca; non può leggere le bozze personali». Il ritardo è importante nelle storie a bivi. Se un giocatore non ha visitato la bacheca, l'assistente non dovrebbe comportarsi come se avesse visto l'ultimo post solo perché quel post esiste altrove nei file dell'autore.

In Twine, le variabili di storia possono essere accessibili attraverso diversi passaggi, mentre le variabili temporanee sono limitate al passaggio corrente in Harlowe e SugarCube. Questa differenza illustra perché gli autori dovrebbero decidere consapevolmente se un fatto persiste nell'intera storia o appartiene solo a una scena particolare. L'implementazione esatta dipende dal formato della storia, quindi considera questa regola come un modello di design piuttosto che come istruzioni di codice. Twine Cookbook: Variables

Sezione 5

Rendere l'incertezza utile al giocatore

Quando un'informazione manca, è datata o risulta ambigua, lascia che l'assistente descriva questa lacuna in termini concreti. Può dire di avere il piano di lunedì ma nessuna conferma successiva, oppure che un personaggio ha riferito di aver spostato i cartelli mentre la bacheca non riporta alcun aggiornamento. Questo offre al giocatore un passo successivo significativo: verificare un'altra fonte narrativa, tornare a dialogare con un personaggio o considerare l'indizio ancora irrisolto.

Questo approccio valorizza il mistero senza ricorrere a un'onniscienza arbitraria. La ricerca sulla narrativa interattiva ha esaminato come una conoscenza limitata possa influenzare il comportamento dei giocatori, compreso uno studio basato sull'avventura testuale *Anchorhead* per analizzare i modelli di comportamento del giocatore. Per un assistente diegetico, l'implicazione di design è semplice: ciò che il giocatore e l'assistente hanno appreso può influenzare le loro scelte successive, per cui è opportuno tracciare esplicitamente questi stati di conoscenza. Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”

Sezione 6

Una rapida verifica prima di scrivere i dialoghi dell'assistente

Prima di redigere una risposta, verifica questi punti per ogni affermazione rilevante:

L'affermazione è presente in un registro narrativo ufficiale o è etichettata come inferenza?

Il registro specifica la propria fonte e distingue tra un piano, una testimonianza, un'osservazione o una conferma successiva?

In quale momento della storia l'assistente vi ha avuto accesso?

Il ruolo fittizio dell'assistente gli consente di accedere a quella fonte?

Se il dato è incompleto o contraddittorio, il dialogo riflette tale incertezza?

Se la risposta a una qualsiasi di queste domande è incerta, ridimensiona l'affermazione dell'assistente finché non corrisponde a ciò che è effettivamente disponibile. Il personaggio risultante potrà comunque essere utile: potrà riassumere ciò che ha visto, individuare cosa resta da confermare e indirizzare il giocatore verso il successivo indizio narrativo. La sua credibilità deriva da un confine chiaro tra l'insieme completo della storia e le informazioni che ha realmente ricevuto.

Letture correlate

Continua a esplorare il tema