Blog Metlivi

Come orientare i giocatori nei giochi di testo a input libero

Quando un gioco accetta comandi digitati, una riga di input vuota può suggerire che quasi tutto sia possibile. I giocatori hanno bisogno di spazio per sperimentare con le proprie parole, ma necessitano anche di indizi su ciò che il gioco comprende e su cosa sia cambiato dopo ogni tentativo. L'obiettivo pratico non è prevedere ogni frase, bensì rendere visibili opzioni significative, mostrare alcuni schemi di comando rappresentativi e rispondere agli input poco chiari con utili passaggi successivi.

30 settembre 20268 min readLettura, arte e culturaDi Metlivi Editorial Team
Sezione 1

Perché una casella di testo aperta può rendere poco chiara la mossa successiva

L'input libero offre un ampio senso di possibilità, ma il modello del mondo di gioco e il parser definiscono comunque quali azioni possono verificarsi. Un giocatore potrebbe non essere sicuro se un comando sia fallito perché il verbo non è riconosciuto, l'oggetto è assente, la formulazione è incompleta o l'azione descritta non ha semplicemente alcun effetto nel gioco. Emily Short fa notare che identificare una parola sconosciuta da sola potrebbe non indicare al giocatore cosa provare in alternativa; un obiettivo chiaro e una breve serie visibile di verbi utili aiutano a orientarlo («Parser Discussion, Redux»).

Questa distinzione è importante perché l'input digitato è una conversazione con le regole del gioco, anche quando il gioco lo presenta come linguaggio comune. La libertà del giocatore ha valore quando le sue azioni possono influenzare il mondo rappresentato. Cercare di accettare ogni frase immaginabile senza una risposta corrispondente da parte del mondo può invece creare aspettative che il gioco non può soddisfare. Le note di design di Short inquadrano il compito del parser come quello di guidare i giocatori verso formulazioni che manipolino in modo significativo il mondo di gioco, insegnando loro al contempo quali tipi di interazione il mondo supporti («Action and Interaction»).

Sezione 2

Fornire alcune opzioni visibili senza trasformarle in un limite

Mantieni aperto il campo di input, ma affianca ad esso una breve serie di suggerimenti contestuali. Rendili azioni concrete legate alla scena attuale: «guarda il biglietto», «chiedi a Mara del traghetto» o «prova il cancello». Questi esempi mostrano la struttura prevista per l'input e indirizzano verso le affordance locali. Dovrebbero essere presentati come punti di partenza, non come gli unici comandi consentiti.

Un prompt utile può anche indicare un obiettivo e alcuni verbi chiave: «Scopri perché il laboratorio è chiuso a chiave. Puoi ispezionare le cose, parlare con le persone o provare gli oggetti sulla porta». Questo dice al giocatore cosa potrebbe far progredire la scena senza imporre una soluzione specifica. Short descrive due approcci generali per rendere accessibili i giochi con parser: supportare un'ampia varietà di comandi con aiuti e suggerimenti, oppure mantenere ridotto l'insieme delle azioni disponibili e segnalarlo chiaramente. In entrambi i casi, i verbi presentati dovrebbero restituire una risposta significativa («Writing Novice-friendly Parser Games»).

L'equilibrio è locale e regolabile. Quando ci sono molte azioni plausibili, un prompt contestuale del tipo «Cosa posso provare qui?» può offrire un breve menu. Quando un obiettivo è chiaro, un paio di esempi possono bastare. Se un'azione è destinata a rimanere nascosta, non rivelarne la soluzione nell'elenco dei suggerimenti; indica invece i tipi di interazione disponibili in quel momento. L'obiettivo è mostrare il vocabolario e le affordance del gioco senza esplicitarne ogni conseguenza.

Sezione 3

Insegnare gli schemi di comando tramite esempi

Gli esempi sono più utili quando illustrano schemi riutilizzabili anziché elencare ogni singola frase accettata. Ad esempio, un gioco potrebbe mostrare «esamina [oggetto]», «parla con [persona] di [argomento]» e «usa [oggetto] su [oggetto]». Può poi esemplificarne uno o due: «esamina la chiave d'ottone» o «chiedi a Mara del traghetto». Una formulazione coerente insegna ai giocatori come combinare azioni e bersagli. Includi una struttura solo quando il gioco la supporta effettivamente.

Nomina i sostantivi importanti sia nella narrazione che nei prompt. Se la scena descrive una chiave d'ottone, il giocatore dovrebbe avere motivo di provare «esamina la chiave» o «prendi la chiave»; richiedere implicitamente un nome diverso e nascosto genera solo confusione. Dove le azioni utili variano in base all'oggetto, un breve indizio di interazione può aiutare: «Il chiavistello è abbastanza allentato da poter essere sollevato» o «Il biglietto ha scritte su entrambi i lati». Short consiglia di evidenziare i sostantivi utilizzabili e fornire suggerimenti come metodi per aiutare i giocatori a scoprire con cosa è possibile interagire («Writing Novice-friendly Parser Games»).

Evita di inondare ogni scena con un catalogo completo di comandi. Troppi suggerimenti entrano in competizione con la storia, ed elencare un verbo distintivo può trasformarlo in un indizio involontario per un enigma. È preferibile un insieme ridotto e specifico per la scena, accompagnato da un comando di aiuto o da una guida espandibile per un supporto più ampio. La guida di IFComp alla narrativa interattiva basata su parser fa notare che alcuni giochi utilizzano guide tutorial opzionali, consentendo ai giocatori di consultare il supporto mentre proseguono nella storia («About IF»).

Sezione 4

Rendere l'input ambiguo un breve chiarimento, non un vicolo cieco

Quando il gioco comprende l'azione ma non riesce a capire a quale bersaglio si riferisca il giocatore, fai una domanda mirata. Se il giocatore digita «apri il libro» e sono visibili due libri, rispondi: «Quale libro: il libro rosso sulla scrivania o il libro blu sullo scaffale?». Un chiarimento utile nomina le alternative con termini che il giocatore può distinguere. Se manca un dettaglio obbligatorio e non esiste un valore predefinito ragionevole, chiedi quel dettaglio: «Cosa vuoi aprire?».

La documentazione tecnica sui parser offre un esempio concreto di questa interazione: TADS descrive la richiesta al giocatore di scegliere tra i libri in base ai loro colori visibili, e richiede separatamente un oggetto quando un comando come «apri» è privo del suo bersaglio (TADS Parser: The Parsing Sequence). L'insegnamento di design più ampio è quello di preservare l'intento originale ove possibile. Chiarisci solo l'elemento mancante invece di scartare il comando e costringere il giocatore a ricominciare da capo.

Se il gioco può scegliere in sicurezza un'opzione predefinita, comunica al giocatore la scelta effettuata: «Usi la chiave d'ottone sul cancello del giardino». Se due scelte possono produrre esiti diversi, chiedi conferma. Emily Short raccomanda di intervenire con un prompt quando un comando è incompleto e non è possibile dedurre un'opzione predefinita ragionevole, rendendo chiara la differenza tra oggetti ambigui («Action and Interaction»).

Sezione 5

Rispondere a domande impreviste con rispetto e orientamento

I giocatori proveranno comandi giocosi, curiosi o non pertinenti. Tratta questa sperimentazione come una normale forma di partecipazione. Evita risposte che rimproverino, deridano o presuppongano che il giocatore debba già conoscere le regole. Fai invece in modo che la risposta riconosca l'intento interpretato, quando possibile, per poi riportare l'attenzione sulla scena.

Ad esempio, se il giocatore chiede all'orologio del laboratorio se sa che ore sono, una risposta potrebbe essere: «L'orologio continua a ticchettare, ma non dà risposta. Il biglietto accanto è coperto di numeri». Ciò fornisce una piccola reazione coerente con il mondo di gioco, attirando al contempo l'attenzione su un indizio visibile. Se il gioco non riesce a interpretare l'input, dichiaralo chiaramente e offri un'azione supportata contestuale: «Non capisco questa azione qui. Potresti esaminare il biglietto o chiedere a Mara del laboratorio». Evita di fingere che il gioco abbia compreso una frase che non ha modellato; un falso riconoscimento rende difficile interpretare gli esiti successivi.

Separa i problemi di input dai risultati nel mondo di gioco. «Non riconosco questo comando» segnala un problema di formulazione o di vocabolario. «Il cancello è chiuso a chiave» segnala che l'azione è stata compresa ma lo stato del mondo la impedisce. «Il cancello non si muove» segnala un tentativo di azione senza alcun effetto. Quando questi messaggi hanno significati distinti, il giocatore può decidere se riformulare, raccogliere informazioni o provare qualcos'altro. L'analisi di Short sul feedback del parser evidenzia come un rifiuto generico possa lasciare i giocatori incerti sul fatto che un verbo non sia supportato o che l'azione stessa sia esterna al mondo di gioco («Parser Discussion, Redux»).

Sezione 6

Mostrare che un'azione è stata registrata e cosa è cambiato

Dopo un comando compreso, riporta il risultato in termini che aiutino il giocatore ad agire nuovamente. Se il giocatore apre l'armadietto, indica cosa è ora visibile. Se fare una domanda modifica la risposta di un personaggio, mostra un indizio concreto o indica al giocatore quale nuova informazione ha appreso. Se l'azione non ha un effetto immediato, spiega la ragione rilevante quando il personaggio può ragionevolmente conoscerla.

Questa è l'altra metà dell'orientamento: i giocatori hanno bisogno della prova che la loro azione ha avuto effetto nel gioco, non solo di un prompt per l'azione successiva. Short sostiene che l'output debba rivelare le informazioni necessarie per interagire con il mondo e che i cambiamenti riusciti debbano essere evidenti, compresi quelli indiretti quando è utile mostrare un segnale («Action and Interaction»). Mantieni il feedback proporzionato: descrivi una serratura modificata, un dettaglio appena notato o la reazione visibile di un personaggio, anziché aggiungere una spiegazione non pertinente dopo ogni comando.

Sezione 7

Una sequenza pratica per progettare ogni risposta

Per ogni scena, elenca le azioni importanti, quindi modella prompt e risposte attorno ad esse. Questo trasforma l'ampia domanda «Cosa possono digitare i giocatori?» in un compito di progettazione gestibile: «Può un giocatore vedere cosa supporta la scena, provare un'idea inaspettata, comprendere la risposta e scegliere il passaggio successivo?».

Identifica gli oggetti interagibili della scena, i personaggi e l'obiettivo immediato. Usa solo dettagli effettivamente modellati o che possono essere narrati in modo significativo.

Scegli alcune azioni rappresentative e formulale come esempi. Mantieni disponibile l'input aperto e assicurati che i verbi suggeriti funzionino come promesso.

Classifica i probabili input poco chiari: azione sconosciuta, bersaglio sconosciuto, dettaglio mancante, bersagli multipli possibili o azione compresa che non può avere successo nello stato attuale.

Scrivi una risposta distinta per ciascun caso. Un chiarimento dovrebbe offrire scelte riconoscibili; un'azione impossibile dovrebbe spiegare l'ostacolo rilevante; un'azione non supportata dovrebbe suggerire una strada alternativa vicina.

Verifica che il risultato di un'azione riuscita sia visibile e che le informazioni rivelate in precedenza possano essere riesaminate quando il giocatore ne ha di nuovo bisogno. Short consiglia metodi per recuperare le informazioni già apprese, cosa particolarmente utile quando i dettagli della trama o le conversazioni influenzano scelte successive («Action and Interaction»).

Testa la scena con comandi letterali, incompleti, formulati diversamente e giocosi. Rivedi qualsiasi risposta che impedisca al tester di capire se il gioco ha frainteso, rifiutato o accettato l'azione.

Il parametro utile non è il numero di frasi accettate dal gioco, bensì la capacità dei giocatori di comprendere la relazione tra le loro parole, le azioni supportate dal gioco e lo stato visibile in seguito. Alcune opzioni visibili, esempi che insegnano schemi e un feedback chiaro e non giudicante preservano lo spazio di sperimentazione, offrendo al contempo ai giocatori informazioni sufficienti per continuare a muoversi.

Letture correlate

Continua a esplorare il tema