Newsgroup: it.comp.giochi.avventure.testuali
Titolo: z-code e glulx su web

Vedo che ormai, oltre ai miei, ci sono tanti post che riguardano la 
possibilitï¿œ di usare via browser i compilati ma, soprattutto, che si 
vuole poter portare sul web anche il mondo glulx per ovvie ragioni, 
prima tra tutte, il comune convincimento che un po' di illustrazioni e 
suoni non intaccano la "purezza" delle AT se usati con garbo.
Inoltre con glulx anche l'interfaccia utente migliora permettendo una 
potenziale estensione del pubblico.
Tutto ciï¿œ premesso, una prima domanda da ignorante in materia di z-code: 
la versione 6 e glulx sono la stessa cosa? Ovvero, in quale modo glulx, 
tecnicamente estende z-code?
La domanda sorge da alcune considerazioni:
- i progetti da voi richiamati nel ng hanno tutti il limite di non 
implementare glulx nel rendering per web
- anche gnusto, il motore di parchment, non lo fa nonostante ne avrebbe 
le prerogative oltre che l'interesse
Quindi volevo sottoporvi due domande:
1.perchï¿œ, vista l'attuale propensione di tutti a usare glulx spinta 
anche dagli strumenti dati da inform 7, non esiste ancora questa 
possibilitï¿œ per il web?
2.perchï¿œ non scegliere uno di questi progetti e costruirvi attorno una 
nuova community piï¿œ estesa, dato che molti di voi conoscono bene z-code 
e glulx e molti di noi sanno programmare?
Il potenziale ï¿œ molto esteso e tutti i progetti realizzati sinora per 
windows, mac e linux denotano una conoscenza enorme del compilato z-code 
e glulx.
Acquisire una nuova piattarforma per il gioco, trasversale alle altre, 
costituirebbe un notevole stimolo alla divulgazione delle AT. Ripeto 
quanto da me scritto in qualche post precedente: non tutti hanno 
l'istinto dello scrittore, la maggioranza ha invece quello del lettore e 
  quindi uno strumento web faciliterebbe l'avvicinamento dei tanti lettori.
Noi, con la voglia di scrivere e sognare, invece, proseguiamo con i 
nostri strumenti implementativi che poi possono essere divulgati 
maggiormente.
Chi ï¿œ forte in z-code e glulx alzi la mano e ce la dia, se vuole.

Paolo G. Sfredda ha scritto:

Aggiungo subito una cosa: i progetti realizzati in java presentano un 
grande vantaggio: si puï¿œ prendere spunto dai sorgenti.
Ma quelli che ho trovato suggeriti hanno in comune almeno un paio di 
problemi:
-non sono velocissimi
-non sono nel browser ma sono solamente veicolati dal browser: il testo 
non ï¿œ selezionabile e nessuno dei vantaggi dati dalle normali pagine web 
funziona.
Non considererei nemmeno come valide le soluzioni basate su flash.
Inoltre, ï¿œ necessario disporre di una piattaforma utilizzabile con 
provider economici come Aruba (colgo l'occasione per evidenziarvi il 
valore di questo provider il cui unico difetto ï¿œ quello di non garantire 
la banda ma che professionalmente dï¿œ moltissimo ai suoi clienti - lo uso 
davvero molto con tantissimi domini)
Java taglia fuori molti di questi provider per non parlare di altri 
problemi dati sulla gestione del file system.
Lascio di nuovo la parola agli esperti di z-code e glulx.

 possibilitï¿œ per il web?
Per lo stesso motivo per cui avviene sui PDA/smartphone: perchï¿œ ï¿œ molto 
piï¿œ complicato implementare glulx che z-machine, e perchï¿œ glulx ï¿œ molto 
piï¿œ esigente riguardo alle risorse della macchina ospite.
Questo non vuol dire che non possa essere fatto...
Altre risposte (forse) in seguito.
bye
-- 
Paolo Lucchesi
email: plucchesiNOSPAM(at)NOSPAMtin(dot)NOSPAMit
homepage: 
http://www.paololucchesi.it

 Non considererei nemmeno come valide le soluzioni basate su flash.
Son d'accordo. Secondo me le possibili soluzioni valide sono:
- Una soluzione server-side in php (che qualsiasi hosting degno di 
questo nome, a partire dal gratuito altervista, fornisce)
- Una soluzione client-side in Ajax
Anche visti i risultati di parchment, io propendo per la seconda strada.


Riciao.
Sto studiando e sono andato direttamente sul sito di ha scritto glulxe. 
Ho scoperto che lui ha anche giï¿œ realizzato una versione javascript che 
perï¿œ prevede, volendolo e non obbligatoriamente, anche una parte server 
che ancora non esiste.
La cosa non mi ï¿œ ancora del tutto chiara e quindi proseguirï¿œ con le 
ricerche.
Il punto ï¿œ che, anche trasformando i sorgenti di glulxe, che sono in c e 
sono abbastanza semplici, in javascript o simili, si pongono subito 
diversi problemi che sono quelli giï¿œ affrontati con Idra e 
dall'esperimento di cui parlavo sopra. Si tratta di tutti i problemi 
derivanti dall'uso dei browser e dalle scelte architetturali che si 
vogliono adottare. Per rimanere fedeli allo spirito della z-machine 
portabile sarebbe meglio la soluzione client-based che perï¿œ rischia di 
essere meno affidabile di quella server-based.
Studio e vi aggiorno.


Onestamente credo che la piattaforma flash sia molto più adatta all
scopo.
Ha l'unico difetto di essere proprietaria, quindi a pagamento per lo
sviluppatore.

 Studio e vi aggiorno.
I miei esperimenti in javascript (prima versione di Neurosi) mi hanno
fatto capire quanto Javascript sia inadatto per questi scopi.
Lascia stare, è un consiglio :)

 
In realt� non si tratta di stabilire la validit� o meno di una 
piattaforma in senso assoluto ma in relazione agli obiettivi.
Se l'obiettivo � quello di avere la possibilit� di disporre 
dell'avventura via web ma poi la si gioca come se fosse in un ambiente 
simile alle z-machine, allora sono d'accordo con saintpumpkin.
Se invece, come a me interesserebbe, si vuole disporre di un sistema che 
metta on-line l'avventura, non in un framework, ma renderizzando delle 
vere e proprie pagine html, ad esempio via js, allora flash non va bene 
e non d� valori aggiunti che non siano ottenibili gi� con js.
Si tratta di stabilire quale progetto si ha in mente.
La proposta che lancio con questo thread � la seconda, ovvero di 
scrivere un interprete glulx per generare pagine html secondo la 
specifica attualmente rilasciata da Andrew Plotkin (3.1.1) sulla base di 
GlulxE 0.4.5.
Come diceva P.Lucchesi, la scelta si limita tra adottare un'architettura 
client-server o solo client-side, basata su js.

Ciao,
ho perso un po' il filo di questi post, spero quindi di non scrivere
ridondanze.
Volevo solo mandare i link a FyreVM, una virtual machine che
implementa Glulx tramite .NET:
https://www.textfyre.com/FyreVM/
Premesso che ci avevo buttato un occhio mesi fa e non sono molto
fresco su come sia la situazione, ci sono i vari sorgenti e docs.
Implementa dei canali I/O per i quali c'è anche una libreria I7.
Questo è un ottimo demo:
https://textfyre.com/sldemo/
Questo è un demo di un'avventura che usa un interprete basato su
SilverLight (l'interprete si chiama SilverFire):
https://www.textfyre.com/shadowdemo.aspx
(spero di non aver scritto tavanate, ho ripescato i link da una
vecchia cartella abbandonata da mesi in locale)
Tristano

 per lo sviluppatore.
Perché a pagamento? Ho scritto alcuni applicazioni Flash con
FlashDevelop e non ho dovuto pagare niente. Tu paghi?

 Tristano
Grazie per le info. Certamente � interessante l'approccio di sviluppo 
seguito dall'autore per evitare di limitare l'I/O.
La demo per� presenta lo stesso limite dell'uso di flash. E' come avere 
un'applet, un oggetto distribuito mediante il browser ed eseguito da un 
interprete come flash o silverlight. Per� non ottiene lo stesso effetto 
di parchment o di Idra.
Mi permetto infatti di contraddire saintpumpkin dicendoli che le due 
piattaforme sopra menzionate dimostrano che js � utilizzabile.
Si tratta di capire se l'interprete glulxe, parimenti a z-code, � 
implementabile con js.
Secondo me si ma ci vorrebbe un gruppo di sviluppo e non un singolo per 
alleggerire il lavoro.
Risultato: se sono in treno e voglio giocare, posso farlo comunque 
perch� lo ho in locale. Se sono on-line, lo vedo come fossero pagine.
Il punto per� � un altro: se si realizza come lo ho descritto sopra, i 
motori di ricerca, non potendo seguire dei link, non giocheranno mai 
l'avventura e quindi non saranno molto attratti come dagli articoli di 
un cms. Per�, grazie ad un aspetto pi� accattivante e completo dato 
dall'uso di glulx, pi� gente sar� interessata a giocare trovando 
comunque in modo pi� agevole le avventure per via del testo della prima 
pagina che anche il motore di ricerca pu� trovare seguendo i link come 
nel caso della pagina del sito di parchment.
Forse un po' lungo e contorto ma questo era il concetto cui volevo arrivare.


Flash develop è solo pe Windows no? Io purtroppo sto su mac e uso
metodi molto più immediati :)

 un cms. 
Dubito che, anche nel caso di una soluzione server-side, i motori di 
ricerca possono essere minimamente sensibili a testo generato 
dinamicamente. Se poi parliamo di soluzioni client-side, il testo 
generato non attraversa nemmeno la rete.


 generato non attraversa nemmeno la rete.
In realt� il motore di ricerca "naviga" i link e quindi anche le pagine 
generate dinamicamente come quelle dei cms anche grazie ai link 
generati, in una forma "parlante", dai SEF.
Sto studiando GlkOte, l'API js di gluxl scritta da zarf. Prevista per 
interagire anche un server (forse scriver� RemGlk). Permette di scrivere 
IF dando tutta una lunga serie di servizi eventualmente utilizzabili 
anche in modalit� AJAX.
Si tratta ora di capire come interfacciare un terp che, lato server o in 
locale, interpreti un compilato glk tipo quello di I7 dato che 
l'architettura glk prevede esplicitamente la separazione tra gui ed 
engine. Quindi il terp svolge funzioni da engine e GlkOte quella di GlkAPI.
pg

 ricerca _possono_ essere...
AARGH!!! POSSANO!!!


 Posto che non mi � ancora chiarissimo cosa sia un terp 
Scusa, 'terp == interprete



Non volevo certo affermare che js (al momento il mio linguaggio
preferito) non è utilizzabile.
Il problema vero e proprio è il browser per quanto mi riguarda.
Come pensate di gestire il codice in chiaro, le compatibilità dei
browser (al momento a dire il vero sono tutti molto simili
nell'implementazione di javascript), i salvataggi, il multimediale.
Fossi in voi escluderei il server-side.. aspettare la risposta del
server per ogni comando deve essere MOLTO noioso e stressante. Ajax
potrebbe fare al caso vostro ma si avrebbero comunque dei
rallentamenti. Non ho inoltre capito l'utilità di indicizzare le
pagine delle avventure sui motori di ricerca... non gioverebbero di
certo ad aumentare il bacino di utenza, su questo sono pronto a
scommettere 100 euro :)

 scommettere 100 euro :)
Non amo molto il... "gioco d'azzardo" ma penso che, oltre a divertirmi 
l'idea di affrontare un nuovo obiettivo (realizzare il terp), in realt� 
si dovrebbero avere effetti benefici sull'utenza in quanto una soluzione 
cos� potrebbe essere raggiunta e giocata anche on-line presso tutte le 
rivisite web basate su cms. Ovviamente le avventure gialle staranno sui 
siti che si occupano di gialli e quelle kappa e spada su quelli che si 
occupano di quel genere. Chi non vorrebbe allietare i propri lettori con 
una distrazione?

 giocare off-line basta usare gargoyle. Non serve il browser.
Non farti illuminare troppo dal Lucchesi...
Fosse per lui, tutti dovrebbero continuare a divertirsi digitando
kilate di caratteri cui il gioco risponde... "Non capisco cosa vuoi
dire". :D
Rob

 rivisite web basate su cms.
Ovviamente la mia non era critica ma curiosità, se ti diverti (e
probabilmente è divertente) ben venga il tuo tentativo :)

 giocare off-line basta usare gargoyle. Non serve il browser.
Che per� nel frattempo si � ricreduto. Non seguo molto la questione, ma 
stanno spuntando fuori dei device (Litl?) e dei s.o. (ChromeOS, credo, e 
nient'altro) molto web-oriented, anche in locale. Un 'terp client-side 
non � peregrino...
bye
-- 
Paolo Lucchesi - pluc...@NOSPAMtin.it