Camel Trophy Videogame twenty years later:

Here comes the storyboard

Once we were done with all the bureaucratic stuff and all contracts were duly signed, the storyboard delivery in early June 1985 officially signaled production start. Together with Eugenio and Bruno, I was going to write the computer code for the game, while Gianluca Magnani - a Run reader especially gifted for screen pictures who already was contributing to the magazine - was given the responsibility for the game's splash screens; Simone Majocchi was the executive producer. Working on the game required throttling the usual magazine work, and this was accomplished both by publishing a special double issue, no. 10-11, and by drawing from a growing group of skillful part-time contributors. Another helping hand was to be found within the countless works submitted by our readers: at this time it was not unusual to find interesting works of good quality which we could buy and publish on the magazine. The editorial schedule called for Run issue no. 12 to hit newsstands shortly after the deadline for the Camel Trophy Videogame master reel, so we had to carefully plan this issue as well.

The storyboard caused mixed feelings. We were a bit worried about the wide range of game situations, more varied than we originally thought: this had prompted to split the whole game into three separate blocks, requiring more technical work in a short time. But we were also relieved because, after many lucubration and suppositions, we finally could start focusing on definitive goals.

A couple of months earlier, Eugenio and I had started writing some code meddling with a few techniques for the so-called spriter, an all-important software module for any videogame, having the task of moving objects through the screen and detecting their collisions. It is a tricky piece of code since all its operations must be completed within the flyback, that very short interval when the video beam jumps from the bottom right corner of the display to the upper left one, thus starting a new image refresh cycle. The PAL standard used by European television sets repeats this process 50 times per second, and proper synchronization between the software code and the video beam is critical to avoid screen flicker or badly rendered images.

A good spriter varies depending by the game type and the number of objects to move. While our goal was to write the most versatile spriter possible, one that could be used whatever the definitive storyboard, we soon realized that the extreme code tuning required to stay within the synchronization limits called for an ad-hoc solution, something that had to wait until the technical issues of the game would become clear.

As it happened, the spriter was the almost exclusive task of one of us: the burden was shouldered by Bruno Molteni, who spent most of the summer investigating several options and studying the internals of other commercial games to discover their secrets. The code he wrote was remarkable: in only 650 bytes he packed a highly optimized module with an easy programming interface, while the synchronization issues were settled by using a secondary display file, aka DF2. Instead of directly placing objects - or sprites - within the video memory (which, in the ZX Spectrum, starts at location address 16384), Bruno's spriter operated in a different, hidden memory area which was eventually transferred to the video memory 25 times per second. This is now a classical technique, and in later years I happened to work on videogames boasting even three display files; but at that time it was a matter of autonomously finding a proper solution, so repeating in our own small way a sort of "reinventing the wheel" which represented a rite of passage for any would-be videogame programmer, at least until the modem and the BBS's became ubiquitous - and, with them, specialized discussion forums and the sharing of knowledge.

This one to me, that one to you...

Since I had a good deal of experience with extended size Basic language programs (my first "serious" applications were written in Basic on a CP/M based ITT 3030 computer), I took upon myself the first two blocks of the game, where the machine language could only play a support role, while the third block general management was assigned to Eugenio, and the spriter to Bruno.

The first hindrance came from the data we had to work with. For the first block we had been given copy of the real test used during the team selection process of a previous Camel Trophy edition; but nobody could find the official answers list. We had to draw from own personal knowledge and that of our off-road driving friends and of the Camel Trophy staff, though I still am unsure about a couple of answers. Results of the first, theory-based block had to affect the final arcade block, awarding an advantage to more knowledgeable players. While working on the program I was asked to investigate a way to print out, at the end of the block, an obscure code from which one could reverse-engineer the actual test result. The tentative idea behind this request was the potential use of the videogame for a contest to be held during the real Camel Trophy team selection or, possibly, as a spin-off of the official Trophy magazine. Unfortunately, this also meant that we could not provide any immediate feedback on the player's skills in the theory test. Since that code was not actually put to any use ever since, a cryptic 4-digit string after 32 not always trivial questions left the players quite puzzled, to say the least. For those interested, the result code resides in the upmost 4 memory bytes so it can pass to the following game blocks without being overwritten. Its key is as follows:

The 32 questions are divided into two sections: driving and mechanics (22), and survival (10). Six driving questions and two survival questions allow for both a "correct" and an "acceptable" answer. We thus have two answer types (correct and acceptable) in two question sections (driving and survival) mirrored by the four result digits:

First digit: correct answers in the driving and mechanics section

Second digit: acceptable answers in the driving and mechanics section

Third digit: correct answers in the survival section

Fourth digit: acceptable answers in the survival section

From a base code A3A7, the best result would be W3K7 (all answers correct); for example, G7B9 would mean six correct answers (G) and four acceptable (7) in the driving and mechanics section, and one correct answer (B) and two acceptable (9) in the survival section.

With the second game block, which allowed to analyze the predefined Trophy routes and build one's own alternative race, I experienced another pain point - this time with the graphics contents. The trouble here was to accurately track down all the legs for the Camel Trophy editions run in Zaire (1981), Amazonas (1982) and Borneo (1983), since the reference material provided was of miscellaneous source and quality - and never perfect for my needs anyway. For the Zaire race I had to rely on just a tiny and blurred photograph of a large-scale geographic map of the equatorial area around Mongo and Bandundu. I had to produce an enlarged print of the original picture and painstakingly research distances and decipher hard-to-read toponyms. At a general level, the efforts for the second game block mainly called for researching, finding and converting data in a common format in order to manage the different tracks with the same program code. While I was no graphic artist, I took it on myself to draw the map screens (the same ones displayed in the game manual), a welcome distraction from calculating distances and fuel consumption, and analyzing terrain characteristics.