Quando un gioco dovrebbe offrire delle scelte dopo aver frainteso ripetutamente l'input del giocatore?
Dopo che un gioco non è riuscito a interpretare l'azione testuale libera del giocatore per più di una volta, dovrebbe smettere di chiedere un'ulteriore riformulazione e offrire un piccolo insieme opzionale di azioni pertinenti. Mantieni visibile o comunque conservata l'azione tentata, spiega cosa comportano le scelte e fornisci una via chiara per tornare al testo libero. Questo è un passaggio di ripristino per fallimenti ripetuti, non equivale a porre una singola domanda di chiarimento quando una sola azione è ambigua.
Trattare gli errori ripetuti come un punto di ripristino
Un chiarimento isolato è utile quando il gioco ha compreso la maggior parte di un'azione ma non riesce a capire a quale elemento si riferisca il giocatore: “Intendi la chiave di ottone o la chiave d'argento?”. Un testo non riconosciuto ripetutamente è un problema diverso. Il sistema potrebbe non sapere cosa il giocatore stia cercando di fare, oppure il suo vocabolario potrebbe non includere le parole scelte dal giocatore. Ripetere “Prova in un altro modo” lascia il giocatore a tirare a indovinare le regole nascoste del parser.
La ricerca sulle interfacce di dialogo nei giochi descrive questa tensione: il linguaggio libero può consentire una gamma più ampia di risposte, ma può anche non riuscire a riconoscere ciò che i giocatori intendono; i menu con risposte fisse sono più facili da interpretare, ma limitano l'espressione disponibile. Tale evidenza supporta l'uso di un menu di scelta come percorso di riserva (fallback), non come sostituto predefinito per il testo libero. “Playing with words: from intuition to evaluation of game dialogue interfaces”
Un trigger pratico è rappresentato da due tentativi consecutivi non riconosciuti nella stessa scena o per la stessa azione. Si tratta di una raccomandazione di progettazione, non di una soglia universale stabilita dagli studi citati. Le proprietà importanti sono che il trigger sia prevedibile, legato al compito attuale e raggiunto prima che il gioco blocchi il giocatore in un lungo ciclo ripetitivo. Un gioco potrebbe necessitare di una soglia diversa se il suo metodo di input è particolarmente rumoroso o se la scena rende la sperimentazione parte integrante del gameplay; tale scelta dovrebbe essere presa deliberatamente e l'interazione risultante andrebbe testata.
Preservare ciò che il giocatore ha già provato
Quando compare la soluzione di fallback, conserva l'ultimo testo tentato nel campo di input, nel registro o in un altro punto visibile. Se il gioco lo cancella, il giocatore potrebbe dover ricostruire un'azione che aveva già formulato. Mostrare la frase aiuta anche a chiarire che il gioco ha ricevuto l'input, ma non è riuscito a mapparlo su un'azione supportata.
Un fallback può prendere atto del tentativo senza dare la colpa al giocatore: “Non sono riuscito a collegare 'solleva la grata con il gancio' a un'azione qui disponibile”. Se il gioco ha identificato una parte plausibile dell'azione, specifica cosa ha riconosciuto: “Ho individuato la grata, ma non so cosa tu voglia fare con essa”. Non millantare una comprensione superiore a quella effettiva del sistema. Questa formulazione distingue un comando sconosciuto da un bersaglio noto con un'azione non risolta.
La spiegazione del W3C relativa a Suggerimento di errore (Error Suggestion) afferma che quando un input viene rifiutato ed è nota una correzione utile, il sistema dovrebbe fornirla. Tra i suoi esempi figurano la visualizzazione di valori accettabili o correzioni probabili. Tale linea guida è scritta per i contenuti web, non per i dialoghi dei giochi, quindi la sua applicazione a un videogioco è un adattamento progettuale consapevole. Il principio condiviso è utile: fornire un passaggio successivo concreto quando il sistema è in grado di farlo. W3C, “Understanding Success Criterion 3.3.3: Error Suggestion”
Offrire un breve menu di azioni adatte a questo momento
Il menu di fallback dovrebbe contenere alcune azioni predefinite supportate dalla scena corrente. Ad esempio, se il giocatore sta interagendo con un cancello chiuso a chiave, le scelte potrebbero essere “Ispeziona la serratura”, “Prova la chiave” e “Allontanati”. Queste sono opzioni a scopo illustrativo, non affermazioni su un gioco in particolare. Le opzioni dovrebbero descrivere azioni distinte, usare verbi chiari ed evitare di indirizzare il giocatore verso diramazioni che il gioco non può attualmente gestire.
Mantieni le opzioni pertinenti alla scena e allo stato corrente. Un menu generico come “Esplora”, “Parla” e “Usa oggetto” potrebbe risultare meno utile se l'ostacolo immediato è un oggetto specifico. Al contrario, un'opzione altamente specifica dovrebbe apparire solo quando le sue condizioni sono soddisfatte. Se la chiave non è nell'inventario del giocatore, non offrire “Prova la chiave”. Un menu che propone azioni impossibili scambia un tipo di confusione con un altro.
La ricerca sui dialoghi di gioco dimostra inoltre che lo stile del menu influenza l'esperienza: le frasi complete possono aiutare a comunicare ciò che un personaggio dirà, mentre le etichette astratte possono far sembrare l'interazione più simile a un controllo strategico. Il giusto livello di dettaglio dipende dall'azione e dalle sue conseguenze. Usa un'etichetta breve per un'azione diretta; fornisci maggiori spiegazioni quando una scelta può modificare la scena o vincolare il giocatore a una risposta rilevante. “Playing with words: from intuition to evaluation of game dialogue interfaces”
Rendere il menu opzionale e mostrare come uscirne
Il menu dovrebbe fornire una via per proseguire, non disattivare silenziosamente il testo libero. Includi un'opzione visibile come “Continua a scrivere” o “Torna al testo libero” e comunica chiaramente che il giocatore può utilizzarla. Se il gioco accetta testo libero mentre le opzioni sono mostrate, rendi esplicito tale comportamento; se la selezione di un'opzione chiude il menu, comunica anche questo.
Usa etichette orientate all'azione per pulsanti e scelte. Il W3C Design System raccomanda un testo per i pulsanti che denomini l'azione dell'utente anziché un'etichetta generica come “Invia”. In un gioco, “Ispeziona la serratura” o “Continua a scrivere” è più informativo di “Continua”. La linea guida specifica per l'interfaccia deriva dai moduli web, ma la chiarezza insita nel denominare l'azione si trasferisce agevolmente ai comandi di gioco. W3C Design System, “Forms”
Mantieni coerente la via d'uscita. Se in un menu di ripristino appare “Continua a scrivere” e in un altro “Annulla”, i giocatori potrebbero non capire se entrambi mantengano lo stesso stato. Se l'uscita dal menu comporta lo scarto del testo, avvisa prima di eliminarlo. Se il giocatore può selezionare le opzioni tramite tastiera, controller, tocco o un altro metodo supportato, assicurati che le scelte di ripristino possano essere raggiunte e attivate mediante il normale schema di controllo del gioco.
Evitare cicli che richiedono continue riformulazioni
Dopo aver mostrato il menu, non tornare immediatamente al solito messaggio “Non ho capito; riprova” quando il giocatore inserisce un altro input non supportato. Ciò non fa che riavviare il modello di fallimento. Preserva invece il nuovo tentativo e mantieni disponibili le scelte offerte, oppure fornisci un indizio più specifico se il parser dispone di informazioni sufficienti per farlo. Consenti al giocatore di scegliere un'azione predefinita, modificare il testo o abbandonare l'interazione, se appropriato per la scena.
Le linee guida di Microsoft per i fallback conversazionali raccomandano di progettare una sequenza di risposte di emergenza, evitando ripetute scuse identiche e preservando il punto in cui l'utente si era interrotto nel momento in cui il sistema lo reindirizza. Poiché sono scritte per prodotti conversazionali, i consigli esatti sul passaggio di consegne (handoff) potrebbero non applicarsi a un videogioco. Il punto applicabile è rendere utile ogni passaggio di ripristino ed evitare di costringere una persona a ricominciare un lavoro già svolto. Microsoft Learn, “Design graceful fallbacks and handoffs”
Una semplice sequenza di ripristino può presentarsi così:
Primo input non supportato: segnala che l'azione non è stata riconosciuta; conserva il testo e fornisci un breve indizio pertinente alla scena, se disponibile.
Secondo input non supportato: mostra un piccolo menu di azioni predefinite valide, insieme al testo conservato.
Da quel menu: consenti al giocatore di selezionare un'azione, modificare e inviare nuovamente il testo, oppure uscire dall'interazione laddove il gioco lo consenta.
Se l'input successivo continua a non essere supportato: mantieni disponibili le opzioni di ripristino e chiarisci lo spazio di azione disponibile anziché riproporre la stessa richiesta di riformulazione.
Verificare se il fallback sia effettivamente d'aiuto
Testa la sequenza con input plausibili che differiscano dal fraseggio preferito dal designer: sinonimi, comandi brevi, nomi di oggetti e descrizioni più lunghe. Verifica che il gioco conservi l'input dopo ogni fallimento, mostri scelte valide per la scena attuale e consenta al giocatore di tornare a digitare senza perdere il punto in cui si trovava. Testa anche cosa accade quando una scelta diventa non valida a causa di un cambiamento dello stato della scena prima che venga selezionata.
Per ogni test, poniti una domanda concreta: dopo un errore, il giocatore è in grado di capire cosa il gioco non sia riuscito a comprendere? Riesce a visualizzare un'azione successiva utile? Può continuare a perseguire la sua idea originale senza essere costretto a selezionare un'opzione di menu? Se la risposta a una qualsiasi di queste domande è no, rivedi il messaggio, l'insieme delle opzioni o il percorso di ritorno. Questa è una checklist di valutazione proposta, derivata dai principi di interazione sopra descritti; non è il risultato documentato di uno studio condotto sugli utenti.
L'obiettivo è un ripristino circoscritto: prendere atto dell'input non supportato, conservarlo, offrire scelte pertinenti dopo errori ripetuti e rendere il testo libero un'esplicita via per procedere. Il menu dovrebbe ridurre i tentativi a vuoto, lasciando al giocatore il controllo sulla scelta di utilizzarlo o meno.