In questo articolo analizziamo la problematica del cosiddetto “cambio di dettaglio”, per comprendere come realizzare al meglio un traduttore da avventura testuale in librogioco. Questa problematica è stata, in origine, sollevata in questo messaggio ed è alla base di un dubbio sollevato da Bonaventura in un altro messaggio del forum, relativamente alla qualità dello libro finale.
L’obbiettivo che si pone questo articolo è quello di trovare una strada per aggirare questa problematica e, al contempo, rispondere al quesito, sempre di Bonaventura:
Il risultato sarà realmente più appetibile, a livello di giocabilità, rispetto all’AT originale? Oppure non si rischia, invece, che la traslazione non tolga gran parte della sfida intrinseca nel meccanisco dell’AT basato su parser?
Partiamo con il definire il problema.
In questo esempio, le scelte sono tre, e potrebbero essere determinate da un certo numero di azioni semplici, di cui però non troviamo traccia.
Nei librigioco le azioni consentite tendono a svilupparsi a un livello di dettaglio molto basso. In altri termini, l’opzione presentata trascura molti dei passi necessari per arrivare a svolgere quell’azione, e si presenta quindi come una sintesi delle attività stesse. Nei librigioco è raro incontrare un’azione semplice. Esattamente l’opposto di ciò che avviene nelle avventure testuali, dove il giocatore è costretto a digitare una serie di comandi per arrivare allo stesso risultato.
Pertanto, sembrerebbe impossibile convertire le une negli altri, perché anche supponendo di fare una conversione diretta, il librogioco ottenuto sarebbe decisamente spezzettato, fatto di tante scelte che portano a paragrafi molto brevi, il cui contenuto è paragonabile ai messaggi di feedback da parte del software che fa girare l’avventura testuale… e, in effetti, la cosa implementata così non va bene.
Un albero decisionale è una rappresentazione grafica delle possibilità di scelta che il giocatore ha in ogni istante di gioco.
Però esiste una soluzione che supera i limiti di una banale traduzione “letterale”, e che renderebbe al meglio la conversione.
Un traduttore efficace, infatti, nell’esaminare l’albero delle decisioni di una avventura testuale, potrebbe accertarsi che un insieme di azioni possibili e sequenziali (“esamina X”, “prendi X”, “apri X”, “prendi Y da X”, “vai a nord”) non modificano la scena in cui il giocatore sta giocando ma esclusivamente lo stato del gioco. Si tratta di una verifica piuttosto semplice, perché si tratta di individuare le risposte “standard” del software.
Dalla concatenazione di più azioni semplici si ottiene l’opzione complessiva, da proporre al giocatore nel librogioco.
Siccome è più facile disegnarlo che spiegarlo, presento qui di seguito un diagramma che dovrebbe illustrare il processo.
Questo è un esempio di albero decisionale. Quelli veri sono decisamente più articolati, con centinaia o migliaia di nodi e rami.
Qui troviamo l’albero delle decisioni di una avventura testuale. Cos’è? Si tratta di una struttura informatica derivata dall’analisi dei sorgenti dell’avventura.
Non mi soffermerò su come tale albero sia prodotto (sarà oggetto di un futuro articolo, spero!), quanto sul fatto che questo in questo albero i rami sono azioni, che modificano lo stato del gioco, mentre i nodi rappresentano appunto lo stato stesso.
Un traduttore non farebbe altro che percorrere questo albero e identificare l’insieme delle operazioni semplici, che modificano solo lo stato del gioco. Quando arriva a uno stato finale (vittoria / sconfitta), oppure a uno stato in cui il giocatore cambia locazione, allora si può fermare nell’analisi ed emettere l’azione complessiva: se decidi di prendere il chiodo, il martello e usare questi oggetti, vai al paragrafo xx.
Ovviamente, l’albero potrebbe contenere rami di lunghezza infinita (come gli anelli individuati nel diagramma sopra), oppure che portano al punto di partenza. In tali casi, non sarebbe possibile generale la scritta dell’opzione. Tuttavia, non si tratta di un problema che va affrontato a questo livello ma, appunto, dagli algoritmi che si occupano di generare e analizzare gli alberi.
L’avventura di Paolo Lucchesi è molto particolare, perché aiuta il giocatore mentre sta giocando (sono le scritte in corsivo.)
Adesso però basta con la teoria e arriviamo alla pratica, utilizzando l’avventura testuale Villa Morgana, scritta da Paolo Lucchesi.
Senza la necessità di scomodare la black box (anticipata nello scorso articolo), proviamo a tracciare manualmente un esempio di albero decisionale (parziale), valido per questa avventura. Per fortuna, si tratta di un’avventura con tutorial e quindi parecchie cose ci sono suggerite. Nel caso reale, invece, sarebbe la macchina a trovare i rami possibili.
Questo albero decisionale è solo un piccolo estratto di quelli potenziali.
Ho tracciato in verde due possibili alternative, a partire dalla descrizione iniziale:
- Vai a ovest, nel qual caso si passa alla descrizione della stanza CORRIDOIO.
- esamina il divano, che nel qual caso si passa alla descrizione del divano.
Il risultato del gioco di questo albero lo trovate su questo file PDF (realizzato con Trame Incrociate).
Questo è solo un esempio, e non pretende di essere esaustivo perché non sono state percorse tutte le strade possibili; inoltre, vi possono essere delle ottimizzazioni semantiche che potrebbero persino ridurre l’esplosione combinatoria dei rami e dei nodi. La cosa importante da sottolineare, invece, è che tale esempio dimostra come la qualità e la giocabilità di quell’avventura non sono granché scalfite dalla traduzione in librogioco. Ciò risponde alla prima parte del dubbio sollevato.
Ovviamente, non possiamo sapere se ciò sarà sempre vero, ma la verifica è una parte importante del processo: un processo sicuramente più divertente che incapponirsi con il parser, aspetto che ho sollevato già in questo articolo (e che, peraltro, risponde alla seconda parte del quesito).