I D R A
Ipertesto Dinamico per Racconti d'Avventura

Manuale dell'autore
rev 1.0, © 2000 Enrico Colombini

 

qui puoi scaricare IDRA con il manuale

qui puoi visitare il sito ufficiale dell'autore Enrico Colombini con esempi e giochi scaricabili


Come funziona Idra

Appendice B

1

L'idea di Idra

5

Lo stato precedente

2

Perché JavaScript?

6

Il debugger

3

Struttura di Idra

7

Possibili migliorie

4

Salvataggio e ripristino

 

 

 

Perché JavaScript?

Anche se col solo HTML delle pagine Web sarebbe possibile scrivere una primitiva forma di racconto a scelte, si tratterebbe comunque di un'opera poco flessibile, essendo basata su scelte fisse; per fare qualcosa di più occorre fare ricorso a un linguaggio di programamzione.

L'esperienza dei miei giochi di avventura scritti negli anni '80, strettamente legati al linguaggio Basic nella versione Microsoft, mi ha insegnato a diffidare degli strumenti prodotti da una sola azienda. Per Idra volevo garantire la massima portabilità su diversi sistemi, l'indipendenza da strumenti di un dato produttore e, possibilmente, una ragionevole durata nel tempo.

Linguaggi dinamici come il Perl o il Tcl/Tk sono molto interessanti per questo genere di applicazioni, ma richiedono che il lettore abbia installato il relativo interprete; è inoltre difficile garantirne il corretto funzionamento con diverse versioni e diversi sistemi operativi.

Java ha il vantaggio della disponibilità di un interprete nei principali browser, ma trovo il linguaggio alquanto pesante e burocratico sia per il programmatore (cioè io) che, soprattutto, per l'autore dei racconti. Inoltre, cosa importante, Java non è dinamico: codice e dati sono rigidamente separati; ciò significa che l'autore sarebbe obbligato a compilare il programma a ogni modifica del comportamento del gioco.

Certo, con un po' di lavoro (non poco) si potrebbe definire in Java un completo linguaggio su misura che l'autore possa usare senza bisogno di ricompilazione. A questo punto, però, tanto varrebbe farlo in C per poter distribuire direttamente un programma eseguibile, almeno nelle versioni per i più diffusi sistemi operativi, coè Windows e Linux. Ciò eliminerebbe indubbiamente molti problemi.

Nell'estate del 1999 definii quindi a grandi linee un linguaggio dinamico e iniziai a scrivere le librerie C che ne avrebbero formato i mattoni portanti. Mi fermai quando lessi le specifiche di JavaScript e mi resi conto che era quasi identico a ciò che avevo in mente (almeno nella struttura di base). Inoltre esisteva uno standard indipendente (ECMA-262).

JavaScript richiede un interprete, ma esso è contenuto nei principali browser: avevo quindi quasi gratis un linguaggio dinamico e i vantaggi di HTML. C'era però un prezzo da pagare: l'impossibilità di accedere ai file e l'obbligo di usare i cookie per salvare la situazione di gioco. Decisi di accettare questi limiti e riprogettai di conseguenza l'intero sistema, scegliendo una versione stabile di JavaScript (la 1.1) per avere la massima compatibilità.