Come evitare che i dialoghi dei personaggi IA inventino indizi nei giochi investigativi
Se un personaggio gestito dall'IA può parlare di indizi, fai in modo che ogni affermazione utilizzabile dipenda da una fonte scritta dagli autori e da uno stato di scoperta controllato dal gioco. Fornisci al modello solo le prove che il giocatore ha già trovato, richiedigli di identificare la fonte di qualsiasi affermazione simile a un indizio e considera non disponibili i dettagli non supportati. Mantieni le battute e l'atmosfera in un canale separato dedicato al colore narrativo che non possa aggiornare il registro del caso né sbloccare progressi. Questo consente ai personaggi di parlare in modo flessibile senza che i dialoghi improvvisati riscrivano il mistero.
Perché gli indizi inventati compromettono un mistero
In un gioco investigativo, i giocatori raccolgono informazioni, traggono conclusioni e usano ciò che apprendono per cercare altri elementi. Ciò rende la relazione tra l'indizio e la conoscenza del giocatore parte del ciclo centrale del gioco, anziché un semplice dettaglio di stile dei dialoghi. Un personaggio che menziona con sicurezza una lettera non ancora collocata o fa il nome di una persona che il giocatore non ha mai incontrato può inavvertitamente creare una nuova pista. Il giocatore non ha alcun modo affidabile per sapere se quel dettaglio sia un indizio progettato, una bugia intenzionale o un riempitivo generato. L'articolo "Generative Forensics: Procedural Generation and Information Games" descrive i giochi informativi in termini di raccolta della conoscenza e del suo utilizzo per comprendere un mistero; applicando questa prospettiva, affermazioni generate e non monitorate possono confondere la conoscenza su cui il giocatore dovrebbe basare i propri ragionamenti.
La soluzione parte da una distinzione chiara: un indizio è un fatto di gioco su cui il giocatore può agire; il testo di colore narrativo (flavor) è un dialogo espressivo che non aggiunge né modifica i fatti di gioco. Un personaggio può sembrare incerto, evasivo, divertente o espressivo, ma una battuta non deve diventare una prova solo perché è formulata in modo convincente.
Crea un registro di indizi d'autore prima di generare i dialoghi
Mantieni un registro essenziale ed esplicito per ogni indizio utilizzabile. Può risiedere in un database, in un file di contenuti o in uno strumento narrativo; il punto fondamentale è che il modello non ne inventi i contenuti. Includi campi che rispondano a cosa dice l'indizio, da dove proviene, chi può conoscerlo e quando diventa disponibile.
Campo: clue_id; Cosa registra: Identificatore stabile per la prova; Esempio (illustrativo): note_blue_01
Campo: canonical_fact; Cosa registra: Il fatto stabilito dal gioco; Esempio (illustrativo): “Il biglietto è firmato con l'iniziale M.”
Campo: source_id; Cosa registra: Oggetto, scena o battuta d'autore a supporto; Esempio (illustrativo): archive_note_03
Campo: discovery_condition; Cosa registra: Stato di gioco richiesto prima della discussione; Esempio (illustrativo): found_archive_note_03
Campo: allowed_speakers; Cosa registra: Personaggi autorizzati a conoscerlo o a parlarne; Esempio (illustrativo): Mara, Ivo
Campo: certainty; Cosa registra: Se la fonte dichiara un fatto o suggerisce un'interpretazione; Esempio (illustrativo): explicit
Campo: player_facing_label; Cosa registra: Come la prova appare nel diario, se applicabile; Esempio (illustrativo): “Biglietto non firmato”
I nomi e i valori sopra riportati sono un esempio fittizio per mostrare un formato, non un riferimento a un gioco specifico. Si noti come il registro separi il contenuto esplicito di una fonte da un'interpretazione: un'iniziale come firma non stabilisce di per sé chi abbia scritto un biglietto. Questa distinzione offre al sistema di dialogo il margine per consentire a un personaggio di speculare senza presentare tale speculazione come una prova appena verificata.
Vincola gli indizi allo stato di scoperta, non solo alla conversazione
Rappresenta la scoperta come uno stato gestito dal gioco. Ad esempio, found_archive_note_03 diventa true solo quando il giocatore trova effettivamente il biglietto. All'inizio di una conversazione, passa al personaggio un elenco dei fatti d'autore di cui gli è consentito parlare, filtrati in base allo stato di scoperta del giocatore e alle conoscenze del personaggio. Un indizio è disponibile solo quando entrambi i controlli hanno esito positivo: il giocatore ha soddisfatto la relativa condizione di scoperta e chi parla è autorizzato a conoscerlo.
Si tratta di un'applicazione pratica della generazione aumentata dal recupero (RAG): recuperare i record pertinenti, inserirli nel contesto del modello e generare a partire da tali record. La panoramica sulla RAG di Microsoft descrive questo flusso di recupero–integrazione–generazione e avverte che un recupero scarso o incompleto può comunque portare a risultati imprecisi. Per un gioco, il recupero dovrebbe rispettare le condizioni di scoperta prima di raggiungere il modello. Dire al modello "non rivelare nulla" è meno efficace rispetto a trattenere del tutto le prove non scoperte.
Mantieni il controllo dei permessi all'esterno del modello, quando possibile. Dovrebbe essere il gioco, e non una riga di testo generato, a determinare se una prova entra in un diario, risolve un enigma o sblocca un'interazione. Un modello può formulare un fatto autorizzato; lo stato del gioco dovrebbe decidere a monte se quel fatto sia autorizzato.
Fornisci al modello un perimetro ristretto e un'alternativa sicura
Un prompt efficace dovrebbe specificare la voce del personaggio, la scena attuale, i record degli indizi consentiti e la differenza tra prove ed elementi di colore narrativo. Definisci cosa fare quando una domanda va oltre le prove fornite: rifiutarsi di confermarla, affermare che il personaggio non sa, oppure rispondere con una battuta non utilizzabile coerente con il personaggio. Includi anche istruzioni per i record contrastanti o ambigui. Le linee guida di Microsoft sul prompt engineering per la RAG raccomandano limiti espliciti di radicamento (grounding), comportamenti di fallback, identificatori di fonte e istruzioni per i conflitti. Questi sono principi di progettazione utili sia per i dialoghi controllati dei personaggi che per gli assistenti informativi.
Ad esempio, se il giocatore chiede se l'iniziale M dimostri che Mara ha scritto il biglietto, la risposta consentita potrebbe essere: “La M c'è, ma questo da solo non ci dice chi l'ha firmato”. Il sistema può autorizzare questa formulazione perché preserva la differenza tra il fatto originale e una conclusione. Non dovrebbe invece improvvisare un testimone, una perizia calligrafica o un secondo documento solo per rendere la risposta più soddisfacente.
Fai in modo che il modello restituisca campi strutturati come spoken_text, claim_type e source_ids. Per una risposta contenente un indizio, richiedi almeno un identificatore di fonte valido e confrontalo con i record forniti per quel turno. Per gli elementi di colore narrativo, contrassegna la risposta come non probatoria e non permetterle di impostare flag di indizi. L'output strutturato non garantisce che il testo sia vero; crea piuttosto un elemento che il gioco può verificare prima della visualizzazione o della modifica di stato.
Etichetta gli elementi di colore affinché i giocatori ne comprendano il peso
Il testo di colore narrativo potrebbe includere lo stato d'animo di un personaggio, una battuta innocua o una reazione generica alla stanza. Non dovrebbe introdurre di nascosto una data, un luogo, un oggetto, un testimone nominato, un movente o altri dettagli che i giocatori potrebbero ragionevolmente considerare una pista. Se desideri discorsi speculativi, rendi evidente l'incertezza nella formulazione ed escludila dai sistemi oggettivi come l'elenco delle prove, lo stato delle missioni e le interazioni basate sugli indizi.
Questa distinzione può riflettersi sia nei dati che nella presentazione. Internamente, etichetta le battute come prova, interpretazione o colore narrativo; nell'interfaccia, riserva lo stile grafico delle prove o le voci del diario agli indizi creati dagli autori del gioco. Un personaggio può dire: “Forse il biglietto è stato lasciato in fretta”, ma a meno che il gioco non abbia previsto questa possibilità come interpretazione consentita, non dovrebbe apparire come un indizio confermato né attivare una nuova diramazione. Questa etichettatura a tre vie è una raccomandazione di design che nasce dalla necessità di preservare ciò che la fonte dice, ciò che qualcuno deduce e ciò che è mera espressione dialogica.
Usa strumenti narrativi per tracciare stati e condizioni
Non è necessario un motore specifico per applicare questo approccio. Gli strumenti per la narrativa interattiva supportano comunemente passaggi o sezioni, variabili e contenuti condizionali. La documentazione ufficiale di scrittura di Ink descrive variabili e logica condizionale per controllare i contenuti della storia; la guida ai passaggi del Twine Cookbook spiega i passaggi come sezioni di contenuto che possono anche contenere codice in grado di influenzare l'aspetto o la reattività del testo. Queste funzionalità possono rappresentare lo stato di scoperta, le conoscenze dell'interlocutore e i dialoghi condizionali, sia che il dialogo stesso sia generato o scritto a monte.
Mantieni coerenti gli ID degli indizi e i nomi degli stati all'interno del registro narrativo e della logica di gioco. Una variabile come found_archive_note_03 è più facile da verificare rispetto a un generico flag clue2, soprattutto quando scene diverse la leggono o la impostano. Aggiungi un collegamento tracciabile da ogni battuta generata utilizzabile al relativo record sorgente consentito; se una riga non ha una fonte valida, il runtime può rifiutarla o richiedere un'alternativa sicura anziché trattarla come una prova.
Verifica i confini con sessioni di playtest mirate
Testa le conversazioni sui limiti della scoperta, dove le regole di stato hanno maggiori probabilità di fallire. Prova una nuova conversazione prima che l'indizio venga trovato, subito dopo averlo trovato e dopo che ha parlato un personaggio con conoscenze diverse. Poni domande dirette su prove non ancora scoperte, fai una domanda a cui la fonte risponde solo parzialmente e rigioca la scena se il gioco lo consente. Confronta la battuta visualizzata, gli ID sorgente restituiti e qualsiasi modifica al diario o allo stato della storia.
Una lista di controllo sintetica aiuta a mantenere concrete queste verifiche:
Ogni affermazione utilizzabile corrisponde a un indizio d'autore o a un'interpretazione esplicitamente consentita.
La condizione di scoperta dell'indizio risulta vera prima che esso appaia come conoscenza disponibile.
L'interlocutore è autorizzato a conoscere tali informazioni in quella scena.
Le domande prive di supporto ricevono l'alternativa di fallback stabilita invece di un nuovo fatto specifico.
Le battute di colore narrativo non possono aggiungere voci al diario, soddisfare requisiti di indizi o modificare lo stato delle prove.
Record ambigui o contrastanti generano incertezza o un fallback verificabile, non una nuova risoluzione introdotta silenziosamente.
Il radicamento (grounding) riduce lo spazio per piste inventate, ma non garantisce che il testo generato rispetti sempre i fatti forniti. Il recupero può tralasciare un record pertinente e un modello può comunque produrre testo impreciso nonostante il grounding, come osserva Microsoft nelle sue linee guida sui limiti della RAG. Mantieni l'autorità finale sugli indizi nei record d'autore e nella logica di gioco; usa la generazione per dare voce e carattere attorno a quei confini.
La regola pratica è semplice: lascia che il modello scelga le parole, mentre il mistero scritto a monte e lo stato attuale del gioco decidono cosa quelle parole siano autorizzate a stabilire. Quando ogni indizio utilizzabile ha una fonte, un vincolo di scoperta e uno stato chiaro, i personaggi possono risultare più colloquiali senza fornire ai giocatori prove che il gioco non ha mai previsto.