Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Lo stato dell'arte per lo sviluppo (in italiano)

Dunque, dall'altro thread e guardando in giro si evince che:
 
- L'ultima ifcomp è stata letteralmente dominata da Inform (principalmente 7 ma anche qualche 6) e Twine
 
- Inform 7 lo colloco assieme al 6 perché di fatto 7 è un precompilatore per il 6, quindi quando parlo di Inform li intendo entrambi
 
- Twine è sostanzialmente il 'nostrano' Idra, che ha preso qualche ormone della crescita... ma il concetto è quello (c'è l'ambiente al posto dell'editor a mano, ma alla fine sempre HTML+JS lavorano). ChoiceScript l'ho visto anche lui molto entry level, ma il succo è quello 
 
- L'unico sistema maggiore 'a parser' per l'italiano è di fatto Inform (TADS è in teoria traducibile, Quest non so neppure se esiste ancora, Alan e Hugo sono sia vecchiotti che intraducibili)
 
Quindi, se rimaniamo sul preesistente abbiamo Inform a parser e Twine/Idra/ChoiceScript (di fatto language neutral) per le avventure a scelte.
 
Aggiungo che, obiettivamente, Inform per quanto talvolta accrocchiato grosse limitazioni non ne ha e la libreria è più che decente (quella di TADS è migliore ma, ahimé è solo in inglese!)
 
Quindi personalmente, al giorno d'oggi per scrivere in italiano utilizzerei Inform o Twine/Idra. 
 
Per quanto riguarda un futuribile ambiente (tutto da programmare, ovviamente!). Per la distribuzione, e non doversi inventare un interprete per ogni piattaforma, le scelte ormai sono poche: o Z-machine/Glulx o HTML+JS (extra: volendo si potrebbe tradurre TADS, anche per quello gli interpreti sono ben diffusi)
 
Glulx è poco più che una Z-Machine a 32 bit. Questo per progetto, in modo da rendere facile il retarget di Inform. Di fatto l'unico compilatore 'serio' rimane Inform 6 quindi o 1) si scrive un compilatore dal "nuovo linguaggio" a Inform 6 (che è esattamente quello che fa Inform 7!) o 2) si scrive un compilatore dal "nuovo linguaggio" all'assembly Glulx (farlo verso lo z-assembly mi sembra un esercizio in retrocomputing... come lo ZILCH). Comunque si rimane con le classiche limitazioni: allocazione di memoria statica (in teoria glulx ha come opzioni malloc e mfree... opzionali!), interfaccia limitata a quello che passa l'implementazione glk locale. Sinceramente non vedo in Inform delle limitazioni tali da giustificare un tale lavoraccio:P
 
Target #2: HTML+JS; portabilità ottima (potenzialmente migliore), interfaccia limitata dal CSS locale, in sostanza... il "nuovo linguaggio" a questo punto può:
1) generare il fantamattone html giocabile, con un core in JS che lo interpreta (prestazioni discutibili ma l'IF non richiede velocità estrema...)
2) generare il fantamattone di cui sopra ma generando lui stesso il JS (compilatore con target JS) o permettendo l'inclusione del JS specifico (caso estremo: Idra è strutturato come libreria di funzioni JS)
3) server side: può fare sostanzialmente quello che vuole ma necessita di hosting e connessione a internet per giocare (IF nel CLOUD :P). Molto divertente in questo caso la gestione delle sessioni e dei salvataggi (server side? megacookie? client side storage?)
 
Mi sono scordato di qualcosa? Idee geniali alternative?
...se continua così mi sa che ci dobbiamo accontentare di Inform (ripeto che non lo trovo malvagio, ma potrebbe esserci di meglio...)

 
La domanda finale è: 1.js, 2.inform, 3.tads
 
Dal mio punto di vista:
 
- soluzione 1: è la più affascinante, sfrutterebbe la distribuzione 
mondiale della VM contenuta nei browser che è sempre più standard e 
affidabile ma richiede una realizzazione ex-novo;
 
- soluzione 2: è la più standard e consente di scrivere da subito e gode 
di tutto il lavoro fatto sinora
 
- soluzione 3: la sto studiando per capire se è usabile (implementando 
la traduzione) o se si può ipotizzare di tradurla in js ma si deve 
superare il limite di js sull'ereditarietà multipla (da non confondere 
con l'uso delle interfaccie che, a parer mio, non c'entra nulla)
 
Nel caso di traduzione di TADS in js, la soluzione 1 e la 2 potrebbero 
collassare in un'unica: jsTADS.
 
pg
 

 che non lo trovo malvagio, ma potrebbe esserci di meglio...)
 
Un commento veloce, che sono di fretta:
Il target alla fine secondo me lascia un po' il tempo che trova, visto 
che in un verso ormai abbiamo due 'terp in js che fanno il loro lavoro, 
e nell'altro non è così complicato - visto che parliamo di soluzioni 
client side - rilasciare uno zip con tutti i file per giocare online.
Certo, parchment e quixe non sono performanti come un js nativo, ma 
parlando di I.F. onestamente non vedo il problema. Inform 7 rilascia 
automaticamente il pacchetto da mettere online, con I6 c'è un po' da 
smazzarsi ma basta chiedere a chi già sa come fare (leggi: me) o 
aspettare che il suddetto infingardo spalletonde rilasci un tutorial per 
quixe (non trattenete il fiato).
(Poi magari ci sono problematiche di cui non ho tenuto conto, 
specialmente vista la pletora di dispositivi su cui gira js... Nel caso 
correggetemi).
 
bye
-- 
Paolo Lucchesi
 
email: plNOSPAM(at)NOSPAMpaololucchesi(dot)NOSPAMit
homepage: 
http://www.paololucchesi.it
 

 (TADS è in teoria traducibile
 
Confermo. C'è una cartella con alcuni file.
Un lavoro un po' lungo e noioso ma molto ben strutturato. Consente di 
introdurre regole lessicali diverse a seconda della lingua.
 
Aiutandomi con quello tedesco in caso di incertezze, ho iniziato la 
traduzione qualora ci interessasse.
 
pg
 
 

Il 29/07/17 15:32, pgsfredda ha scritto:

La versione compilata 3.1.3 di TADS non gira più su gargoyle... :-(
Usa un suo tool QTADS (per mac).
 
pg

 pg
 
Se posso dire la mia, mi pare che sia Infit che Italian abbiano avuto un po' di problemi legati al fatto di essere "di qualcuno" (Riccardi o Stella).
Liberissimo di dire di no, ma per questo progetto io partirei con il piede giusto, mettendo la traduzione in una qualche struttura di condivisione (Github? a me non piace granchè ma ora come ora si usa solo quello).
 
bye

 Usa un suo tool QTADS (per mac).
 
Può essere collegato al fatto che c'erano problemi di portabilità con il C++...
 
Oppure hanno evoluto l'HTML-TADS in modo incompatibile alle limitazioni di glk (che obiettivamente ne ha parecchie)
 
Unito al fatto che è caduto un po' in disuso (non mi pare ci fossero entry alla ifcomp) il maintainer di gargoyle avrà deciso di lasciarlo indietro

 ...se continua così mi sa che ci dobbiamo accontentare di Inform (ripeto che non lo trovo malvagio, ma potrebbe esserci di meglio...)
 
To be honest. Il vantaggio dei motori HTML5+Javascript è che non devi 
scaricare nessun programma per interpretare alcunché e che puoi pensare 
a un prodotto derivato che può anche andare in vendita in formato ebook.
 
Poi nulla ti impedisce di costruire AT a parser anche con HTML5 e 
Javascript, se sei nostalgico. Come scrivevo prima la settimana scorsa 
abbiamo implementato, sperimentalmente, Hamurabi con inserimento dati 
manuale.
 
To be ancora più honest: se devo imparare Inform e le sue librerie 
preferisco impararmi javascript e farmi un mio modello ad hoc, così 
posso curarmi anche la sintassi javascript migliore per ebook senza 
dover dipendere da questo o quel convertitore.
 
IMHO usare inform oggi è anacronistico.

 IMHO usare inform oggi è anacronistico.
 
Certo, implementa tutto il parser di inform, e tutto il world model e tutto quel che ci va dietro in js.  Quando hai finito ne riparliamo :D
 
Non è particolarmente complesso (il parser ha un pattern matcher lineare e il world model è a 'contenimento semplice'), ci sono solo quelle cinquemila linee di codice da scrivere (e collaudare) da zero. Certo un parser alla Quill o alla Scott Adams è un'altra storia ma qui discutiamo di qualcosa di superiore a Inform.
 
Non so se ne valga la pena considerando che come già detto i parser sono ampiamente disponibili ed è impossibile fare il linguaggio perfetto (certe cose per esempio si esprimono meglio in TADS, altre in Inform...)
 
Se parliamo di anacronismi, tecnicamente, le AT in se sono anacronistiche :P

 Se parliamo di anacronismi, tecnicamente, le AT in se sono anacronistiche :P
 
diciamo la stessa cosa. una narrazione interattiva con parser e world 
model alla infocom oggi potrebbe non avere senso.
 

 model alla infocom oggi potrebbe non avere senso.
 
Mah, secondo me c'è una nicchia a 50/50% con il metodo a scelte multiple, se guardiamo com'è finita l'ultima ifcomp. Se guardiamo detectiveland (vincitrice, parserless) è praticamente un'avventura grafica... senza la grafica. Esempio, già nella prima stanza vedi la porta trasparente ma sai subito che non puoi farci niente, perché non c'è nessun pulsantone di fianco. A parte quanto son brutti quei pulsantoni:P Interfaccia molto intrusiva IMHO
 
I 16 modi per ammazzare un vampiro? Prosa ridotta all'osso, si finisce tutta in forse due ore... boh
 
Mi piacerebbe vedere in parserless il babelfish di hitchiker o la metà dei puzzle di Mulldoon's Legacy...


 
 
Io penso che sia un cambio di ottica nella produzione del testo. Non 
puoi pensare allo stesso "enigma" (o accadimento, come lo chiamavo io) 
parserless e con parser. Devi proprio progettare un testo in maniera 
diversa e - ma questo è un mio parere personale - anche con un 
linguaggio e una finalità proprie. Ma anche restando in ambito ludico, 
credo che Locusta mostri che è possibile riuscire a creare trame ed 
enigmi di grande complessità e bellezza pur in ambito parserless.
 
 
f.

Il 29/07/17 20:20, 
plucc...@gmail.com
 ha scritto:

Assolutamente d'accordo. Ci avevo già pensato.
Appena fatto vi mando il link.
 
pg

 
 
In realtà dire che le AT siano anacronistiche è un po' come dirlo dei 
libri in generale. Non trovo sia molto sensato. C'è chi è interessato e 
chi no. Inoltre parlerei più di IF che non di AT ;-)
 
pg
 

 parserless e con parser. Devi proprio progettare un testo in maniera 
 
Sicuramente, se avessero fatto i 16 modi su base parser sarebbe stato poco più di un esempio di programmazione del designer manual. Tuttavia come presentazione almeno riesce a compensare la mancanza di parser, anche se spesso ti viene da chiedere: se clicco questo cosa fa? lo prende, lo usa, lo guarda? Sembra di giocare a myst in solo testo :D
 
Sicuramente è un genere nuovo/diverso che è una via di mezzo fra il parser e la CYOA. Che poi piaccia o meno è una questione di target/moda/gusto personale... certo che un parser che giri su tablet è un filo scomodo (a meno di non fare come le ultime Legend dove un terzo di schermo era una lista di nomi/verbi da cliccare per comporre la frase)

 qualcosa di nuovo.
 
TADS è in C++ da quel che mi risulta, ma il problema non è quello... alla fine il world model di TADS credo si potrebbe implementare anche su Inform (mi pare che grossomodo le limitazioni di sistema siano più o meno quelle). Grossomodo basta riscrivere verblib.h :P:P
 
Una adv3 in italiano sarebbe sicuramente interessante da provare. L'ereditarietà multipla in JS (non so typescript) si simula in modo più o meno automatico con contenimento & delegazione (mi pare ci sia anche un teorema al riguardo), il fatto che sia presente o meno è una questione tecnofilosofica irrisolta, ci sono pro e contro (il contro maggiore è l'ereditarietà "a diamante", con classi base comuni ereditate più volte).
 
Il concetto è che, nonostante sia programmatore di professione, non mi pare una bella prospettiva scrivere una libreria nuova da zero :D (che poi js sia una delle mie nemesi non aiuta di certo, preferirei farlo in assembly XD)

 a un prodotto derivato che può anche andare in vendita in formato ebook.
 
Cito un thread su RAIF (anche se leggermente fuori contesto):
 
The more useful answer is "ChoiceScript" and generally mobile CYOA-things.
 
Questo pare essere il mercato. A me sinceramente non interessa