Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Sono tornato!

Ehilà...adesso sono sicuro che per un po' i miei messaggi non passeranno
inosservati :)))) (è un metodo Zensunni...)
Quindi è meglio che mi metta al lavoro ASAP!
Ho dato una letta al parser Inform, ma solo una letta...per analizzarlo ci
vorrebbero giorni. Mi pare che la sintassi sia molto simile a quella del C
(come ho già sentito dire da altri).
Secondo me, programmare un'at in questo modo è un po' controproducente. Il
parser usa un metodo esaustivo, cioè considera tutte le possibilità in modo
esplicito. Questo fa sì che:
1) è molto difficile apportare modifiche (al parser)
2) le modifiche apportate hanno un impatto trascurabile sulla performance
(sempre del parser)
Come conseguenza nessuno penso sarà disposto a seguirmi in una riscrittura
del parser, vero? (dopo anni di duro lavoro otterremmo un miglioramento
impercettibile).
Il mio suggerimento è di cambiare radicalmente strada! In realtà affrontare
un NL (linguaggio naturale) usando un parser esaustivo è molto più difficile
che utilizzare un shallow / semantic parser*, inoltre la struttura del
parser risulterà molto più modulare e quindi facilmente modificabile.
I vantaggi principali sono:
1) interpretazione corretta di proposizioni leggermente scorrette
2) capacità di auto apprendimento (sottoponendo al programma grossi testi
tipo enciclopedie, opere letterarie, siti internet, ecc...)
3) scrivere un'at sarà molto più facile e distoglierà meno l'attenzione
dell'artista/programmatore dalla parte effettivamente artistica dell'at
* Shallow Parser è contrapposto a Full Parser: il primo impiega un analisi
parziale (o se volete, superficiale) ed è perciò in grado di gestire anche
frasi non completamente corrette, il secondo è più preciso (ma estremamente
lento...si parla di algoritmi O(n) con n > 5) e non ammette imprecisioni di
espressione.
Gli avventurieri particolarmente coraggiosi possono leggersi qualche tesi o
almeno il riassunto iniziale (abstract) giusto per farsi un'idea.
http://lcg-www.uia.ac.be/conll2001/proceedings.html
Dopo aver passato 2 notti a leggermi le varie tesi (20 in tutto) ed essermi
fatto una buona idea su come funziona un NLP (NL parser), ho capito che in
un'at è sufficiente usare un parser molto più semplice di quelli presentati.
Per capire perchè, illustrerò brevemente ai lettori superstiti la struttura
di un parser.
- TAGGER
- CHUNKER
- CLAUSES SPLITTER
- LOGIC ANALIZER
- SEMANTIC ANALIZER
TAGGER
Come s'intuisce dal nome, aggiunge TAG ad ogni parola. I più comuni sono:
Nome, Articolo Det, Articolo Indet., Verbo, Aggett., ecc... insomma come in
analisi grammaticale
CHUNKER
Esamina l'output del TAGGER e raggruppa una o più parole in gruppi di tipo
Nome, Verbo, ecc...
Per esempio la frase: "Egli vide una donna di mezza età che si aggirava per
il viale"
verrebbe così suddivisa:
[P Egli P] [V vide V] [N una donna di mezza età N] [? che ?] [V si aggirava
V] [N per il viale N]
([? ?] indica un blocco di tipo per ora ambiguo)
CLAUSES SPLITTER
Cerca di separare e di ricostruire il rapporto logico tra le proposizioni
(clauses) principali, coordinate e subordinate.
LOGIC ANALIZER
Cerca di identificare il soggetto, il verbo e i complementi di ogni
proposizione (clause)
SEMANTIC ANALIZER
Cerca di identificare il significato di una frase sfruttando l'output del
LOGIC ANALIZER (non è necessario scendere nei dettagli...)
Come avrete visto il compito è eseguito in passi ed ha quindi una struttura
piuttosto modulare.
Il problema principale è rappresentato dal fatto che ogni passo dà origine
ad "ambiguità" che dovranno essere risolte in seguito. Per esempio il Tagger
può interpretare "ancora", "da", "che" o simili, in più di un modo. Quindi,
alla fin fine, il parser è un algoritmo stocastico (che fa uso di modelli
statistici o probabilistici).
I dati vengono acquisiti automaticamente da grossi testi tipo enciclopedie,
opere letterarie, ecc...e vengono usati per risolvere statisticamente le
ambiguità. I migliori risultati vengono (purtroppo) ottenuti usando testi
pre-etichettati (pre-tagged).....manualmente!
Pazzia? No ;-)
Siamo fortunati!
Nelle avventure testuali tutto è più semplice e dovrebbero bastare i primi 2
passi (TAGGING e CHUNKING) e inoltre non dovrebbero esserci più proposizioni
(il giocatore non è incline a scrivere lunghe frasi se può ottenere lo
stesso risultato con qualcosa di più breve).
Tutto questo, a mio avviso, potrebbe essere affrontato in modo ancora più
divertente(!). Perchè non cerchiamo prima di capire il significato della
frase e non eseguiamo poi una minima analisi grammaticale/logica solo per
risolvere le ambiguità eventualmente incontrate? Nessuna ambiguità? Nessuna
analisi aggiuntiva (un po' raro, comunque).
Per "capire il significato" intendo semplicemente "individuare la giusta
_alternativa_".
Le _alternative_ (se mi passate il termine) sono l'insieme dei casi o
sottocasi gestiti dall'autore.
Io aggiungerei (dove, dovrà essere deciso con cura) il passo DE-SYNONYMIZER
che avrà la funzione di normalizzare la frase (frase originale ---> frase
canonica). In questo modo le ambiguità saranno più facili da trattare e
l'autore di at avrà un minor numero di casi da gestire.
Un'ulteriore passo sarà (ma solo in futuro) quello di creare librerie
(auspicabilmente pubbliche, nel senso di disponibili a tutti gli autori)
contenenti casi pre-gestiti. Mi spiego meglio: quante volte ci si trova a
dover gestire porte nella propria vita di autore IF? Molte volte.
Realizzando una classe base (tipo quelle del C++) con diversi aspetti della
porta già gestiti e configurabili mediante parametri (vari tipi di porta:
blindata, temporale, ecc...) sarà possibile ricreare un ambiente complesso e
realistico in pochissimo tempo e senza aumentare i casi da gestire
manualmente. Ovviamente ognuno potrà tenersi strette le proprie classi
personali, però inizialmente sarebbe più facile e utile lavorare su una
libreria comune (libreria = insieme di classi). Le classi diventerebbero
qualcosa come le texture utilizzate nei giochi 3d. Come oggi esistono siti
che offrono texture, forse prima o poi potrebbero esistere siti che offrono
classi per avventure testuali. Chissà...... Oooo-- :-)
Mi scuso per la lunghezza del messaggio. Se siete arrivati fino in fondo
significa che eravati davvero inca**ati!!!
Accetto consigli e critiche di ogni genere (tecniche e non).
Gradirei che il mio (nostro, se volete) progetto fosse open-source, quindi
se qualcuno volesse cortesemente ospitare sul proprio sito un po' di codice
(commentato) e riflessioni varie, mi farebbe un gran favore. Magari un
piccolo angolino su IF-Italia potrebbe andare :-)
Naturalmente non avrò troppo tempo da dedicargli, ma piano piano...

 manualmente.
Beh, in Inform le porte sono gestite piuttosto bene. I "diversi aspetti"
della porta in Inform si chiamano "attributi" (locked openable open) e c'e'
ben poco da gestire manualmente (nulla in teoria). Ma forse, anche in questo
caso, non ho capito bene quello che proponi.
ciao,
f.
--
------------------------------------
Francesco Cordella
fraco...@libero.it
--- In quasi tutte le case ti danno antipasto, tre
primi, quattro secondi, otto contorni, dodici dolci e, al momento del
caffè, la padrona dice timida: "Qualcuno vuole un caffè?". E si sente
rispondere: "Sì, se lo prende anche qualcun altro" --- Alberto Arbasino

 caso, non ho capito bene quello che proponi.
Hai capito benissimo! Mi sembra di aver intravisto la gestione delle porte
nel codice del parser, comunque il mio era solo un esempio. Quello che ho
detto non è limitato alle sole porte. Le librerie di cui parlo possono
contenere mobili, cellulari, automobili, ecc...(senza alcun limite di
complessità).
Se per esempio parte dell'avventura si svolgerà in un'officina, basterà
utilizzare la libreria degli autoveicoli, importare le macchine che si
vogliono, applicare magari qualche modifica (modificare gli attributi, o, se
si vuole, modificare la libreria stessa) e posizionarle spazialmente
(all'interno dell'officina).
Non penso che Inform sia in grado di gestire automaticamente *qualsiasi*
cosa. E comunque le cose buone di Inform non sono mica da buttare :)
Segue anche un piccolo chiarimento...

Sto rispondendo a me stesso :-)
Non immaginatevi chissà che cosa leggendo "autoapprendimento" e "shallow
semantic parser". Come ho già detto, analizzare un "ordine" è molto più
semplice che analizzare una frase qualsiasi, quindi è inutile servirsi di
astrusi full parser o strani algoritmi.
Il parser cercherà di ricondurre l'ordine (la frase) del giocatore a uno dei
casi gestiti dell'autore. In caso di ambiguità (per esempio la frase
"punteggio" non crea ambiguità!) si passerà ad un'analisi
logico-grammaticale (basteranno semplici regole).
Il parser utilizzerà un metodo di "scoring". L'"ipotesi" che totalizzerà il
punteggio più alto sarà selezionata come altamente probabile e, nel caso i
punteggi siano tutti troppo bassi, si comunicherà all'utente di leggersi un
libro di grammatica.
Lo scoring rappresenta un metodo molto semplice ed elastico per gestire cose
molto complesse. Negli scacchi si usa questo metodo. Ad ogni possibile mossa
viene assegnato un punteggio (seguendo regole più o meno complesse) e poi
viene scelta quella col punteggio più alto (in realtà il meccanismo è più
complesso, ma a noi basta questo).


E' esattamente il modo in cui funziona la disambiguation di Inform.
Per quanto riguarda poi i modelli che proponi (officina, automobili, case)
ti dico come faccio io con Inform. Se devo creare l'oggetto automobile, ad
esempio, cerco tra i vari sorgente o tutorial un'automobile programmata da
un altro (o da me stesso in un test/gioco precedente) e parto da quella.
Cio' non vale per oggetti astrusi (vedi Arbaxas in Flamel), ma gli oggetti
astrusi sono astrusi perche' non hanno un modello.


 Naturalmente non avrò troppo tempo da dedicargli, ma piano piano...
Come ho già detto: mi piacerebbe darmi una mossa ma gli impegni non me lo
consentono
Giovanni
NB: Nel tuo messaggio (e io ti ho seguito con la mia risposta) hai confuso
Inform che è un linguaggio di programmazione con il suo bel compilatore con
il parser che è semplicemente un programma scritto con Inform.


Allora perchè se chiedo al barista "ehi barista, dammi una birra" il parser
mi dice qualcosa del tipo "non conosco ehi" oppure "ho capito la frase
soltanto fino...".
Non mi sembra che lo scoring sia stato usato così tanto bene.
Con lo scoring è possibile essere capiti anche se si dice: "ca**o dammi sta
benedetta birrra!" (birra con 3 'r'). Il punteggio dice "quanto somiglia"
una frase a un'altra e il parser si serve di elementi aggiuntivi
(preposizioni, articoli, punteggiatura, ordine, ecc...) solo se necessario.
Errori di battitura non pregiudicano il risultato.
I modelli poi non riguardano direttamente il parser quindi possiamo usare
qualsiasi metodo ci venga in mente. Per ora mi preme migliorare il parser.

 il parser che è semplicemente un programma scritto con Inform.
OK, adesso è tutto più chiaro, comunque mi pare di capire che in realtà
trattasi di "interprete" e non di "compilatore"...

 trattasi di "interprete" e non di "compilatore"...
No, forse il codice viene compilato in una specie di assembly generico e poi
interpretato da un programma tipo (Win)Frotz ?

 interpretato da un programma tipo (Win)Frotz ?
MAcchina virtule, l'antesignana delle macchine virtuali (la prima inventata)
e cioè la z-machine.
Giovanni

 Naturalmente non avrò troppo tempo da dedicargli, ma piano piano...
aggiungo i miei due centesimi da non programmatore. 
Io non credo che il problema sia il tagger o il chunker, credo sia
relativamente semplice farne uno (semplice); leggo che inform ne ha uno.
Il problema -ripeto- è quello nelle attribuzioni di relazioni tra gli
oggetti ed i verbi che possono relazionarsi con gli oggetti stessi
(forse era questo che riccardi intendeva con la 'risposta' del
computer). Non parlo del giocatore di AT disposto a capire che il parser
AT non è un IA, ma del mancato giocatore di AT che si scontra con la
mancaza di relazioni verbo-oggetto e non gioca più. Una delle cose utili
nel gestire un mud è che rimangono i log di tutti i giocatori,
occasionali e non, quindi si può vedere cosa è che fa fuggire un
giocatore da una AT: e nel 90 per cento di casi è il parser. Non si è
capiti. Si vuole fare qualcosa ma il computer non capisce cosa voglio
fare: ma è la mentalità del giocatore/programmatore di AT che dovrebbe
cambiare e non l'opposto, se davvero si volesse allargare il bacino di
utenza. 
Un giocatore esamina una scrivania, va a nord, poi va a est, poi a sud e
capisce, esaminando un quadro cosa doveva fare con la scrivania, allora
digita il suo nord, ovest, e sud e fa quello che deve fare. Ma un
non-giocatore, scrive più semplicemente RITORNA DALLA SCRIVANIA, o, se
deve cercare una spada, scrive, VAI A CERCARE UNA SPADA, insomma, usa
una sintassi che fa rabbrividire un buon giocatore di AT, ma che in
qualche modo dovrebbe essere interpretata dal un parser evoluto. Ma non
potrebbe necessariamente essere programmata passo passo: dico delle
belinate, ma un parser capirebbe che spada è un oggetto, che cercare è
una voce verbale del verbo cerca, e che vai è un verbo di movimento
riferito non ad un luogo ma ad una azione (il cercare) che è quindi una
azione complessa che sottende un insieme di azioni semplici. Ma di
nuovo, prendi birra, compra birra, locandiere dammi una birra, sono
tutte azioni che necessitano di un parser che conosca le relazioni tra
oggetto e verbo.
Anni addietro mi ero messo a fare uno schema per una intelligenza
artificiale per mud, chiamata avintellenza (non ridete). La cosa che
avevo pensato è che ogni oggetto si porta dietro categorie di verbi (e
non tutti i verbi). Se trovo l'oggetto spada, i verbi che possono essere
riferiti all'oggetto spada saranno un determinato tipo, e di determinate
'classi'. I verbi di alimentazione difficilmente saranno legati alla
parola spada, ad esempio, mentre altre categorie di verbi sì. Partivo
dall'oggetto e dalle sue relazioni con il verbo (o l'opposto ovviamente:
determinati classi di verbi si portano dietro solo determinate classi di
oggetti), visto che l'at è basata principalmente su azioni, e le azioni
sono determinate da verbi in unione con verbi.       
Dirò cose superate, ma per fare una IA in una At dobbiamo pensare che
stiamo lavorando ad un microcosmo e che questo è un vantaggio non da
poco: non serve passare l'enciclopedia britannica allo scanner, perché
il parser deve essere sapiente solo delle cose che il gioco sa. Il
vocabolario del parser deve essere il vocabolario del gioco.
Basta.
Un saluto.
f.
-- 
materiali - 
http://www.fabrizio.venerandi.org
neoN - telnet://
neon.ods.org:8010
Il trionfo dell'impiegato - 
http://www.venerandi.org/impi.htm
Pantagrognomicon - 
http://www.venerandi.org/pantagrognomicon.htm

 vocabolario del parser deve essere il vocabolario del gioco.
Pensavo che fare esaminare un testo del genere al parser potesse essergli
utile per apprendere regole grammaticali, modi di esprimersi e relazioni tra
i vocaboli.
Quando il PRG legge una riga del tipo:
L'automobile è un veicolo composto da......
automaticamente fa un associazione tra automobile, veicolo, le parti che lo
compongono ecc... La struttura potrebbe essere qualcosa di abbastanza
semplice: ogni termine è collegato a uno o più termini...si ha insomma una
rete di collegamenti.
(Non è possibile creare tutti i collegamenti manualmente senza diventare
pazzi. A meno che l'AT non sia *molto* strana, i rapporti tra i vocaboli
resteranno quelli...l'automobile sarà sempre un veicolo e potrà essere
guidata, la spada avrà sempre una lama (metallica o laser, al limite),
ecc...)
Per quanto riguarda il microcosmo, hai perfettamente ragione: è un
vantaggio.

Non mi sembra che lo scoring sia stato usato così tanto bene.
Secondo me, non è un problema così grave quello che tu stai esponendo.
E' vero che il parser può (e probabilmente deve) essere migliorato, ma
non per questo le AT perdono il loro fascino. 
E comunque, IMHO, la cosa davvero importante in questo genere di
giochi è la storia in sé...
Ciao da
Vincenzo

In tutta sincerità, non pensi che questa sia un scusa bella e buona per
lasciare le cose come sono?
Agli autori il parser migliorato non creerà nessuna difficoltà extra, però i
giocatori saranno più a loro agio.
Ti riporto una parte del messaggio di Fabrizio Venerandi:
"Non parlo del giocatore di AT disposto a capire che il parser
AT non è un IA, ma del mancato giocatore di AT che si scontra con la
mancaza di relazioni verbo-oggetto e non gioca più. Una delle cose utili
nel gestire un mud è che rimangono i log di tutti i giocatori,
occasionali e non, quindi si può vedere cosa è che fa fuggire un
giocatore da una AT: e nel 90 per cento di casi è il parser. Non si è
capiti. Si vuole fare qualcosa ma il computer non capisce cosa voglio


 un altro gioco)
Forse, in questo caso, il problema non e' solo del parser, ma anche
del programmatore.
f.

 f.
Probabilmente, però m'interessano anche i "solo".

 cosa. 
automaticamente no di sicuro. Ma quello che proponi in pratica sono librerie di "prefabs"
come si usano negli editor 3D? Se è così, credo sia tempo perso; il 90% del tempo andrebbe
comunque perso nella customizzazione, e servirebbero quindi a ben poco...
ciao
S

 Secondo me, programmare un'at in questo modo è un po' controproducente. 
<snip>
un consiglio fraterno: dedica almeno un paio di mesi all'analisi dello stato dell'arte.
Inform, HUGO, TADS e quant'altro. Assicurati di capire bene quali sono le cose importanti
(il modello del mondo soprattutto, e cose come le funzioni di scoping, non delle variabili
nel codice, ma degli oggetti NEL mondo).
Fatto questo, avrà un senso fare questi discorsi... io ti dico fin d'ora che mi pare
assolutamente tempo perso e non mi interessa affatto sviluppare un altro sistema di IF
authoring. ovviamente parlo per me.
ciao
S

 benedetta birrra!" (birra con 3 'r'). Il punteggio dice "quanto somiglia"
è già stato provato, e implementato molti anni fa in via sperimentale. Di solito si
considera un'alternativa improponibile perché (per dire una magagna tra tante) in caso di
errata battitura il parser suggerirebbe istruzioni e riferimenti a oggetti che non sono
neanche venuti in mente al giocatore. in pratica, invece di "indovina il verbo" il gioco
diventerebbe "indovina il cambio di vocale".
non mi sembra così grave richiedere che il giocatore non faccia errori di battitura e si
conformi a una sintassi standard...

 lasciare le cose come sono?
guarda che i parser migliorano costantemente, e da sempre. Il fatto è che vengono anche
usati al 10%, da sempre. Semplicemente, quel che c'è di solito basta, le estensioni hanno
senso solamente se funzionali a un particolare "effetto" scenico.
E poi continuate a parlare di "parser", quando quello che conta è il modello del mondo.
ciao
S