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).