WIDE e XMI
Von: Paolo Gabriele Sfredda (paolo.sfredda@gmail.com) [Profil]
Datum: 08.04.2008 12:31
Message-ID: <ftfhi1$859$1@nnrp.ngi.it>
Newsgroup: it.comp.giochi.avventure.testuali
Datum: 08.04.2008 12:31
Message-ID: <ftfhi1$859$1@nnrp.ngi.it>
Newsgroup: it.comp.giochi.avventure.testuali
Ciao a tutti nuovamente. Tempo fa avevo scritto di un mio desiderio di trasportare l'output delle avventure anche su altre tecnologie. Paolo Lucchesi mi aveva dato anche degli ottimi consigli. Ho fatto un po' di prove con WIDE e l'ho trovato bello e interessante, anche se magari qualche aiutino in più sul completition non guasterebbe. L'idea cui sto lavorando in questo momento però parte dal presupposto che sarebbe bello poter prescindere dal linguaggio finale nello sviluppo della storia. Come dicevo in un post precedente, sarebbe bello dare agli scrittori la possibilità di esercitare la loro professione sollevandoli il più possibile dai problemi legati alla specifica implementazione. L'idea è sicuramente ispirata ai primi lavori di Colombini ma estesa con concetti più attuali legati sia a quanto è possibile fare con linguaggi potenti come Inform sia alla portabilità su più linguaggi. Sarebbe interessante quindi sviluppare un nuovo tool, o estendere wide, in modo che permetta di inserire tutti i dati inerenti l'avventura (oggetti, descrizioni, vocaboli, proprietà, attributi, ...) mediante un'interfaccia semplice. Il tool dovrebbe poi generare un XML particolare, XMI, quello che si usa per descrivere i diagrammi UML. Vantaggi: 1.In realtà è possibile usare qualsiasi tool UML che esporti XMI per "disegnare" l'avventura (mappa compresa) 2.Disponendo di XMI, esistono già o è molto più semplice realizzare, dei trasformer che producano il linguaggio desiderato (inform, tads, java, php, ...). Ovviamente si dovrà provvedere all'include delle librerie che, a seconda del linguaggio utilizzato, saranno diverse. A riguardo sto ancora valutando la soluzione da adottare per i metodi chiamati ma anche su questo ho una soluzione 3.Nulla cambia nella gestione a valle: se si è scelto di generare inform, il sorgente può poi essere modificato a piacere e compilato 4.La soluzione è decisamente molto più standard e supportabile da community più estese Problemi aperti: serve comunque un linguaggio per gestire alcune situazioni e questo linguaggio non dovrebbe essere legato alla scelta che si farà successivamente nella generazione Mi piacerebbe conoscere i vostri consigli e le vostre opinioni. A breve potrei postarvi un esempio. pg[ Auf dieses Posting antworten ]
