Newsgroup: it.comp.giochi.avventure.testuali
Titolo: IF browser-based (javascript)

ciao a tutti!
ho già scritto più volte in questo NG per parlare della mia idea. è un
progetto che, a fasi alterne, sviluppo da anni.
visto che la maggior parte delle applicazioni si stanno spostando sul
web e molte, indipendentemente dalla complessità, nei nostri browser
(e parlo di interi sistemi operativi come eyeos, word processor,
giochi di ogni tipo), sono convinto che il futuro dell'if passi, o
possa passare, per il web. i motivi che mi rendono convinto di cioè
sono, oltre alla constatazione di una tendenza in atto:
1. una IF è un'applicazione testuale, quindi perfetta per essere
portata sul web
2. la possibilità immediata di avere un sistema di formattazione del
testo (colori, disposizione del testo, ma anche immagini o audio
3. l'eventuale possibilità di avere, a pochi click di distanza dal
gioco, un forum per l'aiuto o la segnalazione di errori o giudizi, un
sistema di help rappresentato da altre pagine, eventualmente nua
pagina in cui raccogliere le statistiche sugli utenti che hanno finito
il gioco in meno tempo o con più punti ecc.
4. un sistema basato sul browser è immediatamente compatibile con una
tendenza che da sempre accompagna lo sviluppo delle IF, ovvero
l'essere multipiattaforma.
5. nessuna necessità di installare alcun nuovo software per giocare
all'avventura (ammesso che il computer abbia un browser installato,
cosa certa nella stragrande maggioranza dei casi)
6. nessuna necessità di rilasciare "aggiornamenti" del software o
versioni multiple dei gioco, visto che basta uploadare una nuova
versione corretta del gioco perchè tutti gli utenti giochino sempre
all'ultima versione disponibile.
nella mia ricerca per un sistema di sviluppo mi concentrai
inizialmente sul PHP, ovvero un sistema combinato client / server.
l'ovvio problema era rappresentato dalla necessità di essere collegati
in rete per giocare oltre a una non immediatezza di risposta ai
comandi. mi spostai quindi su un tipo di applicazione esclusivamente
client basato su javascript.
una cosa che mi è parsa chiara da subito, arrivato a questo punto, è
che, per sfruttare il mezzo e poichè un sistema basato sul web avrebbe
attratto parecchi neofiti (non c'è necessità di cercare un client per
le if, installarlo e scaricare il gioco) o giocatori occasionali o
solo curiosi, avrei abbandonato la "riga di comando", così cara e
caratteristica dell'IF ma anche, per certi aspetti, meno immediata dal
"click del mouse" che chi naviga il web è abituatuato ad usare per
ogni tipo di interazione le pagine.
nelle varie prove che ho fatto (il sistema è in via di sviluppo) mi
sono concentrato, alla fine, su due modi per affrontare il problema di
come impostare il gioco. entrambi sono stati discussi qui sul NG anni
fa quando portai anche esempi. purtroppo i siti sui quali erano
presenti i progetti non sono più online e il codice non è disponibile.
torno ad affrontare quello che per è un problema ancora aperto e lo
faccio con maggiore consapevolezza e padronanza del mezzo di
programmazione, oltre che una maggiore convinzione della mia idea.
i due sistemi sono "menu contestuale" e "verbi limitati".
per immaginare un sistema a verbi limitati si figuri facilmente una
versione testuale dello SCUMM system, ovvero il motore dietro le
avventure testuali della lucasart (monkey island, maniac mansion, sam
& max ecc). in una parte del testo c'è la descrizione di quello che il
protagonista vede (come una qualunque IF), nella parte sottostante una
serie fissa di una decina di verbi (prendi, parla con, spingi, usa,
osserva, vai). l'interazione con il gioco avviene clickando sul verbo
e successivamente sull'oggetto (o personaggio) che è l'oggetto diretto
dell'azione (e poi, eventualmente, sull'oggetto indiretto come nel
caso di "dai X a Y"). l'oggetto è un link nella descrizione o
nell'inventario.
il sistema a menu contestuale, invece, funziona in maniera simile ma
il numero di azioni eseguibili su un oggetto non è fisso, ma cambia a
seconda dell'oggetto. Così se in una stanza ho un bicchiere d'acqua e
una leva, clickando sulla leva saranno disponibili le azioni "esamina,
tira, spingi" e clickando sul bicchiere "esamina, prendi, bevi".
il tipo di approccio è radicalmente differente rispetto a quello della
if tradizionale, con vantaggi e svantaggi diversi a seconda del metodo
ed entrambi richiedono di progettare le avvventure in maniera non
comparabile rispetto a quelle tradizionali.
entrambi i sistemi, per iniziare, escludono il problema che affligge
molte IF noto come "indovina la parola". mi trovo davanti a un puzzle,
so cosa devo fare, è ovvio che è quella la soluzione, ma non so come
comunicarla al parser perchè continua a non capire (o non accettare o
mal interpretare) le mie istruzioni.
un sistema a verbi fissi è stato usato per avventure divertenti e
diverse fra loro (come quelle della lucas) con grande successo, quindi
la mia proposta è quella, sostanzialmente, di una versione non grafica
di quel tipo di gioco. ancorato però alle IF tradizionali, mi rendo
conto che un sistema siffatto toglie molto di quell'illusione di
"libertà completa" che è una delle cose più affascinanti dell'IF.
immaginiamo un ripiano pieno di polvere. con il sistema a verbi fissi
posso "esaminare" la polvere per scoprire che è lì da anni, "usare il
fazzoletto con la polvere" e pulire il ripiano, e magari persino
"prendere la polvere" e metterla all'interno di una boccetta che ho
precedentemente raccolto. ma una delle soddisfazioni più grandi
regalate dall'IF è provare a digitare "sniffa la polvere" e scoprire
che l'autore ha previsto tale possibilità e risponde in maniera
scherzosa "sei già in crisi d'astinenza?" o con qualche impatto nel
gioco, per esempio facendo ammalare il protagonista.
l'altro sistema, più libero, permette in effetti di "sniffare la
polvere" (sniffa è uno dei verbi che compaiono nel menu contestuale
quando si clicca sul ripiano e ci viene detto che c'è della polvere e
polvere è uno dei link cliccabili). la maggiore libertà del sistema è
bilanciata in negativo dal problema del guidare troppo il giocatore
verso la soluzione. i puzzle non possono mai essere improntati a
qualcosa di strano e particolare, semplicemente perchè soluzione cosa
strana e particolare sarebbe immediatamente visibile al giocatore.
certo, i menu contestuali sono flessibili, per cui, rimanendo
all'esempio della polvere, si potrebbe rendere il verbo "sniffa"
visibile solo se precedentemente il personaggio ha frugato nei
cassetti, trovato la rinazina spry nasale e l'ha usata (prima aveva il
naso chiuso e quindi non poteva sniffare). di nuovo: si richiede un
approccio alla progettazione dell'avventura diverso.
sono quasi certo che almeno due argomenti verranno fuori come
risposte:
1. idra
2. inform
per quanto riguarda inform, vi prego dall'astenervi dalla discussione
se l'unico apporto è "perchè reinventare la ruota? un altro sistema di
sviluppo? c'è già inform, con la versione sette è diverntato perfetto
e se sei fissato con il web ci sono le applet java come interpreti per
i z5, o prova tads che ha il supporto per l'html e lo stesso fa hugo"
o se siete contrari per principio a giocare nel browser. su questo
punto sono inamovibile, ma sono ansioso di conoscere le opinioni
riguardo all'interfaccia (stabilito il punto fermo del mio progetto).
per idra, ho già visto il sistema, da anni e parecchie volte, ma è più
simile a una cyoa dinamica rispetto a quello che sto sviluppando io.
ah, prevengo anche saintpumpkin: sì, potrei fare la stessa cosa in
flash rispetto al javascript, sì, già lo stai facendo tu, sì, rispetto
il tuo punto di vista ma non lo condivido, il flash mi fa schifo per
applicazioni non grafiche e l'actionscript è una versione dell'ecma
esattamente come il javascritp, con la differenza che facendo
un'avventura testuale in javascript non devo avere a che fare con
grafica vettoriale, frame e scene che sono perfette per un giochetto,
ideali per un filmano ma non c'entrano nulla con quello che sto
facendo io!
grazie dell'attenzione, aspetto i vostri commenti!
gustavo

 tira, spingi" e clickando sul bicchiere "esamina, prendi, bevi".
Ho fatto un paio di mesi fa uno studio su un sistema basato su principi 
simili: e' perfettamente fattibile in javascript, anche se bisogna 
sudare un bel po' con css e dom (mi sono scritto una libreria 
portatile). Il save e' un problema, ma si riesce a risolvere.
Voleva essere un discendente di Idra con un'interfaccia innovativa, ma 
poi ho trovato lavoro... e fin troppo (anche se non so per quanto).
   .Erix.

 applicazioni non grafiche e l'actionscript è una versione dell'ecma
Il flash mi fa schifo punto :D
Oibo', fare una cosa del genere in javascript non e' poi tanto
terrificante... se prendiamo una cosa tipo il famoso modulo base, in
meno di una settimana si potrebbe adattare in js e farlo girare in un
browser... da li a trasformare il parser biparola in un punta-e-clicca
basato su eventi dom non passa tanto...
Per curiosita'... come hai intenzione di salvare? in un cookie
gigante? (non e' implausibile, hai 4k scarsi di spazio a disposizione)
Sinceramente la cosa non mi interessa piu' di tanto... altrimenti
dovrei fare un browser basato su gargoyle :D
Idee da sviluppare comunque

Post interessante (ma sono al lavoro e non l'ho ancora letto
interamente), sappi che condivido appieno la tua riflessione.
Quello che mi lascia dubbioso sulle if online sono il sistema di
salvataggio (database? cookie?) che non mi sembra adatto. Vi è inoltre
la modalità di gioco che mi fa riflettere, le connessioni ad internet
oggi giorno costano veramete poco ma non ho mai trovato "esaltante"
l'idea di poter giocare solamente connesso alla rete.
L'ideale sarebbe sviluppare il gioco con javascript per permettere il
download dell'avventura e poterci quindi giocare offline anche su
dispositivi portatili quali cellulari dell'ultima generazione. Il
problema in questo caso nasce dal fatto che il codice sarebbe
completamente "scoperto" e sarebbe quindi veramente troppo facile
venire a capo dell'avventura (senza contare che javascript è
supportato in maniera differente dai vari browser).
Ad ogni modo mi sto orientando anch'io su un sistema di gioco web-
based con parser "limitato" (rimane la possibilità di digitare
azioni).
Discutiamone insieme, mi piacerebbe sapere cosa ne pensano tutti.



 supportato in maniera differente dai vari browser).
Non me ne parlare... ci ho messo un bel po' a farmi una libreria
portatile (FF 2, IE 7, Opera 9, Safari), sia pure limitata al mio uso.
Comunque si puo' fare.
   .Erix.

Il Tue, 17 Jul 2007 08:30:35 +0000, pistacchio ha scritto:
Io non sono esattamente dentro appassionato di text adventure però per il 
salvataggio cosi mi è venuto in mente una cosa.
Intanto per Il fatto della nuova versione giocabile e che farebbe 
lamentare i giocatori con un salvataggio in attivo basterebbe o rendere 
compatibile il salvataggio oppure semplicemente concedere il poter 
giocare alla versione che si stava giocando... non mi sembra un gran 
problema.
Per il salvataggio due idee mi son venute.
Consentire di lasciare i salvataggi anche sul server (quanto occuperanno 
poi?) e sfruttarli da li oppure inventare uno modo per inviarli in email 
e reinviarli ad un indirizzo per riprendere il gioco da dove lo si era 
lasciato. Entrambi sono portabili.
Un altra cosa sarebbe bello ovviamente concedere sia il gioco off-line 
che on line a scelta.
Ciauz.


....esatto si può fare
Ad ogni modo al momento sono orientato su una soluzione php/ajax con
parser limitato (azioni standard ed un campo di testo per inserire
l'azione, nessuna grammatica)...


Per quanto mi riguarda l'ostacolo più grande è proprio quello del
gioco offline, certo con flash si risolverebbe un po tutto ma non ho
voglia di rimettermi a studiare actionscript :) (anche se....)

 supportato in maniera differente dai vari browser).
il problema dell'incompatibilità è lo stesso che incontra con lo 
sviluppo di ogni pagina web. per quanto riguarda il codice:
1. se sbirci levi divertimento a te stesso
2. come dicevo prima, il codice è offuscabile.

 "esportare" dei dati sul tuo pc
Da javascript crei una nuova pagina, il cui sorgente contiene i dati da 
salvare (hidden) e la mostri in una finestra che chiede al giocatore di 
fare "Salva con nome".
Il browser salva il sorgente di questa pagina, che contiene appunto i 
dati del gioco.
Viceversa per ricaricare (e' un pelino meno ovvio, ma fattibile).
Non l'ho provato per intero, ma dovrebbe funzionare.
   .Erix.

Enrico Colombini ha scritto:

la mia idea era quella di una stringa crittata e compressa i dati che 
servono (quelli da salvare) da mostrare al giocatore che la copia 
(magari la salva in un documento txt) e poi incolla in un'apposito campo 
per caricare. non è molto funzionale e la tua idea mi pare migliore. il 
problema è che entrambi sono scomodi per salvataggi e caricamentu rapidi 
(per esempio durante il corso di un'avventura).
io ho il sospetto che in 4k di cookies si possa mettere molta più roba 
di quello che uno può sospettare..

 di quello che uno puň sospettare..
Ma anche molta meno, dato che parecchi caratteri non sono ammessi e 
vanno sostituiti da sequenze di escape. Alla fine e' probabilmente la 
stessa che uno potrebbe sospettare :-)
Scherzi a parte, hai ragione: con un po' di compressione (es. salvare 
indici in hex invece che stringhe e bit field invece che interi) ci si 
puo' far stare un po' di roba. Dopotutto i save file di Avventura nel 
castello erano da 1 kB circa, e non erano compressi.
   .Erix.

 2. come dicevo prima, il codice è offuscabile.
Tieni ben presente che quando si crea una pagina web javascript si
tende ad usarlo il meno possibile.... mentre in un progetto del genere
javascript dovrebbe farlo da padrone.

 javascript dovrebbe farlo da padrone.
1. se per "si tende" intendi "io tendo", mi sta bene, ma se lo 
generalizzi mi pare un'enorme stupidaggine che non so dove hai 
letto/sentito! specie ora che la tecnologia ajax si sta diffondendo. 
prova a sbirciare il codice, non so, di gmail. ci sono il 2% di righe di 
html e il 98% di righe di javascript. persino in applicazioni non 
dinamiche e non basate su ajax la percentual di codice javascript è 
altissima, sbircia l'homepage di ebay o quella di yahoo (anche qui il 
javascript è ben oltre il 50% del codice totale!) e sto citando siti 
grandi e famosi, ma è così ovunque, almeno che tu non vada a vedere le 
pagine statiche di geocities fatte dai tredicenni tipo "io e il mio 
criceto marty"
2. bah.. detto questo, che senso ha suggerire di limitare l'uso del 
javascript (??) a uno che sta programmando un sistema per IF in javascript?

 javascript (??) a uno che sta programmando un sistema per IF in javascript?
Nessuna !
Io ho fatto una considerazione sulla base delle mie idee, si stava
discutendo no?

 discutendo no?
a giorni spero di riuscire a postare una preview del sistema a cui sto 
lavorando.

 lavorando.
buon per te.

[snip spocchia]
oops, non č rimasto nulla da commentare.
ciao, buona giornata!

Sono certo che avete anche considerato il fatto che il problema non e'
la mancanza di tools di authoring, ma gli autori ed i giochi, vero? :)
Rob
P.S. Saint, perche' tra un js e l'altro non mi mandi la traduzione di
quel file di hugo che ti eri impegnato a fare? :)


ah ero convinto che l'avessi già completato te.
ok, te lo spedisco al più presto.

 ok, te lo spedisco al più presto.
Lascia stare, avevo il pomeriggio semilibero e l'ho fatto io.
Rob


...lol
(non mi smentisco mai)