title: [INFORM] task_scores

text:
Tommaso Caldarola wrote:
>
> vedo che hai centrato in pieno......
> ;--)))
eheh. cmq guarda che da quanto ho capito (poco, perché non uso i punteggi) l' array
task_scores -> t1 t2 ... tn;
è un array di COSTANTI contenenti i punti da aggiungere al computo totale per ogni azione compiuta. insomma, non ha
molto senso farci un test.
il fatto di avere effettivamente compiuto l'azione dipende da qualcosa che ha a che fare con Achieved(task) e si
testa... ehm, non so come si testa. Magari lo sa BaR. O magari non si può e si deve cambiare un flag da qualche parte se
proprio interessa saperlo - ma in questo caso come si potrebbe generare full-scores? beh, passo la parola al barabino,
che ci deluciderà.
A proposito, mi sa che ti stai globalmente confondendo con task_done che è l'array definito da Bar (e assolutamente
non-standard per quanto io sappia), usato in nsua per motivi intrinseci e ignoti.
ciao
S


title: [INFORM] task_scores

author: Roby BaR

text:
Stefano Gaburri <
gab...@elet.polimi.it
> wrote in message
39215C03...@elet.polimi.it...

Stefano ha ragione, task_score tiene i valori COSTANTI dei punti che vale
ciascuna mossa produttrice di punti.
Task_done (o task_provided, ecc a seconda della libreria... non sono stato
io, giuro, a chiamarli così... nella libreria di Nardinocchi non c'è traccia
di task_provided come invece dice il manuale... boh!) è il flag da testare.
Ciao


title: [INFORM] task_scores

author: Tommaso Caldarola

text:
Io ho provato con un array della stessa dimensione del tipo 0/1,
inizialmente tutti a zero e prima di ogni achieved(task) si alza il relativo flag.
Funzione egregiamente, anche se bruttina la soluzione....
ciao
tommi
Roby BaR wrote:
> Stefano ha ragione, task_score tiene i valori COSTANTI dei punti che vale
> ciascuna mossa produttrice di punti.
> Task_done (o task_provided, ecc a seconda della libreria... non sono stato
> io, giuro, a chiamarli cosě... nella libreria di Nardinocchi non c'č traccia
> di task_provided come invece dice il manuale... boh!) č il flag da testare.
> Ciao


title: [INFORM] task_scores

author: Stefano Gaburri

text:
Tommaso Caldarola wrote:
>
> Io ho provato con un array della stessa dimensione del tipo 0/1,
> inizialmente tutti a zero e prima di ogni achieved(task) si alza il relativo flag.
> Funzione egregiamente, anche se bruttina la soluzione....
mi sembra di capire che la stessa identica cosa la faccia già un array predefinito. Del resto dev'essero così,
altrimenti non si potrebbero generare i full_scores. E mi sembra anche di capire che
1) si dovrebbe chiamare task_provided...
2) ...ma le librerie di nardinocchi per qualche ragione lo chiamano task_done.
per le sue librerie (che credo tu stia usando) giovanni lo sa di sicuro, ma a questo punto una bella ricerca nel
sorgente delle librerie stesse (qualsiasi siano quelle che usi) dovrebbe risolvere ogni dubbio.
ciao
S


title: [INFORM] task_scores

text:
hai ragione, spulciando ho trovato in verblibm.h
proprio task_done che pone a 0/1 in seguito a chiamata di achieved(task)
ciao
tommaso
p.s.: io sto usando le Beta5a di GR



title: flamel: piccolo bug?

author: fabrizio venerandi

text:
>guarda tavoli
Sono tavoli di legno.
>esamina tavoli
Sono tavoli di legno.
>guarda arcata
Non servirebbe a niente.
>esamina arcata
L'arcata si apre nel muro a nord.
Me lo fa in diversi posti. Sembrerebbe che a volte consideri guarda e
esamina come sinonimi, altre volte no.
f.
--
materiali -
http://www.fabrizio.venerandi.org
neoN - telnet://
neon.ods.org:8010
Il trionfo dell'impiegato -
http://www.venerandi.org/impi.htm
Pantagrognomicon -
http://www.venerandi.org/pantagrognomicon.htm


title: flamel: piccolo bug?

text:
fabrizio venerandi wrote:
> >guarda arcata
> Non servirebbe a niente.
>
> >esamina arcata
> L'arcata si apre nel muro a nord.
Francesco, fammi indovinare: l'arcata è un oggetto scenic, no? L'errore quindi sarebbe che, nelle
librerie italiane, il fallimento di "guarda" se l'oggetto guardato non è nello scope non genera
(come dovrebbe) un CANTSEE_PE (parser error).
Correggetemi se sbaglio... credo che la cosa riguardi anche Giovanni.

ciao
S
PS per il gruppo: stiamo parlando di scenic.h. Se volete vi spiego cosa fa...


title: flamel: piccolo bug?

text:
Perché lo consideri un bug? Non trovo una discrepanza nelle risposte. Quali
ti saresti aspettato?
--
Flavio
fabrizio venerandi <
fabrizio...@libero.it
> wrote in message
3C985979...@libero.it...



title: flamel: piccolo bug?

text:
Pare che "-" <
altro...@yahoo.it
> abbia scritto:
>Perché lo consideri un bug? Non trovo una discrepanza nelle risposte. Quali
>ti saresti aspettato?
se guardare un oggetto non mi serve a niente, esaminarlo dovrebbe
servirmi ancora meno. Il fatto č che a volte guarda ed esamina sono
sinonimi, altre volte no.
f.
--
http://www.fabrizio.venerandi.org


title: flamel: piccolo bug?

text:
fabrizio venerandi wrote:
>
> Pare che "-" <
altro...@yahoo.it
> abbia scritto:
> >Perché lo consideri un bug? Non trovo una discrepanza nelle risposte. Quali
> >ti saresti aspettato?
>
> se guardare un oggetto non mi serve a niente, esaminarlo dovrebbe
> servirmi ancora meno.
senza contare che il messaggio "non serve a niente" viene implicitamente riconosciuto dal giocatore
come indicazione che l'oggetto "non serve a nulla" nel gioco... il che č infatti vero, tranne il
fatto che ha una descrizione che va appunto stampata esattamente in quel caso.
Cmq il problema č (quasi certamente) risolto, basta aggiungere il verbo #look alla lista delle
azioni che fanno "scattare" scenic.h nel codice della libreria. Nella versione inglese questo manca
perché "guarda" viene usato sempre senza oggetto, in italiano non č cosě...
ciao
S


title: flamel: piccolo bug?

author: Francesco Cordella

text:
Gaburri wrote
>Cmq il problema č (quasi certamente) risolto, basta aggiungere il
verbo #look >alla lista delle
>azioni che fanno "scattare" scenic.h nel codice della libreria. Nella
versione >inglese questo manca
>perché "guarda" viene usato sempre senza oggetto, in italiano non č
cosě...
Grazie per la segnalazione del bug. In inglese non accadrebbe perche'
per esaminare un oggetto usando il verbo 'look' si digita 'look at'
che, nelle librerie italiane, e' sinonimo di Examine e viene gestito
come tale. Look "singolo", invece, dal punto di vista delle librerie
non c'entra niente con Examine. Ecco perche', solo per i giochi
italiani, va corretto scenic.h.
f.


title: TWILIGHT

author: Twilight

text:
The Twilight Corner ,il sito sui Twilight si trova a :
http://turn.to/twilight


title: [INFORM] Novità

author: Giovanni Riccardi

text:
E' da qualche giorno disponibile su if-archive la nuova
versione della libreria di Inform, precisamente la release 6/10.
Mi sono messo al lavoro per rendere compatibile la libreria
in italiano con la nuova release.
Tra le altre cose dovrebbero essere stati corretti quesi noiosi
messaggi di errore che alcuni di voi hanno notato giocando
ad "Avventura" e "Negozio di Giocattoli".
A proposito, č un po' che non ricevo piů email per
quanto riguarda il programma di beta - testing.
Da quando č stato reso pubblico, praticamente piů nessuna email.
Fatevi sentire.
Al piů presto la beta 4 delle librerie in Italiano.
HAPPY INFORMING
Giovanni Riccardi


title: Haste is back...

author: Giancarlo Niccolai

text:
Ebbene sì; Il ridisegno della macchina virtuale è completato. Si era reso
necessario perché alcune ingenuità che avevo commesso nella gestione degli
oggetti avevano reso impossibile lavorare su oggetti con maggiore
profondità di due livelli... me ne sono accorto solo quando ho iniziato a
fare i primi test di IF.
Prima di fare una versione voglio aggiungere un paio di cosette che reputo
troppo interessanti per lasciarle indietro; se mi dice bene posso fare
tutto entro oggi.
Come ho detto, haste non è uno scripting language specifico per le AT;
questo è un bene, perché il comando VERB di inform è la sua maledizione,
più che la sua benedizione... L'idea è quella di scrivere una libreria per
la creazione di AT. In realtà dovrebbe essere una cosa paurosamente
semplice da fare, rispetto a inform, perché in Inform la gestione di
stringhe e array è vicina allo zero, e non ci sono dizionari e altri
costrutti simili.
Per darvi un assaggio di come funziona haste, ecco un piccolo esempio:
attributes
   light
   open
end
object Room1
  name = "La mia prima stanza"
  content = [ palla_bianca, piramide_rossa ]
  description = "Sei nella mia prima stanza!"
  e_to = Room2
[ ... altre proprietà ]
  enter()
    printl( "Benvenuto nella mia prima stanza" )
  end
  has light
end
object palla_bianca
  name = "La palla bianca"
  noun = [ "palla", "sfera" ]
  adjective = "bianca"
  ...
end
....
Assomiglia un po' a tads, ma ha gli attributi (come inform).
Ora, non avendo costrutti "speciali" per le IF, le relazioni di parentela
non sono automatiche. Ad esempio, sarebbe necessario creare un oggetto
World che contiene tutti gli oggetti "stanza" del gioco; questo si può fare
1) avendo un arrayone in world che contiene tutti gli oggetti o
2) chiamando una funzione AddToWorld( object ) per ogni stanza (lo si può
fare subito dopo la dichiarazione dell'oggetto) o
3) derivando la stanza dalla classe if_room, il cui costruttore si aggiunge
automaticamente al mondo:
object Room1 from if_room
  name = "La mia prima stanza"
  ...
end

Questa mi sembra la soulzione più elegante. Un altra maledizione di Inform è
che tutti gli oggetti definiti hanno caratteristiche "ifose". Questo ti fa
salvare un paio di caratteri per ogni oggetto, ma alle volte è una iattura.
Ci sono molti oggetti "degni di stare nel gioco" che non dovrebbero far
parte dell'universo di gioco. Ad esempio, gli item dei menu, gli oggetti di
supporto di vario genere; nelle MFS ho un "arbitro" che descide la
risoluzione dei combattimenti, ho la memoria per registrare gli
incatensimi, gli incantesimi stessi sono oggetti, ho persino "il cielo",
che gestisce lo stato di avanzamento del giorno o della notte. Vi assicuro
che rendere "invisibili" alcuni di questi oggetti ha richiesto una notevole
conoscenza di inform... che come tutti i linguaggi "specifici" è facile da
usare all'inizio, ma come tenti di fare una cosetta nuova 1) o è
impossibile o 2) ce la fai, ma sudando sette camicie.
Allo tesso modo, invece di listare il contenuto degli oggetti esplicitamente
penso che sia più interessante scrivere:
object palla_bianca from if_object( Room1 )
  name = "La palla bianca"
  noun = [ "palla", "sfera" ]
end
con il costruttore della classe if_object che aggiunge l'oggetto
direttamente dentro un parente.
Allo stesso modo, questi costruttori si occuperebbero di costruire l'oggetto
dizionario, che per ora organizzerei così:
object Dictionary
   verbs = [=>]
   nouns = [=>]
   adjectives = [=>]
   /** Adds a noun to the dictionary.
      Each dictionary entry puts in relation a noun with all the
      items having that noun. Each key is a word, and its relative
      value is a list of items where that word is used as a noun.
   */
   addNoun( word, item )
      printl ("Adding ", word, " for ",
item.name
 )
      v = self.nouns
      if word notin v
         self.nouns[ word ] = [ item ]
      else
         self.nouns[ word ] += item
      end
   end
   /** Add adjective.
      See addNoun
   */
   addAdjective( word, item )
      if word notin self.adjectives
         self.adjectives[ word ] = [ item ]
      else
         self.adjectives[ word ] += item
      end
   end
end
In altre parole, quando il mondo si forma gli oggetti si registrano al
dizionario chiamando automaticamente dal loro costruttore
Dictionary.addNoun( "nome", me_stesso )
per ogni parola nella loro lista "noun". Se voglio sapere a quale oggetto
l'utente si riferisce, non devo fare altro che chiedere:
oggetti_che_dice_lutente = Dictionary.nouns[ parola ]
ed otterrò la lista degli oggetti che corrispondo a quella parola (se
esiste). Se avessi qualche dubbio, potrei anche incrociarla con:
oggetti_che_dice_lutente = Dictionary.adjective[ altra_parola ]
e escludere tutti i nomi che non compaiono in entrambe le liste...
I verbi saranno semplicemente fatti con:
Dictionary.verbs[ "saluta" ] = hello_world
function hello_world( nome, secondo )
 printl( "Ciao mondo; il soggetto della frase era ", nome,
  " e il complemento era ", secondo )
end

Inform ha ampiamente dimostrato che per costruire parser MOLTO complessi
sono sufficienti il soggetto della frase (che in inform è la variabile
noun) e un generico complemento, il cui tipo viene determinato dalla
struttura della frase, chiamato "second".
A dire la verità è più probabile che le entry dei verbi siano "oggetti" di
tipo verbo, come questo:
object azione_saluta from if_verb
   noun = ["ciao", "saluta" ]
   grammar = [
 ["*"] => self.saluta_tutti,
 ["*", "*noun" ] => self.saluta_qualcuno,
        ["*", "a", "*noun" ] => self.saluta_a_qualcuno
   ]
   saluta_tutti( noun, second )
     ...
   end
end
con "*" == il verbo, i token grammaticali "*noun", "*second", "*topic" ecc.
alla inform e la routine gestrice, che può essere all'interno dell'oggetto
o all'esterno a seconda dei gusti...
Per l'internazionalizzazione, potrebbe essere sufficiente:
function internazionalizza()
...
  azione_saluta.grammar = [
        ["*"] => azione_saluta.saluta_tutti,
        ["*", "*noun" ] => self.saluta_qualcuno,
        ["*", "at", "*noun" ] => self.saluta_a_qualcuno  // nota "AT"
   ]

   azione_saluta.setNouns( ["hello", "hi"] )
end
cosa che cambierebbe sia la grammatica dell'oggetto che i suoi "nomi di
verbo"; il metodo setNouns penserebbe da solo ad aggiornare il dizionario,
e se le frasi in saluta_tutti ecc. sono messaggi configurabili (se ad
esempio invece di stampare frasi si una una routine configurabile come
print_message( number ) ) dovrebbe essere abbastanza semplice.
Anche il parser potrebbe essere internazionalizzato attraverso la semplice
ridefinizione di alcune strutture, così da poter accettare "lo prendo" o
"prendilo" in italiano e "get it" in inglese...
Cosa ne pensate?
Gian.


title: Haste is back...

text:
Giancarlo Niccolai ha scritto:
> Cosa ne pensate?
Giancarlo
ti avevo spedito tempo fa una email con alcune mie considerazioni sul
World Model in Haste (dopo la discussione in chat in cui se ne era
parlato, ormai un paio di mesi fa, se non sbaglio). Ti è arrivata? L'hai
letta?
Riepilogo quello che avevo scritto. In particolare riflettevo sulla
questione content/parent di cui avevamo discusso in chat. Ho letto
velocemente questo tuo post e non so se oltre al linguaggio e alla
macchina virtuale tu abbia già fatto qualcosa anche per il World Model.
Ti ricopio e incollo qui le mie considerazioni (che potrebbero essere
comunque già "vecchie" in relazione ai recenti progressi nello sviluppo).
Nella chat in questione tu parlavi di scrivere esplicitamente l'elenco
dei contenuti di ogni oggetto (per esempio di una stanza). Il World
Model si sarebbe allora occupato di creare automaticamente i riferimenti
al parent negli oggetti.
Per quanto elegante come soluzione è secondo me piuttosto scomoda per il
programmatore. Se diciamo che bisogna indicare il content forziamo
l'autore a progettare l'avventura in modo poco naturale. Mi spiego
meglio. Normalmente il "flusso" standard di creazione dell'avventura
consiste nella definizione delle locazioni e poi degli oggetti che vi si
trovano dentro. Supponiamo che io crei una stanza. Se ho fatto un buon
progetto a monte so benissimo cosa conterrà. Posso quindi scrivere
esattamente il contenuto di content (sic), non preoccupandomi di non
aver ancora definito gli oggetti perché haste analizza il sorgente e poi
crea l'albero degli oggetti (aggiungendo una proprietà parent). Se però
non ho fatto il progetto prima di scrivere il codice o mi viene in mente
di aggiungere un oggetto dopo che un beta-tester mi ha fatto notare che
manca qualcosa, sono costretto a cambiare il codice già scritto e
aggiungere detto oggetto nel content della stanza.
La soluzione solo parent è invece più "naturale" perché naturalmente le
locazioni non hanno parent (non mi devo preoccupare di definirlo -- o
magari hanno un parent comune definito dal WM in fase di
inizializzazione) e gli oggetti normalmente li inserisco quando ho
creato la locazione. Questa è la soluzione di inform con -> o con la
proprietà found_in (per aggiungere più parent).
Analizzato questo fatto fondamentale penso che si potrebbe usare un
approccio misto lasciando al programmatore la possibilità di usare l'uno
o l'altro. Non so se questo provochi rallentamenti particolari nel
sistema ma è naturalmente una cosa che si fa solo in fase di
inizializzazione dell'object tree perché dopo dipenderà dalla
particolare routine se usare content o parent. Questo sottintende il
fatto che dopo l'inizializzazione e per tutta l'esecuzione ogni oggetto
ha sempre sia un parent che un content. Se dobbiamo spostare un oggetto
da una stanza al player aggiorniamo il content di quest'ultimo e il
parent dell'oggetto.
Dopo queste considerazioni direi che un WM ridotto all'osso deve
semplicemente gestire l'albero degli oggetti (in base ai comandi inviati
dal parser), aggiornare alcune variabili di gioco e stampare i messaggi
di descrizione e di risposta ai comandi.
Giusto per fare un po' di brainstorming mi viene in mente di definire 3
oggetti di base:
1) game: gestisce le variabili di gioco e come evolve l'avventura...
2) player: il giocatore, quello che possiede, cosa può fare
3) world: il mondo delle locazioni e degli oggetti in esse contenuti
Giusto qualche idea/considerazione. MI piacerebbe aiutarti con il World
Model ma sono troppo impegnato, ma un po' di discussione su come fare il
WM perfetto, quello si può fare.
Ciao
Giovanni


title: Haste is back...

text:
Giovanni Riccardi wrote:
> Giancarlo Niccolai ha scritto:
>
>> Cosa ne pensate?
>
> Giancarlo
> ti avevo spedito tempo fa una email con alcune mie considerazioni sul
> World Model in Haste (dopo la discussione in chat in cui se ne era
> parlato, ormai un paio di mesi fa, se non sbaglio). Ti è arrivata? L'hai
> letta?
Mi sa di no... mi ricordo che mi avevi detto che me la avresti spedita, ma
mi pare di non averla ricevuta.
>
> Riepilogo quello che avevo scritto. In particolare riflettevo sulla
> questione content/parent di cui avevamo discusso in chat. Ho letto
> velocemente questo tuo post e non so se oltre al linguaggio e alla
> macchina virtuale tu abbia già fatto qualcosa anche per il World Model.
no; solo ipotesi e test preliminari di funzionamento. Dai test preliminari
(oggetti classless con dizionari o che puntano ad altri oggetti) ho visto
che avevo fatto alcuni errori errori concettuali e mi sono fermato per
sistemare la VM. Dato che questa sistemazione era abbastanza "radicale", ne
ho voluto approfittare per aggiungere delle cose e sistemare l'api interna
come volevo.
> Ti ricopio e incollo qui le mie considerazioni (che potrebbero essere
> comunque già "vecchie" in relazione ai recenti progressi nello sviluppo).
>
> Nella chat in questione tu parlavi di scrivere esplicitamente l'elenco
> dei contenuti di ogni oggetto (per esempio di una stanza). Il World
> Model si sarebbe allora occupato di creare automaticamente i riferimenti
> al parent negli oggetti.
>
> Per quanto elegante come soluzione è secondo me piuttosto scomoda per il
> programmatore. Se diciamo che bisogna indicare il content forziamo
> l'autore a progettare l'avventura in modo poco naturale. Mi spiego
> meglio. Normalmente il "flusso" standard di creazione dell'avventura
> consiste nella definizione delle locazioni e poi degli oggetti che vi si
> trovano dentro. Supponiamo che io crei una stanza. Se ho fatto un buon
> progetto a monte so benissimo cosa conterrà. Posso quindi scrivere
> esattamente il contenuto di content (sic), non preoccupandomi di non
> aver ancora definito gli oggetti perché haste analizza il sorgente e poi
> crea l'albero degli oggetti (aggiungendo una proprietà parent). Se però
> non ho fatto il progetto prima di scrivere il codice o mi viene in mente
> di aggiungere un oggetto dopo che un beta-tester mi ha fatto notare che
> manca qualcosa, sono costretto a cambiare il codice già scritto e
> aggiungere detto oggetto nel content della stanza.
Vero; ti faccio notare che più o meno devi fare la stessa cosa in inform...
ma la soluzione
object mia_cosa from if_object( parente ) ...
sembra piuttosto elegante e potente; del resto, un oggetto può avere UN SOLO
PARENTE... quindi una classe che si occupa da sola di "sottoscriversi" nel
content del parente (oltre che a settare il membro parente) attraverso il
costruttore pare una bella pensata.
>
> La soluzione solo parent è invece più "naturale" perché naturalmente le
> locazioni non hanno parent (non mi devo preoccupare di definirlo -- o
> magari hanno un parent comune definito dal WM in fase di
> inizializzazione) e gli oggetti normalmente li inserisco quando ho
> creato la locazione. Questa è la soluzione di inform con -> o con la
> proprietà found_in (per aggiungere più parent).
No, found_in non aggiunge + parent... di parent ce n'è uno solo (o nessuno).
Semplicemente, ti fa trovare l'oggetto in tutti i luoghi elencati in found
in..
>
> Analizzato questo fatto fondamentale penso che si potrebbe usare un
> approccio misto lasciando al programmatore la possibilità di usare l'uno
> o l'altro. Non so se questo provochi rallentamenti particolari nel
> sistema ma è naturalmente una cosa che si fa solo in fase di
> inizializzazione dell'object tree perché dopo dipenderà dalla
> particolare routine se usare content o parent.
Mah; la VM esegue circa un paio di milioni di cicli al secondo su un PC
normale; l'inizializzaizione di tutti gli oggetti di un gioco come zork
(254, se non vado errato), dovrebbe impiegare un tempo attorno ai 50
centesimi di secondo su una macchina piuttosto lenta...
> Questo sottintende il
> fatto che dopo l'inizializzazione e per tutta l'esecuzione ogni oggetto
> ha sempre sia un parent che un content. Se dobbiamo spostare un oggetto
> da una stanza al player aggiorniamo il content di quest'ultimo e il
> parent dell'oggetto.
Naturale. Mentre inform può fare tutto questo "in background", noi dovremo
necessariamente usare routine come object.move( new_parent ), che si
occupano di fare la cosa in modo pulito. Tutto sommanto, non è malaccio
neanche così...
>
> Dopo queste considerazioni direi che un WM ridotto all'osso deve
> semplicemente gestire l'albero degli oggetti (in base ai comandi inviati
> dal parser), aggiornare alcune variabili di gioco e stampare i messaggi
> di descrizione e di risposta ai comandi.
> Giusto per fare un po' di brainstorming mi viene in mente di definire 3
> oggetti di base:
> 1) game: gestisce le variabili di gioco e come evolve l'avventura...
Beh, possono anche essere oggetti nell'ambiente; ad esempio, non è
necessario avere game.dictionary e game.location; possono essere
tranqullamente dictionary e location.
> 2) player: il giocatore, quello che possiede, cosa può fare
Meglio: actor, di cui gli oggetti player sono implemntazioni particolari.
Vorrei che il motore supportasse i MUD come le AT. E'una cosa che inform
non può fare: è troppo incentrato sulla presenza di un solo giocatore...
> 3) world: il mondo delle locazioni e degli oggetti in esse contenuti
>
> Giusto qualche idea/considerazione. MI piacerebbe aiutarti con il World
> Model ma sono troppo impegnato, ma un po' di discussione su come fare il
> WM perfetto, quello si può fare.
>
Fantastico!
Gian.


title: Haste is back...

text:
Giancarlo Niccolai ha scritto:
> sembra piuttosto elegante e potente; del resto, un oggetto può avere UN SOLO
> PARENTE... quindi una classe che si occupa da sola di "sottoscriversi" nel
> content del parente (oltre che a settare il membro parente) attraverso il
> costruttore pare una bella pensata.
Appunto. Le mie erano considerazioni vecchie visto che sei andato avanti
nello sviluppo. La soluzione
object mia_cosa from if_object( parente ) ...
mi pare non l'avessi ancora sviluppata all'epoca.
> No, found_in non aggiunge + parent... di parent ce n'è uno solo (o nessuno).
> Semplicemente, ti fa trovare l'oggetto in tutti i luoghi elencati in found
> in..
Si, scusa. In realtà se non ricordo male Inform sposta dinamicamente
l'oggetto ogni volta nella nuova locazione. Si dovrebbe fare la stessa
cosa nel WM di haste
> Mah; la VM esegue circa un paio di milioni di cicli al secondo su un PC
> normale; l'inizializzaizione di tutti gli oggetti di un gioco come zork
> (254, se non vado errato), dovrebbe impiegare un tempo attorno ai 50
> centesimi di secondo su una macchina piuttosto lenta...
OK. Visto che l'altra volta avevi parlato di velocità di esecuzione...
comunque io sono un matematico di formazione, tendo sempre
all'ottimizzazione estrema :-)
> Naturale. Mentre inform può fare tutto questo "in background", noi dovremo
> necessariamente usare routine come object.move( new_parent ), che si
> occupano di fare la cosa in modo pulito. Tutto sommanto, non è malaccio
> neanche così...
Anche per la questione di cui dicevo sopra di oggetti che si trovano in
più stanza.
> Beh, possono anche essere oggetti nell'ambiente; ad esempio, non è
> necessario avere game.dictionary e game.location; possono essere
> tranqullamente dictionary e location.
OK.
>>2) player: il giocatore, quello che possiede, cosa può fare
>
>
> Meglio: actor, di cui gli oggetti player sono implemntazioni particolari.
> Vorrei che il motore supportasse i MUD come le AT. E'una cosa che inform
> non può fare: è troppo incentrato sulla presenza di un solo giocatore...
multiplayer!! e vai!
Ciao
Giovanni


title: Haste is back...

text:
Giovanni Riccardi wrote:
> Giancarlo Niccolai ha scritto:
>
>> sembra piuttosto elegante e potente; del resto, un oggetto può avere UN
>> SOLO PARENTE... quindi una classe che si occupa da sola di
>> "sottoscriversi" nel content del parente (oltre che a settare il membro
>> parente) attraverso il costruttore pare una bella pensata.
>
> Appunto. Le mie erano considerazioni vecchie visto che sei andato avanti
> nello sviluppo. La soluzione
>
> object mia_cosa from if_object( parente ) ...
>
> mi pare non l'avessi ancora sviluppata all'epoca.
Infatti, è una pensata che è dipesa dal miglioramento della gestione dei
classless objects.
>
>> No, found_in non aggiunge + parent... di parent ce n'è uno solo (o
>> nessuno). Semplicemente, ti fa trovare l'oggetto in tutti i luoghi
>> elencati in found in..
>
> Si, scusa. In realtà se non ricordo male Inform sposta dinamicamente
> l'oggetto ogni volta nella nuova locazione. Si dovrebbe fare la stessa
> cosa nel WM di haste
ARRG, è una cosa BRUTTA (non found_in, ma la sua implementazione in
inform)... va pensato un modo migliore per mettere gli oggetti found-in
nello SCOPE dinamico calcolato dal WM (a seconda dell'agente per cui si
richiede lo scope).
>
>
>> Mah; la VM esegue circa un paio di milioni di cicli al secondo su un PC
>> normale; l'inizializzaizione di tutti gli oggetti di un gioco come zork
>> (254, se non vado errato), dovrebbe impiegare un tempo attorno ai 50
>> centesimi di secondo su una macchina piuttosto lenta...
>
> OK. Visto che l'altra volta avevi parlato di velocità di esecuzione...
> comunque io sono un matematico di formazione, tendo sempre
> all'ottimizzazione estrema :-)
>
>> Naturale. Mentre inform può fare tutto questo "in background", noi
>> dovremo necessariamente usare routine come object.move( new_parent ), che
>> si occupano di fare la cosa in modo pulito. Tutto sommanto, non è
>> malaccio neanche così...
>
> Anche per la questione di cui dicevo sopra di oggetti che si trovano in
> più stanza.
intendi dire obj.found_in( list_of_rooms ) ? Ci devo pensare su... (ma
parrebbe abbastanza elegante, se non per il fatto che mentre le classi
hanno i costruttori, i classless objects no, quindi non posso lanciare una
routine direttamente nella dichiarazione. Beh... posso sempre fare:
  object xxx from if_object( ... )
    dummy_prop = self.found_in( ... )
  end
Ma non mi piace moltissimo; in fondo si potrebbe anche fare un ciclo a ogni
nuovo turno che analizza TUTTI gli oggetti direttamente al di sotto delle
stanze. Il tempo necessario anche per un gioco con un migliaio di stanze
dovrebbe essere assolutamente trascurabile. Controllare un paio di
proprietà, fino ai 10000 oggetti, è un tempo del quale l'utente non si può
rendere conto... solo che non volevo porre limiti ;-)
>>
>>
>> Meglio: actor, di cui gli oggetti player sono implemntazioni particolari.
>> Vorrei che il motore supportasse i MUD come le AT. E'una cosa che inform
>> non può fare: è troppo incentrato sulla presenza di un solo giocatore...
>
> multiplayer!! e vai!
>
Assolutamente sì. Voglio che chi scrive un avventura non debba scrivere
manco una riga in più perché questa possa funzionare in multiplayer (beh,
se inizia a usare variabili e switch globali questi sono fatti suoi, e
nessuno glielo impedisce, ma il sistema, per conto suo, deve essere
totalmente MP).
Gian.


title: Haste is back...

text:
Giancarlo Niccolai ha scritto:
> ARRG, è una cosa BRUTTA (non found_in, ma la sua implementazione in
> inform)... va pensato un modo migliore per mettere gli oggetti found-in
> nello SCOPE dinamico calcolato dal WM (a seconda dell'agente per cui si
> richiede lo scope).
La stessa cosa. Non allo stesso modo. (Comunque non sono certo di quello
che ti ho scritto. uno di questi giorni vedo bene come inform implementa
il found_in)
> Ma non mi piace moltissimo; in fondo si potrebbe anche fare un ciclo a ogni
> nuovo turno che analizza TUTTI gli oggetti direttamente al di sotto delle
> stanze. Il tempo necessario anche per un gioco con un migliaio di stanze
> dovrebbe essere assolutamente trascurabile. Controllare un paio di
> proprietà, fino ai 10000 oggetti, è un tempo del quale l'utente non si può
> rendere conto... solo che non volevo porre limiti ;-)
Bisogna fare un compromesso tra quello che è *esteticamente* e
concettualmente elegante dal punto di vista del codice e quello che è
pratico. Uno dei punti di forza di Inform è secondo me proprio questo: è
amato moltissimo dai non programmatori che non colgono certe brutture
nella logica di programmazione. Storicamente linguaggio con una logica
troppo rigida (smalltalk, per esempio, per certi versi ancha java) non
hanno avuto un gran successo al contrario di altri meno formali tipo
Python, al quale forse è solo mancata una "politica di marketing" che lo
imponesse di più al pubblico (ma recentemente si è ripreso).
> Assolutamente sì. Voglio che chi scrive un avventura non debba scrivere
> manco una riga in più perché questa possa funzionare in multiplayer (beh,
> se inizia a usare variabili e switch globali questi sono fatti suoi, e
> nessuno glielo impedisce, ma il sistema, per conto suo, deve essere
> totalmente MP).
D'altronde quello di un solo giocatore è un caso particolare di MP.
Ciao
Giovanni


title: Haste is back...

author: riktik

text:
Giancarlo Niccolai ha scritto:
>
> Cosa ne pensate?
a vederlo così mi sembra che il linguaggio si abbastanza facile visto
che più o meno sono riuscito a capire tutto ciò che hai scritto.
Quando pensi ci sarà una libreria, e un poco di documentazione "for
dummies"? (non è per farti fretta, solo curiosità di provare)
Che mi dici a proposito della multimedialità di haste?
ciao
marco


title: Haste is back...

author: Saintpumpkin

text:
riktik wrote:
> Giancarlo Niccolai ha scritto:
>
>>
>> Cosa ne pensate?
>
>
> a vederlo così mi sembra che il linguaggio si abbastanza facile visto
> che più o meno sono riuscito a capire tutto ciò che hai scritto.
>
Anche a me è parso facile facile, ed inizio ad vere paura.
--
www.italiansaints.it
 - Il Fan Club Italiano Del Southampton f.c.
Anche un orologio rotto ha ragione, due volte al giorno.


title: Haste is back...

text:
riktik wrote:
> Giancarlo Niccolai ha scritto:
>
>>
>> Cosa ne pensate?
>
> a vederlo così mi sembra che il linguaggio si abbastanza facile visto
> che più o meno sono riuscito a capire tutto ciò che hai scritto.
>
> Quando pensi ci sarà una libreria, e un poco di documentazione "for
> dummies"? (non è per farti fretta, solo curiosità di provare)
>
Sul sito c'è la guida di sopravvivenza. Manca la referenza alle funzioni, ma
per cominciare a capire come funziona dovrebbe bastare.
> Che mi dici a proposito della multimedialità di haste?
Integrerò il toolit gtk al più presto. Penso di mettere dentro anche le
OpenAL. Sto finendo la gestione dei processi esterni per lanciare player e
cose del genere.
Gian.


title: Haste is back...

author: Paolo Maroncelli

text:
Saintpumpkin ha scritto:
>Anche a me è parso facile facile, ed inizio ad vere paura.
A dire il vero iniziano a tremare i polsi anche a me..... ;-))
PaoloM
----------------------
http://www.maroncelli.net


title: Haste is back...

text:
Saintpumpkin wrote:
> riktik wrote:
>> Giancarlo Niccolai ha scritto:
>>
>>>
>>> Cosa ne pensate?
>>
>>
>> a vederlo così mi sembra che il linguaggio si abbastanza facile visto
>> che più o meno sono riuscito a capire tutto ciò che hai scritto.
>>
>
> Anche a me è parso facile facile, ed inizio ad vere paura.
>
Paura?
:-)


title: Haste is back...

text:
Giancarlo Niccolai wrote:
>
>
> Paura?
> :-)
Non vorrei che il tuo sistema sia troppo potente e facile da usare ;-)


title: Haste is back...

text:
Saintpumpkin ha scritto:
> riktik wrote:
>
>> Giancarlo Niccolai ha scritto:
>>
>>>
>>> Cosa ne pensate?
>>
>>
>>
>> a vederlo così mi sembra che il linguaggio si abbastanza facile visto
>> che più o meno sono riuscito a capire tutto ciò che hai scritto.
>>
>
> Anche a me è parso facile facile, ed inizio ad vere paura.
ritiro tutto, non sono riuscito neanche a stampare hello world :(
(non è a prova di dummies)
printl("Hello world.")
Error 3068 - : 0: Load error (Invalid symbol table position)
Premere un tasto per continuare . . .


title: Haste is back...

text:
riktik wrote:

Uhm, ma hai usato la versione linux?
Perché a me funziona: devo ancora finire le routine della versione
windows... che quindi è ancora quella MOLTO vecchia.
(come avevo scritto nella prima mail ;-)
gian


title: Haste is back...

author: tomb

text:
Giancarlo Niccolai wrote:
> Sul sito c'è la guida di sopravvivenza. Manca la referenza alle funzioni, ma
> per cominciare a capire come funziona dovrebbe bastare.
Pensi di implementare qualcosa a supportdel debug?
bai
t


title: Haste is back...

text:
Giancarlo Niccolai ha scritto:
> Uhm, ma hai usato la versione linux?
no, non ho linux su questa macchina (lo so lo so, ma su questa non si può)
ciao


title: Haste is back...

text:
riktik wrote:

Allora resisti ancora un paio di giorni, che devo usare un paio di funzioni
specifiche per ogni sistema...
Gian.


title: Haste is back...

text:
tomb wrote:

Ovviamente. Tanto per cominciare, per il momento ho la funzione "inspect"
che verifica ricorsivamente il tipo e il contenuto di tutti gli oggetti.
Gian.


title: Haste is back...

text:
Giancarlo Niccolai wrote:

Dimenticavo: inspect si usa con inspect( variabile ); è già presente anche
il concetto di "informazioni di debug (tabella di linee nel sorgente).
Gian.


fe622a1c


title: Richiesta...

author: Desperado

text:
Ciao!
Sono nuovo qui.
Vi vorrei chiedere due cose a proposito delle (nostre adorate) avventure
testuali:
1) Qualcuno ricorda una avventura (in italiano) per Commodore 64 intitolata
"Mission Twain" (credo, ma non sono sicuro)?
Qualche indizio:
* la prima metà si svolge in una foresta di un lontano pianeta (chiamato
Twain), e la seconda metà all'interno di una base spaziale del pianeta.
* ad un certo punto si trova un monolito con incisa una frase che suona più
o meno così: "Cristo l'ha portata in croce e vi è morto attacato... La tua
via sarà come quella, oppur non sarai graziato".
* appena entrati nella base, ci si trova in una serra, e dietro alcune
piante si trova un pannello in cui inserire la password per accedere al
resto della base
* per poter fuggire (e vincere) bisogna trovare e liberare un capitano
imprigionato nella base.
* questa avventura ha una musica (che si interrompeva quando il nostro
personaggio muore): l'"aria sulla quarta corda" di Bach....cioè "la sigla di
Quark"
* la foresta è infestata da zanzare giganti.
* nella foresta c'è un pericoloso frutto "esplosivo" simile ad un melone.
Se qualcuno la conosce, e sa dove posso scaricare l'immagine per il mio
Emulatore di C64, per favore, mi dica dove posso trovarla!!!!
2) Attualmente sto giocando a "Montezuma" (Viking n°6...Terry Jones è il
protagonista): sono bloccato..non so come prendere la statua d'oro massiccio
senza che mi crolli il soffitto addosso..e non so come aprire la porta di
pietra alla fine del tunnel dentro la grotta...
Se qualcuno mi può aiutare, lo ringrazierò a vita........
PS ho finito molte altre avventure della collana Viking...se volete
aiuto....chiedete qua sul forum, o mandatemi una e-mail...
Grazie.... e aspettiamo che sia pronto il nuovo sito di "Progetto Lazzaro",
che è una idea degna di un premio nobel per la cultura....
A presto...
Futak (nico_poddaCHIOCCIOLAtiscali.it)


title: Richiesta...

author: Il nemico delle AT

text:
Ciao Desperado
> PS ho finito molte altre avventure della collana Viking...se volete
> aiuto....chiedete qua sul forum, o mandatemi una e-mail...
QUando inseriremo le AT del progetto Lazzaro nel DB di IIF ti chiedero'
di aggiungere i suggerimenti.
Rob
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news
 segnala gli abusi ad
ab...@newsland.it


title: Richiesta...

text:
> Ciao Desperado
>
> > PS ho finito molte altre avventure della collana Viking...se volete
> > aiuto....chiedete qua sul forum, o mandatemi una e-mail...
>
> QUando inseriremo le AT del progetto Lazzaro nel DB di IIF ti chiedero'
> di aggiungere i suggerimenti.
> Rob
Ben volentieri!
Ciao


title: [glulx] testo su .jpg... e' normale?

author: torredifuoco

text:
ho provato a "blorbare" una .jpg e un file .inf (il solito sorgente
inform) e ho ottenuto un programma .blb che espone alla descrizione
dell'unica locazione la .jpg nel testo a destra. l'immagine e' grande
come uno screenshot di vice (il primo schermo di death in the
caribbean) e la descrizione del luogo (copiata dalla locazione di
partenza di ditc) *non* riesce a circondare l'immagine (ovviamente).
ecco il sorgente:
Constant Story "BLORTEST";
Constant Headline "^My first blorb.^";
Constant MANUAL_PRONOUNS;
Include "Parser";
Include "Verblib";
#ifdef TARGET_GLULX;
Include "Infglk";
Include "btest.bli";
#endif;
[ Initialise; location = behindhouse; "^Hello!^"; ];
Class Room
  has light;

Room behindhouse "Behind your house"
  with description [;
  	glk_image_draw(gg_mainwin, Foresta,
               imagealign_MarginRight, 0);
  		"You are standing behind the house map in hand. A path
  		leads north into the woods. That is the beginning of
  		a classic title, ~Death in the Caribbean~.";
  	   ];
Object sign "sign" behindhouse
  with description
  		"It reads: ~Sherwood Forest~. But you're not *really
  		really* sure that the trees in front of you are *that*
  		forest. It should be far away from here.",
  	   name 'sign',
  has static;

Include "Grammar";
ho notato che gluxe versione 121, dopo "x sign" come prima azione,
stampa la descrizione del sign senza coprire la .jpg... mentre glulxe
versione 125 (l'ultimo) copre l'immagine. c'e' da dire che tutti e
due, se dotati di una descrizione del luogo abbastanza lunga,
circondano la .jpg. inoltre nella "revision history" della 125 si
trova scritto :
Images in the left or right margins of text buffer windows are now
displayed correctly after a flow break.
...se lo dice lui... capisco che qualcosa e' cambiato,
nell'esposizione delle immagini nella finestra di testo ai margini
destro e sinistro, ma non mi sembra che gluxe 125 disponga
"correttamente" la .jpg (potrei aver mancato qualcosa, anzi, *devo*
aver sicuramente mancato qualcosa). opinioni?
max "torredifuoco" bianchi
p.s. cosa consigliate a un povero diavolo alle prese con glulx? ho
cominciato da gull di cadre e ho un leggero mal di testa (cit. e.
short - circa)... come continuo? il documento "definitivo" e'
"glk-spec-061"? vorrei leggere un po' di teoria prima di passare ai
listati...


title: decompilare file .z5

author: matteo

text:
salve, come si decompilano i file di inform?
vorrei decompilare l'avventura di Marco Time Warp, solo per scopo
informativo, e' possibile?
--
______________________________________
            Matteo :-)
    E come disse K.Gibran
'La penna è uno scettro, ma come sono
pochi i re tra gli scrittori!'
         ICQ: #156904795
  MALITO: lollifrolli[at]tin[dot]it
HOME PAGE:
http://utenti.lycos.it/kild
______________________________________


title: decompilare file .z5

text:
"matteo" <
lolli...@tin.it
> ha scritto
> salve, come si decompilano i file di inform?
> vorrei decompilare l'avventura di Marco Time Warp, solo per scopo
> informativo, e' possibile?
Perche' non chiedi il sorgente a lui?
f.


title: decompilare file .z5

text:
>
> Perche' non chiedi il sorgente a lui?
> f.
perche' vprrei sapere se e' possibile o meno
>
>
>


title: decompilare file .z5

text:
"matteo" <
lolli...@tin.it
> ha scritto nel messaggio
news:E1SD8.52619$zW3.7...@news1.tin.it...
> >
> > Perche' non chiedi il sorgente a lui?
> > f.
>
> perche' vprrei sapere se e' possibile o meno
>
Esiste qualche disassemblatore per Inform, ma non so quanto i risultati ti
possano essere d'aiuto. Guarda qui:
http://www.firthworks.com/roger/inflight/tools.html
f.


title: decompilare file .z5

text:

praticamente no


title: decompilare file .z5

author: Barabert

text:
"Stefano Gaburri" <
ste...@gaburri.net
> ha scritto nel messaggio
news:3CE005DE...@gaburri.net...

E invece direi di sì.
Ok, non si ottiene un listato in inform (tutt'altro) ma si possono trovare -
tutte raggruppate in fondo - le frasi del gioco... e io credo che sia questo
ciò che la maggior parte della gente vuole trovare decompilando
un'avventura.
Bye


title: decompilare file .z5

text:
Barabert wrote:
> > praticamente no
>
> E invece direi di sì.
> Ok, non si ottiene un listato in inform (tutt'altro) ma si possono trovare -
> tutte raggruppate in fondo - le frasi del gioco... e io credo che sia questo
> ciò che la maggior parte della gente vuole trovare decompilando
beh, il text dump non c'entra nulla con la decompilazione... e infatti si
può fare facilmente con altri tool.


title: decompilare file .z5

author: Piergiorgio

text:
Barabert wrote:
> Ok, non si ottiene un listato in inform (tutt'altro) ma si possono trovare -
> tutte raggruppate in fondo - le frasi del gioco... e io credo che sia questo
> ciò che la maggior parte della gente vuole trovare decompilando
> un'avventura.
> Bye
Ba' insomma, lo spoiler finale !!!!
Un vero avventuriero non lo dovrebbe usare.....
Saluti,
Piergiorgio.


title: IF browser-based (javascript)

author: pistacchio

text:
ciao a tutti!
ho già scritto più volte in questo NG per parlare della mia idea. è un
progetto che, a fasi alterne, sviluppo da anni.
visto che la maggior parte delle applicazioni si stanno spostando sul
web e molte, indipendentemente dalla complessità, nei nostri browser
(e parlo di interi sistemi operativi come eyeos, word processor,
giochi di ogni tipo), sono convinto che il futuro dell'if passi, o
possa passare, per il web. i motivi che mi rendono convinto di cioè
sono, oltre alla constatazione di una tendenza in atto:
1. una IF è un'applicazione testuale, quindi perfetta per essere
portata sul web
2. la possibilità immediata di avere un sistema di formattazione del
testo (colori, disposizione del testo, ma anche immagini o audio
3. l'eventuale possibilità di avere, a pochi click di distanza dal
gioco, un forum per l'aiuto o la segnalazione di errori o giudizi, un
sistema di help rappresentato da altre pagine, eventualmente nua
pagina in cui raccogliere le statistiche sugli utenti che hanno finito
il gioco in meno tempo o con più punti ecc.
4. un sistema basato sul browser è immediatamente compatibile con una
tendenza che da sempre accompagna lo sviluppo delle IF, ovvero
l'essere multipiattaforma.
5. nessuna necessità di installare alcun nuovo software per giocare
all'avventura (ammesso che il computer abbia un browser installato,
cosa certa nella stragrande maggioranza dei casi)
6. nessuna necessità di rilasciare "aggiornamenti" del software o
versioni multiple dei gioco, visto che basta uploadare una nuova
versione corretta del gioco perchè tutti gli utenti giochino sempre
all'ultima versione disponibile.
nella mia ricerca per un sistema di sviluppo mi concentrai
inizialmente sul PHP, ovvero un sistema combinato client / server.
l'ovvio problema era rappresentato dalla necessità di essere collegati
in rete per giocare oltre a una non immediatezza di risposta ai
comandi. mi spostai quindi su un tipo di applicazione esclusivamente
client basato su javascript.
una cosa che mi è parsa chiara da subito, arrivato a questo punto, è
che, per sfruttare il mezzo e poichè un sistema basato sul web avrebbe
attratto parecchi neofiti (non c'è necessità di cercare un client per
le if, installarlo e scaricare il gioco) o giocatori occasionali o
solo curiosi, avrei abbandonato la "riga di comando", così cara e
caratteristica dell'IF ma anche, per certi aspetti, meno immediata dal
"click del mouse" che chi naviga il web è abituatuato ad usare per
ogni tipo di interazione le pagine.
nelle varie prove che ho fatto (il sistema è in via di sviluppo) mi
sono concentrato, alla fine, su due modi per affrontare il problema di
come impostare il gioco. entrambi sono stati discussi qui sul NG anni
fa quando portai anche esempi. purtroppo i siti sui quali erano
presenti i progetti non sono più online e il codice non è disponibile.
torno ad affrontare quello che per è un problema ancora aperto e lo
faccio con maggiore consapevolezza e padronanza del mezzo di
programmazione, oltre che una maggiore convinzione della mia idea.
i due sistemi sono "menu contestuale" e "verbi limitati".
per immaginare un sistema a verbi limitati si figuri facilmente una
versione testuale dello SCUMM system, ovvero il motore dietro le
avventure testuali della lucasart (monkey island, maniac mansion, sam
& max ecc). in una parte del testo c'è la descrizione di quello che il
protagonista vede (come una qualunque IF), nella parte sottostante una
serie fissa di una decina di verbi (prendi, parla con, spingi, usa,
osserva, vai). l'interazione con il gioco avviene clickando sul verbo
e successivamente sull'oggetto (o personaggio) che è l'oggetto diretto
dell'azione (e poi, eventualmente, sull'oggetto indiretto come nel
caso di "dai X a Y"). l'oggetto è un link nella descrizione o
nell'inventario.
il sistema a menu contestuale, invece, funziona in maniera simile ma
il numero di azioni eseguibili su un oggetto non è fisso, ma cambia a
seconda dell'oggetto. Così se in una stanza ho un bicchiere d'acqua e
una leva, clickando sulla leva saranno disponibili le azioni "esamina,
tira, spingi" e clickando sul bicchiere "esamina, prendi, bevi".
il tipo di approccio è radicalmente differente rispetto a quello della
if tradizionale, con vantaggi e svantaggi diversi a seconda del metodo
ed entrambi richiedono di progettare le avvventure in maniera non
comparabile rispetto a quelle tradizionali.
entrambi i sistemi, per iniziare, escludono il problema che affligge
molte IF noto come "indovina la parola". mi trovo davanti a un puzzle,
so cosa devo fare, è ovvio che è quella la soluzione, ma non so come
comunicarla al parser perchè continua a non capire (o non accettare o
mal interpretare) le mie istruzioni.
un sistema a verbi fissi è stato usato per avventure divertenti e
diverse fra loro (come quelle della lucas) con grande successo, quindi
la mia proposta è quella, sostanzialmente, di una versione non grafica
di quel tipo di gioco. ancorato però alle IF tradizionali, mi rendo
conto che un sistema siffatto toglie molto di quell'illusione di
"libertà completa" che è una delle cose più affascinanti dell'IF.
immaginiamo un ripiano pieno di polvere. con il sistema a verbi fissi
posso "esaminare" la polvere per scoprire che è lì da anni, "usare il
fazzoletto con la polvere" e pulire il ripiano, e magari persino
"prendere la polvere" e metterla all'interno di una boccetta che ho
precedentemente raccolto. ma una delle soddisfazioni più grandi
regalate dall'IF è provare a digitare "sniffa la polvere" e scoprire
che l'autore ha previsto tale possibilità e risponde in maniera
scherzosa "sei già in crisi d'astinenza?" o con qualche impatto nel
gioco, per esempio facendo ammalare il protagonista.
l'altro sistema, più libero, permette in effetti di "sniffare la
polvere" (sniffa è uno dei verbi che compaiono nel menu contestuale
quando si clicca sul ripiano e ci viene detto che c'è della polvere e
polvere è uno dei link cliccabili). la maggiore libertà del sistema è
bilanciata in negativo dal problema del guidare troppo il giocatore
verso la soluzione. i puzzle non possono mai essere improntati a
qualcosa di strano e particolare, semplicemente perchè soluzione cosa
strana e particolare sarebbe immediatamente visibile al giocatore.
certo, i menu contestuali sono flessibili, per cui, rimanendo
all'esempio della polvere, si potrebbe rendere il verbo "sniffa"
visibile solo se precedentemente il personaggio ha frugato nei
cassetti, trovato la rinazina spry nasale e l'ha usata (prima aveva il
naso chiuso e quindi non poteva sniffare). di nuovo: si richiede un
approccio alla progettazione dell'avventura diverso.
sono quasi certo che almeno due argomenti verranno fuori come
risposte:
1. idra
2. inform
per quanto riguarda inform, vi prego dall'astenervi dalla discussione
se l'unico apporto è "perchè reinventare la ruota? un altro sistema di
sviluppo? c'è già inform, con la versione sette è diverntato perfetto
e se sei fissato con il web ci sono le applet java come interpreti per
i z5, o prova tads che ha il supporto per l'html e lo stesso fa hugo"
o se siete contrari per principio a giocare nel browser. su questo
punto sono inamovibile, ma sono ansioso di conoscere le opinioni
riguardo all'interfaccia (stabilito il punto fermo del mio progetto).
per idra, ho già visto il sistema, da anni e parecchie volte, ma è più
simile a una cyoa dinamica rispetto a quello che sto sviluppando io.
ah, prevengo anche saintpumpkin: sì, potrei fare la stessa cosa in
flash rispetto al javascript, sì, già lo stai facendo tu, sì, rispetto
il tuo punto di vista ma non lo condivido, il flash mi fa schifo per
applicazioni non grafiche e l'actionscript è una versione dell'ecma
esattamente come il javascritp, con la differenza che facendo
un'avventura testuale in javascript non devo avere a che fare con
grafica vettoriale, frame e scene che sono perfette per un giochetto,
ideali per un filmano ma non c'entrano nulla con quello che sto
facendo io!
grazie dell'attenzione, aspetto i vostri commenti!
gustavo


title: IF browser-based (javascript)

author: Enrico Colombini

text:
pistacchio wrote:
> il sistema a menu contestuale, invece, funziona in maniera simile ma
> il numero di azioni eseguibili su un oggetto non č fisso, ma cambia a
> seconda dell'oggetto. Cosě se in una stanza ho un bicchiere d'acqua e
> una leva, clickando sulla leva saranno disponibili le azioni "esamina,
> tira, spingi" e clickando sul bicchiere "esamina, prendi, bevi".
Ho fatto un paio di mesi fa uno studio su un sistema basato su principi
simili: e' perfettamente fattibile in javascript, anche se bisogna
sudare un bel po' con css e dom (mi sono scritto una libreria
portatile). Il save e' un problema, ma si riesce a risolvere.
Voleva essere un discendente di Idra con un'interfaccia innovativa, ma
poi ho trovato lavoro... e fin troppo (anche se non so per quanto).
   .Erix.


title: IF browser-based (javascript)

author: Lorenzo Marcantonio

text:
On 17 Lug, 10:30, pistacchio <
pistacc...@gmail.com
> wrote:
> (e parlo di interi sistemi operativi come eyeos, word processor,
> giochi di ogni tipo), sono convinto che il futuro dell'if passi, o
> possa passare, per il web. i motivi che mi rendono convinto di cioè
Scelta opinabile, ma e' meglio di tante altre applicazioni che
vogliono propinarci via web...
> 1. una IF è un'applicazione testuale, quindi perfetta per essere
> portata sul web
Giusto!
> 2. la possibilità immediata di avere un sistema di formattazione del
> testo (colori, disposizione del testo, ma anche immagini o audio
Giustissimo!
> 3. l'eventuale possibilità di avere, a pochi click di distanza dal
> gioco, un forum per l'aiuto o la segnalazione di errori o giudizi, un
> sistema di help rappresentato da altre pagine, eventualmente nua
> pagina in cui raccogliere le statistiche sugli utenti che hanno finito
> il gioco in meno tempo o con più punti ecc.
Oibo', non che a lanciare un url da un programma sia un compito
epico :P (anche se in inform concordo non e' possibile)
> 4. un sistema basato sul browser è immediatamente compatibile con una
> tendenza che da sempre accompagna lo sviluppo delle IF, ovvero
> l'essere multipiattaforma.
Sogna! Su UN browser :P
> 5. nessuna necessità di installare alcun nuovo software per giocare
> all'avventura (ammesso che il computer abbia un browser installato,
> cosa certa nella stragrande maggioranza dei casi)
Plausibile, ma i runtime per IF non sono dei mattoni, dopotutto...
> 6. nessuna necessità di rilasciare "aggiornamenti" del software o
> versioni multiple dei gioco, visto che basta uploadare una nuova
> versione corretta del gioco perchè tutti gli utenti giochino sempre
> all'ultima versione disponibile.
E per le salvate? Quanto ti insultano!
> nella mia ricerca per un sistema di sviluppo mi concentrai
> inizialmente sul PHP, ovvero un sistema combinato client / server.
> l'ovvio problema era rappresentato dalla necessità di essere collegati
> in rete per giocare oltre a una non immediatezza di risposta ai
> comandi. mi spostai quindi su un tipo di applicazione esclusivamente
> client basato su javascript.
Plausibile
> una cosa che mi è parsa chiara da subito, arrivato a questo punto, è
> che, per sfruttare il mezzo e poichè un sistema basato sul web avrebbe
> attratto parecchi neofiti (non c'è necessità di cercare un client per
> le if, installarlo e scaricare il gioco) o giocatori occasionali o
> solo curiosi, avrei abbandonato la "riga di comando", così cara e
> caratteristica dell'IF ma anche, per certi aspetti, meno immediata dal
> "click del mouse" che chi naviga il web è abituatuato ad usare per
> ogni tipo di interazione le pagine.
Buuuu buuuu :D Il parser monoparola da palmari in sostanza?
> seconda dell'oggetto. Così se in una stanza ho un bicchiere d'acqua e
> una leva, clickando sulla leva saranno disponibili le azioni "esamina,
> tira, spingi" e clickando sul bicchiere "esamina, prendi, bevi".
Moooolto limitativo imho. Non per fare il guess-the-verb ma cosi'
rischi di sciupare un sacco di enigmi...
> il tipo di approccio è radicalmente differente rispetto a quello della
> if tradizionale, con vantaggi e svantaggi diversi a seconda del metodo
> ed entrambi richiedono di progettare le avvventure in maniera non
> comparabile rispetto a quelle tradizionali.
Fai un'avventura grafica con interfaccia testuale in sostanza!
> entrambi i sistemi, per iniziare, escludono il problema che affligge
> molte IF noto come "indovina la parola". mi trovo davanti a un puzzle,
> so cosa devo fare, è ovvio che è quella la soluzione, ma non so come
> comunicarla al parser perchè continua a non capire (o non accettare o
> mal interpretare) le mie istruzioni.
Il qual problema e' pressoche' scomparso da almeno un decennio, mi
sembra... altrimenti non e' stato fatto abbastanza beta testing del
gioco per stabilire le idee che ronzano in testa ai giocatori!
> immaginiamo un ripiano pieno di polvere. con il sistema a verbi fissi
> posso "esaminare" la polvere per scoprire che è lì da anni, "usare il
> fazzoletto con la polvere" e pulire il ripiano, e magari persino
E perche' non prendere la polvere? :P E comunque il verbo USA e'
considerato un abominio nella IF :PPPP
> bilanciata in negativo dal problema del guidare troppo il giocatore
> verso la soluzione. i puzzle non possono mai essere improntati a
> qualcosa di strano e particolare, semplicemente perchè soluzione cosa
> strana e particolare sarebbe immediatamente visibile al giocatore.
Esattamente quello che intendevo prima!
> certo, i menu contestuali sono flessibili, per cui, rimanendo
> all'esempio della polvere, si potrebbe rendere il verbo "sniffa"
> visibile solo se precedentemente il personaggio ha frugato nei
> cassetti, trovato la rinazina spry nasale e l'ha usata (prima aveva il
> naso chiuso e quindi non poteva sniffare)
Mi sembra un po' forzata come soluzione ma in effetti e' interessante!
> sono quasi certo che almeno due argomenti verranno fuori come
> risposte:
> 1. idra
> 2. inform
>
> per quanto riguarda inform, vi prego dall'astenervi dalla discussione
> se l'unico apporto è "perchè reinventare la ruota? un altro sistema di
> sviluppo? c'è già inform, con la versione sette è diverntato perfetto
> e se sei fissato con il web ci sono le applet java come interpreti per
> i z5, o prova tads che ha il supporto per l'html e lo stesso fa hugo"
Inform e' tutto fuorche' perfetto (secondo me e' e rimane un
accrocchio di linguaggio, ma dato che c'e' la pappa pronta perche'
rifare un parser da capo?)... lo stesso Nelson ha fatto I7 come un
preprocessore da dare in pasto a I6, perche' aveva paura a toccare il
compilatore....
> per idra, ho già visto il sistema, da anni e parecchie volte, ma è più
> simile a una cyoa dinamica rispetto a quello che sto sviluppando io.
Si, idra in effetti e' tutta un'altra cosa...
> ah, prevengo anche saintpumpkin: sì, potrei fare la stessa cosa in
> flash rispetto al javascript, sì, già lo stai facendo tu, sì, rispetto
> il tuo punto di vista ma non lo condivido, il flash mi fa schifo per
> applicazioni non grafiche e l'actionscript è una versione dell'ecma
Il flash mi fa schifo punto :D
Oibo', fare una cosa del genere in javascript non e' poi tanto
terrificante... se prendiamo una cosa tipo il famoso modulo base, in
meno di una settimana si potrebbe adattare in js e farlo girare in un
browser... da li a trasformare il parser biparola in un punta-e-clicca
basato su eventi dom non passa tanto...
Per curiosita'... come hai intenzione di salvare? in un cookie
gigante? (non e' implausibile, hai 4k scarsi di spazio a disposizione)
Sinceramente la cosa non mi interessa piu' di tanto... altrimenti
dovrei fare un browser basato su gargoyle :D
Idee da sviluppare comunque


title: IF browser-based (javascript)

author: saintpumpkin

text:
Post interessante (ma sono al lavoro e non l'ho ancora letto
interamente), sappi che condivido appieno la tua riflessione.
Quello che mi lascia dubbioso sulle if online sono il sistema di
salvataggio (database? cookie?) che non mi sembra adatto. Vi è inoltre
la modalità di gioco che mi fa riflettere, le connessioni ad internet
oggi giorno costano veramete poco ma non ho mai trovato "esaltante"
l'idea di poter giocare solamente connesso alla rete.
L'ideale sarebbe sviluppare il gioco con javascript per permettere il
download dell'avventura e poterci quindi giocare offline anche su
dispositivi portatili quali cellulari dell'ultima generazione. Il
problema in questo caso nasce dal fatto che il codice sarebbe
completamente "scoperto" e sarebbe quindi veramente troppo facile
venire a capo dell'avventura (senza contare che javascript è
supportato in maniera differente dai vari browser).
Ad ogni modo mi sto orientando anch'io su un sistema di gioco web-
based con parser "limitato" (rimane la possibilità di digitare
azioni).
Discutiamone insieme, mi piacerebbe sapere cosa ne pensano tutti.


title: IF browser-based (javascript)


title: IF browser-based (javascript)

text:
saintpumpkin wrote:
> Quello che mi lascia dubbioso sulle if online sono il sistema di
> salvataggio (database? cookie?) che non mi sembra adatto.
Ci ho pensato a lungo: si puo' aprire una finestra contenente un
elemento con i dati e chiedere al giocatore di fare "Salva con nome"
(non e' tutto qui, ma il principio di base e' quello).
Con FF 2 "Salva con nome" salva il DOM, ma non e' portatile.
> L'ideale sarebbe sviluppare il gioco con javascript per permettere il
> download dell'avventura e poterci quindi giocare offline anche su
> dispositivi portatili quali cellulari dell'ultima generazione.
Si puo' (oddio, con i cellulari c'e' un problema di dimensioni,
sicuramente quello a cui stavo lavorando io non ci starebbe neanche morto).
> Il problema in questo caso nasce dal fatto che il codice sarebbe
> completamente "scoperto" e sarebbe quindi veramente troppo facile
> venire a capo dell'avventura
Secondome non e' un problema: lo puoi comunque fare col Web, no? Se uno
vuole rovinarsi il divertimeno, affari suoi.
> (senza contare che javascript č
> supportato in maniera differente dai vari browser).
Non me ne parlare... ci ho messo un bel po' a farmi una libreria
portatile (FF 2, IE 7, Opera 9, Safari), sia pure limitata al mio uso.
Comunque si puo' fare.
   .Erix.


title: IF browser-based (javascript)

author: Vinnie Costante

text:
Il Tue, 17 Jul 2007 08:30:35 +0000, pistacchio ha scritto:
Io non sono esattamente dentro appassionato di text adventure però per il
salvataggio cosi mi è venuto in mente una cosa.
Intanto per Il fatto della nuova versione giocabile e che farebbe
lamentare i giocatori con un salvataggio in attivo basterebbe o rendere
compatibile il salvataggio oppure semplicemente concedere il poter
giocare alla versione che si stava giocando... non mi sembra un gran
problema.
Per il salvataggio due idee mi son venute.
Consentire di lasciare i salvataggi anche sul server (quanto occuperanno
poi?) e sfruttarli da li oppure inventare uno modo per inviarli in email
e reinviarli ad un indirizzo per riprendere il gioco da dove lo si era
lasciato. Entrambi sono portabili.
Un altra cosa sarebbe bello ovviamente concedere sia il gioco off-line
che on line a scelta.
Ciauz.


title: IF browser-based (javascript)

text:
On 18 Lug, 18:08, Enrico Colombini <erix-at-erix-
punto...@invalid.invalid> wrote:
> Ci ho pensato a lungo: si puo' aprire una finestra contenente un
> elemento con i dati e chiedere al giocatore di fare "Salva con nome"
> (non e' tutto qui, ma il principio di base e' quello).
> Con FF 2 "Salva con nome" salva il DOM, ma non e' portatile.
non ho capito benissimo quello che intendi. In pratica vorresti
"esportare" dei dati sul tuo pc
>
> Secondome non e' un problema: lo puoi comunque fare col Web, no? Se uno
> vuole rovinarsi il divertimeno, affari suoi.
Invece per me è un grosso problema... tutti sarebbero in grado di
sapere tutto ed il tuo gioco non avrebbe segreti !
>
> Non me ne parlare... ci ho messo un bel po' a farmi una libreria
> portatile (FF 2, IE 7, Opera 9, Safari), sia pure limitata al mio uso.
> Comunque si puo' fare.
>
....esatto si può fare
Ad ogni modo al momento sono orientato su una soluzione php/ajax con
parser limitato (azioni standard ed un campo di testo per inserire
l'azione, nessuna grammatica)...


title: IF browser-based (javascript)

text:
> Per il salvataggio due idee mi son venute.
> Consentire di lasciare i salvataggi anche sul server (quanto occuperanno
> poi?) e sfruttarli da li oppure inventare uno modo per inviarli in email
> e reinviarli ad un indirizzo per riprendere il gioco da dove lo si era
> lasciato. Entrambi sono portabili.
> Un altra cosa sarebbe bello ovviamente concedere sia il gioco off-line
> che on line a scelta.
>
Per quanto mi riguarda l'ostacolo più grande è proprio quello del
gioco offline, certo con flash si risolverebbe un po tutto ma non ho
voglia di rimettermi a studiare actionscript :) (anche se....)


title: IF browser-based (javascript)

text:
saintpumpkin ha scritto:
> Quello che mi lascia dubbioso sulle if online sono il sistema di
> salvataggio (database? cookie?) che non mi sembra adatto. Vi è inoltre
> la modalità di gioco che mi fa riflettere, le connessioni ad internet
> oggi giorno costano veramete poco ma non ho mai trovato "esaltante"
> l'idea di poter giocare solamente connesso alla rete.
il salvataggio in effetti E' un problema, ma non insormontabile. Se vuoi
hostare il gioco in una tua pagina e su un tuo sito, con una chiamata al
server puoi memorizzare i dati in un database, e questa è soluzione pià
ovvia. la cosa bello dello sviluppo in javascript, però, è che il gioco
è facilmente usufruibile sia in rete sia in locale. l'alternativa dei
cookies, a cui avevo pensato, ha la limitazione della capacità, come fai
notare tu stesso. andrebbe bene per avventure non lunghe, ma non per
tutte. la soluzione di colombini è quella a cui pensavo anche io: una
stringa fa copiare / incollare contenente i dati da registrare.
calcola che è molto facile comprimere / offuscare / crittare il codide
javascript.
> L'ideale sarebbe sviluppare il gioco con javascript per permettere il
> download dell'avventura e poterci quindi giocare offline anche su
> dispositivi portatili quali cellulari dell'ultima generazione. Il
> problema in questo caso nasce dal fatto che il codice sarebbe
> completamente "scoperto" e sarebbe quindi veramente troppo facile
> venire a capo dell'avventura (senza contare che javascript è
> supportato in maniera differente dai vari browser).
il problema dell'incompatibilità è lo stesso che incontra con lo
sviluppo di ogni pagina web. per quanto riguarda il codice:
1. se sbirci levi divertimento a te stesso
2. come dicevo prima, il codice è offuscabile.


title: IF browser-based (javascript)

text:
saintpumpkin wrote:
> non ho capito benissimo quello che intendi. In pratica vorresti
> "esportare" dei dati sul tuo pc
Da javascript crei una nuova pagina, il cui sorgente contiene i dati da
salvare (hidden) e la mostri in una finestra che chiede al giocatore di
fare "Salva con nome".
Il browser salva il sorgente di questa pagina, che contiene appunto i
dati del gioco.
Viceversa per ricaricare (e' un pelino meno ovvio, ma fattibile).
Non l'ho provato per intero, ma dovrebbe funzionare.
   .Erix.


title: IF browser-based (javascript)

text:
Enrico Colombini ha scritto:

la mia idea era quella di una stringa crittata e compressa i dati che
servono (quelli da salvare) da mostrare al giocatore che la copia
(magari la salva in un documento txt) e poi incolla in un'apposito campo
per caricare. non è molto funzionale e la tua idea mi pare migliore. il
problema è che entrambi sono scomodi per salvataggi e caricamentu rapidi
(per esempio durante il corso di un'avventura).
io ho il sospetto che in 4k di cookies si possa mettere molta più roba
di quello che uno può sospettare..


title: IF browser-based (javascript)

text:
pistacchio wrote:
> la mia idea era quella di una stringa crittata e compressa i dati che
> servono (quelli da salvare) da mostrare al giocatore che la copia
> (magari la salva in un documento txt) e poi incolla in un'apposito campo
> per caricare.
Avevo avuto anch'io l'idea di usare un "server umano" ai tempi di Idra,
ma conoscendo l'utente medio l'avevo scartata subito :-)
> il problema č che entrambi sono scomodi per salvataggi e caricamentu
 > rapidi (per esempio durante il corso di un'avventura).
Beh, il salvataggio rapido si puo' fare in memoria. Come pure
un'eventuale history per sfogliarla indietro/avanti in stile browser.
> io ho il sospetto che in 4k di cookies si possa mettere molta piů roba
> di quello che uno puň sospettare..
Ma anche molta meno, dato che parecchi caratteri non sono ammessi e
vanno sostituiti da sequenze di escape. Alla fine e' probabilmente la
stessa che uno potrebbe sospettare :-)
Scherzi a parte, hai ragione: con un po' di compressione (es. salvare
indici in hex invece che stringhe e bit field invece che interi) ci si
puo' far stare un po' di roba. Dopotutto i save file di Avventura nel
castello erano da 1 kB circa, e non erano compressi.
   .Erix.


title: IF browser-based (javascript)

text:
> calcola che è molto facile comprimere / offuscare / crittare il codide
> javascript.
ma sai che non ho idea di come si faccia! Illuminami :)
> il problema dell'incompatibilità è lo stesso che incontra con lo
> sviluppo di ogni pagina web. per quanto riguarda il codice:
> 1. se sbirci levi divertimento a te stesso
> 2. come dicevo prima, il codice è offuscabile.
Tieni ben presente che quando si crea una pagina web javascript si
tende ad usarlo il meno possibile.... mentre in un progetto del genere
javascript dovrebbe farlo da padrone.


title: IF browser-based (javascript)

text:
saintpumpkin ha scritto:
>> calcola che è molto facile comprimere / offuscare / crittare il codide
>> javascript.
>
> ma sai che non ho idea di come si faccia! Illuminami :)
>
ci sono decine di algoritmi che lo fanno in giro sul web! basta cercare
su google javascript+obfuscate
>> il problema dell'incompatibilità è lo stesso che incontra con lo
>> sviluppo di ogni pagina web. per quanto riguarda il codice:
>> 1. se sbirci levi divertimento a te stesso
>> 2. come dicevo prima, il codice è offuscabile.
>
> Tieni ben presente che quando si crea una pagina web javascript si
> tende ad usarlo il meno possibile.... mentre in un progetto del genere
> javascript dovrebbe farlo da padrone.
1. se per "si tende" intendi "io tendo", mi sta bene, ma se lo
generalizzi mi pare un'enorme stupidaggine che non so dove hai
letto/sentito! specie ora che la tecnologia ajax si sta diffondendo.
prova a sbirciare il codice, non so, di gmail. ci sono il 2% di righe di
html e il 98% di righe di javascript. persino in applicazioni non
dinamiche e non basate su ajax la percentual di codice javascript è
altissima, sbircia l'homepage di ebay o quella di yahoo (anche qui il
javascript è ben oltre il 50% del codice totale!) e sto citando siti
grandi e famosi, ma è così ovunque, almeno che tu non vada a vedere le
pagine statiche di geocities fatte dai tredicenni tipo "io e il mio
criceto marty"
2. bah.. detto questo, che senso ha suggerire di limitare l'uso del
javascript (??) a uno che sta programmando un sistema per IF in javascript?


title: IF browser-based (javascript)

text:
On 20 Lug, 10:08, pistacchio <
pistacc...@gmail.com
> wrote:
> saintpumpkin ha scritto:
>
>
> 1. se per "si tende" intendi "io tendo", mi sta bene, ma se lo
> generalizzi mi pare un'enorme stupidaggine che non so dove hai
> letto/sentito! specie ora che la tecnologia ajax si sta diffondendo.
> prova a sbirciare il codice, non so, di gmail. ci sono il 2% di righe di
> html e il 98% di righe di javascript. persino in applicazioni non
> dinamiche e non basate su ajax la percentual di codice javascript è
> altissima, sbircia l'homepage di ebay o quella di yahoo (anche qui il
> javascript è ben oltre il 50% del codice totale!) e sto citando siti
> grandi e famosi, ma è così ovunque, almeno che tu non vada a vedere le
> pagine statiche di geocities fatte dai tredicenni tipo "io e il mio
> criceto marty"
hai citato i casi più ecclatanti...
se escludiamo "l'ajax" io rimango della mia idea.
Ad ogni modo SCUSAMI se ho dimenticato di digitare imho !
>
> 2. bah.. detto questo, che senso ha suggerire di limitare l'uso del
> javascript (??) a uno che sta programmando un sistema per IF in javascript?
Nessuna !
Io ho fatto una considerazione sulla base delle mie idee, si stava
discutendo no?


title: IF browser-based (javascript)

text:
saintpumpkin ha scritto:
> On 20 Lug, 10:08, pistacchio <
pistacc...@gmail.com
> wrote:
>> saintpumpkin ha scritto:
>>
>>
>> 1. se per "si tende" intendi "io tendo", mi sta bene, ma se lo
>> generalizzi mi pare un'enorme stupidaggine che non so dove hai
>> letto/sentito! specie ora che la tecnologia ajax si sta diffondendo.
>> prova a sbirciare il codice, non so, di gmail. ci sono il 2% di righe di
>> html e il 98% di righe di javascript. persino in applicazioni non
>> dinamiche e non basate su ajax la percentual di codice javascript è
>> altissima, sbircia l'homepage di ebay o quella di yahoo (anche qui il
>> javascript è ben oltre il 50% del codice totale!) e sto citando siti
>> grandi e famosi, ma è così ovunque, almeno che tu non vada a vedere le
>> pagine statiche di geocities fatte dai tredicenni tipo "io e il mio
>> criceto marty"
>
> hai citato i casi più ecclatanti...
> se escludiamo "l'ajax" io rimango della mia idea.
> Ad ogni modo SCUSAMI se ho dimenticato di digitare imho !
tanto per polemica, ma poi la chiudiamo qui: non ho citato "i casi più
eclatanti", ho citato tre dei 10 siti più visitati del web (fonte:
http://toolbar.netcraft.com/stats/topsites
)
prendi i primi dieci (eliminando le varie occorrenze di google come
google.de
 e
google.com
 che è lo stesso, prendi i primi dieci *singoli*),
apri l'homepage e vedi il codice.
persino l'homepage di google (quella classica, non parlo di igoogle) che
è minimale ha comunque un buon 30 / 40% di javascript (e calcola che è
codice compresso).
-yahoo: già detto
-microsoft: pare poco, ma perchè il codice js lo carica da pagine esterne:
http://i3.microsoft.com/shared/core/1/js/lsp.js
http://i3.microsoft.com/shared/core/1/js/library.js
complessivamente 34kb di javascript, più quello sulla pagina
-bbc: oltre a quello sulla pagina carica js dai file:
http://news.bbc.co.uk/js/newsi/latest/newsi.js
http://newsimg.bbc.co.uk/nol/shared/js/nol4.js
http://newsimg.bbc.co.uk/nol/ifs_news/js/av.js
http://newsimg.bbc.co.uk/nol/shared/js/livestats_v1_1.js
http://newsimg.bbc.co.uk/nol/shared/js/csf_2.js
http://www.bbc.co.uk/radio/aod/radioplayer.js
per un totale di una 40ina di kb
-foxnew: anche qui javascript compresso in tutto il sito e caricato da file
gmail: già citato
ricerca immagini google : come homepage di google
ebay : già citato
cnn.com
 : carica javascript da
http://i.l.cnn.net/cnn/.element/js/2.0/ad_head0.js
http://i.l.cnn.net/cnn/cnn_adspaces/cnn_adspaces.js
http://i.l.cnn.net/cnn/.element/js/2.0/scripts/prototype.js
http://i.l.cnn.net/cnn/.element/js/2.0/scripts/scriptaculous.js
http://i.l.cnn.net/cnn/.element/js/2.0/csiManager.js
http://i.l.cnn.net/cnn/.element/js/2.0/StorageManager.js
http://i.l.cnn.net/cnn/.element/js/2.0/local.js
http://i.l.cnn.net/cnn/.element/js/2.0/main.js
più, ovviamente, quello nella pagina che occupa un buon 30/40% del totale.
-
http://search.msn.com/
 prova a fare tu l'esercizio. indovina cosa la
fa da padrone nel codice? bravo, javascript!
ti faccio notare che a parte gmail nessuna delle altre applicazioni
(parzialmente l'homepage di yahoo) sono basate su ajax.
al di là del fatto che sono polemico di mio :P voglio solo aprirti gli
occhi sul modo in cui funzionale il web REALE. visto che parli di
programmazione web e penso ti ci diletti. avere preconcetti su qualcosa
come per esempio il javascript significa non avere la possibilità di
essere professionali, competititivi e realistici nel mondo dello
sviluppo su internet. il web si aggiorna di continuo, le tecnologie
vanno e vengono. se rimani al web del 2003 è anche possibile che gli usi
che venivano fatti del javascript erano cose tipo "inserisci il tuo nome
qui sotto e clicka il bottone!" tu lo facevi e veniva scritto grande
sulla pagina "CIAO SAINTPUMKIN!" o quegli script che scrivono l'ora
nella pagina "ehi, sono le 17.21!". solo che dal 2003 il web è cambiato
radicalmente, se non hai intenzione di imparare a usare (e imparare
QUANDO usare) tecnologie come javascript, css e un linguaggio
server-side + database, se non hai intenzione di supportare firefox che
al momento ha quasi un quarto dell'utenza in europa, se non hai
intenzione di abbandonare la formattazione usando i tables ecc è inutile
avvicinarsi allo sviluppo del web. vedere quello che accade nei 10 siti
più visitati al mondo può dare un'idea abbastanza precisa di quello che
è il web e di dove sta andando, considerando che sono i siti sui quali
lavorano i migliori e più pagati professionisti mondiali del settore.
per la cronaca: nota come nei siti che ti ho citato non compare il flash
  (se non in banner pubblicitari laterali!) e come lì dove una volta si
sarebbe usato il flash (menu, tendine ed effetti vari) i professionisti
hanno preferito utilizzare il javascript per "simulare" effetti grafici
e di animazione "alla flash" ;)
>> 2. bah.. detto questo, che senso ha suggerire di limitare l'uso del
>> javascript (??) a uno che sta programmando un sistema per IF in javascript?
>
> Nessuna !
> Io ho fatto una considerazione sulla base delle mie idee, si stava
> discutendo no?
a giorni spero di riuscire a postare una preview del sistema a cui sto
lavorando.


title: IF browser-based (javascript)

text:
>
> tanto per polemica, ma poi la chiudiamo qui: non ho citato "i casi più
> eclatanti", ho citato tre dei 10 siti più visitati del web
> (fonte:
http://toolbar.netcraft.com/stats/topsites
)
che diavolo significa ?
Il web non sono solo quei 10 siti pidocchiosi e non si sviluppa tutti
i giorni un'applicazione web 2.0 !!!
>
> persino l'homepage di google (quella classica, non parlo di igoogle) che
> è minimale ha comunque un buon 30 / 40% di javascript (e calcola che è
> codice compresso).
buon per lui...
> al di là del fatto che sono polemico di mio :P voglio solo aprirti gli
> occhi sul modo in cui funzionale il web REALE. visto che parli di
> programmazione web e penso ti ci diletti.
è il mio lavoro...
> avere preconcetti su qualcosa
> come per esempio il javascript significa non avere la possibilità di
> essere professionali,
e chi ha preconcetti ?????????????
ho iniziato a sviluppare il mio sistema e fino ad ora ho utilizzato
solamente Javascritpt ... pensa te.
> competititivi e realistici nel mondo dello
> sviluppo su internet. il web si aggiorna di continuo, le tecnologie
> vanno e vengono. se rimani al web del 2003 è anche possibile che gli usi
> che venivano fatti del javascript erano cose tipo "inserisci il tuo nome
> qui sotto e clicka il bottone!" tu lo facevi e veniva scritto grande
> sulla pagina "CIAO SAINTPUMKIN!"
la prendo come una presa per il culo.
> o quegli script che scrivono l'ora
> nella pagina "ehi, sono le 17.21!". solo che dal 2003 il web è cambiato
> radicalmente, se non hai intenzione di imparare a usare (e imparare
> QUANDO usare) tecnologie come javascript, css e un linguaggio
> server-side + database, se non hai intenzione di supportare firefox che
> al momento ha quasi un quarto dell'utenza in europa, se non hai
> intenzione di abbandonare la formattazione usando i tables ecc è inutile
> avvicinarsi allo sviluppo del web.
sono anni che non uso tabelle e sviluppo i siti testandoli prima si
firefox e poi su ie... grazie per la lezione comunque.
Seconda presa per il culo.
> vedere quello che accade nei 10 siti
> più visitati al mondo può dare un'idea abbastanza precisa di quello che
> è il web e di dove sta andando,
secondo me invece i 10 siti più visitati al mondo non sono il web....
> considerando che sono i siti sui quali
> lavorano i migliori e più pagati professionisti mondiali del settore.
yawn
> per la cronaca: nota come nei siti che ti ho citato non compare il flash
>   (se non in banner pubblicitari laterali!) e come lì dove una volta si
> sarebbe usato il flash (menu, tendine ed effetti vari) i professionisti
> hanno preferito utilizzare il javascript per "simulare" effetti grafici
> e di animazione "alla flash" ;)
benissimo ! concordo con la loro scelta....
> a giorni spero di riuscire a postare una preview del sistema a cui sto
> lavorando.
buon per te.


title: IF browser-based (javascript)

text:
[snip spocchia]
oops, non č rimasto nulla da commentare.
ciao, buona giornata!


title: IF browser-based (javascript)

author: rgrassi

text:
Sono certo che avete anche considerato il fatto che il problema non e'
la mancanza di tools di authoring, ma gli autori ed i giochi, vero? :)
Rob
P.S. Saint, perche' tra un js e l'altro non mi mandi la traduzione di
quel file di hugo che ti eri impegnato a fare? :)


title: IF browser-based (javascript)

text:

ah ero convinto che l'avessi già completato te.
ok, te lo spedisco al più presto.


title: IF browser-based (javascript)

text:
Ciao,
> ok, te lo spedisco al più presto.
Lascia stare, avevo il pomeriggio semilibero e l'ho fatto io.
Rob


title: IF browser-based (javascript)

text:

...lol
(non mi smentisco mai)


title: CHAOS ENGINE

author: Michele Caloro

text:
Qualcuno ricorda il vecchi della Bitmap Brothers -
CHAOS ENGINE
e magari dove scaricarlo ???

Grazie

--
www.pillole.it
micaloro
Caloro


title: Declino delle AT...

author: Vincenzo Scarpa

text:
Salve a tutti
bof... qualcuno di voi ha per caso letto l'articolo in questione da me
scritto e che è apparso sull'ultimo numero di Terra D'IF? :)
Siete anche voi d'accordo che le AT hanno perso il loro "alleato"
(cioè il computer) o la pensate diversamente? :-))
Saluti da
Vincenzo Scarpa
http://www.casalengo.it/vscarpa/inform/manuale


title: Declino delle AT...

author: Gabriele Lazzara

text:
> bof... qualcuno di voi ha per caso letto l'articolo in questione da me
> scritto e che č apparso sull'ultimo numero di Terra D'IF? :)
>
> Siete anche voi d'accordo che le AT hanno perso il loro "alleato"
> (cioč il computer) o la pensate diversamente? :-))
Mah sicuramente le AT attraggono meno di un gioco con molta grafica e
sonoro...
A volte tento di avvicinare un mio amico alle AT; spesso mi risponde che
senza grafica si perde gran parte della bellezza di un gioco...
Giocando anch'io a giochi di ultima generazione, devo dire che
onestamente
aspetto con piů trepidazione l'ultimo episodio di Gran Thief Auto
rispetto a
Old Pecos Town 2 (che perň aspetto...).
Nonostante ciň ho comunque voglia di giocare e soprattutto scrivere AT.
I fruitori di AT comunque esistono. Ed č da questo che bisogna partire.
Ci sono vari modi di divertirsi col PC: uno di questi č giocare/fare
avventure testuali.
Saluti,
      Lazy.

--
Posted via Mailgate.ORG Server -
http://www.Mailgate.ORG


title: Declino delle AT...

author: Giancarlo Niccolai

text:
Gabriele Lazzara wrote:
> Giocando anch'io a giochi di ultima generazione, devo dire che
> onestamente
> aspetto con più trepidazione l'ultimo episodio di Gran Thief Auto
> rispetto a
> Old Pecos Town 2 (che però aspetto...).
Anche io aspetto Never Winter Nights 2 e Unreal Tournament 2005; eppure
penso proprio che potendo scegliere, mi andrebbe MOLTO più a genio una
nuova saga di Eddings al livello del Belgariad (il resto è più o meno da
dimenticare), o perché no, fra UT2005 e un nuovo libro di Azar Nafsi avrei
quanto meno parecchi tentennamenti.
Se riuscissimo a portare le AT a questo livello letterario, non credo che le
AT sarebbero in crisi.
Giancarlo Niccolai.


title: Declino delle AT...

text:
On Thu, 24 Feb 2005 14:29:41 +0000 (UTC), "Gabriele Lazzara"
<
schope...@tiscali.it
> wrote:
>
>> bof... qualcuno di voi ha per caso letto l'articolo in questione da me
>> scritto e che è apparso sull'ultimo numero di Terra D'IF? :)
>>
>> Siete anche voi d'accordo che le AT hanno perso il loro "alleato"
>> (cioè il computer) o la pensate diversamente? :-))
>
>Mah sicuramente le AT attraggono meno di un gioco con molta grafica e
>sonoro...
In realtà, almeno imho, questo problema si poneva già all'epoca degli
8 bit. Tuttavia (sempre IMHO) le scarse capacità grafiche dell'epoca
"giustificavano" in qualche modo giochi solo testuali (almeno a
livello di massa) sui computer. Da qui seguiva una pubblicità
enorme...

>A volte tento di avvicinare un mio amico alle AT; spesso mi risponde che
>senza grafica si perde gran parte della bellezza di un gioco...
Ci sono molte persone non si avvicinano ai libri, eppure questi
esistono ancora... :-)
>Giocando anch'io a giochi di ultima generazione, devo dire che
>onestamente
>aspetto con più trepidazione l'ultimo episodio di Gran Thief Auto
>rispetto a
>Old Pecos Town 2 (che però aspetto...).
>Nonostante ciò ho comunque voglia di giocare e soprattutto scrivere AT.
>I fruitori di AT comunque esistono. Ed è da questo che bisogna partire.
>Ci sono vari modi di divertirsi col PC: uno di questi è giocare/fare
>avventure testuali.
Certo.
>Saluti,
>      Lazy.



title: Declino delle AT...

text:
On Thu, 24 Feb 2005 23:45:10 +0100, Giancarlo Niccolai
<
searc...@ingoogle.com
> wrote:
>Gabriele Lazzara wrote:
>
>
>> Giocando anch'io a giochi di ultima generazione, devo dire che
>> onestamente
>> aspetto con più trepidazione l'ultimo episodio di Gran Thief Auto
>> rispetto a
>> Old Pecos Town 2 (che però aspetto...).
>
>Anche io aspetto Never Winter Nights 2 e Unreal Tournament 2005; eppure
>penso proprio che potendo scegliere, mi andrebbe MOLTO più a genio una
>nuova saga di Eddings al livello del Belgariad (il resto è più o meno da
>dimenticare), o perché no, fra UT2005 e un nuovo libro di Azar Nafsi avrei
>quanto meno parecchi tentennamenti.
Anch'io li aspetterei (se avessi poi il tempo di giocarli)... :))
>
>Se riuscissimo a portare le AT a questo livello letterario, non credo che le
>AT sarebbero in crisi.
Mah... anche le avventure testuali stile Di Bello-Colombini andrebbero
bene. Il problema è che si è in qualche modo perso imho il "partner
commerciale" principale ovvero il computer a 8 bit tipo C64 e
Spectrum.



title: Declino delle AT...

text:
On Fri, 25 Feb 2005 09:00:40 GMT, Vincenzo Scarpa <
sca...@libero.it
>
wrote:

Mi riferivo naturalmelmente a quelle avventure testuali che
privilegiano il gioco piuttosto che la narrazione... :)



title: Idea!

author: Regium Lepidi corp.

text:
Ciao a tutti.
Qualche giorno fa ho finito l'Apprendista Stregone, dopo un po' (un bel po')
che non mettevo mano ad avventure testuali... così, mi è venuta voglia di
lavorarci un po' sopra.
L'idea è la seguente: prendere in mano il Modulo Base con cui sono fatte
tutte le avventure di Enrico Colombini (per lo meno quelle del libro
"Avventure", ve lo ricordate vero?) e convertirlo in Java. Non solo,
scrivere un servlet (una specie di CGI in Java, per chi non sapesse cosa
sono) e rendere così accessibile qualunque avventura scritta con questo
modulo base convertito su Internet... Poi, proprio volendo strafare, lo si
potrebbe rendere multiutente trasformando così le avventure in qualcosa di
simile ad un MUD.
Ho già fatto una conversione del modulo base in Rexx (per Amiga) qualche
anno fa, ricordo ancora bene la struttura, non sarebbe difficile. Se
qualcuno trova l'idea interessante potrebbe prendersi l'onere di farci
qualche giro di prova o (meglio ancora) scriverci un'avventurina sopra. Io
mi diverto a programmare, ma le avventure in stesse sè preferisco giocarle
che scriverle... non ho pazienza per definire tutti i dettagli di una storia
per fare una cosa fatta bene...
A proposito, se qualcuno vuole provare il mio modulo base in Rexx (detto
anche Venturexx) glielo do volentieri. Sull'interprete Rexx per PC (Regina,
io conosco solo quello) non funziona, ma forse con qualche sistemata si
mette ad andare. Avevo convertito anche l'avventura di esempio del libro
(quella sui microfilm). Su Amiga funzionava piuttosto bene.
Venturexx a parte, cosa ne dite dell'idea di portarlo in Java? Lo renderebbe
multipiattaforma, fruibile via Internet e multiutente. Naturalmente, una
cosa per volta... non bisogna avere fretta...
Attendo qualche commento... Ciao!
   Gianlu


title: Idea!

author: Glorfindel

text:
> Io mi diverto a programmare, ma le avventure in stesse sè preferisco
giocarle
>che scriverle... non ho pazienza per definire tutti i dettagli di una
storia
>per fare una cosa fatta bene...
>
A Sauron5 che ne dici??? forse hai trovato qualcuno per cui scrivere
un'avventura magari dopo l'esame, saluti
Glorfindel


title: Idea!

text:
[cut]
> L'idea è la seguente: prendere in mano il Modulo Base con cui sono fatte
> tutte le avventure di Enrico Colombini (per lo meno quelle del libro
> "Avventure", ve lo ricordate vero?) e convertirlo in Java. Non solo,
> scrivere un servlet (una specie di CGI in Java, per chi non sapesse cosa
> sono) e rendere così accessibile qualunque avventura scritta con questo
> modulo base convertito su Internet... Poi, proprio volendo strafare, lo si
> potrebbe rendere multiutente trasformando così le avventure in qualcosa di
> simile ad un MUD.
Benissimo!
Sono assai lieto di vedere che qualcuno prova a cimentarsi in un compito
tanto oneroso quanto d grande respiro.
Ti auguro di lavorare per bene, con serietà e di realizzare un prodotto di
buon valore e spessore.
Continua così.
A presto
Sauron5


title: Idea!

text:
> A Sauron5 che ne dici??? forse hai trovato qualcuno per cui scrivere
> un'avventura magari dopo l'esame, saluti
Chissà...forse dpo l'esame...boh?
Sauron5


title: Medievil

author: abc

text:
Ciao a tutti, ho scporto questo NG solo stasera.
Chi mi aiuta con Medievil?
Sono disperatissima.
Mi trovo nel parco del manicomio, al secondo indovinello e non so come vanno
disposte le facce.
Grazie anticipate.
Ci conto.


title: Medievil

author: Nello F.

text:
Salve: lei sta dando o chiedendo informazioni a cui nessuno, in questo
newsgroup, è interessato. Le consigliamo di cercare un luogo più adatto, e
magari di fare anche un tentativo con i motori di ricerca. Se, tuttavia,
questo newsgroup dovesse improvvisamente apparirle interessante, si legga le
FAQ, che vengono postate regolarmente, per avere un'idea di cosa discutiamo.
Cordialmente,
- Nello F. -
"L'artista è il creatore di cose belle.
        Ogni arte è insieme superficie e simbolo.
               L'arte rispecchia lo spettatore, non la vita.
                        Tutta l'arte è completamente inutile."
                                                                       O.W.
abc <
CARBa...@tin.it
> wrote in message 7mdlmc$99q$1...@nslave1.tin.it...



title: [Avventura dell'anno 2001] Premiazione su canale #if (info e istruzioni per l'uso)

author: Sauron

text:
Ben, noto con piacere che la proposta ha avuto successo.
Ogni tanto si vede che ne riesce bene una anche al sottoscritto ;-))
Dunque: la proposta è per lunedì prossimo venturo, ergo 6 maggio, ore 21:30
Il luogo è il medesimo: canale #if su IRC.
Per controproposte siate celeri ma soprattutto ricordate di essere flessibili e di
avere un po' di spirito di sacrificio: dite "Assolutamente lunedì sera no" solo se
davvero non potete, altrimenti qui non si combina nulla. Ovviamente le mie sono solo
indicazioni suscettibili di modifiche a furor di popolo. Spero di vedervi tutti.
Per informazioni su come connettersi se non erro è sufficiente seguire le informazioni
sul sito di riferimento (IF Italia, all'URL
http://digilander.iol.it/ifitalia/irc.html
)
Come segno di buona volontà e prevendendo ulteriori domande via e-mail e su newgroup
specialmente da chi non è pratico dò qui di seguito alcune delucidazioni che
dovrebbero permettere a tutti di essere presenti lunedì 5 maggio a sera sul canale #if
(ridondante, lo so!).
Ecco dunque alcune brevi indicazioni: per IRC si intende Internet Relay Chat, quelle
che volgarmente vengono chiamate "chat line". Bah. Cmq sia, per accedervi è necessario
avere un Client, ossia un programma che permetta di "interfacciarsi".
Il più comune è mIRC (reperibile sul sito
www.mirc.com
). Scaricate, installate.
Dopodichè settate come dovuto e tutto dovrebbe andare liscio. Cosa intendo per
settare? Beh (la mia è la versione 6.01 ma credo che le differenze siano minime tra le
varie versioni) (inutile aggiungere - o forse non è tanto inutile? - che per essere
sul canale bisogna che si sia CONNESSI A INTERNET. Può sembrare stupido, ma non si sa
mai...):
1) Dal menu File scegliete Options...
Nel campo IRC network settare "AzzurraNet".
Oppure premere il pulsante "Add" a fianco a destra e nel campo IRC Server scrivere
irc.net36.com
. Oppure scrivere
irc.filmaker.com
. Nel campo porta lasciar scritto 6667
oppure digitare 7000.
2) Tornati al menu "mIRC options" riempite ora i campi giù in basso: Nickname e
Alternative. Indicheranno il nome con cui sarete riconosciuti all'interno di IRC (o un
nome alternativo se l'altro è già in uso da altri).
3) Premete "Ok" in basso.
4) Sotto ai menu c'è una striscia di icone. Premete la terza da sinistra: è l'icona
Channels folder (c'è una cartella gialla con su scritto #+).
5) Premete il pulsante "Add". Nel campo "Channel" digitate #if (mi raccomando il
cancelletto).
6) Se volete sempre in questa finestra è possibile porre il segno di spunta sulla
casella che recita "Auto-join channel on connect" per fare in modo che ogni volta che
entererete in IRC verrete automaticamente spediti nel canale #if).
7) Cliccate "OK" sempre nella finestra "Add Channel".
8) Ora nell'elenco dei canali dovrebbe esserci anche #IF. Evidenziatelo e cliccate
"Join".
9) Ta-dah! Godetevi la premiazione.
NOTA: per eventuali errori non mi rompete le scatole. Mi sono fatto un mazzo tanto per
scrivere questa mini-guida in 9 punti. Accettatela così com'è.


author: Salkaner il Nero

text:
Poteva essere un giorno come tanti altri, su
it.comp.giochi.avventure.testuali , se Sauron non avesse deciso di
saltar fuori a dire:
>Dunque: la proposta è per lunedì prossimo venturo, ergo 6 maggio, ore 21:30
>Il luogo è il medesimo: canale #if su IRC.
mi spiace, ma io non ci saro` (allergia cronica ed atavica alle chat)
Buon divertimento, CMQ
(volgio sperare che qualcuno posti in NG i risultati il giorno dopo,
eh? ^___-  )
--
/   "A voi!!"   ~~~~~    Salkaner il Nero
\/\ ihgger DCCCXLV - iafo CXVII - ilfestoso XXII - ihggerd IV
  / Signore della Torre Senza Nome ---->>
http://ltsn.ven.cx

http://wakeup.to/vdp
  <<---- visita VdP!
           l'indirizzo corretto e` sul mio sito


author: Atrus

text:
"Sauron" <
rad...@libero.it
> ha scritto nel messaggio
news:GVfA8.47529$W9.11...@twister2.libero.it...
> Dunque: la proposta è per lunedì prossimo venturo, ergo 6 maggio, ore
21:30
Mi spiace ma non riuscirò proprio ad esserci. :(
A me van bene martedì, mercoledì o venerdì, ma non cambiate solo per me.
>
irc.net36.com
.
Assolutamente no. Usate
irc.azzurra.org
net36.com
 NON fa più parte della rete di Azzurra.
--
Atrus di Myst =^=
www.atrus.terrediconfine.net
"Through dangers untold and hardships unnumbered..."


author: fabrizio venerandi

text:
Pare che Sauron abbia scritto:
> Dunque: la proposta è per lunedì prossimo venturo, ergo 6 maggio,
(...)
> presenti lunedì 5 maggio a sera sul canale #if (ridondante, lo so!).
mhh 5 maggio o 6 maggio... deve esserci un enigma nascosto... 5+6 = 11,
sabato 11 maggio a meno che non sia 6-5... il primo maggio oppure 5/6
che fa un numero strano ecco, la stranezza deve essere la chiave, ci
sentiremo in un giorno strano...
f.


author: Zerouno

text:
Sauron ha scritto nel messaggio ...
>Ben, noto con piacere che la proposta ha avuto successo.
>Ogni tanto si vede che ne riesce bene una anche al sottoscritto ;-))
>
>Dunque: la proposta è per lunedì prossimo venturo, ergo 6 maggio, ore 21:30
>Il luogo è il medesimo: canale #if su IRC.
Okay, lunedi' sera saro' sicuramente a casa (indovinate perche'...). Mi
faccio un appunto sul desktop cosi' me lo ricordo.
Ciao,
Marco


text:
> mhh 5 maggio o 6 maggio... deve esserci un enigma nascosto... 5+6 = 11,
> sabato 11 maggio a meno che non sia 6-5... il primo maggio oppure 5/6
> che fa un numero strano ecco, la stranezza deve essere la chiave, ci
> sentiremo in un giorno strano...
> f.
Ehm...come dire...č proprio vero quando di qualcuno dicono "Gli manca un
giovedě"...ecco, si vede che mi sono perso qualcosa strada facendo.
Allora vada per lunedě 6 maggio.
:-))
Sauron


text:
> mi spiace, ma io non ci saro` (allergia cronica ed atavica alle chat)
> Buon divertimento, CMQ
Nemmeno se si cazzareggia tra amici?!
> (volgio sperare che qualcuno posti in NG i risultati il giorno dopo,
> eh? ^___-  )
Comunque posterò sicuramente i risultati ufficiali sul newsgroup, stanne certo.
Sauron


text:
Ho visto che il buon Atrus non potrà esserci.
Per me va bene anche martedì 7.
Ma non so per gli altri.
Dite la vostra al più presto perchè lunedì (o martedì) si avvicina.
Sauron


author: Nero

text:
Io lunedi' sera ci sono, ma credo anche martedi'.
Nero disponibile.
Nero


author: Stefano Gaburri

text:
io martedě ci sono, ma solo dopo le 23 circa.
Sauron wrote:
>
> Ho visto che il buon Atrus non potrŕ esserci.
> Per me va bene anche martedě 7.
> Ma non so per gli altri.
> Dite la vostra al piů presto perchč lunedě (o martedě) si avvicina.
>
> Sauron


author: Barabert

text:
"Sauron" <
rad...@libero.it
> ha scritto nel messaggio
news:GVfA8.47529$W9.11...@twister2.libero.it...
> Ben, noto con piacere che la proposta ha avuto successo.
> Ogni tanto si vede che ne riesce bene una anche al sottoscritto ;-))
>
> Dunque: la proposta è per lunedì prossimo venturo, ergo 6 maggio, ore
21:30
> Il luogo è il medesimo: canale #if su IRC.
Ci sarò. Se non mi vedrete è perché sono talmente imbecille che me ne sono
dimenticato.
Bye


text:
"Sauron" <
rad...@libero.it
> ha scritto nel messaggio
news:m4AA8.1619$5k4....@twister2.libero.it...

A ME PUO' ANDARE BENE SEMPRE!
Bye


text:
"Sauron" <
rad...@libero.it
> ha scritto nel messaggio
news:m4AA8.1619$5k4....@twister2.libero.it...
> Ho visto che il buon Atrus non potrŕ esserci.
> Per me va bene anche martedě 7.
Raga per me in settimana dopo le 23 č difficile quindi fate pure senza di me
se vi č piů comodo.



author: Francesco Cordella

text:
Ci sarò
f.


text:
proverottici!
ma quale e' il server, alla fine?


text:
Poteva essere un giorno come tanti altri, su
it.comp.giochi.avventure.testuali , se Sauron non avesse deciso di
saltar fuori a dire:
>> mi spiace, ma io non ci saro` (allergia cronica ed atavica alle chat)
>> Buon divertimento, CMQ
>
>Nemmeno se si cazzareggia tra amici?!
No, davvero. E` una vecchia storia che risale ai tempi
dell'universita`. Mi spiace
>Comunque posterò sicuramente i risultati ufficiali sul newsgroup, stanne certo.
Thanks!



text:
> >Nemmeno se si cazzareggia tra amici?!
> No, davvero. E` una vecchia storia che risale ai tempi
> dell'universita`. Mi spiace
Curioso, invero, ma no problem, come ho già detto. Posterò certamente tanto i/il log e
i risultati.
Alla prossima.
:-)
Sauron


title: Formamentis: calibrazione analizzatore

author: Andrea

text:
Ciao,
non so se le email di ieri vi sono arrivate... cmq come faccio a sapere
i parametri con cui impostare la calibrazione dell'analizzatore, per
analizzare il contenuto della cella?
Grazie,
Andrea


title: timewarp: margherita?

text:
.
.
.
.
.
dove la trovo la margherita????
il fungo è un calmante,stando a quello che dice il prof.


title: timewarp: margherita?

author: Pink

text:
s8572 ha scritto:


Mi sembra strano che non l'abbia trovata. E' da qualche parte nel bosco.
Rosy
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news
 segnala gli abusi ad
ab...@newsland.it


title: timewarp: margherita?

author: Umberta Cola

text:
"Pink" ha scritto:
> E' da qualche parte nel bosco.
>
>
Quale bosco?


title: timewarp: margherita?

text:
Umberta Cola ha scritto:
> "Pink" ha scritto:
> > E' da qualche parte nel bosco.
> >
> >
> Quale bosco?
Il 50% del gioco si svolge nel bosco!!!



title: Scoperta favolosa!!!

author: David Cappelli

text:
Salve a tutti
Mi e' successa una cosa fantastica.
Dopo pranzo sono entrato nel garage di un mio amico e questo mi ha mostrato uno
scatolone di cassette del vecchio commodor64. Essendosi accorto che sbavavo me
l'ha regalate tutte tanto non se ne faceva di nulla!
Ci saranno piu' di 200 cassette e, ad una prima razzolata, ho visto una
quarantina di avventure testuali (molte delle quali in italiano)!!
Chi era interessato a questa cosa? Mi pare che fosse il progetto Lazzaro no?
Insomma a chiunque interessi mi dica qualcosa perche' questo patrimono non e'
certo da ignorare :)
Ciao
David
--
Posted from  [62.98.242.105]
via Mailgate.ORG Server -
http://www.Mailgate.ORG