z-code e glulx su web
Paolo G. Sfredda
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
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.
Paolo Lucchesi
> 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?
Assolutamente no. Z-machine e glulx sono due macchine virtuali molto
diverse, e la differenza ￜ molto piￜ profonda delle capacitￜ
multimediali. Penso che la differenza piￜ macroscopica sia il fatto che
z-machine ￜ a 16 bit, mentre glulx a 32 bit; poi cambiano gli opcodes e
tutto il resto.
D'altronde glulx ￜ nato con l'idea di superare i limiti ormai troppo
stretti della z-machine, in termini di memoria, capacitￜ e estendibilitￜ.
La versione 6 ￜ piￜ o meno una versione della z-machine con un po' di
operatori per una rudimentale gestione degli elementi multimediali; ￜ
obsoleta, deprecata, non sempre supportata dai 'terp e non sono nemmeno
sicuro che inform possa generarla; ormai la versione 6 serve soltanto
per giocare a Arthur, Journey, Zork zero e poco altro.
> 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?
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
Paolo Lucchesi
> grande vantaggio: si puￜ prendere spunto dai sorgenti.
> Ma quelli che ho trovato suggeriti hanno in comune almeno un paio di
>
> 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.
Paolo Gabriele Sfredda
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.
saintpumpkin
>
> > 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.
>
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.
saintpumpkin
wrote:
> Riciao.
>
> Sto studiando e sono andato direttamente sul sito di ha scritto glulxe.
> 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
> 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
> essere meno affidabile di quella server-based.
>
> 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 :)
Paolo Gabriele Sfredda
> 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.
>
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.
Tristano
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:
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
Leonardo
>
> 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.
Perché a pagamento? Ho scritto alcuni applicazioni Flash con
FlashDevelop e non ho dovuto pagare niente. Tu paghi?
Paolo G. Sfredda
> 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.
>
> 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
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.
saintpumpkin
Flash develop è solo pe Windows no? Io purtroppo sto su mac e uso
metodi molto più immediati :)
Paolo Lucchesi
> Si tratta di capire se l'interprete glulxe, parimenti a z-code, �
> implementabile con js.
Eh, bella domanda. Anche se, vista la scalabilit� di glulx, forse la
domanda giusta � _come_ � implementabile un 'terp glulx in js.
Comunque alcuni esperimenti di zarf sull'implementazione delle glk
sembravano - se la memoria non mi illude - promettenti.
> Secondo me si ma ci vorrebbe un gruppo di sviluppo e non un singolo per
> alleggerire il lavoro.
Bisognerebbe controllare se qualche anglofono sta gia' lavorando a
questo. E comunque mi pare che Zarf stia modificando le specifiche glk
apposta per renderle pi� "web oriented" (ma ho seguito il discorso solo
di sfuggita).
> 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.
S�, � vero, � uno dei motivi per cui sono pi� fiducioso in una soluzione
client-side.
Per contro, visto che stiamo (IMHO giustamente) pensando a dei 'terp, e
non a soluzioni ex-novo, non c'� grosso bisogno di una soluzione che
funzioni in locale... se uno vuole giocare in locale, si scarica Gargoyle.
> 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.
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.
Paolo G. Sfredda
Posto che non mi � ancora chiarissimo cosa sia un terp (immagino sia
un'implementazione di interprete, in questo caso glk), la sintesi l'hai
fatta benissimo tu:
Paolo Lucchesi ha scritto:
> Per contro, visto che stiamo (IMHO giustamente) pensando a dei 'terp, e
> non a soluzioni ex-novo, non c'� grosso bisogno di una soluzione che
> funzioni in locale... se uno vuole giocare in locale, si scarica Gargoyle.
>
> 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.
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
Paolo Lucchesi
> Dubito che, anche nel caso di una soluzione server-side, i motori di
> ricerca _possono_ essere...
AARGH!!! POSSANO!!!
Paolo Lucchesi
> Posto che non mi � ancora chiarissimo cosa sia un terp
Scusa, 'terp == interprete
Leonardo
>
> > > Ha l'unico difetto di essere proprietaria, quindi a pagamento
> > > per lo sviluppatore
>
> e uso metodi molto più immediati :)
Si vede che l'equazione
piattaforma proprietaria = piattaforma a pagamento
vale solo per il Mac :)))
Comunque FlashDevelop è "adeguatamente immediato" per essere gratis ;-
>
saintpumpkin
>
> Mi permetto infatti di contraddire saintpumpkin dicendoli che le due
>
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 :)
Paolo Gabriele Sfredda
>> Mi permetto infatti di contraddire saintpumpkin dicendoli che le due
>>
>
> Non volevo certo affermare che js (al momento il mio linguaggio
> 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.
In generale i problemi maggiori del browser sono proprio i salvataggi e
gli aspetti legati al tasto bak. Come dici tu, la compatibilit� � ormai
un problema superato, almeno per quelli maggiormente diffusi.
Ma a questo punto posso essere fatte due ipotesi di lavoro:
1.vedere come gnusto converte (quindi � proprio un traduttore) z-code in
js e prendere spunto per il nuovo convertitore. A valle di ci� "basta"
implementare le specifiche glk. Il multimediale sul browser non mi
sembra un grosso problema.
2.usare glk-ote come glk-api (ovvero come renderer) e scrivere il terp
(visto che ho imparato) in js per la parte VM. I problemi di base sono
gi� stati affrontati da zarf. Questa soluzione pu� essere benissimo
implementata tutta lato client o client server.
>
> 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.
Per� su questo � illuminante P.Lucchesi quando dice che se si deve
giocare off-line basta usare gargoyle. Non serve il browser.
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 :)
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?
rgrassi
> Però su questo è illuminante P.Lucchesi quando dice che se si deve
> 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
saintpumpkin
wrote:
>
> In generale i problemi maggiori del browser sono proprio i salvataggi e
> un problema superato, almeno per quelli maggiormente diffusi.
>
Il salvataggio è un bel casino :)
E' proprio uno dei motivi che mi ha spinto verso Adobe Air, che
implementa un bel db sqlite nei suoi file eseguibili.
>
> 1.vedere come gnusto converte (quindi è proprio un traduttore) z-code in
> js e prendere spunto per il nuovo convertitore. A valle di ciò "basta"
> implementare le specifiche glk. Il multimediale sul browser non mi
> sembra un grosso problema.
Attenzione, solo l'html5 sta introducendo la multimedialità
(ovviamente escludo le immagini) nei browser. Ma ad oggi - così come
per i css3 - non si può ancora fare affidamento su queste tecnologie.
Purtroppo bisogna ancora bussare la porta ad Adobe :)
>
> Però su questo è illuminante P.Lucchesi quando dice che se si deve
> giocare off-line basta usare gargoyle. Non serve il browser.
>
Io "caricherei" tutta l'avventure in un botto solo e via.
>
> 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 la mia non era critica ma curiosità, se ti diverti (e
probabilmente è divertente) ben venga il tuo tentativo :)
Paolo Lucchesi
>
> Per� su questo � illuminante P.Lucchesi quando dice che se si deve
> 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