Newsgroup: it.comp.giochi.avventure.testuali
Titolo: come si fa a implementare il comando 'L' con le librerie italiane di inform?

Ci ho provato in tutti i modi ma non ci riesco... (a dire il vero ho
fatto delle prove per un'oretta ma poi mi sono rotto ;)
Devo dire cmq che se è così difficile cambiare una cosa tanto
semplice...mah :)
Un'altra cosa... se per imparare un linguaggio come inform mi ci vuole
1 mese... forse faccio sul serio prima a farmela in VB 'sta benedetta
avventura... farà schifo finchè volete come linguaggio, però almeno è
semplicissimo e dà risultati immediati (l'unica sfiga non da poco è la
portabilità).
--- mi preparo ad essere cosparso di insulti più o meno vari ---
...del resto "implementare il parser" mi sembra più un'esercizio di
programmazione che una reale necessità. In quante avventure avete mai
scritto "inserisci la chiave rossa nella toppa della porta d'avorio e
aprila"?
Insomma a che serve un parser complesso se poi la maggior parte delle
avventure va avanti tipo:
apri porta
prendi chiave
usa cacciavite sull'ascensore
e così via...? :)
Io credo che sia inutile stare a "generalizzare" un linguaggio per
farci chissà cosa, se poi viene usato in 2-3 avventure al max. Conta
molto di più un buon testing, in cui ci si pone tutte le domande del
caso e si prevedono le risposte giuste al giocatore per ogni sua
scelta,in modo da non causare frustrazione...
Questa è la mia personalissima opinione...
Ok dov'è che ho messo il VB che ho già perso abbastanza tempo...? :)

 Io credo che sia inutile stare a "generalizzare" un linguaggio 
 > per farci chissà cosa, se poi viene usato in 2-3 avventure al max.
 > Conta molto di più un buon testing
In linea di principio sono d'accordo, anche se temo che tu stia portando 
questo ragionamento un po' troppo in la'.
Se vuoi il mio parere, parti col VB che conosci bene e scrivi la tua 
avventura: male che vada, farai esperienza; a portarla sotto altri 
ambienti non ci vuole poi tanto.
   .Erix.

 scelta,in modo da non causare frustrazione...
Ma una buona AT non è un'avventura in cui semplicemente il programmatore
prevede ogni comando del giocatore e agisce di conseguenza; sarebbe molto
limitante, limitativo e piuttosto stupido (e il bluff sarebbe molto sempice
da scoprire!)
Una AT è scritta bene quando dietro di essa c'è il modello di un mondo
simulato che risponde a regole precise.
Ora, non voglio erigermi a difensore di Inform, però bisogna riconoscere che
esso mette a disposizione del programmatore un "modello" molto coerente ed
estremamente flessibile; il linguaggio in se' potra' anche essere un po'
farraginoso, ma bisogna tenere presente che dietro di esso c'e' un mondo
che, per quanto possibile, va avanti per conto suo.
Paolo M.

ambienti non ci vuole poi tanto.
Sì infatti penso che farò così :)
Jack Norton
-----------------
ex "Rei di Nanto"

che, per quanto possibile, va avanti per conto suo.
Sě ok ma in quante persone lo usano per le loro avventure? e non
ditemi che una semplice gestione di eventi a tempo equivale a simulare
il mondo... ;-))
Non ho visto molte avventure in cui si parla con NPC che si girano, si
muovono ecc. (parlo ovviamente della scena italiana).
Per far certe cose ci vuole molto piů tempo di quanto ne abbiano a
disposizione la maggior parte degli aspiranti autori... credo
(correggetemi se sbaglio).


 che, per quanto possibile, va avanti per conto suo.
C'e' chi preferisce usare mondi 'standard' e chi ama crearseli da se'. 
E' chiaro che se giudichi dal punto di vista della pura simulazione del 
mondo reale, l'uso di strutture prefabbricate e' di grande aiuto (lo so 
che Inform e' completamente riconfigurabile ma, se lo fai, ricadi nel 
secondo caso).
Dal punto di vista del rapporto fatica/risultato, personalmente 
preferisco usare sistemi ibridi come Idra, piuttosto che ricadere in uno 
dei due estremi che sopra ho volutamente esasperato. Ma ognuno ha le sue 
preferenze, e non saro' io a criticarle.
   .Erix.

[...] ognuno ha le sue preferenze, e non saro' io a criticarle.
Oh, su questo sono completamente d'accordo con te. :-))
Certo, quello che dici e' vero, cosi' come e' vero che quando si vuole
sviluppare una AT le strade da seguire possono essere molteplici e
ugualmente valide.
Sai qual'e' la questione che mi riguarda in termini assolutamente personali?
Troppo spesso, in passato, mi sono sentito ingannato dalle avventure
testuali; sentivo che mi stavano prendendo in giro, a livello quasi
istintivo.
Poi guardavo i listati in basic, che spesso erano disponibili, e vedevo che
non c'era un vero e proprio modello del mondo, ma una lunghissima sequenza
di controlli condizionali su ciň che scrivevo.
Ora, forse e' un mio problema di impostazione "filosofica", ma quando mi
rendo conto che sono di fronte ad una situazione del genere il mio livello
di interesse cala di colpo, perche' so che quando digito sto parlando con
uno stupido che sente solo quello che vuole sentire.
Credo che tu capisca cosa intendo dire.
Paolo M.

 programmatore prevede bene quasi tutto? non penso sia cosě semplice.
La mia risposta a Enrico vale anche per il tuo intervento, comunque avrai
capito che non parlo tanto di parser quanto di modello del mondo.
E ovviamente non voglio dire che non si possa fare niente di buono tranne
che con Inform, sarei un imperdonabile ottuso.
Voglio solo dire che, a mio avviso, esistono approcci giusti, un po' meno
giusti e completamente sbagliati alla creazione di AT.
Il "controlla ogni cosa che scrivi", secondo il mio modesto parere, e'
sbagliato perche' fragile e potenzialmente inconsistente.
Basarsi su un modello del mondo che preveda di sistema la presenza di
oggetti apribili, animati, spostabili, porte, collegamenti, demoni e
quant'altro da' una base solida sulla quale basarsi per creare una AT piu'
credibile e complessa nel caso in cui il programmatore abbia la voglia e/o
il tempo per svilupparla.
Il tutto, ovviamente, e' IMHO. :-)))
Paolo M.

 Credo che tu capisca cosa intendo dire.
Capisco benissimo, ma credo anche che la nostra stessa mente si comporti 
spesso in quel modo, con riflessi basati sul riconoscimento di una frase 
specifica piuttosto che su meta-ragionamenti ad alto livello.
D'altra parte il computer *e'* stupido, e che io scriva una struttura 
Porta o venti pezzi di codice uguale, uno per ciascuna porta, le 
operazioni eseguite sono esattamente le stesse.
Puoi parlarmi di eleganza, affidabilita', tempo di sviluppo, coerenza, 
ecc. ecc. e su questo ti posso certamente dare ragione ma, se dal punto 
di vista del giocatore la risposta e' la stessa, dobbiamo riconoscere 
che il grado di "intelligenza" dei due programmi e' assolutamente identico.
Dopotutto il mondo reale non ha una meta-porta, ma ci sono tanti 
distinti oggetti "porta". Qual e' allora la "vera" rappresentazione del 
mondo reale? :-)
   .Erix.

 pezzi uno per uno nella forma che vuole, e' una sua scelta.
Inform sarà anche come i Lego, ma se dici questo in qualche modo contraddici
te stesso quando hai ne hai parlato come linguaggio a basso livello. Forse i
Lego sono la libreria di Inform, ma nessuno toglie la voglia e il piacere a
nessuno di farsi una libreria da solo (e limarsi i pezzi uno per uno della
forma che vuole).
Giovanni

 semplice...mah :)
Extend "l"
    *         -> Look;
    * noun    -> Examine;
ecc.
(basta copiare da Italiang.h la grammatica del verbo "guarda")
"Extend" si usa per estendere la grammatica di un verbo già presente in
libreria, mentre "Verb" si usa per dichiarare la grammatica di un nuovo
verbo.
Comunque in Infit 2 è stato corretto anche "l" come sinonimo di "guarda".
HAPPY INFORMING
Giovanni

 fatto delle prove per un'oretta ma poi mi sono rotto ;)
non capisco perché come "prova" invece di creare due o tre stanze e qualche
oggetto vuoi riscrivere una routine già presente... comunque basta guardare
i file di libreria per vedere come è stata fatta, no?

 credibile e complessa 
ehm... questo non l'avevo ancora letto  - si vede proprio che siamo spiriti
affini :)
aggiungo che tutte queste cose sono ortogonali, per cui la complessità (non
del linguaggio, proprio del problema!) cresce come puoi immaginare. non a
caso anomalie si verificano sotto inform ancora adesso, dopo tanti anni.
ciao
S

Comunque in Infit 2 è stato corretto anche "l" come sinonimo di "guarda".
Quando esce? :)
Jack Norton
-----------------
Web & 3D Graphic
http://www.celso.biz
NWN Modules
http://nwn.celso.biz
IF Site
http://if.celso.biz

> Inform sarà anche come i Lego, ma se dici questo in qualche modo 
 > contraddici te stesso quando hai ne hai parlato come linguaggio
 > a basso livello.
I Lego sono ovviamente le librerie, che sono un discorso diverso 
rispetto al linguaggio.
   .Erix.

parliamo più di linguaggi... IDRA con il modulo inventario va più che bene.
Ecco questo è il mio caso allora :)
Non posso (per questioni di tempo) a cose molto complesse :(




Le stanze con qualche oggetto le ho già fatte, quello è semplice.
Ed ho guardato i file di libreria ma non ci ho capito molto, anche se
ammetto di non aver studiato niente del manuale o altro... volevo
vedere se è vero che inform si capisce facilmente se si ha
un'infarinatura di linguaggi di programmazione (ed io ce l'ho
sicuramente visto che ho fatto 3-4 giochi completi budget in VB).


 alle sollecitazioni
Questo e' un modo di scrivere racconti interattivi, piu' che 
rispettabile, probabilmente amato dalla maggioranza, ma che non e' il 
mio preferito.
Per dirla chiara, io ho trovato l'interfaccia di Anchorhead pesante e 
fastidiosa, pari pari con quella di Zork (ma almeno allora c'era il 
sapore della novita').
In altri termini, non condivido minimamente la passione anglosassone per 
la simulazione nei minimi dettagli; delle AT mi interessano altri aspetti:
- il gioco.
- la trama.
- la narrazione.
- la regia.
- gli (eventuali) enigmi.
   .Erix.



Sono d'accordo al 101% con te.
E' un po' come ciň che accade nei vg. 3D moderni... si guarda di piů
al motore 3D che al gioco stesso... chi se ne frega se il motore fa
girare 1 miliardo di poligoni se il gioco da giocare fa schifo?


 fanno molto per me... 
non hai capito, ovviamente io non intendo questo (anche se è indispensabile
che le interazioni siano sempre coerenti, altrimenti gli oggetti è meglio
toglierli). Dico solo che SE SI VUOLE permettere un'interazione di questo
tipo, il modello che ho descritto è indispensabile. Poi la "granularità"
delle cose che si devono fare dipende unicamente dalle scelte del designer
(e dalla voglia di metterci puzzle, e dalla complessità degli stessi).
ciao
S

 Le stanze con qualche oggetto le ho già fatte, quello è semplice.
allora la prova è riuscita, no?  :)

- gli (eventuali) enigmi.
Certe volte mi chiedo se la mia ammirazione per quest'uomo non sia
dovuta piu' che altro all'entusiamo provato giocando a vecchie glorie
ma addentrandomi nella tecnica ludica mi rendo conto che ogni parola
proferita da lui rappresenta ORO COLATO.
Cari amici designer, pensatela come volete ma trovo che Enrico
Colombini sia un GENIO della narrazione giocata (informatica).  Lui lo
negherebbe e sono certo che nemmeno gli interessa gran che' ma CIO'
CHE FA E' GIUSTO. La sua visione e' quella corretta e mi piacerebbe
avere la meta' delle sue intuizioni. La maggior parte di esse sono
applicabili in molti altri ambiti, alcuni che esulano dal gioco ma
bisognerebbe organizzare dei corsi.
Purtroppo come tutti i geniacci queste qualita' sono assolutamente
incontrollabili :)
Per tornare in topic sono completamente d'accordo (anche questa volta)
con cio' che dice. Ribadisco, come ho fatto in un altro thread, che la
simulazione del mondo e' inutile, ridondante e perfino disorientante.
Ho anche l'impressione che venga recepita in modo ostile dal giocatore
che non si aspetta affatto un mondo 100% verosimile da un videogioco
come non si aspetta una verosimiglianza assoluta in un film.
Ovviamente esistono le eccezioni derivanti da sperimentazioni
d'autore.
- Nota -
Rileggendo questa mail mi rendo conto di aver distribuito abbondanti
leccate e sviolinate. In realta', da quando lo conosco, ho ottenuto
dal sig. Colombini solo la sua -NON PUBBLICIZZATA- presenza all'Acqui
Comics per cui se di sviolinate voleve parlare sappiate che sono
gratuite 8) (che cosi' peggiori la situazione? 8))) ).
--
Il Capo Officina
Tommaso Percivale
http://www.officinadelleidee.org

Io non credo.
Pero' mi  piace un sacco che morde se tenti di prendere qualcosa al
suo interno. Mi ricorda molto le mie posate in tessuto o il
personaggio segreto de L'Artificiere che verra' fuori nella sua
versione definitiva (che pare non si chiamera' piu' cosi').


 Non posso (per questioni di tempo) a cose molto complesse :(
Ti capiamo perfettamente.
Ormai e' chiaro che ognuno ha un punto di vista personale sulle AT, e si e'
capito chiaramente "chi" pensa "cosa".
Io, come sviluppatore, tendo al paradigma "framework", con un modello del
mondo complesso; mi piace la complessita' e in una AT come giocatore l'ho
sempre cercata, la cerco e la cerchero'; ma la mia e' una pura e semplice
opinione personale. Punto.
Attendiamo la tua avventura.
Buon lavoro! :-))))
Paolo M.

 esamina ragazza
puoi finire l'avventura senza usare la parola "ragazza".
--------------------------
questo sì che è utile, necessario e "orientante"!
Sì lo so, tu intendevi un altro tipo di simulazione del mondo, ma sei tu ad
aver capito male perché nella mia accezione non indicavo il tentativo di
descrivere minuziosamente TUTTO con una certa dovizia di particolari (cosa
che al contrario ho indicato come eventuale obiettivo di design), bensì la
solidità delle _infrastrutture_ del mondo simulato che permettono di gestire
al meglio ogni possibile input. E questo non è affatto disorientante, al
contrario è una condizione fondamentale per l'interattività...
ciao
S

 Quando esce? :)
bella domanda ;-)
--
riktik
http://www.nexusent.net
la riscossa della Avventure grafiche

 condizione fondamentale per l'interattività...
io trovo che uno strumento organizzato in tal modo, sia senz'altro
interessante. Ma spesso l'autore è portato  ad "abusare" di tali
simulazioni.
Ogni volta che accade, il gioco diventa frustrante. Come lo è quando a
qualsiasi comando ci si ritrova davantiad un "non ti capisco".
ciao


 simulazioni.
no, perché gli richiede un fracco di lavoro: l'autore fa lo stretto
necessario e aggiunge tutto quello che vuole e che _può_ aumentare il
divertimento, rischiando semmai che il giocatore veda solo una parte (anche
piccola) delle cose che ha scritto. I particolari aggiuntivi non fanno male
a nessuno proprio perché il giocatore medio, o non curioso, non li vede
neanche. Semmai costano un sacco di fatica, questo sì...

 allora la prova è riuscita, no?  :)
Sisi, non dico che non riuscissi a far nulla, ma mi sembrava assurdo non
riuscire a capire come implementare il semplice comando "L" :-P

 Buon lavoro! :-))))
Eheh spero di creare qualcosa di (perlomeno) decente :-)

 (e dalla voglia di metterci puzzle, e dalla complessità degli stessi).
Sì ok, ma il rischio è di esagerare e poi perdersi per strada, un po' come
accade nei vg normali con i motori 3D (per usare un paragone azzeccato
secondo me).
Prima è importante creare un gioco bello da giocare, poi al limite lo si può
arricchire di particolari.

 secondo me).
secondo me no: il fatto č che nell'IF l'interazione non č un gadget, non č
fuffa optional, č _il gioco_. 
ciao
S

 riuscire a capire come implementare il semplice comando "L" :-P
ma non č affatto semplice, al contrario - pensa se ci sono supporter,
contenitori, oggetti trasparenti e cosě via.
Tecnicamente "look" č un dump dello scope (bella sta frase) e i problemi di
scoping sono notoriamente i piů bastardi...
ciao
S

> secondo me no: il fatto è che nell'IF l'interazione non è un gadget, 
 > non è fuffa optional, è _il gioco_.
In uno dei modi di intendere l'IF :-)
   .Erix.


se togli l'interazione, rimane solo la F, no?   :))

 Ok dov'è che ho messo il VB che ho già perso abbastanza tempo...? :)
Ogni tempo sottratto al VisionaryBasic è tempo guadagnato. Disintallalo 
e la tua vita diventerà un paradiso. ;-)
bye
-- 
Paolo Lucchesi
email: 
pluc...@tin.it
homepage: 
http://www.paololucchesi.it
ICQ# 731067
"Non viviamo in un mondo perfetto (per fortuna)"
 

> io trovo che uno strumento organizzato in tal modo, sia senz'altro

non capisco questa risposta, o non ne vedo l'affinità con il modello del
mondo.
Quando parlavo di "abusare" non intendevo certo l'inserimento di
particolari messi in più (che sono sempre apprezzabili), ma mi riferivo
alla tentazione in cui cade l'autore nello sfruttare tale sistema per
nascondere gli oggetti (talvolta in modo assai discutibile e fuori
contesto). Il modello del mondo proposto da uno strumento come inform,
infatti, rende assai facile inserire contenitori e quant'altro, cosicchè
l'autore (che magari vuol fare solo lo stretto necessario) è portato ad
usarne in abbondanza.
Naturalmente questa è una mia sensazione.
Ma io non sono molto interessato a che un gioco simuli la realtà o che
ne rispetti la fisica, non trovo alcun piacere nell'aprire cassetti o
salire su  tavoli e sedie se questo non è di alcun aiuto. Ovviamente
apprezzo la battuta spiritosa per una delle suddette azioni, ma allora
l'autore deve farsi un mazzo a prescindere dalla simulazione.
Diciamocelo alla fine conta l'idea, e l'impegno profuso, non il mezzo.


> se togli l'interazione, rimane solo la F, no?   :))
Su questo siamo d'accordo :-)
   .Erix.

e la tua vita diventerà un paradiso. ;-)
Eheh...potrei provare a farlo direttamente in C++ (anche se credo ci
metterei un anno!!!)




Ah ok allora non era una cosa semplice :) meno male...




Sě, continuando il paragone, per molta gente i giochi SONO l'engine
3D. Per altri conta di piů il divertimento, l'atmosfera, ecc.
Sono due aspetti diversi...




Non si parla di TOGLIERE completamente, ma di semplificarla :)


 quanto -nella realtà- venga usato per le avventure (italiane poi)...
Stai scherzando... quel tipo di mondo a cui fai riferimento tu
viene spesso, se non sempre, almeno nelle mie avventure, utilizzato...
Cosa significa implementare, tu non devi riscrivere nulla, devi semplicemente
specificare delle regole per rendere un contenitore tale,
in modo da renderlo reale, ad es. non poter mettere in un vaso un elefante. 
bai
t

 TOGLIERE completamente, ma di semplificarla :)
Limitare l'interattività per aumentare la giocabilità? Sembra lo slogan
delle ultime avventure grafiche, quelle dove esistono solo gli oggetti da
inventario e il resto del mondo è solo tappezzeria e eye candy.
--
Atrus di Myst
"Solo Dio puo` scegliere a caso."
http://legendknights.keenspace.com

inventario e il resto del mondo è solo tappezzeria e eye candy.
Non hai capito cosa intendo!! rispetto alle avventure grafiche hai cmq
molta più varietà.
Non dico che bisogna eliminare o limitare il numero di oggetti o
verbi. Semplicemente che lo si fa ad hoc.
Le avventure grafiche hanno molte più limitazioni di qualunque
avventura IF.
Per prima cosa non avere l'input a linea di comando... non si passano
ore a pensare qual'è il verbo giusto (sarà girare o svitare o
ruotare?).
Ripeto che il sistema non conta più di tanto, per ottenere
un'avventura bella e giocabile: se si vuol fare una SIMULAZIONE,
allora è un'altra cosa. Però non è mia intenzione di sicuro :-P


 ruotare?).
potevi trovare un esempio più calzante, questo è un limite nelle
avventure testuali non un pregio.


avventure testuali non un pregio.
Eh lo so ma mentre sono al lavoro non mi riesco a spremere molto le
meningi :)


 editato ItalianG.h e ho aggiunto L come sinonimo di guarda.
ma mnon vale, io pensavo che Jack cercasse di reimplementarlo proprio, con
un objectloop sugli oggetti in scope! 
ciao
S



eeeEEH? :-)
no no penso che vada bene come dice lui (ora mi sto accingendo a
provarlo!)

 un'avventura bella e giocabile
Secondo me l'unica cosa importante è che il giocatore non veda la finzione,
ossia non abbassi la sospensione di incredulità. Il ché non vuol dire
infarcire le stanze di oggetti, ma di rendere credibili quelli che nomini.
Se si dice, ad esempio, "sul muro desttro c'è un pezzo di tappezzeria
strappato" e poi il gioco non permette di interagire con muro e tappezzeria,
io mi sento più limitato che in una avventura punta e clicca.
--
Atrus di Myst
Legge di Weiler: Nulla e' impossibile per colui che non deve farlo.
http://legendknights.keenspace.com

provarlo!)
Sě cosě funziona :)
Ma allora č un semplice bug di infit 1.0!  tra l'altro basta invertire
2 righe... perň si potrebbe correggere e rimettere online cosě, in
attesa della versione 2 (a meno che non sia veramente imminente!).
Grazie cmq per la soluzione!

 arricchire di particolari.
Beh, i particolari possono essere proprio ciň cha fa la differenza tra 
un buon gioco e un gioco appena decente, visto che molto spesso sono i 
particolari che creano l'atmosfera.


 eeeEEH? :-)
mi spiego meglio :)
c'è un'_azione_ di look e un _verbo_ look, io pensavo che tu volessi
implementare (per tua insana perversione) l'azione vera e propria (che è
seppellita nei meandri di inform e che nessuno tocca mai, anche perché
esistono apposite funzioni di priorità/risoluzione dello scope per gestire
eventuali problemi).
per farlo dovresti, a grandi linee, stampare ogni oggetto visibile, quindi
fare un objectloop sull'albero degli oggetti - o meglio il sottoalbero
visibile. Così a occhio...
comunque non parliamone più, è meglio. ho appena visto Wasabi in divx, non
male. Stamattina poi ho preso 29...
ciao
S

 - gli (eventuali) enigmi.
Ma siamo perfettamente d'accordo su questo. Non mi pare che il punto 
della discussione sia cosa è importante nello sviluppo di un'avventura, 
ma quanto un modello già sviluppato e coerente sia un buono strumento 
per realizzare ciò. Niente ti può aiutare a realizzare una buona trama, 
ad avere una buona prosa.
Ma a mio parere, anche per dare realismo (che non vuol dire per forza 
avere una simulazione di un mondo, ma piuttosto cercare di raggiungere 
al meglio la 'sospensione dell'incredulità') al gioco, la cura dei 
dettagli è (come già dissi) importante. E un modello completo ti induce 
naturalmente, IMHO, ad una maggior cura dei dettagli.


> E un modello completo ti induce naturalmente, IMHO, ad una maggior 
 > cura dei dettagli.
Io invece temo che con un modello completo sia praticamente impossibile 
curare tutti i possibili dettagli perche' sono troppi, e cio' puo' 
ridurre il piacere di gioco invece di aumentarlo.
E' vero che gran parte dei dettagli sono automaticamente forniti dai 
default delle librerie, ma proprio perche' prevedibili non sono 
interessanti.
Come al solito, sta all'abilita' dell'autore risolvere il problema, ad 
esempio facendo in modo che il giocatore capisca chiaramente che e' 
inutile guardare sopra, sotto, dietro, dentro a ogni oggetto, a meno che 
non ci sia un valido motivo per farlo.
   .Erix.

> Stamattina poi ho preso 29...
Molto bene... a meno che non volessi a tutti i costi almeno 30!
Adesso che sei piu' rilassato :-) parliamo di parser.
Premessa: mi sono ripromesso di aggiornare a tempo perso il Modulo Base 
(diciamo per fine 2003?) senza aggiungere nuove caratteristiche, ma 
purtroppo non posso impedire ai miei neuroni di divagare. Quanto segue 
non ha nulla a che fare col suddetto aggiornamento, non aspettatevi che 
lo aggiunga al codice.
Al momento sto ragionando a tempo perso su aggettivi e parti di frase 
che hanno la stessa funzione:
- Guarda il pavone con le piume verdi
- Riempi il cuscino con le piume verdi
E' evidente che le due frasi hanno un significato del tutto diverso. Nel 
primo caso "con le piume verdi" e' assimilabile a un aggettivo, in 
quanto distingue il pavone in questione da quello con le piume blu; nel 
secondo caso le piume verdi sono un oggetto separato.
Come si comportano in questa situazione gli attuali parser (Inform o altro)?
   .Erix.

male. Stamattina poi ho preso 29...
Ecco, pensiamo alle cose belle della vita...!
Cmq ieri sera ho smanettato un po' e devo dire che superato lo scoglio
iniziale, inform non č male: ho realizzato 1 stanza con 2 oggetti di
cui uno contenitore e ho testato il tutto e funziona perfettamente.
Effettivamente l'approccio ad oggetti consente, alla fine, di
risparmiare un po' di tempo (anche se per fare il tutto ci ho
impiegato 2-3 ore! spero di velocizzarmi un po' altrimenti la finisco
per Natale l'avventura! :).


non ci sia un valido motivo per farlo.
Sì esatto. L'avventura deve essere difficile per gli enigmi e per
capire COSA fare (nel senso, se andare in un dato posto, parlare con
una certa persona, ecc) e non su COME farlo (cioè non riuscire a
trovare il verbo giusto oppure compiere un'azione che non ha un senso
apparente e immediato).


LE PIUME VERDI
Confronta con un verbo con una sintassi piu` complessa, che prevede varie
possibili combinazioni di parti letterali e di argomenti:
Verb 'take' 'carry' 'hold'
                * multi                          -> Take
                * 'off' worn                     -> Disrobe
                * multiinside 'from' noun        -> Remove
                * multiinside 'off' noun         -> Remove
                * 'inventory'                    -> Inv;
(Nel mio esempio ho messo sempre "noun", ma probabilmente un vero verbo
"riempi" richiedera` che almeno l'oggetto con cui si riempe sia "held",
come qui si richiede che se ci si puo` togliere di dosso qualcosa, doveva
essere "worn".)
Per quanto riguarda il verbo "guarda", la sua sintassi richiedera` in
genere al piu` un solo argomento e quindi (ma qui non sono sicurissimo)
quella frase sara` riconosciuta solo se esiste un oggetto che ha tra i
possibili nomi "pavone con le piume verdi".
Il succo e` che il parser, per cosi` dire, non nota la somiglianza
apparente di quelle due frasi. Una volta individuato il verbo, si rivolge
alle possibili grammatiche definite per quel verbo per interpretare il
resto.
   A questo punto mi chiedo come si possa affrontare una frase (estrema)
del tipo "Riempi il pavone con le piume verdi con spezie e miele" (ponendo
che quello con le piume viola invece non lo si voglia farcire...).
Ciao, spero di essere stato un pochino utile,
							Daniele

 apparente di quelle due frasi. Una volta individuato il verbo, si 
 > rivolge alle possibili grammatiche definite per quel verbo per
 > interpretare il resto.
Interessante, grazie. Quindi, se ho ben capito, Inform (o l'autore) deve 
definire una sintassi per ciascun possibile significato di ogni verbo usato?
E frasi come:
  - "guarda la rosa rosa rosa" (inteso come fiore/colore/corrosa)
come vengono analizzate?
   .Erix.

ROSA ROSA
Quale, la rosa rosa rosa o la rosa fresca aulentissima?
...
Il modo piu` semplice per uscirne che mi viene in mente (oltre ovviamente
a cambiare gli oggetti) comporta manipolare un po' il parser. Se hai
sottomano il DM4, nella sezione 33 si parla in generale di "come aiutare
il parser", e alla fine si menziona un'estensione alla libreria
(calyx_adjectives.h) che prevede che nel definire i "name" si distinguano
accettivi da sostantivi (questa a sua volta si rifa` all'estensione
adname.h che credo sia stata la prima ad introdurre questa distinzione).
Ciao,
							Daniele

> Il modo piu` semplice per uscirne che mi viene in mente (oltre 
 > ovviamente a cambiare gli oggetti) comporta manipolare un po'
 > il parser.
Al momento, come dicevo, e' pura curiosita': stavo chiedendomi come 
rendere piu' versatile un non-parser :-)
Altra curiosita': se Inform richiede di definire i requisiti di un verbo 
(es. "lascia" richiede un oggetto posseduto), come gestisce le frasi 
tipo "lascia perdere" o "lascia la nave"?
   .Erix.

 come vengono analizzate?
Che io sappia gli aggettivi servono solo a disambiguare (opzionalmente
sostituire) i nomi, per cui in mancanza di altre rose, cambia poco che
quella che dici tu sia rossa o rosa, (e)rosa o luccicante di cromo e
vanadio. Comunque in casi di ambiguità esplicita (quelli che il
programmatore prevede, o che più plausibilmente emergono dal betatesting) si
può inserire codice che esplicitamente "aiuta" il parser indicando priorità
eccetera. Però non è una parte che conosco bene perché non ne ho mai avuto
bisogno...
ciao
S

 accettivi da sostantivi 
si ma questo è overkill, in un caso come questo basta usare direttamente
ChooseObjects... penso...

 tipo "lascia perdere" o "lascia la nave"?
cosě a occhio non capisce un tubo & stampa stupidi messaggi d'errore tipo:
"non hai mica in mano la nave!".
Ma questi sono tutti problemi di grammatica, non di parser... una prima
soluzione č appunto cablare  nella grammatica questi casi esplicitando gli
oggetti/parole che danno problemi, come appunto "perdere", "nave" (facile e
veloce, ma molto brutto). Altrimenti si scrivono routine a "monte"
dell'azione tipo: se l'oggetto č un contenitore (stanza) e il personaggio vi
č dentro, lascia --> esci, altrimenti lascia --> molla.
ciao
S

 per Natale l'avventura! :).
se la finissi per Natale saresti davvero veloce, credimi...


Posso garantire... Per il mio progetto attuale (grossino, potrebbe anche 
venir fuori un file .z8), lavorando nei (pochi) ritagli di tempo, ho 
impegato circa sette mesi e ne stimo per lo meno un'altro, più 
probabilmente un paio. E vi posso garantire che il grosso del tempo l'ho 
impiegato a scrivere i testi.
Come ho già detto, inform IMHO spinge alla cura dei dettagli (oltre che 
ad una certa verbosità, ma questa deriva più probabilmente dal mio gusto 
personale). E questi richiedono tempo.


 curare tutti i possibili dettagli 
Enrico, mi sa che non ci stiamo capendo: quando parlo di modello mi
riferisco solo all'architettura _interna_ del sistema, è un discorso
unicamente tecnico e non ha nulla a che fare col game design. Se al designer
non interessano i supporter, i contenitori trasparenti ma non troppo, i
demoni, le fake action ec ec ec può benissimo non solo farne a meno, ma
proprio ignorarne il funzionamento. Anzi non sapere proprio che esistono.
Quindi considerazioni come stile di gioco, cura dei dettagli ecc non
c'entrano nulla... che poi sul DM4 si parli di tutto questo e molto più, e
in che modo, è un problema semmai di documentazione 
ciao
S

impiegato a scrivere i testi.
Che differenza c'é tra il formato Z5 e quello Z8? Forse il secondo
supporta il Glux e il primo no o c'è anche qualcos'altro?
Ciao da
Vincenzo

 supporta il Glux e il primo no o c'è anche qualcos'altro?
no, glulx è un'altra roba, z8 è semplicemente "più grande" (più spazio in
memoria perché la macchina virtuale è diversa)



Ah. Quello che però non ho ancora capito è se Glux è facente parte
delle istruzioni della Z-machine, oppure è una sorta di "modulo
esterno" da integrare con Inform.
Ciao da
Vincenzo

 esterno" da integrare con Inform.
glulx non c'entra niente con la z-machine, è proprio un'altra macchina
virtuale con il relativo "emulatore" (glulxe). L'unica cosa che hanno in
comune è il fatto che glulx-inform compila per l'una o l'altra
piattaforma... sempre che non si usi assembler o cose simili, ovviamente. 
In generale comunque qualsiasi programma z-inform si converte in
glulx-inform in un attimo (ad esempio convertendo la lunghezza delle parole
da 2 a 4 byte, cosa che non devi fare se usi correttamente la costante
WORD_SIZE nel codice). In altre parole glulx-inform è quasi completamente
retrocompatibile con z-inform.
è divertente vedere il "percorso" compiuto da tutto l'ambaradan pensando che
inform non c'entra nulla con la infocom ed è stato sviluppato partendo dalla
sola specifica della z-machine :)
ciao
S

 esterno" da integrare con Inform.
Su IF Italia, nella sezione Help e Guide, č presente la traduzione di Gull, 
un documento di Adam Cadre che cerca di spiegare a modo suo cosa č Glulx e 
come si usa. 
-- 
Paolo Vece - 
pv...@inwind.it
 - 
http://www.vece.net

sola specifica della z-machine :)
Uh? Ma Nelson non aveva convertito lo Zil della Infocom in Inform?
Ciao da
Vincenzo

 Uh? Ma Nelson non aveva convertito lo Zil della Infocom in Inform?
non credo proprio, Zil era un linguaggio funzionale lisp-like mentre inform
è imperativo... l'unica cosa che hanno in comune è il target del
compilatore, ovvero la z-machine. Inoltre mentre la specifica della
z-machine è disponibile praticamente da sempre, non credo sia mai stato
rilasciato un "manuale tecnico" di Zil.

come si usa. 
Ti ringrazio, appena ho un po' di tempo vado a darci un'occhiata...
Grazie e ciao
V.

rilasciato un "manuale tecnico" di Zil.
Se non mi sbaglio, con imperativo intendi il modo di programmare piů
usuale: quello di dire al computer una certa cosa e fargliela fare.
Ricordo che alle superiori il nostro professore di informatica ci
aveva fatto qualche lezione sul PROLOG, un linguaggio che, a partire
dai dati fornitigli dal programmatore, riusciva a trovare la
soluzione. Mi chiedo se una tecnologia simile possa essere usata per
la scrittura di un parser piů realistico...
Ciao da
Vincenzo

 soluzione. Mi chiedo se una tecnologia simile possa essere usata 
 > per la scrittura di un parser più realistico...
Il Prolog e' abbastanza usato per l'analisi linguistica, specie a 
livello universitario (spero che cio' non sia considerato OT...). Eoni 
fa feci qualche esperimento per portare il Castello sotto il Turbo 
Prolog, ma dovetti lasciar perdere perche' a) raggiunsi subito i limiti 
dell'implementazione e della memoria del PC e b) Purtroppo la Borland lo 
abbandono' quasi subito, evidentemente per lo scarso successo commerciale.
 >Mi chiedo se una tecnologia simile possa essere usata per
 >la scrittura di un parser più realistico...
Beh, qualunque linguaggio puo' essere usato per qualunque cosa, o 
quasi... alla fine e' questione di praticita'. Direi che col Prolog la 
parte di riconoscimento potrebbe forse essere semplificata, mentre 
probabilmente si complicherebbe il resto (eseguire azioni, stampare 
messaggi, ecc.).
Personalmente credo che i linguaggi dinamici tipo Lisp (tra cui i 
migliori linguaggi di scriting, che ne ereditano molte caratteristiche) 
siano piu' adatti a questo tipo di applicazione, anche perche' ormai i 
problemi di memoria e velocita' non esistono piu' (almeno sui PC).
   .Erix.

In un momento di rara lucidità, Vincenzo Scarpa ha scritto:

il link è corrotto
--
riktik
http://www.nexusent.net
la riscossa della Avventure grafiche

 il link è corrotto
Beh, c'è sempre il mirro del vecchio IF Italia all'indirizzo:
http://plovec.interfree.it/IFItalia/index.html
Il link diretto per Gull è:
http://plovec.interfree.it/IFItalia/Varie/gull/index.html
