UN APPUNTO SU TWINE!!!!

Ho scaricato e installato Twine, quel programma per creare libri-game in HTML che ho menzionato alcuni post fa.

Installandolo su XP ho avuto problemi a farlo funzionare causa una DLL mancante.

La DLL in questione è la MSVCP71.DLL e la potete scaricare gratuitamente a questo link:

http://www.dll-files.com/dllindex/dll-f … ml?msvcp71

poi basta copiarla nella cartella dove si è installato Twine:

C:\Programmi\Twine

Non so perchè mancasse questa DLL, forse il programma dava per scontato fosse presente sul sistema.

Ad ogni modo, sperimenterò un po' con questo programma e vi farò sapere. Così, di primo impatto, mi sembra interessante, anche perchè si può sfruttare il linguaggio Python nei libri creati -- cosa che potenzia i libri per chi conosce il codice.

THE GAMEBOOK ENGINE

Ho anche scaricato The Gamebook Engine e ci ho dato un'occhiata. Si tratta di un motore per giocare librigame scritti tramite file di testo secondo un linguaggio dedicato. I libri-gioco creati con questo prog. includono grafica e suoni.

Mi sembra che sia un programma molto vicino a quello che prospettavate in questo thread. Però gira solo su Windows e Linux per ora. Ma essendo Open Source può essere tradotto facilmente anche per altri sistemi operativi. E, quel che conta, è che ha un suo pseudo-linguaggio di programmazione per realizzare i librigame che si presta a essere interpretato-on-the-fly da qualsiasi piattaforma.

Prodo ha scritto:

Che tipo di file supporta? Importa e gestisce file scritti con programmi altri, oppure ha incluso un editor specifico per scrivere LG?

Non mi è  molto chiaro. Purtroppo il Wiki di supporto per questo programma è ancora in alto mare, e compare solo un codice di esempio ma nulla di più. Direi che è un "linguaggio" creato ad hoc per il programma. Guardano l'esempio sul Wiki sembra abbastanza intuitivo, credo che per apprenderlo sia sufficiente studiarsi i file di esempio che si scaricano con il programma.

Ti ringrazio per le precisazioni --  mi rendo conto che i termini pertinenti questi generi sono soggetti a tante interpretazioni diverse, e a volte è difficile farsi strada nel discorso anche solo per i fraintendimenti. Per "stanze" intendevo appunto qualcosa come "nodo", in senso generico.

Seven_Legion ha scritto:

Tradizionalmente il mondo dei librogame e' composto da utenti tanto appassionati di narrativa avventurosa quanto poco interessati di computer e programmazione. (al contrario della comunita' IF che ' formata da appassionati di computer fin dagli anni '80)
Fare uno standard sofisticato e "potente" e che presupponga una mentalita' da informatico (come l'esempio che hai fatto) potrebbe essere la prassi ottimale nella comunita' delle adventure. Qua da noi, farebbe sicuramente fuggire i potenziali scrittori.

Questo è vero, però credo che uno standard tipo XML sia necessario. Alla fine, chi creerà i libri lo farà appoggiandosi a dei programmi con interfaccia grazie ai quali il "codice" XML non dovrà neanche vederlo. Alla fine, se ci pensi, anche un documento Word sottende tutti dei tag che l'utente non vedrà mai ma che sono incorporati nel file. Questo però non scoraggia dall'uso dei wordprocessors coloro che non hanno feeling per i codici informatici.

Quello di creare uno standard intermedio tra i vari applicativi di sviluppo e quelli di pubblicazione, credo sia l'unico modo per avviare uno standard di lavoro comune ai vari generi, piattaforme, ecc. E' ovviamente un compito che grava sugli informatici, ma lo sviluppo di applicativi che offrano delle interfacce user-friendly renderà il compito quanto più lontano possibile dalla programmazione.

Anche Libro Game Creator crea dei file con dei tag simili a quelli da me proposti -- ed è grazie a quei tag che sono riuscito a creare l'applicativo di conversione LGC2ZM -- però l'utente che crea i libri non ha l'impressione di star lavorando a dei codici informatici -- l'esperienza è simile all'uso di un wordprocessor.

Le differenze che tu sottolinei tra libri-gioco e avventure testuali sono molto importanti (e io non le comprendo ancora appieno), ciò nonostante credo che uno standard XML dovrebbe essere abbastanza elastico da accogliere entrambi i generi.

Mi è chiaro, ad esempio, che gli sviluppatori di avventure testuali quando realizzano un libro game possono facilmente cadere nell'errore di voler indicare il passaggio da ogni stanza all'altra -- una cosa che ha senso in un gioco di avventura testuale ma che ne ha molto meno in un'opera di narrativa poichè nella narrativa è sufficiente che il protagonista enunci l'intenzione di andare in un luogo, dopodichè il paragrafo successivo si può tranquillamente descrivere il protagonista in quel luogo -- senza dover specificare che ci è arrivato andando a nord, poi a est, ecc.

Vi sono aspetti dei libri gioco che immagino siano legati alla tradizione, e di cui non saprei bene cosa si prefferisce, come ad esempio il fatto che in un libro game è normale che ci si imbatta in un testo del tipo "Se hai preso la spada vai a 140, altrimenti vai a 150." L'accesso a variabili di ambiente può evitare di mostrare testo di questo tipo dato che può stabilire cosa mostrare in base alle variabili che diranno al programma se il giocatore è in possesso della spada o meno. Questo rende il testo in qualche modo più lineare, però è anche vero che per gli appassionati di libri-gioco questo non è mai stato un problema.

Comunque, insisto sull'importanza di uno standard di questo tipo, poiché consentirebbe di collegare tra loro molti programmi già esistenti. Certo è che la creazione di un simile standard richiede una lunga e dettagliata discussione di quali siano le funzioni di base e quelle avanzate richieste per un libro gioco. Uno sforzo che ritengo sarebbe ampiamente ricambiato dal fatto che si avrebbe un modello di riferimento solido cui rifarsi. Mi sono imbattuto in un sito (non ricordo più quale) in cui  stavano lavorando a un progetto del genere per il cinema e il teatro -- uno standard XML per le sceneggiature. Era un bel progetto ed era già decollato nonostante non fosse ancora definito come ultimato.

Seven_Legion ha scritto:

Si usa questo formato "interno" dei TAG che l'utente non dovra' manipolare direttamente, utilizzando invece degli editor che operano a livello di resa visiva del progetto (l'utente lavora in sostanza sul  "wysiwyg" )
Ebbene, neanche farlo apposta, tutti gli esempi di file citati sopra sono proprio quelli noti per la poca stabilita':
....
Insomma, bisogna studiare bene la faccenda per evitare di porre costrutti poi difficili da gestire.

Che dire ... l'instabilità non è certo dovuta agli standard in sè ma alle implementazioni dei programmi che gestiscono file con quegli standard.

Voglio essere però ottimista e sperare che a un buono standard seguano anche programmi ben realizzati. ;-)

A queste domande la persona piu' indicata a rispondere potrebbe essere Venerandi.
Per la loro iniziativa, immagino abbiano studiato bene il problema prima di prendere le loro decisioni.
Anche io ho sentito che certi e-reader sono basati su kernel linux ma temo questo non significhi nulla circa l' eventuale possibilita' di far girare del software.
C'e' il fatto che, credo, gli e-reader siano molto "basici" nelle funzioni. Altrimenti alla partenza dovresti aspettare il caricamento del sistema operativo, diventando pressoche' dei tablet PC e vanificando la comodita' d'uso...