L'articolo qui presentato fa parte dell'Archivio Storico di Quattro Bit ed è tratto dalla rivista Bit n. 38 (aprile 1983) pp. 132-136, fonte: Retroedicola
[Questo articolo, oltre a presentare una descrizione delle tecniche di programmazione utilizzate dalla versione Apple II di Avventura nel castello, offre una panoramica generale sulle categorie videoludiche presenti nel 1983, differenziando i giochi arcade da quelli di strategia. Per quanto riguarda la storia di Avventura nel Castello, si veda il sito dell'autore Enrico Colombini.]
Avventura nel castello:
a cura della Redazione
Un po' per problemi commerciali, un po' forse per disdegno nei confronti di un così "vile" argomento, il settore dei giochi da personal computer è di quasi totale appannaggio dei soliti americani, con qualche timida puntata giapponese. Suscita quindi un certo interesse la notizia della commercializzazione di un gioco italiano per Apple: appunto "Avventura nel castello". Per quanto ne sappiamo, si tratta del primo "adventure game" di concezione originale italiana.
Apriamo una parentesi per dare un'occhiata al settore dei "computer game" e alle sue attuali linee di evoluzione. Possiamo, grosso modo (i sofisti mi perdoneranno l'approssimazione), suddividerlo in tree aree ben distinte.
Al primo posto nei cataloghi (e nelle vendite) stanno i soliti "arcade game", in pratica i videogiochi riportati sul personal computer. Le varianti sono innumerevoli, dall'ennesimo "invader" alla corsa automobilistica, ma sempre con due regole costanti:
1) Strategia e astuzia sono bandite o quasi: contano solo l'occhio e i riflessi.
2) Si gioca da soli.
Indubbiamente alcuni di questi sono ben riusciti e divertenti da giocare (un esempio per tutti: Threshold della On-Line), ma l'insieme appare scialbo e ripetitivo (quante versioni di Pac-Man ci sono in giro?). Spazio per fantasia e innovazione ce n'è dunque in abbondanza.
Tuttavia, come accade per certi "serial" televisivi, gli "arcade game" non possono uscire dalla loro struttura base e sono pur sempre i lontani discendenti del compianto flipper: simpatici aggeggi per rilassarsi una mezz'ora (o più...) senza pensare.
C'è stato anche qualche tentativo di realizzare giochi "tipo arcade" per più persone, ma questi tentativi sono pochissimi e per lo più mal realizzati. Tralasciamo (a malincuore) questo argomento perché ci porterebbe troppo lontano dal discorso che oggi ci interessa.
Ovviamente sono stati riportati sul computer tutti i più noti giochi di strategia, dal domino agli scacchi. Ben pochi sono stati invece i tentativi di realizzare qualcosa di originale sfruttando le opportunità offerte dal nuovo strumento. Anche in questo caso il copione è "tu solo contro il computer", ma si può facilmente variarlo in "noi tutti contro il computer" (e riusciremo a vincerne una, prima o poi, contro quella stupida macchina).
Il campo dei giochi di strategia è un ottimo terreno di coltura per lo sviluppo delle tecniche di intelligenza artificiale. Dal punto di vista del giocatore rimane, forse, un po' troppo arido, soprattutto per la mancanza delle emozioni che sempre accompagnano il gioco tra "umani".
A questo punto vi aspettate: ed ecco finalmente il Gioco perfetto, che unisce tutte le migliori qualità, che sfrutta le nuove possibilità offerte dal calcolatore ecc. ecc. Bene, non ve lo dico. Non ve lo dico perché questo genere non esiste e, per quanto ne so, ben pochi sforzi si fanno fuori dai soliti binari, soprattutto negli USA, dove la tecnica eccellente è spesso compensata da una incredibile carenza di fantasia.
Esiste però un terzo genere di giochi, che è nato con il computer e difficilmente potrebbe esistere senza: gli "adventure game" (giochi di avventura). Sono lontani cugini dei giochi di strategia, con i quali hanno in comune la necessità di risolvere problemi. Hanno però qualcosa di originale: l'emozione della scoperta e la sfida dell'imprevisto.
Le origini degli "adventure" si perdono nella leggenda: pare che in un lontano passato (alcuni anni fa) due programmatori si siano divertiti a scrivere in FORTRAN su un DEC PDP-10 una dimostrazione della possibilità, per un calcolatore, di "capire" semplici frasi e agire di conseguenza.
Le frasi erano del tipo GO NORTH (vai a nord), TAKE CHEST (prendi il forziere) e via dicendo; lo scenario era la Colossal Cave, un'immensa caverna sotterranea colma di tesori, di pericoli e di problemi da risolvere. Il programma si chiamava (guarda caso) "Adventure".
Il programma ebbe una tale notorietà tra gli addetti ai lavori da essere presto trasportato su praticamente tutti i computer, grandi e piccoli. Ogni personal oggi ha la sua versione dell'originale "Adventure", ridotta, integrale o addirittura ampliata. Apple ne vanta ben due, praticamente identiche!
Visto il successo dell'originale, negli ultimi anni sono stati scritti tanti "adventure" da portare il genere al secondo posto nelle classifiche, dopo gli "arcade". A loro volta gli "adventure" si sono suddivisi in due filoni:
1) Parlati: diretti discendenti dell'Adventure originale, in questi giochi il computer descrive in dettaglio ogni nuovo ambiente in cui si mette piede, lasciano ricreare la scena alla fantasia del giocatore-avventuriero. Esempio classico: Apple Adventure (versione Apple del primo originale).
2) Grafici: gli ambienti non vengono descritti ma illustrati, meglio se in alta risoluzione e a colori, con un brevissimo commento parlato (sempre nel senso di scritto). Esempi: il classico Mystery House e il gigantesco Time Zone (12 dischi!). Alcuni dei giochi più recenti hanno anche un minimo di animazione.
Si potrebbe pensare che gli adventure grafici abbiano messo definitivamente fuori causa quelli parlati, ma questo non è ancora avvenuto. Come qualcuno ha osservato, l'adventure grafico sta a quello parlato come il fumetto sta al racconto: un disegno è spesso meno "vero" e "reale" dell'immagine fantastica suscitata da un'abile descrizione. Inoltre la necessità di risparmiare tempo e spazio nei grafici porta in molti casi a disegni assai poco rifiniti e poveri di particolari.
A questo va aggiunto che le trame delle avventure, specialmente quelle grafiche dove l'attenzione si concentra sui disegni, sono quasi sempre inconsistenti. In genere le azioni principali sono "prendi" e "ammazza", con poca fantasia e ancor meno humour.
Da noi gli adventure americani hanno ben poca diffusione, soprattutto per la necessità di conoscere discretamente l'inglese o meglio l'americano: giocare con il vocabolario traducendo ogni parola è piuttosto noioso.
Qualcuno ha tentato delle traduzioni in italiano, con risultati sconsolanti: occorre pensare in inglese e poi tradurre in italiano. (un esempio: "fai la doccia" diventa "prendi la doccia", dato che in inglese si dice "take shower").
Per giocare gli adventure americani ci sono dunque due alternative: aspettare traduzioni fatte sui "sorgenti" dei programmi (e qualcuno, ci dicono, sta lavorando in questo senso) o imparare l'inglese. Non scherzo: gli adventure sono un ottimo mezzo per imparare l'inglese: chi scrive ha imparato più con questo sistema che con tutti gli altri. Era comunque ora che qualcuno si decidesse a scrivere un adventure, anzi un'avventura originale in italiano.
Hanno affrontato l'avventura (alla lettera) una coppia di bresciani, professionisti dell'elettronica industriale e inveterati giocatori di "adventure". Ne è uscito un prodotto di ottima fattura e molto divertente, specialmente se giocato con un gruppo di amici.
La trama è questa: l'aereo precipita, l'avventuriero si salva a stento in un antico castello diroccato, dove... Ma rimandiamo a Personal Software per la prova completa del gioco (non illudetevi di trovare anche le soluzioni.)
Qui su Bit vogliamo invece analizzare la struttura del programma e le tecniche usate per la realizzazione su Apple II, grazie anche alle informazioni forniteci dagli autori.
In linea teorica, sarebbe possibile scrivere un adventure come programma sequenziale, del tipo:
IF A$="APRI LA PORTA" AND LUOGO=13 AND CHIAVE=1 THEN...
Naturalmente si otterrebbe un programma talmente enorme da superare la capacità di qualunque personal, per non dire dell'impossibilità di scriverlo fisicamente e provarlo a fondo. Occorre un approccio più strutturato al problema; è meglio prescindere dalla specifica avventura e realizzare una "base" universale in cui introdurre trama, mappe, oggetti e problemi dell'avventura che si vuole scrivere. Tra l'altro la base è riutilizzabile senza sforzo per ulteriori avventure.
Conviene creare quella che si dice una "macchina a stati": ogni situazione di gioco è uno "stato" tra i molti possibili, identificato dal luogo dove ci si trova, gli oggetti posseduti, le azioni effettuate, ecc.
Un'azione può non avere alcun effetto sullo stato (soltanto un messaggio di risposta) o causare un cambiamento di stato (es. NORD può cambiare luogo). La macchina passa dunque in un nuovo stato dove sono possibili altre azioni, che a loro volta possono determinare altri cambiamenti di stato.
Questo approccio, a prima vista complicato, consente invece, come vedremo, di semplificare notevolmente il problema.
La macchina a stati si può realizzare con una struttura organizzata a tavole. Descriviamo una struttura di questo tipo con un esempio, riferendoci al diagramma di flusso di figura 1, che rappresenta in forma molto semplificata il ciclo principale del programma.
Per prima cosa, il programma stampa una descrizione del luogo dove ci si trova, usando la variabile LUOGO come indice nella tavola delle descrizioni di tutti i luoghi.
Poi aspetta la frase del giocatore, che analizza consultando le tavole delle parole (verbi, nomi, articoli, ecc.) per vedere se è composta da parole valide. In caso negativo stampa un messaggio di default e torna all'inizio.
Se le parole sono valide, consulta la tavola delle azioni valide in quel particolare luogo (a ogni luogo è associata una tavola di frasi) per vedere se l'azione è prevista in quel luogo. Se la trova esegue l'azione (vedremo poi come) e torna all'inizio.
Altrimenti, consulta la tavola delle azioni valide dovunque (tavola unica per tutto il gioco) e, se la ricerca ha successo, esegue l'azione. Notare che la stessa azione può avere un effetto diverso in un certo luogo, nel qual caso sarebbe stata intercettata dal test precedente.
Infine, consulta la tavola delle direzioni ammesse nel luogo (che costituisce la mappa). Se coincide, cambia la variabile LUOGO di conseguenza, se no dà un messaggio di default.
In questo esempio mancano per semplicità gli oggetti, ma è facilmente intuibile come la struttura può essere estesa per comprenderli (tavola del luogo di ciascun oggetto, tavola degli oggetti posseduti, ecc.).
Abbiamo tralasciato di vedere cosa succede se una frase è riconosciuta valida e dev'essere eseguita l'azione corrispondente. Questa può consistere nella semplice stampa di un messaggio, oppure può implicare un cambiamento di stato; in quest'ultimo caso l'azione consisterà nel modificare la relativa variabile (es. porta aperta).
Il problema della velocità è fondamentale: se bisogna aspettare qualche secondo per avere la risposta, il gioco diventa noioso.
Per avere risposte veloci, si pensa subito a tenere tutto in memoria. Ma questo limiterebbe fortemente le dimensioni del gioco: e allora?
Avventura nel castello ha un tempo di risposta brevissimo, grazie a un sistema ibrido: mappa, tavole e indici vari sono permanentemente in memoria, mentre il disco contiene le descrizioni complete degli ambienti (che vengono date la prima volta) e i numerosi messaggi di risposta.
In memoria sono anche le routine di "azione" che vengono chiamate, come abbiamo visto, quando il giocatore esegue un'azione valida. I programmatori americani tendono a strutturare a tavole anche queste, costringendo però in tal modo le possibilità delle routine entro schemi fissi.
I messaggi sono registrati con la tecnica del file sequenziale indicizzato. È un sistema che offre accesso velocissimo e massima flessibilità e di cui avremo modo di parlare in un prossimo articolo.
Avventura nel castello è scritto in Applesoft... o quasi.
Se infatti l'Applesoft rimane il linguaggio di gran lunga più pratico per programmare Apple II a livello professionale, il suo limite maggiore è la bassa velocità di esecuzione. E la velocità, come abbiamo visto, è un fattore essenziale per ogni gioco.
Il programma originale, in Applesoft puro e semplice, impiegava ben otto secondi per rispondere, con pause molto più lunghe per la routine di garbage collect!
I fattori limitanti, in ordine di importanza, erano:
1) la routine di garbage collect;
2) il tempo di ricerca di GOTO e GOSUB;
3) il tempo di accesso alle variabili;
4) l'esecuzione delle istruzioni.
Una compilazione con il TASC della Microsoft avrebbe risolto tre dei problemi, lasciando inalterato il primo, il più fastidioso. Anche il TASC, infatti, impiega molto tempo a riordinare le stringhe.
Purtroppo, il TASC usa una diversa organizzazione delle variabili stringa, rendendo inutili le ruotine di riordino veloce, come SPEEDFRE, descritta in un recente articolo su su Bit n. 37.
Restava una sola, drastica soluzione: abolire le stringhe, o comunque ridurne il numero da qualche centinaio a qualche decina. Facile a dirsi. Occorreva scrivere una gestione in linguaggio macchina degli array stringa, alternativa a quella Applesoft. Ed è proprio quello che hanno fatto gli autori di Avventura nel castello.
In Italia molti utenti (e venditori) hanno la pessima abitudine di far circolare copie illegali dei programmi, contribuendo a scoraggiare i già pochi autori in circolazione. I venditori di software che vogliono guadagnare il 250% hanno le loro responsabilità in questa situazione, ma questo consola ben poco chi del software vuol fare il proprio lavoro.
Avventura nel castello usa una tecnica molto efficace per scoraggiare questo genere di cose; ogni tanto, a caso e comunque dopo un po' di tempo, controlla la consistenza di alcune informazioni critiche incise sul dischetto in modo non riproducibile dai vari Locksmith & simili.
Se il disco è copiato, cancella l'intera memoria. Il comportamento random rende molto lento e difficile neutralizzare la protezione, in quanto occorre molto tempo per stabilire se una copia funziona o no.
Riteniamo comunque che il prezzo di vendita, decisamente basso per un prodotto di questo livello, sia un argomento notevole a favore della confezione originale.
Programma: compilato, 24 Kbyte
Tavole e indici: 4 Kbyte
Dizionario: (tavole delle parole): 6 Kbyte (routine ausiliarie): 600 byte
Dati su disco: 26 Kbyte
Sorgenti: 28 file, per complessivi 135 Kbyte
[Questo articolo, oltre a presentare una descrizione delle tecniche di programmazione utilizzate dalla versione Apple II di Avventura nel castello, offre una panoramica generale sulle categorie videoludiche presenti nel 1983, differenziando i giochi arcade da quelli di strategia. Per quanto riguarda la storia di Avventura nel Castello, si veda il sito dell'autore Enrico Colombini.]
Avventura nel castello:
un nuovo gioco italiano per Apple II
a cura della Redazione
Un po' per problemi commerciali, un po' forse per disdegno nei confronti di un così "vile" argomento, il settore dei giochi da personal computer è di quasi totale appannaggio dei soliti americani, con qualche timida puntata giapponese. Suscita quindi un certo interesse la notizia della commercializzazione di un gioco italiano per Apple: appunto "Avventura nel castello". Per quanto ne sappiamo, si tratta del primo "adventure game" di concezione originale italiana.
Apriamo una parentesi per dare un'occhiata al settore dei "computer game" e alle sue attuali linee di evoluzione. Possiamo, grosso modo (i sofisti mi perdoneranno l'approssimazione), suddividerlo in tree aree ben distinte.
Gli "arcade game"
Al primo posto nei cataloghi (e nelle vendite) stanno i soliti "arcade game", in pratica i videogiochi riportati sul personal computer. Le varianti sono innumerevoli, dall'ennesimo "invader" alla corsa automobilistica, ma sempre con due regole costanti:
1) Strategia e astuzia sono bandite o quasi: contano solo l'occhio e i riflessi.
2) Si gioca da soli.
Tuttavia, come accade per certi "serial" televisivi, gli "arcade game" non possono uscire dalla loro struttura base e sono pur sempre i lontani discendenti del compianto flipper: simpatici aggeggi per rilassarsi una mezz'ora (o più...) senza pensare.
C'è stato anche qualche tentativo di realizzare giochi "tipo arcade" per più persone, ma questi tentativi sono pochissimi e per lo più mal realizzati. Tralasciamo (a malincuore) questo argomento perché ci porterebbe troppo lontano dal discorso che oggi ci interessa.
I giochi di strategia
Ovviamente sono stati riportati sul computer tutti i più noti giochi di strategia, dal domino agli scacchi. Ben pochi sono stati invece i tentativi di realizzare qualcosa di originale sfruttando le opportunità offerte dal nuovo strumento. Anche in questo caso il copione è "tu solo contro il computer", ma si può facilmente variarlo in "noi tutti contro il computer" (e riusciremo a vincerne una, prima o poi, contro quella stupida macchina).
Il campo dei giochi di strategia è un ottimo terreno di coltura per lo sviluppo delle tecniche di intelligenza artificiale. Dal punto di vista del giocatore rimane, forse, un po' troppo arido, soprattutto per la mancanza delle emozioni che sempre accompagnano il gioco tra "umani".
Gli "adventure game"
A questo punto vi aspettate: ed ecco finalmente il Gioco perfetto, che unisce tutte le migliori qualità, che sfrutta le nuove possibilità offerte dal calcolatore ecc. ecc. Bene, non ve lo dico. Non ve lo dico perché questo genere non esiste e, per quanto ne so, ben pochi sforzi si fanno fuori dai soliti binari, soprattutto negli USA, dove la tecnica eccellente è spesso compensata da una incredibile carenza di fantasia.
Esiste però un terzo genere di giochi, che è nato con il computer e difficilmente potrebbe esistere senza: gli "adventure game" (giochi di avventura). Sono lontani cugini dei giochi di strategia, con i quali hanno in comune la necessità di risolvere problemi. Hanno però qualcosa di originale: l'emozione della scoperta e la sfida dell'imprevisto.
Le origini degli "adventure" si perdono nella leggenda: pare che in un lontano passato (alcuni anni fa) due programmatori si siano divertiti a scrivere in FORTRAN su un DEC PDP-10 una dimostrazione della possibilità, per un calcolatore, di "capire" semplici frasi e agire di conseguenza.
Le frasi erano del tipo GO NORTH (vai a nord), TAKE CHEST (prendi il forziere) e via dicendo; lo scenario era la Colossal Cave, un'immensa caverna sotterranea colma di tesori, di pericoli e di problemi da risolvere. Il programma si chiamava (guarda caso) "Adventure".
Il programma ebbe una tale notorietà tra gli addetti ai lavori da essere presto trasportato su praticamente tutti i computer, grandi e piccoli. Ogni personal oggi ha la sua versione dell'originale "Adventure", ridotta, integrale o addirittura ampliata. Apple ne vanta ben due, praticamente identiche!
Gli "adventure", oggi
 |
| Dopo il prologo, comincia l'avventura! |
Visto il successo dell'originale, negli ultimi anni sono stati scritti tanti "adventure" da portare il genere al secondo posto nelle classifiche, dopo gli "arcade". A loro volta gli "adventure" si sono suddivisi in due filoni:
1) Parlati: diretti discendenti dell'Adventure originale, in questi giochi il computer descrive in dettaglio ogni nuovo ambiente in cui si mette piede, lasciano ricreare la scena alla fantasia del giocatore-avventuriero. Esempio classico: Apple Adventure (versione Apple del primo originale).
2) Grafici: gli ambienti non vengono descritti ma illustrati, meglio se in alta risoluzione e a colori, con un brevissimo commento parlato (sempre nel senso di scritto). Esempi: il classico Mystery House e il gigantesco Time Zone (12 dischi!). Alcuni dei giochi più recenti hanno anche un minimo di animazione.
Parlato o grafico?
 |
| Esempio di descrizione completo, descrizione sintetica e tentativo di movimento |
Si potrebbe pensare che gli adventure grafici abbiano messo definitivamente fuori causa quelli parlati, ma questo non è ancora avvenuto. Come qualcuno ha osservato, l'adventure grafico sta a quello parlato come il fumetto sta al racconto: un disegno è spesso meno "vero" e "reale" dell'immagine fantastica suscitata da un'abile descrizione. Inoltre la necessità di risparmiare tempo e spazio nei grafici porta in molti casi a disegni assai poco rifiniti e poveri di particolari.
A questo va aggiunto che le trame delle avventure, specialmente quelle grafiche dove l'attenzione si concentra sui disegni, sono quasi sempre inconsistenti. In genere le azioni principali sono "prendi" e "ammazza", con poca fantasia e ancor meno humour.
E in Italia?
 |
| Il programma "capisce" e cerca di eseguire il comando |
Da noi gli adventure americani hanno ben poca diffusione, soprattutto per la necessità di conoscere discretamente l'inglese o meglio l'americano: giocare con il vocabolario traducendo ogni parola è piuttosto noioso.
Qualcuno ha tentato delle traduzioni in italiano, con risultati sconsolanti: occorre pensare in inglese e poi tradurre in italiano. (un esempio: "fai la doccia" diventa "prendi la doccia", dato che in inglese si dice "take shower").
Per giocare gli adventure americani ci sono dunque due alternative: aspettare traduzioni fatte sui "sorgenti" dei programmi (e qualcuno, ci dicono, sta lavorando in questo senso) o imparare l'inglese. Non scherzo: gli adventure sono un ottimo mezzo per imparare l'inglese: chi scrive ha imparato più con questo sistema che con tutti gli altri. Era comunque ora che qualcuno si decidesse a scrivere un adventure, anzi un'avventura originale in italiano.
Avventura nel castello
 |
| Una particolareggiata descrizione di ambiente |
Hanno affrontato l'avventura (alla lettera) una coppia di bresciani, professionisti dell'elettronica industriale e inveterati giocatori di "adventure". Ne è uscito un prodotto di ottima fattura e molto divertente, specialmente se giocato con un gruppo di amici.
La trama è questa: l'aereo precipita, l'avventuriero si salva a stento in un antico castello diroccato, dove... Ma rimandiamo a Personal Software per la prova completa del gioco (non illudetevi di trovare anche le soluzioni.)
Qui su Bit vogliamo invece analizzare la struttura del programma e le tecniche usate per la realizzazione su Apple II, grazie anche alle informazioni forniteci dagli autori.
Una macchina a stati
 |
| Un altro ambiente interessante |
In linea teorica, sarebbe possibile scrivere un adventure come programma sequenziale, del tipo:
IF A$="APRI LA PORTA" AND LUOGO=13 AND CHIAVE=1 THEN...
Naturalmente si otterrebbe un programma talmente enorme da superare la capacità di qualunque personal, per non dire dell'impossibilità di scriverlo fisicamente e provarlo a fondo. Occorre un approccio più strutturato al problema; è meglio prescindere dalla specifica avventura e realizzare una "base" universale in cui introdurre trama, mappe, oggetti e problemi dell'avventura che si vuole scrivere. Tra l'altro la base è riutilizzabile senza sforzo per ulteriori avventure.
Conviene creare quella che si dice una "macchina a stati": ogni situazione di gioco è uno "stato" tra i molti possibili, identificato dal luogo dove ci si trova, gli oggetti posseduti, le azioni effettuate, ecc.
Un'azione può non avere alcun effetto sullo stato (soltanto un messaggio di risposta) o causare un cambiamento di stato (es. NORD può cambiare luogo). La macchina passa dunque in un nuovo stato dove sono possibili altre azioni, che a loro volta possono determinare altri cambiamenti di stato.
Questo approccio, a prima vista complicato, consente invece, come vedremo, di semplificare notevolmente il problema.
La struttura a tavole
 |
| Figura 1 - Struttura del ciclo principale del programma (molto semplificata) |
La macchina a stati si può realizzare con una struttura organizzata a tavole. Descriviamo una struttura di questo tipo con un esempio, riferendoci al diagramma di flusso di figura 1, che rappresenta in forma molto semplificata il ciclo principale del programma.
Per prima cosa, il programma stampa una descrizione del luogo dove ci si trova, usando la variabile LUOGO come indice nella tavola delle descrizioni di tutti i luoghi.
Poi aspetta la frase del giocatore, che analizza consultando le tavole delle parole (verbi, nomi, articoli, ecc.) per vedere se è composta da parole valide. In caso negativo stampa un messaggio di default e torna all'inizio.
Se le parole sono valide, consulta la tavola delle azioni valide in quel particolare luogo (a ogni luogo è associata una tavola di frasi) per vedere se l'azione è prevista in quel luogo. Se la trova esegue l'azione (vedremo poi come) e torna all'inizio.
Altrimenti, consulta la tavola delle azioni valide dovunque (tavola unica per tutto il gioco) e, se la ricerca ha successo, esegue l'azione. Notare che la stessa azione può avere un effetto diverso in un certo luogo, nel qual caso sarebbe stata intercettata dal test precedente.
Infine, consulta la tavola delle direzioni ammesse nel luogo (che costituisce la mappa). Se coincide, cambia la variabile LUOGO di conseguenza, se no dà un messaggio di default.
In questo esempio mancano per semplicità gli oggetti, ma è facilmente intuibile come la struttura può essere estesa per comprenderli (tavola del luogo di ciascun oggetto, tavola degli oggetti posseduti, ecc.).
Abbiamo tralasciato di vedere cosa succede se una frase è riconosciuta valida e dev'essere eseguita l'azione corrispondente. Questa può consistere nella semplice stampa di un messaggio, oppure può implicare un cambiamento di stato; in quest'ultimo caso l'azione consisterà nel modificare la relativa variabile (es. porta aperta).
Memoria, disco e velocità
Il problema della velocità è fondamentale: se bisogna aspettare qualche secondo per avere la risposta, il gioco diventa noioso.
Per avere risposte veloci, si pensa subito a tenere tutto in memoria. Ma questo limiterebbe fortemente le dimensioni del gioco: e allora?
Avventura nel castello ha un tempo di risposta brevissimo, grazie a un sistema ibrido: mappa, tavole e indici vari sono permanentemente in memoria, mentre il disco contiene le descrizioni complete degli ambienti (che vengono date la prima volta) e i numerosi messaggi di risposta.
In memoria sono anche le routine di "azione" che vengono chiamate, come abbiamo visto, quando il giocatore esegue un'azione valida. I programmatori americani tendono a strutturare a tavole anche queste, costringendo però in tal modo le possibilità delle routine entro schemi fissi.
I messaggi sono registrati con la tecnica del file sequenziale indicizzato. È un sistema che offre accesso velocissimo e massima flessibilità e di cui avremo modo di parlare in un prossimo articolo.
Tecniche e trucchi
Avventura nel castello è scritto in Applesoft... o quasi.
Se infatti l'Applesoft rimane il linguaggio di gran lunga più pratico per programmare Apple II a livello professionale, il suo limite maggiore è la bassa velocità di esecuzione. E la velocità, come abbiamo visto, è un fattore essenziale per ogni gioco.
Il programma originale, in Applesoft puro e semplice, impiegava ben otto secondi per rispondere, con pause molto più lunghe per la routine di garbage collect!
I fattori limitanti, in ordine di importanza, erano:
1) la routine di garbage collect;
2) il tempo di ricerca di GOTO e GOSUB;
3) il tempo di accesso alle variabili;
4) l'esecuzione delle istruzioni.
Una compilazione con il TASC della Microsoft avrebbe risolto tre dei problemi, lasciando inalterato il primo, il più fastidioso. Anche il TASC, infatti, impiega molto tempo a riordinare le stringhe.
Purtroppo, il TASC usa una diversa organizzazione delle variabili stringa, rendendo inutili le ruotine di riordino veloce, come SPEEDFRE, descritta in un recente articolo su su Bit n. 37.
Restava una sola, drastica soluzione: abolire le stringhe, o comunque ridurne il numero da qualche centinaio a qualche decina. Facile a dirsi. Occorreva scrivere una gestione in linguaggio macchina degli array stringa, alternativa a quella Applesoft. Ed è proprio quello che hanno fatto gli autori di Avventura nel castello.
Protezione e prezzo
In Italia molti utenti (e venditori) hanno la pessima abitudine di far circolare copie illegali dei programmi, contribuendo a scoraggiare i già pochi autori in circolazione. I venditori di software che vogliono guadagnare il 250% hanno le loro responsabilità in questa situazione, ma questo consola ben poco chi del software vuol fare il proprio lavoro.
Avventura nel castello usa una tecnica molto efficace per scoraggiare questo genere di cose; ogni tanto, a caso e comunque dopo un po' di tempo, controlla la consistenza di alcune informazioni critiche incise sul dischetto in modo non riproducibile dai vari Locksmith & simili.
Se il disco è copiato, cancella l'intera memoria. Il comportamento random rende molto lento e difficile neutralizzare la protezione, in quanto occorre molto tempo per stabilire se una copia funziona o no.
Riteniamo comunque che il prezzo di vendita, decisamente basso per un prodotto di questo livello, sia un argomento notevole a favore della confezione originale.
QUALCHE DATO
Programma: compilato, 24 Kbyte
Tavole e indici: 4 Kbyte
Dizionario: (tavole delle parole): 6 Kbyte (routine ausiliarie): 600 byte
Dati su disco: 26 Kbyte
Sorgenti: 28 file, per complessivi 135 Kbyte
Commenti
Posta un commento