Camel Trophy Videogame vent'anni dopo:

Hai visto l'alba stamattina

Tornati in redazione affrontammo a ranghi serrati le ultime quattro settimane ancora a disposizione. Il tempo ormai scarseggiava, e non era insolito iniziare a programmare alle otto del mattino per andare a dormire - giusto qualche ora - alle sei del mattino successivo. Chiunque abbia mai realizzato software commerciale conosce bene la frenesia che caratterizza l'avvicinarsi della data di consegna. Le giornate si fanno sempre più brevi nonostante si sacrifichino ore di sonno per terminare la realizzazione delle funzionalità previste, cercare e neutralizzare i bug e far fronte agli imprevisti dell'ultim'ora. Questo significa spesso riaprire moduli già sottoposti al check-out finale, prendere al volo decisioni che in teoria avrebbero dovuto essere affrontate in sede di progetto, sincronizzarsi con i colleghi... Tutte fasi che caratterizzano tuttora la produzione software e che vent'anni fa, quando le funzioni tipiche dei linker dovevano essere svolte manualmente, erano possibilmente ancora più complesse. Provate a pensare la quantità di indirizzi di memoria corrispondenti a variabili o subroutine che, dichiarati in un certo modulo, erano referenziati da altri moduli. Bastava che il programmatore che aveva in carico il primo modulo modificasse la locazione di una variabile o di una subroutine che tutti gli altri programmatori dovevano aggiornare tutti i rispettivi moduli per mantenere la coerenza complessiva del software. Una dimenticanza o un errore di battitura comportavano, come è facile immaginare, l'insorgere di bug assai fastidiosi.

All'inevitabile opera di debug si affiancava inoltre la necessità di trovare accorgimenti per velocizzare le parti critiche del programma e ridurne il più possibile la lunghezza. La questione delle dimensioni fu infatti il nostro peggior incubo in quest'ultima fase finale. In assenza di un piano dettagliato che imponesse limiti di spazio alle varie sezioni di codice, facevamo affidamento solamente sulla nostra abilità nel limare byte e cicli macchina. In questo senso riuscimmo a ottenere risultati egregi, anche se in fase di ultimazione fummo costretti ai salti mortali; per esempio fu necessario tagliare un'animazione di contorno poiché non avevamo più lo spazio necessario per la grafica e il relativo codice. L'animazione in questione era quella di un elicottero che interveniva per rimuovere la Land Rover impantanatasi nell'attraversamento del guado. La grafica dell'elicottero è tuttora presente all'interno del programma definitivo: ma gli 80 byte o giù di lì che sarebbero serviti al codice per muoverla non si trovarono mai.

I problemi iniziavano a far capolino anche al di fuori della programmazione. Il primo, e per certi versi assolutamente imprevedibile, riguardò la colorazione con il caratteristico "giallo Camel" di tutti gli elementi della produzione come cassetta, etichetta, confezione, libretto di istruzioni, adesivo. L'indicazione pervenuta dall'organizzazione era di utilizzare un colore ben preciso, il "Pantone 116C"; come però si scoprì ben presto, il 116C non era un codice previsto dalla scala Pantone ufficiale, o almeno così ci venne garantito da tutti i fornitori interpellati, per cui ognuno adottò la tonalità che gli sembrava più vicina a quella dei campioni ufficiali. Per questo motivo esiste un "giallo Camel" diverso per ogni elemento del Camel Trophy Videogame - anche se a parziale consolazione verificammo che lo stesso problema riguardava tutto il materiale ufficiale prodotto in precedenza dalla stessa organizzazione del Camel Trophy. Al nostro interno "Pantone 116C" divenne immediatamente una frase in codice per indicare qualunque specifica impossibile o palesemente destinata a essere aggirata.³

Ok, il prezzo manca

Gli inglesi dicono che il diavolo si annidi nei dettagli: per questo tutti si erano concentrati sul design, sulle densità di colore, sulle diciture legalmente corrette e insomma su tutte quelle cose che solitamente risultano essere "vettori di errore" in qualsiasi produzione grafica o editoriale. Abbastanza ovviamente, i problemi del penultimo minuto arrivarono da direzioni alquanto inaspettate. La Scoperta Terrorizzante numero uno riguardò il depliant con la scheda di iscrizione alle selezioni del Camel Trophy, la cui altezza era stata decisa in modo da poterlo inserire all'interno della confezione del gioco. Peccato che per questo scopo fosse stata tenuta in considerazione l'altezza esterna della confezione, di qualche centimetro superiore all'effettivo spazio utile interno. Fu così necessario, in fase di confezionamento, piegare a uno a uno tutti i depliant: un lavoro certamente facile, ma che moltiplicato qualche decina di migliaia di volte può mettere a dura prova la pazienza di chiunque.

La Scoperta Terrorizzante numero due depone invece a favore della natura poco venale dei partecipanti al progetto. Nessuno si accorse infatti che tra tutte le diciture e indicazioni riportate sull'esterno della confezione mancava un'informazione tutto sommato fondamentale: quella del prezzo. Anche qui, decine di migliaia di adesivi (ovviamente color Pantone 116C, ovviamente di tonalità diversa da tutte le altre) dovettero essere apposti a mano in fase di confezionamento. Per fortuna chi si occupava dell'assemblaggio delle componenti del prodotto disponeva di legioni di gnomi certosini - non poteva essere altrimenti - e quindi nonostante questi due noiosi imprevisti le consegne finali non subirono alcun ritardo.

Lo spot radiofonico

Tornando alla programmazione, nella corsa contro il tempo gli effetti di qualunque intoppo risultavano amplificati. Un calo della tensione elettrica, un floppy difettoso, un crash che costringesse a ricaricare l'intero ambiente di sviluppo: quelli che fino a un certo punto del progetto potevano essere considerati come semplici fastidi, nell'ultimo periodo di lavoro finivano con l'assumere un carattere ben più infelice. La stanchezza si faceva ormai sentire, gli errori diventavano più frequenti e le persone più introverse. Fu quindi con piacere che, a una settimana esatta dalla scadenza, ci venne consegnata la cassetta con lo spot radiofonico destinato alla diffusione sul circuito nazionale SPER Italia Radio dal 25 settembre al 25 ottobre 1985 (per ascoltarlo fate click qui). Se da un lato questa anteprima poteva aumentare la pressione ricordandoci che al di fuori del nostro ufficio molte altre persone stavano facendo la loro parte nel progetto e che tutti non aspettavano ormai che noi, dall'altro ci fece rendere conto che bene o male eravamo giunti alle strette finali: bastava un piccolo sforzo ancora e avremmo potuto tirare il meritatissimo sospiro di sollievo. In ufficio erano arrivati anche gli scatoloni con gli adesivi ufficiali del Camel Trophy 1986 da allegare al gioco, oltre agli impianti esecutivi della confezione e del manuale. Più del calendario, erano proprio questi segnali a farci rendere conto di essere finalmente arrivati al traguardo del nostro personalissimo Trophy.

Master blaster jammin'

Ultima tappa, 15 settembre 1985. Tutto il team al gran completo si riunisce per collegare un'ultima volta tutti i tasselli: i primi due blocchi, terminati da tempo ma ricontrollati e aggiornati con le immancabili modifiche dell'ultimo minuto, e soprattutto i vari moduli che compongono il terzo blocco. Non tutto fila subito liscio, e i test finali sono resi più difficoltosi dal particolare sistema di masterizzazione che utilizza una apposita routine per il caricamento turbo messa a punto da Eugenio e Bruno sulla base di quella già adottata per Run, nota come Furbo Tape. La routine per il gioco, ribattezzata - non poteva essere diversamente - Furbo Camel, è suddivisa in due parti: la prima carica i moduli del terzo blocco nell'ordine appropriato per poi salvare il tutto su nastro a velocità superiore rispetto a quella standard prevista dallo ZX Spectrum. La seconda porzione, residente all'interno del gioco stesso, serve invece per poter eseguire il caricamento nonostante la velocità accelerata che la consueta routine di LOAD presente nella ROM del computer non riuscirebbe a gestire.

Il ricorso ai turbo si era presto affermato su tutti gli home computer dell'epoca nel tentativo di ridurre i lunghi tempi di caricamento di allora. Utilizzando frequenze più elevate rispetto a quelle previste dai fabbricanti era infatti possibile tagliare di una buona percentuale i tempi di attesa, a prezzo però di una riduzione dell'affidabilità complessiva. Era sufficiente un nastro di qualità inferiore o un registratore con le testine sporche o disallineate per dare origine a infinite serie di errori di caricamento che, di fatto, impedivano l'utilizzo del software. Spesso alle routine turbo venivano associati meccanismi di protezione dalla copia, e la faccenda diventava ancora più complicata. Rimane famoso il caso della testata concorrente Load'n'Run, che a un certo punto fu costretta ad abbandonare la strada del turbo per i ripetuti problemi segnalati dai suoi lettori. Al contrario, Run riuscì a offrire un giusto mix tra algoritmi di velocizzazione e qualità del nastro, e le lamentele furono sempre limitate e quasi sempre risolvibili o con un semplice intervento di pulizia e taratura del registratore o, nei casi più ostinati, con la sostituzione della cassetta. Sul numero 12, in particolare, era stato pubblicato un eccellente analizzatore di spettro, Scanner, tra i cui utilizzi vi era anche quello di assistere nella regolazione delle testine dei registratori a cassetta. Questo tool aiutò a migliorare decisamente la qualità del caricamento da parte dei nostri lettori, come molti non mancarono di farci sapere.

La bobina con il master per la duplicazione viene terminata il 16 settembre, esattamente nei tempi previsti. Esco dall'ufficio sotto un sole ormai indebolito che già preannuncia l'imminente autunno. Un'intera stagione è scivolata tra dromedari e codice macchina: è arrivato il momento di andare a casa a smaltire l'adrenalina che ha tenuto in piedi tutti noi in questi ultimi giorni, riprenderci da quella sensazione simile a uno svuotamento che si prova dopo aver raggiunto un traguardo a lungo agognato. È tempo che il cammello vada per il mondo con le sue gambe. Le mie mi stanno portando finalmente "in due metri a caricar pupille".

3 - La possibile soluzione a questo annoso "mistero" mi è stata proposta da un lettore di questo sito, Davide Benaglia (che ringrazio), il quale mi ha spiegato come il Pantone 116C non sia altro che il colore che uno stampatore deve mettere in macchina per ottenere il Pantone 116 puro quando la stampa avviene su carta lucida; ottenere il Pantone 116 su altre superfici di stampa come stoffa, carta opaca o plastica richiede colori differenti (116U e 116M, per esempio). L'equivoco dunque non sarebbe sorto se le specifiche del branding avessero correttamente specificato "Pantone 116" lasciando poi la scelta di 116C, 116M o 116U al singolo stampatore incaricato di produrre i vari materiali del gioco, dalla confezione esterna fino alla audiocassetta. Torna al testo