Quali decisioni del giocatore dovrebbero ricordare i personaggi dei videogiochi?
Per chi si occupa di narrative writing nei videogiochi, le decisioni del giocatore più preziose da ricordare sono quelle in grado di cambiare una scena, una relazione o un'azione futura. Traccia ciò a cui un personaggio ha effettivamente assistito separatamente da ciò che è accaduto nel mondo e da ciò che ha semplicemente sentito dire. Poi dai a ogni ricordo una fonte, una ragione per essere rilevante e una regola su quando può svanire o essere corretto. Ricordare ogni singola battuta aggiunge solo lavoro di gestione; ricordare una scelta che cambia le azioni di qualcuno dà a quella scelta una vera conseguenza.
Scegli le decisioni in base al loro risvolto futuro
Una decisione merita un posto nella memoria di un personaggio quando richiamarla trasforma la scena presente. Prima di salvare una scelta, chiediti: cosa può fare, dire, rivelare, rifiutare o offrire diversamente questo personaggio grazie a essa? Se la risposta è “nulla”, l'informazione appartiene forse a un registro missioni o a uno stato del mondo, oppure non ha alcun bisogno di essere conservata.
Un test pratico consiste nello scrivere prima il momento successivo. Ad esempio: “Al posto di blocco, la guardia affida al giocatore il registro sigillato perché in precedenza le ha restituito il distintivo”. Se il momento dipende da una decisione ricordata, salva il fatto rilevante. Se la guardia si comporta allo stesso modo in entrambi i casi, il ricordo potrebbe essere puramente decorativo anziché drammatico.
I ricordi utili rientrano spesso in tre gruppi sovrapposti:
**Impegni e costi:** il giocatore ha promesso, rifiutato, sacrificato, restituito o protetto qualcosa, e il risultato può avere un peso in seguito.
**Priorità rivelate:** in una scelta condizionata, ciò che il giocatore ha deciso di proteggere o rischiare aiuta a definire il modo in cui un personaggio interpreterà un'offerta futura. Consideralo come una prova data da una scelta specifica, non come una diagnosi definitiva del giocatore.
**Conseguenze irrisolte:** una scelta ha lasciato una persona, un oggetto o un obbligo in una condizione diversa. Il ricordo acquista importanza quando un personaggio si imbatte in seguito in quella condizione o decide cosa fare al riguardo.
Queste sono euristiche di design, non affermazioni secondo cui ogni gioco debba avere una memoria persistente dei personaggi. Il loro valore dipende dal fatto che la scena successiva dia o meno all'evento ricordato una conseguenza leggibile.
Separa la memoria dallo stato del mondo e dai rumor
Un sistema narrativo affidabile distingue l'evento dalla conoscenza che ogni personaggio ne ha. Un giocatore potrebbe nascondere una chiave in segreto (stato del mondo); un compagno potrebbe vedere l'azione (memoria del personaggio); un negoziante potrebbe sentire un resoconto impreciso (voce di corridoio). Appiattire tutto questo in un unico flag può far sembrare i personaggi onniscienti o far passare una diceria per una prova.
Per ogni evento di rilievo, registra una provenienza sufficiente a rispondere a quattro domande:
**Evento:** che cosa è successo nel mondo? Il giocatore ha restituito la chiave d'ottone.
**Osservatore:** chi ha visto o sentito direttamente l'accaduto? Mara ha assistito alla consegna.
**Canale:** in che modo gli altri l'hanno saputo? Il traghettatore l'ha sentito da Mara.
**Affidabilità:** quanto è certa l'informazione? Testimoniata; riferita; contestata.
Una struttura di design compatta potrebbe apparire così: `returned_key = true`; `Mara.knows_returned_key = witnessed`; `Ferryman.knows_returned_key = reported_by_Mara`. Questi sono campi illustrativi, non un formato tecnico prescrittivo. La distinzione fondamentale è che il fatto accaduto nel mondo non diventa automaticamente conoscenza di ogni personaggio.
Questa separazione offre a chi scrive opzioni migliori per la scena. Mara può riferirsi alla consegna come a qualcosa visto con i propri occhi. Il traghettatore può ripeterlo con incertezza, chiedere se sia vero o agire sulla base di una versione errata. Se il giocatore ha nascosto la chiave e nessuno ha assistito all'azione o trovato il nascondiglio, un personaggio deve avere un modo plausibile per venirne a conoscenza.
Costruisci una scelta che possa avere un risvolto in seguito
Prendiamo una scena fittizia in cui il giocatore trova una lanterna di segnalazione danneggiata e un messaggero di nome Iven che attende dietro le sbarre di un cancello chiuso a chiave. Il giocatore ha tre opzioni:
**Dare a Iven l'unica fiaschetta d'olio funzionante.** Il segnale resta spento, mentre Iven fugge e potrà in seguito portare un messaggio.
**Usare l'olio per accendere il segnale.** Una pattuglia nota l'avviso, ma Iven rimane dietro il cancello finché non arrivano i soccorsi.
**Tenere l'olio e andarsene.** Il giocatore conserva la risorsa; il destino immediato di Iven dipende dalle regole stabilite nella scena, e l'assenza del giocatore non deve essere riscritta come un'azione a cui si è assistito.
Ora stabilisci chi sa cosa. Se Iven vede che gli viene data la fiaschetta, ricorda di aver ricevuto aiuto. Se vede invece che viene acceso il segnale, può ricordare la scelta del giocatore di chiamare aiuto, pur ricordando di essere stato lasciato ad aspettare. Se il giocatore se ne va senza essere visto, Iven non può ricordare sinceramente il giocatore mentre gli volta le spalle; un altro personaggio potrebbe in seguito segnalare una lanterna vuota o una fiaschetta mancante, ma questi indizi non provano chi abbia preso cosa.
Una scena successiva può esprimere queste differenze attraverso l'azione anziché un riepilogo. Iven potrebbe affidare un messaggio al giocatore dopo aver ricevuto l'olio, chiedere spiegazioni dopo aver atteso i soccorsi, oppure reagire senza attribuire l'olio mancante al giocatore se non lo ha visto allontanarsi. Questi sono risvolti possibili per questo esempio, non reazioni emotive universali. La scena deve stabilire perché Iven risponde in quel modo, e altri eventi potrebbero complicare la sua reazione.
Mantieni il ricordo specifico: “Iven ha visto il giocatore dargli la fiaschetta d'olio” è più utile di “Iven si fida del giocatore”. La prima frase registra un evento e la sua fonte; la seconda trasforma un singolo evento in una conclusione generica sul rapporto. Se la fiducia è una variabile di gioco, mostra la regola che la aggiorna e il comportamento successivo su cui può influire. Un evento ricordato può informare una relazione senza determinarla meccanicamente.
Assegna ai ricordi una durata e una possibilità di correzione
Non tutti i dettagli ricordati dovrebbero rimanere vividi allo stesso modo per sempre. Imposta la ritenzione in base alla funzione drammatica: mantieni un ricordo finché sblocca una scena pianificata, risolve un obbligo o supporta un richiamo successivo; lascia svanire i dettagli di poco conto quando non influiscono più sull'esperienza di gioco. La “scadenza” non significa necessariamente che un personaggio dimentichi a comando un evento che gli ha cambiato la vita. Può semplicemente indicare che il gioco smette di riportare un fatto secondario nei dialoghi dopo l'unico utilizzo previsto.
La correzione è essenziale quando un ricordo è nato da una voce di corridoio, da un'osservazione incompleta o da una prima impressione fuorviante. Un personaggio che ha sentito dire che il giocatore ha preso l'olio della lanterna può scoprire che invece lo ha consegnato a Iven. Decidi cosa accade dopo: il flag della voce di corridoio viene corretto, il personaggio mantiene sia la notizia originale che la rettifica, o rimane scettico? La risposta dipende dalla storia, ma la correzione non dovrebbe riscrivere silenziosamente ciò che il personaggio ha udito in precedenza.
Una voce di memoria funzionale può includere uno stato come `current`, `disputed` o `corrected`, oltre alla fonte dell'aggiornamento. Questo aiuta a evitare che una battuta successiva ripeta una voce smentita come se fosse un fatto accertato. Se due testimoni sono in disaccordo, mantieni viva la discrepanza dove conta, invece di imporre una verità unica e onnisciente nei dialoghi di tutti i personaggi.
Trasforma la memoria in uno stato narrativo azionabile
Il ricordo di un personaggio dovrebbe collegarsi a una reazione possibile. Definisci le condizioni di tale reazione e l'effetto che produce: cosa deve essere successo, chi deve saperlo e cosa cambia nella scena successiva? Questa struttura rende la memoria verificabile ed evita che una scelta venga salvata senza influenzare mai il gioco.
Ciò è in linea con un concetto limitato e pertinente illustrato in [STORY2GAME](https://arxiv.org/abs/2505.03547): il documento descrive la generazione di azioni per la narrativa interattiva con precondizioni ed effetti che guidano quali parti dello stato del gioco richiedono tracciamento e come le azioni modificano tale stato. Il suo focus è la generazione di azioni e dello stato di gioco, e la sua valutazione riguarda la capacità del codice d'azione generato di supportare l'esperienza di gioco attraverso storie generate. Non è uno studio che dimostra come i ricordi delle scelte migliorino la narrazione d'autore o l'esperienza del giocatore. Per gli scrittori, l'applicazione utile è più circoscritta: specificare la condizione in cui un evento ricordato ha importanza e l'effetto concreto quando ciò accade.
L'articolo [StratMem-Bench paper in the ACL Anthology](https://aclanthology.org/2026.acl-long.1491/) valuta come i personaggi virtuali utilizzino i ricordi nelle conversazioni incentrate sul personaggio. Il suo benchmark comprende ricordi necessari, di supporto e irrilevanti, e segnala che i modelli hanno gestito i ricordi necessari rispetto a quelli irrilevanti meglio dei casi in cui i ricordi di supporto complicavano la decisione. Si tratta di un benchmark sulla conversazione dei personaggi virtuali, non di uno studio sui risultati narrativi nei giochi. Non stabilisce quali scelte debbano essere salvate da chi scrive un gioco; offre tuttavia un utile promemoria per valutare se un ricordo sia necessario, puramente utile o del tutto irrilevante per la scena attuale.
Verifica le conseguenze ricordate in fase di QA
Testa la scelta nel momento in cui viene presa e di nuovo a ogni risvolto previsto. Un ciclo di QA essenziale può intercettare la maggior parte degli errori di continuity:
**Controllo testimoni:** per ogni battuta che fa riferimento a una decisione, verifica che chi parla vi abbia assistito o possa indicare una fonte di informazione plausibile.
**Controllo delle ramificazioni:** gioca ogni percorso di scelta e conferma che imposti correttamente gli eventi e le registrazioni di conoscenza previsti. Controlla che due esiti mutuamente esclusivi non rimangano entrambi attivi.
**Controllo dei risvolti:** conferma che ogni memoria registrata modifichi una battuta disponibile, una risposta nella relazione, una condizione della scena o un'azione. Se non cambia nulla, riconsidera la necessità di conservarla.
**Controllo dei rumor:** verifica che le informazioni di seconda mano siano presentate con il giusto grado di incertezza e che un'eventuale correzione aggiorni coerentemente le scene successive.
**Controllo di scadenza:** torna sulla scena dopo che il ricordo ha svolto il suo scopo previsto. Assicurati che le informazioni a bassa priorità smettano di emergere e che le conseguenze irrisolte fondamentali rimangano accessibili.
**Controllo di assenza:** verifica come si comporta il personaggio quando l'evento non è stato visto, non è mai stato riferito o è stato deliberatamente nascosto. Evita che l'assenza di un flag si traduca automaticamente in conoscenza.
La domanda finale di design è semplice: ricordare questa scelta dà al personaggio un motivo per comportarsi diversamente ora, e il giocatore può comprenderne il perché? Quando la risposta è chiara, un piccolo numero di ricordi ben documentati può avere un peso drammatico maggiore rispetto alla trascrizione di ogni singola interazione.