REALMS OF INTERACTION
part 1 of 5
by Alan Davis
from ZX Computing, May 1986

Alan Davis, author of Firebird's 'Runestone', begins a new series
showing you how to create a world full of independent characters.

Ask a seasoned adventure player to describe the qualities of a good
adventure, and you're likely to find the word 'atmosphere' high on his
list of priorities. In other words, a good adventure should (among
other things) create the illusion that the player is exploring a world
which, though imaginary, seems tangible and real. It should be easy
for the player to forget that he is, after all, dealing only with a
computer program. Certainly the best traditional adventures go a long
way towards achieving this in some respects. Level 9 games are
renowned for their detailed, well-written text descriptions, and the
arrival of The Quill a couple of years ago has resulted in a vast
number of traditional text adventures - some of them excellent. You
could well argue that the adventure player has never had it so good -
and of course in some sense, you'd be right.

The classic adventure game invariably takes the form of an intricate
series of puzzles, set within the framework of an imaginary world.
Essentially, the puzzles make the game - and if it's puzzles you want,
then the world's your oyster. If, on the other hand, you value
adventures more for their atmosphere than for their puzzles - for the
thrill of exploring a strange and exciting world - then all may not be
quite so well.

Let's take an example: you're wandering along a dark, damp passageway,
and turn a corner to find your way blocked by a troll. Hmmm. Try
talking to it. Silence. Give it the gold coin? "You can't" comes the
not so helpful reply. Frustration sets in - clobber it with your axe.
"You can't".

Slowly but surely the realisation is forced upon you that this is no
troll. It's just another puzzle set by the programmer. It sits there,
a part of the scenery, until you come up with the correct response.
Now an avid puzzle solver doesn't mind this, by now he's well hooked
on the sequence of puzzles and simply wants to solve them. But, alas
for the seeker after thrills and exploration, he's just had all his
illusions shattered.


Still life

It remains a source of astonishment to me that among the hundreds of
adventure games available, so few have attempted to tackle the problem
of 'lifeless' characters. So few, in fact, that one could probably
list them all in a couple of lines: Hobbit, Sherlock, Lord of the
Rings, Valhalla, Fantasia Diamond, Kentilla ... I may have missed one
or two, but apart from my own Runestone there can't be many more (for
the Spectrum, at any rate). What these few games have in common (with
varying degrees of success, it must be admitted) is the aim of
convincing the player that the world in which he finds himself is
already inhabited, that life is going on there whether the player is
present or not. Undoubtedly they have their limitations, but games of
this type create an atmosphere of vitality which is almost totally
lacking in most traditional adventures. Oddly enough, many experienced
adventurers tend to regard these games with suspicion, or even
dislike, often on the grounds that the independent behaviour of the
characters interferes with the serious business of puzzle- solving.
Again, it all comes down to what you want from your adventure playing,
but it's been my steadily growing belief that intelligent independent
characters are almost essential to an adventure if the game is to be a
satisfying imaginative experience and not just an intellectual one.
Which brings us, at last, to the tricky question - "How is it done?".

Adventure games have always offered considerable scope to the BASIC
programmer. Many fine programs have been written entirely in BASIC
simply because speed of response (up to a point) isn't a major
consideration. But the moment we try to introduce independent
characters, the situation changes. The program has to process not just
the player's one set of actions, but several. In Runestone there are
about 40 characters and the program has to look after each one. BASIC
would be impossibly slow for this kind of job, but despite this it
really isn't so difficult to write independent characters into your
adventure programs, and the result makes the effort well worthwhile.
There are two main points to bear in mind.

1) It's essential that we give our characters some semblance of
intelligence (however limited) to make it as easy as possible for the
player to 'suspend disbelief'. We might for example, program them to
recognise and address each other by name, or to adapt their
conversation to suit changing circumstances. However we approach the
problem, we must create the illusion that they are behaving in a
purposeful way.

2) We need to identity those parts of the program which would be
unacceptably slow in BASIC and inject machine code routines where
necessary.


Things to come

In this series of articles, we'll look at the various ways in which
these things can be achieved, rooting out the problems involved, and
finding flexible programming solutions which you can adapt for use in
your own games. In fact, let's make a start this month by solving one
simple (but essential) problem. It's an inevitable fact that in any
program which contains independent characters, we simply do not know
in advance exactly what any given character will say or do at any
given time. This means that we can get nowhere at all without a
thoroughly flexible method of printing text to the screen, word-
wrapping at the ends of lines as necessary. Listing 1 gives an
assembly language program which will do just that, and we shall make
heavy use of this routine in future. If you don't have an assembler
program (go on, treat yourself!) then the BASIC program in Listing 2
will POKE the code into memory, check for errors, SAVE it to tape, and
test it.

Lines 80 and 90 of Listing 2 show how the routine is used. Simply
build up your text from BASIC in the variable z$ and then LET m = USR
64505. There are three points about this routine which you need to be
aware of:

1) It will deal only with strings up to a maximum of 255 characters in
length. This is ample for our present purpose, but if you use the
routine elsewhere you may need to print up your string in several
parts to avoid problems.

2) POKE 64500,1 will cause the text to be sent, line by line, to the
printer as well as the screen (ZX-type printer, that is). POKE 64500,0
turns the printer off.

3) As it stands, the text is printed to line 20 on the screen and
scrolled upwards. If you want printing to start at some other line,
then POKE 64658, (line number) will do the trick.

This, of course, is just a taster to scratch the itch in those finger-
ends. Next month we'll start to build a world in earnest.

