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
