Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Ma siete ancora vivi

Che dire, pochi ma buoni... anche se la tecnologia si è (de)evoluta (visto quanti twine ci sono in contest quest'anno...) almeno si fa ancora qualcosa!
 
Piuttosto, come funziona quel coso inguardabile di inform 7? Sarà che sono programmatore 'tradizionale' ma azzeccare quella sintassi mi sembra un'impresa. Specialmente quando ci sono i nomi italiani di mezzo (alla fine bisogna trattenersi dal non ridere mentre si legge il programma)
 
Insomma, viene usato o inform 6 regna sempre supremo? (se non fosse che il TADS 3 non è mai stato tradotto lo preferirei...)
 
PS lo usate ancora garglk *vero*? :D

 PS lo usate ancora garglk *vero*? :D
 
Gargoyle è sempre il mio interprete preferenziale, ovviamente (non uso 
più la tua mod, però).
 
bye
-- 
Paolo Lucchesi - p...@NOSPAMpaololucchesi.it

 più la tua mod, però).
 
Purtroppo per la mia mod c'è stata una tragica mancanza di coordinazione... io avevo aggiunto inizialmente anche il supporto unicode e parallelamente è stato creato utilizzando un'altra libreria, così come la cache delle picture e dei caratteri estesi. Quindi un merge era diventato implausibile. Tipograficamente il mio però è ancora più avanzato, ma nemmeno compila adesso (va sistemato per i 64 bit, fra l'altro. Lo stesso interprete TADS ha bisogno di manutenzione perché i compilatori C++ moderni lo rifiutano (anche il C++ non è compatibile con se stesso ormai...). Brutta storia considerando che sono anni che non fa una release.

 
 
Ciao.
Dopo anni di vari tentativi di approccio al "coso inguardabile" anche se 
affascinante, ho desistito. E' davvero inutilizzabile.
 
Finché si tratta di mettere insieme un po' di oggetti e stanze tutto 
fila liscio. Alcune semplici procedure sono di facile implementazione.
 
Ma tutto il resto è davvero troppo dispersivo.
 
Anche la sintassi e alcuni limiti di inform 6 non scherzano.
 
Lavorando molto con typescript e javascript, venendo da una tradizione 
come pascal a oggetti, c++ etc etc, ritengo che aver inventato una nuova 
sintassi, che vagamente ne richiama altre del passato, non sia stata una 
buona idea.
 
L'approccio che trovo ancora il più efficace e più manutenibile, usando 
un linguaggio di programmazione, è quello in stile Idra di Colombini.
 
Stavo cercando di capire come realizzare un convertitore javascript (o 
typescript) -> i6 o direttamente zcode (o glulx).
 
Ci vorrebbe un sacco di tempo e poi lo trovo poco efficace: l'unico 
vantaggio sarebbe quello di poter riutilizzare la macchina virtuale 
zcode ma oggi giorno forse varrebbe la pena rimanere in ambito browser, 
la macchina virtuale per eccellenza.
 
Esattamente come Erix aveva già capito molti anni fa.
 
pg
 

 la macchina virtuale per eccellenza.
 
Se non fosse che il browser dopo un po' tende a strisciare se non hai millemila giga di ram, si, è una buona soluzione (vedi twine). Ci sono stati esperimenti anche in altri ambienti, per esempio dunnet è scritta in emacs lisp (e ovviamente gira sotto emacs...)
 
Anzi il lisp è per sua natura uno dei linguaggi più adatti allo scopo (scopo originale: macinare liste di token... ricorda niente?). Un buon lisp portabile tipo clisp potrebbe essere attaccato senza grossi problemi a glk.
 
Rimane 'solo' il problema della libreria base, a parte parser e grammatica non è particolarmente complesso ma è un sacco di lavoro...

 più la tua mod, però).
 
io invece si ;)

 
 
Secondo me il tema è piuttosto articolato, come del resto già illustrato 
da molti di voi molto bene in passato.
 
I livelli di approccio sono almeno due e molto ben distinti:
 
- livello della redazione:
E' il livello della realizzazione, dello sviluppo. A questo livello sono 
state seguite strade diverse più o meno vicine al linguaggio 
"pesudo-naturale" (inform 7) o più orientate allo sviluppo (tads, inform 
6, ...). In alcuni sono stati sviluppati tool di supporto (quest, 
adrift, ...) che minimizzavano la scrittura di codice.
A questo livello la cosa più importante, a mio parere, è la scelta della 
soluzione più vicina all'esperienza e all'interesse dello 
scrittore/sviluppatore.
 
- livello della divulgazione:
E' il livello che si occupa del canale di divulgazione/fruizione dell'opera.
Linguaggi come mobi (per gli ireader) si sono dimostrati ostici e 
limitati (vedi pubblicazioni di Colombini) per una buona redazione. E 
quindi mi sembrano imperseguibili anche se interessanti.
Resta il modo javascript (lato client) o php + javascript (lato server). 
Anche se è certamente preferibile il primo dato che, una volta scaricata 
l'opera, è fruibile anche off-line.
 
Ecco perché ritengo che il mondo javascript, quale punto di approdo 
anche per tecnologie diverse come  zcode o tads, sia più lungimirante in 
quanto consente la massima potenza e versatilità oltre che 
manutenibilità nella fase di test ma, soprattutto, la massima 
distribuibilità.
 
Proprio in questi giorni ho cominciato a studiare TADS 3.1. Devo 
contraddire Lorenzo in quanto è stata ripresa la manutenzione evolutiva 
(la 3.1.3 è stata rilasciata a maggio 2016). Ed è già predisposto anche 
per i MUD.
 
Troppo presto per dare una mia valutazione sul linguaggio ma, da 
programmatore, mi sembra più lineare di inform 6 nell'approccio.
 
Durante le ferie magari vi tedio con ulteriori considerazioni. Per ora 
solo un rammarico: il sistema di sviluppo di TADS per la parte di 
editing, esiste solo per windows e non per mac. Poco male se non fosse 
per la sintassi e per quei piccoli aiutini che un editor dedicato può 
dare durante la scrittura del sorgente.
Forse non c'è nemmeno la traduzione in italiano...
 
pg
 

 Forse non c'è nemmeno la traduzione in italiano...
 
La traduzione infatti non c'è. Il compilatore c'è per mac, probabilmente non c'è l'IDE.
 
Il problema massimo per la traduzione è scrivere la funzione che "compila" il dizionario: TADS distingue fra nomi e aggettivi e quindi il nome viene 'annotato' un po' come su inform il //p per il plurale. Per l'italiano però c'è anche la complicazione di genere e coniugazione...

 
 
Questo limite di TADS è inquietante perché significa che in italiano non 
è utilizzabile. Speravo che qualcuno l'avesse già fatta la traduzione...
 
Comunque mi interessava studiare TADS per vedere se è possibile pensarlo 
in js, proprio per superare tutte le specificità di un ambiente di 
scarsa divulgazione e approdare a un modo usato tantissimo dal mondo dei 
guru del software. A parer mio aprirebbe scenari interessanti.
 
pg

 guru del software. A parer mio aprirebbe scenari interessanti.
 
A me il js non piace quindi sono di parte a priori :D in ogni caso il lavoro in un modo o nell'altro lo può fare, è questione di bestemmiarci sopra appropriatamente :P
 
Piccolo suggerimento: nell'IF la parte più complessa è la gestione del save/restore (che nelle VM viene gestita 'in hardware'), l'eventuale undo può essere semplicemente gestito come un save ad ogni turno (se le prestazioni lo consentono).
 
Una volta risolto questo problema (es. stashing in json o simili) il resto è 'mera' implementazione E praticità d'uso.
 
La praticità per l'autore è importante, non per niente inform è famoso per la scorciatoia "xxx"; <=> print_rtrue "xxx"; e tads lo è per i template (proprietà create per posizione e non per nome)
 
Una possibilità interessante potrebbe essere un compilatore che ha come *target* il javascript, ma la difficoltà ovviamente aumenta (se non vuoi fare un clone di twine con le sue limitazioni)