The Acorn Electron is blessed with the superb BASIC which is versatile, easy to use, a doddle to master, blah blah blah. The usual banter we've heard lots of times really falls apart in one area. For whilst it's very easy to equip oneself with Yazdani and the User Guide to create BASIC monochrome shoot-'em-ups, string utilities or puzzles, should you attempt to build up a traditional adventure from scratch with it, you'll soon realise just how tough it is. Allowing for all the eventual user's possible inputs in all locations is not an easy task and, for a beginner to computing, it borders impossibility.

That is, of course, not to say it cannot be done. Anyone willing to entrust some time to a specialist book on the subject of writing adventure games in BASIC, such as Adventure Games For The Electron claims to be, can learn its author's methodology, emulate it and, time and patience providing, produce something pretty decent. It's certainly a more appetising alternative than beginning a project in the metaphorical dark location without the lamp to guide you.

In general, adventure programs written in BASIC are invariably long and complex beasts. The spaghetti coding of some, such as Usborne's Silver Mountain published this EUG, are impossible to trace through if a bug occurs. If you've ever typed in an adventure listing such as this (or one from Electron User or Elbug), you'll be aware of how laborious and time-consuming bugchecking is. There are almost infinite possibilities regarding text input. Imagine missing the closing " inverted commas on the text "You have nothing." in a game where your adventurer starts with a full inventory. You may not think to DROP everything to test this INVENTORY feature and the bug, giving the break off error "Mistake" will get through. Even the professionals have fallen into such traps.

Such an example illustrates just how difficult the production of a 100% unbugged adventure game really is and, despite BASIC's versatility, it requires a very good teacher to help you program one in it. But, despite the promising artwork on the cover of the roughly A5 paperback, Adventure Games For The Electron by A. J. Bradbury isn't going to help you at all.

Opening it, we find each chapter jovially headed and subcategorised ("4. Who Goes There?", "9. The Well-Chosen Word") and an emphasis on teaching the skill of writing adventure games by means of modular walkthrough programs concerned with moving around, using objects and accepting input. At 232 pages, the book appears a tiny bit daunting but then, we now know this isn't easy, so in we plod. And the nightmare begins. According to the blurb, A. J. Bradbury is a keen adventurer and a Computer Studies teacher writing for leading magazines. Keen adventurer he may be but what is immediately obvious is that he has no idea of how to construct a user-friendly program. Teacher he may be but he isn't even halfway competent at stating his subject matter clearly!

Instead of sticking to the traditional format of adventure game, he constantly switches through everything from the role-playing character type to a section on User Defined Graphics to illustrate objects! When did you see these in an adventure? Never. And this is just the start.

Through each piece of code, Bradbury employs a terrible programming style, choosing the numbers for his lines like someone plucking balls for the National Lottery. Instead of 10, 20, 30... we get haphazrd numbering like 1, 2, 3, 98, 99, 163, 297... (Page 67). He doesn't use procedures, he uses GOSUBs - cue groans from anyone who has ever tried to disentangle these. But the cardinal sin has to be using variable values to retrieve lines with silly high numbers: 7190CH=VP*200:GOTO(CH+9400). If CH is not what it should be, the code leaves its reader clueless as to how to correct the line! And it does need correcting.

There's a fabulous overuse of REM statements. They frequently take up over half of the routine's space - and are then inaccurately refered to in the accompanying text! More than this, the routines frequently just do not work, even though we are assured they come direct from a working Electron. Take a look at this (on page 230):

   13000DIM N$(22)
   13020FOR X=1 TO 23:READ N$(X):NEXTX

An array is dimensioned to 22 places, then the subsequent line tries to put values into *23* of them! Not unsurprisingly, this hangs with the "Subscript" message. Pretty exasperating stuff for the learned, never mind the amateur. "Came from a working Electron", my left foot!

Each procedure defines boring. There are no mini-adventures to work through. No real hints even on how to create your own, apart from a section devoted to mapping, laughably negatively worded. Do you know our machine has only very limited memory? Where Bradbury should be teaching us how to "tokenise" text to overcome this, he gives a comparative table of free memory on each machine from VIC 20 to C64, you know, just in case you might be interested in how puny the Elk is. Makes you wonder if the title is a bit of propaganda trying to get you to upgrade!

Using the RND function, as all professional adventure programmers know, should be avoided at all costs! No-one told this man.

When you arrive at the end, you are presented with a full type-in adventure introduced with the dubious merit of a "press just two keys for any action" feature. This means that, instead of typing GO NORTH at the prompt, you instead must hit C (GO) then R (NORTH)! Which means you need to constantly refer to the table in the book, and entering commands you're used to takes about five times as long!

Can it get any worse? Regretably yes. The adventure itself is more than bugged, it's crippled; missing huge chunks of code and GOing off TO lines that don't exist. The ridiculous numbering also means I failed to notice when typing it in and then spent days rechecking every last ASCII before slumping to the floor in despair!

This book is disgusting, deplorable and diabolical, an affront to a wouldbe programmer and a disgrace to your Acorn-related collection. At least if I run out of coal in winter, I know the first book to burn!

Dave E