22nd October 1987 (yes, really!)
ForewordI'm leaving this article exactly as it was when I wrote it fourteen years ago - the only change is the conversion from troff -ms format into HTML. Some of what I wrote then is now pretty embarassing as I read it now, but that's history for you. I was only nineteen at the time. (Arrrgh! That must mean I'm thirty-three now!) Anyway, here it is in all its very unvarnished glory.
This series will teach you to write Adventure games in BASIC. Why use BASIC, you may ask, when utilities with which to write these games are available in increasing numbers and sophistication? Well, the recent history of Adventure games should make this clear.
Around 1984, Gilsoft released the original Quill, a utility which allowed the inexperienced programmer to write adventures using a very simple command language. The results, however, were correspondingly simple. The market was flooded with a number of games, many of which were of poor quality, and the remainder of which, while working well within the limitations imposed by the system, were restricted in structure.
This is not to say that nothing good came out of The Quill - certainly it was responsible for the emergence of a number of quality games, including, for instance, Sentient Software's Crystal Frog and Malice in Wonderland, and Fergus Bored of the Rings McNeill's early efforts. However, it was not long before the similarity of many of these games - imposed by the system - started to tell, in the form of increasing disillusionment in the press and public.
By the time Bored of the Rings was released, Delta4 had started using Gilsoft's Patch, allowing greater flexibility in Quilled games, and were also making their own changes independent of the official Gilsoft product. This allowed the distinctive character of Delta4's early games - including the redefined character sets.
When The Patch was officially released, there was a small and temporary upsurge in the quality of new games, but nothing lasting - the next major development in Adventure-writing was Incentive's GAC, or Graphic Adventure Creator. This, as the name implies, includes a graphics facility as standard, (whereas The Quill required a further 20 pound outlay on the complementary Illustrator before any graphical work could be done).
But the major factor in GAC's favour was a far more general flexibility - the command structure resembling a real programming language far more closely than The Quill's relatively primitive subset. The potential of this system was (and is) far greater, with the ability to include more complex combat routines, and suchlike. Yet this system, too, is beginning to show signs of age. Read the Adventure column in any recent edition of Zzap!64 if you doubt this, for all too frequently it is claimed that ten, eight and even six pounds is too great a price to ask for a GACked game.
And it's true - while the limitations of GAC are less immediately obvious than those of The Quill, they are inherently similar. There is still a lack of real flexibility in the system, and now that the novelty of GAC has, to some extent, worn off, the press and public alike are now beginning to see the similarity between its offspring. Exactly the same thing that happened to The Quill a couple of years back.
So where does all this leave today's aspiring adventure author? Well, he (or she, obviously), can invest in Gilsoft's latest utility PAW, (That is, Professional Adventure Writer), which is far more complex even than GAC. The command structure of PAW continues the trend towards ``real'' programming languages, with a greater complexity than ever before, to the extent that magazine reviews have unanimously warned away the beginner. And, be fair, PAW is certainly a very professional piece of software by all accounts.
But can you see where all this is leading? Each new system, in attempting to overcome the limitations of its predecessor, has hit a deeper form of the same underlying problem, namely the lack of freedom allowed by a command structure that allows only adventure-programming actions to be accomplished. How, for instance, can any such system be used to write a multi-player adventure?
This is the problem I faced when I started to write The Causes of Chaos for CRL. Not to beat around the bush, none of the available systems allow freedom enough from pre-ordained structures for such a concept to be implemented. This being the case, I had no choice but to use BASIC, or at least, to use some high-level language for the game.
This, of course, has other advantages - the inherent flexibility of using a fully comprehensive language means that it is far easier to restructure the memory of the machine used to accommodate any machine-code or graphics storage-space required, and to include user-defined character sets and suchlike, than it would otherwise be.
In this series, I will not concentrate so much on the technical details of how to shift memory around and so on, since this kind of knowledge is firstly, not strictly necessary to produce a playable and complex game, and secondly, not portable from machine to machine. The Causes of Chaos was written for the Commodore 64, and so any machine-specific details will relate to this machine, but the great majority of this material will be entirely portable between BASIC computers.
Finally, some people may question the choice of BASIC as the right high-level language in which to write a long and complex program. Personally, I happen to like BASIC, but this is more due to familiarity than any inherent advantages it has over other high-level languages. No, the real reason for choosing BASIC is the simple fact of its standard implementation on home micros. I mean, be fair, how many people would really benefit from a series on how to write Pascal?
I realise that this has all been a bit historically based, and even rather vague for an introductory article, but I feel that it's worth establishing the motivation for tackling such a formidable task as programming an adventure in BASIC. Next time, I shall start to explain the concepts involved in an adventure game from the point of the view of the programmer, comparing the BASIC implementation with the Quilled one - this being the utility most widely used at the moment - and maybe even writing some code!
Have a nice day! - Mike.
AfterwordHuh. Was that it? How disappointing. Turns out that I didn't say anything much about programming, just complained about the utilities that existed in the 80s. I guess in retrospect I was right in recognising that there is a trade-off between flexibility and ease of use - not only in this area but in all programming - but I wish I'd written more about how I actually put the games together. Ah well.