15. The Slave

by Garry Francis

 

Issue 24

Nov/Dec 86

Next Article >>

<< Prev Article

 

Let's suppose that you've played a few Adventures. You've been bitten by the 'Adventure bug' and you decide to have a go at writing an Adventure of your own. You've got a few ideas floating around in your head and the programming side of it doesn't seem too difficult. After all, it's just text input and text output. Right?

The ideas begin to multiply and conflict with one another, but as they evolve, only the best ideas survive. After a little more day-dreaming, you come up with an original theme. You sift out the most intriguing puzzles from the back of your mind and devise a cunning map on the back of a shopping list. This game is going to be brilliant! When you unleash it onto an unsuspecting world, they will herald you as the greatest Adventure writer of all time.

Now all you've got to do is put all the pieces together and write the code. Then everything collapses in a heap. How on earth do you even start to write an Adventure program?

Writing an Adventure is quite a monumental task, but it is not difficult, just tedious. If you are serious about writing an Adventure (whether for fun or profit), there are probably three approaches you could take. Firstly, you could do an immense amount of research into human psychology, database design, parsing techniques, artificial intelligence, compiler design and so on and hopefully write a complete Adventure from scratch in the language of your choice. This may take as long as two years, so you'd have to be pretty dedicated. I have taken this approach in my own spasmodic Adventure writing pursuits and some of my research notes are over five years old!

Secondly, you could take a listing of an existing Adventure, decipher it to see how it works and modify the database and logic processing parts to create your own game. There are a number of books and magazine articles that you could use to help you along the way. A friend of mine followed this approach just recently by following an ANALOG listing and came up with quite an impressive Adventure in just a few weeks!

Thirdly, you could use an Adventure writing utility. There are a number of these around including commercial products such as Adventure Master and Adventure Writer or the more primitive public domain offerings such as Max Manowski's Adventure which is available from Antic, Page 6 and various user groups. That brings us to the subject of this month's column, The Slave.

The Slave

The Slave is the latest offering in the area of Adventure writing utilities available for the Atari 400/800/XL/XE. The hype in the advertisements make it out to be the greatest thing since the ring-pull beer can. Unfortunately, this is just not so. Writing Adventures is downright hard work and The Slave doesn't make the job any easier you just do things differently. It is a tool to help you get the job done. Nothing more, nothing less. Once you've accepted that fact, you are less likely to be disappointed with the product.

The creative aspect of Adventure writing is still up to you. No Adventure writing utility will help you design an Adventure and neither should it. YOU must create the plot, draw the map, design the puzzles, select the vocabulary, create the characters, write all the room and object descriptions, predict the player's actions and decide how to handle them. If you can't write, can't spell or can't design logical puzzles (and logical solutions), then Adventure writing is not for you. If you fall into this category, then you might as well stop reading right now.

For those of you still with me, I hope I've softened your expectations so that you don't expect too much from The Slave. Now, let's get down to the nitty gritty evaluation.

First impressions

I was bubbling with enthusiasm when the editor told me that The Slave was on the way for review I'd never been sent anything to review before. When it arrived, I couldn't wait to get started. I ripped the parcel open to find a disk and a bulky manual. The loading instructions said to insert The Slave disk and turn on the computer. When I did, I was rewarded with a screen full of garbage! Hey, what's going on here? When I double checked the instructions, I found a paragraph AFTER the loading instructions which told me that I needed BASIC. Sheesh!

I rebooted with BASIC.

This time a rather impressive GRAPHICS 8 title screen came up accompanied by a "horribly cute little tune, totally out of character with the screen display itself". At least that's how the manual described it.

When the tune finished, another program loaded and I was presented with a GRAPHICS 0 menu in Atari's default blue. None of the options made much sense, so I started at the top to see what would happen. Another program loaded. Another menu presented itself in default blue. And again, nothing made much sense. After experimenting a bit, I was able to achieve nothing except considerable apprehension because of the way the disk drive kept turning on and off for no apparent reason. I tried to get back to the first menu, but couldn't. It turns out that you have to reboot (by pressing SYSTEM RESET) and repeat the title page/cute little tune sequence.

The next time around, I picked a different option from the main menu and ended up in the same state of confusion. It looked like I'd struck a dog! At this point, I rebooted the system with trusty old DOS 2.0 and did a disk directory. Nothing! It was time to heed the old hacker's proverb, 'If all else fails, read the manual'.

The manual

The Slave manual consists of 126 pages of blurry, draft quality, dot-matrix printing (without lower case descenders) printed on single-sided, tractor feed paper. In other words, a backyard job. But that's okay. I've got a lot of respect for anyone who tries marketing their own product PROVIDING THEY'VE GOT A PRODUCT WORTH MARKETING!

A first glance at The Slave manual was encouraging. It had a good contents page and everything appeared to be laid out in a logical order. Little was I to know what the future held in store.

If you ignore the author's tendency to pat himself on the back, then a couple of the early chapters make interesting reading. These early pages also told me what I'd already learnt the hard way, mainly that The Slave manual is essential to learn how to use the program. "Ignore it at your peril without it you will go nowhere very quickly indeed." This advice should have been plastered all over the front cover!

I spent the next week reading The Slave manual from front to back. Mind you, this was done while travelling to and from work and some parts of the manual were virtually impossible to fathom without a computer in front of me. By the time I'd finished the manual, I felt like saying 'So what?'.

My initial impressions had been misleading for the manual turned out to be horribly inadequate and broke many of the rules of good documentation. For example, it was not broken down into small manageable chunks, it did not flow properly from section to section and there was no indication of how the minor parts fit into the whole. Nothing seemed to make sense.

The sample Adventure

It struck me that the next step was to try and run the sample Adventure referred to in the advertisements and the manual. The manual didn't actually tell you how to do this, but I thought I'd be able to work it out with a bit of trial and error. By this time, I'd discovered that the disk was formatted using DOS 3.0. (Why on earth anybody would want to use DOS 3.0 is a complete mystery to me.)

Anyway, I re-examined the disk and found that it had 15 files. The purpose of these files wasn't mentioned anywhere. I could see that I was going to have to do this the hard way, so I started out by converting all the files to DOS 2.0 using Matthew Jones' 'Access III' from page 6 issue 14. Lo and behold, the program wouldn't run in DOS 2.0! I wondered why.

When I examined the files, I found that five of them were written in BASIC. Hmm. Maybe I could browse through the listings, work out what they were supposed to do and why they wouldn't work in DOS 2.0 and perhaps make a couple of little changes so that they made more sense. I particularly wanted to avoid the reboot every time you tried to return to the main menu.

Unfortunately, the author had put some protection in the programs to avoid them being listed. It was all pretty standard stuff so I promptly proceeded to unprotect them. During the process I discovered that the programs had been written using Revision B BASIC. This was evident by the way the programs had 'grown' each time they had been saved. By fiddling with BASIC's zero page pointers, I was able to shrink the programs back to their proper size. I also discovered that the author used some pretty sloppy programming techniques (such as premature exits from FOR ... NEXT loops) and that two of the programs had not been through the standard LIST, NEW, ENTER procedure to clear out the variable name tables.

I realise that all this is of little or no interest to the end user, but it showed all the signs of an amateur. I was building up a very strong image of The Slave's author and it wasn't very favourable!

Once everything was all cleaned up, I was able to work out how things fitted together. With my new found knowledge, I cross referenced all the files with the menus in the manual and started to see the light at the end of the tunnel. Then I was struck a crushing blow. I suddenly realised that there was no sample Adventure! Bloody hell! Talk about false advertising! I was shattered.

The Slave

By this time, I'd wasted a month or so (in between other projects) just trying to understand how The Slave was supposed to work and I still hadn't written so much as one byte of an Adventure! The deadline for this review was rapidly drawing near and I started to panic.

I couldn't cheat. I couldn't just study the sample Adventure (because there wasn't one) and I couldn't think of any other shortcuts. There was nothing for it but to write an Adventure from scratch and try to get it running with The Slave.

Luckily for me, I love writing Adventures. I've written a few before and knew exactly what to do. I christened this one 'baby Adventure' because of its size and came up with a cute little map, an objective and a couple of fairly straightforward puzzles. Once the Adventure was designed (on paper at least), the next step was to turn it into a program using The Slave. I did so with a great deal of apprehension.

I started at the beginning of the manual and worked through it very slowly and very cautiously. It rarely presented anything in a logical order, so I had to constantly flip forwards through its pages in search of the missing instructions. In many cases, the missing instructions were obscure, ambiguous or weren't to be found anywhere.

While building my Adventure, The Slave constantly did things that I didn't expect, like adding bits that I didn't want added. Whenever this happened, I backtracked and tried again. And again ... and again ... until I eventually got it right. In fact, I started the entire Adventure from scratch at least three times!

When the Adventure was finished, The Slave compiled it without any complaints, but it wouldn't run. Don't ask me why. I'm sure I did everything properly, but the manual is so vague on some points, that I couldn't be sure. In the end I gave up in despair. If I had pushed on any further, I'm sure I'd have had a nervous breakdown and I didn't think it was worth it.

A typical session with The Slave

Despite my inability to get the Adventure running, I was able to sort out most of The Slave's illogical menus and its obscure way of handling things. Here is a brief account of what to expect.

Begin by making a backup of both sides of The Slave, then put the original away in a safe place(?). Side 1 contains all The Slave programs and side 2 contains DOS 3.0 and all its support files. You will need to use both sides during a typical session, so you might want to save yourself some disk swapping by copying all the DOS 3.0 files onto side 1. Before you start writing your Adventure, format three disks with DOS 3.0. One is needed for all the text files, one for all The Slave's working files and one for the final game disk.

Boot The Slave and wait for the main menu to load. This has 9 options as listed below:

Descriptions editor
Exits editor
Flags and object locations
Compile adventure code
Vocabulary compile
Sound editor
Rearrange data files
Header creation
BASIC mode

Each of these options except Rearrange data files loads another program, so the normal sequence of events is to make a menu selection, wait for the program to load, remove The Slave disk, insert the appropriate data disk, do some editing, save your work to the data disk, remove the data disk, insert The Slave, reboot the system, wait for the main menu to load and repeat the whole process over and over again until your Adventure is finished.

The descriptions editor is nothing more than an extremely primitive editor which you use to enter all the text that will be output by the game. The Slave divides this text into four files (which are not DOS compatible) for messages, objects, locations and examine.

The exits editor allows you to create the map for your Adventure onto a DOS 3.0 file called EXITS.SLV.

The flags editor allows you to set up flags, initialise the locations of objects and decide whether an object is movable or not. This information is saved onto FLAGS.SLV, OBLOC.SLV and IMMOVE.SLV respectively.

The most complex part of the Adventure writing process is the logic. The manual warns that "the faint of heart should turn back now". The Slave handles logic in the most cumbersome way that I have ever encountered in an Adventure writing utility. You must write the logic in a sort of pseudo language that the author calls Slave Adventure Language. SAL strikes me as being a horribly disorganised mess. It is somewhat similar to a job control language on a mainframe, but less logical. At first glance, the range of commands looks pretty impressive, but a closer look reveals that many of these are necessary to account for The Slave's other limitations. The Slave makes you write the code for the entire program, not just the processing of actions as with other Adventure writing utilities. So how do you write with SAL? Hang onto your hats. You're going to love this next bit. You must first go to BASIC and type in your SAL commands within BASIC DATA statements! That's right ... in BASIC! I couldn't believe it! Talk about a half-baked product! Why not just write the whole thing in BASIC in the first place?

Fortunately, there is a sort of skeleton set of DATA statements included on the disk which you can use as a guide. Once you've finished entering your SAL commands, save the file using LIST "D:SLAVE.ext". You must use SLAVE as the filename, but you can use any extender except XXX. This has a special purpose as discussed below. You can now use the main menu option labelled compile adventure code to create two files called DATAFILE.ext and DATAFILE.XXX. This is why you can't use XXX as an extension.

You must go through a similar process of writing BASIC DATA statements to define your verbs and nouns, then use the vocabulary compile option to create VERBS.SLV and NOUNS.SLV.

The next item on the main menu is the sound editor. I think you can skip this one as a bad joke.

The rearrange data files option goes through a lot of disk activity, but I don't know what it does.

By now, you should have one disk with the text for messages, objects, locations and examine and a second disk with all the following files:

EXITS.SLV
FLAGS.SLV
OBLOC.SLV
IMMOVE.SLV
DATAFILE.ext
DATAFILE.XXX
VERBS.SLV
NOUNS.SLV

Go to DOS, copy SLAVEDRI.VER from The Slave disk to the third blank disk, then append all the above files to it. This takes about 18 disk swaps!

Finally, the header creation option allows you to prepare a GRAPHICS 0 title screen and write a header to the disk you just created with the expanded SLAVEDRI.VER file on it. If everything has gone to plan, you should now be able to boot this disk. If everything hasn't gone to plan ...

A few observations

The Slave is not for beginners. Don't even THINK about using it unless you're an experienced programmer and you have a thorough understanding of how an Adventure works.

Using The Slave turned out to be a disk swapping nightmare. You need five disks to create a game and must constantly swap amongst them. Having two disk drives is of no benefit because The Slave only supports one drive.

Flags are used so frequently in Adventures that I normally associate a flag with every object. Thus flag 1 is used for object 1, flag 2 for object 2 and so on. Unfortunately, The Slave's system doesn't allow this flexibility. Flags 0 to 29 are reserved for special purposes and therefore can't be associated with objects 0 to 29. You can either start numbering your objects with 30 or forget about any one-on-one flag to object association. If you adopt the latter course, your logic in the processing of verbs will need more tests and be much harder to follow.

Unfortunately, The Slave also fails to provide flags for rooms. These are normally used for functions like 'Does the room contain water?', 'Can the thief enter this room?', 'Has the player visited this room before?' and 'Is the room dark?'. These will have to be simulated using extra tests in the logic processing part.

The final Adventure is totally disk based and seems to always take two disks (or two sides of one disk) regardless of how big the Adventure is. I couldn't get my Adventure to run, but it certainly appears that ALL text is read from the disk only as needed. None of it is kept in memory. You know what that means ... lots and lots of disk activity. I love disk intensive Adventures!

Summary

I mentioned earlier that the author of The Slave had a tendency to pat himself on the back. This got me really angry while I was battling to get the program to even work, but it was brought to a head by the following paragraph: "Slave Driver is thus the master control program, the 'guts' of the Slave system, and, throwing modesty to the four winds, is quite brilliant! Anyone out there want to argue?" Yes! I want to argue!

The Slave is a dog of a program. The only feature it has is consistency. It is consistently bad! In fact, in my six years in the computer business, this is unquestionably the worst single piece of software that I've ever been unfortunate enough to encounter on ANY computer. It should never have been released. It is obviously a backyard product written by an amateur. It has the worst user interface and the worst human engineering that I've ever encountered and obviously has no regard at all for the end user. I doubt that it's even been tested. In fact, it strikes me as a half-finished product that's still in the experimental stages.

As an Adventure writing tool, it makes a good drink coaster. It doesn't come within a bull's roar of other Adventure writing utilities even those in the public domain. On a score out of ten, I'd give it a one ... and even that's being generous!

If you're serious about writing Adventures, this product probably won't help you. You'd be better off buying a good book on the subject.

top