Newsgroup: it.comp.giochi.avventure.testuali
Titolo: if-xml: una sfida teorica

Diversi anni fa mi intrattenevo nel giardino di un mio amico conferendo 
con lui di temi sull'object orientation applicata proprio all'IF che 
all'epoca si chiamava riduttivamente "adventure".
Quanto teorizzato all'epoca, ovviamente in forma embrionale, l'ho 
ritrovato nel modello di inform 6 che ho infatti subito molto apprezzato.
Durante l'universitï¿œ, perï¿œ, ho sviluppato un piccolo sistema fatto di 
uno scriber e di un runner che mutuava il sistema proposto da erix in 
basic. Il mio era sviluppato in pascal (il turbo pascal della borland 
nella mitica versione 3.1). Adrift, in forma decisamente molto piï¿œ seria 
ed evoluta, mi ricorda quei tempi.
Anche io amo lo sviluppo del codice e trovo il mouse di intralcio, delle 
volte, ma mi piace trovare nuove forme di rappresentazione che uniscano 
la potenza dell'OO, alla stabilitï¿œ dei sistemi relazionali, alla 
facilitï¿œ di accesso delle gui. Non possiamo negare che l'avvento dei 
sistemi visuali ha permesso la contrazione dei tempi di approccio per 
gli utenti anche esperti.
Quindi vedo nel modello di inform 6 e nell'approccio di adrift una 
coniugazione molto interessante che, se gestita con standard aperti 
(come xml e dintorni, o anche altri) e senza precludere l'uso dei 
linguaggi dedicati (parser e generatore inform 6 o altri), potrebbe 
aprire nuovi orizzonti.
Per definire lo schema if-xml userei quindi il modello a oggetti di 
inform 6 ma affiancherei (non sostituirei) a wide, un toolkit per chi 
vuole concentrarsi di piï¿œ sulla scrittura che non sulla tecnica.
<object name="bird">
	<property before="...">code</property>
	...
	<attribute edible="yes"></attribute>
	...
</object>

 aprire nuovi orizzonti.
La butto lì (giusto perchè è un'idea che mi frulla in testa da un
po'): mi chiedevo se l'UML potesse avere un posto in tutto questo. Non
conosco l'UML ma mi pare di capire che sia un buono standard per la
gestione/pianificazione/visualizzazione di codici OO.
http://it.wikipedia.org/wiki/Uml
Magari può essere adottato come standard (anche solo in maniera
parziale) per la visualizzazione nelle varie interfacce. Questo
consentirebbe di poter accedere alla struttura delle AT in costruzione
tramite una mappa visuale in grado di sintetizzare in maniera
immediata i vari "snodi" del gioco. Altresì, potrebbe visualizzare
eventuali problematiche del codice in maniera visuale, esplicitando in
maniera chiara i punti in cui il codice è problematico per il contesto
generale, ecc.
Tristano

 Tristano
Su questo stavo gi� lavorando.
Esiste un tool (bouml - 
http://bouml.free.fr/
) che permette di modellare 
in UML. E' possibile estendere l'applicazioni con dei plug-out (cos� li 
chiama l'autore) per l'export dell'UML nel linguaggio che si vuole. 
Esistono gi� plug-out per vari linguaggi.
Basterebbe realizzare quello per inform.
L'idea infatti � imparentata con quella dell'xml: adottare una 
rappresentazione standardizzata per generare codice a partire da un 
modello visuale.
A tal fine esiste gi� uno schema xml per la traduzione di UML che si 
chiama xmi, il cui plug-out gi� esiste. A questo punto si tratta di 
usare gli stereotipi giusti per convertire xmi generico nel linguaggio 
voluto, ad es. inform.

Prova a dare una occhiata a questo.
http://ifml.sourceforge.net/
Rob

 </object>
Tutto molto interessante, per lo meno in teoria. Perï¿œ in pratica mi 
sembra che non sia cosï¿œ semplice (ma forse sono io che non ho capito).
Il toolkit come dovrebbe funzionare? Mi mostra la mia lista di oggetti, 
io ne scelgo uno, mi fa vedere una lista delle proprietï¿œ e degli 
attributi dell'oggetto in questione e me le fa modificare in una casella 
di testo?
Se funziona cosï¿œ, non vedo un grosso vantaggio in termini di semplicitï¿œ; 
potrebbe esserci un vantaggio in termini di organizzazione.
Ti ricordo che una properties, prendiamo ad esempio n_to, puï¿œ avere 
valori molto diversi, puï¿œ essere una stanza adiacente, una porta, una 
stringa o una routine (o altro, ma si entra nel campo della 
programmazione esoterica); se mi togli una o piï¿œ di queste possibilitï¿œ, 
limiti molto quello che posso fare.
Inoltre molte cose di un programma Inform non sono codificabili come 
oggetti (gli Entry Point, e la gestione delle azioni, per esempio), le 
proprietï¿œ sono modificabili, posso definire nuove proprietï¿œ e attributi,
etc.etc.
A meno di non realizzare volutamente una versione "semplificata" (magari 
con la possibilitï¿œ di usare cose di difficoltï¿œ progressiva), ma 
ovviamente scordandosi l'importazione (per lo meno completa) di progetti 
preesistenti. Questo potrebbe essere interessante...
Ah, il formato xml sarebbe solo un formato "di salvataggio" del toolkit?
bye
-- 
Paolo Lucchesi - pluc...@NOSPAMtin.it

Farei un passo alla volta: prima di tutto tenterei, prendendo spunto da 
quanto segnalatomi da Grassi, la definizione di un xml dedicato alla IF. 
Partendo da ifml ed estendendolo/modificandolo, sulla base primariamente 
di inform 6.
Questo primo passo consente di convertire un linguaggio, ad oggetti ma 
specifico, in un insieme relazionale di informazioni. E permette anche 
di ipotizzare come deve funzionare il parser per convertire, ad esempio, 
inform 6 in xml.
Successivamente la gui ï¿œ relativamente semplice da realizzare anche 
perchï¿œ, come dice plucchesi, si puï¿œ pensare ad un percorso evolutivo che 
all'inizio permette un primo grado di completezza/complessitï¿œ per poi 
evolvere in qualcosa di sempre piï¿œ avanzato.
Inoltre tale lavoro permetterebbe di standardizzare un po' l'approccio 
tecnico (NON QUELLO CREATIVO) a paritï¿œ di problemi. Definire quindi dei 
pattern per risolvere problemi imparentati tra loro. Quindi, invece che 
lavorare alle librerie, lavorare al modo di implementare le complessitï¿œ 
narrative.
Il vero grande merito di ADRIFT ï¿œ quello di aver scelto una metodologia 
standard per affrontare alcune classi di problema e, a parer mio, non ï¿œ 
sbagliato. In tutti i settori dell'informatica lo si ï¿œ fatto.
Paolo Lucchesi ha scritto:


Paolo Lucchesi ha scritto:

Nella precedente risposta ho messo il mio testo sopra per sbaglio.
Lo rimetto qui di seguito.
Farei un passo alla volta: prima di tutto tenterei, prendendo spunto da 
quanto segnalatomi da Grassi, la definizione di un xml dedicato alla IF. 
Partendo da ifml ed estendendolo/modificandolo, sulla base primariamente 
di inform 6.
Questo primo passo consente di convertire un linguaggio, ad oggetti ma 
specifico, in un insieme relazionale di informazioni. E permette anche 
di ipotizzare come deve funzionare il parser per convertire, ad esempio, 
inform 6 in xml.
Successivamente la gui ï¿œ relativamente semplice da realizzare anche 
perchï¿œ, come dice plucchesi, si puï¿œ pensare ad un percorso evolutivo che 
all'inizio permette un primo grado di completezza/complessitï¿œ per poi 
evolvere in qualcosa di sempre piï¿œ avanzato.
Inoltre tale lavoro permetterebbe di standardizzare un po' l'approccio 
tecnico (NON QUELLO CREATIVO) a paritï¿œ di problemi. Definire quindi dei 
pattern per risolvere problemi imparentati tra loro. Quindi, invece che 
lavorare alle librerie, lavorare al modo di implementare le complessitï¿œ 
narrative.
Il vero grande merito di ADRIFT ï¿œ quello di aver scelto una metodologia 
standard per affrontare alcune classi di problema e, a parer mio, non ï¿œ 
sbagliato. In tutti i settori dell'informatica lo si ï¿œ fatto.
pg

 Rob
Grazie. Molto interessante.
pg