Camel Trophy Videogame twenty years later:

Did you see the sunrise?

After that welcome though short change, the whole team reassembled back to the office bracing for the last four, hectic weeks still available. There wasn't much time left given the amount of work still ahead of us, so it was not unusual to start coding at eight AM and leave the desk for a quick nap at six AM next day. If you have ever been involved in software production surely you are familiar with that particular feeling of a deadline approaching fast. Days get shorter in spite of the longer hours spent in front of the computer screen coding the last features, squashing bugs and managing a wide range of last minute issues. This often means re-opening software modules already checked out, changing critical design decisions, getting in sync with the rest of team and so on... problems that still plague many projects today, but that possibly were more complex twenty years ago when code linking procedures had to be done manually. Just imagine the wealth of program variables or subroutines which, declared in a particular module, were referenced by other modules as memory addresses. A change in the first module meant that everybody had to update their own modules to guarantee consistency throughout the whole program. Failure to do so resulted in obnoxious bugs which took time to identify and solve.

As if debugging were not enough, we also needed to find ways to speed up critical code portions while saving memory wherever possible. Managing code size was our worst nightmare during the final stage of the project. Lacking a detailed plan assigning sizes to each program module, we relied only on our ability to shave off bytes and CPU cycles here and there. We were forced to remove a secondary animation - a helicopter coming to rescue a Land Rover stuck in the mud in the Ford Crossing module - since we had no space left for both the graphics and the actual animation code. You may still find the graphics data within the published program; but we never found the 80 bytes or so for the animation routine.

We were also experiencing problems in other production matters. Completely unexpected was an issue with the typical "Camel yellow" for the various elements such as tape shell, label, box, instructions leaflet and sticker. The Camel people had sent a precise color specification, "Pantone 116C"; but soon we discovered that 116C was not included in the official Pantone reference, or so we were told by all the vendors we were working with. So, while everybody tried to stick to the official samples as much as they could, every piece of the Camel Trophy Videogame boasted its own version of the "Camel yellow". Luckily enough, this problem was also apparent in every sample of officially approved promotional and merchandising reference material provided to us. As an inside joke, "Pantone 116C" quickly became a code word for any unrealistic, impossible specification.

Ok, the price is missing

Devil is in the details, they say: for this reason everybody focused on design, color densities, legally perfect disclaimers, and on all those things usually known to be "error vectors" in the graphic arts and publishing industries. Of course, the last minute troubles came from unexpected directions. Horrifying Discovery number one involved the Camel Trophy application form, the size of which had been carefully planned for the inclusion within the videogame retail box. Alas, the form measures had been based on the outside box size, half an inch wider than the actual size available within. At packaging time, someone had to fold all forms one by one, an easy task indeed but not great fun for anybody when done tens of thousands times.

Horrifying Discovery number two speaks volumes about the ungreedy nature of the whole project team: nobody had realized that, among all the mandatory indications and fine print, the package lacked an essential piece of information - its price. Again, tens of thousands stickers (with their own variety of Pantone 116C, of course) had to be printed and manually applied to each individual package. But in the dungeons of the packaging company, legions of hard-working gnomes were forced into brutal 24-hours shifts, enabling the timely delivery of the product in spite of the previous production shortcomings.

The radio ad

In the meanwhile, racing against the clock meant that any unplanned issue had nearly devastating results. A power spike, some defective floppy disk, a computer crash that forced loading back the whole development environment... every nuisance had a greater impact than normal. We were tired, coding errors kept creeping in at an increasing rate, and we were growing irritable and introvert. Some welcome excitement came just one week before deadline upon receiving a tape cassette with the radio ad, broadcasted on the SPER Italia Radio national network for a whole month from September 25th, 1985 (click here to listen to the ad - Ogg Vorbis file, in italian). This sneak preview raised the pressure further as it was a reminder of the many other people involved into the project who were just waiting for us; on the other hand it signaled that, at last, the finish line was nigh. We had also been provided with the long-awaited 1986 Camel Trophy official stickers, plus the executive layout for the game manual and the box. These, more than anything else, indicated that our own Trophy was finally done.

Master blaster jammin'

Last leg of the race, September 15th, 1985. The whole team meets to assemble the final version of the software. The first two program blocks, finalized by weeks, are thoroughly re-checked and updated with the last minute changes; but most of the work goes in scrutinizing the third block's modules. Things do not go smoothly at first, and the final tests are complicated by the particular turbo-loading method developed by Eugenio and Bruno leveraging the traditional Run turbo routine, called Furbo (or "smart", in italian) Tape. This new system, aptly named Furbo Camel, is divided into two parts: the first one loads each module in its correct order, then saves the whole memory image on tape at a higher speed than the ZX Spectrum standard speed. The second part of the routine, residing within the game, enables the custom turbo loading effectively replacing the usual LOAD command from the computer ROM.

Several turbo methods had found their way on the home computers of that time addressing the needs to reduce the otherwise lengthy loading times. By using higher frequencies it was indeed possible to shorten the wait while lowering the overall reliability. The errors generated by a low quality magnetic tape or a cassette player with dirty or off-azimuth heads were sufficient to abort the whole loading procedure, effectively preventing the software from working at all. Turbo routines were often associated to anti-copy schemes, making the whole procedure even more complex and flimsy. An exemplary case was that of Load'n'Run, a competing magazine which had to give up the turbo because of the continuous errors experienced by its readers. On the contrary, Run had been able to provide the right mix of speed and tape quality: reader complaints were minimal and most of times quickly resolved by cleaning or tuning the player's heads, only seldom requiring the tape substitution. On issue 12, Run published an excellent spectrum analyzer, Scanner, particularly helpful for azimuth correction. This tool proved critical to enhance the loading quality for our readers, as many enthusiastically let us know.

The master reel is delivered to the duplication facility on September 16th, right on schedule. I leave the office under a pale sun announcing the imminent autumn. A whole season of the year has slowly passed through camels and computer code: it is now time to go home, drain off the adrenaline that kept us standing during these days, and get over that feeling of emptiness often experienced upon reaching a long-awaited goal. It is time the camel starts walking with its own legs. Mine, are taking me to get some rest - at last.