title: liste di verbi limitate

text:
Paolo Lucchesi ha scritto:
>> se c'è una piaga che sembra
>> possa affliggere un gioco in qualche modo è l'infame
>>"indovina-il-verbo" "indovina-il-nome". quelle scomode situazioni in
>> cui dopo ore di tentavi sei costretto a ricorrere alla soluzione solo
>> per scoprire che l'autore non ha contemplato il tuo "accendi il fuoco
>> nel camino" ma solo il suo "appicca legna nella caldaia" [esempio
>> inventato al momento ma tristemente realistico].
> Premettendo che reputo decisamente interessanti e degne di discussione
>le tue idee, ma intanto diciamo che per buona parte i problemi di
> "invovina-la-parola" dipendono da errori del programmatore (che non
> mette un sufficiente numero di sinonimi e non pensa ad altre forme in
> cui potrebbe essere espressa la stessa azione) e, soprattutto, da
> mancanza di play-testing.
verissimo. però quello che dici è ancor più vero dal punto di vista
teorico che dal punto di vista pratico. agli atti, anche giochi molto
ragionati e sviluppati con cura e perizia dagli autori, con lunghe fasi
di playtesting, risultano spesso "infangati" dalla piaga della (ovvia)
impossibilità di un computer di capire [tutto] quello che gli viene
detto. per quanto io possa trovare 100 sinonimi per ogni oggetto
mensionato nell'avventura, potrà sempre essercene un 101esimo che è
sfuggito, o un altro modo, più o meno ovvio, per compiere la stessa
azione ma non preso in considerazione da autore + playtester. il
problema, più che di applicazione allo sviluppo, tempo, attenzione o
devozione, è intrinseco nel mezzo. che poi ci siano avventure
splendide, è indubbio. ma mi pare altrettanto statisticamente
significativo che terminare un'avventura senza aver trovato almeno un
"non capisco cosa vuoi dire" o "prova qualcos'altro" o simili sia
abbastanza raro. a me non è mai capitato, per dire. e questa è una
cosa che distrugge la mimesi.
un'avventura molto carina, per esempio, è nazy jones, di gabriele
lazzara. mi sono divertito parecchio a giocarla, e ci sono belle idee e
begli spunti. qualcosa di leggero per staccare, insomma. ma quando mi
sono trovato
S
P
O
I
L
E
R
S
P
O
I
L
E
R
con una tanica in mano piena di benzina e una jeep davanti a me e non
ero in grado di riempire il serbatoio.. beh, la magia del gioco
scompare! in questo caso penso che la colpa fosse dell'implementazione,
ma situazioni simili purtroppo sono piuttosto frequenti. forse non è
l'esempio migliore, in questo caso ritengo che la colpa fosse della
programmazione, ma, a mio avviso, il problema è intrinseco nella
natura dell'avventura testuale.
F
I
N
E
S
P
O
I
L
E
R
>> trovandomi a gestire un sistema con browser, le capacità dell'html, il
>> mouse, i link eccetera, mi sono istintivamente indirizzato verso
>> qualcosa di punta-e-clicca che ben presto ha fatto virare il mio
>> progetto in qualcosa di abbastanza distante dal classico stile infocom.
> Questo e' interessante. La parte del punta-e-clicca, intendo. La parte
> relativa a giocare con il browser... ok, non riprendiamo vecchie
> discussioni, concentriamoci sul nuovo...
> Non sono sicuro che il PnC sia la panacea universale di tutti i problemi
> dell'I.F. e che rappresenti il futuro, ma e' sicuramente una cosa da
> studiare, da provare...
sì, accantoniamo vecchie discussioni, mi pare saggio! eh eh
il "punta e clicca" come termine pare aver associato a sè un concetto
di limitatezza e semplicità che può essere disturbante. mi viene da
pensare a un'avventura punta e clicca come monkey island. mi sono
divertito (e penso di non essere l'unico) moltissimo a giocarla e
rigiocarla: bella atmosfera, divertente, intelligente e con puzzle ben
studiati. e il tutto con una decina (12?) di verbi.
riproporre questo a livello testuale, però, non è nelle mie
intenzioni. le avventure grafiche p&c e le at sono molto diverse e
sostituire il disegno animato di un pappagallo con la parola cliccabile
"pappagallo" non è certo costruire un ponte fra i due tipi di gioco.
quello che ho in mente e a cui lavoro si avvicina di più a una
versione testuale dell'interfaccia di return of zork. molti verbi che
si adattano alle varie situazioni.
>> inutile dire che la prima "mini avventura" sulla quale ho deciso di
>> testare il sistema è cloak of darkness
> Non so quanto sia stata una scelta azzeccata. Pensando a un PnC stai
> cambiando paradigma; il modo di concepire una a.t., appena si entra un
> minimo nel dettaglio, viene influenzato dal tipo di interfaccia che si
> vuole adottare. Cloak e', per quanto semplice, pensato per il parser;
> semplicemente i suoi enigmi potrebbero non funzionare con un'altra
> interfaccia.
più vado avanti più mi rendo conto di quanto tu abbia ragione. resta
il fatto che cloak of darkness è cortissima e facile da implemenare,
quindi, anzichè perder tempo a pensare a qualcosa di nuovo, la userò
comunque per dirvi "ecco, più o meno l'idea è questa".
>> il sistema funziona così: [...] ogni oggetto è cliccabile. questo fa
>> apparire, sepmpre in quella parte dello schermo, la descrizione
>> dell'oggetto e le varie azioni eseguibili con l'oggetto stesso (è uno
>> splendido cappotto eccetera .. POSA INDOSSA eccetera) [...]
> Quasi buono... Non e' un po' troppo intrusiva la finestra sottostante?
> Io negli ultimi tempi stavo pensando ad un pop-up menu' con le azioni...
> Per la descrizione: o la metti in "on mouse over" (non mi piace troppo,
> ma proprio per gusto soggettivo) o aggiungi il buon vecchio "esamina"
> tra le azioni e fai apparire la descrizione nella finestra principale...
non è una finestra sottostante... immagina una schermata divisa in
frame (ma non uso frame!) con una colonna a destra e la parte più
ampia (la finestra principale con le descrizioni delle stanze ecc) di
schermo sulla sinistra. ecco, lavoro sulla colonna laterale..
>> questo sistema semplicissimo e molto intuitivo (ho comunque lasciato lo
>> spazio per un "input box" normale per tutti quei comando che potrebbero
>> servire, come parole magiche, numeri telefonici eccetera)
> Mmm, bah... questo mi piace poco... Se sto giocando con il mouse, sto
> giocando con il mouse... Dettagli comunque...
in effetti l'ho eliminato..
>> tutto quello che posso fare è lì, a portata di click.
>> questo è anche il grosso limite del sistema. in questo tentativo di
>> ottenere sintesi e trasparenza, ho portato all'estremo le conseguenza.
>> il gancio del gioco non è tirabile, staccabile eccetera. è fisso e
>> inutile. al massimo ci si può appendere il cappotto [...] la sola presenza
>> di un verbo non standard come appendi, per
>> esempio, è una chiara indicazione al giocatore su un'azione da
>> compiere.
> Questo e' vero, ed e' un problema che in parte mi angustia. La lista
> delle azioni contestuali e' molto elegante, ma in effetti rischia di
> guidare troppo il personaggio, anche se si aggiungono per ogni oggetto
> un po' di azioni logiche ma inutili ai fini del progresso della trama
> (esempio, per un armadio, il giocatore potra' guardare sotto, trovando
> "solo polvere").
> D'altronde, cosi' ad occhio, il principale problema di ogni interfaccia
> PnC e' proprio quello di avere una certa "ovvieta'" sulle possibili
> linee d'azione offerte al giocatore.
> Come dicevo, la prima cosa da fare e' quella di "pensare" i dettagli
> dell'avventura, e soprattutto gli enigmi, in funzione di un'interfaccia PnC.
infatti. come giustamente sottolinea anche paolo maroncelli in un altro
post della discussione, penso che molte "coversioni" da if tradizionali
perderebbero parecchio. sto lavorando proprio a quello che tu chiami
"menu contestuale", una serie di azioni disponibili per l'oggetto o per
il giocatore che variano a seconda delle circostanze, della stanza,
dell'oggetto che ci si associa. inoltre la trovo, come tu sottolinei,
una scelta molto elegante.
immaginiamo che io abbia una macchina in una locazione giardino. in una
if tradizionale devo implementare risposte non standard (o lasciare le
poco eleganti risposte di default) per azioni come assaggia o solleva
che il giocatore potrebbe provare: "hai voglia di mangiare metallo?"
"non hai voglia di procurarti un'ernia". le variabili da prendere in
considerazione sono moltissime, e comunque il giocatore, come dicevo
prima, potrebbe provare a fare qualcosa di inatteso. nel sistema che
sto sviluppando è molto facile implementare false azioni razionali per
riempire il menu, come "spingi" ("è troppo pesante e probabilmente il
freno a mano è tirato") "rompi finestrino" ("hai paura di romperti la
mano") eccetera. quando poi il giocatore trova una chiave, questa non
ha alcuna azione associata a sè, tranne che nelle locazioni in cui
sono presenti delle porte e nel giardino, dove aprirà la portiera.
>> [...] nella prima stanza, fra vari oggetti c'è anche una libreria.
>> se il giocatore
>> dovesse arrampicaricisi, però, troverebbe anche una doppietta nascosta
>> lì dal nonno [...] La libreria, implementata con il sistema di cui sto
>> discutendo, avrebbe solo un verbo palese: ARRAMPICATI, levando spessore
>> al gioco.
> Vero, anche perche' l'enigma della libreria e' pensato per il parser.
> Senza starci a pensare molto, basta aggiungere una sedia da "spostare"
> per poter salire sulla libreria.
giustissimo, si ritorna al "ogni avventura al suo sistema".
>> da qui l'idea di avere una serie di verbi standard (tipo le avventure
>> grafiche della lucas, per dire!), divisi fra quelli di movimento e
>> quelli applicabili agli oggetti o ai png. ogni oggetto, quindi,
>> potrebbe avere un menu a tendina (per esempio) di azioni fra cui
>> ARRAMPICATI. nel caso di una caffettiera non porta a nessun risultato,
>> nel caso della libreria a una doppietta.
> L'idea della lista non contestuale mi piace poco, e l'avevo gia'
> scartata. Il problema sta nella dimensione della lista di azioni.
> Se vogliamo contemplare tutte le azioni possibili, vien fuori una lista
> immensa, in cui per ogni oggetto la maggior parte delle azioni sono
> inutili (perche' dovrei in condizioni normali voler parlare ad un tavolo
> o chiudere un png).
sì sì, in effetti il menu dinamico è molto più elegante. però
alcune azioni non legate agli oggetti ma al personaggio dovrebbero
essere sempre disponibili, come "aspetta" o "inventario", per esempio..
(suggerimenti su quali altre?)
> Se invece vogliamo ridurre le dimensioni della lista a 6/8 azioni, siamo
> costretti a ricorrere ad azioni generiche (e qui mi sento arrivare tra
> la terza e la quarta vertebra cerebrale l'orribile verbo "USA") che non
> sempre rispecchiano la vera intenzione del giocatore.
e invece, per quanto anche io odi "usa" così com'è (un verbo per
risolvere gli enigmi sena averne capito la soluzione), includerei un
"usa con" o "associa" o simili come "pre-verbi". per spiegarmi (prendo
dalla memoria un esempio in qualche vecchissimo post, penso di
r.a.i.f.): "usa spada + troll" potrebbe essere ambiguo. sebbene nel 98%
dei casi significhi "ammazza il troll con la spada", potrebbe anche
essere "rifai il taglio di capelli al troll usando la spada come
rasoio" o "investi il troll del titolo di cavaliere" (battendogli la
spada sulle spalle) e tutto dipende dall'avventura. l'uso (scusa il
gioco di parole) di "usa spada + troll", quindi, potebbe far apparire
un secondo menu (di secondo livello, diciamo) con varie azioni
disponibili per la combinazione troll + spada. certo, prendendo in
considerazione cloak of darkness, posso anche sfruttare il verbo
generico "usa cappotto + appendiabiti" e dare per scontato che ce lo si
voglia appendere!! questo sistema di menu nascosti aiuta ulteriormente
a non "far vedere tutto e subito" che potrebbe rovinare il gioco. in
return of zork c'era un fiore (o una piantina, non ricordo). lo si
poteva solo cogliere. usandoci sopra il coltello, si poteva recidere,
scavare per prenderla con tutte le radici eccetera...
> Inoltre una lista ridotta porta il problema degli enigmi risolti per
> esaustione, ovvero provando tutte le azioni e tutte le combinazioni (un
> classico delle A.G.)
in realtà questo si presenta sia con liste lingue che con liste
contestuali, e, purtroppo, certe volte il "brute forcing" è possibile
anche con le if tradizionali, sebbene sia più lungo.
presumo, comunque, che un sistema come quello a cui sto pensando debba
avere un mondo mediamente più complesso, con più cose da provare,
abbinare, esplorare, per evitare di avere giochi risolvibili di 15
minuti. per quanto ho visto ora, comunque, è possibile creare e
espandere un mondo molto rapidamente.
> Mi viene in mente mentre scrivo una soluzione ibrida: dividiamo gli
> oggetti per categoria (png, uscite, oggetti grandi/statici, oggetti
> piccoli/trasportabili, etc.etc.) e usiamo una lista diversa per ogni
> categoria...
in realtà, più vado avanti a leggere, scrivere, pensare e sviluppare
e più la soluzione dei menu contestuali mi pare ottima. per quanto
molti oggetti siano "prendibili" o "posabili", ci sono moltissimi
oggetti splendidi da caratterizzare. prendi un televisore: ci si
possono fare molte cose e implementarlo in una if, anche se non
complicatissimo, richiede il comunicare al giocatore come usarlo, visto
che non è la classica leva da tirare, il buco da riempire, la palla da
lanciare. una volta acceso, si possono cambiare i canali, mettere un
dvd, consultare il televideo... pensalo in una if senza menu.. ci vuole
qualcosa che spezzi la mimesi tipo "puoi usare 'cambia canale <numero>'
o 'usa televideo <pagina>' eccetera o prevedere i mille modi in cui il
giocatore può provare a compiere queste azioni. un menu contestuale
può semplicemente contenere i verbi che si vogliono..
> Btw, come pensavi di gestire, nelle due soluzioni, le combinazioni di
> oggetti con altri oggetti (es. COLPISCI IL VASO MING CON IL RANDELLO)?
appunto.. usa / abbina + eventuale sub-menu per le varie azioni fra i
due oggetti!
l'ho già implementato in questo modo: la selezione di "usa" dal menu
abilita un altro menu a tendina contenente gli oggetti presenti
nell'inventario + quelli nella stanza (gli oggetti "in scope", per
intenderci) per renderli associabili.
A queto punto, però, mi chiedo se non sarebbe il caso, per la stessa
"onestà ed eleganza" di cui sopra, di non rendere disponbili solo gli
oggetti con i quali è effettivamente possibile assiaciare l'oggetto in
discussione..
> Bon, per ora basta cosi'... continuo poi.
bye
a presto!


title: liste di verbi limitate

text:
[snip]
> Possiamo parlare di questo, prima pero' consentimi qualche domanda su
> certi dettagli che ignoro:
> -Scusa la prima curiosita': sei "Pistacchio" ma poi dici di chiamarti
> "troy mcclure"... sei uno straniero in Italia o e' solo un secondo
> soprannome? (..preso da un personaggio che non conosco??)
eh eh, troy mcclure è un personaggio di simpson (non so se ricalca
qualche reale personaggio pubblico) che nella serie si presenta sempre
con la frase "salve, sono troy mcclure, forse vi ricorderte di me
per.." e aggiunge un programma / film / serie / documentario a cui ha
preso parte. è una macchietta divertente.
> -Il sistema che stai svilluppando come dovrebbe essere poi impiegato
> dall'utente per scrivere un gioco? Sempre programmando in javascript con
> l'ausilio di librerie e strutture gia' da te predisposte per l'if o
> attraverso un linguaggio "ad hoc" che poi il tuo sistema provvederebbe a
> "compilare" in java script in modo da disporre di un macchina virtuale?
un linguaggio "ad hoc" provai già a svilupparlo tempo fa. è un lavoro

if (x == y) {}


eccetera..
> -Conosci il sistema "Idra"? Pensi sarebbe possibile ottenere qualcosa di
> simile a quello che hai in mente sfruttando tale sistema, oppure
> potenziando le possibilita' dell'Idra attuale?
all'idra ho dato qualche fugace occhiata, soprattutto agli esempi e ad



title: liste di verbi limitate

text:
>> se c'è una piaga che sembra
>> possa affliggere un gioco in qualche modo è l'infame
>>"indovina-il-verbo" "indovina-il-nome". quelle scomode situazioni in
>> cui dopo ore di tentavi sei costretto a ricorrere alla soluzione solo
>> per scoprire che l'autore non ha contemplato il tuo "accendi il fuoco
>> nel camino" ma solo il suo "appicca legna nella caldaia" [esempio
>> inventato al momento ma tristemente realistico].
> Premettendo che reputo decisamente interessanti e degne di discussione
>le tue idee, ma intanto diciamo che per buona parte i problemi di
> "invovina-la-parola" dipendono da errori del programmatore (che non
> mette un sufficiente numero di sinonimi e non pensa ad altre forme in
> cui potrebbe essere espressa la stessa azione) e, soprattutto, da
> mancanza di play-testing.
verissimo. però quello che dici è ancor più vero dal punto di vista

P
O
I
L
E
R
S
P
O
I
L
E
R


>> trovandomi a gestire un sistema con browser, le capacità dell'html, il
>> mouse, i link eccetera, mi sono istintivamente indirizzato verso
>> qualcosa di punta-e-clicca che ben presto ha fatto virare il mio
>> progetto in qualcosa di abbastanza distante dal classico stile infocom.
> Questo e' interessante. La parte del punta-e-clicca, intendo. La parte
> relativa a giocare con il browser... ok, non riprendiamo vecchie
> discussioni, concentriamoci sul nuovo...
> Non sono sicuro che il PnC sia la panacea universale di tutti i problemi
> dell'I.F. e che rappresenti il futuro, ma e' sicuramente una cosa da
> studiare, da provare...
sì, accantoniamo vecchie discussioni, mi pare saggio! eh eh
il "punta e clicca" come termine pare aver associato a sè un concetto
di limitatezza e semplicità che può essere disturbante. mi viene da
pensare a un'avventura punta e clicca come monkey island. mi sono
divertito (e penso di non essere l'unico) moltissimo a giocarla e
rigiocarla: bella atmosfera, divertente, intelligente e con puzzle ben
studiati. e il tutto con una decina (12?) di verbi.
riproporre questo a livello testuale, però, non è nelle mie
intenzioni. le avventure grafiche p&c e le at sono molto diverse e
sostituire il disegno animato di un pappagallo con la parola cliccabile
"pappagallo" non è certo costruire un ponte fra i due tipi di gioco.
quello che ho in mente e a cui lavoro si avvicina di più a una
versione testuale dell'interfaccia di return of zork. molti verbi che
si adattano alle varie situazioni.
>> inutile dire che la prima "mini avventura" sulla quale ho deciso di
>> testare il sistema è cloak of darkness
> Non so quanto sia stata una scelta azzeccata. Pensando a un PnC stai
> cambiando paradigma; il modo di concepire una a.t., appena si entra un
> minimo nel dettaglio, viene influenzato dal tipo di interfaccia che si
> vuole adottare. Cloak e', per quanto semplice, pensato per il parser;
> semplicemente i suoi enigmi potrebbero non funzionare con un'altra
> interfaccia.
più vado avanti più mi rendo conto di quanto tu abbia ragione. resta
il fatto che cloak of darkness è cortissima e facile da implemenare,
quindi, anzichè perder tempo a pensare a qualcosa di nuovo, la userò
comunque per dirvi "ecco, più o meno l'idea è questa".
>> il sistema funziona così: [...] ogni oggetto è cliccabile. questo fa
>> apparire, sepmpre in quella parte dello schermo, la descrizione
>> dell'oggetto e le varie azioni eseguibili con l'oggetto stesso (è uno
>> splendido cappotto eccetera .. POSA INDOSSA eccetera) [...]
> Quasi buono... Non e' un po' troppo intrusiva la finestra sottostante?
> Io negli ultimi tempi stavo pensando ad un pop-up menu' con le azioni...
> Per la descrizione: o la metti in "on mouse over" (non mi piace troppo,
> ma proprio per gusto soggettivo) o aggiungi il buon vecchio "esamina"
> tra le azioni e fai apparire la descrizione nella finestra principale...
non è una finestra sottostante... immagina una schermata divisa in
frame (ma non uso frame!) con una colonna a destra e la parte più
ampia (la finestra principale con le descrizioni delle stanze ecc) di
schermo sulla sinistra. ecco, lavoro sulla colonna laterale..
>> questo sistema semplicissimo e molto intuitivo (ho comunque lasciato lo
>> spazio per un "input box" normale per tutti quei comando che potrebbero
>> servire, come parole magiche, numeri telefonici eccetera)
> Mmm, bah... questo mi piace poco... Se sto giocando con il mouse, sto
> giocando con il mouse... Dettagli comunque...
in effetti l'ho eliminato..
>> tutto quello che posso fare è lì, a portata di click.
>> questo è anche il grosso limite del sistema. in questo tentativo di
>> ottenere sintesi e trasparenza, ho portato all'estremo le conseguenza.
>> il gancio del gioco non è tirabile, staccabile eccetera. è fisso e
>> inutile. al massimo ci si può appendere il cappotto [...] la sola presenza
>> di un verbo non standard come appendi, per
>> esempio, è una chiara indicazione al giocatore su un'azione da
>> compiere.
> Questo e' vero, ed e' un problema che in parte mi angustia. La lista
> delle azioni contestuali e' molto elegante, ma in effetti rischia di
> guidare troppo il personaggio, anche se si aggiungono per ogni oggetto
> un po' di azioni logiche ma inutili ai fini del progresso della trama
> (esempio, per un armadio, il giocatore potra' guardare sotto, trovando
> "solo polvere").
> D'altronde, cosi' ad occhio, il principale problema di ogni interfaccia
> PnC e' proprio quello di avere una certa "ovvieta'" sulle possibili
> linee d'azione offerte al giocatore.
> Come dicevo, la prima cosa da fare e' quella di "pensare" i dettagli
> dell'avventura, e soprattutto gli enigmi, in funzione di un'interfaccia PnC.
infatti. come giustamente sottolinea anche paolo maroncelli in un altro
post della discussione, penso che molte "coversioni" da if tradizionali
perderebbero parecchio. sto lavorando proprio a quello che tu chiami
"menu contestuale", una serie di azioni disponibili per l'oggetto o per
il giocatore che variano a seconda delle circostanze, della stanza,
dell'oggetto che ci si associa. inoltre la trovo, come tu sottolinei,
una scelta molto elegante.
immaginiamo che io abbia una macchina in una locazione giardino. in una
if tradizionale devo implementare risposte non standard (o lasciare le
poco eleganti risposte di default) per azioni come assaggia o solleva
che il giocatore potrebbe provare: "hai voglia di mangiare metallo?"
"non hai voglia di procurarti un'ernia". le variabili da prendere in
considerazione sono moltissime, e comunque il giocatore, come dicevo
prima, potrebbe provare a fare qualcosa di inatteso. nel sistema che
sto sviluppando è molto facile implementare false azioni razionali per
riempire il menu, come "spingi" ("è troppo pesante e probabilmente il
freno a mano è tirato") "rompi finestrino" ("hai paura di romperti la
mano") eccetera. quando poi il giocatore trova una chiave, questa non
ha alcuna azione associata a sè, tranne che nelle locazioni in cui
sono presenti delle porte e nel giardino, dove aprirà la portiera.
>> [...] nella prima stanza, fra vari oggetti c'è anche una libreria.
>> se il giocatore
>> dovesse arrampicaricisi, però, troverebbe anche una doppietta nascosta
>> lì dal nonno [...] La libreria, implementata con il sistema di cui sto
>> discutendo, avrebbe solo un verbo palese: ARRAMPICATI, levando spessore
>> al gioco.
> Vero, anche perche' l'enigma della libreria e' pensato per il parser.
> Senza starci a pensare molto, basta aggiungere una sedia da "spostare"
> per poter salire sulla libreria.
giustissimo, si ritorna al "ogni avventura al suo sistema".
>> da qui l'idea di avere una serie di verbi standard (tipo le avventure
>> grafiche della lucas, per dire!), divisi fra quelli di movimento e
>> quelli applicabili agli oggetti o ai png. ogni oggetto, quindi,
>> potrebbe avere un menu a tendina (per esempio) di azioni fra cui
>> ARRAMPICATI. nel caso di una caffettiera non porta a nessun risultato,
>> nel caso della libreria a una doppietta.
> L'idea della lista non contestuale mi piace poco, e l'avevo gia'
> scartata. Il problema sta nella dimensione della lista di azioni.
> Se vogliamo contemplare tutte le azioni possibili, vien fuori una lista
> immensa, in cui per ogni oggetto la maggior parte delle azioni sono
> inutili (perche' dovrei in condizioni normali voler parlare ad un tavolo
> o chiudere un png).
sì sì, in effetti il menu dinamico è molto più elegante. però
alcune azioni non legate agli oggetti ma al personaggio dovrebbero
essere sempre disponibili, come "aspetta" o "inventario", per esempio..
(suggerimenti su quali altre?)
> Se invece vogliamo ridurre le dimensioni della lista a 6/8 azioni, siamo
> costretti a ricorrere ad azioni generiche (e qui mi sento arrivare tra
> la terza e la quarta vertebra cerebrale l'orribile verbo "USA") che non
> sempre rispecchiano la vera intenzione del giocatore.
e invece, per quanto anche io odi "usa" così com'è (un verbo per
risolvere gli enigmi sena averne capito la soluzione), includerei un
"usa con" o "associa" o simili come "pre-verbi". per spiegarmi (prendo
dalla memoria un esempio in qualche vecchissimo post, penso di
r.a.i.f.): "usa spada + troll" potrebbe essere ambiguo. sebbene nel 98%
dei casi significhi "ammazza il troll con la spada", potrebbe anche
essere "rifai il taglio di capelli al troll usando la spada come
rasoio" o "investi il troll del titolo di cavaliere" (battendogli la
spada sulle spalle) e tutto dipende dall'avventura. l'uso (scusa il
gioco di parole) di "usa spada + troll", quindi, potebbe far apparire
un secondo menu (di secondo livello, diciamo) con varie azioni
disponibili per la combinazione troll + spada. certo, prendendo in
considerazione cloak of darkness, posso anche sfruttare il verbo
generico "usa cappotto + appendiabiti" e dare per scontato che ce lo si
voglia appendere!! questo sistema di menu nascosti aiuta ulteriormente
a non "far vedere tutto e subito" che potrebbe rovinare il gioco. in
return of zork c'era un fiore (o una piantina, non ricordo). lo si
poteva solo cogliere. usandoci sopra il coltello, si poteva recidere,
scavare per prenderla con tutte le radici eccetera...
> Inoltre una lista ridotta porta il problema degli enigmi risolti per
> esaustione, ovvero provando tutte le azioni e tutte le combinazioni (un
> classico delle A.G.)
in realtà questo si presenta sia con liste lingue che con liste
contestuali, e, purtroppo, certe volte il "brute forcing" è possibile
anche con le if tradizionali, sebbene sia più lungo.
presumo, comunque, che un sistema come quello a cui sto pensando debba
avere un mondo mediamente più complesso, con più cose da provare,
abbinare, esplorare, per evitare di avere giochi risolvibili di 15
minuti. per quanto ho visto ora, comunque, è possibile creare e
espandere un mondo molto rapidamente.
> Mi viene in mente mentre scrivo una soluzione ibrida: dividiamo gli
> oggetti per categoria (png, uscite, oggetti grandi/statici, oggetti
> piccoli/trasportabili, etc.etc.) e usiamo una lista diversa per ogni
> categoria...
in realtà, più vado avanti a leggere, scrivere, pensare e sviluppare
e più la soluzione dei menu contestuali mi pare ottima. per quanto
molti oggetti siano "prendibili" o "posabili", ci sono moltissimi
oggetti splendidi da caratterizzare. prendi un televisore: ci si
possono fare molte cose e implementarlo in una if, anche se non
complicatissimo, richiede il comunicare al giocatore come usarlo, visto
che non è la classica leva da tirare, il buco da riempire, la palla da
lanciare. una volta acceso, si possono cambiare i canali, mettere un
dvd, consultare il televideo... pensalo in una if senza menu.. ci vuole
qualcosa che spezzi la mimesi tipo "puoi usare 'cambia canale <numero>'
o 'usa televideo <pagina>' eccetera o prevedere i mille modi in cui il
giocatore può provare a compiere queste azioni. un menu contestuale
può semplicemente contenere i verbi che si vogliono..
> Btw, come pensavi di gestire, nelle due soluzioni, le combinazioni di
> oggetti con altri oggetti (es. COLPISCI IL VASO MING CON IL RANDELLO)?
appunto.. usa / abbina + eventuale sub-menu per le varie azioni fra i
due oggetti!
l'ho già implementato in questo modo: la selezione di "usa" dal menu
abilita un altro menu a tendina contenente gli oggetti presenti
nell'inventario + quelli nella stanza (gli oggetti "in scope", per
intenderci) per renderli associabili.
A queto punto, però, mi chiedo se non sarebbe il caso, per la stessa
"onestà ed eleganza" di cui sopra, di non rendere disponbili solo gli
oggetti con i quali è effettivamente possibile associare l'oggetto in
discussione..
> Bon, per ora basta cosi'... continuo poi.
> bye
a presto!


title: liste di verbi limitate

author: loscimmiotto

text:
pista...@gmail.com
 ha scritto:
> salve, sono troy mcclure, forse vi ricorderete di me per discussioni
> come "if in php".
io sono un po' un visionario (dicesi visionario uno che dice come fare
le cose in maniera infattibile e poi non le fa), devo però dire che
questo tuo metodo non mi fa impazzire, mi sembra un compromesso non
molto originale (una cosa del genere è ad esempio già presente nel
client di jeeneon per neonecronomicon, vedi
http://img515.imageshack.us/my.php?image=jneon7jl.jpg
 ).
allora potresti pensare qualcosa di più interessante, che si avvicina
per alcuni aspetti ad idra, ovvero presentare un testo narrativo in cui
vi siano elementi attivi e combinabili tra loro solo via mouse, abolendo
del tutto verbi e verbetti. ad esempio "sei davanti ad una fontana che
spruzza acqua, un gatto riposa sul selciato", le parole in evidenza sno
gatto e fontana, tu clicci su gatto e lo trascini su fontana e si attiva
l'azione di prendere il gatto di lanciarlo nella fontana.
il problema del 'ma io volevo lavare il gatto e non buttarlo nella
fontana' è secondario, sia perché per il gatto l'acqua fa schifo uguale,
sia e soprattutto perché *comunque* le azioni fattibili in una at sono
limitate a quelle preorganizzate dal programmatore: fornire un 'non
puoi' e non presentare neppure la possibilità di fare una azione ai fini
della narrazione pari sono.
una evoluzione di idra è possibile secondo me in questa direzione,
ovvero una maggiore permeabilità del testo narrativo via mouse, ma
inserire menù a tendina nel testo banalizzando i comandi tipici delle at
non mi pare questa grande invenzione.
ultima notazione a margine: vi prego programmatori se programmate un
motore per narrazioni interattive, fatele in maniera che un *narratore*
possa usarle, non pensatele per un altro programmatore.
f.
--
http://loscimmiotto.splinder.com/


title: liste di verbi limitate

author: Pistacchio

text:
On Sat, 26 Nov 2005 10:04:12 +0100, loscimmiotto
<"fabriziovenerandi"@
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
>
wrote:
>
pista...@gmail.com
 ha scritto:
>> salve, sono troy mcclure, forse vi ricorderete di me per discussioni
>> come "if in php".
>
>
>io sono un po' un visionario (dicesi visionario uno che dice come fare
>le cose in maniera infattibile e poi non le fa), devo però dire che
>questo tuo metodo non mi fa impazzire, mi sembra un compromesso non
>molto originale (una cosa del genere è ad esempio già presente nel
>client di jeeneon per neonecronomicon, vedi
>
http://img515.imageshack.us/my.php?image=jneon7jl.jpg
 ).
ciao! io non ho mai parlato di originalità, nel mio post parlo anche
di return to zork come fonte di ispirazione, per esempio. non
conoscevo il client jeeneon, ma pare interessante. peccato che sia
dedicato a un solo gioco e che il gioco in questione sia di fatto un
mud. ci darò un'occhiata, comunque, grazie per la segnalazione!
>allora potresti pensare qualcosa di più interessante, che si avvicina
>per alcuni aspetti ad idra, ovvero presentare un testo narrativo in cui
>vi siano elementi attivi e combinabili tra loro solo via mouse, abolendo
>del tutto verbi e verbetti. ad esempio "sei davanti ad una fontana che
>spruzza acqua, un gatto riposa sul selciato", le parole in evidenza sno
>gatto e fontana, tu clicci su gatto e lo trascini su fontana e si attiva
>l'azione di prendere il gatto di lanciarlo nella fontana.
>
>il problema del 'ma io volevo lavare il gatto e non buttarlo nella
>fontana' è secondario, sia perché per il gatto l'acqua fa schifo uguale,
>sia e soprattutto perché *comunque* le azioni fattibili in una at sono
>limitate a quelle preorganizzate dal programmatore: fornire un 'non
>puoi' e non presentare neppure la possibilità di fare una azione ai fini
>della narrazione pari sono.
hmm.. premetto che qui si entra nel campo del personale, ma definire
"più interessante" un sistema in cui ad ogni oggetto corrisponde una
sola azione, e una sola azione a ogni singola coppia di oggetti mi
pare azzardato. io con un gioco del genere mi annoierei dopo tre
minuti, per dire.
le azioni presenti in un'if sono limitate, è vero. quello che si tende
a fare da 30 anni a questa parte è cercare di rendere meglio
l'illusione che non lo siano.
il mio approccio, diverso, al problema della limitatezza è quello di
mettere le carte in tavola del tipo: "con questo oggetto puoi fare le
seguenti cose, se lo abbini puoi fare anche queste altre. se lo porti
in una particolare circostanza, ecco che puoi farne di diverse ancora.
visto che è logico provarlo, prova a fare anche questo, ma ti dirò che
non puoi. magari successivamente sarà possibile farlo". questo è molto
diverso da:  oggetto a = una azione. oggetto a + b = una azione. e
permettimi, sempre secondo me, la seconda opzione è peggiore.
il mio proggetto parte dal tentativi di avere un modo diverso (nè
migliore nè peggiore) di gestire la comunicazione giocatore / gioco e
porta alla necessità / virtù di sviluppare quindi prodotti un po'
diversi che si adattino alla nuova interfaccia.
un gioco in cui il programmatore ha deciso per me che gatto + fontana
= lancia gatto nella fontana è a mio avviso non diverso, ma peggiore.
la cosa più grave è che il gioco risulta intrinsecamente povero di
possibilità. immagina che io voglia implementare un sistema ci karma
nel gioco che è più o meno positivo a seconda delle azioni che compio
(non so, un gioco che alla fine deciderà se sono destinato all'inferno
o al paradiso, per esempio). a un certo punto trovo la descrizione:
"sei davanti ad una fontana che spruzza acqua, un gatto riposa sul
selciato". posso dar da bere al gatto (fontana + gatto) e guadagnare 2
punti karma positivo, annegare il gatto (gatto + fontana) e guadagnare
2 punti karma negativo, lanciare il gatto nell'acqua e vedere che
succede (gatto più fontana) e scoprire che ho ritrovato il leggendario
gatto di cristo che cammina sulle acque (10 punti karma positivo),
lavare il gatto nella fontana (gatto + fontana) e scoprire che non ci
riesco, lavare il gatto con un po' d'acqua presa dalla fontana
(fontana + gatto) e in questo modo riuscirci. tutto questo secondo il
tuo sistema sarebbe impossibile. sono alla mercè della volontà del
programmatore, senza neanche, male che vada, l'illusione di poter fare
quello che voglio quando non è così tramite messaggi come "il gatto
non è assetato" e "il gatto non vuole lavarsi".
la differenza fra "azioni limitate" "UNA azione decisa in partenza dal
programmatore" penso sia abissale.
>una evoluzione di idra è possibile secondo me in questa direzione,
>ovvero una maggiore permeabilità del testo narrativo via mouse, ma
>inserire menù a tendina nel testo banalizzando i comandi tipici delle at
>non mi pare questa grande invenzione.
secondo il tuo sistema, sempre secondo me, non banalizzi i comandi
tipico della at, che può essere grave, ma banalizzi il gioco, che è
anche peggio.
>ultima notazione a margine: vi prego programmatori se programmate un
>motore per narrazioni interattive, fatele in maniera che un *narratore*
>possa usarle, non pensatele per un altro programmatore.
su questo punto, e con una tesi simile alla tua, discussi a lungo
sulla controparte inglese di questo newsgroup. ci sono strumenti di
sviluppo, come alan o adrift, che hanno un approccio più semplice alla
programmazione di altri come inform o tads. che il linguaggio sia
solamente un mezzo e che il fine è una bella storia, ne sono convinto.
che in giro ci siano più bravi programmatori che bravi narratori e che
questo risulti in at con puzzle spettacolarmente programmati inseriti
in mondi grigi, poco interessanti e mal descritti è anche probabile
(non lo so, non ho fatto indagini statistiche).
ma purtroppo l'avventura testuale è un hobby ibrido: programmazione +
scrittura. chi è interessato solo alla scrittura può scrivere un
libro, chi è interessato solo alla programmazione può buttarsi su uno
sparatutto. l'at è un mezzo complesso, ma questo è il suo fascino, per
la produzione del quale devono necessariamente concorrere più abilità.
questo dovrebbe essere uno stimolo a migliorarsi come scrittori e come
programmatori, ma difficilmente vedo altre vie.
gu


title: liste di verbi limitate

author: Enrico Colombini

text:
loscimmiotto wrote:
> ultima notazione a margine: vi prego programmatori se programmate un
> motore per narrazioni interattive, fatele in maniera che un *narratore*
> possa usarle, non pensatele per un altro programmatore.
Ah, ecco perche' mi fischiavano le orecchie :-)
Parole sante, bisognerebbe frustarli tutti (io pero' purtroppo oggi ho
un altro impegno)
   .Erix.


title: liste di verbi limitate

text:
Pistacchio ha scritto:
> dedicato a un solo gioco e che il gioco in questione sia di fatto un
> mud. ci darò un'occhiata, comunque, grazie per la segnalazione!
non infierire...
> le azioni presenti in un'if sono limitate, è vero. quello che si tende
(...)
> la differenza fra "azioni limitate" "UNA azione decisa in partenza dal
> programmatore" penso sia abissale.
come dicevi si entra nel campo del personale. dopo le mie esperienze
passate e dopo aver tentato in quarantena (che non ho finito) una
iperverbizzazione del rapporto tra giocatore ed oggetti, mi sono reso
conto che -come narratore- preferisco mostrare al giocatore un testo che
dinamicamente mostra diverse vie di svolgimento, piuttosto che impegnare
risorse a scrivere decine di frasi narrativamente congrue per azioni
inutili ai fini della storia o inverosimili. vedi in coda al presente
messaggio la quantità di roba che secondo me era necessaria per dare una
buona idea di rapporto tra personaggio e una coppia divani: ma
programmare una interactive fiction di questo genere è uno sforzo enorme
che non credo verrebbe neppure ricompensato.
dopo quarantena ho deciso di perseguire il fine opposto e ci provo con
inferno e idra, se devo impiegare sforzo 'narrativo' per una storia
preferisco che sia fruibile dal lettore in maniera più immediata e
funzionale.
questo vuol dire 'azioni limitate'? forse, ma quante? una normale if ha
poi uno schema narrativo lineare e difficilmente esistono svolgimenti
paralleli ad esempio. le 'azioni inutili limitate' valgono meno o più di
una 'storia limitata'?
> ma purtroppo l'avventura testuale è un hobby ibrido: programmazione +
> scrittura. chi è interessato solo alla scrittura può scrivere un
> libro, chi è interessato solo alla programmazione può buttarsi su uno
> sparatutto. l'at è un mezzo complesso, ma questo è il suo fascino, per
> la produzione del quale devono necessariamente concorrere più abilità.
> questo dovrebbe essere uno stimolo a migliorarsi come scrittori e come
> programmatori, ma difficilmente vedo altre vie.
io credo che sia piuttosto un retaggio. è come se obbligassi uno
scrittore ad usare latex invece che un word processor, credo che
esistesse un equivalente di un word processor per fare racconti
interattivi ci sarebbero in giro prodotti più numerosi e
qualititativamente diversificati.
f.
APPENDICE: relazioni tra personaggio e due divani
***
#3,\Jacob osservò i due divanetti posti all'interno della sala. Si
trattava di due piccoli divanetti, apparentemente identici, ma in realtà
speculari. Il divanetto rosso, infatti, era privo di uno dei due
braccioli, mentre a quello verde mancava l'altro. Jacob ricordò come
quei due brutti divanetti venissero dalla famiglia di elletra e come lei
li tenesse in grande considerazione, benché, a ben vedere, non si
trattasse che di due pezzi di scarto della metà del secolo scorso. Ma,
anche Jacob aveva ricordi particolari legati a quei due piccoli divani.
Era su quelli che per la prima volta aveva masturbato Elettra, quando
era ancora una ragazzina, e dove avevano provato i primi rapporti di
sesso. Ancora una rabbia profonda lo prendeva al ricordo dei due
divanetti che, sotto il muoversi dei corpi, si allontanavano l'uno
dall'altro, costringendo a frequenti interruzioni quei maldestri
tentativi di venirsi addosso.\\
#4,\Jacob osservò con attenzione i due divanetti presenti nella sala.
Quello rosso era posto tra l'ingresso dello studio e quello della
cucina. Quello verde era invece nell'angolo, di fronte alla libreria.\\
#5,\All'improvviso a Jacob venne voglia di afferrare uno dei due
divanetti, ma rimase immobile senza sapere verso quale rivolgersi. \\
#6,\Sfinito Jacob si avvicinò ai due divanetti per sedersi, per
riposarsi un attimo. Ma erano troppo distanti per potersi sdraiare in
entrambi, doveva sedersi in quello verde o quello rosso. \\
#7,\Jacob, a fatica, si mise in ginocchio e cercò di guardare sotto i
due bassi divanetti. Ma non riusciva a vedere che il nero, l'oscurità di
spazi inutilizzati.\\
#8,\"Devo togliere questi due divanetti", disse tra sé e sé il valente
Jacob, osservandoli da lontano.
Si mosse verso di loro con l'intenzione di spostarli. Rimase però
incerto a fissarli senza sapere con quale cominciare.\\
#9,\Jacob desiderò alzare i due divanetti, di scoprire cosa fosse
nascosto sotto il loro essere collocati, di occupare uno spazio
geometrico. 'A volte' pensava, le cose offrono il fianco quando meno ci
si aspetterebbe. A tratti, quel giorno, ritornavano ricordi improvvisi,
senza nessun legame: si vedeva con Elettra arrivare in traghetto a
Zadir, prima della fine del mondo, e nel primo mattino prendere un caffè
in una bar talmente distante. Ricordi come questi apparivano e
scomparivano, come se qualcosa li muovesse sconsideratamente.\Comunque
se voleva alzare un divanetto doveva decidere quale dei due.\\
#10,\Unire i due divani, certo, pensava il buon Jacob. Ma poi si ricordò
che aveva già fatto quella unione e che Elettra non era stata per nulla
contenta, ah questo no. I divanetti uniti prendevano tutta una parete e
davano ad Elettra l'impressione di un lungo pesce morto, un luccio di
mare, se mai sono esistiti lucci di mare, qualcosa di morto comunque, di
abbandonato.\No, no, pensò Jacob scuotendo la testa, unire i divanetti
non era certo una buona idea.\\
#11,\Gli venne d'improvviso la curiosità di vedere cosa fosse nascosto
sotto il divano. 'Forse un drago', pensava, o uno di quei mostri
antidiluviani che tanto erano cari ad e Elettra. Rimase così, ad
inseguire le sue immaginazioni, senza neppure saper decidere se chinarsi
sotto il primo divanetto o il secondo.\\
#12,\Jacob si pose di fronte ai due divanetti, quello rosso e quello
verde, senza sapere verso quale rivolgere la sua attenzione.\\
#13,\Jacob sentiva il desiderio di prendere, di possedere uno dei
divanetti, ma quale?\\
#14,\Jacob sentì il desiderio di sdraiarsi sopra uno dei due divanetti,
dimenticare tutto, Elettra, la quarantena e il Comitato, aprire la
boccuccia ed aspirare un latte immaginario, uno sperma dolce che
galleggiava nell'aria, privo di atmosfera. Ma restava in piedi,
ghiacciato, senza sapere verso quale divanetto muoversi.\\
#15,\Jacob si avvicinò ad uno dei due divanetti, pronto a spostarlo,
quando osservò l'altro che giaceva immobile nell'angolo, come se lo
stesse fissando. Si avvicinò all'altro e di nuovo il primo gettò
l'invisibile sguardo su di lui. Rimase così incerto, senza sapere quale
dei due divani spostare.\\
#16,\Alzarli voleva Jocob, quei divani, sollevarli nel profondo della
memoria forse e si ricordò, senza nessuna motivazione di una volta che
da bimbo, si morse un labbro ed uscì stilla. Passandosi una mano sul
volto Jacob mise a fuoco quei due divanetti, sempre immobili come mosche
morte.\\
#17,\D'improvviso Jacob si mise a girare per la sala, come se avesse
perso qualcosa, le mani in avanti, gli occhi quasi socchiusi, poi si
fermò di fronte ai due divani che mai si erano mossi di là.\\
#18,\Si avvicinò ai due divani, per salirci sopra, cosa mai va a pensare
l'uomo. Ma i divani erano due e lui uno solo.\\
#19,\Jacob si diresse verso i divanetti. Quando fu presso di loro,
rimase dubbioso se andare verso quello verde, o quello rosso.\\
#50,\Jacob si avvicinò al piccolo divanetto che era collocato tra i due
ingressi, dello studio e della cucina. Si trattava di un dono di
famiglia di Elettra, un brutto pezzo d'arredamento della metà del secolo
scorso. Lui più volte aveva chiesto ad Elettra di buttarlo per prendere
qualcosa di più moderno, ma lei aveva sempre rimandato, dicendo che si
trattava di un ricordo. Poi era stato troppo tardi, non si poteva più
comperare nulla. Il divanetto era basso, praticamente poggiava sul
pavimento. Aveva i braccioli soltanto da una parte, perché faceva coppia
con il secondo divanetto, quello verde, che aveva anch'esso un solo
bracciolo, dalla parte opposta. Pur essendo i due divanetti identici,
Elettra aveva voluto fasciare i cuscini e la fodera con due stoffe
diverse: quella che stava di fronte a Jacob, rossa, e l'altra, verde
scuro.\\
#51,\Jacob tornò ad osservare il piccolo divano posto tra i due
ingressi, dello studio e della cucina. Era un piccolo divanetto, molto
basso, che faceva coppia con quello che stava nel'angolo, vicino alla
libreria. Entrambi avevano infatti un solo bracciolo, come se fossero
stati pensati per essere messi l'uno accanto all'altro per formare un
divano. Elettra però aveva deciso di separarli, anni prima, e li aveva
rifoderati con due stoffe di colore differente. Jacob posò lo sguardo
sui vecchi cuscini rossi che gli stavano di fronte, gli stessi, lisi,
che conosceva da tempo; identici, nella forma, a quelli verdi dell'altro
divanetto.\\
#52,\Jacob afferrò con le mani il divanetto e contrasse le dita per
prenderlo con sé. Con un gesto di fastidio lasciò la presa: era troppo
pesante per essere trasportato. Quel genere di azioni lo stancavano molto.\\
#53,\Jacob, con un sospiro di sollievo, si buttò sul divanetto, ma
subito provò un dolore fastidioso alle anche, nel punto delle ossa.
Aveva l'impressione di cadere e tutta la stanza che gli stava di fronte
gli sembrava alzarsi, innalzarsi fino a divenire un punto infinitesimale
della sua produzione in codice. Ma, nello stesso tempo, tutto restava
identico a prima, nello stesso silenzio ininterrotto. Per questo non era
bene sedersi, per questo quelli del comitato avevano tolto tutte le
sedie dalla casa.\\
#54,\Jacob si avvicinò al divano ed afferrandolo con le mani fece per
spostarlo. La sua forza sembrava percorrere il corpo per scaricarsi
nelle gambe e poi nel pavimento, dove trovava riposo. Con molta fatica
scostò il divanetto dal muro, osservò l'intonaco bianco, identico al
resto della casa, e con uguale sforzo, lo ricollocò nella posizione in
cui Elettra desiderava fosse posto.\\
#55,\Jacob si guardò attorno in cerca del divano. Appena lo vide, si
avvicino senza fretta.\\
#56,\Jabob salì sul divano e si mise a vedere le cose da quella
prospettiva. L'ingresso della camera da letto gli appariva ora l'antro,
la bocca sdentata di una fornace il cui corpo da bruciare, da riportare
allo stato carnale fosse il suo. Stare sul morbido dava fastidio a
Jacob, e così tornò sul solido pavimento\\.
#60,\Jacob si mosse verso il divanetto posto nell'angolo, di fronte alla
libreria. Era un piccolo divanetto, un dono di famiglia di Elettra, di
nessun valore ed anche abbastanza scomodo. Aveva chiesto ad Elettra di
buttarlo, assieme a quello rosso, per prendere qualcosa di più comodo,
ma  lei aveva sempre negato, adducendo al fatto che si trattava di un
ricordo. Poi era stato troppo tardi, adesso non serviva a niente. Il
divanetto era basso, quasi poggiava sul pavimento. Aveva i braccioli
soltanto da una parte, perché faceva coppia con il secondo divanetto,
quello rosso, che aveva anch'esso un solo bracciolo, dalla parte
opposta. Nonostante fossero del tutto uguali, Elettra aveva deciso di
fasciare cuscini e fodera con due stoffe diverse: quella che stava di
fronte a Jacob, verde, e l'altra, rossastra.\\
#61,\Jacob si avvicinò nuovamente al piccolo divano posto di fronte alla
libreria. Era un piccolo divanetto, molto basso, che faceva coppia con
quello che stava tra i due ingressi, dello studio e della cucina.
Entrambi avevano infatti un solo bracciolo, come se fossero stati
pensati per essere messi l'uno accanto all'altro per formare un divano,
probabilmente ad angolo. Elettra però aveva deciso di separarli, anni
prima, e li aveva rifoderati con due stoffe di colore differente. Jacob
posò lo sguardo sui molli cuscini verdi che gli stavano di fronte, gli
stessi, lisi, che conosceva da tempo; identici, nella forma, a quelli
rossi dell'altro divanetto.\\
#62,\Andò verso il divanetto credendo che vi fosse qualcosa che a lui
interessava molto, qualcosa di essenziale, ma tutto era privo di valore,
il divanetto un semplice divanetto e niente di più.\Afferrò con le mani
il divanetto e contrasse le dita per prenderlo con sé. Con un gesto di
fastidio lasciò la presa: era troppo pesante per essere trasportato.
Quel genere di azioni lo stancavano molto.\\
#63,\Jacob, con un sospiro di sollievo, si buttò sul divanetto, ma
subito provò un dolore fastidioso alle anche, nel punto delle ossa.
Aveva l'impressione di cadere e tutta la stanza che gli stava di fronte
sembrava alzarsi, innalzarsi fino a divenire un punto infinitesimale
della sua produzione in codice. Ma, nello stesso tempo, tutto restava
identico a prima, nello stesso silenzio ininterrotto. Per questo non era
bene sedersi, per questo quelli del comitato avevano tolto tutte le
sedie dalla casa.\\
#64,\Jacob si avvicinò al divano ed afferrandolo con le mani fece per
spostarlo. La sua forza sembrava percorrere il corpo per scaricarsi
nelle gambe e poi nel pavimento, dove trovava riposo. Con molta fatica
scostò il divanetto dal muro, osservò l'intonaco bianco, identico al
resto della casa, e con uguale sforzo, lo ricollocò nella posizione in
cui Elettra desiderava fosse posto.\\
#65,\Jacob si guardò attorno in cerca del divano. Appena lo vide, si
avvicino senza fretta.\\
#66,\Jabob si sedette sul divano e si mise a vedere le cose da quella
prospettiva. Di fronte a lui la liberia, sigillata, mostrava le
rientranze inutili, i fori della privazione. Vicino alla libreria,
l'ingresso della camera da letto gli appariva l'oscuro passaggio verso
qualcosa che gli avrebbe sottratto quel poco di serenità che a fatica
custodiva dentro di sé. Stare seduto portava a Jocob una sorta di breve
dolore, ed era anche per quel motivo che il Comitato aveva fatto
togliere tutte le sedie dalla casa. \\
#67,\Seduto sul divano, Jacob provò il desiderio di sedersi sul divano.
Si trovava contemporaneamente nella condizione in cui voleva essere e in
quella in cui si trovava isoddisfatto del suo stesso desiderio inappagato.\\
#68,\Decise di guardare sotto i cuscini. In verità Jacob aveva un
terrore delle cose nascoste, non gli piaceva mettere le mani in posti
sconosciuti. "Magari se fossi seduto sul divano sarebbe più semplice"
disse tra sé e sé, non si tratterebbe di una scoperta, ma quasi di una
azione continuata, sono andato sui cuscini e poi lentamente sono
scivolato tra cuscino e cuscino, mi sono schiantato, diciamo così sul
divano, ecco che razza di pensieri aveva Jacob.\\
#69,\Jacob guardò sotto i cuscini, lentamente, con timore, quasi che
avesse paura di trovarvi qualche bestia, qualche insetto addormentato. O
anche un topo, chi sa mai che sotto i cuscini non riposino i topi.
Invece trovò un un libretto. Lo prese in mano con curiosità chiedendosi
chi cavolo l'avesse messo in quel posto.\\
#70,\Jacob guardò sotto i cuscini, lentamente, con timore, quasi che
avesse paura di trovarvi qualche sporcizia, qualche bestia addormentato.
Magari un ratto, chi sa mai che sotto i cuscini non riposino i ratti.
Invece c'era soltanto la tela del divano.\\
#71,\Jacob guardò nuovamente sotto i cuscini, lentamente, con timore.
Gli parve di vedere, per un attimo, denti che baluginavano, o zampe che
si ritraevano verso il buio, ma quando il cuscino fu ben alzato, c'era
solo la nudità del divano.\\
#72,\Si mise ad osservare i cuscini dei due divanetti. Erano identici,
cambiava soltanto la tinta, ora rossa, ora verde. Spesso si era seduto
su di loro, provando un certo piacere, anche se, alla lunga, gli
sembrava che si schiacciassero, che sprofondassero perdendo la loro
forma originaria, e provocandogli un tenero dolore all'altezza della
spina dorsale.\\
#73,\Gettò il suo sguardo sui divanetti e ancora una volta si mise ad
osservarne i cuscini. Erano sempre gli stessi. Uno grosso sotto, e tre
piccoli messi sul lato.\\
#74,\Mosse la testa per vedere meglio i cuscini su cui sedeva. Molli,
coperti da quella stoffa grezza che Elettra aveva comprato chissà dove e
che aveva lei stessa tinto sporcando per settimane il bucato della
lavatrice.\\
#75,\Con la coda dell'occhio fissò i cuscini su cui sedeva. Erano sempre
gli stessi, ruvidi e scomodi.\\
#76,\Con una mano afferrò un cuscino e lo tirò a sé, ferendosi il polso.
Solo in quel momento si ricordò che la parte terminale dei cuscini era
cucita alla base del divano, per evitare che cadessero o si spostassero.\\
#77,\Decise di prendere uno dei cuscini. Ma quell'azione, da in piedi,
sembrava fiaccarlo, nausearlo. Si sentiva già stanco per quel gesto
tanto risoluto; e così decise che lo avrebbe fatto, certo, ma una volta
seduto sul divano.\\
#78,\Jacob decide di spostare uno dei cuscini del divano. Ma il solo
pensare di mettersi lì, tirare, lasciare, oggetti molli... sentiva come
il ruvido sulle dita, nell'interno delle dita, un sapore quasi delle
unghie che s'infilavano nella stoffa, che frizionavano, che graffiavano
e -stupito- si ritrovò a contrarre e rilasciare le dita. Fiaccato decise
che lo avrebbe spostato, certo, ma una volta che si fosse seduto.\\
#79,\Prese uno dei cuscini e fece per spostarlo quando sentì che il
cuscino resisteva e rimaneva fermo. Si ricordò allora che la parte in
fondo era cucita al divano, perché non cadessero per terra. Lasciò le
mani e si mise ad osservare il centro della stanza, senza vedere niente.\\
#87,\Prese il bordo di uno dei cuscini per alzarlo, quando sentì che il
cuscino resisteva e rimaneva fermo. Si ricordò allora che la parte in
fondo era cucita al divano, perché non cadesse per terra. Si poteva
alzarli di quel tanto per poter vedere cosa c'era sotto e per poterli
pulire da quella dannata sporcizia che da sempre si riuniva sotto i
cuscini per festeggiare la propria sopravvivenza di mesi ed anni.\\
#88,\Si guardò attorno per cercare dove fossero finiti i cuscini dei
divani, poi s'accorse che erano sempre sui divani. "Che sciocco che
sono" disse sorridendo.\\
--
http://loscimmiotto.splinder.com/


title: liste di verbi limitate

text:
On Sat, 26 Nov 2005 11:50:48 +0100, loscimmiotto
<"fabriziovenerandi"@
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
>
wrote:
>> le azioni presenti in un'if sono limitate, è vero. quello che si tende
>(...)
>> la differenza fra "azioni limitate" "UNA azione decisa in partenza dal
>> programmatore" penso sia abissale.
>
>come dicevi si entra nel campo del personale. dopo le mie esperienze
>passate e dopo aver tentato in quarantena
non so cosa sia ma potrebbe essere interessante. hai un link?
>(che non ho finito) una
>iperverbizzazione del rapporto tra giocatore ed oggetti, mi sono reso
>conto che -come narratore- preferisco mostrare al giocatore un testo che
>dinamicamente mostra diverse vie di svolgimento, piuttosto che impegnare
>risorse a scrivere decine di frasi narrativamente congrue per azioni
>inutili ai fini della storia o inverosimili. vedi in coda al presente
>messaggio la quantità di roba che secondo me era necessaria per dare una
>buona idea di rapporto tra personaggio e una coppia divani: ma
>programmare una interactive fiction di questo genere è uno sforzo enorme
>che non credo verrebbe neppure ricompensato.
invece a me pare una cosa molto interessante, ho letto con piacere
l'appendice, è scritta bene e aggiunge un'incredibile profondità al
personaggio (di cui non so nulla). bello il modo in cui un personaggio
non presente (elettra) diventa una presenza tangibile e quasi
opprimente tramite i ricordi, le sensazioni.. almeno, questa è
l'impressione che ha dato a me la lettura di una cosa ovviamente
decontestualizzata!
per quanto riguarda la ricompensa.. penso che un'at che esplori in
questo modo l'emotività di un personaggio possa ricevere grandi elogi.
se parli di altro tipo di ricompensa.. beh, dubito che al momento si
possa diventare ricchi con una qualunque at ^__-
>dopo quarantena ho deciso di perseguire il fine opposto e ci provo con
>inferno e idra, se devo impiegare sforzo 'narrativo' per una storia
>preferisco che sia fruibile dal lettore in maniera più immediata e
>funzionale.
>questo vuol dire 'azioni limitate'? forse, ma quante? una normale if ha
>poi uno schema narrativo lineare e difficilmente esistono svolgimenti
>paralleli ad esempio. le 'azioni inutili limitate' valgono meno o più di
>una 'storia limitata'?
quello che dici è vero, ma temo che stiamo parlando di cose diverse.
l'at, per sua natura, tenta di ricreare un mondo in cui è massimizzata
l'interazione. per quello paradigmi come "tutto quello che è presente
nel testo dovrebbe essere un oggetto con cui poter interagire". in
realtà è quello che in molti, me compreso, si aspettano da una buona
if. come base, poi una bella storia, enigmi interessanti ecc.. è un
mondo virtuale nel quale calarsi.
quello di cui tu parli è ancora una volta molto più simile al libro
game. non so quale sia la parentela fra at e cyoa, probabilmente anche
stretta, ma di certo non sono la stessa identità. stiamo parlando di
progetti diversi che incidentalmente usano mezzi simili (javascript,
il browser), ma rimangono cose differente e penso anche difficilmente
comparabili.
>> ma purtroppo l'avventura testuale è un hobby ibrido: programmazione +
>> scrittura. chi è interessato solo alla scrittura può scrivere un
>> libro, chi è interessato solo alla programmazione può buttarsi su uno
>> sparatutto. l'at è un mezzo complesso, ma questo è il suo fascino, per
>> la produzione del quale devono necessariamente concorrere più abilità.
>> questo dovrebbe essere uno stimolo a migliorarsi come scrittori e come
>> programmatori, ma difficilmente vedo altre vie.
>
>
>io credo che sia piuttosto un retaggio. è come se obbligassi uno
>scrittore ad usare latex invece che un word processor, credo che
>esistesse un equivalente di un word processor per fare racconti
>interattivi ci sarebbero in giro prodotti più numerosi e
>qualititativamente diversificati.
credo che se ci fosse io ne starei alla larga. mi piace programmare,
mi da' gusto debuggare una parte difficile per mezz'ora, trovare
l'errore e scoprire che poi funziona come volevo. fare if significa
scrivere e programmare, se non ti piace una delle due cose forse non
ti piace davvero sviluppare if. o in alternativa, se propendi verso la
scrittura, datti alle cyoa, ma mi pare che sia infatti quello che stai
facendo.
l'esempio del word dubito che sia calzate. se voglio usare il computer
come macchina per scrivere tutta la mia attenzione deve essere
concentrata su quello che scrivo, più è difficile il programma, più il
computer sta fallendo nel darmi quello di cui ho bisogno. tenendo la
metafora del word processor, è come se tu ne volessi uno che per
semplificare il compito di battere sulla tastiera elimasse vocali , la
t e la s. avresti un programma monco. e creare if senza programmare è
fare un prodotto monco.
la programmazione ai non programmatori è stata tentata più volte, si
chiamano rad, rapid application development. nel mondo dei
videogiochi, anche, ce ne sono moltissimi, vecchio klick & play, al
gamemaker. certo, puoi farci dei giochi. con un rad puoi fare un
calcolatrice e anche un programma che si interfaccia in automatico a
un database, ma fatto sta che se vuoi programmarti il word o quake v,
non ci sono scorciatoie: algoritmi, loop, c.. le solite cose.
persino strumenti di sviluppo complessi come adrift (che a me piace
molto) che tentano di essere user-friendly tramite un'interfaccia a
finestre eccetera, nelle comp producono troppo spesso risultati
definiti dai recensori come "buoni ma si sentono le limitazioni legate
allo strumento di sviluppo".
se percorri a ritroso la storia della programmazione e dei calcolatori
troverai, nelle primissime pagine, la parola assembler. se torni ai
giorni nostri trovi i linguaggi di alto e altissimo livello con una
sintassi similissima all'inglese, più facili da scrivere e senza righe
incomprensibili come:
      mov    ax,@data
      mov    ds,ax
      mov    ah,9
      mov    dx,offset hello_message
      int    21h
      mov    ax,4C00h
eppure tutt'oggi spesso nello sviluppo di applicazioni complesse ci
sono punti nodali in cui si continua a ricorrere, a decine di anni di
distanza, all'assembler per ottimizzare il codice.
purtroppo ottimizzare potenza, duttilità e semplicità, in un modo o
nell'altro, è davvero difficile da ottenere. visto che questa
discussione sembra il duplicato di una che tenni io (proponendo la tua
visione dei fatti) ti invio il link. purtroppo mi sono ricreduto.
http://groups.google.it/group/rec.arts.int-fiction/browse_frm/thread/e1aefe6e1c8022dd/fad17fbd3d54adf6?lnk=st&q=pistacchio%40gmail.com&rnum=1&hl=it#fad17fbd3d54adf6


title: liste di verbi limitate

text:
On Sat, 26 Nov 2005 13:30:16 +0100, Pistacchio
<pista...@NOSPAMgmail.com> wrote:
>
>
http://groups.google.it/group/rec.arts.int-fiction/browse_frm/thread/e1aefe6e1c8022dd/fad17fbd3d54adf6?lnk=st&q=pistacchio%40gmail.com&rnum=1&hl=it#fad17fbd3d54adf6
ecco, dalla discussione che sto rileggendo, riporto una parte che mi
pare esprima bene quello che al momento penso io (e calcola che è
presa da una risposta  a un mio post! eh eh)
***
It isn't so much that the complexity of IF serves as a filter (which
it does, of course), but, rather, that IF's complexity is *intrinsic
to
IF*. IF's complexity is *not* something that can be worked around or
evaded. You just *can't* simplify IF; at best, you may be able to
*conceal* it, by delegating however-much of the complexity to the
toolset's code rather than forcing the would-be IF author to confront
that complexity head-on. This is fine as long as the author only wants
to do standard stuff that's built into the code... but what if the
author wants to do something *more*, or even *different*, than is
built
into the code? In that case, the author is screwed. Thus, my assertion
that you *can't* make IF newbie-friendly without side-effects that are
sufficiently bad that you might as well not have bothered.
   All of which said, there are programs like Photoshop, which offer
the user an immensely wide and versatile toolset, but which don't
*force* the user to deal with *all* of that toolset up front. Even the
veriest novice can open up Photoshop and *do stuff* with less than 2
minutes' instruction... but the more you play with Photoshop, the more
tools and options it reveals to you. I'm not sure what the jargon term
for this is -- "progressive revelation", perhaps? -- but it may be
that
"progressive revelation" is a principle around which IF tools can be
built.
***
se non dovessi leggere l'inglese (in soldoni): per avere un'if c'è
bisogni di :"a b c d e f"
se manca una di  queste cose, hai un'if di basso livello. per rendere
lo sviluppo facile quello che puoi fare è lasciar fare al tool, per
esempio "a b c d" e tu fai solo "e f". questo significa anche che più
cose deleghi al linguaggio, meno possibilità di espressione hai tu e
quindi peggiore è l'at che ne risulta.
quello che bisognerebbe fare è avere uno strumento a "strati" come il
photoshop: puoi iniziare a farci qualcosa anche in 2 minuti, ma per
padroneggiarlo ci vuole parecchio tempo, dedizione, conoscenza dei
filtri, di tutti i menu..
alla fine, però, il risultato è sempre quello: se il tuo prodotto
fatto usando il photoshop come fosse il paint viene messo a confronto
con quello da un esperto sfruttando le potenzialità, una tavoletta
grafica ecc, il tuo sarà, senza girarci intorno, più brutto.
ma d'altronde l'inform (prendo l'inform perchè è diffuso e
*apparentemente* è una bestia nera capace di essere dominata solo dai
laureati al mit!) è proprio così. per costruire una stanza non ci
vuole poi molto!!
Object "Cucina"
	with description
		"Una cucina sporca di sangue",
	e_to Salotto,
	has light;
è anche vero che una stanza del genere è poco interessante. come un
disegno fatto con photoshop usandolo come fosse il paint. come un'if
scritta "in modo facile".
ho accusato chi mi faceva gli stessi discorsi che faccio io ora di
elitismo. sono passato dall'altra parte della barricata, è ironico,
no?
vedi, iniziare a suonare la chitarra non è facilissimo, cerchi delle
scorciatoie ma non ce ne sono. le dita continueranno a farti male
finchè non ti sarai fatto i calli. se non sei disposto a farteli passa
al piano.
io capisco che fare il barrè è difficile. e certo, puoi dire "io
voglio suonare la chitarra ma senza barrè". sei libero di farlo, puoi
suonarci un sacco di brani, ma dovrai evitare tutti i brani con un fa,
un do minore eccetera. e ci sarà sempre quello che si è preso il suo
tempo per imparare scale, barrè e farsi dei bei calli che suonerà
meglio di te.
(e spero mi perdoniate la metafora musicale ^__* )


title: liste di verbi limitate

author: Paolo Lucchesi

text:
loscimmiotto wrote:
> allora potresti pensare qualcosa di più interessante, che si avvicina
> per alcuni aspetti ad idra, ovvero presentare un testo narrativo in cui
> vi siano elementi attivi e combinabili tra loro solo via mouse, abolendo
> del tutto verbi e verbetti. ad esempio "sei davanti ad una fontana che
> spruzza acqua, un gatto riposa sul selciato", le parole in evidenza sno
> gatto e fontana, tu clicci su gatto e lo trascini su fontana e si attiva
> l'azione di prendere il gatto di lanciarlo nella fontana.
Tralasciando per un attimo tutti i discorsi relativi all'interfaccia,
questi discorsi cascano a fagiolo per un'idea che mi sta ronzando in
testa da qualche giorno.
Secondo me uno dei limiti di Idra e' non tanto la limitatezza delle
opzioni offerte al giocatore, ma piuttosto quello di non avere un world
model (e' un po' lo stesso problema che hanno M.A.C. e modulo base). In
Idra e' estremamente difficile, per non dire impossibile, gestire delle
relazioni spaziali tra i vari "elementi" della storia, o avere p.n.g.
che si muovono con una certa indipendenza, o avere oggetti che
funzionano piu' o meno nello stesso modo indipendentemente dal contesto
immediato in cui si trovano.
In realta' forse una linea di pensiero piu' proficua per la ricerca di
un sistema piu' "semplice" per l'utente e' non tanto quella di cercare
di ridisegnare in qualche modo le a.t. con parser, ma quella di cercare
di estendere il sistema a ipertesti.
Ovviamente, mi ripeto, il progetto di una a.t. secondo questi canoni
deve essere diverso dal progetto di una a.t. con parser.
> il problema del 'ma io volevo lavare il gatto e non buttarlo nella
> fontana' è secondario
Il problema e' secondario soltanto fino ad un certo punto; si tende a
perdere il concetto secondo cui le azioni del p.g. dovrebbero sempre
riflettere esattamente la volonta' del giocatore (cosa che gia' accade,
ad esempio, nelle a.g.). Ma questo non e' necessariamente un male:
dipende dallo stile che si vuole dare al prodotto che si sta creando.
Faccio un esempio: "Whom the telling changed" utilizza largamente un
parser ad una sola parola, ed e' questa parola a far evolvere la
narrazione in una certa direzione; ma il giocatore non sempre (anzi
quasi mai) puo' prevedere con esattezza la reazione del personaggio al
suo comando di una parola. Questo funziona benissimo nel gioco in
questione, e il giocatore viene efficacemente dalla narrazione. Ma con
tutta probabilita' in un altro gioco, un gioco piu' classico (ad esempio
un mistery), la cosa non funzionerebbe altrettanto bene.
La stessa cosa probabilmente vale per l'"advanced idra"; dipende tutto
dall'effetto che si vuole ottenere, e il gioco deve essere progettato
per esso.
A questo punto possiamo anche accettare la lieve indeterminazione con
cui vengono accettati i comandi del giocatore.
> ultima notazione a margine: vi prego programmatori se programmate un
> motore per narrazioni interattive, fatele in maniera che un *narratore*
> possa usarle, non pensatele per un altro programmatore.
Questo punto meriterebbe una discussione a se stante. E' possibile avere
un sistema che sia semplice da usare anche senza saper quasi nulla di
programmazione e che allo stesso tempo sia sufficientemente potente da
poter offrire i mezzi per realizzare situazioni anche abbastanza complesse?
Forse la soluzione e' in un sistema scalabile. Una realizzazione basata
su template facili da usare, ma con i mezzi per estendere e
personalizzare questi template.
Ma e' mezzanotte passata e i miei neuroni (entrambi) sono ancora in
sciopero.
bye
--
Paolo Lucchesi
email: plucchesiNOSPAM(at)NOSPAMtin(dot)NOSPAMit
homepage:
http://www.paololucchesi.it
"Non viviamo in un mondo perfetto (per fortuna)"


title: liste di verbi limitate

author: hal incandenza

text:
Pistacchio ha scritto:
> non so cosa sia ma potrebbe essere interessante. hai un link?
no, il progetto è al momento congelato.
> per quanto riguarda la ricompensa.. penso che un'at che esplori in
> questo modo l'emotività di un personaggio possa ricevere grandi elogi.
> se parli di altro tipo di ricompensa.. beh, dubito che al momento si
> possa diventare ricchi con una qualunque at ^__-
il dubbio che ponevo all'epoca del congelamento, ma che fuori contesto
vale ancora oggi in generale, vale la pena di scrivere così tanto (e
così bene nel mio caso) dedicandosi ad un media che per sua natura ha
una diffusione limitata e settoriale? un best seller di un esordiente
raggiunge le 6000/7000 copie per una piccola casa editrice, non parlo di
un autore affermato di una grande casa, ecco, quanto vale la pena di
lavorare ad una storia interattiva piuttosto che ad un romanzo o
comunque un progetto libro?
se si parla di un gioco at destinato a qualche centinaio di persone con
una ricerca narrativa limitata e funzionale, d'accordo, ma se si volesse
fare davvero narrativa interattiva forse il parser at non è quello più
indicato per un lavoro a lungo termine.
> quello di cui tu parli è ancora una volta molto più simile al libro
> game. non so quale sia la parentela fra at e cyoa, probabilmente anche
> stretta, ma di certo non sono la stessa identità. stiamo parlando di
> progetti diversi che incidentalmente usano mezzi simili (javascript,
> il browser), ma rimangono cose differente e penso anche difficilmente
> comparabili.
si tratta di mondi paralleli probabilmente.
> persino strumenti di sviluppo complessi come adrift (che a me piace
> molto) che tentano di essere user-friendly tramite un'interfaccia a
> finestre eccetera, nelle comp producono troppo spesso risultati
> definiti dai recensori come "buoni ma si sentono le limitazioni legate
> allo strumento di sviluppo".
è un punto di vista interessante, ma io credo che possano esistere
compromessi: così come posso fare con openoffice una query in mysql
semplicemente tirando delle righine tra le diverse tabelle e senza
conoscere di fatto un solo comando mysql, così credo che sarebbe
possibile avere strumenti per la lettura dinamica che permettano ad uno
scrittore di creare ambienti e storie senza dover da subito scrivere
codice per ogni cosa ci sia da fare.
questo è comunque un punto di vista.
f.


title: liste di verbi limitate

text:
Pistacchio ha scritto:
> quello che bisognerebbe fare è avere uno strumento a "strati" come il
> photoshop: puoi iniziare a farci qualcosa anche in 2 minuti, ma per
> padroneggiarlo ci vuole parecchio tempo, dedizione, conoscenza dei
> filtri, di tutti i menu..
ti ho risosto altrove: ad esempio si potrebbe avere un programma capace
di gestirti l'abcefg, lasciando il d ad un lavoro successivo più complesso.
> Object "Cucina"
> 	with description
> 		"Una cucina sporca di sangue",
> 	e_to Salotto,
> 	has light;
la prima cosa che mi verrebbe da fare vedendo una cosa del genere è come
fare un programma che mi permetta di fare questo codice a partire da un
tool grafico, non certo di impararmi un linguaggio per le if.
> io capisco che fare il barrè è difficile. e certo, puoi dire "io
> voglio suonare la chitarra ma senza barrè". sei libero di farlo, puoi
> suonarci un sacco di brani, ma dovrai evitare tutti i brani con un fa,
> un do minore eccetera. e ci sarà sempre quello che si è preso il suo
> tempo per imparare scale, barrè e farsi dei bei calli che suonerà
> meglio di te.
sinceramente credo che le limitazioni siano spesso e volentieri un bene.
meno strumenti e limitati sono più utili ad un creativo che infiniti
strumenti, è un paradosso.
f/


title: liste di verbi limitate

text:
Paolo Lucchesi ha scritto:
> Ovviamente, mi ripeto, il progetto di una a.t. secondo questi canoni
> deve essere diverso dal progetto di una a.t. con parser.
posso essere d'accordo. peraltro uno dei difetti di idra è che si basa
sul concetto di bivio e ogni cosa diventa bivio e quindi funzione: un
racconto interattivo complesso diventa in poco tempo una lista di
centinaia e centinaia di funzioni messe tutte sullo stesso piano.
> A questo punto possiamo anche accettare la lieve indeterminazione con
> cui vengono accettati i comandi del giocatore.
certo/ dato un motore è il gioco che ci deve nascere dentro e non
l'opposto. lo strumento crea il gioco quanto il creatore, vedi il
paradosso che facevo pocanzi. datemi un prodotto chiuso e vi creerò un
gioco migliore di un prodotto 'aperto' ma mal governato.
> Forse la soluzione e' in un sistema scalabile. Una realizzazione basata
> su template facili da usare, ma con i mezzi per estendere e
> personalizzare questi template.
condivido è quello che scrivevo anche io altrove.
f.


title: liste di verbi limitate

text:
hal incandenza wrote:
> peraltro uno dei difetti di idra è che si basa
> sul concetto di bivio e ogni cosa diventa bivio e quindi funzione:
Piu' esattamente, uno dei difetti di Idra e' che puoi uscire da questa
visione del mondo, ma cio' ti costa trasformarti in un programmatore
(e anche di livello medio-alto). E poi non c'e' l'antidoto per
ridiventare umano.
   .Erix.


title: liste di verbi limitate

text:
On Mon, 28 Nov 2005 15:49:06 +0100, hal incandenza <
i...@tu.no
> wrote:
[snip]
[snip]
[snip]
[snip]
premetto che non voglio sembrare scortese o brusco.
dunque.. io penso che i tuoi punti di vista siano molto interessanti e
sarebbe costruttivo discuterli più a lungo. solo che temo che questo
non sia il luogo più adatto e in questa sede ci scontreremmo senza
arrivare a nessun punto.
voglio dire, critichi le if così come sono, critichi il modo in cui si
sviluppano, critichi gli strumenti di sviluppo e il modo in cui
vengono fatti. non vanno bene le if come sono perchè sono povere dal
punto di vista puramente narrativo. lo strumento per fare qualcosa di
più simile a quello che pensi tu è idra ma è limitato e c'è comunque
troppa programmazione. proponi qualcosa di tuo ed è un mud. affermi
che non vale la pena perder tempo a scrivere if che tanto non te le
legge nessuno e allora tanto vale la pena scrivere un libro. vuoi
programmare if ma senza programmare.. (e sottolineo il verbo
programmare.. i quadri si dipingono, le paste si cucinano, le if si
programmano, oltre che scrivono)
ora, io posso essere d'accordo con te o non condividere le tue idee,
ma questo mi pare un problema secondario in questo contesto. voglio
dire, il linea di principio condivido anche alcune delle tue idee, ma
qui si discute di if, di come programmarle, di come migliorarle. puoi
anche venire a postare che il limite delle if è che si giocano al
computer e non davanti a un tavolo, che non hanno un tabellone, che
non ci sono pedine, che non puoi giocarci con tre amici e che non c'è
mai vicolo corto. la tua sarebbe un'opinione rispettabile come tutte,
ma resta che qui si parla di if, non di monopoli.
solo un appunto personale.
ciao!
[snip]
[snip]
[snip anche l'altro post]
[snip]


title: liste di verbi limitate

text:
Enrico Colombini ha scritto:
> Piu' esattamente, uno dei difetti di Idra e' che puoi uscire da questa
> visione del mondo, ma cio' ti costa trasformarti in un programmatore (e
> anche di livello medio-alto). E poi non c'e' l'antidoto per ridiventare
> umano.
nnnno, non vogliooo
--
http://loscimmiotto.splinder.com/


title: liste di verbi limitate

text:
Pistacchio ha scritto:
> premetto che non voglio sembrare scortese o brusco.
> dunque.. io penso che i tuoi punti di vista siano molto interessanti e
> sarebbe costruttivo discuterli più a lungo. solo che temo che questo
> non sia il luogo più adatto e in questa sede ci scontreremmo senza
> arrivare a nessun punto.
> voglio dire, critichi le if così come sono, critichi il modo in cui si
> sviluppano, critichi gli strumenti di sviluppo e il modo in cui
> vengono fatti. non vanno bene le if come sono perchè sono povere dal
> punto di vista puramente narrativo. lo strumento per fare qualcosa di
> più simile a quello che pensi tu è idra ma è limitato e c'è comunque
> troppa programmazione. proponi qualcosa di tuo ed è un mud. affermi
> che non vale la pena perder tempo a scrivere if che tanto non te le
> legge nessuno e allora tanto vale la pena scrivere un libro. vuoi
> programmare if ma senza programmare.. (e sottolineo il verbo
> programmare.. i quadri si dipingono, le paste si cucinano, le if si
> programmano, oltre che scrivono)
credo che tu abbia letto il mio messaggio sotto una luce sbagliata: i
rimproveri che faccio alle at sono solo ed esclusivamente per me, per
quello che ci voglio fare io con le if, se li generalizzo è per semplice
funzione espositiva.
per me come -ipotetico sviluppatore di storie interattive- inform o
comunque una at classica è un gioco che non vale la candela, perché la
quantità di tempo che impiegherei a fare la if che ho in mente io
sarebbe tale da prendermi lo stesso tempo che impiegherei a buttare giù
la bozza di un romanzo.
il divertimento sarebbe diverso -questo è fuori di ogni dubbio- ma nel
farmi i conti in tasca *quel* modo di fare if è uno spreco di tempo,
perché sostanzialmente non ci credo, non credo nel parser e nel verbo +
oggetto e non credo soprattutto ad un pubblico di massa per un lavoro
del genere.
posso fare un lavoro del genere per mio diletto personale, nel ritagli
di tempo, senza pretese (aggiungere qui ad libitum) perché mi diverte
fare mondi virtuali, ma da qui a teorizzare una if oggi e qui ce ne passa.
un appunto storico: ho scritto la mia prima at su apple II, si chiamava
mens e grazie al cielo è andata persa spero per sempre, era un fantasy
di oltre cento locazioni ne ero fierissimo la distribuii come freeware
con il nome di 'ave il mago' nel 1987, non avevo neanche un modem
all'epoca scambiavo programmi piratati e ogni volta che qualcuno mi
chiedeva della roba ci infilavo il disketto di mens (sospiro), poi ho
fatto con alessandro uber necronomicon, un mud vecchio stile dove dentro
ci sono una serie di -a mio parere- belle avventure testuali correlate
tra loro da un plot generale, stiamo parlando del 1989-1994, svariate
centinaia di stanze, pagato, una grande soddisfazione vedere gente
giocare da vivo nelle mie at, con un bellissimo codice di alessandro.
ecco, con quello ho chiuso un capitolo e -aggiungo- non presento oggi un
mud, quello è un prodotto finito che resta on line come monito, badate a
voi.
se dovessi fare oggi un gioco multiutente lo farei in maniera
completamente diversa, ho trentacinque anni, due figli, un cane, ho
fatto lettere, ho visto svariati film di tarskovskj, ho letto infinite
jest, non mi metto a fare un gioco con draghetti e nanetti, a calcolare
i punti ferita, niente di personale, non mi interessa.
poi nel 2002 mi pare ho fatto natalie e pur essendo una if molto povera,
quella è una linea che mi interessa, anzi credo di aver esaurito lì
dentro molti discorsi che mi ero fatto dentro alla testa.
l'ho anche fatta tradurre in inglese con riscontri molto mediocri, ma
credo che sia rimasta incompresa o che la if in italia sia in alcuni
casi avanti a quello che arriva oltralpe.
quindi se ti sembra che mi lamento del panorama attuale perché voglio
fare qualcosa di diverso, oh beh certo, è un problema voler fare
qualcosa di diverso? semmai il problema è trovare quel fuochetto che ti
mette la voglia di farlo quel qualcosa di diverso.
un saluto
f.
--
http://loscimmiotto.splinder.com/


title: liste di verbi limitate

author: Giovanni Riccardi

text:
hal incandenza ha scritto:
> Paolo Lucchesi ha scritto:
>
>> Ovviamente, mi ripeto, il progetto di una a.t. secondo questi canoni
>> deve essere diverso dal progetto di una a.t. con parser.
>
>
> posso essere d'accordo. peraltro uno dei difetti di idra è che si basa
> sul concetto di bivio e ogni cosa diventa bivio e quindi funzione: un
> racconto interattivo complesso diventa in poco tempo una lista di
> centinaia e centinaia di funzioni messe tutte sullo stesso piano.
(Mi dispiace, ma questo periodo sono straimpegnato e non riesco a
seguire la discussione con l'attenzione che merita)
Solo per dire che anche la maggior parte (non tutte, naturalmente) delle
at basate su parser è a livello base un sistema a bivi. Perché se in
IDRA il collegamento tra uno stato e il successivo è rappresentato dal
link, in una AT basata su un parser (per esempio fatta con Inform) il
collegamento tra uno stato (un particolare stato dell'object tree) e il
successivo è dato da una azione più o meno complessa (parser a una
parola, a due, ecc.) che modifica l'albero degli oggetti. Anche
l'introduzione di elementi random in IDRA (così come nelle AT con
parser) non fa uscire il racconto interattivo dal sistema a bivi, perché
ho sempre un numero discreto di possibilità programmate (= previste) in
anticipo dall'autore.
Ora IDRA = Ipertesto Dinamico per Racconti d'Avventura.
Ebbene uno dei difetti di IDRA è che erix non ha sottolineato abbastanza
nella guida quel "dinamico". Probabilmente il difetto risiede nella
guida dove sembra che dinamico voglia semplicemente dire "generato con
una funziona javascript" anziché messo in un file HTML.
Giovanni
PS: fabrizio, ricevuta mail (stop) ti scrivo quando ho un attimo di
tempo (stop)


title: liste di verbi limitate

text:
loscimmiotto wrote:
> nnnno, non vogliooo
Non vuoi ridiventare umano? Non preoccuparti, e' normale.
   .Erix.


title: liste di verbi limitate

text:
Giovanni Riccardi wrote:
> Perché se in IDRA il collegamento tra uno stato e il successivo
 > è rappresentato dal link
Non proprio. In Idra non esitono stati, ma pagine. La distinzione
consiste nel fatto che ogni elemento cliccabile attiva un programma
cui si puo' far fare quello che si vuole (entro i limiti delle energie
che il programmatore puo' dedicarci), incluso modificare la pagina
stessa a piacere. Che poi la cosa piu' semplice ed  economica sia un
cambio di pagina statica sono d'accordo, ma vedi per esempio le pagine
del mercato in "Una storia di campagna" di A.Angiolino.
> l'introduzione di elementi random in IDRA (così come nelle AT con
> parser) non fa uscire il racconto interattivo dal sistema a bivi, perché
> ho sempre un numero discreto di possibilità programmate (= previste) in
> anticipo dall'autore.
E' comunque possibile creare nuovi link e nuove pagine (anche dal
contenuto non prevedibile a priori) in base alle azioni del giocatore.
> Ora IDRA = Ipertesto Dinamico per Racconti d'Avventura.
> Ebbene uno dei difetti di IDRA è che erix non ha sottolineato abbastanza
> nella guida quel "dinamico". Probabilmente il difetto risiede nella
> guida dove sembra che dinamico voglia semplicemente dire "generato con
> una funziona javascript" anziché messo in un file HTML.
In effetti la guida e' scritta per principianti. Il grosso limite di
Idra e' che le protezioni del browser rendono arduo costruire uno
strato a livello superiore. Ogni tanto mi viene l'idea di rifarlo con
Java + Rhino, ma trovo alquanto repellente l'immensa burocrazia delle
librerie Java. Forse se mi pagassero... ;-)
   .Erix.


title: liste di verbi limitate

text: loscimmiotto wrote: > nnnno, non vogliooo Tu cerchi la via piu' facile, giovane skywalker... Paolo Lucchesi email: plucchesi(at)tin(dot)it


title: liste di verbi limitate

text:
Giovanni Riccardi ha scritto:
> parola, a due, ecc.) che modifica l'albero degli oggetti. Anche
> l'introduzione di elementi random in IDRA (così come nelle AT con
> parser) non fa uscire il racconto interattivo dal sistema a bivi, perché
> ho sempre un numero discreto di possibilità programmate (= previste) in
> anticipo dall'autore.
sì, quello che volevo dire è che la if procede mentalmente per
locazioni, mentre la natura di idra di per sé non è così a camere
stagne, ma ha o può avere una struttura assai più lineare e quindi più
dispersiva.
>
> Ora IDRA = Ipertesto Dinamico per Racconti d'Avventura.
> Ebbene uno dei difetti di IDRA è che erix non ha sottolineato abbastanza
> nella guida quel "dinamico".
adesso vedo cosa viene fuori con inferno per ora non ho dovuto usare
variabili perché il prologo non ne aveva bisogno, ma già domani ne devo
provare una; devo dire che 'a manuale' la sintassi per variabili e
soprattutto ridisegno di stanze è... colombiniana ;)
> PS: fabrizio, ricevuta mail (stop) ti scrivo quando ho un attimo di
> tempo (stop)
troppo tardi (stop) sicari già partiti (stop)
f.
--
http://loscimmiotto.splinder.com/


title: liste di verbi limitate

text:
Enrico Colombini ha scritto:
> il programmatore puo' dedicarci), incluso modificare la pagina stessa a
> piacere. Che poi la cosa piu' semplice ed  economica sia un cambio di
> pagina statica sono d'accordo, ma vedi per esempio le pagine del mercato
> in "Una storia di campagna" di A.Angiolino.
per la poca esperienza avuta fin'ora direi che la sintassi relativa a
pagine temporanee, e comandi javascript all'interno delle virgolette è
deterrente, almeno io la vedo come poco omogenea e complicata.
f.
--
http://loscimmiotto.splinder.com/


title: liste di verbi limitate

text:
Paolo Lucchesi ha scritto:
> Tu cerchi la via piu' facile, giovane skywalker...
in realtà io sono ancora a THX-1138
--
http://loscimmiotto.splinder.com/


title: liste di verbi limitate

text:
loscimmiotto wrote:
> devo dire che 'a manuale' la sintassi per variabili e
> soprattutto ridisegno di stanze č... colombiniana ;)
Mi sento vagamente ma elegantemente insultato ;-)
   .Erix.


title: liste di verbi limitate

text:
> Non proprio. In Idra non esitono stati, ma pagine. La distinzione
> consiste nel fatto che ogni elemento cliccabile attiva un programma cui
> si puo' far fare quello che si vuole (entro i limiti delle energie che
> il programmatore puo' dedicarci), incluso modificare la pagina stessa a
> piacere. Che poi la cosa piu' semplice ed  economica sia un cambio di
> pagina statica sono d'accordo, ma vedi per esempio le pagine del mercato
> in "Una storia di campagna" di A.Angiolino.
Diciamo che allora stato IDRA è:
STATO = (PAGINA) + VARIABILI = (TESTO + LINK STATICI + LINK "DINAMICI")
+ VARIABILI
Sono andato a vedere il codice di "Una storia di campagna" ed è proprio
quello che volevo dire nel post precedente (ma alle 3 di notte uno non è
proprio lucidissimo e non si sa spiegare bene).
L'ipertesto di USDC è completamente determinato anche se utilizza alcune
variabili per gestire l'inventario e i link vengono generati in rapporto
al loro valore (link "dinamici" nella *formula* sopra). Probabilmente
proprio perché USDC è una trasposizione di un gioco di Angiolino da
carta a software il dinamismo è solo pseudodinamismo. Come dici tu sul sito:
"è piuttosto difficile arrivare a un finale soddisfacente, ma esiste una
strategia sicura per riuscirci, anche se trovarla richiede un certo
impegno."
Infatti, da quello che ricordo (l'ho giocata un po' di tempo fa) e dal
codice che ho visto, arrivare a un finale soddisfacente implica che
spesso il giocatore è costretto in un loop molto lungo tra diverse
pagine (spesso la stessa, come quella del mercato, acquistando e
vendendo caproche e vaccopotami).
Insomma la puoi fare complessa quanto ti pare (funzioni javascript) e
probabilmente quello che hai è un ipertesto (matematicamente, un grafo
orientato) complesso sì, ma finito e determinato.
> E' comunque possibile creare nuovi link e nuove pagine (anche dal
> contenuto non prevedibile a priori) in base alle azioni del giocatore.
Esatto, è quello che intendevo quando dicevo che nella guida non viene
sottolineato bene il significato di dinamico. Cioè, IMHO, dinamico non è
  "generato da una funzione javascript" quando questa funzione non fa
altro che uscire a seconda di un calcolo complicatissimo in una pagina
oppure in un'altra. Si deve in qualche modo fornire all'autore inesperto
la possibilità di generare pagine a partire da elementi scritti prima
(pagine come collage di frasi e paragrafi unite in qualche modo). E' un
discorso di combinatoria peraltro già affrontato in letteratura a
partire dagli anni '60 (per esempio "Cent mille milliards de poèmes" di
R. Queneau).
> In effetti la guida e' scritta per principianti. Il grosso limite di
> Idra e' che le protezioni del browser rendono arduo costruire uno strato
> a livello superiore. Ogni tanto mi viene l'idea di rifarlo con Java +
> Rhino, ma trovo alquanto repellente l'immensa burocrazia delle librerie
> Java. Forse se mi pagassero... ;-)
Sto facendo un po' di esperimenti in tal senso (per cose che
riguardano il mio lavoro) e secondo me non serve Java...
Giovanni


title: glulx: ora il timer!

author: Il giocatore

text:
Ciao a tutti,
rieccomi con una nuova!
HO provato il timer globale in glulx, mi funziona benissimo!!
Solo una cosa mi resta da chiarire....
io ho provato una print ogni 4 secondi e, funziona!
Ma cosa succede se io, durante il timer attivo, metto una keydelay nel
codice?
E in particolare, cosa succede se la metto nella routine di evento del
timer, cioè quella che glulx chiama ogni 4 secondi?
Ho provato, e la print non funziona più, se la faccio precedere dalla
KeyDelay!
Cosa succede, forse alla chiamata della KeyDelay il timer si ferma?
Se è così, è facile gestire, tanto dopo la KeyDelay lo faccio ripartire! Se
invece si blocca proprio, è un'altra cosa....
Insomma, si ferma o si blocca?
Cordialmente


title: glulx: ora il timer!

text:
"Il giocatore" <
f.dedo...@alice.it
> ha scritto nel messaggio
news:46e41872$0$10623$4faf...@reader2.news.tin.it...
> Ciao a tutti,
> rieccomi con una nuova!
> HO provato il timer globale in glulx, mi funziona benissimo!!
> Solo una cosa mi resta da chiarire....
> io ho provato una print ogni 4 secondi e, funziona!
> Ma cosa succede se io, durante il timer attivo, metto una keydelay nel
> codice?
> E in particolare, cosa succede se la metto nella routine di evento del
> timer, cioč quella che glulx chiama ogni 4 secondi?
> Ho provato, e la print non funziona piů, se la faccio precedere dalla
> KeyDelay!
> Cosa succede, forse alla chiamata della KeyDelay il timer si ferma?
> Se č cosě, č facile gestire, tanto dopo la KeyDelay lo faccio ripartire!
> Se invece si blocca proprio, č un'altra cosa....
> Insomma, si ferma o si blocca?
> Cordialmente
Beh, mi rispondo da solo, ho risolto!
basta gestire la context
grazie a tutti quelli che mi hanno aiutato in questi giorni!


title: glulx: ora il timer!

author: Lorenzo Marcantonio

text:
On 9 Set, 22:14, "Il giocatore" <
f.dedomini...@alice.it
> wrote:
> Beh, mi rispondo da solo, ho risolto!
> basta gestire la context
> grazie a tutti quelli che mi hanno aiutato in questi giorni!
Molto semplicemente la keydelay usa il timer e quindi lo resetta :P


title: Ruins in italiano - ho quasi finito

author: Vincenzo Scarpa

text:
Salve a tutti
allora... due parole prima del gran premio di F1 per dirvi che ho (o
meglio, abbiamo, insieme al mio amico Raffaello Valesio) finito di
tradurre Ruins in italiano e la sto scrivendo in Inform.
Per la fine della prossima settimana dovrebbe essere pronta; vi faro'
sapere...
Ciao da
Vincenzo


title: Ruins in italiano - ho quasi finito

author: Nero

text:

Complimenti!
Ce ne vorrebbero di piu' di traduzioni italiane di belle AT inglesi...
Grazie a Vincenzo e a Raffaello.
Nero


title: Ruins in italiano - ho quasi finito

author: Dott. Piergiorgio

text:
Nero wrote:
> Complimenti!
> Ce ne vorrebbero di piu' di traduzioni italiane di belle AT inglesi...
> Grazie a Vincenzo e a Raffaello.
Quello che servirebbe di più, adesso sarebbero traduzioni delle librerie
aggiuntive.
Io le ho scaricate tutte e le sto studiando con calma.
Se qualcuno volesse darci un' okkiata, stanno nella directory
../inform/library/contribuitions dell' ifarchive (Il path esatto non ce l'
ho a mente adesso)
Saluti,
Dott. Piergiorgio.


title: Ruins in italiano - ho quasi finito

text:
On Sun, 06 Apr 2003 17:19:21 GMT, "Nero" <
fearner...@ngi.it
>
wrote:

Soprattutto a Raffaello... :-)))
La traduzione di Ruins si è rivelata essere più difficile del
previsto, ma ormai sono a buon punto. Avrei anche intenzione di
distribuire a qualcuno del ng il file in formato rtf contente i testi
tradotti e gli originali (quelli cioè in inglese). Sebbene ritenga
infatti che la traduzione sia a un buon livello, gli errori non sono
mai da escludere. C'è qualcuno a cui posso spedirlo?
Ah, per chi non lo sapesse, Ruins in italiano sarà l'avventura
testuale su cui si basera' il terzo capitolo del mio manuale.
Nel frattempo però, una volta che l'avrò finita di scrivere in Inform,
la metterò on-line (codice sorgente e eseguibile) in attesa della
stesura del suddetto capitolo. Così potrete divertirvi un po'
(anche se Ruins è un "esercizio interattivo" rimane pur sempre
un'avventura da giocare a tutti gli effetti). :-)
Grazie e ciao da
Vincenzo


title: Ruins in italiano - ho quasi finito

text:
On Sun, 06 Apr 2003 19:07:11 GMT, "Dott. Piergiorgio"
<
pg...@libero.it
> wrote:
>Quello che servirebbe di piÃ¹, adesso sarebbero traduzioni delle librerie
>aggiuntive. Io le ho scaricate tutte e le sto studiando con calma.
Beh, dopo aver ottenuto il permesso di Nelson, ho tradotto Ruins in
italiano solo ed esclusivamente per proseguire col terzo capitolo del
mio manuale. Purtroppo, come dissi tempo fa, in questo periodo non ho
molto tempo per scriverne una io e allora sono stato costretto mio
malgrado a ripiegare su qualcosa di già esistente.
>Se qualcuno volesse darci un' okkiata, stanno nella directory
>../inform/library/contribuitions dell' ifarchive (Il path esatto non ce l'
>ho a mente adesso)
Sono d'accordo con te. Per quel che ne so, esistono la scenic.h
e le librerie per gli NPC. Ma in effetti se ne dovrebbero aggiungere
molte altre...
Ciao da
Vincenzo


title: Ruins in italiano - ho quasi finito

text:
Vincenzo Scarpa wrote:
>
> Sono d'accordo con te. Per quel che ne so, esistono la scenic.h
> e le librerie per gli NPC. Ma in effetti se ne dovrebbero aggiungere
> molte altre...
IO ho finora solo scenic.h.
Dove si possono trovare le librerie in Italiano per gli NPC ?
Mi sarebbero davvero utili.
Saluti,
Dott. Piergiorgio.


title: Ruins in italiano - ho quasi finito

text:
Dott. Piergiorgio wrote:
> Nero wrote:
>
> > Complimenti!
> > Ce ne vorrebbero di piu' di traduzioni italiane di belle AT inglesi...
> > Grazie a Vincenzo e a Raffaello.
>
> Quello che servirebbe di più, adesso sarebbero traduzioni delle librerie
> aggiuntive.
> Io le ho scaricate tutte e le sto studiando con calma.
Sono d'accordo, ma non dimentichiamo che non tutti sono programmatori, anzi
la maggior parte sono soltanto giocatori, e come tali interessati solo alle
AT.
Quindi sarebbe un bene per l' intera comunita' se ci fossero piu' classici
inglesi tradotti.
Nero


title: Ruins in italiano - ho quasi finito

text:
Nero wrote:
> Quindi sarebbe un bene per l' intera comunita' se ci fossero piu' classici
> inglesi tradotti.
Questo e' innegabile. Permettere ai non anglofoni di giocare
Christminster, Spider&Web, Photopia sarebbe una grande cosa (in un
angolo del mio neurone c'e' ancora l'idea di tradurre Photopia).
Certo bisogna vedere se gli autori sono disposti a lasciar tradurre la
loro opera e a condividere il sorgente con il traduttore (non credo ci
siano troppi problemi).
E poi, ammettiamolo, tradurre un'avventura può essere un lavoro lungo,
pesante e noioso, con pochissime soddisfazioni "creative". Non c'e' da
stupirci se in genere si preferisce dedicarsi ad un progetto proprio. E
dopotutto le if sono un hobby, non un lavoro; divertirsi e trarre
soddisfazioni dal proprio operato sono due cose di importanza prioritaria.
Pero' se ci sono volontari che vogliono dedicarsi alla traduzione dei
classici, ben vengano. Io ancora non ho giocato ad Anchorhead, e non mi
dispiacerebbe giocarla in italiano... :-)))))
bye
--
Paolo Lucchesi
email:
pluc...@tin.it
homepage:
http://www.paololucchesi.it
"Non viviamo in un mondo perfetto (per fortuna)"


title: Caro vecchio DOS

author: Alessandro

text:
Ragazzi (e ragazze!!!),
avrei una grande richiesta da fare a tutti voi.
Sono alla disperata ricerca di un vecchissimo gioco tipo gestionale DOS
che usavo sul mio vecchio 286: mi sembra si chiamasse "IMPERO".
Ne avete mai sentito parlare?
Sapreste dove posso ritrovarlo?
Grazie
Ale
P.S. Se puņ aiutarvi si parlava di "moggi di grano" da distribuire alla
popolazione, bisognava costruirsi ed ingrandire la reggia, combattere e
sconfiggere gli avversari con l'esercito...


title: Caro vecchio DOS

author: Lorenzo d'Amato

text:
mmm prova un po' qui... di abandonware ce ne sono tanti... ma taaaaanti...
http://www.gangsters.org/
--
Lorenzo d'Amato
bal...@libero.it
ICQ 28889190


title: Enigma

author: donna

text:
Ho fatto un passo avanti, ma mi son bloccata di
nuovo.

Domande:

1) nel labirinto si deve andare solo nel
mattatoio?

2)che me ne facci della penna a sfera?

Grazie a chi mi vorrà dare una mano


title: articolo

author: fabrizio venerandi

text:
vi segnalo la seconda parte del mio articolo su mud e at, sempre su
muditalia
--
http://www.fabrizio.venerandi.org


title: Aiuto x Inform newbie!!!

author: xAiN

text:
Salve a tutti!
Nonostante segua da molto tempo il mondo dell'IF, solo da poco ho deciso di
intraprendere lo studio dell'inform per crare qualcosa di mio... ma
purtroppo ho solo tutorial in inglese!!
Qualcuno sa se esistano tutorial in lingua italiana?
Nel newsgroup si parlava di una traduzione del Designer Manual di Nelson...
č stata fatta?
grazie a tutti coloro che sapranno darmi una mano!
byez
xAiN


title: Aiuto x Inform newbie!!!

author: Tommaso Caldarola

text:
xAiN ha scritto nel messaggio <9gccbh$9jr$
1...@fe2.cs.interbusiness.it
>...
>
> Salve a tutti!
Ciao!!!
>
> Nonostante segua da molto tempo il mondo dell'IF, solo da poco ho deciso di
> intraprendere lo studio dell'inform per crare qualcosa di mio... ma
> purtroppo ho solo tutorial in inglese!!
>
> Qualcuno sa se esistano tutorial in lingua italiana?
Ancora un pň di pazienza.... č in arrivo!!!
sciao
tommaso
--
Inviato il ven 15 giu 2001 11:20:28 CEST da 62.110.223.218
[62.110.223.218]
http://www.neuromante.net/


title: [ANNUNCIO]Intervista alla Infocom del 1984

author: Zoan

text:
L'ha trovata Paolo Vece, ed è online su IF Italia:
www.uno.it/utenti/sim/ifitalia/
Simone Zanella
ICQ: 27790485
Webmaster di Retroplay
http://www.retroplay.com
e di IF Italia
http://www.uno.it/utenti/sim/ifitalia/