Stati di errore nei giochi testuali: come distinguere un imprevisto narrativo da un problema di input o di recapito
In un gioco testuale in stile chat, un turno non riuscito non significa sempre che il giocatore abbia fatto una scelta sbagliata. La scena potrebbe essere giunta a un valido imprevisto narrativo, il gioco potrebbe non supportare la formulazione usata, il personaggio potrebbe non avere le informazioni necessarie per agire oppure il messaggio potrebbe non essere stato recapitato. Queste situazioni richiedono feedback diversi e diversi effetti di riprova. Classifica innanzitutto la causa, poi spiega al giocatore cosa è cambiato e cosa può accadere in seguito.
Inizia chiedendoti cosa è andato storto
Una prima domanda pratica è: il gioco ha compreso l'azione desiderata e l'ha risolta all'interno della narrazione? In caso affermativo, il risultato potrebbe essere un imprevisto narrativo. In caso contrario, stabilisci se il problema risieda nell'input, nelle informazioni del personaggio o nell'invio da parte del sistema. Questa distinzione in quattro parti è un supporto alla progettazione dedotto dal modo in cui i sistemi di narrativa interattiva separano parsing, regole del mondo, flusso della storia e comportamento di annullamento (undo); non si tratta di uno standard tecnico universale. La documentazione di Inform, ad esempio, descrive il parser e il modello del mondo simulato come parti separate di un gioco, e il suo parser può segnalare diverse ragioni per cui un comando non ha trovato corrispondenza. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)
Tratta il messaggio come parte del contratto di risposta del gioco. Dovrebbe chiarire tre elementi: cosa è successo, se lo stato narrativo è cambiato e cosa può fare il giocatore ora. Una breve frase come “La barchetta di carta si rovescia prima di raggiungere la riva opposta. Il biglietto piegato è ancora nella tua mano. Puoi provare un canale più largo o scegliere un altro modo per attraversare” rende chiari l'imprevisto, l'oggetto conservato e il passo successivo.
1. Un valido imprevisto narrativo
Un imprevisto narrativo è appropriato quando il gioco ha compreso l'azione, l'ha verificata rispetto alla scena corrente e ha prodotto intenzionalmente una conseguenza nel mondo di gioco. Forse il giocatore tenta di trasportare troppi libri della biblioteca contemporaneamente e uno scivola su una sedia vicina. Forse una barchetta di carta imbarca acqua prima di raggiungere l'altro lato di un ruscello poco profondo. Il risultato può essere scomodo o sorprendente senza trasformare l'interazione in un giudizio sulle capacità del giocatore.
La caratteristica fondamentale è il cambiamento di stato. Se la scena dice che la barca è affondata, tale esito deve essere vero nella storia. Se il giocatore può recuperarla, spiega come; se la barca è persa, non far credere che riprovare con lo stesso testo annullerà l'evento. Riprovare potrebbe significare costruire un'altra barca, scegliere un percorso alternativo o proseguire partendo dalla scena modificata. L'opzione esatta dipende dalle regole del gioco.
Un messaggio di imprevisto efficace nomina l'azione tentata, la conseguenza e le opzioni disponibili per proseguire. Non dovrebbe camuffare un'azione supportata da errore di input solo perché l'esito è stato sfavorevole. Viceversa, non suggerire che si sia verificata una conseguenza se il gioco non ha effettivamente modificato lo stato della storia. Questa distinzione permette al giocatore di comprendere se sta continuando da una nuova situazione o se sta correggendo un comando non elaborato.
2. Input non supportato: il gioco non è riuscito a interpretare il testo
Un input non supportato si verifica quando il sistema non riesce a mappare il messaggio del giocatore su un'azione prevista. Il giocatore potrebbe digitare “chiedi al fornaio delle albicocche” in una scena in cui il gioco accetta solo un piccolo insieme di pulsanti di scelta, oppure usare un nome che il parser non riconosce. Questo dice qualcosa sulla copertura dell'interfaccia, non sulla validità dell'idea del giocatore.
I parser di narrativa interattiva mostrano bene perché un feedback utile debba essere specifico: Inform elenca errori distinti per un verbo non riconosciuto, un riferimento poco chiaro, un input troppo breve e un oggetto non visibile. Il suo manuale mostra anche come un gioco possa sostituire un errore generico del parser con un messaggio più informativo. (Inform 7 §18.35: Printing a parser error) In un gioco via chat, una risposta sintetica potrebbe essere: “Non riesco a interpretare ‘chiedi delle albicocche’ qui. Puoi chiedere della consegna o scegliere un argomento dal bancone.”
Offri una via di correzione. A seconda dell'interfaccia, ciò potrebbe significare mostrare le opzioni riconosciute, porre una singola domanda mirata di chiarimento o invitare il giocatore a riformulare. Non descrivere un comando non supportato come un fallimento all'interno della storia: se non è stata eseguita alcuna azione, dichiaralo chiaramente. Mantieni intatta la scena precedente e chiarisci che l'invio di un input corretto permetterà di riprovare lo stesso momento, anziché riavvolgere un evento narrativo.
3. Conoscenza del personaggio non disponibile: una domanda valida che non ha ancora risposta
A volte l'input è comprensibile, ma il personaggio non sa abbastanza per agire di conseguenza. Un giocatore potrebbe chiedere all'assistente di un negoziante dove sia stato consegnato un pacco, prima che l'assistente abbia visto la ricevuta. Il gioco può riconoscere la domanda pur trattenendo legittimamente una risposta definitiva.
Questo differisce da un input non supportato: l'argomento o l'azione sono validi, e la limitazione risiede nelle informazioni possedute dal personaggio all'interno della narrazione. Definisci chiaramente questo limite. Ad esempio: “Mina non ha visto la bolla di consegna, quindi non può dirti la via. L'etichetta del pacco è ancora sul bancone.” Se il giocatore può esaminare l'etichetta, chiedere a qualcun altro o tornare più tardi, indica questa possibilità. In caso contrario, riferisci ciò che è effettivamente noto invece di inventare un indizio o trattare la domanda come mal formulata.
Decidi se questa risposta fa avanzare il tempo o cambia lo stato. Se porre la domanda è una normale azione nel mondo di gioco, il sistema potrebbe registrare la conversazione o modificare il modo in cui un personaggio risponderà in seguito. Se il gioco prevede che le domande di informazione siano gratuite in termini di risorse o tempo, preserva la scena e consenti di porre un'altra domanda subito dopo. Il giocatore non dovrebbe dover tirare a indovinare per capire se una richiesta di informazioni abbia silenziosamente consumato un'opportunità.
4. Errore tecnico di recapito: l'azione potrebbe non aver mai raggiunto la storia
Un errore di recapito avviene al di fuori della narrazione: una risposta scade per timeout, appare due volte o si interrompe a metà frase. Il gioco non può affermare con certezza che il personaggio abbia agito o che la storia sia andata avanti a meno che non sappia che l'azione è stata elaborata. Questo è diverso da un messaggio interno al mondo come “il corriere non ha trovato l'indirizzo”, che rappresenta invece un esito narrativo.
Usa formule di stato chiare e segnala lo stato noto. Se il gioco può verificare che il turno non è stato elaborato, segnalalo e permetti al giocatore di inviarlo nuovamente. Se non può determinare se il turno sia stato elaborato o meno, evita di invitare a una ripetizione alla cieca che potrebbe eseguire l'azione due volte. Spiega brevemente l'incertezza e offri un modo per verificare la scena corrente o riprendere dall'ultimo punto confermato. Queste sono raccomandazioni di progettazione dedotte dalla necessità di distinguere una mancata corrispondenza di input da un esito narrativo; i sistemi narrativi citati non definiscono un protocollo universale per gli errori di invio nelle chat.
Quando il recapito torna a funzionare, ripristina l'ultimo messaggio confermato o mostra un riepilogo conciso della scena e dell'azione più recente portata a termine con certezza. Etichetta un riepilogo come tale, non come un nuovo turno della storia. Se il giocatore sceglie di inviare nuovamente, chiarisci se verrà considerato un nuovo tentativo. Questa piccola trasparenza impedisce che un'azione duplicata venga scambiata per una ripetizione intenzionale.
Attribuisci significati diversi a riprova, annulla e riprendi
Queste parole descrivono diversi effetti sullo stato, quindi evita di usarle in modo intercambiabile. Un'azione di “riprova” (retry) invia nuovamente un comando allo stato corrente; non dovrebbe cancellare silenziosamente una conseguenza già acquisita. Un “annulla” (undo) ripristina uno stato precedente. Un “riprendi” (resume) prosegue dall'ultimo stato confermato dopo un'interruzione. Un “riavvia” (restart) ricomincia la storia da capo.
Il manuale di Harlowe per Twine documenta l'operazione di undo come il ritorno al passaggio precedente cancellando le modifiche alle variabili apportate nel passaggio corrente; descrive restart come il ricaricamento della pagina per ricominciare la storia dall'inizio. Sottolinea inoltre che la cronologia degli annullamenti può essere limitata. Queste meccaniche mostrano perché un comando dovrebbe comunicare la propria portata anziché affidarsi a una vaga etichetta “riprova”. (Harlowe 3.3.8 Manual: undo and restart)
Una sequenza decisionale compatta aiuta a mantenere coerente l'interfaccia:
Il gioco ha compreso e risolto l'azione? In caso affermativo, comunica l'esito narrativo e lo stato risultante.
Il sistema non è riuscito a mappare le parole su un'azione supportata? Spiega cosa non è stato possibile interpretare e mostra un percorso di correzione; mantieni inalterata la scena.
L'azione è stata compresa, ma il personaggio non ha le informazioni necessarie? Spiega il limite della conoscenza e gli eventuali modi interni al mondo narrativo per saperne di più.
L'elaborazione o il recapito sono incerti? Dichiara ciò che è confermato, quindi offri un modo sicuro per verificare o continuare.
Se il giocatore desidera tornare indietro, etichetta il comando come “Annulla” e indica quale momento o quali modifiche ripristina. Riserva “Riavvia” per ricominciare da capo.
Un breve controllo di coerenza per ogni messaggio di errore
Prima di implementare una risposta, verificala rispetto allo stato della storia. Se descrive un imprevisto, il mondo è effettivamente cambiato? Se descrive un input non supportato, il gioco ha evitato di fingere che l'azione abbia avuto luogo? Se il personaggio non ha informazioni, la risposta distingue questo caso da un comando inesistente? Se il recapito è fallito, il giocatore sa se il turno è stato elaborato? Infine, il comando di riprova o di ripresa fa ciò che la sua etichetta promette?
Un gioco testuale risulta leale quando il suo feedback aiuta il giocatore a distinguere ciò che il personaggio ha vissuto da ciò che l'interfaccia non è riuscita a fare. Conseguenze chiare preservano la storia; indicazioni di input specifiche rendono possibile un nuovo tentativo; limiti di conoscenza onesti mantengono coerente la finzione narrativa; e un percorso di ripristino ben definito offre al giocatore un modo affidabile per andare avanti.