Camel Trophy Videogame vent'anni dopo:

Arriva lo storyboard

Terminate tutte le formalità burocratiche, firmati tutti i contratti, la consegna dello storyboard agli inizi di giugno 1985 suggellò l'avvio ufficiale del progetto. Insieme con Eugenio e Bruno mi sarei occupato della programmazione del gioco, mentre Gianluca Magnani - un lettore di Run particolarmente versato nelle schermate grafiche che aveva già iniziato una collaborazione a distanza con la rivista - si sarebbe occupato degli splash screen del gioco, e Simone Majocchi avrebbe coordinato la produzione. Nel frattempo il consueto lavoro redazionale dedicato a Run sarebbe stato parzialmente ridotto grazie all'uscita di un numero doppio, il 10-11, mentre si sarebbe parallelamente aumentato ricorso a una schiera di collaboratori esterni che di mese in mese si faceva più ampia e capace. Un ulteriore contributo sarebbe giunto dalle vere e proprie chicche meritevoli di pubblicazione che iniziavamo a trovare tra le decine di lavori che i lettori spedivano ogni mese alla redazione. Il numero 12 di Run avrebbe dovuto essere licenziato poco tempo dopo la prevista consegna del master del Camel Trophy Videogame, per cui anche questo appuntamento doveva essere pianificato con cura.

La sensazione scaturita dalla prima lettura dello storyboard definitivo fu un misto di ansia e di sollievo. Ansia, perché le situazioni contemplate dal gioco erano ben più varie del previsto, tanto che lo stesso progetto prevedeva la suddivisione del gioco in tre blocchi distinti, e questo avrebbe significato un maggior lavoro di implementazione tecnica in un tempo alquanto stringato; sollievo, perché dopo tante supposizioni potevamo finalmente iniziare a concentrare i nostri sforzi su obiettivi effettivi.

Eppur si muove

Già da due mesi, infatti, Eugenio ed io avevamo inaugurato le danze sul codice sperimentando le tecniche del cosiddetto spriter, ovvero quel modulo che nei videgiochi si incarica di muovere oggetti per lo schermo e rilevarne eventuali collisioni. La difficoltà di questo genere di routine dipende principalmente dal fatto che tutte le operazioni devono essere compiute durante il flyback del pennello video, ovvero quella risicatissima quantità di tempo in cui il cannone che illumina in sequenza i fosfori del televisore o del monitor CRT "stacca" per passare dall'angolo inferiore destro all'angolo superiore sinistro e iniziare così un nuovo ciclo di rinfresco dell'immagine. Nei sistemi standard PAL dei televisori europei questa operazione viene svolta dall'hardware per 50 volte al secondo e la sincronizzazione tra le routine software di stampa con il pennello video è essenziale per evitare fastidiosi effetti di sfarfallio dell'immagine o di scomposizione degli oggetti spostati sullo schermo.

Le caratteristiche richieste a uno spriter variano a seconda del tipo di gioco e della quantità di oggetti da muovere; anche se il nostro obiettivo era quello di riuscire a scrivere uno spriter più versatile possibile, che avrebbe avuto il pregio di essere utilizzabile qualunque fosse stato lo storyboard definitivo, ci rendemmo ben presto conto che l'alto grado di ottimizzazione necessario per restare nei tempi di sincronizzazione ci imponeva di rimandare lo studio di una soluzione ad hoc nel momento in cui gli aspetti tecnici del gioco sarebbero stati più chiari.

In ultima analisi, la questione dello spriter richiese l'impegno pressoché esclusiva di una persona: il fortunato prescelto fu Bruno Molteni, che trascorse buona parte dell'estate a studiare approfonditamente diverse opzioni e a curiosare all'interno di altri giochi commerciali per carpirne i segreti. Il codice che produsse fu comunque notevole: in soli 650 byte ci mise a disposizione un modulo assolutamente ottimizzato che poteva essere chiamato con grande semplicità, mentre i problemi della sincronizzazione hardware furono risolti ricorrendo a un cosiddetto display file secondario, o DF2. Anziché stampare gli oggetti nella memoria direttamente collegata al video (quella che nello ZX Spectrum iniziava dall'indirizzo 16384), lo spriter di Bruno effettuava infatti tutte le operazioni in un'area di memoria differente per poi copiarla integralmente nella memoria video 25 volte al secondo. Si tratta di una tecnica ormai considerata classica, e negli anni mi è capitato anche di lavorare su videogiochi che possedevano tre display file; ma allora si trattò di giungere autonomamente a una soluzione appropriata ripetendo anche nel nostro piccolo una sorta di "invenzione della ruota" che, almeno fino all'avvento dei modem e dei BBS e, con essi, dei forum di discussione specializzati e quindi della diffusione della conoscenza, rappresentava una specie di rito di passaggio per chiunque volesse programmare videogiochi.

Questo a me, questo a te...

Avendo accumulato una certa esperienza con programmi Basic di grandi dimensioni (i miei primi programmi "seri" li avevo scritti proprio in questo linguaggio su un calcolatore ITT 3030 basato su CP/M), fu deciso che mi sarei occupato di realizzare i primi due blocchi del gioco, dove il linguaggio macchina poteva limitarsi ad avere una funzione di supporto, mentre Eugenio si sarebbe dedicato alla parte di gestione generale del terzo blocco e Bruno dello spriter.

Il primo "intoppo", se così si può chiamare, fu nei dati che dovevamo utilizzare. Per il primo blocco ci era stata fornita una copia dei quiz usati per le selezioni italiane di una precedente edizione del Camel Trophy; nessuno però trovava più l'elenco ufficiale delle risposte corrette. Tra conoscenze personali, di amici fuoristradisti e di personale dello stesso staff organizzativo del Camel Trophy riuscimmo a venire a capo della questione, anche se tuttora conservo qualche dubbio su almeno un paio di casi. I risultati dell'esame di teoria iniziale del gioco dovevano essere utilizzati per influire sulla parte arcade, secondo la logica per cui un concorrente maggiormente preparato avrebbe incontrato meno difficoltà sul suo cammino. Mentre la programmazione proseguiva di buona lena, mi fu richiesto di studiare la possibilità di stampare alla fine del primo blocco un codice dal quale si potesse ricavare l'effettivo punteggio raggiunto nei test. L'idea, in verità molto sfumata, era quella di tenersi aperta un'opzione per utilizzare il gioco ai fini di un concorso - magari in occasione delle nuove selezioni ufficiali o come iniziativa dell'apposita rivista edita dall'organizzazione del Camel Trophy. Il rovescio della medaglia era però il divieto di fornire ai giocatori un feedback immediato della loro bravura nella parte teorica. Considerando il fatto che quel codice non venne poi messo a frutto per alcun concorso, proporre un codice alfanumerico un po' criptico dopo 32 non sempre facili domande lasciava i giocatori quantomeno dubbiosi. Per i curiosi, comunque, la chiave di lettura del codice - residente nei 4 byte di memoria più alti della macchina per permetterne il passaggio ai blocchi successivi - è strutturata come segue:

I 32 quiz sono suddivisi in due categorie, teoria di guida (22) e sopravvivenza (10). In alcuni casi - sei nella guida e due nella sopravvivenza, per la precisione - le tre risposte presentate comprendono sia quella corretta, sia una ritenuta comunque accettabile anche se non perfettamente giusta. I quattro digit del risultato riflettono quindi le due tipologie di risposta - esatta e accettabile - per entrambe le categorie di domande:

Primo digit: risposte esatte nella teoria di guida

Secondo digit: risposte accettabili nella teoria di guida

Terzo digit: risposte esatte nella sopravvivenza

Quarto digit: risposte accettabili nella sopravvivenza

Da un codice base A3A7 il giocatore può dunque arrivare a un punteggio massimo W3K7 (tutte risposte corrette), mentre per esempio un risultato G7B9 indicherebbe sei risposte esatte (G) e quattro accettabili (7) nella teoria di guida, e una risposta esatta (B) e due accettabili (9) nella sopravvivenza.

Un altro punto cruciale riguardò invece la parte grafica del secondo blocco, quello dedicato all'analisi dei tracciati preconfezionati e alla costruzione del proprio percorso alternativo. Qui la difficoltà fu quella di ricostruire con precisione le tappe dei Camel Trophy tenutisi in Zaire (1981), Amazzonia (1982) e Borneo (1983), dato che il materiale a disposizione era di varia provenienza e qualità, e comunque mai ideale per le mie esigenze. Per lo Zaire, in particolare, l'unico elemento su cui potevo lavorare era la piccola fotografia un po' sbiadita e sfuocata di una mappa geografica a grande scala dell'area equatoriale di Mongo e Bandundu. Dovetti innanzitutto ricavare un ingrandimento della foto originale e quindi, con pazienza certosina, passare a calcolare distanze e decifrare toponimi. Più in generale, l'impegno richiesto da questo blocco del gioco riguardò soprattutto il reperimento dei dati necessari e la loro conversione in un formato omogeneo che permettesse di gestire uniformemente i vari tracciati con le medesime routine. Pur non essendo un grafico, mi occupai anche di realizzare le schermate con le mappe (le stesse che appaiono nel manuale cartaceo del gioco), il che fu un piacevole diversivo rispetto ai conteggi chilometrici, ai calcoli dei consumi di tappa e all'analisi delle caratteristiche del terreno.