"Easy" Interactive Fiction Languages, Page 3

ADRIFT

Alan may be easy, but Campbell Wild's ADRIFT is designed to be even
easier. According to Campbell, ADRIFT "takes all the difficulty
away... Adventures are built up by adding rooms, objects, tasks,
events and characters. All you have to do is type in the descriptions,
and select how everything interacts with each other from pull down
menus and lists."

When I read this claim I couldn't help investigating it. With Alan,
for the nonprogrammer at least, there is still a slight learning curve
and quite a number of concepts, from attributes to syntax, to be
mastered. But how difficult can it be, I wondered, to make selections
from pull-down menus?

The answer, as far as getting started: not very. Learning to design
simple locations and objects isn't so much a curve in ADRIFT as a
bump. As usual my impulse to WRITE SOMETHING took over and in a few
weeks I came up with some puzzleless IF called LOST about a
fellow wandering around in the woods at twilight. Though it seemed to
be one of the simplest games possible, my puzzleless IF, which
required certain timed events, was probably not the best choice for
ADRIFT. Just about everything in ADRIFT results from direct player
input, making the system better suited to a traditional game of
exploring and collecting objects, not to mention fighting if you use
the combat system. But as with my Alan effort, LOST was
passable, judging from the rankings it's been getting at the ADRIFT
download site.

Writing in ADRIFT was a lot like playing a game, a kind of text sim
where you choose a world of words simply by clicking on
selections. The text the player sees is inserted into boxes and seems
somehow separate from the processes which allow it to be
displayed. While writing LOST I was very aware that the strings
of words I was writing were text, to be read, and not just part of a
conglomeration of coding.

Still, the process was not quite the same as writing straight text
and I ended up with at least two significant bugs. ADRIFT's pull-down
menus for objects, actors and so forth are a lot of fun and even less
frightening for the nonprogrammer than Alan but in a sense are simply
templates. While ADRIFT insures that you can't make an actual coding
error (no small advantage!), as with Alan, or any other language, you
still have to reason things out.

For instance, if you are writing a verb (or "task" in ADRIFT) to
let you "talk to" a character and want to make sure that the player
can't talk to someone who isn't present, you have to remember to go to
the "restrictions" menu within the "task" menu, choose a restriction
on "player or character" and then choose that "player," "must be," "in
same room as," "character." An experienced programmer might decide it
would be easier to just write something like "check act is here" in
code but, even in Alan, such a simple statement presupposes quite a
bit of knowledge about statements and attributes and checks, among
other things.

However, the problem with "easy" authoring systems is that, no
matter how much of the technical stuff is done automatically, the
author can never be relieved of wrestling with the potentially complex
relationships between objects, actors, events and locations -- those
are, after all, the essence of the story that's being told. My wife
and I have co-authored mystery novels and short stories and I've
learned that even conventional fiction can be as buggy as any computer
game. How many times have we had to make sure, for instance, that the
chauffeur doesn't tell the inspector that he saw the butler burying
the boat hook in the garden just after dark when we'd indicated ten
chapters earlier that the chauffeur was at a pub three-hours away at
twilight? (Unless we intended the chauffeur to be lying).