Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Z-Machine .NET

Sto valutando l'idea di fare un porting sulla piattaforma .NET/MONO della 
Z-Machine, finora non ho trovato lavori simili per questo framework, voi che 
ne pensate ?
L'obietivo è quello di creare un interprete che possa usare interfacce I/O 
diverse, ed esteso facilmente dall'ambiente .net. Penso ad esempio alla 
possibilità di usarlo con applicazioni di tipo Desktop ma anche Web.
Commenti are welcomed. 

LSS ha scritto:

Anche io avevo fatto proposte simili, soprattutto nella direzione di 
esportare le avventure su web ma la recettività del gruppo è molto bassa 
in quanto teme contaminazioni stile gioca-e-getta.
Inoltre mi sembra che l'imperativo sia: tutto sulla chiavetta!
Io invece sono molto interessato e disponibile. Io lo volevo fare in PHP 
ma mi va bene dare una mano anche su .NET, poi mi faccio io il porting.
Partirei dal sorgente java che ho trovato in giro. Si tratta di un 
interprete per glulx (non ricordo la versione). Ma vanno bene anche 
tutti gli altri.
Parlo di interprete perché convengo con Lucchesi che non valga la pena 
metter mano al compilatore (che peraltro prevede anche l'uso di assembler).
Possiamo iniziare con il capire il sorgente e poi dividerci i compiti.
Se vuoi, scrivimi. L'indirizzo, se già non lo vedi, è:
paolo macchia sfredda lumaca gmail puntino commerciale


Se parte qualche iniziativa su .Net dò la disponibilità per qualche 
supporto/aiuto tecnico...

LSS ha scritto:

E comunque qualche bella dritta potrebbe darcela Marcantonio che mi 
sembra sia molto preparato (v. gargoyle mod04)
riciao

dopo qualche ricerca ho trovato questo:
http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/d1fa4a1c204f474b/3c25b107bf18dc4f
si tratta del sorgente c# di un interprete basato proprio sul concetto dei 
canali I/O. Dal punto di vista tecnico mi sembra segua lo stesso principio 
che avevo ipotizzato, tuttavila la licenza č proprietaria, non č GPL, anche 
se permette l'utilizzo per fini non-commerciali.


(critica)
Onestamente non ne capisco l'utilità, voglio dire... esiste già
l'interprete che gira su windows, esistono già interpreti che
permettono di giocare i giochi in z-machine su web (uno è addirittura
in flash).
Ne servirebbe uno per il mio cellular - palmare symbian uiq3 :D

 sembra sia molto preparato (v. gargoyle mod04)
Bisogna vedere esattamente il target... il modello della Z-machine e'
piuttosto diverso da quello di Glk (infatti, per esempio, i colori
della Z-machine non sono direttamente 'adattabili' alle glk).
D'altra parte per glk e' molto piu' semplice trovare il punto di
suspend su I/O interattivo in quanto strettamente ad eventi... in
pratica e' possibile bufferizzare tutto e gestire l'interazione utente
nella glk_select (e' esplicitamente consentito che l'utente non veda
nulla fino alla glk_select!).
Il problema ovviamente e' tenere attivo il processo fra un'attivazione
e l'altra... una possibile implementazione potrebbe essere tenere
l'interprete come processo indipendente appeso ad un socket con la
parte web o qualcosa del genere... molte sessioni di gioco, molti
processi. La scalabilita' e' quella che e' ma non mi risulta che frotz
sia stato progettato per girare sotto un tp monitor :P:P

 Ne servirebbe uno per il mio cellular - palmare symbian uiq3 :D
Frotz 1.08 uiq ???
E' nominato ma non so se funga :P


funziona su uiq2, non uiq3 :(
(infinita tristezza)

sia stato progettato per girare sotto un tp monitor :P:P
La mia idea era differente, e ho visto corrisponde esattamente al concetto 
dietro l'implementazione del Fyre, ovvero astrazione del canale di I/O per 
poterlo adattare ad ambienti diversi come quello web, quindi un nucleo che 
faccia solo da interprete (cpu + memoria) e lasci fuori la parte i/o, da 
demandare all'applicativo desktop, o server che realizza l'interfaccia 
utente. Glk non mi sembra adatto a questo scopo, troppo pensato per l'ambito 
desktop, ed in effetti in Fyre non è usato.
Riepilogando: l'obiettivo è realizzare una machine che possa essere inserita 
come cuore in un interprete ovunque esso sia, magari anche dentro sqlserver 
:) (ho letto di un tizio che ci ha provato con successo)
L'unico problema è che Fyre ha una licenza aperta sul free, ma chiusa verso 
il commerciale, quindi questo potrebbe essere il casus belli per una 
implementazione nostra sotto LGPL. Essendoci comunque Fyre al momento 
l'obiettivo sarebbe esclusivamente didattico.
Sempre a livello didattico sarebbe interessante un JIT z-machine->IL code, 
ma qui forse faccio troppo vapore.

LSS ha scritto:

La tua idea corrisponde, alla lontana, a quella da me già proposta un 
po' di tempo fa ed è per questo che mi rendo disponibile.
Di fondo l'obiettivo è duplice: mantenere l'uso di inform 6 e gestire, 
lato server (on line oppure su pc) l'esecuzione dei comandi che potranno 
essere gestiti o da una virtual-machine java o da interprete php o da 
eseguibile win (quelli attualmente esistenti).
L'uso di flash non ha molto senso perché costituisce un ambiente 
specifico di un produttore (ex-macromedia), non open perché comunque 
legato a chi realizza i plug-in dei browser.
Si deve poter produrre HTML: è raggiungibile dai motori di ricerca, 
permette di divulgare molto di più le avventure.
Una cosa è la passione per le IF e una cosa per il fatto di poterle 
giocare da chiavetta.
Ovviamente su web bisognerà gestire poi il concetto di sessione e di 
salvataggio partita con indicazione del giocatore ma questi sono 
dettagli che possono venire un minuto dopo.
Ciao

Continuo a rompere le scatole.
Ma gestire un'avventura lato server non è pesante? Per ogni comando la
pagina deve essere caricata, l'esperienza di gioco rischia di essere
noiosa.

 noiosa.
A parte che non so se avevi giocato su C64, che ad ogni comando
meditava e swappava da disco (con la z-machine) :D
In questo caso una tecnologia AJAX e' esattamente quello che
serve :P:P (e se lo dico io che odio il javascript :D)
Il problema di base e' che comunque bisogna tenere in esecuzione sul
server un'instanza dell'interprete per ogni sessione aperta

Lorenzo Marcantonio ha scritto:

Su questi temi devo confidarvi che sono forte e quindi non temo smentite:
come gestisce il server l'interprete php, ad esempio, o la virtual 
machine java, non è un problema ne nostro ne gli utenti in quanto fa 
parte delle ottimizzazioni di chi sviluppa questi oggetti.
Quello che dobbiamo fare noi è solo realizzare una serie di librerie in 
uno di questi linguaggi che verranno invocate, ovviamente in modo non 
visibile a chi scrive in inform, come stessimo normalmente navigando le 
pagine di un normale sito.
Inoltre, i tempi di risposta, che vi assicuro non sono un problema, 
sarebbero comunque inconfrontabili con i tempi impiegati dal giocatore 
per pensare alle soluzioni: non si tratta di un arcade dove velocità e 
riflessi sono importanti. IF è soprattutto pensiero.
E' un po' come per idra, il cui unico limite per i miei gusti sono le 
risposte in numero finito: descrizione e comando. Il tempo d'esecuzione 
è veramente minimo e assolutamente più veloce, anche su un server iper 
condiviso, rispetto alle prestazioni delle z-machine di un tempo.

Lorenzo Marcantonio ha scritto:

Su questi temi devo confidarvi che sono forte e quindi non temo smentite:


 condiviso, rispetto alle prestazioni delle z-machine di un tempo.
Appunto, quella del C64 che swappava ad ogni comando :P:P

ok le mie conoscenze mi impediscono di capire di che cavolo state
parlando.
ad ogni modo buona fortuna :)