Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Riparliamo di Inform6 vs Inform7?

Lo so, se ne ï¿œ giï¿œ discusso molto ma questa volta volevo introdurre un 
nuovo concetto ricollegandomi anche alla discussione sul "mercato".
Penso di poter affermare che, almeno in Italia e non so all'estero, l'IF 
si ï¿œ sviluppata in particolar modo tra esperti, o quasi, programmatori 
con il gusto della scrittura e delle avventure. Il fiorire, pertanto, di 
linguaggi e/o sistemi piï¿œ o meno evoluti, orientati al tale tipologia 
creativa si sono rivolti prevalentemente ad un pubblico che giï¿œ sapeva 
qualcosa di programmazione.
Ciï¿œ ha determinato un forte spostamento anche tra i giocatori tra 
persone dello stesso ambiente e possibilmente in etï¿œ tale da poter 
spendere grandi quantitï¿œ di tempo.
Ora non sarï¿œ piï¿œ cosï¿œ ma non penso che l'affluenza nel settore sia 
cambiata molto e quindi ï¿œ rimasto un settore di nicchia per 
programmatori interessati alla scrittura.
Infatti, soprattutto in Italia, Inform7, rivolto ad un pubblico meno 
esperto di programmazione e piï¿œ di scrittura, non ha avuto un grande 
seguito e la produzione non ï¿œ molto proseguita.
Il vero programmatore lavora di editor (come Wide) e produce codice, piï¿œ 
che scrivere...
Mi sono chiesto: e se si realizzasse uno strumento che, non ancora 
evoluto come Inform7 ma piï¿œ veloce nell'uso e meno complesso di un Inform6?
Cosa ha fatto di Inform6 la cosa interessante e potente che in tanti 
hanno usato e apprezzato ma che gli scrittori non proveranno mai a 
usare se non altro perchï¿œ spaventati dalla quantitï¿œ di documentazione 
che c'ï¿œ da leggere?
La documentazione di Inform6 e 7 ï¿œ davvero orientata a chi di software 
non sa niente o quasi?
Conclusione: forse, ma sottolineo forse, ci vorrebbe uno strumento 
semplice e intuitivo che permetta a chi davvero non sa niente o quasi di 
programmazione e non ha molto tempo per leggere documentazione o 
programmare, di realizzare le proprie opere IF. Un sistema guidato dalla 
grafica e semplice che, a colpi di mouse, permetta di imbastire 
velocemente la struttura della storia (oggetti, classi, etc etc). 
Qualcosa che, prendendo spunto dalla sintassi ad oggetti di Inform6, 
molto ampia, completa ed efficace, permetta di trascurarne le 
implicazioni softwaristiche, ma di usarne la sola potenza.
Sto lavorando, per ora sulla carta, ad un progetto come questo che, tra 
le altre cose, permetta anche il reverse engineering da Inform6 
sfruttando, se mi sarï¿œ consentito, il parser di Wide.
Si tratta di un gestore di oggetti e classi che, permetta di pensare 
alla storia sia da un punto di vista della trama (plot) sia degli 
oggetti che la animano mediante attributi, properties, azioni.
Ritenete che ne valga la pena?

Paolo G. Sfredda ha scritto:

Mi auto rispondo per aggiungere un'ultima considerazione relativa anche 
alla discussione del "Nuovo mercato". Con un sistema come quello da me 
ipotizzato sarebbe possibile generare Inform6 ma anche altri linguaggi 
da compilare/interpretare. Verrebbero meno quindi alcuni vincoli odierni 
come la necessitï¿œ di usare glulx per tutto ciï¿œ che non ï¿œ solo testo 
sequenziale.
Per l'input utente, inoltre, sono ipotizzabili sistemi come il T9 su 
palmari e cell. Visto che mi sono occupato di sw per cell, vi garantisco 
che molte marche mettono a disposizione sistemi abbastanza potenti per 
ampliare il dizionario o usare direttamente il T9 in tutte le applicazioni.
Quindi si potrebbero scrivere opere in modo molto semplice e con un alto 
livello di interattivitï¿œ semplificata su palmare o cell.
Riciao

Alcuni aspetti di ciò che hai scritto (semplicità d'uso per non
programmatori, ad esempio) mi ricordano l'estensione "adventure book"
di Inform7. Viene posto l'accento sulla narrazione, ma permettendo
comunque operazioni più avanzate agli utenti smaliziati.
La tua idea è ovviamente più ambiziosa e ne seguirò gli sviluppi con
interesse.
Ciao, Leo

 Ciao, Leo

 Ritenete che ne valga la pena?
Sembra interessante. Puoi elaborare meglio ciï¿œ che vuoi fare e come 
dovrebbe funzionare il prodotto finale?
bye
-- 
Paolo Lucchesi - pluc...@NOSPAMtin.it


Infatti, ma del resto con alcuni applicativi/framework/linguaggi
moderni (rilasciati negli ultimi 2 anni) è possibile con pochi mezzi
sviluppare ottimi videogiochi, anche per dispositivi portatili
(android e iphone). Non c'è da stupirsi del crollo di utenza. Risulta
più facile sviluppare un gdr che un'avventura testuale
probabilmente :)
http://unity3d.com
 è il primo che mi viene in mente
Personalmente avrei già abbandonato il settore se non avessi in ballo
il progetto Neurosi, parallelo di fatto allo studio di Actionscript3
che mi è molto utile in ambito professionale. Mai e poi mai mi
metterei a (ri)studiare un tool come Inform 6/7, perché non ne caverei
un euro. :)
I miei 2 cents.

Paolo Lucchesi ha scritto:

In effetti sono partito con le idee un po' confuse e, leggendo in 
qualcuno dei vari post recenti dell'uso di ADRIFT, ho cominciato a 
leggermi il manuale della versione 4.
Devo dire che mi permetto di dissentire un po' con plucchesi in quanto 
lo trovo un progetto completo e sufficientemente flessibile per coprire 
una buona percentuale di casi d'uso.
La mia idea era invece un po' piï¿œ ampia e orientata a degli standard piï¿œ 
diffusi in quanto ADRIFT ha come unico difetto quello di essere troppo 
proprietario.
La mia idea ï¿œ piï¿œ o meno la seguente.
1.Realizzare vari parser (ovviamente scritti da esperti dei vari 
linguaggi) per caricare nel nuovo applicativo i dati di opere giï¿œ 
esistenti (si puï¿œ iniziare con I6). Questi parser, per fare le cose 
bene, dovrebbero produrre xml, secondo uno schema da concordare, che 
funga da meta linguaggio.
L'applicativo dovrebbe quindi essere semplicemente in grado di leggere 
questo xml secondo un certo schema che chiamerei if-xml.
In questo modo, sia i vecchi lavori giï¿œ scritti sia quelli nuovi possono 
essere caricati in questo applicativo con il quale si procede con 
l'editing in modo piï¿œ o meno spinto a seconda di quanto lo si vuole 
usare come ide o come rad ma con il grande vantaggio di poter 
prescindere dallo specifico linguaggio e di usare strumenti piï¿œ 
produttivi che non la stesura del codice.
Il nuovo tool dovrebbe quindi generare il sorgente nel linguaggio voluto 
(if-xml, i6, tads, ...) e successivamente questo essere compilato o 
ulteriormente modificato.
Cosa c'entra con il mercato?
Ritengo che maggiore sia il numero degli scrittori e delle loro 
tipologie e maggiori sono le probabilitï¿œ che le opere interessino i 
lettori. Ci sarebbe una maggiore divulgazione. Tra i vari linguaggi 
generati potrebbe esserci javascript o php per consentirne la 
divulgazione anche via web in modo massivo o anche giï¿œ usando parchment 
si potrebbero ottenere risultati a grande compatibilitï¿œ.
Non ï¿œ forse vero che leggere if ï¿œ un po' come leggere un e-book? E non ï¿œ 
forse vero che nei prossimi anni ï¿œ prevista un'esplosione nell'uso degli 
e-book (ahimï¿œ)?
Ci vogliono contenuti e non solo stile puzzle da risolvere ma della vera 
e propria fiction anche se interattiva.
Aug.
PS: ho finalmente una storia che forse sarï¿œ degna di essere scritta e 
raccontata via if e mi piacerebbe testare ADRIFT per campirne pregi e 
difetti nella scrittura. Devo pensare a un titolo...

 funga da meta linguaggio.[...]
Buona fortuna... Ne avrai bisogno.
Spero di sbagliarmi, ma mi sembra che l'obiettivo che ti poni sia 
oltremodo complicato. In particolare la parte dell'acquisizione (a meno 
che non venga fatta in modo banale - <source>tutto il sorgente 
inform</source> - ma non la vedrei molto utile).


Non ci dimentichiamo la gestione di suoni e immagini.
Inform 7 attualmente gestisce le immagini in modo ottimale grazie alla
"magia di IF6" ma è completamente sguarnito di un controllo decente
sull'audio (più canali audio, fade in, fade out, etc...).
E la cosa sinceramente limita la creatività dell'autore.

 E la cosa sinceramente limita la creativit� dell'autore.
In effetti � strano, ma notoriamente la comunit� internazionale � meno 
sensibile di noi per quanto riguarda la multimedialit�.
Perch� non realizzare un'estensione apposita? Non conosco I7, ma - se 
serve - nell'estensione SGW.h c'� l'implementazione in I6 di fade in, 
fade out e crossfade (e posso dare delucidazioni, visto che la roba glk 
non � semplicissima).


 difetti nella scrittura. Devo pensare a un titolo...
Ciao, mi unisco al thread partendo da questo tuo ultimo post.
Anzitutto, volevo dirti che se ti butti a sviluppare un AT con ADRIFT
ti posso passare i file per l'implementazione dell'italiano che ho
usato per la mia AT del CAT 2010. Io ho utlizzato i file di Grassi e
li ho solo ritoccati qui e là e vi ho aggiunto personalizzazioni.
L'implementazione dell'italiano in ADRIFT può essere a tratti
frustrante. Sinteticamente, vi sono due file che vanno creati e
importanti in ADRIFT Generator: uno per la traduzione dei comandi del
giocatore, l'altro per la traduzione dell'output del parser.
Quest'ultimo è strutturato in un file di testo che contiene riga per
riga le parole/frasi da tradurre, 
p.es
:
"you can't|non puoi"
... dove il simbolo | separa il testo originale inglese del parser
dalla sua tradizione italiana.
I problemi nascono con le varie particelle, articoli, ecc.:
"to|a" causerà la deformazione di parole come "vento" in
"vena" (ritraduce i testi di output italiani oltre che quelli
inglesi).
In definitiva ho ritoccato il file originale assicurandomi che fossero
inseriti spazi prima e dopo (es. " to | a ").
In teoria, qualsiasi output ed input dovrebbe poter essere
italianizzato, di fatto vi sono risposte del parser non abbastanza
specifiche ad un evento (per esempio, senza riferimento all'oggetto
dell'azione) da poter essere personalizzati. Altresì, se nomini un
oggetto "maniglia della porta", nei vari task che esaminano i comandi
impartiti dovrai tener conto della traduzione italiana-inglese e del
fatto che il comando giungerà all'interprete come "maniglia of the
porta", ecc.
Insomma, quel che si guadagna in praticità per via dei menù visuali,
ecc., lo si perde nei labirintici problemi dell'implementazione in
italiano.
Detto questo, l'idea di un ambiente di sviluppo per IF con menù tipo
ADRIFT mi pare buona. Anzitutto, per chi preferisce lavorare in
modalità codice-digitato è comunque possibile modificare con un editor
di testo i file che ADRIFT importa (e in teoria, con questo metodo si
ha un controllo maggiore rispetto all'interfaccia).
Probabilmente, l'ideale sarebbe creare un sistema che offra sia l'uso
dell'interfaccia che l'accesso diretto alla stesura del codice.
Tra gli aspetti pratici dell'interfaccia vi è il fatto che quando si
cambia il nome di un oggetto, personaggio, o stanza, l'intero sorgente
viene aggiornato immediatamente.
Non credo però che si possa costruire un'interfaccia abbastanza
complessa da poter gestire funzioni avanzate di codice senza che
l'operazione diventi più complessa della stesura diretta di codice. In
ADRIFT per creare dei cicli condizionali bisogna creare un sacco di
task e/o eventi che, fossero scritti in forma di codice, sarebbero
molto più gestibili.
Probabilmente la soluzione "ideale" sta nel mezzo: accesso totale ai
sorgenti + interfacce per la semplificazione di operazioni complesse
ricorrenti.
Tristano

 Tristano
Se i file italianizzanti sono quelli del sito zenfactor, li ho scaricati 
proprio ieri sera. Grazie!
Per il resto concordo con tutto quanto hai scritto dato che hai 
sintetizzato quello che volevo dire/fare io.
Ho appena comprato la registrazione di ADRIFT perch� mi sembrava giusto 
sostenere il grande lavoro fatto per realizzarlo. Ora per� sono 
terrorizzato da quello che mi hai detto sull'inglesizzazione 
dell'italianizzazione ;-) per i task.
Va be, un passo alla volta.

 Paolo Lucchesi - plucch...@NOSPAMtin.it
Diciamo che sarebbe anche tutto bello e impacchettato perché nel
lontano 2007 alcuni programmatori spagnoli han ideato e rilasciato, un
anno dopo, questa simpatica espansione per IF6. Solo che sono ormai
più di due anni che dura sto betatesting per la versione in IF7 :P


riguardo l'italianizzazione dell'inglesizzazione (o viceversa!) ti ho
risposto sull'altro thread ... e i file di localizzazione te li ho
inviati tramite mail privata.
Tristano

 implicazioni softwaristiche, ma di usarne la sola potenza.
Mi chiedevo: ma per realizzare questo progetto non è possibile
costruire un software che si interfacci con il compilatore di Inform
6?
Prendendo spunto da ADRIFT, il programma potrebbe avere l'interfaccia
per la creazione di una stanza/oggetto/ecc., in cui si impostano i
vari campi e si spuntano le varie scelte e il programma le converte in
codice.
Sempre il programma, gestirebbe la compilazione, le librerie, ecc.
Questo consentirebbe di avere un ambiente di sviluppo ad interfaccia
già impostato per l'italiano, di facile uso e che non richiede la
stesura di codice.
Non ho mai usato Inform 6, ho solo spulciato la documentazione, però
mi pare possibile realizzare un interfaccia del genere, così come è
stato possibile realizzare Wide.
Questo approccio ti risparmierebbe un sacco di tempo perchè partiresti
da un linguaggio di sviluppo IF già completo e testato, e i giochi che
produrrebbe sarebbero già negli standard comuni.
Se poi vuoi ricalcare ADRIFT, ci inserisci già le librerie per la
gestione della finestra grafica, la mappa e i suoni, e il gioco è
fatto. Avresti una specie di ADRIFT in lingua italiana.
Un'interfaccia del genere, realizzata per sistema operativo Windows,
potrebbe benissimo essere programmata in AutoIT che è un linguaggio
pratico e consente di sfruttare tutte le risorse e DLL di Windows.
(spero di non aver detto "tavanate"!!!)
Tristano